闲话哲科思维与软件开发

最近学习混沌大学的哲科思维课程体系，对哲学科学有了一面之缘。神学、哲学、科学，一脉发展至今，哲学注重严密的逻辑推理，科学同样对先思想后实践这一脉络延展发展而来。计算机属于科学发展的产物，同样由先理论的奠基再进行实际的落实应用。

工程化思维：最近读计算机天才王垠的一篇文章《程序员的心理疾病》一文提到了程序员严重缺乏工程化思维:

如果力学工程师犯了错误，飞机会坠毁；如果结构工程师犯了错误，大桥会垮塌；可是如果软件工程师犯了错误，大不了网站挂掉一小时，重启一下貌似又好了。所以所谓“软件工程师”，由于门槛太低，他们的工作严谨程度，其实是没法和力学工程，结构工程等真正的工程师相提并论的。实际上“软件工程”这个名词根本就是扯淡的，软件工程师也不能被叫做“工程师”。跟其他的工程不一样，软件工程并不是建立在科学的基础上的—计算机科学其实不是科学。

文中说到软件行业普遍缺乏工程思维，这点也有同感，因为大部分程序员是在从事民用企业内部软件开发，这种环境下，对软件的可靠性要求并不是近乎于严苛的程度。而且门槛低，招致大量非计算机专业学生的涌入也是事实，当然非科班的也不乏优秀的工程师。我对于计算机科学不是科学这个观点不能表示认同。

陈皓（网名左耳朵耗子），曾在极客时间《左耳听风》专栏中提到了软件的工业级、民用级的差异，其中论述了软件工程的好坏等级问题。如果按照工业级软件的开发流程，软件的开发过程是有极严苛的流程限制的。而目前的 IT 行业来看，多数公司对软件工程是不够尊重的。其表现在：不尊重软件的开发过程，压缩排期，急于求成。这就造成了软件开发过程的环节压缩，交付水准缩水。最终会使用户成了测试群体，bug 频频爆出，对开发团队抱怨，形成不信任的思维定势，一有问题第一反应是把问题归结于软件系统不好用这些客观层面。

软件开发，是属于一个创造性行业，他需要一个宽松的环境来进行发挥与创造，而不是天天被排期紧压着喘不过气来。

那么，正常的软件工程，怎样才算合理，才能少出问题呢，下面仅从我个人的经验层面总结出以下规则或注意事项：

1. 开发前一定要做好调研，设计，沟通的关键内容最好通过邮件多方确认留下会议纪要。我曾经经历过一次需求方案评审，因为是在夜里加班开的会，散会后已经快凌晨，没有发会议纪要，后来开发完成后，另一个合作方的系统展示与业务预期不符，后来对方责怪我们团队在会上说了 xxx 他们就是按照这个 xxx 开发的。但是，这个没有记录，事后也很难想起来，再加上对方没有按照产品文档要求做事，这个后来只能重做，好在业务并没有追究责任。开发者其实不愿意卷入更多扯皮事件中来，所以我们还是不断完善做事流程吧。

2. 程序功能设计时，要预先通过假设、逻辑演绎，推敲设计的逻辑是否能够自洽，文章开头提到过，计算机是科学技术，非常注重演绎推理，这点我深受混沌大学的哲科思维培训的内容影响。

3. 开发时除了实现程序功能以外，还要考虑程序的数据边界、异常、安全、性能、监控、日志等事项，而不是开发出功能就结束了。并且，开发的完成并不意味着程序就可以甩手了，而是还需要很长时间的维护与迭代，使其完善。

4. 调试：调试时至少做到可用版本的研发侧调通，其中包含环境的搭建、反复验证没问题，特别是环境问题，需要极力避免环境的错位导致的问题掩盖。

5. 自测，研发不应该只停留在写代码层面，对于程序的测试也是需要负有相当的责任。而且研发很清楚自己的程序的细枝末节，对写起程序自测清单，将会是很容易的事情，按照自测 checkList 自己跑完一遍，能够发现一些非常明显的问题，自己修复一遍，达到一定可用的水平再给测试团队进行细致的测试。而我们常常对自己开发的程序过于自信，更甚者直接修改生产代码，未经测试就发布，这样的风险就是会花费很多精力处理意想不到的问题。

6. 测试：测试团队根据研发的内容相，做全面的验证，为的是保证程序能够达到交付程度，是研发团队的补充与护航角色。但是不能说，测试通过了就一定没有问题，《软件工程》这本书有句话，我觉得非常好：测试只能证明问题的存在，而不能证明问题不存在。所以，每当生产环境出现问题，我们第一要考虑的是快速恢复，而不是追责。

好了，啰嗦这么多，总结了一些自己从软件开发这几年的一些经验与体会，技术进无止境，如果你有更好的心得体会，欢迎留言交流。