我认同这篇文章里的不少观点，像是”聪明的程序员使用50%-70%的时间用来思考，尝试和权衡各种设计和实现，而用30% – 50%的时间是在忙碌着编码，调试和测试。“很多时候看你活做得好不好不是看你花了多少时间Coding，或是Code有多少行。要做到Clean Code或Beautiful Code里提到的那种程度必须编码前的思考和规划。
不过对于文章里很多观点我个人觉得都有值得推敲的地方。首先我感觉作者对Agile有些误解。下面把我的观点一一道来。
软件开发真是这样的吗？难道不需要花时间去思考吗？
Agile里定义的开发应该不止是Coding吧？研究，计划，设计都是开发活动。用Agile不是说把所有开发活动都变为Coding了。
TDD、快速原型和迭代可能会对软件和团队产生负面影响。一开始，你需要花很大的精力来让你的软件从无到有（做过软件的人都知道，从零开始写代码是很痛苦的事），但是因为你没有想好，先做再说，所以，后期你会面临更多的质量问题而让你需要花更多的时间精力。。。TDD、迭代、原型只关注功能性需求，其不会关注非功能性需求，比如性能问题，高可用性问题，系统维护问题（模块的耦合问题），等等。而这些问题往往都可以让你的软件设计重新来过。
同理，如果你把研究计划设计定义都算为Agile里的开发，这个论点的依据就不成立了。此外还有一个我觉得普遍的观点就是传统开发由于计划周全，所以后期出现的意外质量问题少。其实很多问题早期设想根本不可能看到，只有实际deploy后才会发现。而如果从0到开始部署周期太长的话问题会出现的很晚，解决起来更痛苦。
重构是恶梦，重构应该越少越好。
我个人反而喜欢重构。比如以前写了10个method现在重新设计为3个，或者基本没什么变化但是变量，缩进设计和method安排使得代码可读性更高了，其实都是增加了价值。我觉得代码就要经常重构，大的或者小的。这样才能改进产品和个人能力。当然一般的老板意识不到重构也是做产品。本人是Clean Code和Beatiful Code这两本书的忠实执行者。
所以可能对重构的抵触也是和Agile不兼容的原因之一？但是很多传统的开发方式不是避免了重构，而是把重构的成本变的很高所以公司会选择能拖则拖，最后technical debt越滚越大。
我现在在做的项目，花了几乎4个月的时间来做设计，在这个过程中，我们反复思考、讨论和权衡若干种实现方法，并尽可能地穷举所有的场景和细节以及未来可能的变化（那怕是那些简单的模块），有个模块被重写了至少三次，每次都是写到一半就被推翻重写，我们整个团队不断地在和其它团队讨论，并在对系统不断地认识中对系统进行简化和优化，并力求达到完美。现在看来，没有贸然使用Scrum是明智的。
我们公司用的是scrum。在写新系统的时候，大部分任务都是investigate，或是benchmark不同的solution，或是按照想法做demo。可见我们花在计划上的时间也不少。所以这个和你用不用敏捷是无关的，而是思考和计划在公司里的位置。
最后声明一下，我对Agile的知识都是在公司里工作学来的，没怎么看过理论。而公司里用的是Scrum。我个人对开发方法没什么喜好，什么管用用什么。但是我们公司开发情况比2年前用Waterfall时好太多了。
No related posts.
谢谢你对本文的关注。我也想和你讨论一下。
其一、Agile当然不只是coding。我当然也不是说只有在coding的时候思考。用Agile是不是需要思考软件的设计。这点我想说的是，1）Agile的TDD倡导的是对需求功能性的Test Case开始，这会分散对非功能性需求的注意力，我觉得设计软件得把功能性需求和非功能性需要放在一起同时考虑。2）Agile倡导的迭代周期是2-4周，这个时间实在是太短了，尤其对一个相对复杂的系统。所以，Agile的这些倡导会把团队推向一个误区，就是先实现再说，这可能是灾难性。
其二、请注意我在文中所说的，多一些时间，是用来思考更多的情况，思考实现的细节，多和别人沟通，多和高手交流，而我强调的一点是，设计的时候一定要去尝试，而不是纸上谈兵。所以，你说的“其实很多问题早期设想根本不可能看到，只有实际deploy后才会发现”，1）如果你觉得*很多问题*在早期不可能看到，那你真的需要反思和改善了。早期不能看到的东西应该是少数的、隐藏得深的问题才是正常的。多一些时间尽可能多的比较一下不同的方案，多一些时间把问题扎得深所得广，你会发现其实很多问题早期都应该能预见到的。 2）如果通过Deploy才能发现问题，我觉得这是不是有点太重量级了，为了发现问题，我需要release一个版本，做一个原型。我觉得没有必要，有很多事（尤其是功能性需求的东西），不用实现我们也能知道会是什么样的结果，不是吗？对于看不清的东西，更多的应该是非功能性的东西（比如性能，算法等），作几个实验也能知道会有什么样的问题啊，无需做一个release出来deploy。
你也许会说，复杂的东西的确在初期看不清。关于这点，我想说，复杂的东西才是要在一开始小心，不要仓促决定，不然到后期很可能就不是重构，就是费了重写了。我这十多年来经历过很多个这种重构不成，重写也不成的项目，最后就是将就了，程序乱成一团，再也没有办法重构。
其三、关于重构。我说的是越少越好。关于你说的，我想反问一下，为什么不把后期重构的时间放在一开始呢，你调整了程序要花时间，你就需要再次测试，有错误还得再次调试，这也花很多时间，为什么不把这些时间放在开始写程序的时候呢？另外，对于代码，我们知道最难的事是和那些legacy的代码搏斗，这些已成形的代码会成为创新的绊脚石。如果在一开始写代码的时候，多思考一些时间，多想好了，就能少一些重构，你反而能少一些工作量。不是吗？
重构这种事不应该被喜欢的，就像擦屁股的事越少越好。作为程序员，我们应该更喜欢创新，不是吗？
最后，关于Agile，我想说的是，软件开发这种活动没有必要为自己标榜成Agile式的，或是传统式的。这些东西只是形式上的东西，标榜这些东西，就像一些商品标榜自己是美国货一样，没有任何意思。这是商家的手段，不是吗？正真要标榜软件，应该你Unix/C那样，标榜自己是高性能的； 像git那样标榜自己是优雅的； 像Java那样标榜自己是run everywhere的；像苹果那样标榜自己是易用简单的…… 不是这样的吗？
Reply/回复