我的10个开发原则
在从事软件开发若干年之后，我已经对“软件应该如何设计”有些心得。实际上，我有了这样一个结论：所有的事情最后都浓缩成10个原则，如果我们很好地执行这些原则，任何软件开发都应该会取得成功。
0. 客户至上
“如果我们没有关注客户……其他人将会取代我们。”
从客户的角度出发，客户首先会把焦点集中在产品开发的真正价值，其他方面（例如概念、需求、技术等等)在项目中是次要的。
不关注客户，就是程序员常犯的5个非技术性错误的其中之一。
1. 代码质量
即使代码质量是一些非常主观性的东西，（甚至有人说所有的代码都有问题），它却影响着很多重要的方面，比如：如何去维护应用程序，或者如何去带一个新手程序员。
在我看来，代码质量的指标在于：简单性、可读性、健壮性和可测试性。其他特性，例如外观或者可扩展性，如果没有要求的话，在你的应用程序中可以灵活设计。
2. 授权
软件开发过程中最重要的资源是人力，而非技术。人力决定产品的好坏，但他们需要得到授权。
授权是一个鼓励开发者积极做事和制定决策的过程。一些高效的机构的授权体现为：指导\配合或者委派。 不知你是否也有过和Derek相同的经历，每隔5分钟就有员工跑过来向他请示这个和那个问题？如果有，可以通过《管理者的困境：放权或者崩溃》这篇文章看看Derek如何解决这个问题的。
3. 持续集成
从我的经验看来，集成是软件开发的主要问题。在项目后期或者大型功能模块完成后，等着集成是一个令人纠结的过程。
持续的集成是保证每部分委托的代码在系统中自动集成的过程。请记住，持续集成优先于持续编译。
Martin Fowler的这篇文章是网上关于持续集成的最优秀的参考文献之一。
4. 迭代
迭代提供了持续的反馈信息。持续反馈很重要，因为它降低了软件开发的不稳定性。
虽然迭代经常与敏捷方法有关系，不过有其他方法例如RUP，也使用迭代，他们却不是敏捷方法家族中的一员，记住这一点很重要。
5. 自动化测试
允许重构和递归，给开发者带来自信，如果得到有效贯彻的话，会提高最终产品的正确性。对于自动化测试，你可以考虑与测试有关的一些情况和如何编写一个良好测试组件的建议。
6. 重构
不管你如何关注编码，在你迈出第一步的时候，你将会走错路。重构是我们用来保持代码修改的做法，以满足系统说明的必要更迭。
7. 非正式架构
前期的大型设计，除非你是NASA，能够把项目50-60%的时间花在这上面，否则这完全是浪费，毫无准备去编码情形也一样。非正式架构是一种折衷解决方案，它在项目发展的基础上进行讨论，并存留于文件，留言板或者类似的物件之中。
8. 沟通
软件开发只与沟通有关。客户向软件开发团队阐述他想要达到的目标，以便于软件开发团队能通过编码形式向计算机解释。
9. 避免浪费
浪费是软件开发过程的主要生产力杀手之一。毫无必要的会议、毫无必要的要求、毫无必要的过程和毫无必要的文件成为最常见和最危险的浪费。
0. 客户至上
“如果我们没有关注客户……其他人将会取代我们。”
从客户的角度出发，客户首先会把焦点集中在产品开发的真正价值，其他方面（例如概念、需求、技术等等)在项目中是次要的。
不关注客户，就是程序员常犯的5个非技术性错误的其中之一。
1. 代码质量
即使代码质量是一些非常主观性的东西，（甚至有人说所有的代码都有问题），它却影响着很多重要的方面，比如：如何去维护应用程序，或者如何去带一个新手程序员。
在我看来，代码质量的指标在于：简单性、可读性、健壮性和可测试性。其他特性，例如外观或者可扩展性，如果没有要求的话，在你的应用程序中可以灵活设计。
2. 授权
软件开发过程中最重要的资源是人力，而非技术。人力决定产品的好坏，但他们需要得到授权。
授权是一个鼓励开发者积极做事和制定决策的过程。一些高效的机构的授权体现为：指导\配合或者委派。 不知你是否也有过和Derek相同的经历，每隔5分钟就有员工跑过来向他请示这个和那个问题？如果有，可以通过《管理者的困境：放权或者崩溃》这篇文章看看Derek如何解决这个问题的。
3. 持续集成
从我的经验看来，集成是软件开发的主要问题。在项目后期或者大型功能模块完成后，等着集成是一个令人纠结的过程。
持续的集成是保证每部分委托的代码在系统中自动集成的过程。请记住，持续集成优先于持续编译。
Martin Fowler的这篇文章是网上关于持续集成的最优秀的参考文献之一。
4. 迭代
迭代提供了持续的反馈信息。持续反馈很重要，因为它降低了软件开发的不稳定性。
虽然迭代经常与敏捷方法有关系，不过有其他方法例如RUP，也使用迭代，他们却不是敏捷方法家族中的一员，记住这一点很重要。
5. 自动化测试
允许重构和递归，给开发者带来自信，如果得到有效贯彻的话，会提高最终产品的正确性。对于自动化测试，你可以考虑与测试有关的一些情况和如何编写一个良好测试组件的建议。
6. 重构
不管你如何关注编码，在你迈出第一步的时候，你将会走错路。重构是我们用来保持代码修改的做法，以满足系统说明的必要更迭。
7. 非正式架构
前期的大型设计，除非你是NASA，能够把项目50-60%的时间花在这上面，否则这完全是浪费，毫无准备去编码情形也一样。非正式架构是一种折衷解决方案，它在项目发展的基础上进行讨论，并存留于文件，留言板或者类似的物件之中。
8. 沟通
软件开发只与沟通有关。客户向软件开发团队阐述他想要达到的目标，以便于软件开发团队能通过编码形式向计算机解释。
9. 避免浪费
浪费是软件开发过程的主要生产力杀手之一。毫无必要的会议、毫无必要的要求、毫无必要的过程和毫无必要的文件成为最常见和最危险的浪费。
