现场一
“科班程序员”：这功能很好实现呀，直接写几个嵌套for循环，在里面判断一下就行了，直接返回数据就行了，为啥你这写的这么墨迹呢？
“培训程序员”：内心OS：嵌套for？再加上几个if，你确定你的数据超过1w条，没有明显的延迟么？于是，只能告诉他，兄弟，这么写肯定是没什么问题，但是你不想一下后期怎么维护么？你这才一两万的数据我都能感觉出明显的延迟了，为啥不能优化一下呢？
说实话，说到这个问题的时候，也避免不了被大家diss，觉得这不是科班出身的程序员能写出来的代码，而事实情况确实是这个样子的，也可能是工作经验不太足，所以很多代码写的不是很给力，也可能是之前的公司做过几次 CodeReview，所以每次在写完代码之后都习惯性的去考虑一下这个代码还能不能优化的更加简单一点，所以考虑的时间要稍微长一点。
于是，兄弟就开始和我较真了，阿粉的策略一直很简单，兄弟，你自己写个三个for循环，然后去看看你执行完这个循环的时间，然后想想如果在循环中加入查询数据库的所有的操作，你再想想怎么处理，就比如说，你要比对循环里面的List里面是不是有这个的时候，不用写那么多的for循环，不然那不就是X*Y次了，为啥不再单独的造一个List用contains来获取呢？
现场二
“科班程序员”：哥，这个功能是不是还可以再继续把这些内容加上，这块我觉得加上它会更加的完善。
“培训程序员”：来自内心的OS，加个锤子，需求上怎么定，我就怎么干，干完了不是就OK了，为什么要多此一举，但是心里这么想，实际还是不能这么干，于是说，这个地方你看怎么改，邮件给我说，抄送给xxx，然后我再改。
也不是说加这个不行，确实是，按照需求完成了工作之后，你再过来给我扯东扯西的，有点让人难以接受不是，你要是说这地方写的有问题，是吧，咱们还能请教一下你这块应该修改成什么样子，你现在过来给我说加功能，你这不是要搞事情，怎么能惯你这个毛病呢，于是二话不说，先发邮件，抄送给领导，谁让加的，别到时候你一句话，加了功能，到最后出问题了，第一时间找的还是我，于是这个功能需求上没有的，自动屏蔽。
阿粉在这里不是说“科班出身”，和“培训出身”之间的差距，没有任何其他的含义，只是这次确实是比较巧合，这个哥们是刚毕业2年的本科，专业是计算机科学与技术的。仅仅是巧合，不要多想呦。
现场三
“科班程序员”：这个简单，几天就能搞定了，不用那么麻烦，
“培训程序员”：这是啥呀，我得先看看基础，然后再实际动手操作吧。
说实话，不得不说，有时候“科班程序员”虽然有些时候会让你感觉到他们有着一些些的优越感，但是技术也确实很给力，比如说在公司要使用一项新技术，他们能够二话不说的几天就能开始干活，而在这些内容上相比较，“培训出身”的程序员反而没有那么给力，而是得先摸清楚基础，毕竟大部分的科班生都是经过学校系统的学习，知识体系更加完整，所以能够更深入的解决问题，但是有一些碍于时间短的原因，没有成功的积累起来经验的时候，还是欠缺点火候的。
这不正是之前网上看的一个图么？
现场四
这个场景就比较有意思了，就是双双联合和产品battle，面对产品的灵魂提问：
“这个需求用户/运营说要改成这样,”,
我们的统一回答，邮件呢？你发个邮件先，然后抄送给那个谁谁谁，单独给我说，我实在是不敢给你这么干，不然改来改去，还是第一版怎么弄，你就先发邮件，证明我们在干活不是吗？你先去准备邮件吧。
这话说的是没有啥毛病吧，这是经验总结出来了，不然等你开了头之后，接下来的事情就比较难办了，能做完还行，这做不完的话，那就相当于你没有干活，所以，对程序员来说，你把做的功能给我罗列清楚，然后提交上去，下发指定哪些功能确定之后，我再做也是完全不虚的。
说了也挺多的了，阿粉也在后边给大家放上一个曾经的面试题，是属于那种上手实践的面试题。
面试官给的一个面试题，而面试题很有意思，大家可以看一下。这个题阿粉是没有回答上来，但是来自科班生的答案，让面试官很满意：
而他的实现方法和我从网上看到的是一模一样的，
Task<bool> task = new Task<bool>(() => checkCustomerprice()); task.Start(); bool result = task.Result; Task<bool> task2 = new Task<bool>(() => checkInventory()); task2.Start(); bool result2 = task2.Result; if(result&&result2) return true; else return false;
网上的大神也不确定对不对，阿粉觉得这么实现确实也是有道理的，不知道大家的意见是什么样子的呢？
