“你們進(jìn)行同行評(píng)審嗎？”

同行評(píng)審，或者讓別人看看你的代碼再把它放進(jìn)代碼庫(kù)，這是識(shí)別愚蠢錯(cuò)誤的辦法，同時(shí)也是開(kāi)始你的職業(yè)生涯時(shí)一個(gè)關(guān)鍵的培訓(xùn)機(jī)會(huì)。

危險(xiǎn)信號(hào)：“我們相互信任！”→很有可能那些開(kāi)發(fā)者對(duì)自己的代碼非常警惕不想給人看也不擅長(zhǎng)接受反饋。

　　“你們的繼續(xù)教育計(jì)劃是什么樣的？”

作為一名軟件工程師意味著當(dāng)新技術(shù)出現(xiàn)、成熟并以令人眼花繚亂的速度走向過(guò)時(shí)的時(shí)候要不斷學(xué)習(xí)。因此，很多公司都有培訓(xùn)預(yù)算用來(lái)買(mǎi)大學(xué)和在線課程、會(huì)議或者內(nèi)部交流。

危險(xiǎn)信號(hào)：“你是說(shuō)在閑暇時(shí)間讀讀網(wǎng)上的東西？” →這家公司要么資金緊張，要么把開(kāi)發(fā)者視為可替代的，而不是長(zhǎng)期投資。

b) 出差。

我本人上有老、下有小，不愿經(jīng)常出差。不過(guò)我知道很多人喜歡出差。所以無(wú)論喜不喜歡出差，問(wèn)一問(wèn)還是有好處的。這條算做企業(yè)文化，有些勉強(qiáng)，但也沒(méi)別的更好的地方歸類(lèi)。暫且放這吧。

c) 考勤。

工作十幾年，絕大部分時(shí)間沒(méi)打卡上過(guò)班。所以事先問(wèn)清楚考勤制度，心理上好做個(gè)準(zhǔn)備。這條跟企業(yè)文化還是有很大關(guān)系的。本人還是喜歡彈性工作制。

d) 培訓(xùn)。

企業(yè)是不是給員工提供不同形式、內(nèi)容的培訓(xùn)能看出這個(gè)企業(yè)是不是以人為本，給員工提供職業(yè)發(fā)展的路徑和機(jī)會(huì)，而不是只會(huì)一味地使喚人。

e) 團(tuán)隊(duì)建設(shè)。

我原來(lái)的公司會(huì)經(jīng)常搞一些團(tuán)隊(duì)建設(shè)活動(dòng)。比如：Team Lunch、郊游、拓展、年會(huì)等等。這也是企業(yè)文化的一種表現(xiàn)。只知道讓我埋頭苦干的企業(yè)，我想不是我理想中的企業(yè)。

f) 同事關(guān)系。

此問(wèn)題一般得到的都是正面的回答。所以問(wèn)不問(wèn)都行。但是至少在試用期里要關(guān)注這件事情。在團(tuán)結(jié)和融洽的團(tuán)隊(duì)內(nèi)工作，心情會(huì)很不錯(cuò)。

快進(jìn)5個(gè)月……

該系統(tǒng)開(kāi)始經(jīng)歷許多關(guān)于維護(hù)CRUD操作完整性的問(wèn)題。設(shè)計(jì)用來(lái)處理事務(wù)的瘦應(yīng)用程序邏輯層已經(jīng)不再那么薄了。升級(jí)和向后兼容性的故事開(kāi)始變得更加復(fù)雜。

由于受到許多其他問(wèn)題的困擾，工程師們又回到了繪圖板——這次是用Azure SQL替換存儲(chǔ)層！我不記得具體的細(xì)節(jié)，但是這個(gè)改變?cè)黾恿舜蠹s40%的額外時(shí)間和成本。

管理層很不高興，這個(gè)項(xiàng)目幾乎掉了。但是團(tuán)隊(duì)的工程師們非常好，他們能夠完成這個(gè)項(xiàng)目，盡管有了一些延遲和初的錯(cuò)誤的技術(shù)決定。

這個(gè)項(xiàng)目有一個(gè)圓滿的結(jié)局——但它也可能不是這樣的。事實(shí)上，很多內(nèi)部項(xiàng)目都被關(guān)閉了，因?yàn)樗麄儾荒茉诔兄Z的日期范圍內(nèi)交付承諾的功能。

那么，您如何知道NoSQL解決方案適合您的下一個(gè)軟件項(xiàng)目呢？首先問(wèn)問(wèn)你自己和你的團(tuán)隊(duì)這十個(gè)問(wèn)題：

您的數(shù)據(jù)事務(wù)是基于什么？或者，您需要什么級(jí)別的事務(wù)支持？如果您的系統(tǒng)需要ACID屬性，那么您很好還是堅(jiān)持使用RDBMS解決方案。否則，您將花費(fèi)大量的時(shí)間試圖在您的應(yīng)用程序/業(yè)務(wù)邏輯層重制ACID保證，并且您可能仍然沒(méi)有RDBMS解決方案那么。#3: 您需要Web/高可伸縮性嗎？總是在先計(jì)算出您需要什么樣的可伸縮性。比如說(shuō)一個(gè)類(lèi)里面有5個(gè)接口，那么我的限流插件就應(yīng)該能針對(duì)每一個(gè)接口就行不同的限流方案。在這個(gè)特殊的例子中，我們正在為微軟內(nèi)部游戲工作室構(gòu)建系統(tǒng)。有10到15個(gè)游戲工作室正在考慮中——這取決于有多少注冊(cè)用戶使用這個(gè)系統(tǒng)每個(gè)工作室多有3-5個(gè)活躍的游戲標(biāo)題。每個(gè)游戲標(biāo)題為三個(gè)環(huán)境存儲(chǔ)遙測(cè)模式——開(kāi)發(fā)、預(yù)生產(chǎn)（PPE）和生產(chǎn)對(duì)于每個(gè)標(biāo)題，將會(huì)有2-5個(gè)數(shù)據(jù)科學(xué)家同時(shí)修改游戲標(biāo)題數(shù)據(jù)每一個(gè)標(biāo)題事件都有大約50 KB的max事件數(shù)據(jù)我們被要求存儲(chǔ)所有的版本——我們估計(jì)這個(gè)數(shù)字是1000除以一個(gè)標(biāo)題的生命周期有了以上粗略的估計(jì)，我們就可以計(jì)算并發(fā)性和存儲(chǔ)需求：

總并發(fā)數(shù) = 工作室數(shù)量 * 標(biāo)題數(shù)量每工作室 * 用戶數(shù)量每標(biāo)題

=  15 * 5 * 5 = 375 并發(fā)用戶

大存儲(chǔ) =  工作室數(shù)量 * 標(biāo)題數(shù)量每工作室 * 環(huán)境數(shù)量 * 事件存儲(chǔ)大小每版本* 需要存儲(chǔ)的版本數(shù)

= 15 * 5 * 3 * 50 KB * 1000 = 11250000 KB = 11.25 GB大存儲(chǔ)

SQL Azure支持1024個(gè)并發(fā)打開(kāi)連接，并且能夠很容易地支持并發(fā)需求。另外，在考慮云計(jì)算時(shí)，11.25 GB實(shí)際上是一個(gè)非常小的數(shù)字。

這個(gè)系統(tǒng)并不是下一個(gè)FaceBook或必應(yīng)——那么NoSQL的路線真的值得嗎？