作為乙個android菜鳥，跟著老大做android專案，從立項到上線，從架構到實現，從懵懂到掌握，在這裡我總結一下在此專案中和收穫、遇到的問題和解決辦法
1、首先乙個專案最重要的兩個點就是需求和架構。需求搞不懂做的再多也是枉然，架構沒設計好，之後遇到問題想改會遇到很多問題會牽扯到很多東西。需求和架構這兩點沒搞精通以後修改問題都是整個專案級別的。
2、需求要看實際專案來定，一般產品都會理解的比較通透。在做專案的工程中，需求改變是經常的事兒，產品經常會給你提新的問題新的設計。因為產品可能聽boss一嘴聽總監一語，然後新的設計就來了。這時候我們碼農再接受更好的設計的同時，我更建議並不是什麼都要聽產品的，因為經常因產品提的一點點的小細節需求，我們的**結構就會被影響，影響**的一致性和通讀性，這兒做點特殊處理那兒做點特殊處理，一點點一點點我們的**就會被腐蝕，失去整體的一致性和規範性，閱讀起來就會非常反感。在這裡我更建議在一開始產品或者架構師就設計好我們的邏輯規範等等，到時候我們也會有據可循，而且這些都一致了之後，使用者也會習慣這種設計，也不會影響使用者的使用體驗。為了使用者體驗更棒一點，偶爾的特殊處理也不會特影響**的結構。
3、架構設計一定要低耦合。整個專案的模組可以大致分為以下幾個：
資料層：用來儲存各種資料的資料結構的定義。
通用控制項層：一些常用的自定義的控制項，提出來方便之後的復用
第三方sdk：引入的第三方sdk
utilities工具層：用到的一些工具類似的方法，把他們都放到這裡。這是一種將不相關**統一管理的一種方法，不會將一些和業務邏輯不相關的**寫到某個activity或fragment中。而且，這也是一種積累，以後找工具類直接去裡面拿就可以了。
5、兩個提高點：第一，所有的資料請求不管是否是訪問網路的請求，都統一使用非同步方法來請求和設定資料。第二，業務邏輯與許可權判斷分離。我們之前可以通過乙個accountaction來統一處理許可權的判斷和截斷，但是這也只能做到在入口處進行檢驗，而登入進去之後，token失效，這時候再操作應該讓其重新登入的，而這種處理就不容易實現，而且超級麻煩。現在使用aop面向切面程式設計的思想，使用aspectj向**中注入切點，攔截請求，判斷許可權，就能比較輕鬆的實現業務邏輯與許可權判斷分離。當然在實際的實現中也會遇到一些問題，結合技術文件和我們的程式設計經驗和現有的技術一定是可以解決掉問題的。
專案管理心得
做專案，和做其他任何事情一樣，對於我們面前的專案，在行業認知上我們多少都是無知的，不過我們可以根據經驗，用這世界乙個相同的東西 相似性 去分析它，細化它，抽象出來，一層一層，一塊一塊的實現出來。所以在我們的專案團隊中，我認為以下幾個原則非常重要 1，先慢後快。團隊的合作往往是磨合再磨合的合作在用，在...
部署專案心得
最近幾天在部署乙個專案，碰到了一些問題，同時也產生了一些心得體會，所以記錄下來。我部署的專案說不難其實也挺難的，模組比較多，一共8個模組。系統方面涉及到jdk版本的問題，涉及到動態庫的問題，涉及到凝思系統的問題，涉及到tcp和http連線的問題。當然最後邊的東西就不在我的範圍之內了。專案部署方面遇到...
專案管教心得
產品通過定時迭代版本來新增和優化功能，乙個產品 版本或功能都是乙個個內部專案，如何在乙個確定的有限的時間段內，準時高效地交付高質量產品，就顯得格外重要。大部分的公司沒有內部專案經理，產品經理算是研發團隊中最懂管理的人，並且是產品 owner，所以責無旁貸的需要負責內部專案管理的職責。如果乙個產品經理...