多些时间能少写些代码

多些时间能少写些代码

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

@左耳朵耗子:聪明的程序员使用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. 同意楼主的观点。通常越小的公司只会注重项目的成果,才不管你设计怎样,往往只是完成了就好。但到了重构阶段,苦的又是我们这些搞重构的。BUG不断,最后的结果必然就是重构,而重构,必然也是对自己工作的推翻,这样没几个人会有什么成就感的。
    但也许这个观点的前提需要是这个小公司的老总不是搞技术出身的。如果公司的老总是搞技术出身的,那么他多少会理解一些技术人员的难处,会考虑多一些技术人员甚至开发人员的工作。
    国内的很多公司之所以成一了大公司,就是因为别人说什么他就做什么,什么敏捷,估计老总不知道是啥,但就是要你做。中国的大环境,也就意思着码农远远多于“攻城师”。

  2. 多花些时间在设计上面,能减少写代码的时间。
    确实是这样的。设计清晰了,写代码的时候就直接前进。
    先把代码给写起来,然后再返工,这个太痛苦了。真的是会造成士气低落、倦怠和懈怠情绪。
    上次我们团队讨论的时候,我坚决认为设计应该花多些时间,而不是测试。

  3. ?欢乐的老评论:KX99Ex:反正能运行就行了么。写着方便是第一要点,让运行效率都去死,反正运行程序不用我的CPU……呵呵!

  4. 非常赞同,其实不光是设计、技术,其实做什么都要多思考,多思考的人总会比别人得到更多。

  5. 我的作法,是先选择关键技术。然后会写一个简单的demo,来验证在核心部分上的实现难点。
    然后再进行代码架构的设计。
    最后再进行编码。

    这三个阶段有时候会相互夹杂,分不太开。

  6. 很不错啊,我看了博主很多文章,但是我还是很想看下博主对跳槽的看法及建议,下次写个文章吧!

  7. 设计->编码->测试,这个流程是前辈给我们留下的好东西。直接“编码->测试”,会很容易进入这个循环“编码->测试->编码->测试”,浪费金钱和时间。通常项目进度紧是程序员采用这种模式的借口,因为这种方式可以让大脑偷懒。但换来的却是加班再加班,虽然带来了加班费,但毁掉的是身体和思考能力。

  8. 就是这样的 虽说我没有写过代码 但玩游戏的时候就是这样的 三分之一的时间自己玩 三分之二的时候看别人的教程 自己尝试 想 很多次梦中把游戏反复演练 技术提升基本都是在梦中

  9. 楼主, 你的题目写错了吧, 应该是“多些时间思考,能少写些代码” 而不是“多些时间能少写些代码”。

  10. 原来你是在创业,很期待你已经设计了4个月的产品。到底是啥玩意?不过我有一句疑问:你怎么避免闭门造车这种情况呢?也许你之前4个月中否决的某个想法正好是大众认为很酷的一个东西呢?再说下去,就要说市场调查的事情了。哈哈

  11. 不过,应用系统,没有跑起来之前,
    开发者很难想完整、想清楚整个系统的过程及会出现的问题
    用户本身就更加不会想了
    没有原型,开发者再多的思考、设计也是空想、闭门造车
    有了原型,用户才能真正介入,然后就是需要快速开发了:用户指着屏幕说的问题,开发者要能及时改掉,并把正确的立即运行出来,以便得到用户的确认或纠错。。。。。。。。

  12. lz说得是。。。注重思考很重要。。。我就觉得我写得代码很混乱。。以后会多注意。。

  13. 写成这样也有人赞同.
    做什么事情都有个折中, 不能只从一个方面看问题. 写个hello world思考一个星期行不行?
    思考只是做项目中的一个方面而已, 不要可以放大它的重要性. 它是必要条件这一点也不假, 但是必要条件可不止它一个. 实际动手去做也是非常重要的, 个人认为稍加思考就做好过光思考不做.

  14. 学而不思则惘,思而不学则殆。 整天开口闭口模式,方法论的人很多。这算不算思,当事人肯定是这么认为的。大量的行动必然会产生大量问题。对大多数人来说,面对这些问题自然会有所思考,这些从实践出发的思考,比干巴巴的纸上谈兵要深刻的多。 所以个人认为行动更重要。 BTW, 我不是敏捷的fans, 只是觉得执拗的反敏捷和一味的敏捷一样有害.

  15. sorry, 大多数人对你只可能有肤浅的认识,一如你对大多数人也只可能有肤浅的认识

    1. 我从未对大多数人有肤浅的认识,我相信大多数人,我批评的只是那些教条主义的没有项目经验的咨询师。

  16. 谢谢,希望大家都友好的交流, 不要动不动给别人扣帽子。 码农什么的都是谁想出来的?如果有人乐意做一个快乐的码农,这不是一件很好的事情吗? 为什么有人会有意见。 我有一个同事, 以前做过waiter, 卡车司机,后来做硬件,软件。现在买了农场。打算做farmer了。开心就好,为什么有那么多偏见和藐视。 

    1. @adhoc 你说对了,不要动不动就给人扣帽子。另,关于码农的问题,我个人理解的是“编码农民工”,也就是被形容为,编码是干体力活而不是脑力活,所以,如果你要自己选择做码农我没有意见,自己对自己的人生负责就好。我只是在这里告诉大家——软件开发是脑力活。不是偏见和藐视。

      当年鲁迅骂中国人的时候,你会觉得那是对中国人的偏见和藐视吗?我当然不是鲁迅。我只是想告诉你,你可以从这个角度去思考这些事。(不要只看表面,你要看其观点和目的是什么?)

  17. 我非常同意第一个观点。 但对于后面两点则保留意见。 程序员最无奈的事就是被动接受变化,所以极限编程会说拥抱变化。TDD,重构都是我们用于拥抱变化的工具。

    2) TDD、快速原型和迭代可能会对软件和团队产生负面影响
    博主的这个观点用上了无敌的“可能”,啥事都是过犹不及,我只能说它是对的。我来评下论据:
    a)性能这个例子举得不对,性能是一个隐含的需求,某个操作如果最优化的实现只需10ms,但快速的实现要1s,用户多半无所谓。但如果是1s和100s的区别,那就不一样了。
    b)高可用性问题,系统维护问题(模块的耦合问题)。我的结论是易于测试的代码,其耦合会更小。 例子我不想花时间举了。

    3) 重构是恶梦,重构应该越少越好
    这是我反对的,判断是否重构,是看其能否带来价值。 博主的这个观点有点偏颇。我在(《重构代码的7个阶段》)也有回复。 引用在此:

    “如果重构能带来价值,那就是再难也要重构。对于维护性质的项目,显然不会加什么翻天覆地的新功能了,无非就是改几个BUG,加几个小功能,你重构干嘛?
    重构最好从自己的代码做起,别人的代码除非是你理解透了,否则别动。勿以善小而不为之,看到某个变量名没有揭示其含义,就rename;看到某段代码可以提取出来,就extract method。
    不是说没有UT,就不能重构,只是没那么方便和自由。”

    看了博主的几篇博文,我第一反应是我得重读下“设计已死”,也许博主想反对的是那种 code and fix 的方式。

    总结一下: 只想不做,埋头苦做,都没出路。

  18. 过度设计和纸上谈兵。有人说会不会设计太多,造成过度设计,或是在设计上花太多的时间。这有可能。我上一家公司的一个项目团队就花了1年多的时间来不停不停的开会和做设计,结果release的时候还有1000多个bug。这个问题的原因是,这个团队的设计是在纸上谈兵,开会是开神仙会,讨论的设计都是浮云。所以,设计并不是讨论和思考,还需要去尝试,我认为当你的设计完成的时候,你的骨干核心代码都基本完成了。

    太赞了, 设计一定要由比开发更有经验的人来做主要设计,否则开发可以完全抵制了

  19. 我认同文章里的不少观点,像是”聪明的程序员使用50%-70%的时间用来思考,尝试和权衡各种设计和实现,而用30% – 50%的时间是在忙碌着编码,调试和测试。“很多时候看你活做得好不好不是看你花了多少时间Coding,或是Code有多少行。要做到Clean Code或Beautiful Code里提到的那种程度必须编码前的思考和规划。

    不过对于文章里很多观点我个人觉得都有值得推敲的地方。首先我感觉作者对Agile有些误解。下面把我的观点一一道来。

    1. “软件开发真是这样的吗?难道不需要花时间去思考吗?”

    Agile里定义的开发应该不止是Coding吧?研究,计划,设计都是开发活动。用Agile不是说把所有开发活动都变为Coding了。

    2. “TDD、快速原型和迭代可能会对软件和团队产生负面影响。一开始,你需要花很大的精力来让你的软件从无到有(做过软件的人都知道,从零开始写代码是很痛苦的事),但是因为你没有想好,先做再说,所以,后期你会面临更多的质量问题而让你需要花更多的时间精力。。。TDD、迭代、原型只关注功能性需求,其不会关注非功能性需求,比如性能问题,高可用性问题,系统维护问题(模块的耦合问题),等等。而这些问题往往都可以让你的软件设计重新来过。”

    同理,如果你把研究计划设计定义都算为Agile里的开发,这个论点的依据就不成立了。此外还有一个我觉得普遍的观点就是传统开发由于计划周全,所以后期出现的意外质量问题少。其实很多问题早期设想根本不可能看到,只有实际deploy后才会发现。而如果从0到开始部署周期太长的话问题会出现的很晚,解决起来更痛苦。

    3. “重构是恶梦,重构应该越少越好。”

    我个人反而喜欢重构。比如以前写了10个method现在重新设计为3个,或者基本没什么变化但是变量,缩进设计和method安排使得代码可读性更高了,其实都是增加了价值。我觉得代码就要经常重构,大的或者小的。这样才能改进产品和个人能力。当然一般的老板意识不到重构也是做产品。本人是Clean Code和Beatiful Code这两本书的忠实执行者。

    所以可能对重构的抵触也是和Agile不兼容的原因之一?但是很多传统的开发方式不是避免了重构,而是把重构的成本变的很高所以公司会选择能拖则拖,最后technical debt越滚越大。

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

    我们公司用的是scrum。在写新系统的时候,大部分任务都是investigate,或是benchmark不同的solution,或是按照想法做demo。可见我们花在计划上的时间也不少。所以这个和你用不用敏捷是无关的,而是思考和计划在公司里的位置。
    ————
    最后声明一下,我对Agile的知识都是在公司里工作学来的,没怎么看过理论。而公司里用的是Scrum。我个人对开发方法没什么喜好,什么管用用什么。但是我们公司开发情况比2年前用Waterfall时好太多了。

  20. Pingback: Systems Thoughts
  21. 所谓的敏捷方法和你所说的那些本质上根本不矛盾也不互斥,甚至有些暗合。把思想抽象成方法来用才能可复制、可控制。为什么敏捷就是傻瓜式的迭代?不要拿李鬼说事。不过也没什么争的,我早说够了,这些只是皓哥拿来区分大师和白痴的YY文而已。

    1. 我就奇怪了,1)我又没有骂你,2)我和你个人也没有利益上的冲突。为什么你会脸红,你会激动,还要骂我呢?

  22. 皓哥,我再回最后一次。你以后再写关于敏捷的我屁也不放一个了。 敏捷方法一定是有适用性的,没有人蠢到什么项目都用敏捷方法(好,可能有吧)。它就像个微波炉。没有人指望它做出一流的菜,只有熟了可以吃就ok了。你是一位特级厨师,如小当家,没错。但是老是说微波炉不能煮一流的菜,有半毛钱意思吗?
    另外另外另外,不要老说什么设计设计设计,搞得好像是艺术家不是码农了,大哥。不是所有产品都靠艺术的大哥。
    最后,设计很重要,但是 敏捷什么的不等于 不设计。。。 把抽象的思想具体化是很困难的,这是别人的劳动成果,要感谢,要学习。

  23. @陈皓
    皓哥你又在搞笑了,我没有脸红也没有骂你。提出你观点中搞笑的地方,就是骂你吗? 其实完不知道“敏捷”是什么内容的人,光从“敏捷”这2个字上就能用屁股思考出来他不是用来实现你所谓的好的设计的。它是干别的的。而且做好的设计和用敏捷根本不矛盾。所以你用牛人不用敏捷做好的设计来 PK 搓人用敏捷不做设计 得出敏捷方法是shit的结论是非常搞笑的。你要知道一个烂人如果什么方法都没有地去做设计那么结果可能更恐怖。这个叫不可控,不可控就是风险。方法就是为了尽量可控,减低风险。当然方法本身也是需要不断改进的。
    还有你说有钱的公司才会请不干活的人,这个观点也实在搞笑。当然你贬低一些东西不都只是为了贬低而已,最终都是想褒扬另一些东西罢了,考虑到可能是作为技术人员特有的那种“优越感”和YY情节,我也就不想再说什么了。

  24. 先感谢一下博主能够坚持更新博客,为我们这些读者带来这么好的食粮,因为这些东西不是在哪本书中可以读到的。
    关注您的博客也有一段时间了,我本身也是一名程序员,入行的时间不长。而且也在思考,怎么样可以吃好这碗饭。
    我知道,大家在谈论这个职业的时候,很多的时候都在探讨技术,从这个职业所需要的专业知识出发来研究他,我认为这是一种方式,但是仅仅从专业知识的角度来考虑是远远不够的。
    文中提到的多一些时间少一些代码,告诉我们如果在前期软件设计上面多花一些时间,我们写代码或者改代码的时间都会大大减少。但是在进入软件设计之前,还有一层。就是产品设计。
    我知道产品设计不是开发人员或者架构师的职责,但是如果产品经理,或者更高Level的人,能够有很广的知识面,很准确的定位产品的功能,而不是朝三暮四,这样开发人员才能真正少一些代码,而且不至于做很多力气活。
    也许博主只是想从软件进入设计,开发阶段谈论这个问题,并没有打算从设计层面谈起-:)

  25. 敏捷论本就有其特定的范围,不是适合于任何程序的。 比如图形设计。 个人感觉空想真的很累。

  26. 我本人的开发过程是和作者很相似的,就是会更加关注于设计,设计先行,想清楚了再做,如果有几种不同的设计方案需要权衡,我会快速做一些原型,帮助自己进行设计的抉择,我也建议我团队的同事更加关注设计,而不要一头就扎进功能里palapala的就实现了功能,出来混总是要还的。不过,团队的成员的水平良莠不齐,事实上,大多数成员的经验都不超过三年,对于这种情况,一方面我还是鼓励他们多思考,多在设计上下功夫,另一方面,我也鼓励他们快速地验证他们的设计,把设计做简单,用简单做为衡量前期设计的首要标准,跟头是一定会栽的,不吃一堑也不会长一智,这个时候重构可不就有用了吗,我个人也很喜欢重构,争取时间重构,糟糕的代码一定会在将来让我吃苦头的。简单的设计让重构更简单,我想表达的就是我们不仅需要重构,还需要把重构尽量提前,让重构来辅助你的设计。敏捷从来没有反对过设计,它只是反对设计过度。我没有使用过TDD,老实说针对我所在的业务领域,我所看到的做TDD的同事效果都不是很好(可能他们水平不够),但是我们团队里是有引入一些敏捷开发方法的,比如站立式会议,比如迭代开发,持续集成等等,这些应该很多公司都采用,效果还不错,因此对于敏捷,我喜欢它的一些思想,但也从不认为它是包治百病的良药,敏捷对我而言,这些基本就够了。写得有点乱,见谅。

  27. mic,LZ其实没必要再“热烈讨论”了,再“热烈”下去你们未免有点像某行业那样炒作了,呵呵!敏捷,TDD都是总结出来的理论与方法的一个代名词而已,它们其中很多的理解与见解在这个代名词出现之前就有,至于叫什么更多时候不都是哪个人在业界首先提出而慢慢形成的吗?TDD很好,敏捷很好,传统的方法都很好,但无论从技术角度还是实际项目的角度都是没有最好的,而只有相对适合的。相信LZ和mic都很清楚这点,呵呵!!

  28. @hugh 我觉得你说的才是核心,其实设计和开发分不开。没有设计,开发出来的是一团浆糊,没有开发,设计出来的只是浮云。

  29. emily :
    我本人的开发过程是和作者很相似的,就是会更加关注于设计,设计先行,想清楚了再做,如果有几种不同的设计方案需要权衡,我会快速做一些原型,帮助自己进行设计的抉择,我也建议我团队的同事更加关注设计,而不要一头就扎进功能里palapala的就实现了功能,出来混总是要还的。不过,团队的成员的水平良莠不齐,事实上,大多数成员的经验都不超过三年,对于这种情况,一方面我还是鼓励他们多思考,多在设计上下功夫,另一方面,我也鼓励他们快速地验证他们的设计,把设计做简单,用简单做为衡量前期设计的首要标准,跟头是一定会栽的,不吃一堑也不会长一智,这个时候重构可不就有用了吗,我个人也很喜欢重构,争取时间重构,糟糕的代码一定会在将来让我吃苦头的。简单的设计让重构更简单,我想表达的就是我们不仅需要重构,还需要把重构尽量提前,让重构来辅助你的设计。敏捷从来没有反对过设计,它只是反对设计过度。我没有使用过TDD,老实说针对我所在的业务领域,我所看到的做TDD的同事效果都不是很好(可能他们水平不够),但是我们团队里是有引入一些敏捷开发方法的,比如站立式会议,比如迭代开发,持续集成等等,这些应该很多公司都采用,效果还不错,因此对于敏捷,我喜欢它的一些思想,但也从不认为它是包治百病的良药,敏捷对我而言,这些基本就够了。写得有点乱,见谅。

    你说的也很好,我们只要取其精华,把切合实际的东西拿过来就好了,不是说道敏捷,就是要一顿抨击。我们在做scrum时,总是有人说scrum的核心是experiencal developer,我觉得,你如果非要追求理论,我只能说我不是scrum。我们不用在名词上较真,分享经验,讨论我们的思考才是重要的。我写的更乱,见谅了啊。

  30. > 做过软件的人都知道,从零开始写代码是很痛苦的事

    真是这样么?我感觉你这个结论很有问题。

    我所接触的大多数人,绝对宁可自己写代码也不愿意维护别人的代码。

    有的模块,每换个人就被重写一遍,因为多数人宁可全部自己重写,也不愿意维护前人的代码。

    对我个人来说,也赞同说,从零开始写代码,绝对是一件比维护别人代码幸福得多的事情。

  31. 我是同意作者的观点的。
    相信作者也明白一个道理:存在者有其合理性——所以,类似MJ在相当一部分范围内大行其道只能说明——在中国有非常多的“码农”他们并不是程序员,只是混口饭吃而已。追求不同,意义不同,所以价值观不同。
    进一步只能说明:我们国家还是个相对落后的国家。
    其实哪行哪业都是这样,这只是一个缩影而已。
    我们最终总是在研究2个问题:“存在”和“为什么存在”

发表回复

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