《构建之法》阅读笔记04

《构建之法》阅读笔记（3）

3.开发阶段

3.1 代码规范

类似于写作文时每段首行要缩进两格，敲代码前也要规定好格式规范，所有开发人员都要按照这个规范来编码。机器不用管代码格式，只要语法逻辑无误就可以运行，但程序员是人，过于难看的排版会让人逐渐失去耐心。谁都不想对着一堆i，j，a，b猜测变量和方法的含义，这就对程序员的英语水平提出了要求。写字好看能给人留下好的印象，好的命名习惯亦是如此。

每个人思考问题的方式不同，代码写得再清楚，有时也容易产生错误理解。所以，为了有助于他人理解，注释是一定要写的。这样后期维护时也会节约不少时间，没有人能清楚地记得几个月前敲了些什么。注释具有时效性，一定要随着项目更新而更新，一个错误的注释比没有注释更具误导性。

3.2 确定合作规模

       虽然不是每个公司都有比较完备的团队，但整个公司只有一个开发人员的情况应该并不多见。如果和同事关系还不错，可以试试两人合作的开发模式：一人敲代码，一人在旁检查错误，如此轮替。这样思路出现问题时可以及时得到纠正(两人都具备一定实力的情况下)，不会出现完成一个模块后才发现问题又要大规模修改的情况，减少了修改和重构的时间。但结对编程也容易加深矛盾，如果一个人巴拉巴拉说个不停，那正在编码的同事绝对想一键盘呼过去。。。因此，交流频率和交流时长都要适当控制。在予以他人反馈时，应尽量对他人的行为和后果作出客观评价，避免对他人的本质和固有属性进行攻击。

3.3 选择合适的技术

国内一直有这样的误区，觉得最新的技术就是最好的。其实不同的技术各有所长，适用于不同的领域。python是近几年的产物吗？并不是，只是时代发展到恰好需要它而已。很多时候，已经发布几年的成熟技术才是更好的选择。结合自己的经验，选择合适的技术才是王道。

3.4 应对需求的变动和增加

       需求是千变万化的，可能今天是根据用户心情改变手机壳颜色，明天就是根据用户发色改变壁纸。做好需求文档再开发显然已经不适应瞬息万变的时代。因此，即刻开始->每日开会讨论变动情况->根据变动修改代码的“敏捷”开发模式成为了主流。编码人员要预留位置来应对可能的需求变动和增加，同时保证项目处在一个随时可交付的状态。随时变动，随时交付，更强调适应性而非预见性，这是“敏捷开发”的优势所在。

3.5 注重效率

上面提到的这些，提高代码可读性也好，敏捷开发应对变动也好，都是为了能够第一时间将项目交付给客户。如果每天的开会流于形式，这对加快进度起不到任何作用。同理，如果一个公司的绩效根据代码行数来评定，那趁早离开比较好。每一行代码都要尽可能高效地完成它的任务。只要你愿意，一行代码可以拆成五行来写，但这真的有意义吗？