i am freshman

及时反馈问题：程序员都是乐观的，认为自己的程序没问题，报喜不报忧，

其实leader希望能了解项目的进度，有问题困难瓶颈拿出来大家一起分析。

论单元测试的重要性，单元测试可能测出80%的bug，剩下的bug可能是业务没有搞清楚的原因，程序架构的原因，网路，硬件的原因。

问题永远存在，解决问题会把这个棘手的问题变的不棘手，带来别的问题，所以解决后应该多问问自己肯呢个会带来什么问题，没有意识到的潜在问题才可怕。

人月神话中的人月概念，一个项目再里程碑呃时候延期了，解决办法是什么，增加人员是蠢的，应该把工作划分的关联性很小，不然一项12月的工作，

1个人需要12个月，12个人还是需要12个月，因为每个人都需要解决所有的问题。这就是人月的概念

外科手术团队，这个概念我也有所体会，参与过一个100人的项目团队，每个产品线的负责人每天都要在一个小屋里碰头，吧项目的进展和问题说出来，这可以避免有些细节

主治医生保证产品的概念一致性~~~~

上述的概念一致性在实践中是可取的，但是带来了后面一章的主治独裁，那程序员还能有自己发挥创造的空间么，

我自己的结论是服从命令。如果感觉不对可以讨论，把自己的想法告诉主治医生，但是服从，这就是软件工程。

画蛇添足说的是一个系统架构师在做第二个产品的时候，由于哟第一个项目的经验，非常细化在他的第二个

版本或者项目中加上很多他想到的但是实际上没用的都系，画蛇添足，回头留一下是不是这样。

代码大全：

代码变量和方法名字的艺术性，最好的代码是不需要注释，先从需要注释开始。

多看些优秀开源项目的源码，学习变量方法起名。

开发人员时间花费问题：

1/3需求设计

1/6开发

1/4调试

1/4测试

个体与团队人员的开发效率上也有研究表明存在二八原则，即20%的人开发出80%的代码。

管理你的管理者：

管理人员可能是不懂技术或者技术很老的人员，如果是这种，你需要用你的观点去影响他。

在类似有开会讨论问题头脑风暴这种场合下，他会问你的想法，在这种场合下发表自己的观点影响他是最合适的时机。

过滤脏数据

发布上线有一点跟做饭很像，做饭前把食材准备好，不会导致手忙脚乱