学生时代，我还在长沙实习的时候，一位工作了 10 年的 php 跟我说，90% 的长沙互联网公司代码写的都很差，而我们现在处在另外的 10% 里。我当时一听相当触动，没想到就这样，我们写的代码轻而易举地就代表了长沙互联网公司的最高水准。
那时我并不知道什么样的代码是好的代码，直到后来我逐渐上了一些班，有了一些体会，有点知道那些坏代码是怎么来的。
不懂软件工程为何物？
虽然我也没有资格谈论软件工程的具体规划实施，但是我们都知道，国内大多数公司的代码只是为了完成需求不断地堆砌叠加，以求早日上线，这样过不了多久代码就变成了一锅粥。
为什么会出现这种局面？当然和编码人员本身的素质分不开，所以在一定程度上，我们自称“码农”还是有一定道理可寻。
另外就是和公司本身的文化有关，我们知道国内互联网公司的模式是：产品经理提需求，工程师实现需求。这样就把工作形成 了割裂，因为实现需求的工程师不知道产品形态的规划，无法在代码上做出合理的架设。很简单，如果是半桶水，我们不会准备一个大缸，结果却缸低都铺不满。将工作进行隔离后，产品经理和工程师就会存在一定的对立面，一方要快速实现，一方就觉得“好，那就实现吧”，这样极易造成代码混乱，变成技术债务。
为了避免这种情况，让就必须让工程师实际参与具体的产品规划，避免工作的割裂。据说 Facebook 在这方面做的不错，谁知道呢。
看平安科技程序员和产品经理打架的事件，我们就会发现这两种职业产生的冲突可以有多大，非常有意思。平心而论，工作只是工作，犯不着和个人产生冲突，但是冲突就是发生了。举工程师要参与具体产品规划的观点来说，一些产品经理听到了可能会说：程序员会有意规避实现的难度，最后产品不可用。程序员的反应也可能是：让我来规划产品，程序上的东西要少很多。可见，这两种观点的荒谬。
技术 leader 不给力
据说程序员社区 CSDN 的代码写得十分糟糕，蒋涛决意要重构代码，在微博上发布招聘广告。
阿里的玉伯转发他的微博并给出评论：
技术债务往往来自产品混乱、业务不清、高管不行。
回到上面那个问题，技术 leader 应该对产品形态具有一定的话语权，才能对代码的架构做出合理的规划，千万不能变成产品运营团队对技术团队的中间控制人。或者说，只管人，不管项目。
程序员自身的问题
现在我们很少会从 0 开始写出自己的第一行代码，我们总是基于框架、基于第三方库、基于前人的代码开始写我们的代码，因为我们是站在巨人的肩膀上，但是我们依然写出了烂代码。
从前端来举例，以前我们用 jQuery，代码容易写着写着就变成意大利面条，但是现在用 vue 用 react，框架本身预设了良好的代码结构，但是我们还是不可避免的写出了糟糕的代码。
所以我想说的是，程序员本身应该努力写出优雅的代码，热爱分享与学习，从行业里大师的代码领悟，具有让事情变得更简单的能力。
总结
写出优秀的代码是一场博弈，今天来看，这可能是一个需要解决的问题，明天太阳也照常升起，关键在于我们能找到一个平衡点，并维持这个平衡点。
