最讓程序猿頭疼的九件難事

在外行人眼里，軟件開發工作就跟看天書一樣難，但是程序猿往往會一臉苦哈哈地表示“還有更難的呢！”以下總結了9件最讓程序猿糟心的事，簡直就是分分鐘讓他們精神分裂啊！！！

1、命名

任務：為變量、過程、函數、類、對象、數據庫組件等命名。

難點：即使是一個小程序，也會有很多需要命名的東西。名字最好一貫又簡潔，有內涵，能承載一些意思——這個是什么或者這是用來做什么的。

網友的話：

“想啊想啊想名字，想出一個好名字~”

“別煩我，我正在給函數命名呢。”

“計算機科學中只有兩座大山：緩存失效以及命名。”

2、解釋我的工作

任務：向非程序猿，親朋好友，解釋自己的工作內容。

難點：親人和愛人不了解自己是做什么的，總是被要求去解決任何與計算機有關的問題（比如修電腦）。

網友的話：

“總是要跟人解釋：我，不是，修電腦的。”

“不止一遍地和我的家人說明，我到底是干什么的。”

“編程的世界，外行人不懂。”

“為什么別人都認為我是給電腦安裝盜版操作系統和其他盜版軟件的家伙呢？我干什么了我，我只是程序猿。”

3、預估項目工期

任務：項目一開始，就需要估算出完成所需要的時間。

難點：哪怕沒有接觸過項目，手頭只有模糊的需求說明也得硬著頭皮預估時間。

網友的話：

“在開工之前，真的很難估算出會出現多少亂七八糟的問題……”

“我發現估算時間可能是最難的部分了，因為很多人會將其當做一個承諾，信守著一諾千金。” 

“……每次碰到這個問題我就一個頭十個大……”

4、和其他人打交道

任務：收集客戶需求，提供狀態管理報告，配合測試人員，和其他工程師協作。

難點：需要向非技術人士解釋技術問題，不得不依賴于其他人交接過來的任務，與QA或其他開發人員出現意見相左情況的處理方式。

網友的話：

“交代機器干事比交代人去做要來得容易得多。”

“……和外行人說話簡直就像對牛彈琴。” 

“總是要等其他團隊完成任務之后我們才能開工，太拖我們的后腿了。”

5、關于別人家的代碼

任務：維護、調試或改善由其他開發人員寫的應用程序或者代碼片段。

難點：理解前任開發人員的代碼是非常痛苦的一件事，特別是如果此人已經離開，而他的代碼寫得亂七八糟、缺少必要的注釋和文檔，那就更悲劇了。

網友的話：

“沒文檔的代碼就像后媽。”

“應該淘汰掉那些不會好好寫代碼的程序員……”

“代碼破萬行，沒有注釋也不怕不怕了。”

6、實現自己并不認可的功能

任務：不管什么原因，如果你的客戶或者上司堅持某個特性和功能，那么你就不應該將個人的感情因素帶到工作中去。

難點：摒棄個人想法和意見，竭盡全力地實現或支持功能需求。

網友的話：“……當然你也可以堅持己見然后提早退休，呵呵。”

7、編寫文檔

任務：創建用于解釋代碼和應用程序的文檔，包括獨立文檔和代碼注釋。目標人群范圍從終端用戶乃至其他開發人員。

難點：很耗時間，甚至有時候你會覺得要是沒人看的話那不就是在浪費時間。

網友的話：

“Shit！！！就因為這是“進程”的組成部分，我們就得寫這些可能根本沒人會去看的文檔。”

“通過文檔，我們不需要閱讀代碼就能知道其作用。”

“簡潔又能清晰闡述的文檔，我的大愛啊！”

8、寫測試

任務：編寫單元測試，以確保每一部分代碼都能正常運作。這些測試不但有助于在開發早期找出bug，還能方便后續的回歸測試。很多開發方法論甚至鼓勵我們在寫代碼之前就可以先寫好測試程序。

難點：選擇和編寫測試的過程是既辛苦又繁重的，有時候會讓人感覺是在做無用功。

網友的話：“我就是不喜歡寫測試，你能怎么滴。”

9、設計解決方案

任務：給出一系列要求，設計出可實施的方案，包括設計數據和代碼結構、功能算法和應用程序流程。

難點：確保你設計的解決方案得滿足客戶的要求，并且按時完成。

網友的話：

“如何始于此終于彼可謂是最難的部分了。”

“過于臃腫的設計會崩潰，過于淺薄則沒有用。”

“不去一個個試一試，就不知道什么樣的方案才適用……。”

那么各位程序猿們，最讓你頭疼的事情是什么呢？