程式設計師最頭疼的七件事

懂點技術，瞎指揮

有人說不懂技術的瞎指揮很可怕，我倒是覺得懂點技術，然後指手畫腳更可怕！

有個國企的專案，甲方負責人李總是個局裡的二把手，不知道什麼時候了解了一點程式設計的技術，每次開需求會都是和我們大談如何開發軟體，他的口頭禪就是：這個需求，用個sql從資料庫一選不就出來了？！你們怎麼得開發一周？！別想蒙我！

唉，他怎麼能考慮到用sql的like是效率極低的，資料量大了是要崩潰的，我們得建立全文索引，需要用一套基於搜尋的解決方案才行。

甲方的技術實力看起來這麼「強悍」，不懂技術的乙方負責人只好和稀泥：我們回去再評估一下。

懂技術的程式設計師在下面大眼瞪小眼。

**都寫玩完了，需求變了

這一點我不想多說，相信大家都深有體會。

雖然敏捷軟體開發的方式對這個問題有一定的改善，但是無法**，尤其是當客戶覺得這個東西就是好，一定要實現的時候，程式設計師基本上是無能為力的。

必須得改！不想改? 還想不想幹了！

任務時間估算

我工作了這麼多年了，遇到任務的時間估算，或者專案的工期估算還是頭疼。

主要有兩方面原因，乙個是內因，即軟體固有的複雜性，軟體工程發展了這麼多年，我們努力地讓系統的各個模組獨立，關注點分離，高內聚，低耦合。

但是還是沒有辦法像搭積木那樣去開發軟體。很多細節糾纏在一起，難以準確估算。還有乙個很大的風險是：乙個你預料不到的，很小的問題就能把你死死地拖住，讓你耗費大量的精力。

另外乙個原因就是外因，人和專案的因素。你把任務時間估算得多了，有人會挑戰你，怎麼需要這麼長時間? 估算的少了，自己就默默加班忍受吧。

如果是專案倒逼工期，那任務估算就是乙個擺設了。

到客戶那兒去演示

為了做好乙個演示，在公司把系統除錯了很多遍，把演示的步驟一步步都準備好了，到了客戶那裡，可能是手賤點了乙個什麼東西，然後，系統崩潰了，演示進展不下去了。

經歷過兩次這樣的事情後，每次演示我都變得戰戰兢兢，如履薄冰，不敢越雷池一步，嚴格按照指令碼來走。

現場演示乙個不成熟的產品確實是讓人挺崩潰的事情。寫到這兒，我不由得想起來老羅在台上滿頭大汗地演示tnt的場面......

寫文件**好不容易寫完了，剛剛喘口氣，準備開始下乙個工作，領導說，把文件也補一下，介面引數的含義都寫上，程式設計師心裡通常都會不爽，有所牴觸，結果就是草草地寫個文件出來。

為什麼這樣呢，因為實現功能的那些**才是體現自己價值的，能夠賺錢的工作，文件看起來只是附加品而已。工作做完了，誰願意多幹活呢？再說了，工作量估算的時候把寫文件時間算進去了嗎？你都不給我時間，現在還讓我寫，不是讓我加班嗎？

如果想把工作做得漂漂亮亮，既有優雅的**，又有完善的文件，必須得給文件工作留出時間才行。

修改遺留多年的**

為了實現乙個新功能，我得修改六七個檔案，其中包括乙個長達5000行的jsp，三個500行的函式，2個沒人問津的儲存過程，做這一切的時候，還得小心翼翼地不能破壞老功能，此中酸爽滋味，不知道別的行業能否體會得到?

你說這遺留**爛吧，但是人家可以工作，你想重寫吧，一是沒有時間，二是重寫了能保證每個犄角旮旯的業務點都覆蓋嗎？所以只能採用漸進重構的道路，慢慢地把他改好。

能夠從頭開啟乙個新專案的同學，還是挺幸福的，好好珍惜吧。

bug不可(難以)重現

人世間最痛苦的事就是明明有個bug在我的眼前，我卻無法重現它。

四五年前，我們有個執行良好的應用突然出了狀況，一到下午兩點左右就會毫無徵兆地崩潰，檢視了日誌，根本沒有報任何錯誤。在測試環境中想盡了一切辦法進行模擬，總是無法重現。

這樣的現象持續了乙個多月，感覺就要絕望的時候發現了蛛絲馬跡，北京時間的下午兩點，是義大利的早上8點，那個時候，義大利的使用者會登入系統，有些特殊屬性的使用者做了乙個操作，觸發了乙個年久失修，普通使用者根本走不到的**分支，導致系統直接退出。

只用一行**就fix了這個bug，但是重現的過程竟然長達乙個多月！