之前大家议论纷纷的还是网上说的一个程序开发人被逼的跳楼的事。那么我就借这个题目说说一些在互联网公司一些关于开发的扰事。
陈大可是A公司的一个开发程序猿，最近完善某个功能，上线后导致损失了1000万，今天被各层级的老大们拉到各个会议上进行总结或“批斗”，到晚上感觉“生无可恋”。毕竟大可比较理智，这种想法仅存在了1s的时间，终于被自己的正向理智征服。智商重新占有了大脑，毕竟互联网人都是聪明的。
大可是什么事情呢，原来是踩了之前人的坑。之前这个功能都是在使用，在比较小的概率下可能出问题，大可只是在上面添加了功能而已。
- 同事们讨论：
- 大可的同事龙斌：他做的功能他应该都测到，这就是他的问题。
- 大可的领导周：这个不能算他的问题，属于整个组的问题。
- 这个是之前人做的，找之前的人
- ......
龙斌的呼声颇高，对这个是程序者们的基本素养，需要通过全面测试，但是这个很片面，公司如果使用内部很多组件也都需要一个个测试么，甚至linux系统网络底层是否有问题也需要测试么。
这个还是要从一个关于一个互联网一个大家比较通晓的词说起。
「互联网公司都讲究“快速试错”，但是大多数都只实现了“快速试”，没有“错”」
互联网公司都想快速实现某个功能，然后上线，看看行不行。如果不行就取消。但是有很多时候这个取消却是很难。这个需求本想上去看看情况，需求或产品在前期的调研做的很充分，这个却是做的不错，完成上线后，没有大力推行这个功能，导致这个功能很少有人用，都看不出来这个功能有没有问题。给人的感觉就是好像有人用，功能应该没有问题。一天100w次请求，就5、6个请求走这个逻辑，产品上线了，但是产品人员或市场人员不进行推广。最后这个功能使用量非常低，自然测试效能也会降低。（测试效能=线上使用率／测试的人力成本）
后续可能还没有完，还会在当前的状态下在添加功能，最后导致bug累积bug，最后形成系统的崩溃，当这个崩溃的点在某个人开发功能上线的时候，就是所谓的背锅。
是所谓的“先上去看看用户反应再说” 惹的祸。是先上去了，情况没看出来。由于代码的复杂性，也没有在这次的小范围的线上中提前暴露一些bug。
其实理想的状态应该是这样一条路线：
功能->开发->上线->小部分推广->定性分析（总结方案）->
取消方案（或更改方案）-> 开发（注释原功能）->再上线 ......
大可的公司就是没有注重上线后的小范围推广，更不用说分析和更改取消方案了。也就是整个流程都是“快速试”，没有“错”的承认。
这样就会存在很多无用的功能的叠加，越不对之前做的东西进行整理和排除，整个系统越来越庞杂羸弱。问题性越高。一个系统重要功能毕竟核心是有限的，如果不排除额外的功能，就吸收不了更有用的功能，这个海绵吸水是相同的道理。
代码上存在重构，这也存在设计和方案上的重构。代码避免经常重构，产品也应该避免经常重构，程序需要考虑未来的兼容性，产品也需要目前设计和未来的兼容性。这一切都是相通的。
从无到有，从有到精，从精到强。都需要一个产品周期的各个不同职责的人共同的努力。既要划清职责边限（boundary），又要多为对方想一点。这看似矛盾，其实是做好一个市场产品的根本所在。【小注：薄弱地方主要在接口边界处，所以现在很多工业设计都追求一体成型；划清边限主要是为了让更适合的人做更合适的事，而不是责任推诿】
对于程序者们，开发代码是为了不去开发代码，是为了解放劳动力，让代码给你做事。如果整天还是重复着代码，不去思考系统的合理性，整体的协调性，甚至是系统对于整个社会的益处，那站应该去总结下自己了。
