每日总结3.29（附《构建之法》阅读笔记03）

每日总结：

　　所花时间：5h

　　代码量：50行

　　博客量：1篇

————————————~~~~~~刷~~~~~————————————————

今天下午没有写太多的代码，只是简简单单写了点安卓的画面

 

 

 

 

 

————————————~~~~~~刷~~~~~————————————————

这里附上第三次读书笔记《构筑之法》阅读笔记03

团队，在软件开发中是个不可缺少的名词，很少有一款开发是脱离团队的。团队是有一致的集体目标，团队要完成这目标。同时团队成员各有分工，互相依赖合作，共同完成任务。

团队有各种各样的模式：蜂窝模式、主治医师模式、明星模式、社区模式、业余剧团模式、秘密团队、特工团队、交响乐团模式、爵士乐模式、功能团队模式、官僚模式。其中我最喜欢的是功能团队模式，掌握各种不同技能的人整合成团队，每个人在项目中有自己的分工，同时在项目过程中又有团队的交流，个人感觉，团队的交流是不可缺少的，这样还能够互相督促，在这种模式下，任何人只要偷懒就会被发现，每个阶段的问题也充分暴露。

我这里有个问题就是代码规范问题，倒不是说缩进的问题，因为对于我来说，缩进其实是最不需要担心的一个问题，我这里一直在用tab缩进，我的问题主要在于命名，因为大一时期的代码简单，要求的变量不多，一般情况下不超过十个变量就能完成所有的任务，但是到了现在的阶段，需要的变量数量激增，而且因为代码复杂程度的激增，导致每个变量都需要定制一个专属的name才方便在各种不同的文件中使用，所以代码命名是挡在我的代码规范面前的一座大山。

 我们还没有走向工作岗位，在学校里做的最大的工程项目也就是三四个人组队开发一个小的系统或者一个小的软件，但是当我们真正走向工作岗位以后会发现这种做法会使得你无法融入一个集体。集体要想高效的工作并取得比较满意的成果，就必须有一套开发标准，代码的规范也包括在这套标准之中，但我们不按照标准去做时，不仅仅会降低整个团队的工作效率，更严重的会引起其他成员的反感。对于程序员来讲，读别人的代码是一件非常“痛苦”的事情，更何况是没有任何标准的“个性”代码呢？因此，代码的规范不仅体现着一个程序员编程的能力，同时也展现其能否适应团队的工作。

要多练多想，熟练技能，不要过多时间放到低层次的问题上，对于一个员工而言，当他一直把解决低级问题变成主要问题的时候，他就没有办法再将精力投入到更需要脑力来解决的问题上，这样的员工是没有竞争力的。只有精通解决低层次问题才能有更多时间学习需要用脑力思考解决的问题上。进而提升自己。