本文首發自「慕課網」，想了解更多IT幹貨内容，程式員圈内熱聞，歡迎關注！
善戰者，無赫赫之功。
這句話的字面意思是說，總是輕松打勝仗的将軍，别人就會覺得他沒有多少功勞。
那對于一個程式員來說，按部就班的完成需求，算不算一種成績？
悲觀地說，可能并不算。
不出bug的程式員是好程式員嗎？
前不久，有個大廠離職員工發了個文章。
他說，自己寫代碼戰戰兢兢，充分測試，聯調順利，是以也很少加班，也沒有多少問題單需要處理。
可這樣做的後果就是在公司根本沒有存在感，考評的時候，高績效反而給了那些天天加班處理問題的。
他所在的公司，考評體系是将代碼量和績效挂鈎的，是以周圍的程式員都把代碼寫得臃腫無比、難以維護。
而這個程式員自己，則因為無法适應這種文化，被處處排擠，最終離職。
這就是個很典型的“善戰者無赫赫之功”的例子。
為了避免過于平庸，在這個團隊中，可能有非常多的程式員都在有意無意的用這種蠢方式寫代碼。
因為隻有通過這種看起來很蠢的方式，他們才能實作：
- 提高本人對于項目組的重要性，因為現在隻有他本人看得懂這套代碼，别人一動就會出bug
- 給上司留下一個奮鬥者形象，天天加班寫代碼、改bug，感覺全項目組的問題都是他在處理
這太不合理了，事情為什麼會變成這樣？
問題的關鍵在于考核。
該如何考核程式員？
不同于其他崗位，如市場崗位可以根據銷售額去定績效，産品崗位可以根據關鍵名額去評判，但技術崗好像用什麼次元都不太完美。
用工作量考核？
上文就是個典型的例子，如果一個程式員能輕松處理每一個任務，短短幾行代碼就能完成一個超級複雜的需求，每天到點下班，那麼在老闆看來，他很有可能是工作不飽和。
相反，那些代碼臃腫，每天加班改bug的程式員，雖然技術水準欠佳，但老闆卻很滿意。
技術水準高，和技術水準看起來高，是兩碼事，是以單純用代碼量考核，并不合理。
那，用業務效果評判？
一般來說，程式員隻負責處理産品經理提出的需求。
而業務方向、實作形式都是産品經理決定的，而程式員能做的就是保質保量地還原方案，保障穩定性，好像和“業務效果”也沒有太多關系？
用人工評判呢？
各大公司派系林立，管理者任人唯親的不在少數，辦公室政治也普遍存在。
程式員很多是醉心于技術，不善于表達的類型，也許能力很強，但人緣卻處理不好，在人工評判中就非常劣勢，反而是一些善于搞關系、強于彙報的人能夠上位。
缺乏一個合理的考核标準，就不能準确界定每個程式員的貢獻。
這也是很多優秀的程式員遲遲難以晉升的原因。
程式員要如何突出自己的價值？
在脈脈上，一個人分享了他是如何将一個老前端問得啞口無言的。
其實，這個老前端被問住，不是因為他本身的問題，更多是崗位本身的屬性如此。
程式員一般不參與業務決策，僅僅是完成需求，也不需要額外做什麼。
長此以往，做彙報的時候就很吃虧。
而且還原需求這件事，你能做，别人也能做，甚至一些基礎的任務，一個剛畢業的大學生經過教育訓練都能做。
在業務普遍增長，招聘需求遍地的時期，這類程式員還算穩定。
但在招聘需求越來越收窄，各大業務線都在裁員縮招的當下，突出個人價值這件事，就突然變得非常緊要了！
我足夠優秀嗎？
我是否比身邊的人更強？
如果裁員真的發生，我是被保留的，還是被淘汰的？
這些問題，都要重新去考慮。
上面說到，技術水準高，和技術水準看起來高，是兩碼事。
那技術水準高的人，如何讓自己的技術水準同樣“看起來高”呢？
肯定不至于用上面說的“蠢辦法”去寫代碼，因為這是病态的。
我的建議是，從現在開始，有意識的進行“自我增值”。
這個增值，指的是在完成本質工作之餘，主動優化流程，充分疊代，也可以是造更好的輪子，引入新架構等等。
例如，對需求進行分析後，不是簡單利用模闆，而是引入一套效率更高，功能更強的架構，來提升功能的體驗。
或者，通過借鑒一些業内的優秀案例，對現有項目的架構進行優化。
這樣，既能給業務帶來增長，也能充實自己的履曆。
你個人的地位，在公司也會更加牢固。
當然，有人會說，公司的業務已經非常穩定了，可創新的角度有限，陳年老架構也沒有優化的空間，這種時候又該怎麼辦呢？
這種時候，我們要從兩個角度去看——
業務真的是沒有優化空間，還是以你現在的水準，壓根沒法做到在這個基礎上進行優化？
如果是前者，那麼恭喜你，你所處的項目已經非常成功，這本身就是你履曆上值得大書特書的閃光點！
如果是後者，那麼可能先提升自我的技術水準，是目前最需要做的事。
不論是用何種方式，在當下這個大環境下，去思考如何更好的為“自我增值”，是每個程式員都無法逃避的話題。
寒冬已至，我們每個人都要思考如何活下來。
歡迎關注「慕課網」，發現更多IT圈優質内容，分享幹貨知識，幫助你成為更好的程式員！