介绍本期技术琐话坐馆司机老G先生，这是老G在技术琐话的第三篇投稿。老G先生，16年IT研发及管理经验，曾在通信大厂、沪上知名电商工作。说起老G，大家或许有些陌生，老K想必是熟悉的，就是老G他哥。
老G作品列表：
昨天，有一篇投稿《精通那么多技术为何还是做不好一个项目？》竟然引起了广泛的讨论，甚至被怼了。
作者痛心疾首的回顾了自己做的项目：
先贴几张代码截图，看一下这个重病缠身的项目的病灶和症状：
- 这是该项目中一个最核心、最复杂也是最经常要被改动的 class，代码行数 4881；
- 结果就是冗长的 API 列表（列表需要滚动 4 屏才能到底，公有私有 API 180 个）；
- 还是那个 Class，头部的 import 延绵到了 139 行，去掉第一行 package 声明和少量空行总共 import 引入了 130 个 class！
还是那个坑爹的组件，从 156 行开始到 235 行声明了 Spring 依赖注入的组件 40 个！
这里先不去分析这个类的问题，只是初步展示一下病情严重程度。
我相信这应该不算是特别糟糕的情况，比这个严重的项目俯拾皆是，但是这也应该足够拿来暴露问题、剖析成因了。
//
作者后面对问题给出药方，并给出了一般性的方案，并总结：
我认为程序员最大的声誉、最重要的职业素养，就是通过写出高质量的代码做好一个个项目、产品，来帮助团队、帮助公司、帮助组织创造价值、增加成功的机会。
这难道不是程序员的本分吗？？？
持不同观点的朋友典型意见如下：
A老师：
这个观点我觉得是技术硬给自己找存在感。
业务方向，运营方法才是关键，技术只是保底。
某千万日活产品，从百万到千万的过程中，代码被外来和尚说是垃圾，但暴发增长了，然后全面重构了，代码质量也高了。可读性也好了。扩展性也强了。但日活停止增长了。
老G观点：
如果业务增长停止了，是市场的原因，技术不背这个锅。 代码重构也不背锅。如果重构代码的过程中，因为没有精力去支持业务，技术团队不能响应业务，那自然是不ok的。
这个文章在敏捷成都群也有广泛讨论，比如
