Businesspeople dig numbers. They don’t necessarily want to hear that you got something done; they want to hear how much you got done—especially relative to past results or some other relevant benchmark—and they want to know the value of what you did.

商人關(guān)注的是量化，他們想從你哪里通道你做了什么，帶來(lái)了什么價(jià)值，而不是你做了多少。

Some professionals have it easy when it comes to quantifying their job performance. Salespeople can measure their achievements in dollars and cents, for example, and many other fields also have clear-cut numbers with which to calculate their contributions.

教授可以輕松地量化出他們的工作，銷售人員可以計(jì)算出他們的收益。其他的領(lǐng)域也可以通過(guò)一些方式算出他們的貢獻(xiàn)。

For software developers and some other technology-based roles, however, quantifying your work can be a struggle without a straightforward solution. Yet doing so is crucial not just in job searches, but in many aspects of a software engineer’s career: performance reviews, effectively communicating up the chain of command, working efficiently with non-technical business units, and ensuring you’re properly valued within your organization.

但是從事軟件開(kāi)發(fā)以及技術(shù)相關(guān)的人員，量化工作確實(shí)一個(gè)困難的事情。量化這件事情，不是在求職，更是一個(gè)技術(shù)人員生涯的一部分。績(jī)效評(píng)估，有效的了解溝通，高效的和非技術(shù)人員合作，確保你再團(tuán)隊(duì)或組織中的價(jià)值。

So how do you measure the value of the applications you build, scale, monitor, test, and otherwise support? Here are some of the approaches used at New Relic, as well as industry best practices:

但是我們要如何量化工作中的價(jià)值呢？這里有一些 New Relic 推薦的做法：

“I like to see work accomplishments described in terms of situation, action and results,” says Merilee Krebs, a technical recruiter at New Relic. “What was the business or technical problem to be solved? What unique actions did you take to resolve them and what was the resulting improvement.”

New Relic 的技術(shù)招聘人員這樣說(shuō)："我喜歡看到用情況，行動(dòng)和結(jié)果去描述工作成果，技術(shù)人員需要解決的問(wèn)題是什么？采用什么樣的行動(dòng)去解決和提升這個(gè)問(wèn)題。"

What does that look like in the real world? Try asking yourself some pointed questions: Did your monitoring and testing lead to a code update that cut down on help desk tickets by X percent? That’s quantitative gold right there. Did you deliver a new app six weeks ahead of schedule? Yeah, you’ll want to brag about that (in a professional manner, of course). Can you connect your code to strategic company objectives? Please, do so. Are you doing something that’s outperforming the traditional standards in your industry? You should be able to quantify the achievement is some way.

現(xiàn)實(shí)世界中是怎樣的呢？你試著問(wèn)自己一些關(guān)鍵的問(wèn)題：你有在更新你的代碼的時(shí)候去監(jiān)控和測(cè)試...這就是量化的目標(biāo)。如果你在日程表前六周就完成了一個(gè) app，你肯定會(huì)去炫耀一下。但是你有考慮公司的戰(zhàn)略目標(biāo)嗎，如果沒(méi)有，請(qǐng)思考一下。...

If this exercise feels unnatural to you, you’re not alone—many programmers often aren’t born sales and marketing pros. If they were, they’d probably work in sales or marketing. So let’s consider six ways to better measure and communicate the value of your code and related work.

你是不是感受到一些不同的感覺(jué)，這不是你一個(gè)人的問(wèn)題，技術(shù)人員的通病。如果技術(shù)人員做好了量化這一塊，那么他們也許就去從事銷售了。所以，讓我們考慮六種去量化你代碼以及工作的方式：

Think in percentages
Get involved with open source projects
Measure progress, not just products
Keep a work journal
Communicate in two languages
Collect recommendations

參考資料

6 Ways to Quantify Your Code—and Why You Need to Do It

程序員必備的代碼審查（Code Review）清單

在我們關(guān)于高效代碼審查的博文中，我們建議使用一個(gè)檢查清單。在代碼審查中，檢查清單是一個(gè)非常好的工具——它們保證了審查可以在你的團(tuán)隊(duì)中始終如一的進(jìn)行。它們也是一種保證常見(jiàn)問(wèn)題能夠被發(fā)現(xiàn)并被解決的便利方式。

軟件工程學(xué)院的研究表明，程序員們會(huì)犯15-20種常見(jiàn)的錯(cuò)誤。所以，通過(guò)把這些錯(cuò)誤加入到檢查清單當(dāng)中，你可以確保不論什么時(shí)候，只要這些錯(cuò)誤發(fā)生了，你就能發(fā)現(xiàn)它們，并且可以幫助你杜絕這些錯(cuò)誤。

