你是在正在建立一個坑仍是在擴建一個坑？

　　這周的工做終於告一段落，費神的一週啊。在歷史功能上開發新功能，歷史代碼還有bug。開發過程當中心情至關的糾結。還好，最後仍是把它拿下了，邏輯還算清晰，可是就是代碼太多了，這個提醒咱們，在編碼規則中必須加一條，一個方法的代碼不能超過多少行代碼，每行代碼不能超過多少字，每一個類不能超過多少個方法。

　　其實你們都知道，做爲具體業務開發，不少狀況是根據業務，通常就不會作過多結構和代碼優化的考慮。一切主要爲具體的功能服務，這樣的思路對於小模塊或者說邏輯不是不少功能需求來講，彷佛並無什麼錯；可是久而久之，你就會發現，以這種思路作出來的功能，到最後總有幾個坑留在整個項目中。不動它固然沒有什麼問題，可是一旦要在這個基礎上作擴展，就像在原來坑的基礎上作更大更深的坑同樣，一發不可收拾。因此，咱們在作代碼規範的時候，必須作一些必要的限制和控制。這樣控制能夠解決方法過大，單行代碼過多，代碼瀏覽不方便。還能有意思的提醒咱們的業務開發者，在遇到普通或複雜業務邏輯都必須做結構上的優化，該封裝的要封裝，該靈活控制的要靈活控制。這樣才能讓咱們在整個項目將來的發展和功能的修改升級時駕輕就熟，收放自如。

　　在我遇到的開發中遇到比較多的都是流程性的功能會出現方法過大，加之在開發過程當中做爲開發者的咱們一般是以慣性思惟來解決問題，因此方法過大就會成爲必然。因此在開發之初也要考慮將來的發展，這一思路也是必不可少的。作必要的封裝解耦，把不變的業務邏輯分析出來封裝，把容易變的邏輯分析出來解耦，這樣在作擴展的時候，就能夠駕輕就熟，沒必要糾結，不管是開發測試，仍是從公司開發成原本說，均可以省一筆不小的數目。

　　單行代碼過多，能開的比較多的通常是針對一個對象的方法的多層調用。你們通常的習慣是放在一行處理，若是分開又要新聲明變量來接收而後調用後續的方法。其實大可沒必要這麼麻煩，如今的編輯器和編譯器是支持換行的，你只須要在合適的地方換行就ok。勁量讓全部代碼在一屏和主視線能接收的範圍內以方便瀏覽，在這個過程當中能夠容許經過屏蔽下滑瀏覽其他代碼。若是你寫的代碼又要讓代碼橫向滑動又要縱向滑動才能看完，這該是多麼痛苦的一件事情，你以爲呢？