我以前写代码有个毛病。每次要改点东西，都是「推倒重来」。
那会儿接需求，客户说做成什么样，我就照着做成什么样。恨不得每个细节都定死。一个功能做完，逻辑全堆在一块，看着挺完整。过两天需求变了一点，我就得把整个功能翻出来重改一遍。有时候就为了改一个数字，我折腾了一整天，改完还带出新 bug。
后来才想明白，问题不在那个需求。在我当初动手的时候，就没想到需求肯定会变。
这事我是吃过几次亏才学会的。
刚开始我不懂。每次需求一来，我就钻进去改半天。累不说，还容易改坏。做得多了我才发现，有一类人做功能特别轻松。同样一个需求变更，人家十分钟就改完了。
后来我才看懂。秘密在动手之前。
那些人写第一行代码的时候，就把以后可能会变的地方先过一遍。哪个参数大概率要调，哪条规则以后会改，先拎出来，单独放，写清楚。等需求再变，只动那一小块。其他代码碰都不用碰。
我以前是反过来的。一开始只想现在这个功能要做成什么样，压根不看以后会变成什么样。所以写出来的东西是死的。一动，全身跟着动。
这不是聪明不聪明的事。是个习惯。
想通以后我改了做法。就两条。
第一条，动手前先问自己一句。这个地方，以后最可能怎么变。
别什么都留，那样代码反而更乱。只挑那种一看就知道以后肯定会调的地方。写死的数字。顺序。名字。这些东西现在定死，以后改起来最疼。
第二条，把这些地方单独放一边。别跟主体逻辑混在一起。
就跟家里的配电箱一样。你不会把所有电线都埋墙里。你会留一个箱子，把开关集中在那。以后哪一路跳了，打开箱子拨一下就行，不用拆墙。
我现在写任何功能，都会先想一下这个「配电箱」在哪。
做一个配置表单，我把以后可能要改的规则单独列一块。主体逻辑都指着这块去取值。哪天规则变了，我只改这块。其他地方不用动。
写一段业务逻辑，我把那些以后大概率会来回调的参数单独拎出来，放在最前面。改的时候翻到开头改一处。后面不用动。
管自己也是一样。我给自己定了不少规矩。凡是那种大概率会变的，我都不写死，留个余地。
这套做法的好处，一句话，以后不用重来。
我以前最怕的不是写代码。是写完了又得整个推翻重写。那种重复劳动最磨人。它让你觉得前面白干。学会提前留口子以后，这种事少多了。
我见过太多人，包括以前的我。都是把力气全花在这一次这个功能做得多好上。没想过下一次需求变了，改起来多麻烦。结果每天都很忙。忙的都是同一件事，返工。
也不是什么都要做成能改的样子。那样太累，也没必要。就挑那几个你心里清楚以后一定会变的地方，提前给它留个位置。
下次你再动手做一个功能，先别急着把它定死。先问自己一句。三个月以后，这里面哪个地方我最可能要改。
想清楚这一条，你后面能少返工很多回。
