「程序員」還是「代碼生成器」？
TL; DR. 工程師在項目中的角色不應只是執行者，而應是整個項目的參與者。
按：國外的程序員有一句自嘲的話叫做：coffee in, code out. 程序員是最喜歡自嘲的一群人，這不失為一種積極的生活態度。但有些話如果你當真了，結果往往不會很好，比如剛才那句話。
</blockquote>入職以后接到的第一個任務，就是更新和修復現有的部門簽名系統。這個系統可以根據當前登入的帳號自動從后臺獲取相關信息，填入到簽名檔的對應位置上，因為自動獲取到的信息可能有誤差，所以還支持用戶手動修改。用戶修改完成后可以生成一張圖片保存下來，加入到郵件的簽名檔中。因為設計了新一版的郵件簽名，所以需要按照新的設計圖更新簽名樣式，同時需要解決當前系統中某一行過長時不能自動換行的 bug，以及后臺信息獲取不全的問題。
接到任務后，我大致瀏覽了一遍現有系統的源代碼以后就馬上著手改版了。在我看來，對于原有的系統來說，這些任務只是一些小修小補，所以我直接選擇了在現有的系統上加 patch 的方法。對于新增加的設計圖與原來的系統產生的不兼容的部分，也通過一些 patch 來修改掉。
這樣做的結果就是，這個任務完成后，系統里充斥著各種各樣的 patch ，邏輯異常復雜，如果不仔細想的話，就連自己再讀一遍代碼也未必能馬上明白所有地方。花了一天完成的新系統雖然上線了，布置給我任務的師兄和我自己都不太滿意。所幸這只是一個內部的系統，我還有機會補救。我提出重構整個系統。為了不讓重構僅僅是重蹈覆轍，我們對于出現的問題進行了分析。
問題分析
回顧從接到任務開始到重構前這整個的過程，問題出在了哪里呢？在接到任務以后，我做的是馬上著手執行。第一個問題可能就出在「馬上」上面。
第一次完成后的系統雖然能正常工作，但面臨的最大的問題就是，當需要添加新的設計圖或者對現有的設計圖做出修改時，非常難以維護。然而在動手之前，我并沒有考慮過這些問題。這個系統曾經供五六個不同的部門共同使用，每個部門都有自己的簽名檔，并且每個的設計也在不斷地變化當中。也就是說，這個系統需要高度可維護和可擴展是一個隱含的需求，然而因為我并沒有對整個系統的背景進行了解，只是執行眼前的任務，造成了最終難以維護的問題。
所以，工程師不僅要寫代碼，還要了解需求的背景，以指導自己的工作。
在解決后臺信息獲取不全的這個問題時，我花費了大量的時間在對接接口上，然而最終發現當時系統所用的 PHP 后臺接口已經很久沒有人維護了，連文檔中給出的示例都無法正常運行。這樣的經歷無疑讓人沮喪。究其問題在于，在接到任務的時候，我僅僅了解到后臺提供了這樣的接口就作罷，沒有對接口進行可用性測試，最終浪費了自己的時間。換句話說，需求方提供的資源不一定都是可用的，在正式開始工作之前，需要對資源進行可用性測試。
所以，工程師不僅要寫代碼，還要測試資源的可用性，以支持自己的工作。
我接到的任務不算復雜，但直接就去寫代碼的執行方式還是白白花費了不少時間和精力。對于文字換行這一個 bug ，其實可考慮的情況有很多：一種是因為部門信息本身就過長，從后端取得的結果直接就超出了一行；另一種是用戶在自己修改的時候讓結果超過了一行。而第二種情況又可以細分為兩種，即用戶輸入了換行符，或者添加文字后同段的內容超過一行。對于邏輯處理來說，這幾種情況每種需要做的處理都不一樣。如果沒有想清楚就去執行，要么是在過程中發現問題，邏輯反復更改，要么上線后才發現沒有考慮周全，這都不是我們想要看到的。
所以，工程師不僅要寫代碼，還要對需求進行完整地分析，把需求拆分成具體可執行的動作，以確保自己的工作嚴謹和周密。
在學校中，我們常常說 Deadline 是第一生產力。沒有時限的工作往往是很難有效推進的。學校里的 Deadline 通常由老師根據經驗來確定，而工作中就很難這樣了。布置任務的時候，師兄問我說，三個小時能不能做完？我大概只是簡單的過了一下腦子，就回答可以。結果最終花了一整天的時間。這里就涉及到一個時間評估的問題。在真實業務場景下，需求方通常要和工程師協商一個時間線，從工程師的角度來講，這個時間如何評估才比較合理呢？在上一步需求拆分完成后，針對每一個具體可執行的小步驟，都預估一個時間。那些很難直接給出預估時間的地方，就是任務的風險點。比如在這個任務中，我對于 Canvas 的操作不是很熟悉，這里可能占用很多時間，就是一個風險點。對于風險點，要找出解決方案，并且給出足夠并且合理的預留時間。把所有時間加到一起，再向上浮動 10% ，才是一個比較準確的預估時間。預估的時間對于整個項目的流程都起著至關重要的作用。
所以，工程師不僅要寫代碼，還要對時間進行合理預估，配合需求方制定項目的時間流程。
在做完以上所有的工作之后，才到了具體的執行階段。也就是之前我認為的工程師工作的全部——寫代碼。在完成這個任務的這一過程中，也不是沒有可以改進的地方。在寫代碼時候，遇到的問題我都傾向于獨立解決，即使在已經花費了很長時間的情況下，也沒有及時與師兄溝通。我們都遇到過這樣的情況，自己苦苦想了很久的問題，其實已經進入了死胡同，然而局外人一句話就可能幫我們解決。對于實際項目來講，溝通不僅僅局限于技術人員之間，發現問題后作為工程師，還應該及時與需求方溝通，保持信息的通暢，來幫助需求方協調整個項目。完成這個系統的時候我遇到的技術上的問題沒有及時和別人溝通，在約定的時間快要截止的時候沒有通知任何人，這在真實項目中是需要堅決避免的。
所以，工程師不僅要寫代碼，還要把問題及時與相關人員溝通，幫助自己也幫助別人高效地工作。
重構
問題分析過后，對于我來說，這一重構的過程也是我對工程師在項目中的定位的重新認識的過程。我記下了這個過程，感興趣的同學可以移步這里查看。
結語
現在有很多工程師抱怨自己在大公司中只是一枚鏍絲釘，多了不多，少了不少。他們每天埋頭寫代碼，需求來了，執行任務，再等待下一個需求。至少我認為，「人」的價值不應該僅限于此。如果把人當作黑盒，coffee in, code out，那人又和工具有什么差別呢？要做一個「程序員」還是「代碼生成器」，值得思考。
來自：http://code.mforever78.com/essay/2015/08/02/programmer-or-code-generator/本文由用戶 xcxc 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！