代码路上的自省

今天在知乎看过度设计,看到一段评论,让我反思了好久.先贴帖子.

开发一个组件，你可以
1. 用1天的时间做完，但只是功能上的可用，集成的人需要花2天要处理各类的问题，完成你没有完成的工作
2. 用1天时间做完，再用1天时间优化设计，让你的组件更灵活通用，这样集成的人只需要一天时间就够了，甚至更短

大多数开发者为了显示自己开发效率高而走了第1条路，这是一个悲剧，也是一个普遍现象。

但是是谁的悲剧可不好说！！！

因为只用了1天时间，所以代码写的不怎么样，文档更不用提了，根本没有。别人在集成时不得不过来和你讨论，这在无形中增加了你的被需要感，领导看在眼里你会是一个不可或缺的角色。突然有一天，某个老几在用你的组件时发现出问题了，怎么办，火烧眉毛了，那边等着发布呢，测试团队、部署团队都在等着开发release，紧急时刻大家不由自主的想到了你——俺们的救世主！而你面对无比风骚的代码，挠挠头，“我今晚通宵搞定”，其实是我现在不知道怎么办！当然，最终问题是会被搞定的，一个通宵不行还能连续通宵。

啊，你tm简直是太重要了，太敬业了，领导啊，快给他加薪吧，看他贡献多大，你不给他加薪我都看不下去。升他！升他！领导当然也乐意为大家竖这么个劳模榜样！

假如，我是说假如，你脑抽走了第2条路，你的组件是那么的漂亮，接口不多不少刚好够用，不那么主流的操作场景都被你覆盖到了，用组件的人只需要一两行代码就搞定了，撑死0.5天，你默默的在心中算计：如果有一个人用这个组件，第1条路需要3天，第2条路需要2.5天，节省了0.5天；但是如果有两个人用就能节省2天，三个人节省3.5天……我为公司节省了这么多人力，应该是做了很大的贡献了吧！加薪有望，嗯！

然后一天过去了，两天过去了，一个月过去了……你的组件根本没有人提起，你开始不安，想要去弄清楚怎么回事。你找到了平时要好的哥们，“哦，你说那个啊，挺好用的，这个功能挺简单吧，大家很快就集成好了，我看都没出过什么问题”。

你的心中一w只草泥马飞过，MLGB，要不是老子幸幸苦苦的在那设计，你们这帮孙子能这么轻松？你们能那么容易集成？不是老子你们还在那撅着腚修bug呢！

这个时候老板从你的身边路过，“小伙子呀，可得好好干，你还年轻，正是努力奋斗的时候，加把劲！”

全剧终，
卒，
一辈子是个程序员！

看完有些感慨,也有些反对.

看似无懈可击的故事,却有一个BUG, BUG就是你会永久在这个公司干,不会遇到天花板,而公司也可以永久存在并且永不转型.

如果年限的积累导致需要走向更高层次,没有足够的设计底蕴,结果可想而知.

所以,我觉得结果会颠倒,1会成为永久的程序员,而2,会成长为架构师.当然,也是假定1先加薪升职后不会去做2;

那么问题来了,什么才是最好的方式?

我向往的代码生活的时间分配是:编程30%,设计40%,阅读20%,交流10%

所以我个人认为,设计>编码.能编码的程序员一招一大把,能设计好系统的,才是核心.

人生经验：
T0：学习OOP(面向对象)基本原则，以功能性和可用性为第一要务；
T1：学习通过增加抽象（层）提高代码灵活度和泛用性；
T2：学会避免过度设计。（不要引入没必要的层，只封装变化的部分）
T3 以上我还没悟透。
假设你在T1：
如果T2 跟你说没必要，那就是没必要。
如果是T0跟你说没必要，别理他，又不是他维护你的代码。

作者：钱森
链接：https://www.zhihu.com/question/52951851/answer/132951293
来源：知乎
著作权归作者所有，转载请联系作者获得授权。