程式設計師，如何在工作中嶄露頭角？

　　文章作者 Yuriy Lopotun有著8年的IT工作經驗，分別在4家不同的公司。在這期間有幸和一些程式設計師一起共事，他們都很特別：有的人在這個行業裡取得了成功；有的人對自己的現狀很滿意，就一直在一家公司一個崗位上幹了很多年；還有一部分人被炒魷魚了。基於作者自己的所見所聞所想，於是列出了下面的能夠幫助程式設計師在工作崗位上取得成功的建議。（以下是編譯內容）

　　1. 大膽的提出問題

　　有些新的程式設計師在進入公司的第一天很猶豫是否要去向別人尋求幫助，比如：當程式設計師在專案環境設定上遇到問題或者是他們不明白這個專案的商業流程的時候，他們很猶豫，不知道該不該問出這個問題。其實這都不是什麼大的問題——儘管尋求幫助，或是向別人澄清一下你的想法。否則的話將會在和專案有關的問題上糾結、浪費時間。

　　還有一種情況就是，當領導讓你自己提出根本沒有任何限制的問題的時候，很多程式設計師對自己的口才很吝嗇。千萬不要害怕問問題，尤其是在大的環境下。

　　2. 找準自己的定位

　　在很多專案或者專案模組裡缺少資源，這就意味著在你開始工作的時候或是完成目前專案的時候要讓你的領導知道你的偏好專案和執行能力。許多人常常是喜歡加入一個新的有特色的專案，而有的人喜歡加入一個有熟人的開發團隊。

　　不過，最明智的選擇是挑選一個沒有多少同行的開發者知道的專案，只有你一個人在這方面擅長。只不過在剛開始的時候需要花大量的時間去了解熟悉它的運作模式和現有的程式碼；當一切事項都已掌握之後，就可以向管理層自我推薦，領先於別人，就是超越了自己。

　　3. 熟悉App的“藍圖”

　　現如今大多數的企業App都是比較複雜的，使用不同的技術完成的模組來組成的。作者展示了他現在的工作就是由3個部分組成的：

• 一個和社交網路和收集資料互動的模組。
• 一個處理收集的所有資料的模組。
• 一個UI模組。

　　每一個模組都是由不同的開發者團隊開發並操控的。這些模組在技術上沒有什麼聯絡，但是在商業流程上是相互聯絡的，也就是說，無論什麼時候想要引入一個新的功能的時候，都會影響到這3個模組。

　　事實上並沒有多少人理解整個App的商業流程，當討論一個新功能的時候，經理常常會要求在行的人對軟體程式的更改最初最好的評估，評估結果可能會用在每一個模組裡。所以如果你這道這個App藍圖的話，你就能參與到這個討論中。

　　4. 做你需要做的事，而不是做你喜歡的事

　　一些非常有才能的程式設計師經常會遇到很嚴重的問題——他們有自己的特別之處或者說是感興趣的方向，一旦被要求去做其他的不一樣的事情的時候，能力和做事質量就下降了。因為他們不能集中注意力在不感興趣的事情上，這是很致命的短板。你如說：人們可能想要測試Scala，但必須先處理Hibernate或原生SQL；他們可能想要併發性，但是必須要協助與前端開發相關的工作。

　　如果你需要長期處理你自己根本不擅長的技術問題/工作，那麼你最好換工作。否則如果你是臨時幫助別人處理你不擅長的問題，最好表現的專業一點，把事情做好。

　　5. 善於分享，樂於幫助

　　估計很少有人單槍匹馬的情況下還能有很高的產量吧，這隻能暗示在交流上的貧乏。自私是團隊合作的最大障礙，最後也只能是整個團隊停滯不前的結果。這樣的“孤狼”也基本上得不到團隊的信任。

　　此外，如果你在一個區域辦事處工作，而你的同事沒有把任務做好，你最好去幫助他，因為團隊榮譽至關重要，這也是一個雙贏的決策。

　　6. 儘量給出現實的評估

　　給出太樂觀的評估對於程式設計師來說是比較困難的，作者站在自己的立場給出兩大主要原因：

　　A. 我們經常忽略將要花費的時間：

• 在實施階段處理預料之外的問題。
• 在開發環境上測試實現的功能。
• 編寫單元測試和整合測試。
• 分散時間和精力到其他高優先順序任務上。

　　B. 有時在給出真正的評估之後會讓我們覺得不舒服，因為經理看到這樣的評估之後表情會很嚇人。在這種情況下，我們通常會把特點劃分成幾個子任務，以至於總的評估看起來不是那麼可怕。

