vlambda博客
学习文章列表

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

介绍本期技术琐话坐馆司机老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 不能支持多业务场景的复用。

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

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


最后借安总的话说,

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

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

往期推荐








技术琐话 



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