《梦断代码》笔记三

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

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

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

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

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

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

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

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

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

原文地址:https://www.cnblogs.com/wang321/p/4392909.html