工作思考：拒绝一次性代码
最近做了一些其他产品线的工程开发，由于做的是功能更为简单的控制器，所以市场上的竞争对手很多，项目的工程周期也很短。
即使是二点备胎，也要和其他的一点供应商赶时间，拼进度。
常常是临时组织一堆人，一窝蜂地干得热火朝天。等到项目结束时，团队成员就原地解散了。
由于没有项目和团队的连续性，很多人都抱着一样的想法。“项目节点这么急，哪有空想那么多，先编过了再说。”
就是因为这样的想法，导致了大家所写的代码都是一次性代码。
所谓的一次性代码，就是一锤子买卖，无法被其他人复用。来了一个新的项目，就在base上直接进行修修改改，或者从头重新开发。
在短期时间来看，一次性代码是可以应付当前的时间节点，但下个项目怎么办呢？那再下一个项目呢？
更令人绝望的是，当项目不可避免的delay的时候，向一个项目添加新的人手并不会使项目提前，我们似乎陷入了一个无法摆脱的困境。❶
然而，项目不可能推掉，需求也无法拒绝，添加新人反而会更加拖延。每个人就这样，被项目的滚滚洪流推动着。看似不断向前，实则随波逐流。
不停地编写这些一次性代码，竟然从来没有想过跳出这个低效的循环。
有时候，大家也会抱怨：“我的base代码就是这么拉胯，我还怎么复用？”
看起来确实如此。但如果你认真地想过这个问题，就会尝试着通过架构设计或添加中间层来对老代码进行封装和隔离。归根到底，还是缺乏思考，或者说是动力不足罢了。
话说回来，即使不从整体的项目角度来考虑，就我们小兵而言，也应该尽可能地编写复用程度高的代码。
想一想吧，你的工资是以代码行数进行支付的吗？应该不是吧。
所以真正具有时效性的软件工程师，在编写每一段代码时，并不会只注重当下，而是着眼于长期。
真正优秀的开发应该是：流水的项目，铁打的代码。
我个人有一个癖好，就是会时不时地去看其他人写的代码。基本上从他的代码风格，就能大体看出这个人的水平。正所谓“码”如其人，这句话还是有道理的。
所以，每一位软件工程师都应该好好想一想，自己写的这个代码，在尽可能少修改的前提下：
● 是否能应对动态的参数调整？
● 能不能复用到该客户的其他项目中？
● 是否同一平台的其他客户也能使用？
● 同一控制器的不同平台项目能否复用？
● 能否跨控制器进行移植？
如果你在编写代码时，都能考虑到以上问题，那我相信你的代码的复用程度绝对不会低。
本文参考资料
《人月神话》❶增加人手只会使项目更加拖延
汽车ECU设计
一个菜鸟程序猿的成长之路。116篇原创内容
公众号
🌏 微 信：@氨气中的战斗机✍🏻 知 乎：@吃完饭后不刷牙👬 公众号：@汽车ECU设计
历史精华文章集合：
氨气“ 携手进步 共同成长 ”
钟意作者
工作思考 · 目录
上一篇 下一篇
工作思考 —— 传统控制器 工作思考：云端工作