軟件原型開發哪兒不對勁了
名詞解釋
我所在的公司是一箇中小型的公司。中小型的公司軟件的開發方法很多都是基於快速原型開發的。現在還有一種開發方法，叫敏捷開發，它挺好的，不過看起來蠻複雜的，權且不論。
那麼什麼是快速原型開發呢？它是一種軟件開發模型，官方的解釋是，快速原型模型的第一步是建造一個快速原型，實現客戶或未來的用戶與系統的交互，用戶或客戶對原型進行評價，進一步細化待開發軟件的需求。 通過逐步調整原型使其滿足客戶的要求，開發人員可以確定客戶的真正需求是什麼；第二步則在第一步的基礎上開發客戶滿意的軟件產品。
非官方的解釋是：用戶和你都不太明確他想做什麼軟件，先讓你做個簡單的樣板看看，符合胃口的話再繼續做。就好像你想到市場上買把武器，但不知道選劍好，還是選刀好。這時候你就讓夥計把他所有的兵器拿出來，你覺得哪種適合你，就爲你打造那種。
優缺點
很多公司應該利用這種開發方法發展的很好，因爲這樣做的成本低，風險相對小。假如是基於其他引擎做二次開發或者上層開發，那麼這種開發方法獲得的效果更加大大的好。這點好像解釋了爲什麼短短兩三年，手機軟件每天都會以上萬計的被開發出來（暫時不討論其中的質量問題）。
自然的，這種方法也存在不足。爲了快速響應用戶的需求，你就得加班了。所以本來是一項創造性的工作會變成一種勞力工作。真正能夠讀懂用戶的需求，或者能創造性的做出讓用戶耳目一新並放棄他原本心中弱小的但又包含固執想法是很困難的，更不幸的是，有些項目參與者會堅持把自己的想法套在上面，因爲那樣會體現一個人在項目中的作用。
加班其實還只是表面現象，其實質卻可能包含了更多的貓膩。看似風光的開發過程，其實做更多的開發也可能只是量的改變。我們都知道，人以上年紀，就看重經驗，就會用以前的經驗去判斷事情將怎麼去做。同樣的，一種能夠快速成功的方法，會讓人認爲這種方法可行。假如你用原型開發方法獲得了成功，那麼你就或多或少的被這種方法所吸引，從而減少對所作工作的知識的積累。所以到頭來，你雖然擁有很多的成果，但他們之間的關係卻沒有形成網絡聯繫。
飄渺的辦法
既如此，那爲何不採用更高級的開發模型呢？不過好像更高級只說應該不存在吧。每個公司，每個項目會有各自的特色，強行套用別人的方法恐怕會死的更早。我們知道當前世界有家公司比較特別，他就是蘋果，他可以對用戶的期望置之不理，直到發佈了，你才知道他的產品的廬山真面目。我想這樣的人才還是不多的，很多公司走出來就是爲了賺錢，這也是他們的生存之道，如此的劍走偏鋒他們喫不消的。
大型的公司會有專門的人負責底層的設計，然後另外的人在上面做功能開發。這樣做，就好像自助餐的盤子，盤子夠大，上面管你放湯，放水果還是放生魚片。這樣好像不錯哦。
不過中小公司卻用不了，因爲完全負責底層設計的人而能夠適應上層開發的人在這些公司很難找，存在一兩個也可能不夠數。很多人會說爲何公司捨不得放長線釣大魚。我想這樣的想法有點理想。現實社會不是你敢闖就會贏，你得有資本，要麼是頭腦好使，要麼賠的起運氣好。兩者都沒有，猶如螞蟻撼大象。 當然上面的說法忽略那些可以這麼做，但不敢做的人。
或許的辦法
上面看起來是一個死循環。既需要類似快速原型的方法來實現目標，又會被這種方法折騰的夠嗆。要突破這個死循環，或許再增加一項工作可以避免。這項工作大點的說是叫業務重組吧，小點的說是代碼重構。
業務重組不是我創的名詞，本來就有的。簡單的說就是對企業的功能進行重新劃分。這個部門做什麼，那個部門做什麼。業務重組重新梳理公司的業務情況，歸併功能相似的業務，分撤具有多個流程的業務。對於原先使用快速原型的公司做了很多產品的公司，能夠找到相同類型的項目，然後提取出公共的部分，新的類似項目就在此公共的部分進行開發。
代碼重構，它適合於在一個項目內部來提取底層接口。簡單的說就是你做一點東西，發現以後將會有類似的功能，或者以前就存在類似的功能的時候，就提取一個接口類。其實本來也應該這麼做的，但人嘛，一則不能完全判斷哪些是相似的，二則嫌麻煩，提取接口內核後會產出新的問題，三則對這樣做是否值得，是否符合時機都存在疑問。
上面的是2013年寫的。到了今天快速原型開發還是中小企業的選擇方式，但敏捷開發已經開始在大公司進行展開。快速原型的缺點誠如那時候所寫，面臨着產品並丟棄，質量差，難修改的問題。而我上面提到的方法雖然名稱差了，但是思路看起來是對的。我們仍然也必須時刻做好對每個小的功能的完善。