不經歷這一遭，永遠不會明白爲啥要遵循這些規範
命名規範
基礎的駝峯或者其他，相信不用多說，重點在於，平時以爲沒必要的
xml中屬性順序
在第一個版本開發的時候，往往不會注意這些，寫的順序會比較混亂，畢竟複製黏貼不少，甚至有些width和height還有id放到最下面去了。
但是重構的時候，或者說第二個版本開發的時候，想要快速理解代碼，這裏就增加了很多難度，有時候要找是否有居中，間距多少，要查看半天
so, 這裏建議，按順序寫，首先寫id，然後寬高，然後相對位置，然後間距，再然後其他
xml中每個控件的用途註釋
這裏有利於理解代碼，特別是對於英語不好的同學，每次要去看id命名，然後腦子裏要把英文轉爲中文，如果有個地方相似id有幾個，那看得更加頭疼。
文件名
儘量以model+function的形式命名，或者其他，而且一旦約定，最好就要遵循，這樣看起來會非常的舒服
資源名
在第一版開發的時候，爲了偷懶，經常在xml中直接引用公用的資源，例如default_blug_color,可是後續改版中，一旦項目風格改變，那麼，就只能在對應的xml中去修改，所以建議：在color中將對應需要使用的顏色聲明出來，然後引用default_blug_color，這樣，便於查看和修改
正式改版開發的約定
命名
有時候你不能更改原文件，一是爲了方便對照，二是不引起其他地方報錯，比如有寫activity需要intent各種傳值，接受值，如果，沒有做好容錯處理，很容易nullPointException
建議約定，新版本的都命名爲在文件末尾添加一標識例如“_new”或者“_temp”
而且，在變量中儘量不要使用包含以上的命名，這樣就可以寫一個腳本，通過遍歷的方式來修改，而不是手動修改，but，資源文件中，有可能存在_new
的變量，所以，在寫這個腳本的時候，務必排除這些有可能有類似變量的文件，至於修改之後發生的錯誤，運行一遍，一目瞭然，再慢慢修改，我認爲這樣比重複勞動n次所造成的勞累要小很多。(當然，不同類型的人，不一樣)
不過，在這之前，如果代碼結構有變化，建議先把原有的文件移動到對應模塊下，這樣新建的文件和舊的文件，會排列在一起，便於查看
功能模塊
最好是邊界清晰，方便複用
暫時想到這麼多，先這樣吧
