9.設計解決方案
任務：給出一系列要求，設計出可實施的方案，包括設計資料和程式碼結構、功能演算法和應用程式流程。
難點：確保你設計的解決方案得滿足客戶的要求，並且按時完成。
網友的話：
“如何始於此終於彼可謂是最難的部分了。”——misconfiguration
“過於臃腫的設計會崩潰，過於淺薄則沒有用。”——nvteighen
“不去一個個試一試，就不知道什麼樣的方案才適用……。”——jpkotta
8.寫測試
任務：編寫單元測試，以確保每一部分程式碼都能正常運作。這些測試不但有助於在開發早期找出bug，還能方便後續的迴歸測試。很多開發方法論甚至鼓勵我們在寫程式碼之前就可以先寫好測試程式。
難點：選擇和編寫測試的過程是既辛苦又繁重的，有時候會讓人感覺是在做無用功。
網友的話：“我就是不喜歡寫測試，你能怎麼滴。”——Anonymous
7.編寫文件
任務：建立用於解釋程式碼和應用程式的文件，包括獨立文件和程式碼註釋。目標人群範圍從終端使用者乃至其他開發人員。
難點：很耗時間，甚至有時候你會覺得要是沒人看的話那不就是在浪費時間。
網友的話：
“Shit！！！就因為這是“程式”的組成部分，我們就得寫這些可能根本沒人會去看的文件。”——Christian Dechery
“通過文件，我們不需要閱讀程式碼就能知道其作用。”——Raghu Nandan
“簡潔又能清晰闡述的文件，我的大愛啊！”——Ayush Goel
6.實現自己並不認可的功能
任務：不管什麼原因，如果你的客戶或者上司堅持某個特性和功能，那麼你就不應該將個人的感情因素帶到工作中去。
難點：摒棄個人想法和意見，竭盡全力地實現或支援功能需求。
網友的話：“……當然你也可以堅持己見然後提早退休，呵呵。”——Sabbir Asgar
5.關於別人家的程式碼
任務：維護、除錯或改善由其他開發人員寫的應用程式或者程式碼片段。
難點：理解前任開發人員的程式碼是非常痛苦的一件事，特別是如果此人已經離開，而他的程式碼寫得亂七八糟、缺少必要的註釋和文件，那就更悲劇了。
網友的話：
“沒文件的程式碼就像後媽。”——Omar Diab
“應該淘汰掉那些不會好好寫程式碼的程式設計師……”——Nani Tatiana Isobel
“程式碼破萬行，沒有註釋也不怕不怕了。”——Simon Zhu
4.和其他人打交道
任務：收集客戶需求，提供狀態管理報告，配合測試人員，和其他工程師協作。
難點：需要向非技術人士解釋技術問題，不得不依賴於其他人交接過來的任務，與QA或其他開發人員出現意見相左情況的處理方式。
網友的話：
“交代機器幹事比交代人去做要來得容易得多。”——Marko Poutiainen
“三人行，必有我師焉……合作也是學習的機會。“——Anonymous
“……和外行人說話簡直就像對牛彈琴。” ——lnostdal
“總是要等其他團隊完成任務之後我們才能開工，太拖我們的後腿了。”——Anonymous
3.預估專案工期
任務：專案一開始，就需要估算出完成所需要的時間。
難點：哪怕沒有接觸過專案，手頭只有模糊的需求說明也得硬著頭皮預估時間。
網友的話：
“在開工之前，真的很難估算出會出現多少亂七八糟的問題……”——Jan Christian Meyer
“我發現估算時間可能是最難的部分了，因為很多人會將其當做一個承諾，信守著一諾千金。” ——Samnang Chhun
“……每次碰到這個問題我就一個頭十個大……”——Jack Menendez
2.解釋我的工作
任務：向非程式設計師——親朋好友，解釋自己的工作內容。
難點：親人和愛人不瞭解我們是做什麼的。總是被要求去解決任何與計算機有關的問題（比如修電腦）。
網友的話：
“總是要跟人解釋——我，不是，修電腦的。”——Brandon P-Lost
“不止一遍地和我的家人說明，我到底是幹什麼的。”——Utsav Singh Rathour
“程式設計的世界，外行人不懂。”——Anand Safi
“為什麼別人都認為我是給電腦安裝盜版作業系統和其他盜版軟體的傢伙呢？我幹什麼了我，我只是程式設計師。”——Anbu Jey
1.命名
任務：為變數、過程、函式、類、物件、資料庫元件等命名。
難點：即使是一個小程式，也會有很多需要命名的東西。名字最好一貫又簡潔，有內涵，能承載一些意思——這個是什麼或者這是用來做什麼的。
網友的話：
“想啊想啊想名字，想出一個好名字~”—— Aditya Muraletharan
“別煩我，我正在給函式命名呢。”—— Lakshman Siripurapu
“電腦科學中只有兩座大山：快取失效以及命名。”——Phil Karlton
各位，最讓你頭疼的事情是什麼呢？歡迎在這裡傾訴。
來自：PHP100
相關閱讀
評論(2)