兩個項目, 一個總結 - 2012.12.18項目總結
博客連續13天沒有更新了, 有種強烈的負罪感, 當一件事成為一個習慣后如果有一天你突然沒有去做會覺得很不適應。這12天以來做了兩個小項目, 一個是成功的, 一個是失敗的。
一、這篇博客的適用對象
1>. 沒有實戰經驗的獨立開發者 ;
2>. 想在網上接私活的朋友 ;
3>. 需要一篇項目總結模板應付檢查的朋友(開玩笑的)。
博文背景:
2012年12月13日夜, 在某任務發布網站接到一個小活, 這里對於任務網站以及其他信息全部省略, 避免軟文嫌疑, 經過5天的努力后項目順利通過驗收。次日, 經朋友介紹又開始着手一個小項目, 此時是19號, 22號晚該項目宣布失敗。兩個項目的成員, 筆者自己。
這里不說項目內容, 只說項目的一些體會。
一、項目啟動前的准備工作
這兩個小項目客戶都沒有對代碼的所用的語言加以要求, 客戶一要求要盡快完成並且軟件運行要穩定, 客戶二的項目有些棘手, 因為項目的成功和失敗不掌握在我手里, 是有關廣告推廣的一個軟件。
1>. 確定所使用的語言
對於這兩個項目我使用的都是Python語言, 一是因為筆者對Python語言較為熟悉, 二是項目較小, 對數據處理的速度要求也並不高, 只是為了用軟件替代重復的手動工作。
2>. 工欲善其事, 必先利其器
除了開發環境的准備外, 一個人的項目也要做好版本控制, 及時提交進行備份, 避免代碼的意外發生, 選擇並使用好一個順手的版本控制管理工具是每個開發者都應該具備的能力, git、svn等任你選。 此外還有各種項目管理工具, 感覺需要就提前准備好。
3>. 明確項目需求
需求不明確就直接進行編碼那是不明智的選擇, 直接編碼項目過程中不知道需求變動多少次, 可以以單位n進行計算, 因此在需求不明確的情況下就開發編碼即使客戶需求變動頻繁開發者也有很大一部分責任。
二、如何避免項目過程中需求頻繁變動
在聯系到客戶時客戶就已經將軟件的需求和我說了一遍, 但是並不詳細, 只是大致的描述了軟件所需的功能, 用戶中途需求頻繁變動是個很常見的問題, 也是千萬開發人員最不想面對的問題。 我聽說過一個笑話, 說殺死一個程序員很簡單, 把需求改三遍就行了。 當然, 這不是說開發人員怕需求變動, 而是感覺無謂的變動簡單就是在浪費大家寶貴的生命, 為什么客戶就不能提前把需求一次性描述清呢? 筆者認為, 可能有以下幾點原因:
①. 客戶不懂技術, 他只能將自己想要的功能描述清楚, 並且從決定找人開發這個軟件到找到開發人員這個過程所考慮的時間一般不會太長, 在這個過程中很少有客戶認真分析並把所需的功能全部考慮徹底再聯系開發者, 甚至他不會想着去寫一個需求文檔交給你 ;
②. 客戶會認為軟件開發者是萬能的, 他們會把軟件開發的漂漂亮亮 ;
③. 把大致軟件需求大致描述后客戶不會把這件事拋到腦后, 因為這直接和他口袋里的RMB有關, 當他閑下來喝茶的時候他也會想着這個軟件開發的怎么樣了, 以后打算怎么使用這個軟件之類的問題, 忽然, 客戶一拍腦門, 對了, 這個功能不如改成這樣, 這樣我使用時肯定會更方便怎么怎么樣, 然后... 就都知道然后了。
筆者是如何處理需求頻繁變動的問題的:
對於需求變動, 我們一般不可能直接對用戶說一旦需求確定, 不允許再變動需求, 這樣是不科學的, 除非你確定以后堅決不會再和這個客戶打交道, 也不指望下次他再找你開發軟件。
筆者的做法:
①. 從客戶那得到需求后再自己整理遍需求並得到用戶確認
筆者的這兩個客戶都沒有給筆者相應的需求文檔, 只是通過電話或QQ聊天告訴我軟件需求的功能, 當客戶將需求說完后筆者將這些需求整理並寫成一份軟件功能需求設計文檔交給用戶看, 看看是否漏掉了某個功能或者哪個功能設計的不夠合理。 一般來說, 對於一些用戶描述模糊的需求, 或者在項目過程中可能變動的可能性最大的需求再這一步用戶就會提出。
②. 給用戶最大的DIY空間
我們不知道客戶對軟件的使用習慣, 尤其是在UI這塊, 有可能你設計的很滿意的一個界面, 設計完成后客戶看過會讓你這里調整下, 那里調整下, 這個過程是個痛苦的過程, 就像你自己親手設計的一件完美的藝術品現在就要被不懂藝術的人"踐踏"一樣, 心里一定很不舒服。 這里我覺得我們不應該埋怨用戶不懂"藝術", 而是每個人的使用習慣不同, 這是實際情況, 就像我們喜歡使用快捷鍵, 不喜歡拿個鼠標一點點的點擊, 而普通用戶才不會去記這些快捷鍵, 他們覺得鼠標點更方便, 你能讓用戶放棄使用鼠標而全部改用快捷鍵或者更干脆點使用命令行?
筆者首先詢問了客戶對於軟件界面是否需求自己進行設計, 如果客戶需要的話, 趁這個時候你可以去分析下項目了, 如果客戶說你們設計就行, 我對界面沒有要求。 那么這時也要注意, 是真沒要求嗎? 客戶這樣說可能是平時比較忙, 沒有時間來自己個性化界面, 二是怕自己不懂設計, 如果自己設計, 設計出來后被人笑話, 以后想找我們再修改也不好意思。
對於筆者這個項目客戶說讓我設計就行, 於是筆者使用PS設計了份軟件四個不同界面的草圖, 和大多數開發者一樣, 本以為設計的自己已經很滿意了, 誰知拿給用戶看時看時還是進行了4處局部調整。
③. 模塊化開發, 反復詢問
在確定軟件的結構后, 每進行一個界面/模塊的功能前向用戶描述該界面/模塊的功能, 並詢問這樣設計如何, 當用戶感覺滿意后再進行該界面/模塊的功能的實現。
④. 過大的變動或不必要的變動放到最后進行實現
對於需求變動很大的請求, 可以酌情考慮是否拒絕, 如果決定拒絕的話要盡量向用戶解釋清拒絕的原因, 要從用戶角度進行拒絕, 不要說技術上難以實現之類的話, 如果你說技術上難以實現, 即使真的難以實現客戶也會覺得你這人不厚道, 下次再也不和你合作了。 可以向用戶這樣解釋: 如果要進行這個變動的話從技術上是沒問題的, 但是如果確定要進行變動的話可能要增加項目開發的時間X天, 因為前面所進行的架構也要重新進行設計, 以及xxx原因。剩下的xxx原因就自己發揮想象吧, 筆者對文字游戲實在不擅長。就像這次中途的3次變動我也全部都答應了。
如果你感覺這個變動可有可無, 即使不變動也不會對使用上有影響, 那么告訴客戶說這樣變動將再軟件收尾時進行實現, 避免打亂了現在的腳步, 不過你應該把變動需求記下來, 如果忘了那就是你的責任了, 誠信很重要。
三、如何提高開發效率
1>. 先動腦、再動手
不要先記着碼代碼, 不然寫着寫着你就會發現, 又寫廢了xxx行代碼, 或者, 額... 好吧, 再Ctrl + C, Ctrl + V一段湊合上去, 如果你又copy paste了一段, 那么你應該慶幸, 還好, 是一個人的項目, 反正代碼也餿了, 就讓它更垃圾一些吧! 仔細而又認真分析需求才是硬道理, 做好功能上的分析, 從中分析出一些基本的通用方法, 調用的價值遠大於copy paste。
架構上就不多說了, 由於前文已說, 不講項目內容, 沒有實例也談不上架構。
2>. 合理注釋和命名
如果你覺得這個軟件從此不再維護並且能夠一氣呵成, 恭喜你, 注釋對你已成浮雲。 "注釋就是對代碼的解釋和說明。目的是為了讓別人和自己很容易看懂。", 這是百科對編程代碼注釋的定義, 從接觸編程開始就和注釋打交道, 寫注釋是個習慣, 需要慢慢養成。 我有個朋友, 代碼寫的很棒, 就是不願寫注釋, 他不寫注釋, 代碼我就是不想看, 因此雖然我們在說話上很談得來但從來沒有合作過一個項目。如果在一個團隊里, 不寫注釋的代碼是令人無法忍受的。
命名問題根據自己喜好, 作用也就不再啰嗦一遍了。
3>. 模塊化開發, 避免思維混亂
不要同時打開多個模塊的工作窗口, 把一個模塊的功能徹底完善了再去實現另一個模塊, 人類大腦即便可以"多線程", 但別忘了線程間的切換也是需要花費一定時間的。
4>. 適當加班
這一條可能要惹起爭議, 不多說, 加班根據個人情況而定, 一個人的項目, 只能說加班是常事。
四、面對問題, 心態很重要
如果一個項目, 在手里很順利的就給解決掉了, 這個項目對你來說實際上又虧了一點, 因為他沒有難度, 你只不過是在做你以前重復做的事情, 就像幼兒園時老師讓我們寫20遍 1 + 1 = 2, 到了五年級再讓我們寫1 + 1 = 2一樣, 如果是這樣的話, 這樣項目帶給你的只是一點經濟上的收益, 對知識上收益卻不大。
遇到問題是好事, 起碼說明利用這次項目又可以學習到新的知識。
"沒有解決不了的問題, 沒有實現不了的功能。" 不管這句的真假, 但一定要抱着這種思想來解決問題, 官方的手冊和搜索引擎是解決問題最好的幫手。 向別人提問那是次要的, 鍛煉自己獨立解決問題的能力才是真能力。
遇到棘手的問題, 不要着急, 越急越沒有頭緒, 喝杯水躺下來休息會再思考, 很有可能在你躺下的那一會靈感就好了。 一定要事先准備好筆和紙, 靈感稍縱即逝, 打個哈欠的就很有可能導致把剛才的靈感給忘了。
五、做好優化、做好測試
代碼的優化是筆者經常忽略的一個問題, 並且常常找借口來忽略掉代碼優化, 這類的借口通常是客戶要的緊或者是優化不優化對效率的影響不大。 明知道可以優化的情況下不去優化這種行為稱為什么好呢? 要想寫出高質量的代碼, 優化是個很重要的步驟, 希望讀者引以為戒, 不要犯筆者這樣的錯誤, 條件允許的情況下一定要回顧下代碼看看哪里需要優化下。
模塊集成完畢后開始測試, 測試也是門很深的技術, 尤其是在軟件較為復雜的情況下, 筆者沒有深入研究過有關測試的內容, 所以不敢亂說, 怕一不小心就造成了誤導, 那我就是罪人啊。
測試最主要的是模擬用戶的真實使用情況進行測試, 在第一個項目中由於對穩定性要求較高, 所以筆者就將軟件隨機導入好任務后讓他自己跑了一天一夜, 結果還真出問題了, 白天一天運行正常, 夜里莫名拋出了個異常導致軟件中止, 第二天筆者就感覺十分慶幸, 幸虧跑出問題了, 如果拿給用戶后再出現這樣的問題用戶會怎么想? 軟件掛掉的原因根據軟件的日志也找到了, 是由於異常處理不到位導致的。
六、項目結束后應該做的
寫篇博客, 把心得總結出來, 分享給更多的朋友。
引用《黑客防線》上的一句話作為本篇的結束語: 程序員是值得尊敬的，程序員的雙手是魔術師的雙手，他們把枯燥無味的代碼變成了豐富多彩的軟件。
--------------------
wid, 2012.12.24