1、好代码不止于编码
好代码从哪里来？
对于这个问题，很多人肯定会说：“好代码肯定是写出来的呀。”
我曾做过多次调研，发现很多软件工程师日常所读的书确实是和 “写代码” 紧密相关的。
但是，这里要告诉读者的是，代码不只是 “写” 出来的。在很多年前，我所读的软件工程方面的教科书就告诉我，编码的时间一般只占一个项目所花时间的 10%。作者曾说过一句比较有趣的话：
“如果一个从业者告诉你，他的大部分时间都在写代码，那么他大概率不是一个高级软件工程师。”
那么，软件工程师的时间都花到哪里去了呢？软件工程师的时间应该花在哪里呢？
好的代码是多个工作环节的综合结果。
（1）在编码前，需要做好需求分析和系统设计。而这两项工作是经常被大量软件工程师忽略或轻视的环节。
（2）在编码时，需要编写代码和编写单元测试。对于 “编写代码”，读者都了解；而对于 “编写单元测试”，有些软件工程师就不认同了，甚至还有人误以为单元测试是由测试工程师来编写的。
（3）在编码后，要做集成测试、上线，以及持续运营/迭代改进。这几件事情都是要花费不少精力的，比如上线，不仅仅要做程序部署，而且要考虑城市是如何被监控的。有时，为了一段程序的上线，设计和实施监控的方案要花费好几天才能完成。
因此，一个好的系统或产品是以上这些环节持续循环执行的结果。
2、需求分析和系统设计
2.1 几种常见的错误现象
相对于编码工作，需求分析和系统设计是两个经常被忽略的环节。在现实工作中，我们经常会看到以下这些现象。
（1）很多人错误地认为，写代码才是最重要的事情。不少软件工程师如果一天没有写出几行代码，就会认为工作没有进展；很多管理者也会以代码的产出量作为衡量工作结果的主要标准，催促软件工程师尽早开始写代码。
（2）有太多的从业者，在没有搞清楚项目目标之前就已经开始编码了。在很多时候，项目目标都是通过并不准确的口头沟通来确定的。例如：
“需要做什么？” “就按照 XXX 网站的做一个吧。”
（3）有太多的从业者，在代码编写基本完成后，才发现设计思路是有问题的。他们在很多项目上花费很少（甚至没有花费）时间进行系统设计。对于在设计中锁隐藏的问题并没有仔细思考和求证。基于这样的设计投入和设计质量，项目出现设计失误也是很难避免的。而面对一个已经完成了基本编码的项目，如果要 “动大手术” 来修改它，相信每个有过类似经历的人都一定深知那种感受—越改越乱，越改越着急。
以上这几种情况，很多读者是不是都有过类似经历？
2.2 研发前期多投入，收益更大
2.3 修改代码和修改文档，那个成本更高
2.4 需求分析和系统设计之间的差别
若有收获，就点个赞吧
0 人点赞
