程師在項(xiàng)目中的角色不應(yīng)只是執(zhí)行者，而應(yīng)是整個項(xiàng)目的參與者。

按：國外的程序員有一句自嘲的話叫做：coffee in, code out. 程序員是最喜歡自嘲的一群人，這不失為一種積極的生活態(tài)度。但有些話如果你當(dāng)真了，結(jié)果往往不會很好，比如剛才那句話。

[[146787]]

入職以后接到的***個任務(wù)，就是更新和修復(fù)現(xiàn)有的部門簽名系統(tǒng)。這個系統(tǒng)可以根據(jù)當(dāng)前登入的帳號自動從后臺獲取相關(guān)信息，填入到簽名檔的對應(yīng)位置 上，因?yàn)樽詣荧@取到的信息可能有誤差，所以還支持用戶手動修改。用戶修改完成后可以生成一張圖片保存下來，加入到郵件的簽名檔中。因?yàn)樵O(shè)計(jì)了新一版的郵件 簽名，所以需要按照新的設(shè)計(jì)圖更新簽名樣式，同時(shí)需要解決當(dāng)前系統(tǒng)中某一行過長時(shí)不能自動換行的 bug，以及后臺信息獲取不全的問題。

接到任務(wù)后，我大致瀏覽了一遍現(xiàn)有系統(tǒng)的源代碼以后就馬上著手改版了。在我看來，對于原有的系統(tǒng)來說，這些任務(wù)只是一些小修小補(bǔ)，所以我直接選擇了 在現(xiàn)有的系統(tǒng)上加 patch 的方法。對于新增加的設(shè)計(jì)圖與原來的系統(tǒng)產(chǎn)生的不兼容的部分，也通過一些 patch 來修改掉。

這樣做的結(jié)果就是，這個任務(wù)完成后，系統(tǒng)里充斥著各種各樣的 patch ，邏輯異常復(fù)雜，如果不仔細(xì)想的話，就連自己再讀一遍代碼也未必能馬上明白所有地方。花了一天完成的新系統(tǒng)雖然上線了，布置給我任務(wù)的師兄和我自己都不太 滿意。所幸這只是一個內(nèi)部的系統(tǒng)，我還有機(jī)會補(bǔ)救。我提出重構(gòu)整個系統(tǒng)。為了不讓重構(gòu)僅僅是重蹈覆轍，我們對于出現(xiàn)的問題進(jìn)行了分析。

問題分析

回顧從接到任務(wù)開始到重構(gòu)前這整個的過程，問題出在了哪里呢？在接到任務(wù)以后，我做的是馬上著手執(zhí)行。***個問題可能就出在「馬上」上面。

***次完成后的系統(tǒng)雖然能正常工作，但面臨的***的問題就是，當(dāng)需要添加新的設(shè)計(jì)圖或者對現(xiàn)有的設(shè)計(jì)圖做出修改時(shí)，非常難以維護(hù)。然而在動手之前， 我并沒有考慮過這些問題。這個系統(tǒng)曾經(jīng)供五六個不同的部門共同使用，每個部門都有自己的簽名檔，并且每個的設(shè)計(jì)也在不斷地變化當(dāng)中。也就是說，這個系統(tǒng)需 要高度可維護(hù)和可擴(kuò)展是一個隱含的需求，然而因?yàn)槲也]有對整個系統(tǒng)的背景進(jìn)行了解，只是執(zhí)行眼前的任務(wù)，造成了最終難以維護(hù)的問題。

所以，工程師不僅要寫代碼，還要了解需求的背景，以指導(dǎo)自己的工作。

在解決后臺信息獲取不全的這個問題時(shí)，我花費(fèi)了大量的時(shí)間在對接接口上，然而最終發(fā)現(xiàn)當(dāng)時(shí)系統(tǒng)所用的 PHP 后臺接口已經(jīng)很久沒有人維護(hù)了，連文檔中給出的示例都無法正常運(yùn)行。這樣的經(jīng)歷無疑讓人沮喪。究其問題在于，在接到任務(wù)的時(shí)候，我僅僅了解到后臺提供了這 樣的接口就作罷，沒有對接口進(jìn)行可用性測試，最終浪費(fèi)了自己的時(shí)間。換句話說，需求方提供的資源不一定都是可用的，在正式開始工作之前，需要對資源進(jìn)行可 用性測試。

所以，工程師不僅要寫代碼，還要測試資源的可用性，以支持自己的工作。

