這個項目太小了，只是個“監聽軟件”而已，且用到的都是android的上層API。界面不需要，只是幾個Service而已。但是對於從來沒有接觸過android開發的我們來說，確實學到了不少東西。
項目的具體分工，在真正的寫代碼之前就已經分好。做爲負責人，我一開始想同意代碼風格，這樣不管之後誰來讀，都相對容易一些。並且把模塊都需要的方法都做成接口或是集成。這樣在別分寫代碼的時候，就可以分別取實現不同的功能。並且可以採用同一個工程，只是寫的模塊不同而已。或許我有更好的辦法，只是我不知道而已。所以才這麼想。在我的想象中一個APK，分成不同的模塊，不同的人去完成，模塊之間儘量減少耦合，形成高內聚低耦合。而然我對此的軟件工程的知識只知道皮毛而已，在實際操作中根本達不到想象的那樣。所以，還是我太過天真了。
第一，統一代碼風格，一開始我只是說了寫代碼應該遵循的幾點，代碼中儘量不要出現非0，和1 的數字，其他的數字可以定義爲常量，打日誌用到的TAG也要統一作爲常量，等。儘量用面向對象的方法來寫，不要寫出的代碼像下面條一樣。（我對面向對象的瞭解也不是很透徹）。現實就是命名方式不統一，代碼都是堆在一起。這雖然是個小的不能再小的項目了，可是也要有一定的規範。我試着去解決這個問題，但是始終沒有解決好。要麼說了，還是按照自己的套路寫，要麼堅持認爲自己的代碼風格很好。執行力完全沒有，我說那麼做，非說那麼做不好。都覺得自己的就是對的。其中，我的做法也有些欠佳，一是我沒有足夠的理論基礎，
二是我語言說的有點過激，可能讓別人認爲我在指責他。
第二，分模塊，這個是我的理論基礎不足。我並沒有提供一個可行的框架。所以每個模塊寫的時候，測試的時候，都是自己新建一個工程，針對自己的寫的做測試，確認沒有問題了然後我把幾個模塊的代碼合在一起，合代碼的時候也是極爲痛苦的。各種水土不服，各種修改，各種溝通，各種吵，都說自己寫的沒有問題，那麼都是我合代碼有問題。 在不到5天的時間裏，我們終於完成了。這中間，我們爭吵很多，但是並沒有傷和氣。沒有爭吵就沒有進步吧。收穫還是很多的。只是每個人都有自己的看法，從而導致了執行力不強。
而我也看到了我的各種缺點：1、喜歡把自己的想法強加給別人
2、說話不講究方式方法，導致別人接受不了
3、作爲領導者，並沒有估計到團隊成員的感受
4、理論知識的嚴重缺乏，想法很多，就是實現不了
我針對這些缺點，會盡快做出改變。
經過這個小項目，不僅學習了技術，更是學會了如何爲人處世！