大多數貼士和技巧，對於開發人員的重點是知識、經驗或溝通技巧。雖說這些肯定是有用的因素，但是它們對於學習者能有效地執行還是太過抽象了。
成為乙個更好的開發者沒有捷徑，但是這裡一些實踐和工具將肯定會有幫助。這裡我將會分享一些東西來提公升**和產品，也提公升開發者的水平。
這些是建議不是教條，請依據情況進行調整。
實現和加強編碼風格指南
ruby 是一門富有表現力的語言。有了這種表現力，就會有一百萬種風格的**來完成任務。統一這些風格有助於統一乙個**庫，使其更容易地理解並更愉快地在其中工作。使用 rubocop 可以實現這一點。rubocop 具有可讓你調整和細化為你的喜好的預定義風格。不過現在討論的不是你的編碼風格，而是整個**庫風格的統一性。
但是你現在的專案**風格十分雜亂?rubocop 可以忽略已存在的違反風格指南的地方，讓你隨時修復。如果你願意，它甚至會嘗試修復違反風格指南的**風格。
加強**風格在個人和團隊專案上是非常具有挑戰性的。使用自動化工具強制執行這些風格，例如 guard-rubocop, codeclimate, hound 等，以防止提交錯誤風格的**。為避免**被汙染，可以使用像 reek 這樣的工具。
盡早收集效能指標
你可能已經在其他地方讀過或者聽過這句話：
「在大約 97% 的時間裡，我們應該無須關心效率問題：過早的優化是所有**的根源。」— donald knuth
這句話被引用了很多次，是個好的謀生建議。優化的時間通常是沒什麼警告的，所以當那一刻到來時，最好能很好地了解當下的情況。當效能成為問題時，已經有了的這些資訊是非常有用的，而不是試圖在迫在眉睫的時候才收集它。
使用 librato 和 skylight 等檢出工具來收集產品的效能指標。另外，請參閱這個優秀的 gem rack-min-profiler，用於每個請求的效能指標。
避免耗費大的資料庫查詢
如果說過早的優化是不幸的根源，那麼對效能差勁的**的無知與其有著緊密的關係。當編寫 rails **時，通常會出現這樣的情況：思考不足、未使用或使用代價昂貴的資料庫查詢。
做有效的提交
我們都會在提交資訊時犯以下錯誤：缺乏幫助的訊息、或者有錯誤的**、或者提交中有乙個偵錯程式呼叫。畢竟人都會犯錯。
利用 git 的 pre-commit 鉤子來分析改動並提交訊息，以確保它們能夠達到標準。從驗證你的提交資訊是有意義的開始，為了確保你的方案變動存在於你剛編寫的遷移中，驗證你的**是遵循你編碼風格指南的。檢出可配置的工具，如 pre-commit (ruby)、pre-commit (framework)，或自己實現乙個!
樹立零停機遷移意識
不可避免地你將需要更改**，改變資料庫的結構。這些變更可能會導致你的應用在遷移時執行鎖資料庫的命令，從而導致宕機。
雖然你的應用沒有在執行關鍵的任務，宕機也可以接受。但考慮到當需要在上次維護之後的第二天進行架構更改時，樹立零停機意識，並養成習慣，這對你將會有所幫助。檢視 這些優秀的指南，學習該怎麼做。
編寫全棧測試**
你在寫測試**，對吧?單元測試非常適用於識別重大的改進，但驗證所有的改動是否能正確地一起執行能讓你更踏實。全棧測試會驗證模型、控制器、檢視和前端**是否正好與使用者期望的一致。capybara 可讓你針對真正的瀏覽器(如 chrome 或 firefox)或無介面(headless browsers)瀏覽器(如 phantomjs)執行測試。
開發者的效率目標
在實際開發過程中，往往存在兩種截然相反的行為傾向 以時間換效率 以效率換時間 這兩種行為模式，在固定一天時間內，達到同樣的生產力，可以靠低效率 堆時間的方式，和另一種高效率，節省時間的方式。大多數人都知道提高效率，但是，提高效率是目的，是手段，如果僅僅知道提高效率，還是沒找到落腳點。從大的方面，可以...
效率低下的原因 開發者說
1 老大給我分類了任務，這個是新需求，我只了解這個需求的大概，不了解這個需求的細緻業務邏輯是什麼，2 老大對需求進行了分析，可是我精力有限，光記住了記住了跟我相關的需求，其他的需求沒有太了解，到時候再去說吧。3 我好像之前開發過這樣的 我去找找在 唉，浪費了半天時間才找到。4 我找到了之前做的 可以...
如何成為「10倍效率」開發者
the rise of developeronomics中提到了 10倍效率的開發者 10x developer 的概念 偉大的開發者的效率往往比一般的開發者高很多，而不只是一點點 adam loving在讀了之後受到啟發，並向多位大牛 ben sharpe collin watson和jonath...