《人月神话》阅读笔记之——第十一章：未雨绸缪

       这一章讲到了化学工程师已经认识到无法一步将实验室工作台上的反应过程移到工厂中，需要一个试验工厂来为提高产量和在缺乏保护的环境下运作提供宝贵经验。这使我想起了以前工作中做过一次类似的事情。

       那是一个商品上传功能，因为公司需要在像万圣节这样的日子前上传大量商品，所以需要在正式上传到现有平台前做个前置的上传-检查功能。我做这个功能一开始是先用最普通的方式，用纯html做上传表单，一次只能上传一个商品。虽然很笨很低效，但是现在想起来，这就是一个“试验工厂”，目的是验证业务逻辑的可行性。

       完成了对流程的完整性验证后，我尝试用那时候刚刚兴起的react对这个功能进行改造。首先是可以做到不刷新页面上传，通过点击按钮在一个list的最上方添加一个空白表单，表单填写完后点击“提交”是通过ajax发送的。同时在后台做数据有效性验证，一次将所有无效数据和必填数据连同提示信息一起返回，然后前端根据返回内容将对应的错误内容的表格显示成红色，当鼠标hover时可以看到错误提示信息。

       由于每个商品的属性非常的多，我通过react的状态切换将主要信息和次要信息分别放在正常状态和下拉状态的表单中，状态切换是react的特性之一，这就使得正常情况下需要三个屏幕宽度才能显示的内容现在只用一个屏幕的宽度就显示完了。

       这个完成品大大提高了商品上传的效率，上传时没有页面刷新的停顿，错误提示更加友好，而且可以在同一个页面里批量完成。在我之后的工作经历中，虽然在我新进的那家公司已经全面使用react做前后端分离，但是产品经理设计出的UI效果依然是非常原始的表单形式，甚至错误信息依然是一次只显示一条，完全没有发挥出应有的实力。由此可见如果产品/UI对新技术的特点不了解，是没法吧技术的优势发挥到最大化的。所以，一旦基本的功能完成，开发人员已经对产品功能有了清晰的理解，那么后面的优化升级就应该由开发人员来主导了。开发人员是对投入/产出比最了解的人，也是对升级空间最了解的人，除非产品本身就是技术出身。

 

除此之外，还需要强调的有：

第一个开发的系统对于大多数项目并不何用。他可能太慢，太大，而且难以使用，或者三者兼有之。

系统的丢弃和重新设计可以一步完成，也可以一块块地实现，但这是必须完成的步骤。

因此，为舍弃而计划，无论如何，你一定要这样做。

开发人员交付的是用户满意程度，而不仅仅是产品。

目标上（和开发策略上）的一些正常变化无可避免，事先为它们做准备中比假设它们不会出现要好的多。

 

为变更计划组织架构

程序员不愿意为设计书写文档，不仅仅因为惰性，更多的是源于设计人员的踌躇——要为自己尝试性的设计决策进行辩解。

为变更组建团队比为变更进行设计更重要。

 

前进两步，后退一步——程序维护

缺陷的修复总会以20%-50%的几率引入新bug。

实现设计的人越少、借口越少、产生的错误越少。

 

前进一步，后退一步——系统熵随时间增加

所有修改都倾向于破坏系统的架构，增加了系统的混乱程度（熵）。即使是最熟练的软件维护工作，也只是延缓了系统退化到不可修复的混乱状态的进程，以致必须要重新进行设计。（许多程序升级的真正需要，如性能等，尤其会冲击它的内部机构边界，原有边界引发的不足常常在日后才会出现）