程序員最頭疼的七件事

懂點技術，瞎指揮

 

有人說不懂技術的瞎指揮很可怕，我卻是以爲懂點技術，而後指手畫腳更可怕！

 

有個國企的項目，甲方負責人李老是個局裏的二把手，不知道何時瞭解了一點編程的技術， 每次開需求會都是和咱們大談如何開發軟件，他的口頭禪就是： 這個需求，用個SQL從數據庫一選不就出來了？！大家怎麼得開發一週？！別想蒙我！

 

唉，他怎麼能考慮到用SQL的like是效率極低的， 數據量大了是要崩潰的，咱們得創建全文索引，須要用一套基於搜索的解決方案才行。 

 

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

 

懂技術的程序員在下面大眼瞪小眼。 

 

代碼都寫玩完了，需求變了

 

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

 

雖然敏捷軟件開發的方式對這個問題有必定的改善，可是沒法根治，尤爲是當客戶以爲這個東西就是好，必定要實現的時候，程序員基本上是無能爲力的。

 

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

 

任務時間估算

 

我工做了這麼多年了，遇到任務的時間估算，或者項目的工期估算仍是頭疼。

 

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

 

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

 

另一個緣由就是外因，人和項目的因素。你把任務時間估算得多了，有人會挑戰你，怎麼須要這麼長時間?  估算的少了，本身就默默加班忍受吧。

 

若是是項目倒逼工期，那任務估算就是一個擺設了。

 

到客戶那兒去演示

 

爲了作好一個演示，在公司把系統調試了不少遍，把演示的步驟一步步都準備好了，到了客戶那裏，多是手賤點了一個什麼東西，而後，系統崩潰了，演示進展不下去了。

 

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

 

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

 

寫文檔

 

代碼好不容易寫完了，剛剛喘口氣，準備開始下一個工做，領導說，把文檔也補一下，接口參數的含義都寫上 ，程序員內心一般都會不爽，有所抵觸，結果就是草草地寫個文檔出來。

 

爲何這樣呢，由於實現功能的那些代碼纔是體現本身價值的，可以賺錢的工做，文檔看起來只是附加品而已。工做作完了，誰願意多幹活呢？再說了，工做量估算的時候把寫文檔時間算進去了嗎？ 你都不給我時間，如今還讓我寫，不是讓我加班嗎？

 

若是想把工做作得漂漂亮亮，既有優雅的代碼，又有完善的文檔，必須得給文檔工做留出時間才行。

 

修改遺留多年的代碼

 

爲了實現一個新功能，我得修改六七個文件，其中包括一個長達5000行的JSP，三個500行的函數，2個沒人問津的存儲過程，作這一切的時候，還得當心翼翼地不能破壞老功能，此中酸爽滋味，不知作別的行業可否體會獲得?

 

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

 

可以從頭開啓一個新項目的同窗，仍是挺幸福的，好好珍惜吧。

 

Bug不可(難以)重現

 

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

 

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

 

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

 

只用一行代碼就Fix了這個Bug，可是重現的過程居然長達一個多月！