《代码大全》第四节

第４节　关键的“构建”决策

在真正构建之前，需要进行一些决策，首先是要选择语言，这貌似是一个难题，而且很有争议，其实对于具体程序员来说却不是一个问题，你几乎没啥选择权，老板让你用啥你就用啥吧，对新手来说，你会什么就找什么样的工作就是了，对于老手来说，公司要决定换一种语言开发，你就学习学习，换呗，难道你还换个工作？如果你的职位需要你对编程语言做出选择，每种语言都是有他自己的优势和适用范围，我想应该不会有人用javascript写驱动程序，用汇编语言做网页吧。当然除了个人喜好和信仰外，对语言的选择还需要考虑员工的熟悉程度，是否容易招到人等因素。
　　语言确定下来后，要有一套编程规范，以指导团队的编码过程。比如类，方法，变量的命名规则，缩进风格，数据库，表，字段的命名规则，是否强制使用参数化查询等，有了一套CodingGuidline后，会让团队的编码更规范统一，对接下来的编码和项目维护很有帮助。
　　明确你在技术浪潮中的位置，要深入一门语言去编程，而不是限制在一门语言上去编程。这一节是说在软件发展的前期阶段，编译器，开发工具，周边辅助系统都很原始，且有BUG，编程的参考文档也不全面，程序员需要为这些问题花费很多时间，而现在大多数语言，工具都已成熟，程序员可以更专注于实现软件本身的功能，如果你用的这门语言有一些限制，或者少一些你需要的特性，不要受制于它，而是想办法利用一些约定或者自己开发一些类库来支持你的需求。
　　接下来是选择构建实践方式，是用TDD，FDD，MSF，XP还是RUP还是其中几个的组合？应该大多数公司都不会严格的使用某种开发方法论，根据自己团队的实际情况来做决策吧。大多数人都知道结对编程能提高软件质量，有几个公司去做了？我在上家公司和上个项目都曾经推荐过领导用结对编程以节约成本（某些阶段），提高质量，都没有实行下去，可能大多数程序员需要更自由的工作，大多数老板都认为单兵作战更有效率更能提高质量吧。虽然我们不照搬某个软件开发方法论，但我们还是应该对整个软件开发过程的每个环节制定适合自己的流程和制度。比如需求规格说明书或产品设计文档的都包含哪些章节，是否在架构设计之前进行需求冻结？测试用例在什么时期进行编写及评审？由哪些人参与评审？如果需要小组之间协调工作，是否已经指定了每个小组的接口人？是否每个人非常明确自己的职责，哪些是分内的，哪些是没权限做的？是否每个人知道要做的事情该找谁？代码check in的策略是怎样的，是否强制填写comments,是否强制必须能编译通过，是否必须经过同事review?各种文档都应该放在什么位置？BUG的流转流程是怎样的，如何管理的，对BUG的修复是否定期总结？项目的计划由谁来制定，管理和监督？是否在某些关键的里程碑进行需求确认和验证等？团队对测试环境的使用遵循什么制度，是自己更新，还是专门有人更新？是否明确了团队要使用的开发工具，建模工具，文档格式？每个环节都需要一些决策，如果这些规则或者流程不明确，开发过程就会不顺畅，开发人员甚至不知道怎么做是对的。