大多數(shù)貼士和技巧，對(duì)于開發(fā)人員的重點(diǎn)是知識(shí)、經(jīng)驗(yàn)或溝通技巧。雖說這些肯定是有用的因素，但是它們對(duì)于學(xué)習(xí)者能有效地執(zhí)行還是太過抽象了。

成為一個(gè)更好的開發(fā)者沒有捷徑，但是這里一些實(shí)踐和工具將肯定會(huì)有幫助。這里我將會(huì)分享一些東西來提升代碼和產(chǎn)品，也提升開發(fā)者的水平。

這些是建議不是教條，請(qǐng)依據(jù)情況進(jìn)行調(diào)整。

實(shí)現(xiàn)和加強(qiáng)編碼風(fēng)格指南

Ruby 是一門富有表現(xiàn)力的語言。有了這種表現(xiàn)力，就會(huì)有一百萬種風(fēng)格的代碼來完成任務(wù)。統(tǒng)一這些風(fēng)格有助于統(tǒng)一一個(gè)代碼庫，使其更容易地理解并更愉快地在其中工作。使用 rubocop 可以實(shí)現(xiàn)這一點(diǎn)。Rubocop 具有可讓你調(diào)整和細(xì)化為你的喜好的預(yù)定義風(fēng)格。不過現(xiàn)在討論的不是你的編碼風(fēng)格，而是整個(gè)代碼庫風(fēng)格的統(tǒng)一性。

但是你現(xiàn)在的項(xiàng)目代碼風(fēng)格十分雜亂?Rubocop 可以忽略已存在的違反風(fēng)格指南的地方，讓你隨時(shí)修復(fù)。如果你愿意，它甚至?xí)�嘗試修復(fù)違反風(fēng)格指南的代碼風(fēng)格。

加強(qiáng)代碼風(fēng)格在個(gè)人和團(tuán)隊(duì)項(xiàng)目上是非常具有挑戰(zhàn)性的。使用自動(dòng)化工具強(qiáng)制執(zhí)行這些風(fēng)格，例如 guard-rubocop, CodeClimate, Hound 等，以防止提交錯(cuò)誤風(fēng)格的代碼。為避免代碼被污染，可以使用像 reek 這樣的工具。

盡早收集性能指標(biāo)

你可能已經(jīng)在其他地方讀過或者聽過這句話：

“在大約 97% 的時(shí)間里，我們應(yīng)該無須關(guān)心效率問題：過早的優(yōu)化是所有邪惡的根源�！薄� Donald Knuth

這句話被引用了很多次，是個(gè)好的謀生建議。優(yōu)化的時(shí)間通常是沒什么警告的，所以當(dāng)那一刻到來時(shí)，最好能很好地了解當(dāng)下的情況。當(dāng)性能成為問題時(shí)，已經(jīng)有了的這些信息是非常有用的，而不是試圖在迫在眉睫的時(shí)候才收集它。

使用 Librato 和 Skylight 等檢出工具來收集產(chǎn)品的性能指標(biāo)。另外，請(qǐng)參閱這個(gè)優(yōu)秀的 gem rack-min-profiler，用于每個(gè)請(qǐng)求的性能指標(biāo)。

避免耗費(fèi)大的數(shù)據(jù)庫查詢

如果說過早的優(yōu)化是不幸的根源，那么對(duì)性能差勁的代碼的無知與其有著緊密的關(guān)系。當(dāng)編寫 Rails 代碼時(shí)，通常會(huì)出現(xiàn)這樣的情況：思考不足、未使用或使用代價(jià)昂貴的數(shù)據(jù)庫查詢。

Rails 的性能對(duì)于大多數(shù) webapp 來說，通常是 “足夠快的”。差的性能通常被歸咎于 N+1 查詢導(dǎo)致的數(shù)據(jù)庫的數(shù)據(jù)多次往返。大多數(shù)性能監(jiān)測工具都能識(shí)別這些問題，不過我們應(yīng)該從一開始就避免它們。在開發(fā)中識(shí)別和消除這些問題可以使用優(yōu)秀的 bullet gem。它會(huì)分析你的頁面，當(dāng)你加載的數(shù)據(jù)沒有被使用或者有機(jī)會(huì)消除 N+1 查詢時(shí)，它就會(huì)告訴你。

做有效的提交

我們都會(huì)在提交信息時(shí)犯以下錯(cuò)誤：缺乏幫助的消息、或者有錯(cuò)誤的代碼、或者提交中有一個(gè)調(diào)試器調(diào)用。畢竟人都會(huì)犯錯(cuò)。

利用 git 的 pre-commit 鉤子來分析改動(dòng)并提交消息，以確保它們能夠達(dá)到標(biāo)準(zhǔn)。從驗(yàn)證你的提交信息是有意義的開始，為了確保你的方案變動(dòng)存在于你剛編寫的遷移中，驗(yàn)證你的代碼是遵循你編碼風(fēng)格指南的。檢出可配置的工具，如 pre-commit (ruby)、pre-commit (framework)，或自己實(shí)現(xiàn)一個(gè)!

樹立零停機(jī)遷移意識(shí)

不可避免地你將需要更改代碼，改變數(shù)據(jù)庫的結(jié)構(gòu)。這些變更可能會(huì)導(dǎo)致你的應(yīng)用在遷移時(shí)運(yùn)行鎖數(shù)據(jù)庫的命令，從而導(dǎo)致宕機(jī)。

雖然你的應(yīng)用沒有在執(zhí)行關(guān)鍵的任務(wù)，宕機(jī)也可以接受。但考慮到當(dāng)需要在上次維護(hù)之后的第二天進(jìn)行架構(gòu)更改時(shí)，樹立零停機(jī)意識(shí)，并養(yǎng)成習(xí)慣，這對(duì)你將會(huì)有所幫助。查看 這些優(yōu)秀的指南，學(xué)習(xí)該怎么做。

編寫全棧測試代碼

你在寫測試代碼，對(duì)吧?單元測試非常適用于識(shí)別重大的改進(jìn)，但驗(yàn)證所有的改動(dòng)是否能正確地一起運(yùn)行能讓你更踏實(shí)。全棧測試會(huì)驗(yàn)證模型、控制器、視圖和前端代碼是否正好與用戶期望的一致。Capybara 可讓你針對(duì)真正的瀏覽器(如 Chrome 或 Firefox)或無界面(headless browsers)瀏覽器(如 PhantomJS)運(yùn)行測試。

 

來自：http://developer.51cto.com/art/201704/538287.htm

 

標(biāo)簽： 代碼 開發(fā)者 數(shù)據(jù)庫

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請(qǐng)聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點(diǎn)！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請(qǐng)與原作者聯(lián)系。