對程序員來說最難的是寫代碼嗎？

掌握一門編程語言基本語法和常用框架之后，再來寫具體的實現代碼是非常簡單的一件事情。工作中程序員大部分時間用在三件事情上，一是談需求。二是寫文檔。三是杠測試。

談需求是與業務人員溝通程序實現哪些功能，與產品敲定程序的范圍到什么程度。業務人員描述需求很簡單，經常是用一句話概括，如我想要一個什么樣的功能。產品對功能范圍的要求也不麻煩，那誰誰家的功能很不錯，按照那個來做咱們的就行。在這種情況下，程序員基本是懵逼狀態。經過N輪的“談判”，才能最終確定需求是很平常的事情。

寫文檔是把大家的想法落到字面上，并形成完整的技術方案。討論需求時，大家是東一棒槌西一镢頭地高談闊論。匯總論證時，發現會議紀要的內容是松散的，很難形成一個整體的思路。撰寫修改寫、討論確認，反復多次，極個別技術方案的版本號從0.1能修改到0.9。如此折騰下來，讓本來文字功底一般的碼農，到了崩潰的邊緣。

杠測試是與功能測試人員的恩怨情仇。恩的方面，測試人員為自己的質量把關。仇的方面，大家對細節的理解偏差，帶來的互相鄙視。碼農覺得主題功能完成就可發布版本，測試覺得細節也很重要。BUG、缺陷、優化項最好是能完全解決。小編曾經遇到過界面風格圖片相差2個像素值，測試不發布正式版本的情況。

最后，用我們團隊的需求受理到版本發布的時間作為栗子來給大家說明。普通簡單需求、一個碼農、一個測試的情況下，我們需要10個工作日完成。由于涉及到客戶money，我們要求功能必須是零缺陷。這10個工作日是這么安排，2天需求對接、1天編碼工作、1天單元測試（碼農自測附帶文檔）、測試2天，剩余4天作為機動。在實際執行時，只有編碼時間基本不變，其他超出計劃時間的情況非常普遍，10個工作日還比較緊張。由此可見，編碼最可控，其他比較難把握，難易程度也大抵如此。

屏幕前的您是怎么認為的呢？