主要的构建实践方法

最近在读代码大全，读到主要的构建实践方法时，对这些问题很感兴趣，这一张表的确需要软件设计者深思。

---

Checklist: Major Construction Practices
核对表：主要的构建实践

编码
q 你有没有确定，多少设计工作将要预先进行，多少设计工作在键盘上进行（在编写代码的同时）？
q 你有没有规定诸如名称、注释、代码格式等“编码约定”？
q 你有没有规定特定的由软件架构确定的编码实践，比如如何处理错误条件、如何处理安全性事项、对于类接口有哪些约定、可重用的代码遵循哪些标准、在编码时考虑多少性能因素等？
q 你有没有找到自己在技术浪潮中的位置，并相应调整自己的措施？如果必要，你是否知道如何“深入一种语言去编程”，而不受限于语言（仅仅“在一种语言上编程”）？
团队工作
q 你有没有定义一套集成工序——即，你有没有定义一套特定的步骤，规定程序员在把代码check in（签入）到主源码（代码库）中之前，必须履行这些步骤？
q 程序员是结对编程、还是独自编程，或者这二者的某种组合？

质量保证
q 程序员在编写代码之前，是否先为之编写测试用例？
q 程序员会为自己的代码写单元测试吗（无论先写还是后写）？
q 程序员在check in代码之前，会用调试器单步跟踪整个代码流程吗？
q 程序员在check in代码之前，是否进行集成测试（integration-test）？
q 程序员会复审（review）或检查别人的代码吗？

工具
q 你是否选用了某种版本控制工具？
q 你是否选定了一种语言，以及语言的版本或编译器版本？
q 你是否选择了某个编程框架（framework，如J2EE或Microsoft .NET），或者明确地决定不使

用编程框架
q 你是否决定允许使用非标准的语言特性？
q 你是否选定并拥有了其他将要用到的工具——编辑器、重构工具、调试器、测试框架（test framework）、语法检查器等？

---

程序员会复审（review）或检查别人的代码吗？这个以前基本没有思考过，团队合作要求队员不能只埋头编程，还要学会交流，通过复审或检查别人的代码与队友交流相当重要，这点今天学习了。

转载声明: 出自: Ghoul To World!作者: GreatGhoul