※ 引述《NDark (溺于黑暗)》之铭言：
: 的原因避开了管理及工程的检验。其中的一些甚至应该烧掉，埋葬，用巨石镇压，然后把
: 这个警告刻在石头上：天真地过分简化管理，...
: Agile became a brand-name, with marketing hype. It therefore became subject
: to the rules of all such hyped products....
: 敏捷已经变质为一个招牌，还是一种行销的炒作。它只是波潮流所推送的产品中的品项。
这段文章还好啦(没看本文,只看节录)
主要不就是理想和现实间的差距吗
理想,也就是敏捷开发,这个idea很好,也有很多书在提倡
可以参考这本书 http://goo.gl/zYTckv
书的后面提供了一个失败和成功的例子
就像信仰一样,大家都希望人心向善,世界大同,但是理想和现实总是很差距
有很多要妥协的
敏捷开发很好,重构很好,可是schedule很赶
没时间好好思考,copy paste功能弄出来再说,先求有再求好
design pattern很好,但是没事用继承这种高超手法干么,明明有比较简单的作法
(我有听过前同事这样讲....)
写测试程式很好,但是schedule很赶,先求有再求好
总之就是先求有再求好了,不过事后通常不是因为懒或是code太难懂
反正也不会出错,就先放著,累积久了就变烂code了,相信大家都有经验
理想很好,但是没考虑到实务上的状况
有改动就有风险,跑好好的地方为什么要改,一定会有人这样想
更何况,要量化出怎样才叫好的开发是很困难的
敏捷开发很好,但是你要如何拿出数据说服别人??
举一个我个人的想法(不过也只是单方面的看法XD)
我觉得姑且不论任何写作方式,只要能作到三个大方向,大致上code不会烂到哪里去
1.命名精确,不要出现a1,a2等等的名称
2.每个函式控制在200~250行内
3.括号的层数控制在三层内
e.g if
{
for
{
if
{
}
}
}
我觉得这很基本,离敏捷开发也还谈不上,但实务上要完整实现就不知道要等多久了
so~实务离理想还太远了,一步一步来嘛,你要求一步到位下场就是没人认同
呼应一下这句,敏捷已经变质为一个招牌，还是一种行销的炒作。
至少面试拿来嘴砲是很有用的
同样的道理,"当责"这名词不也一样吗,观点很好
但想要一步到位,科科,当你去死~