软件开发的 5 条核心准则，让工作事半功倍

作为一名程序员，小伙伴们有没有想过这个简单的问题，“软件是什么？”

软件 = 程序 + 数据 + 文档 + （服务）
程序 = 数据结构 + 算法

看完这两个直观的公式，是不是有一种恍然大悟的感觉，“哦，原来这样啊。”

再来看四条对“软件”的定义，尽管比较枯燥，但概念是到位的：

软件是能够完成预约功能，达到预期性能的，可以执行的计算机指令；
软件是能够让程序解决适当信息的数据结构；
软件是形容程序操作和使用的文档；
软件是一种逻辑实体，具有知识性的产品集合，是对物理世界的一种笼统，同时又是一种人脑智力的成果。

软件开发并不是一件轻而易举的事情，需要经历下面这些基本过程：

1）软件计划，确定产品定位和目标客户。这一步是需要甲方去规划和调研的。

2）软件需求分析：根据甲方需求，分析出甲方需要的产品功能。这一步是需要项目负责人（或者者产品经理）去和甲方沟通的。

3）根据需求进行设计：包括概要设计和详细设计。这一步是需要项目负责人（或者产品经理）做的，并且要正确地传达给开发人员。

4）编码并运行。这一步是需要开发人员去做的。

5）测试：确认甲方需求，对设计和结果进行验证。开发人员要进行单元测试，集成测试，假如有专业的测试团队的话，就需要站在甲方和客户的角度去测试整体产品能否符合要求并达到性能要求。

6）维护：保证软件能够在正式环境下运行，并且对少量缺陷（bug）进行修正，或者者对功能进行完善，或者者对性能进行改进，不断迭代软件版本。

既然软件开发的过程是有难度的，是需要付出时间和精力的，那就有必要遵循少量准则，否则开发成本就会变得很昂贵，开发周期就会拖延很长时间。

准则一： Don't Repeat Yourself。

直译叫做“不要重复你自己”，还有另外一个耳熟能详的版本，“不要重复造轮子”。

在你一开始进入软件开发这个领域后，就肯定要注意，把你自己写过的少量处理方案汇总到一起，定期梳理一遍，写点文档，不断重构，使它们成为一把把瑞士军刀。假如可以的话，把它们开源出来，服务更多的开发者。

有了自己的工具库后，当你下次遇到相似的需求时，即可以直接拿出来用，省去不少时间。

除此之外，你还应该善于利用那些业界已经开源出来的成熟的技术方案，比方下面这些。

准则二： Keep it simple stupid。

著名的 KISS 准则，即“保持简单、保持愚蠢”，和史蒂夫·乔布斯的名言“stay hungry, stay foolish”有着殊途同归之妙。

从苹果产品的设计上也可以表现出来这个准则，起初的手机，比方说诺基亚智能机，带很多实体键，但苹果只有一个 home 键，其余一律虚拟键代替，彻底革了诺基亚的命。

在我们设计软件的过程中，千万不要想得太复杂，越简单越好，等成型了以后再丰富效果，否则开发成本会变得很昂贵，软件即可以腹死胎中。

准则三： You Ain't Gonna Need It。

英文直译为“你不需要它”，该规则要求程序员在必要之前不应该增加功能。极限编程的联合创始人罗恩·杰弗里斯（Ron Jeffries）曾经说过：“总是在实际需要时才实现事物，而不是在预见到需要它们时才实现。”

项目负责人（产品经理）更应该坚持这条准则，千万不要过度拆解客户的需求，在产品设计的过程追加过多自己认为应该追加的功能，由于在一个软件使用中，往往 80% 的请求都花费在 20% 的功能上。

很屡次要的功能可能需要，由于它们的存在而使软件锦上添花，但没有它们，软件的商业价值仍然是存在的。功能越少，开发周期就会越短，这样就更有可能打败竞品。

准则四： Done is better than perfect。

Done is better than perfect because perfect is never done。

很简单的一句英文，能了解吧？

不要总想着把所有的功能做完善，做完美后再上线，应该在产品具备肯定的雏形后就立即上线试错，根据客户的反馈，根据市场的需求再去考量能否追加少量其余的功能或者者优化。

“人无完人，金无足赤”，应该允许少量瑕疵存在，刻意追求完美并不见得是一件好事。乔布斯想要一整块屏幕，但技术达不到的时候，他也是会留一个 home 键的。

我们程序员在开发软件的时候，也应该遵循这条准则，先把功能做出来再说，至于效果，客户的体验，应该往后放，不要总想着尽善尽美，尽善尽美意味着永远也完不成——没有最好，只有更好。

准则五： Choose the most suitable things。

选择最适合的，不要盲目追求时髦。技术日新月异，应接不暇，假如在开发软件的时候，一味追求最前沿的技术，可能就会让产品变成小白鼠。

就如同我们谈一场恋爱，不要一味去追求高不可攀的，往往那些在我们身边的，肯陪伴我们的才是最好的。

技术选型的时候，适合就好。假如产品的目标客户只有一千人不到，就没必要搞分布式，搞大数据，否则就有点“蛇吞象”的意味；等真到了需要搞分布式，搞大数据的时候再更新完全来得及。