关于软件开发的一些想法

最近读了Aaron生前写得《The Pokayoke Guide to Developing Software》原文地址：http://pokayokeguide.com/，收获很多，分享一下。

需求

• 客户需求是一个好项目的基石。不要做没人想用的东西。
• 一个客户的准确需求比60亿人的理论需求靠谱。因为准确需求即意味着一个忠诚客户，60亿人的理论需求可能意味着nothing；另外，人性是共通的，一个忠诚客户意味着你很容易找到更多相同的客户。
• 做自己能感受到的需求，最好是需求自己来源于自己。如果不是，那么你最好能够按照目标用户的生活方式去感受一下，是否真的存在这个需求；如果这也做不到，那么你至少需要仔细研究你的目标用户，弄清楚他们的真实需求。
• 弄清真实需求和虚假需求，有时候，对某个Idea的过度热爱，会蒙蔽你，让你觉得真的有这样的需求。因此，对于自己过度热爱的想法，最好能找到一个无关人员的需求和你的一致。

想法

• 有了需求之后，需要的是实现这个需求的想法，冷静客观的评估你的想法，是否真的能满足所有需求。想法必须以需求为基础，而不是因为对某个想法的喜爱，而在自己心中设想许多不存在的需求。只从一个需求出发，去认真思考一个想法，比想同时满足多个需求好。
• 想法源于一个需求，并不是说不存在同时满足多个需求的想法。好的想法可以，但是这个想法天生就是某几个问题的解决方案，但是其本来是来源于一个需求的。而不是把一个解决方案拧巴成能够适应多个需求的想法。
• 当有了一些基础的想法之后，千万不要过早的进入各个细节。但是，基础想法进入你的脑袋之后，无可避免的会有各种各样的附加想法，特性钻进你的脑袋，好像你不做点关于新想法的事，就没办法安心。这个时候，只需要把所有的想法写到一个文档中，在记录的过程中，就有机会把所有的想法列出优先级。也许你以后都不会再去看这个文档，但是找个地方，安静的写下这些想法，可以防止这些想法一直骚扰你。

假设前提

• 确认了解决方案之后，接下来就是实现它，这个时候，很容易整个人投入进去，开始一步一步的构建一个完整系统，生怕自己做得少了，其实，在项目刚开始的时候，开发者应该想的不是怎么做更多，而是怎么做更少。
• 每一个想法都是基于一些假设的，如果这些前提假设是错误的，那么想法毫无疑问是会失败的。因此，做最少的事情去验证想法里面的每一个假设，使用Lean Startup的MVP（Minimum Valuable Product）概念，和验证环，一步一步的构建你的产品。

团队

• 想法有了，如何验证产品假设的策略也有了。接下来可以开始构建产品了，第一步就是确定该产品的“Product Owner”，就是这个产品的“乔布斯”，“张小龙”。 该Owner的责任是保证所有完成特性的一致性。
• 使用卡片管理描述每一个Task，它的目标用户是哪些，这个Task能够给用户带来哪些价值以及如何验证这个Task的效果。这样，整个产品的构建过程就被分成了一张张的卡片。
• 有了卡片之后，需要根据优先级排列，越重要的假设前提需要越早验证。排定好优先级之后，团队的UX和Product Owner选取最高优先级的卡片，开始设计该特性的用户体验，一定确定，由Product Owner拍板，然后转交给开发人员开始开发该特性。
• 在实际的开发过程中，如果实现或者实际使用过程中导致多次修改原来的用户体验设计，那么就有必要引入Product Owner来对每次修改进行把关。

开发

• 测试自动化是必须的。
• Pair Programming，让开发人员更有融洽，更有乐趣一点吧。
• 每次提交之前，请检测一下所有的代码改动。

架构

• 所有的代码都放到同一个版本库中，如果该系统涉及多个团队维护的多个模块，那么建议拆分为多个应用，以Service Interface的形式相互协作。
• 显式声明所有的依赖，不依赖任何不曾使用的库。
• 所有在各个环境会使用不同值的东西，使用单独的文件保存，并且能够很容易的切换使用不同的配置文件。
• 所有的后台服务都当做远程服务，不要把本地的和远程的区别对待，它们都是通过网络服务的。
• 代码部署分为3个阶段， build（包括代码的编译，构建等）， release（获取对应的配置文件，放置到对应的服务器上）， run（运行系统）。 这3个阶段必须是相互隔离，不能在一个阶段做另一个阶段的事。
• 系统的所有进程是无状态，所有关于状态的信息，都应该统一保存在某一个后台服务中。
• 每个应用都是自我完备的，只需要 通过端口和外部通信。
• 应用应该可以Scale out，可以通过增加新的instance就可以提升吞吐率。
• 应用应该很容易启动，关闭，并不对系统造成任何损害。
• 开发环境和产品环境尽可能一致，最好是只有配置文件上的一点差别。
• 由基础设施提供日志功能，而非应用本身，应用只需要把日志内容写到标准输出流。
• 所有的管理任务应该只是一次性流程。
• 使用Chaos Monkey测试系统的健壮性。

部署

• 每一个后台服务的Code Change都应该通过migration服务完成，该服务知道如何回滚所有的变更。每次的变更都要同步，保持代码中的版本，和后台运行的版本一致。migration服务功能一定要严格测试。
• 不要使用code brunch，所有人都向Main Line提交代码。如果实在是有没完成的特性变更，可以使用Feature Toggle使该部分代码不影响当前版本的系统行为。
• 每一次代码提交都应该触发CI，重新Build，测试整个系统。
• 构建一个监控系统，监控整个部署过程，如果一些关键的业务指标被新版本影响，该监控系统需具备自动回滚到前一版本并通知开发团队的能力。
• 任何没有经过Product Owner查看过的特性代码不能出现到产品行为中，开发代码特性的控制权给Product Owner，让他们可以选择性的添加某些用户使用某些特性，以验证某些业务假设。如果效果好，就可以逐步开放直到该特性开放给所有的用户。

发布
有人喜欢好莱坞式的发布流程，发布前几个月就开始造势什么时候发布什么东西，这对于电影，硬件可能是对的，但是对于软件系统来说，这并不是一个好的发布宣传，因为软件产品的bug是在所难免的，造势太早，导致把一些小问题暴露在过多的用户面前，而且很多用户会对功能吹毛求疵，对系统开发会造成很大影响。

软件系统发布更倾向于一种温和的，逐步提升的发布方式，先拥抱小部分迫切需求客户，让他们使用系统，同时根据他们的反馈改进系统，再通过他们邀请更多的用户，在研究新的客户价值，在这个不断循环的过程中，你就拥有了一个好的系统，和很多的用户。