业务重要还是技术和代码质量重要

Posted 2021-04-23 技术琐话

介绍本期技术琐话坐馆司机老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的。

这个文章在敏捷成都群也有广泛讨论，比如

一位老板说团队某员工“追求极致” 结果在让中小企业“负担”更重了，这个罪名不可谓不大。但试问是追求质量的问题，还是学艺不精的问题啊。

B先生观点：

如果甲、乙两家公司的代码都满足了客户的需求，那这个质量好一些的是不是从客户那边就看不出来了？

熊节老师回应：

如果少打几根钢筋也能把楼盖起来，从客户那边是不是就看不出来？一样的道理。

ke先生观点：

客户后期发现代码可维护性太差，还会给你单么？

老G先生现身说法：

曾经在某行业做单，是关系型销售，老板和甲方信息部的关系，反正多少钱他们谈的差不多。然后干活的时候甲方项目经理不断加需求，然后在项目维护期间尽量让乙方免费干活。乙方的投入就要精打细算了。有可能牺牲部分功能，再跟甲方谈判。求仁得仁！

小海同学说：

大部分团队前期不怎么管代码质量，等大再做，结果已经迟了。

万里兄弟说：

优质的代码首先要遵守开发原则和规范。然后就是测试，除了测试，没有第二种办法。代码质量是无论何时都必须要保证的。

kane：现在很多人写代码不做设计的，想到哪写到哪。

冯先生：追求质量，属于高级程序员的论点。如果是初中级不一定使用，某些公司开发初中级占很大比例。大部分公司都处于求生存状态。

老G观点：

• 程序员需要有追求，比如写优质的代码。代码是程序员的脸面。

• 技术为业务服务，不服务业务的造轮子就是耍流氓。
  

• 业务早期求快，技术上可能糙一定。蘑菇街七公分享过从php到java 服务化的过程，无数的if else 不能支持多业务场景的复用。

• 做技术决策，需要判断在合适的点，对于架构做演进，至少技术不要拖业务后退。
  

• 业务和技术本来不是对立的，技术好一点，凭啥业务要差；业务好了，技术为啥要去拖后退？
  

最后借安总的话说，

希望本文分享的经验和方法能够对此有所帮助！

往期推荐

• 
  

• 
  

• 
  

• 
  

• 
  

• 
  

技术琐话 

以分布式设计、架构、体系思想为基础，兼论研发相关的点点滴滴，不限于代码、质量体系和研发管理。本号由坐馆老司机技术团队维护。