程式設計師的飯碗和杯具

你有沒有這樣的經歷？

　　在需求階段搞得很複雜，需要各種各樣的功能，然後系統設計的時候，想用這個設計模式，那個架構，等等，總是想把自己的系統搞得功能強大，靈活性好，可擴充套件性好等等，有時候為了照顧使用者體驗加了一堆亂七八糟的東西，總認為自己能建一座鳥巢。然後等到編碼的時候，忽然發現，資料庫設計不合理，缺這少那，更悲催的是，需求錯了，使用者真的需要這些東西嗎？一遍，兩遍，N遍改。結果，就一直改啊改的，把系統改成了一個雞窩，這個過程中，客戶還一直催啊催啊的，你只能著急上火，什麼架構，什麼設計模式，什麼使用者體驗，什麼效率啊，什麼根據UML啊，什麼後期維護啊，都是扯淡，系統能跑起來就已經是萬幸了。

經歷過嗎？

　　面對著看似簡單的任務，構思得如何美好，然後因為前期需求和設計的問題，後期不停得改啊改啊的，然後改得面目全非。然後看著系統，在心裡恨恨地罵一句：狗屎。圖一時之快帶來後期的無盡痛苦。只要是合格的程式設計師，都理解需求和前期設計的重要性。

　　常常用“需求永遠都是變化的，如果不變化，那程式設計師還幹屁啊”這句話來安慰自己。需求變化是程式設計師的飯碗，貌似也是程式設計師的一大杯具。

　　不得不擺低姿態，用於承認，自己的團隊在專案經驗和技術水平上都有很大欠缺，在專案控制上很有問題。也曾想過，用敏捷開發的思想去應對上面提到的問題（敏捷開發是一種以人為核心、迭代、循序漸進的開發方法。）也想過，使用快速原型，自頂向下開發，使用者意見，快速迭代.....但是這些也就停留在想想的階段，我的團隊是一個草根團隊，本人也缺少專案經驗和技術水平對整個系統進行合理控制，而且有的時候，工期很短滴，不可能一搞搞個年八月的。
 
　　大家都知道OFFICE好，可是人家投入了多少嗎？今天的OFFICE經過多少個版本、經過多少年頭才熬出來的，絕不是一蹴而就的。國內企業願意在這方面花那麼多成本嗎？一個差不多的專案幾個月時間而已，需求佔一個月（半個月寫需求文件，半個月評審需求，修改需求），原型佔一個月（半個月畫原型，半個月評審和修改原型），一個月開發（2個星期打架構，畫UML，2個星期寫程式碼），一個月測試，然後改。是人們太著急嗎？人們不得不急，大家都是要吃飯的，我們沒有那麼多資源去搞使用者體驗，去不停地調查需求，去考慮後期擴充套件等等。公司沒那實力，自己也沒必要給自己找罪受，只知道到期交專案拿錢，維護事，別人看著辦。系統用個一兩年，然後維護的人換了一批又一批，直到人們不耐煩了，罵了句：雞窩。然後推倒重構，重新來，然後幾個月時間，一個新系統趕出來，繼續迎接著下一批人的批判，步了上一批人的後塵，然後迴圈下去。當我們一遍遍地叫囂“別人做的什麼玩意兒啊，垃圾”，當我們一遍遍數落“前輩”的不是的時候，當我們一遍遍地叫喧“使用者體驗”的時候，我們真的吸取他們教訓了嗎？（不要拍我啊）我們在批評別人的時候，自己真的做得足夠好嗎？當我們真正做的時候，是不是又走了別人的老路？你懂得。
 
　　程式設計師這條路，依然是條學習的路啊，在專案中，總是能看到別人喝自己的不足，發現那麼多問題。我們可以抱怨做不出優秀的專案是因為環境不好，團隊不好，公司資源不好，但抱怨的同時，一定要看看，你自己是不是足夠好，寫得程式碼是不是狗屎一樣，如果是專案經理，你的技術和經驗，對整個團隊和專案的把控，是否在一個高水平上，和某些國際水準有多大差距。不要盲目地抱怨，抱怨地同時，請記住一步步提高自己。想要發出自己的聲音，必須要到達那個層次。
 
　　還要知道，程式設計師這條路，絕不是單打獨鬥，逞個人英雄的路。你個人技術再怎麼強，專案經驗再怎麼豐富，你也很難做好一個產品，管理好一個產品。必須要一個團隊，一個技術強，專案經驗豐富的學習型團隊。不然，很難順利地在做需求，寫需求文件，畫原型，需求評審，搞設計，打架構，寫程式碼，和測試這條路上走下來，或者快速迭代，不噁心，按部就班地下來。
 
　　呼應一下開頭，最近剛剛合作開發完畢業設計管理系統，屬於教務系統的一個小的子系統，麻雀雖小，五臟俱全啊，就很徹底地遭遇了文章開頭描述的情形。僅僅20來天，很容易想象我們需求和設計搞得怎麼樣，後期已經吐了又吐了，不幸中的萬幸，讓它跑起來了，跑得怎麼樣還得繼續看。不到一個月就已經吐成這樣了，可想而知，如果一個專案戰線拉到以年為單位了，那豈不是成吐仙了，水平不夠啊，接著學習吧。有同感的人，為了我們的飯碗和杯具，也努力提高自己吧。

來源：網路