软件开发开发真正的问题是什么?其实软件开发主要还是一种观念，一种意识，通过人来推动。最近我重温软件开发开发;真正的问题是什么?下面是一份26条关键原则的清单，以指引软件开发团队。

1、不要破坏构建：非常明显，但必须被包含在任何软件开发建议清单中。程序员在签入之前采取所有合适的预防措施进行测试，则永远不会破坏构建。如果构建被破坏，通常是因为有人偷懒了。

2、完整地干完一件事后在开始另一件事：用厨房比喻来说就是：“先上这道菜，再开始做下一道”。软件开发的最大问题就是同时开始几件事情，这将不可避免的造成某些工作被废弃，从而造成浪费。专注于一件事;完整地实现其功能;运行测试;编写文档;签入所有，把这当做一项工作完成，然后再开始下一件事。

3、在用例需要之前，不要添加数据成员：同上一条，不过这是从类的数据成员角度考虑的。似乎显而易见地，“客户”记录需要“送货地址”，但直到有用例明确需要送货地址，才应该实现它。

4、持续学习如何改善质量：这项工作永不会结束，因此你应经常留意可以改善的事情，并收集质量问题被确认和处理的案例。

5、为人而设计，而不是系统：开发者常常因技术而使设计误入歧途。绝不要忘记设计的最终目标，那就是帮助人们完成工作。

6、在用例需要之前，不要实现程序：当你实现一个特定的类，你应该在脑海中有一个特定的用例，同时应该只实现用例需要的方法。你可以考虑该类潜在的功能，写入注释之中，但直到用例真正需要时，才应去实现它。

7、不要害怕做决定，不要害怕改变先前的决定：软件开发开发是关于相应变化和快速相应的。开发初期，你没有完整的信息。你应该尽可能的推迟决策，直到你必须做出决策的时候。没有信息，无法支持你的决定，相反，在有效信息的基础上做出最佳决定。有了新的信息，不要害怕改变先前的决定。(某些“恐龙”称之为摇摆不定，但我称之为响应变化的环境)

8、在代码之前编写测试：测试本身可以用来阐释真正需要的设计。设计的缺陷常常是通过测试用例被发现的。想想看，编码之前，通过这些用例，可以节约多少时间。但是，为用例1编写测试，然后编码，然后再开始用例2。

9、度量、度量、度量：软件开发开发帮助处理未来不确定性问题，但对于过去应没有不确定性。测试应持续运行，每次运行的性能表现应被度量和记录。

10、消除浪费：坦率的说，这是另一个必须包含在任何开发原则清单中的陈词滥调，因为它太重要了。发现浪费并消除它，这项工作没有尽头。消除任何不能增加客户价值的东西。如果你不能确认客户价值，那很可能你并不需要它。

11、建立对构建破坏立即响应的文化：要明白当构建被破坏，会影响项目中的每一个人，因此，最重要的是确认核心代码被构建并合理测试。我曾见过有些团队放任失败测试持续数月，因为那是其它人的工作。每个人都痛苦，但没人采取行动。想反，必须形成共识，那就是小工作能为团队获得大的回报。

12、测试是产品的一部分：很多开发者和经理认为产品就是交付给客户的东西，而其它所有东西都不那么重要。测试应被认为是产品实实在在的一个部分，值得在设计时仔细考虑，甚至，在很多情况下，和产品一起交付给客户。(后半部分有争议，但是内建测试作为软件交付的一部分仅仅占用无关紧要的空间，却在必要时提供显而易见的好处，这种方式应该被考虑。)

13、把相关定义放在一起：组织代码以使高度相关的事情在一起，或在一个类中。这是标准面向对象设计封装原则。理想情况下，所有的类外的代码不需要知道内部工作细节。一些开发者乐于将细节扩散到多个文件中以便按不同方式组织，如所有相同的数据类型放在一起，或者按字母顺序组织。例如，在他们要用的不同包中，将所有常量放在一个类里，这增加了不必要的程序复杂性。指导原则应该是按相关性分组从而隐藏复杂性。

14、所有团队成员应理解客户需要：大型的复杂项目定然被分解为独立的团队，进而被分派给开发人员。但是，不应在此范围内做的是，失去关注最终项目真正用户的期望和目标。

15、过早的优化时万恶之源：引用高德纳被证实的话：代码应编写良好以避免微观层面的浪费，但独立方法层次以外的优化应等待整个程序基于真实的最终用户使用情景的压力测试的进行。仅仅基于对代码的静态理解，直觉地判断对整体性能什么是重要的，结论几乎总是错误的。相反，度量整个系统的行为，辨别1% 真正影响性能的代码，并专注于此。

16、始终在签入之前运行测试：这条准则帮助你满足“不要破坏构建”准则。

17、不要过度强调代码的通用性：这就是着名的“YAGNI-你不会需要它”。当编写一个特定类的时候，程序员总喜欢认为该类可能用于其它用途。如果现在的用例需要这些用途，这很好，但是，程序员经常考虑未被提及的用途，或者那些实际上永远不需要的。(这常常让我联想到经典的周六现场滑稽短剧