我接到的任務(wù)不算復(fù)雜，但直接就去寫代碼的執(zhí)行方式還是白白花費(fèi)了不少時(shí)間和精力。對于文字換行這一個 bug ，其實(shí)可考慮的情況有很多：一種是因?yàn)椴块T信息本身就過長，從后端取得的結(jié)果直接就超出了一行；另一種是用戶在自己修改的時(shí)候讓結(jié)果超過了一行。而第二種 情況又可以細(xì)分為兩種，即用戶輸入了換行符，或者添加文字后同段的內(nèi)容超過一行。對于邏輯處理來說，這幾種情況每種需要做的處理都不一樣。如果沒有想清楚 就去執(zhí)行，要么是在過程中發(fā)現(xiàn)問題，邏輯反復(fù)更改，要么上線后才發(fā)現(xiàn)沒有考慮周全，這都不是我們想要看到的。

所以，工程師不僅要寫代碼，還要對需求進(jìn)行完整地分析，把需求拆分成具體可執(zhí)行的動作，以確保自己的工作嚴(yán)謹(jǐn)和周密。

在學(xué)校中，我們常常說 Deadline 是***生產(chǎn)力。沒有時(shí)限的工作往往是很難有效推進(jìn)的。學(xué)校里的 Deadline 通常由老師根據(jù)經(jīng)驗(yàn)來確定，而工作中就很難這樣了。布置任務(wù)的時(shí)候，師兄問我說，三個小時(shí)能不能做完？我大概只是簡單的過了一下腦子，就回答可以。結(jié)果最 終花了一整天的時(shí)間。這里就涉及到一個時(shí)間評估的問題。在真實(shí)業(yè)務(wù)場景下，需求方通常要和工程師協(xié)商一個時(shí)間線，從工程師的角度來講，這個時(shí)間如何評估才 比較合理呢？在上一步需求拆分完成后，針對每一個具體可執(zhí)行的小步驟，都預(yù)估一個時(shí)間。那些很難直接給出預(yù)估時(shí)間的地方，就是任務(wù)的風(fēng)險(xiǎn)點(diǎn)。比如在這個任 務(wù)中，我對于 Canvas 的操作不是很熟悉，這里可能占用很多時(shí)間，就是一個風(fēng)險(xiǎn)點(diǎn)。對于風(fēng)險(xiǎn)點(diǎn)，要找出解決方案，并且給出足夠并且合理的預(yù)留時(shí)間。把所有時(shí)間加到一起，再向上浮 動 10% ，才是一個比較準(zhǔn)確的預(yù)估時(shí)間。預(yù)估的時(shí)間對于整個項(xiàng)目的流程都起著至關(guān)重要的作用。

所以，工程師不僅要寫代碼，還要對時(shí)間進(jìn)行合理預(yù)估，配合需求方制定項(xiàng)目的時(shí)間流程。

在做完以上所有的工作之后，才到了具體的執(zhí)行階段。也就是之前我認(rèn)為的工程師工作的全部——寫代碼。在完成這個任務(wù)的這一過程中，也不是沒有可以改 進(jìn)的地方。在寫代碼時(shí)候，遇到的問題我都傾向于獨(dú)立解決，即使在已經(jīng)花費(fèi)了很長時(shí)間的情況下，也沒有及時(shí)與師兄溝通。我們都遇到過這樣的情況，自己苦苦想 了很久的問題，其實(shí)已經(jīng)進(jìn)入了死胡同，然而局外人一句話就可能幫我們解決。對于實(shí)際項(xiàng)目來講，溝通不僅僅局限于技術(shù)人員之間，發(fā)現(xiàn)問題后作為工程師，還應(yīng) 該及時(shí)與需求方溝通，保持信息的通暢，來幫助需求方協(xié)調(diào)整個項(xiàng)目。完成這個系統(tǒng)的時(shí)候我遇到的技術(shù)上的問題沒有及時(shí)和別人溝通，在約定的時(shí)間快要截止的時(shí) 候沒有通知任何人，這在真實(shí)項(xiàng)目中是需要堅(jiān)決避免的。

所以，工程師不僅要寫代碼，還要把問題及時(shí)與相關(guān)人員溝通，幫助自己也幫助別人高效地工作。

重構(gòu)

問題分析過后，對于我來說，這一重構(gòu)的過程也是我對工程師在項(xiàng)目中的定位的重新認(rèn)識的過程。我記下了這個過程，感興趣的同學(xué)可以移步這里查看。

結(jié)語

現(xiàn)在有很多工程師抱怨自己在大公司中只是一枚鏍絲釘，多了不多，少了不少。他們每天埋頭寫代碼，需求來了，執(zhí)行任務(wù)，再等待下一個需求。至少我認(rèn)為，「人」的價(jià)值不應(yīng)該僅限于此。如果把人當(dāng)作黑盒，coffee in, code out，那人又和工具有什么差別呢？要做一個「程序員」還是「代碼生成器」，值得思考。

原文：http://code.mforever78.com/essay/2015/08/02/programmer-or-code-generator/ 作者： MForever78