《梦断代码》笔记三

    此次笔记主要在于对OSFA的Chandler 0.2这个版本的分析。版本发布必须有确定目标的，但是对于Chandler 0.2是毫无目标可言的

他仅仅是根据发布期限来做版本计划，虽然0.2版本没有让Chandler的工作偏离正轨，但是也造成了严重影响，给OSFA留下了一道伤痕。

卡普尔从0.2中吸取了一条教训——该死的布鲁克斯法则。

    《搞掂》书中有就一句话：“事情很少因为时间不够用而停滞，往往是因为没有确定怎么做而停滞，由于尹的加入，意味着OSFA终于有了

专职人员，负责就Chandler的用户界面提出问题并做出回答，以及定义这个界面。随着托伊的退出，卡普尔陷入困境。Chandler的步调缓慢

并非例外，其实如果想做大项目，追求根底还是做小项目。不要期望它变大，如果这么想，就会过度设计，而且你会因为他的庞大复杂而退缩。

这和上课时的课堂练习极度相似，先能实现最基本功能再说。对于时间复杂度等等的要求那是后续完善的。如果直接就达到所有要求，我想我

已经放弃了。四则运算的题目就是这样，先从简单入手。一步一步加上功能。

    搞掂设计方案，永远不要想着瞬间完成所有功能，这样只会让你停止不前。只会让你感到一座大山压在肩头。