为什么小公司的代码比大公司的好维护

博主: Simon Lin 创建于: Aug 15, 2018 更新于: Aug 15, 2018
分类: management
标签: management tech

为什么小公司的代码比大公司的好维护


  我知道,提的这个题目会有人过来争辩,我说的小公司是成立一年以内的新公司,那种已经建立3-5年的小公司不是我说的那种,而大公司是指10年以上历史的企业,至少1000人以上的开发团队吧。还有人不信的话,去看看微软的开源代码,看看HP的代码,或者看看BATJ的代码。我呆过大公司,也呆过小公司,看过许多的代码,在我的印象中,小公司的代码比较好维护,更简单明了,今天我想来探究一下原因。

ps,不讨论小公司去买外包代码。


怎么样的代码好维护呢?

可读,模块化,功能明确,方便扩展,最好有文档。

程序员最不喜欢的4件事:

  • 给自己的代码写注释
  • 给自己的代码写文档
  • 别人的代码,没有注释
  • 别人的代码,没有文档
事实一

你指望有好文档?不论大公司小公司,关于文档这个事,只有两个结果
1.没有文档
2.文档不全

那些说自己有很全的文档的人,不服来辩?
最简单的来说,代码规范的问题天天有人提。那么有几个公司的代码规范明明白白写出来有文档的?
API接口总该有文档吧?你把接口文档拿来,我们来看看,有几个文档写清了http header里要哪几个内容的?有几个写了接口出错的时候返回什么内容,每种出错对应的情况的?有几个文档写了接口的最大调用量,及超量之后会发生啥的?有几个接口文档又写了,会有哪些调用方,都在什么情况下会被调用的?如果不幸被我说中了,我就可以说你文档不全啊。
在我看来,基本没有人能把所有事都写在文档里。不要什么事都怪文档,其实和它没关系。

事实二

  文档的问题说明了一个很重要的事实,关于业务需求,技术细节,开发实现的很多信息,会在传递的过程中丢失,我粗略估计超过30%的信息会丢。假设有两次交接工作,例如开发被调到别的项目去了,换了个人接手,或者产品经理辞职了,然后接手的人两次交接后基本对于项目所有的代码,资料和口头传授讲解,只接受了不到50%。
  我曾经在接受一个发红包代码的时候,测试说生产环境有收不到红包的问题。查了好久,发觉是一个数据库配置问题,发出的红包金额是一个随机数,要求红包均值是某个设置的值,同时要设定上限,下限。配置红包的时候,操作人员就把上下限配反了,导致代码里判断不正确退出了。

事实三

在丢了大量信息后,即使代码原先的质量很好,新人维护就会出很多的问题。我真的不知道程序员当时为什么这么写,先写一个if-else做特殊判断吧。别笑,这是微软的兄弟真的和我这么讲的,而且是真实案例,解决一个客户提出的最高等级的Bug。大牛写的代码不是每个人都能看懂的,可这么干真的能解决眼前的Bug,你认为我干不干?
我想想也有点心疼那下一个看代码的同学,你说他看到这个代码的时候会想啥?


事实四

实际情况中,需求又会压倒性的战胜代码可维护性。

  • 需求太急了,我知道代码写的有点乱,就先解决业务问题吧。
  • 以前的产品经理说过不会这样的?可是现在情况变了,需要这么干。那好吧,那就改吧。
  • 我前天说的需求改了没?改了。现在又有点变化,我们在那个基础上在变一下。好吧,那再加个特殊判断……



说了这么多,就一点,代码的可维护性真的很难保证。

小结

  • 让别人看懂代码,不容易
  • 告诉别人代码做什么的,不容易
  • 在不清楚完全的信息的情况下,做维护不容易
  • 现实情况变化太快,维护起来当然不容易。

分析

那么,一个芝麻点大的小公司,却能做的更好一些是为啥?

人少

交接少
代码风格容易统一
直接接触业务需求,对需求把握更准,减少需求的变更。觉得需求有问题,也可以直接交流,避免了沟通成本。

代码少

新系统,针对性强
不用考虑复杂的场景,往往是先跑原型,容易简化
不用考虑前期流量问题,先解决功能问题,再解决性能问题

大公司的研发能学到点啥不?

我们把大的系统分割成小的,每个部分的代码不就少了?
我们把服务变成微服务,针对性不就强了?
引入敏捷开发的方式,打破部门间的沟通壁垒,开发,测试,产品,需求方都协同工作,不就和小公司一样了?
如果交接经常丢信息,唯一不丢信息的方法是完整重来一遍,那么我们让接手代码的人,重构整个部分,他就有完全的知识和掌控力了。
重构不是这么简单的,所以一个建议是微服务化,单个微服务的重构,比整个系统重构风险小的多。微服务的一个评定标准就是在2周内,能把一个微服务代码整个重写。2周完成重构,多好?


打赏 支付宝打赏 微信打赏

如果文章对你有帮助,欢迎点击上方按钮打赏作者