给将要进入职场的同学 - 开发软件不是闭卷考试
有同學問我這個問題：
“你正在做一個項目，這個項目有一項關鍵的feature需要實現，這個feature有一定的技術難度，你調試了很久，都沒找到實現的途徑，這時你已經在這個feature上花了很多時間了，而且無法預期解決需要多長時間。在這種情況下，你會怎么做？”
??
一種典型失敗的情況是：
第一天：我正在做一個關鍵的feature, 看起來不難，做好了會很有面子。。。
第三天：就是搞不通，就這樣過了三天，其中“murphy's law”又浪費了一天。我想還是加班，先別告訴老板；如果做好了，再加緊做幾個小的feature。這樣還是能趕上進度。。。
第五天：全組開會，支吾了幾句，說還是很有希望如期完成的。。。
第九天：加了班，也問了同事，還是沒戲，小的feature也沒時間做了… 眼看期限就要到了，心里充滿了悲劇情緒。老板要是問起，就如實說明，要是沒問，我還是爭取做好了再報告。
第十一天：期限到了！還是沒頭緒， 要和老板開會review了，Panic！
?
?
首先我們要明確，這是一個實際的團隊項目。不是學校里的閉卷考試（一些人在離開學校很久還偶爾做惡夢，考試中一些題做不出來…）。
?
實際的項目中的問題，都是有解的，而且大多數是多項式時間內有解。我們在現實項目中的“解題能力”，取決于下面這些因素：
?
1．? 對問題的了解，有沒有能力了解客戶需求，分析問題，把大問題分解成小問題來解決。有沒有眼光看到可以簡化/繞過一些難題. 在閉卷考試的時候，所有的題意都在試卷上，理解好了之后，就可以埋頭做題了；但是實際項目中，用戶的初始需求是非常含糊的，而且經常變化。比如“網站要支持搜索”- 是哪一種呢？
????? - 全部自己做搜索，還是可以用第三方的解決方案？
????? - 所有剛剛post的信息必須立即顯示在結果中，還是允許有延時
????? - 支持中文？分詞？還是。。。
????? - 支持復雜的查詢條件么？是否支持再次查詢？
????? - 結果的ranking 有何要求？
????? - 最終想達到什么結果？
????? 不同的需求，有不同的解決方案，這時不宜“make too much assumption”，認為用戶要的就是某一種，就甩開膀子開始做。
?
????? 要深入的了解用戶文字后面的真正理由，一個工程師有一次說他的企業客戶要求 UI 所有的按鈕都要是3D 并且半透明。深入了解后，發現原因是客戶的MM 喜歡玩某一時髦游戲軟件（就不點名了），上面的按鈕都是這樣的。 工程師大叫一聲 - 我倒...?? 他從Faint 中蘇醒后，怎么辦?? 我想他可以提示客戶專注于軟件的流程和業務邏輯，也許能把按鈕的需求放到較低的優先級。
?
????? 另外，有時候 low-tech 的解決方案要更好。 不一定每一個類都要多態繼承, 用很多虛函數, 才能實現。
?
2．? 對技術的了解，看書的時候覺得“技止此耳”，開發項目的時候才覺得實際情況和書上講的都有一些出入，偏偏一些重要的出入書上沒有提。我們很多人是邊看asp.net的書, 邊開發asp.net 的項目，這相當于一邊看醫學書一邊動手術。。。
?
3．? 溝通的能力 – 軟件工程項目中最怕的是“surprise”和“lack of visibility”，作為程序員，溝通非常重要。及早和同事/上級/客戶通報項目遇到的風險，會讓大家都了解項目的進展及問題，及時得出解決方案。 比如要達到某個要求有困難，用戶是否一定要此功能？要及時溝通。
?
4．? 估計任務的能力 – 軟件項目難度及日程的估計，是一門不小的學問，初學者犯了錯誤也沒關系，關鍵是要吃一塹，長一智。當你說“某某 feature要在某某日子完成”，你的意思是到了那一天：
??? - 程序剛寫好，編譯通過， or
??? - 可以在debugger 中運行通過， or
??? - debug/retail 都成功，可以集成在網站上，但是有一些問題 or
??? - 自己已經完成了測試， or
??? - 測試人員已經全面完成了測試，or
??? - 和其他有依賴關系的功能都集成測試過。
?
??? 要達到不同的狀態需要的時間是很不一樣的！
?
5.? 在以上能力的基礎上，還要有對不切實際的需求說 “no”的勇氣和自信。
?
講了這么多，我想大家都會知道怎么做了。
原作寫于 2006 年.
http://yishan.cc/blogs/xin/archive/2006/07/17/450.aspx
?
總結
以上是生活随笔為你收集整理的给将要进入职场的同学 - 开发软件不是闭卷考试的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： asp.net 文本框显示xml格式数据
- 下一篇： 去 QCon 学习