多些时间能少写些代码

多些时间能少写些代码

我在我的微博上说过这样一段话,我想在这里把我的这个观点阐述地更完整一些。

@左耳朵耗子:聪明的程序员使用50%-70%的时间用来思考,尝试和权衡各种设计和实现,而用30% – 50%的时间是在忙碌着编码,调试和测试。聪明的老板也会让团队这样做。而傻逼的老板,苦逼的程序员会拿出来100%-150%的时间来忙着赶进度,返工,重构,fix 大量的bug… 所以, 越差的团队一般会越忙,而且还忙不完。

在现在这个浮躁的时期,再加上敏捷咨询师们念的歪经,他们让人感觉上就像是软件产品是可以在很短的时间内高质量的完成的,这令那些管理者们很兴奋,就像巴甫洛夫的条件反射实验中的狗看到了肉就会流口水那样兴奋。他们使用TDD,快速迭代,不断重构,持续集成直至持续部署的方法在进行软件开发。

软件开发真是这样的吗?难道不需要花时间去思考吗?对此,有些观点在Todd的《“品质在于构建过程”吗?》以及《Bob大叔和Jim Coplien对TDD的论战》中谈到过了。我只想想表达下面的观点:

  • 软件的精髓在于设计,设计是一件很费大脑的事件。对于软件来说,设计没有完美的,它总是一件需要取舍需要权衡的事,比如:时间换空间,空间换时间,TCP或UDP,同步还是异步,数据冗余还不冗余等等。那怕是一个小小的observers模式是pull方式还是push方式 都需要仔细讨论。这些的东西需要时间和做前期尝试。
  • TDD快速原型和迭代可能会对软件和团队产生负面影响。在一开始,你需要花很大的精力来让你的软件从无到有(做过软件的人都知道,从零开始写代码是很痛苦的事),但是因为你没有想好,先做再说,所以,后期你会面临更多的质量问题而让你需要花更多的时间精力。当然,那些咨询师会让你用持续集成和持续部署这样的方法。但我想告诉你,这并不解决你软件设计的缺陷。举个例子——TDD、迭代、原型只关注功能性需求,其不会关注非功能性需求,比如性能问题,高可用性问题,系统维护问题(模块的耦合问题),等等。而这些问题往往都可以让你的软件设计重新来过。
  • 重构是恶梦,重构应该越少越好。当你维护一个复杂的系统时你会知道重构是一件多么恐怖的事情(参看《重构代码的7个阶段》)。如果一开始没有想好,你要面临的不单单是re-design, re-architect,还要面对时间和人力成本的增加,最难的是你还要面对的是团队士气因为不断的rework而逐渐低落并产生厌倦和懈怠情绪。

所以,如果你能有多一些时间去和客户讨论一下需求和未来可能的变化,去调查一下实现的技术难点和细节,去和其他有经验的人讨论并推敲一下架构和设计,去思考设计上的缺陷,那么,你的coding会变得非常地直,直到你一眼就看到尽头,你的测试案例也会写得非常地好,你会几乎不需要重构,于是,你会在未来少写很多代码,从而你的软件开发会越来越轻松,直到技术开始换代。

我现在在做的项目,花了几乎4个月的时间来做设计,在这个过程中,我们反复思考、讨论和权衡若干种实现方法,并尽可能地穷举所有的场景和细节以及未来可能的变化(那怕是那些简单的模块),有个模块被重写了至少三次,每次都是写到一半就被推翻重写,我们整个团队不断地在和其它团队讨论,并在对系统不断地认识中对系统进行简化和优化,并力求达到完美。现在看来,没有贸然使用Scrum是明智的。

这就好像我们修路造桥一样,我们需要花大量的时间勘测地形地质,分析数据,思考可能出现的各种问题(各种自然灾害),评估不同的设计方案,而不是先尽快建好再说。

所以,多一些时间,不是让你多做几次迭代,多完成几个模块,而是可以让你少写一些代码,更快的交付一个更好的产品

我相信你会有很多疑问,下面是我觉得你可能会有下面的一些观点,让我一条一条来回复:

  • 首当其冲的一定会是项目的deadline,或是那种你没有活语权的项目。比如做那种“甲乙方合同式的项目”,我把这种项目统一认为是“外包项目”,在这种项目性质下,你很难有话语权。对此,我觉得,1)作为乙方的你还是应该和甲方在项目计划上争取一下,晓之以情,动之以理。2)如果不行,只能在时间、需求范围和质量上做一个权衡。另外,在这种情况下你要找一个方法,把你的压力和痛苦分担给用户和领导。(找到这个方法的前提需要你找到用户和领导他们害怕什么,嘿嘿)
  • 过度设计和纸上谈兵。有人说会不会设计太多,造成过度设计,或是在设计上花太多的时间。这有可能。我上一家公司的一个项目团队就花了1年多的时间来不停不停的开会和做设计,结果release的时候还有1000多个bug。这个问题的原因是,这个团队的设计是在纸上谈兵,开会是开神仙会,讨论的设计都是浮云。所以,设计并不是讨论和思考,还需要去尝试,我认为当你的设计完成的时候,你的骨干核心代码都基本完成了。
  • 我的团队成员水平太差,不会思考。首先,先恭喜你找到一堆码农,当然,这不怪你,这是中国教育和大环境的问题,让人不会思考。对于这样的情况,我有两个建议,1)量力而行,使多大的碗就吃多少饭。2)鼓励思考,那怕那些想法很不靠谱,因为如果不开始,那么将永远不会思考。
  • 必需使用快速迭代。很多公司都在强行上敏捷,他们希望产品越快release越好,而没有充分的时间思考和讨论。对于这种项目,我的建议是,1)找有丰富经验的人来做。2)迭代过程中力求架构和程序逻辑的简单,简单,再简单,力求代码间的高内聚,低耦合。不然,重构的时候你就好玩了。
  • 创业团队必需要快。做得快就是做得好吗?很多时候,不是谁快谁就能笑到最后的。这样的例子太多了。第一个做出来的人并不一定就会占领市场,其很有可能会成为先驱。
  • 有钱的公司才会让团队用更多的时间去思考。错了,你们没有见过有钱的公司,有钱的公司可以招一堆干不成活的人,可以把事搞乱了再新来过,甚至可以把做失败的项目换个名字再重新立项。这些真正的有钱的公司只求快,只求人多,不怕做错决定。像我们这些没钱的人,干什么事都是小心翼翼地,生怕做错决定。