　　太樂觀的評估在大多數情況下會有悲慘的結局：

　　你必須把任務移到QA在一個buggy狀態下，通過思考來證明它：“通常QA會返回所有開發功能列表的備註資料給開發人員，所以我仍然會有機會解決所有的bug”。但是在現實的評估條件下情況就不會是這個樣子了。

　　7. 測試，測試，再測試！

　　許多程式設計師因為錯誤評估而被迫轉入QA環節，有些程式設計師在交貨期來臨之前停止了任務，轉入測試階段，只是想證明他們的高效能。當然了，這是一個好的意圖，但是並不似所有的掉頭檢查都能帶來好的結果。總之，中途檢查要比從頭開始好得多。

　　再次強調一下單元測試和整合測試的重要性。它們是迴歸分析的第一個指標：一個打破現有功能的機會。不幸的是,有些人編寫測試只有一個目的——避免漏掉程式碼覆蓋率而帶來的責任。這樣的程式碼在程式碼審查過程中需要被捕獲並拒絕，這是提高程式碼質量的另一個好方法。

　　8. 記住：誰都會犯錯誤的。

　　有誰希望和一個出現bug就喜歡批評別人的的人一起工作呢？估計沒人願意，但事實是我們大多數人看起來就是那個樣子，只是自己沒意識到。下面列舉了一些避免出現這些狀況的建議：

　　如果你和同事一起構建一些功能，而他有稍微慢了一些，與其去責怪他還不如去幫助他，至少應該到經理那去爭取更多的時間。既然需要共同的按時交付產品，那麼兩個人對這項功能的完成都是有責任的。

　　當你修復了一個bug或者是發現了一個bug，即使你知道是誰的緣故導致這些bug的出現，也沒必要通過網路電話渠道讓公司裡的每個人都知道這件事。犯錯誤是在所難免的，有的時候你會遇到“ugly code”模組，同上，不需要讓更多的人知道它的製造者。

　　如果你對一個同事有什麼不好的意見，都沒必要向你的上級反映，除非上級向你詢問。首先你要確保你的上級是一個開明人士——知曉他所管理的團隊裡隊員的強項和弱項，這樣才能處理好隊員之間需求。

　　恰恰相反，我們應該經量多的向大家包括領導反映同事做的一些好事。比如，數週之前我的一個同事在早上7點鐘的時候臨時駕車到公司來試執行App模組，所以他應該得到大家的讚美之詞。

　　9. 在社交網站上宣傳公司的強項。

　　現如今，基本上每個程式設計師都在使用社交工具。你可以關注朋友們的公司，也可以在網上介紹自己所在公司，不管是好事還是壞事，都可以在網上貼出來：有的時候會組織技術峰會、贊助商會議、商業論壇、釋出會、尋找新的開發者等等，社交工具對於一個程式設計師來說是有很大的用處的。除此之外，有很多的網站上都有公司人員對公司的評論，任何人都可以寫，當然，只要是你喜歡的內容，沒必要撒謊。

　　在國外，想要和公司CTO或者是CEO進行交流的最簡單的方式是通過Twitter，在國內可使用的交流工具也是各種各樣啊！

　　10. 小建議和小技巧。

　　接下來的是一些能夠讓你獲得領導或者同事的讚美的建議和技巧：

　　A. 適應老闆的時區

　　許多來自歐洲和印度的程式設計師都是從美國那邊接受發自總部的指令的。在這種情況下，如果程式設計師能夠在晚上的時間段和美國總部進行交流討論工作上的事情，肯定比在下午5點鐘下班時候和總部進行交流所獲得的工作效率要高得多。

　　B. 如果有需要，任何時候都要幫助公司做事。

　　身邊的例子：公司的生產系統需要全天候的監視著，因為任何時候都有可能出現問題。通常情況下是區域的程式設計師參與監視，但是去年的新年假期期間我們被要求留下來值班，我被安排在大年三十那天，我本來可以要求調整一下的，但是我服從了公司的安排，很幸運，那一晚上基本上沒什麼問題出現，我在一個很正常的環境下度過了我的新年，但是至少公司知道我隨時願意為公司付出。

　　C. 在公司的指引下參加應聘面試

　　如果你有機會以面試官的身份參加面試，一定要好好利用這一機會，因為這是無價的經驗。首先，這能發揮出你的口才能力，很多程式設計師都缺乏這樣的技能。其次，你可以認真聽一聽別的面試官（你的同事）都問了哪些問題。最後，你對求職者的觀點將會納入參考範圍，這關乎到這個應聘者最後能不能加入到這個公司裡。

　　原文： DZone