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

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

這些是建議不是教條，請依據情況進行調整。

實現和加強編碼風格指南

Ruby 是一門富有表現力的語言。有了這種表現力，就會有一百萬種風格的代碼來完成任務。統一這些風格有助于統一一個代碼庫，使其更容易地理解并更愉快地在其中工作。使用 rubocop 可以實現這一點。Rubocop 具有可讓你調整和細化為你的喜好的預定義風格。不過現在討論的不是你的編碼風格，而是整個代碼庫風格的統一性。

但是你現在的項目代碼風格十分雜亂?Rubocop 可以忽略已存在的違反風格指南的地方，讓你隨時修復。如果你愿意，它甚至會嘗試修復違反風格指南的代碼風格。

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

盡早收集性能指標

你可能已經在其他地方讀過或者聽過這句話：

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

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

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

避免耗費大的數據庫查詢

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

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

做有效的提交

我們都會在提交信息時犯以下錯誤：缺乏幫助的消息、或者有錯誤的代碼、或者提交中有一個調試器調用。畢竟人都會犯錯。

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

樹立零停機遷移意識

不可避免地你將需要更改代碼，改變數據庫的結構。這些變更可能會導致你的應用在遷移時運行鎖數據庫的命令，從而導致宕機。

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

編寫全棧測試代碼

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

 

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

 

標簽： 代碼 開發(fā)者 數據庫

版權申明：本站文章部分自網絡，如有侵權，請聯系：west999com@outlook.com
特別注意：本站所有轉載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權歸原作者所有，如需使用，請與原作者聯系。