关于软件项目管理的文章,还可以参看《软件公司的两种管理方式》,最后,欢迎大家表达观点。

(全文完)


关注CoolShell微信公众账号和微信小程序

(转载本站文章请注明作者和出处 酷 壳 – CoolShell ,请勿用于任何商业用途)

——=== 访问 酷壳404页面 寻找遗失儿童。 ===——
好烂啊有点差凑合看看还不错很精彩 (28 人打了分,平均分: 3.82 )
Loading...

多些时间能少写些代码》的相关评论

  1. 只站在技术的角度 思考问题。

    文章很多时候是一种 YY ,很情绪化。事情不是只有黑和白 两种极端,很多时候都是 中庸。

    为了自己的观点,将一些理论,思想 扭曲化,来证明自己的观点?

    ———————————-
    在我身边发生过 的真实案例:

    换个角度:产品或者是boss。

    有很多竞争对手在做这个产品,这个时候比的是时间(相同质量的产品,比如:功能一样)。

    这个时候 如果 研发 人员 说:我要思考以后重构的事情。

    然后boss说:你就告诉我 能不能做?技术上有没有问题?什么时候能做完?就可以了。
    ————————————————————–

    最后,我是做研发的,研发应该有研发的严谨和谦虚。

    我同意你的观点:多思考问题,多从很多角度思考问题。

  2. 我觉得本来就应该这么干!

    试问,挖一个坑可能不需要设计(大概知道多深,多宽,多长),但做一个房子你敢先不画图纸,直接开始施工吗?

    你敢施工的过程动动地基吗?或者吧承重墙给毁了重做吗?

    如果一个房子出现问题,说明在图纸上就已经可能有问题了(不排除coder的问题)。

    一个软件应该是类似的。

  3. 顶 非常赞同
    “聪明的程序员使用50%-70%的时间用来思考,尝试和权衡各种设计和实现,而用30% – 50%的时间是在忙碌着编码,调试和测试。聪明的老板也会让团队这样做。而傻逼的老板,苦逼的程序员会拿出来100%-150%的时间来忙着赶进度,返工,重构,fix 大量的bug… 所以, 越差的团队一般会越忙,而且还忙不完。”

  4. 是的,思考是软件开发中必须的重要环节,而且好的设计的确需要很多的思考。对于重构,应当作获取高质量软件的一种辅助手段,而不是主要手段。重构是不可避免的,因为软件存在生命周期的问题(形成、成长、成熟和衰退),我们也很难在设计之初将未来的所有细节都考虑清楚。

  5. 前辈,客户有时候并不知道他们真正要的是什么,如果客户常改变需求呢?(这貌似会发生吧)

  6. @watermelon
    说明是客户不知道自己的需求是什么,所以应该是在确定需求这件事上下功夫,而不是被动的接受客户的需求。

  7. 我们team本来就是搞平台项目了,上了敏捷之后,反而在最根本的质量上出现了问题
    虽然我们也在引进持续集成等工具,但是平台项目本身的复杂性就决定了这些工具的局限性
    唉,希望上层能早日看到这些问题

  8. 流程其实蛮“屠杀”热情的,但百人项目,没有流程不可能,没有代码审核不可能,怎么平衡?

  9. 我再次看这篇文章的时候,才保持100%的赞同。工作快两年才系统的做好一个很小很小的项目,做完大概花了两周的时间。第一周第一个版本出来了,其中我花了3天的时候缠着各种人把需求理清楚,然后花两天把代码写完并内测成功。后面一周又是测试人员提各种需求,但是有了前一次良好的沟通,需求的明晰,后面提的小需求也改的特别快。 后面我才发现,原来把需求理清是多么重要的事情,现在如果在碰到独自开发一个项目的,我都会花绝大部分的时间来把需求理清楚,把主要代码给理顺。这里确实得感谢耗子哥,让我坚持这种开发软件的方式。

  10. 苦逼的程序员会拿出来100%-150%的时间来忙着赶进度,返工,重构,fix 大量的bug
    ——当时在华为,每天就是解决bug!

  11. Pingback: 码农城
  12. 很有道理,上来就写代码,出了问题然后就改,后来改得自己都不认识了……..

  13. “我现在在做的项目,花了几乎4个月的时间来做设计”,你好,我一直很关注编码之前的设计阶段。所以很想知道其他人实际流程中的从0设计是个什么样的过程?先使用UML画个图,然后再做?还是先做好一个框架代码?使用了哪些工具。

    我自己写模块或者框架时,特别是一个之前没有写过的较复杂点的模块,只能做到“先设计一半,先艰难的把基础功能贯通,然后再重构”。如果当时精神状态好,脑内存够大还好,遇到再大一点复杂一点的模块,就真的很艰难了。
    设计方面我只知道UML、也有自己手画类图或者其他能想到的各种图。只能画个基础的类图和关系,没法想要的流畅清晰。

    我一直希望找到,照着流程图清晰的逻辑的编码的感觉,那种设计100%,照着图纸翻译成代码的感觉。

发表回复

您的电子邮箱地址不会被公开。