这是一个创建于 1974 天前的主题，其中的信息可能已经有所发展或是发生改变。
一点随笔感想，内容比较单薄，楼主大四抠脚中，大佬轻喷~
——————————正文——————————
在《人月神话》的第一章《焦油坑》中，有这么一句“表面上看起来好像没有任何一个单独的问题会导致困难，每个问题都能获得解决，但是当它们相互纠缠和累积在一起的时候，团队的行动就会变得越来越慢。”
在读到这句话时，我首先想到的是“墨菲定律”，没想到这在软件中同样适用。
在 1949 年，工程师墨菲在同事将 16 支火箭加速度计全部安装错误的情况下，得出了一个结论：如果做某项工作有多种方法，而其中有一种方法将导致事故，那么一定有人会按这种方法去做。
后来，这条定律衍化为四个方面：任何事情都没有表面看上去这么简单；所有事都会比你预计的时间长；会出错的事总会出错；如果担心某事发生，那么它将更有可能发生。
这乍听起来似乎玄而又玄，但是渐渐地，它在我的生活中得到多次印证。正与开篇佛瑞德·布鲁克斯在《人月神话》中论断不谋而合。
有人说，软件工程的本质就是对复杂性的管理，而大型软件的复杂性主要来源于以下三个方面：
问题域本身的复杂性。举个简单的例子，红绿灯在日常生活中随处可见，但是它究竟是按照何种规则调度来使得交通尽可能通畅？是否是通过对车流量的监控来动态调整的？在何种情况下允许人员干预以及如何干预？这本是一个貌似简单到每个人都会忽视的问题，却蕴含着一定的复杂性。那么一些人们觉得“复杂”的事物，将会拥有更高的复杂性。
采用的技术方案引入的额外复杂性。对于这条，我的理解比较浅。举一个我自认为合适的例子，可以参照下图：
涉及到的人和组织再引入的额外复杂性。关于这点我认为应该是大家最深有体会的，不然也不会有那么多的产品与开发，前端与后端的矛盾了。此外，在一些大型公司的历史中，也常常因为组织架构与战线的问题所引入的复杂性，错失了良机。
在对于这三种复杂性的管理中，我认为应该尽量秉持一种对于单个简单问题的自我约束。
什么是自我约束呢？就是在我的能力水平背景下，我觉得那样做应该会好一点，但是为了省事儿，选择了一种可能会引起混乱的做法。
物理学中有一个“熵增”的概念，即：熵增过程是一个自发的由有序向无序发展的过程，虐猫狂人薛定谔也就曾高瞻远瞩地指出了熵增过程也必然体现在生命体系之中。
这种例子不胜枚举，比如不打扫的房间只会越来越乱，不护理的皮肤只会越来越差（没错，就是我）
在软件中，任由“熵增”，最终必定会跌入“墨菲定律”。
比如，一段代码本可以提取为公共方法 /组件，但是这需要轻微地调整结构，以及随之带来的一些调试工作，这是有意义的，但很多人会选择复制粘贴，能跑就行。《程序员修炼之道》中提到的“ don't repeat yourself ”原则，便是如此。
比如去拥抱函数式编程，虽然这学习和使用起来更有挑战，但是在可读性和简洁性上更胜一筹。
比如在完成代码后注意立即更新相应的文档，谨防遗忘，更重要的是避免给合作者带来难以溯源的问题以及问题产生之后的沟通成本。
这些虽然都是小事，要做到真的不容易。我觉得原因有两方面，一是认知不够，积累太浅，比如我所认为的“ great ”，在他人看来仅仅只是“ common ”，这需要通过学习来弥补。第二点就是自身的松懈，觉得“差不多就完事儿了”。
所以 X 叔和我说，项目肯定都要阶段性重构的。
不要等你的代码变成了难以攻克的庞然大物，才后悔之前没有常行举手之劳。
今天在提交代码时，由于有多条 commit message，但这都是对一个功能的描述，有的甚至只是改动了一个微小的参数。如果就这么 request 到 upstream repo，必然污染了 log 记录。
所以我用 rebase 合并了无关 commit，虽然只是一个很小的细节，但感觉舒服多了，将来如果其他维护者需要通过 log 来理解代码，相信会给他带来一些便利。
Peter Hutterer 有言：重新明确一小段代码的语境与目的是非常浪费时间的，但是我们不可能完全避免掉它，因此我们应该尽可能地去减少它。Commit Message 就是这样的工具，并且同时 Commit Message 会告诉你一个开发者是不是一个好的合作者。
虽然我还很菜，或许你现在也很菜，但这不妨碍你尽可能去成为一个好的合作者，与人方便与己方便。
以上是我在提交一条 commit 时的想法，标题很宏大，观点还很稚嫩，一些感想，信手偶得。
 |
1
noNOno 2018-11-20 13:12:07 +08:00
文章太长了,能总结下么...
复杂问题简单化,请从手头做起. |
Select Language