Artwork? Or tools?

Artwork? Or tools?

是一篇主观的文章

在实习和刚毕业的那一两年, 由于在写业务, 然后又想刷经验, 所以很容易就写出一些匪夷所思的代码, 虽然有部分设计是合理的, 但是很多都有过度设计和过早优化的味道. 那个时候也因为代码怎么写, 和 同事争吵过很多次. 但其实里面的很多写法, 只不过是 城里的人想出去, 城外的人想进来, 从一座城 去到另一座城 而已.

所以 工程师是在做艺术品吗? 呵, 当然不是啦. 那我们在写代码的时候纠结什么呢? 去追求的那些是幻灭 还是 真实存在的梦想?

很现实的是, 代码是会腐烂的, 架构是会腐烂的, 我们所开发的一切都在腐烂, 我们所做的都只是在给它续命, 然后等待下一次重构.

工程师所做的工程 和 艺术品 不一样, 艺术品做完 作者 可以不存在了, 比如 拉斐尔 的《雅典学院》, 距今 五百年过去了, 我们依旧可以在 梵蒂冈看到他的画.

但工程不一样, 工程是有目的性的, 比方说 做一个 社区买菜软件, 去追当下短暂的风口. 它可能生命周期就 3-5 年, 难道我们要在这一个又一个的 3-5 年生命的项目里一次又一次去追求所谓的 “艺术” 吗? 追求到了又怎么样? 下一次从头再来一次吗?

纵观目前大部分的开源软件, 你会发现即便强如 Kubernetes , TiDB 这种软件, 里面很多代码其实也写的很一般, 不是说开发者能力不行, 是没有必要, 软件规模到达一定程度之后必然会出现这种状况. 即便强如 Linus , 你会发现 Linux 系统中的很多功能也是顺应需求 “生长” 出来的.

那在工程中我们要追求什么? 笔者认为应该追求实现需求, 更加的顺应需求. 工程的本质只是工具, 为了完成需求而存在的, 仅此而已.

那么为了完成需求, 我们会返回去思考比方说 业务上 DDD, 六边形架构, 在平台上去思考分层分级, 剥离和拆分等, 这是一个由内而外再入内的一个过程, 但思考的东西已经变了.

updatedupdated2021-08-102021-08-10