為了幫助你開(kāi)始創(chuàng)建一個(gè)清單，這里列出了一些典型的內(nèi)容：代碼審查清單。

常規(guī)項(xiàng)

代碼能夠工作么？它有沒(méi)有實(shí)現(xiàn)預(yù)期的功能，邏輯是否正確等。
所有的代碼是否簡(jiǎn)單易懂？
代碼符合你所遵循的編程規(guī)范么？這通常包括大括號(hào)的位置，變量名和函數(shù)名，行的長(zhǎng)度，縮進(jìn)，格式和注釋。
是否存在多余的或是重復(fù)的代碼？
代碼是否盡可能的模塊化了？
是否有可以被替換的全局變量？
是否有被注釋掉的代碼？
循環(huán)是否設(shè)置了長(zhǎng)度和正確的終止條件？
是否有可以被庫(kù)函數(shù)替代的代碼？
是否有可以刪除的日志或調(diào)試代碼？

安全

所有的數(shù)據(jù)輸入是否都進(jìn)行了檢查（檢測(cè)正確的類型，長(zhǎng)度，格式和范圍）并且進(jìn)行了編碼？
在哪里使用了第三方工具，返回的錯(cuò)誤是否被捕獲？
輸出的值是否進(jìn)行了檢查并且編碼？
無(wú)效的參數(shù)值是否能夠處理？

文檔

是否有注釋，并且描述了代碼的意圖？
所有的函數(shù)都有注釋嗎？
對(duì)非常規(guī)行為和邊界情況處理是否有描述？
第三方庫(kù)的使用和函數(shù)是否有文檔？
數(shù)據(jù)結(jié)構(gòu)和計(jì)量單位是否進(jìn)行了解釋？
是否有未完成的代碼？如果是的話，是不是應(yīng)該移除，或者用合適的標(biāo)記進(jìn)行標(biāo)記比如‘TODO’？

測(cè)試

代碼是否可以測(cè)試？比如，不要添加太多的或是隱藏的依賴關(guān)系，不能夠初始化對(duì)象，測(cè)試框架可以使用方法等。
是否存在測(cè)試，它們是否可以被理解？比如，至少達(dá)到你滿意的代碼覆蓋(code coverage)。
單元測(cè)試是否真正的測(cè)試了代碼是否可以完成預(yù)期的功能？
是否檢查了數(shù)組的“越界“錯(cuò)誤？
是否有可以被已經(jīng)存在的API所替代的測(cè)試代碼？

總結(jié)

你同樣需要把特定語(yǔ)言中有可能引起錯(cuò)誤的問(wèn)題添加到清單中。

這個(gè)清單故意沒(méi)有詳盡的列出所有可能會(huì)發(fā)生的錯(cuò)誤。你不希望你的清單是這樣的，太長(zhǎng)了以至于從來(lái)沒(méi)人會(huì)去用它。僅僅包含常見(jiàn)的問(wèn)題會(huì)比較好。

優(yōu)化你的清單

把使用清單作為你的起點(diǎn)，針對(duì)特定的使用案例，你需要對(duì)其進(jìn)行優(yōu)化。一個(gè)比較棒的方式就是讓你的團(tuán)隊(duì)記錄下那些在代碼審查過(guò)程中臨時(shí)發(fā)現(xiàn)的問(wèn)題，有了這些數(shù)據(jù)，你就能夠確定你的團(tuán)隊(duì)常犯的錯(cuò)誤，然后你就可以量身定制一個(gè)審查清單。確保你刪除了那些沒(méi)有出現(xiàn)過(guò)的錯(cuò)誤。（你也可以保留那些出現(xiàn)概率很小，但是非常關(guān)鍵的項(xiàng)目，比如安全相關(guān)的問(wèn)題）。

得到認(rèn)可并且保持更新

基本規(guī)則是，清單上的任何條目都必須明確，而且，如果可能的話，對(duì)于一些條目你可以對(duì)其進(jìn)行二元判定。這樣可以防止判斷的不一致。和你的團(tuán)隊(duì)分享這份清單并且讓他們認(rèn)同你清單的內(nèi)容是個(gè)好主意。同樣的，要定期檢查你的清單，以確保各條目仍然是有意義的。

有了一個(gè)好的清單，可以提高你在代碼審查過(guò)程中發(fā)現(xiàn)的缺陷個(gè)數(shù)。這可以幫助你提高代碼標(biāo)準(zhǔn)，避免質(zhì)量參差不齊的代碼審查。