多些时间能少写些代码

 在现在这个浮躁的时期,再加上敏捷咨询师们念的歪经,他们让人感觉上就像是软件产品是可以在很短的时间内高质量的完成的,这令那些管理者们很兴奋,就像巴甫洛夫的条件反射实验中的狗看到了肉就像流口水那样兴奋。他们使用 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)迭代过程中力求架构和程序逻辑的简单,简单,再简单,力求代码间的高内聚,低耦合。不然,重构的时候你就好玩了。
  • 创业团队必需要快。做得快就是做得好吗?很多时候,不是谁快谁就能笑到最后的。这样的例子太多了。第一个做出来的人并不一定就会占领市场,其很有可能会成为先驱。
  • 有钱的公司才会让团队用更多的时间去思考。错了,你们没有见过有钱的公司,有钱的公司可以招一堆干不成活的人,可以把事搞乱了再新来过,甚至可以把做失败的项目换个名字再重新立项。这些真正的有钱的公司只求快,只求人多,不怕做错决定。像我们这些没钱的人,干什么事都是小心翼翼地,生怕做错决定。

原文发布于微信公众号 - Java学习网(javalearns)

原文发表时间:2016-12-08

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏喔家ArchiSelf

如何进入一个新领域

自己也没想到,项目进展的如此迅猛,事情来的措手不及,伙伴们还在加班鏖战。但是,承诺的,还是要做到。更何况,这是好友海峰提前半月就约定的,最终还是参加了4.21 ...

592
来自专栏镁客网

以虚拟现实骨灰级开发者视角,来看VR智能硬件平台

1584
来自专栏互联网高可用架构

技术人如何修炼内功(高级篇)

3165
来自专栏C语言及其他语言

靠编程赚钱的7个方法:普通程序员最难

来源:码农网 原标题《编程赚钱的7个方法》,IT之家编辑酌来源:码农网 几个星期前,当我收到一个自称Someone712的人发给我的一条消息时,我决定要...

5045
来自专栏大数据文摘

我们可以从Alexa语音助手的错误中学到什么:用户对话界面的设计性挑战

1312
来自专栏成猿之路

如果你是一个程序员,看完你会分享到朋友圈的...

但问题是,程序员往往意识不到自己的这种特异功能,在他们的眼里,会认为自己很普通,跟常人一样,所以,程序员能做到的事情,其他人——比如他们的客户/软件用户——也应...

962
来自专栏Java进阶架构师

阿里巴巴P9大佬雷卷与中间件小哥重新定义:高段位程序员的学习之道

随后就是这几年的事情了,云计算、大数据、AI的流行,使得程序员这个群体越来越庞大,对社会的贡献不仅仅局限在某个企业软件,或某个手机APP上,而是影响到人们吃穿住...

1703
来自专栏云计算D1net

亚马逊暂时赢得云之战 谷歌将成变革者

业界似乎非常容易地想到,公开的云大战已经告一段落,而且亚马逊已经在此大战中成为了赢家。市场研究机构Gartner在最近发布的Gartner Magic Quad...

3464
来自专栏java一日一条

对优秀程序员的思考

不管是谁,活着总是有方向和追求的,差别可能是有些人“高尚”一些,有些人“低俗”一些,有些人对自己的方向没有那么坚定、今天定了明天可能就变了。 无论是短期或长期、...

1771
来自专栏Java学习网

对优秀程序员的思考

对优秀程序员的思考 人生总有目标和追求 不管是谁,活着总是有方向和追求的,差别可能是有些人“高尚”一些,有些人“低俗”一些,有些人对自己的方向没有那么坚定、今天...

2974

扫码关注云+社区

领取腾讯云代金券