今天不聊技術，談談“工程師“三個字

16年畢業由於幾門公選課的緣故和興趣我居然進入了現在這家公司成為了一名程式設計師，從最初的懵懵懂懂到後面公司業務的輕車熟路，我覺得自己還是有所成長的。但說實話有時看到OA上“中級工程師”我會感到羞愧，並不是因為“中級”的檔次不夠，是我有時候會質疑自己是不是“工程師“？我一向覺得只有修路築橋，翻手間起高樓成大廈的那種才是工程師，我這種天天靠著電腦伺服器的算的上工程師嗎？

這個問題我想過很多次，當我在工作中遇到越來越多的問題，比如前期設計不當影響的頻繁返工，比如單元測試的不到位導致程式碼的維護舉步維艱，比如怕出錯的地方最後一定出錯……，當這樣的問題越來越多的時候我開始明白這個行業的合格從非業者絕對是工程師。

我曾經以為技術就是一切，我總是在空餘閒暇時間逛論壇，看部落格，跑開源專案，我在這些大佬層出不窮的想法和讓人驚歎的程式碼實現中常常不能自拔，我總是豔羨著別人的“技術天賦”，而我就只能fork，star…..，那段時候，我總想把所有最新站在潮流前沿的技術瞭解清楚，以致於我忽略了工程師其它方面的積累，到後面應對更加複雜的業務，領導讓我獨當一面的時候卻感到壓力很大，如果我具備一個工程師全面的能力，我相信我會輕鬆很多，在後來的時間裡我開始積累這些東西，剛好也快從這個公司離開了，就以這篇部落格總結下吧！

一.主人翁意識
在參與一個專案的開始，無論我是主要開發人員也好，還是臨時抽調安排也好，我都需要對這個專案有主人翁意識，並不是僅僅作為一個員工來參與這個專案，我寫的每一行程式碼，每一行註釋，每一行文件都應該邏輯清晰，因為我的每一次commit都會影響我的同事，如果我能做到一切清晰，那麼相互正影響下，整個專案的交付質量必然是不可能低的！
在每一個專案的節點，我們都應該問問自己系統的架構是否需要改進？介面文件是否清晰完善？日誌是否完整？單元測試是否覆蓋合格？資料庫是否需要擴容？快取空間夠不夠？這都是我們要考慮的事情！
我們不怕問題，並且應該積極發現問題暴露問題，推動team的合作，保證專案的順利進行。

二.時間觀念
說實話，我的時間觀念還真的是挺強的，但我深深理解需求頻繁改變導致專案的一再延期的無奈，但是在除掉不可抗力的情況下，專案進度按時進行是一項很重要的執行能力。而保證專案的進度，我覺得有兩點做事的計劃和主次，凡事預則立不預則廢，我們需要用工具嚴格把控自己每天的timeLine，本來今天該完成的為什麼沒完成？以後是否還會出現這種情況？假如萬一出現該怎麼解決？其次對於手頭的工作要合理的根據情況以及領導的安排分清主次，比如先完成別人需要依賴我們的工作，這就好像我們的工作是同步阻塞的，我不完成後面的同事就被堵住了。

三.階段性反饋
專案每推進到一個節點，需要跟team或者領導積極的反饋，切勿自己悶頭往前走，我們總是記得一個詞叫“積重難返”，我們儘量做到交代的事件件有著落，事事有迴音。

四.合理的提問和討論
在專案進行的過程中，有時候很多情況是專案經理帶著我們跑，在一些會議的過程中，很多專案參與人員很少發言，這是不利於專案的良性發展的，作為專案的參與人員，它就像我們的孩子一樣，也許你在造腳，我在劃手，他在弄軀幹，但是不可能由一個人全權，他不可能考慮到方方面面，在程式碼評審專案評審的這類體現集體智慧的活動中就是為了讓大家集思廣益，如果大多數都沉默，那麼這次會議基本沒有意義，波克定理告訴我們，只有在爭辯中，才可能誕生最好的主意和最好的決定。

五.保持敬畏
在工作中存在各種各樣的規範，例如程式碼規範、設計規範、上線規範等等。我們必須明白，這些規範的制定一定是基於某些客觀原因的，它們都是歷史上無數 Case 積累而來的經驗。團隊裡的每一個成員都應該學習並嚴格遵守，這一點對於新人尤其重要。當我們進入到一個新的團隊，請先暫時忘掉之前的習慣，要儘快學習團隊既有的規範，並且讓自己與團隊保持一致。以編碼風格為例，很多同學往往習慣於自己之前的程式碼寫作風格，在做新公司第一個專案時，也按照自己的習慣進行變數、包的命名等等。
當然我們也需要保持對技術的敬畏，學習同事的優點，不能因為自己隨著工齡和技術水平的提高便不再虛若懷谷，我非常喜歡一句話，“知道的越多知道的越不多”，世界很大，奇妙的東西很多，只有保持謙虛的態度才能從這個世界獲取更多有意思的東西。

隨隨便便寫了幾條自己有感而發的東西，當然成為一個合格的工程師還有許多需要我們去打磨學習的東西，需要我們一點點的積累和思考，或許不久的將來會發現我們做的東西比起高樓成大廈更有成就感！

管什麼困難無窮，進一寸有一寸的歡喜。