軟體隨想-項目上線後

從開發到上線差不多用了3個月，其實第一個月就把大部分功能實現了，之後兩個月都是需求的再次確認和修改BUG，期間穿插的做別的一些事情。總的來說比較順利，一馬平川沒有任何卡住的地方，也沒有出現“大腦CPU使用率突然飆升的情況”，但瑕疵太多，在此做一下簡單的記錄。

簡單介紹一下我們的作戰方式。頁面由專門的人切，只製作出部分頁面，類似的自己搞定，之後的樣式問題自己搞定，一個產品經理，兩個程式員，所有的需求都問產品經理，基本上是除了切頁面，其他的都由我們程式自己搞定。做的是一個公司內部的專案管理軟體(網站)的改版和升級，對於我來說基本上是新開發一個系統，因為以前的實現方式不太好，我換了一個實現方式，大約重寫了91.1%的代碼。

 

對需求的理解不夠全面。瞭解需求來自兩個方面一個是產品經理另一個是現有代碼。產品經理先跟我大致的介紹了一下，然後自己看現有的代碼，兩者結合得到自己的想法，於是開始開發，期間有問題隨時問產品經理。剛開始的時候加入太多自己的想法在裡面，導致對需求的理解有些偏差，導致後期做了一些不必要的修改，修改就是對原有代碼的破壞，本來寫得還行的代碼，被一點點的修改，因為小的修改我們總是不在意，慢慢的代碼就變得不好理解，到後期對部分代碼產生陌生的感覺，我怎麼會寫出這樣的代碼。儘管開發期間多次確認過需求，但還是有的地方被忽略掉了。用於理解消化需求的時間太少，導致後期一連串的惡化反應。代碼被改得不好理解，在改之前是別人對你的否定以及自我否定，因為你理解需求有誤，而現在的實現方式又是你對需求理解的結果，毀掉自己的代碼是痛苦的，特別是自己認為寫得好的代碼，還有就是很浪費時間。總之一句話：在需求調研時引入的BUG危害是最大的。

 

出來混遲早是要還的。不要抱僥倖心理，以為這不會發生，使用者不可能這樣操作，但是要知道，有的測試人員是很“變態”的，使用者也是很懶的，測試人員的一些變態操作會深深植入你的腦海，於是你在測試過程中也會做出異常的因為，於是你的程式就崩潰了，好的，你終於意識到這是個問題，於是你又開始了你的代碼修改之旅，也許是個快樂的旅程，更可能多的是痛苦的枯燥的沒什麼意義的自我批評。可能你還是無視測試人員的變態，運氣好的話這種問題一直都沒出現，直到遇到一個相同變態的使用者，地獄之門突然向你開啟，你開始承認錯了，你該承認錯誤了，在開發中我認為可能出錯的地方大部分都被測試人員發現了，沒有被發現的，我也默默的改了，因為我相信出來混遲早是要換的。

 

成也蕭何敗蕭何。程式員成就了自己的軟體，也是最瞭解自己作品雞肋在哪的人，如果我們像測試人員一樣摧殘我們的軟體，或許我們能發現測試人員發現不了的問題，同樣測試人員發現的BUG就越少，你的BUG列表就乾淨多了，在這次開發過程就是自己測試太少了，前前後後至少改了大大小小150個BUG。也明白別人發現自己那麼多錯誤多沒意思，你發現的問題越多跟別人口水的時間久越少，效率一直都是我追求的，也是因為一直追求開發效率導致這麼多BUG。

 

要有一點喬布斯精神，追求完美。因為我們是程式員，我們是有思想有主見的人。我們不能別人讓我們怎麼做我們就怎麼做，這樣很沒勁，被否定久了就必須反擊。需求可能不是很合理，咋們可以給個更合理更完美的實現，頁面板塊的色調搭配不合理，我們就應該大膽的質疑，給出自己的方案，你不覺得否定別人的方案給出自己更好的方案很爽嗎，軟體是我們程式員的作品，它應該有我們的思想，我們的設計理念，軟體對於我們來說不應該僅僅是執行、實現。我們必須打一場漂亮的反擊戰，反擊設計、反擊測試、反擊產品經理。只有這樣更好的提高自己，才可能做出更好的軟體。軟體使我們的孩子，必須有我們的DNA，我們應該讓他出生後比人的孩子更帥更聰明，直到有一天你很淡定的告訴別人：這是我的優良品種。

 

心有多遠，思想就有多遠，軟體隨想還在繼續......

軟體隨想--寫牛B的代碼

軟體隨想（一）

 

作者：陳太漢

部落格：http://www.cnblogs.com/hlxs/