※ 引述《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~實務離理想還太遠了,一步一步來嘛,你要求一步到位下場就是沒人認同
呼應一下這句,敏捷已經變質為一個招牌，還是一種行銷的炒作。
至少面試拿來嘴砲是很有用的
同樣的道理,"當責"這名詞不也一樣嗎,觀點很好
但想要一步到位,科科,當你去死~