读《多些时间能少写些代码》

看了一篇文章：《多些时间能少写些代码》。整合《黑客与画家》的内容，有必要做一次整理，这次无关语言，只和开发模式有关。

《黑》的基本观念：软件开发不应该正襟危坐，设计好所有图纸后才动手。应该立即动手，在不停的修修改改的思考过程中完成项目，或者做一个永远也完不成但一直可用的项目

《多》的观点：软件开发需要多写时间花来思考和设计，但设计不同于纸上谈兵，还要不断的尝试。设计完成的时候就是项目基础架构代码都完成的时候。

咋一看有矛盾，《黑》的学说强调一点，代码必须是尽快可用的，在一个可用版本中持续迭代到下一个可用版本。而《多》的观念并不强调必须可用，一个设计很好的基础代码架构可能同时也是一个没法编译的东西。但写的人清楚自己写的到底是什么。然后在设计完成的时候开始编写第一个可用版本。

《黑》的成果是能最快得到需求方的意见，尽早作出业务上的方向判断或产品设计判断，并且强调重构和语言的动态性，迭代次数更是无限多。《多》的成果是良好的设计在未来能减少（但不是消灭）重构、迭代次数。并且作者反对TDD（这一点我肯定认同）

《多》的这个结论与目前“业内”（只是项目经理老板们甚至客户的业内、不是真正干活儿的程序员的业内，讽刺吧）提倡的敏捷、TDD是反向而行的，这就是本篇的另一个重点：打破那些无所事事不喜欢写代码只喜欢构思开发流程的项目经理的连篇P话！我从来不相信敏捷、TDD这些东西适合大多数团队，它只适合少数专业素质过硬的团队。最终， 你组建敏捷流程化团队的代价和得到的回报是不高效的。至少在中国，有大量公司运用低能力值的员工通过简单粗暴的流程依然能够很好地完成项目获得市场价值。

现在可以写我的结论了，很明显，这只是个权衡问题，拿自己的经验去把握这条线即可。倾向于固定需求的合同式项目适合《多》的观念。倾向于自主创业项目肯定是适合《黑》的观念。