多些时间能少写些代码

     <p> 我在我的微博上说过<a href="/misc/goto?guid=4958195771551615258" target="_blank">这样一段话</a>，我想在这里把我的这个观点阐述地更完整一些。</p>    <blockquote>     <p><a href="/misc/goto?guid=4958185590815146876" target="_blank">@左耳朵耗子</a>：聪明的程序员使用50%-70%的时间用来思考，尝试和权衡各种设计和实现，而用30% – 50%的时间是在忙碌着编码，调试和测试。聪明的老板也会让团队这样做。而傻逼的老板，苦逼的程序员会拿出来100%-150%的时间来忙着赶进度，返工，重构，fix 大量的 bug… 所以， 越差的团队一般会越忙，而且还忙不完。</p>    </blockquote>    <p> 在现在这个浮躁的时期，再加上敏捷咨询师们念的歪经，他们让人感觉上就像是软件产品是可以在很短的时间内高质量的完成的，这令那些管理者们很兴奋，就像巴甫洛夫的条件反射实验中的狗看到了肉就像流口水那样兴奋。他们使用 TDD，快速迭代，不断重构，持续集成直至持续部署的方法在进行软件开发。</p>    <p> 软件开发真是这样的吗？难道不需要花时间去思考吗？对此，有些观点在 Todd 的《<a title="“品质在于构建过程”吗？" href="/misc/goto?guid=4958195772980338359" target="_blank">“品质在于构建过程”吗？</a>》以及《<a title="Bob 大叔和 Jim Coplien 对 TDD 的论战" href="/misc/goto?guid=4958193883440436868" target="_blank">Bob 大叔和 Jim Coplien 对 TDD 的论战</a>》中谈到过了。我只想想表达下面的观点：</p>    <ul>     <li><strong>软件的精髓在于设计，设计是一件很费大脑的事件</strong>。对于软件来说，设计没有完美的，它总是一件需要取舍需要权衡的事，比如：时间换空间，空间换时间，TCP 或 UDP，同步还是异步，数据冗余还不冗余等等。那怕是一个小小的 observers 模式是 pull 方式还是 push 方式都需要仔细讨论。这些的东西需要时间和做前期尝试。</li>    </ul>    <ul>     <li><strong>TDD</strong>、<strong>快速原型和迭代可能会对软件和团队产生负面影响</strong>。在一开始，你需要花很大的精力来让你的软件从无到有（做过软件的人都知道，从零开始写代码是很痛苦的事），但是因为你没有想好，先做再说，所以，后期你会面临更多的质量问题而让你需要花更多的时间精力。当然，那些咨询师会让你用持续集成和持续部署这样的方法。但我想告诉你，这并不解决你软件设计的缺陷。举个例子——TDD、迭代、原型只关注功能性需求，其不会关注非功能性需求，比如性能问题，高可用性问题，系统维护问题（模块的耦合问题），等等。而这些问题往往都可以让你的软件设计重新来过。</li>    </ul>    <ul>     <li><strong>重构是恶梦，重构应该越少越好</strong>。当你维护一个复杂的系统时你会知道重构是一件多么恐怖的事情（参看《<a title="重构代码的7个阶段" href="/misc/goto?guid=4958195774388656684" target="_blank">重构代码的7个阶段</a>》）。如果一开始没有想好，你要面临的不单单是 re-design, re-architect，还要面对时间和人力成本的增加，最难的是你还要面对的是团队士气因为不断的 rework 而逐渐低落并产生厌倦和懈怠情绪。</li>    </ul>    <p> 所以，如果你能有多一些时间去和客户讨论一下需求和未来可能的变化，去调查一下实现的技术难点和细节，去和其他有经验的人讨论并推敲一下架构和设计，去思考设计上的缺陷，那么，你的 coding 会变得非常地直，直到你一眼就看到尽头，你的测试案例也会写得非常地好，你会几乎不需要重构，于是，你会在未来少写很多代码，从而你的软件开发会越来越轻松，直到技术开始换代。</p>    <p> 我现在在做的项目，花了几乎4个月的时间来做设计，在这个过程中，我们反复思考、讨论和权衡若干种实现方法，并尽可能地穷举所有的场景和细节以及未来可能的变化（那怕是那些简单的模块），有个模块被重写了至少三次，每次都是写到一半就被推翻重写，我们整个团队不断地在和其它团队讨论，并在对系统不断地认识中对系统进行简化和优化，并力求达到完美。现在看来，没有贸然使用 Scrum 是明智的。</p>    <p> 这就好像我们修路造桥一样，我们需要花大量的时间勘测地形地质，分析数据，思考可能出现的各种问题（各种自然灾害），评估不同的设计方案，而不是先尽快建好再说。</p>    <p> 所以，<strong>多一些时间，不是让你多做几次迭代，多完成几个模块，而是可以让你少写一些代码，更快的交付一个更好的产品</strong>。</p>    <p> 我相信你会有很多疑问，下面是我觉得你可能会有下面的一些观点，让我一条一条来回复：</p>    <ul>     <li><strong>首当其冲的一定会是项目的 deadline，或是那种你没有活语权的项目。</strong>比如做那种“甲乙方合同式的项目”，我把这种项目统一认为是“外包项目”，在这种项目性质下，你很难有话语权。对此，我觉得，1）作为乙方的你还是应该和甲方在项目计划上争取一下，晓之以情，动之以理。2）如果不行，只能在时间、需求范围和质量上做一个权衡。另外，<strong>在这种情况下你要找一个方法，把你的压力和痛苦分担给用户和领导。</strong>（找到这个方法的前提需要你找到用户和领导他们害怕什么，嘿嘿）</li>    </ul>    <ul>     <li><strong>过度设计和纸上谈兵</strong>。有人说会不会设计太多，造成过度设计，或是在设计上花太多的时间。这有可能。我上一家公司的一个项目团队就花了1年多的时间来不停不停的开会和做设计，结果 release 的时候还有1000多个 bug。这个问题的原因是，这个团队的设计是在纸上谈兵，开会是开神仙会，讨论的设计都是浮云。所以，<strong>设计并不是讨论和思考，还需要去尝试，</strong>我认为当你的设计完成的时候，你的骨干核心代码都基本完成了。</li>    </ul>    <ul>     <li><strong>我的团队成员水平太差，不会思考</strong>。首先，先恭喜你找到一堆码农，当然，这不怪你，这是中国教育和大环境的问题，让人不会思考。对于这样的情况，我有两个建议，1）量力而行，使多大的碗就吃多少饭。2）鼓励思考，那怕那些想法很不靠谱，因为如果不开始，那么将永远不会思考。</li>    </ul>    <ul>     <li><strong>必需使用快速迭代</strong>。很多公司都在强行上敏捷，他们希望产品越快 release 越好，而没有充分的时间思考和讨论。对于这种项目，我的建议是，1）找有丰富经验的人来做。2）迭代过程中力求架构和程序逻辑的简单，简单，再简单，力求代码间的高内聚，低耦合。不然，重构的时候你就好玩了。</li>    </ul>    <ul>     <li><strong>创业团队必需要快</strong>。做得快就是做得好吗？很多时候，不是谁快谁就能笑到最后的。这样的例子太多了。第一个做出来的人并不一定就会占领市场，其很有可能会成为先驱。</li>    </ul>    <ul>     <li><strong>有钱的公司才会让团队用更多的时间去思考</strong>。错了，你们没有见过有钱的公司，有钱的公司可以招一堆干不成活的人，可以把事搞乱了再新来过，甚至可以把做失败的项目换个名字再重新立项。这些真正的有钱的公司只求快，只求人多，不怕做错决定。像我们这些没钱的人，干什么事都是小心翼翼地，生怕做错决定。</li>    </ul>    <p> 关于软件项目管理的文章，还可以参看《<a title="软件公司的两种管理方式" href="/misc/goto?guid=4958195775126519083">软件公司的两种管理方式</a>》，最后，欢迎大家表达观点。<br /> <br /> 来自: <a id="link_source2" href="/misc/goto?guid=4958195775862209908" target="_blank">coolshell.cn</a></p>