一个安卓小项目（5）——总结与感想

  项目再小，只要不是一个人去做，就涉及到带领人的问题，如果这个问题不处理好，再小的项目都会变得艰难难行。
  这个项目太小了，只是个“监听软件”而已，且用到的都是android的上层API。界面不需要，只是几个Service而已。但是对于从来没有接触过android开发的我们来说，确实学到了不少东西。

  项目的具体分工，在真正的写代码之前就已经分好。做为负责人，我一开始想同意代码风格，这样不管之后谁来读，都相对容易一些。并且把模块都需要的方法都做成接口或是集成。这样在别分写代码的时候，就可以分别取实现不同的功能。并且可以采用同一个工程，只是写的模块不同而已。或许我有更好的办法，只是我不知道而已。所以才这么想。在我的想象中一个APK，分成不同的模块，不同的人去完成，模块之间尽量减少耦合，形成高内聚低耦合。而然我对此的软件工程的知识只知道皮毛而已，在实际操作中根本达不到想象的那样。所以，还是我太过天真了。 

 第一，统一代码风格，一开始我只是说了写代码应该遵循的几点，代码中尽量不要出现非0，和1 的数字，其他的数字可以定义为常量，打日志用到的TAG也要统一作为常量，等。尽量用面向对象的方法来写，不要写出的代码像下面条一样。（我对面向对象的了解也不是很透彻）。现实就是命名方式不统一，代码都是堆在一起。这虽然是个小的不能再小的项目了，可是也要有一定的规范。我试着去解决这个问题，但是始终没有解决好。要么说了，还是按照自己的套路写，要么坚持认为自己的代码风格很好。执行力完全没有，我说那么做，非说那么做不好。都觉得自己的就是对的。其中，我的做法也有些欠佳，一是我没有足够的理论基础，

二是我语言说的有点过激，可能让别人认为我在指责他。

 

 第二，分模块，这个是我的理论基础不足。我并没有提供一个可行的框架。所以每个模块写的时候，测试的时候，都是自己新建一个工程，针对自己的写的做测试，确认没有问题了然后我把几个模块的代码合在一起，合代码的时候也是极为痛苦的。各种水土不服，各种修改，各种沟通，各种吵，都说自己写的没有问题，那么都是我合代码有问题。 在不到5天的时间里，我们终于完成了。这中间，我们争吵很多，但是并没有伤和气。没有争吵就没有进步吧。收获还是很多的。只是每个人都有自己的看法，从而导致了执行力不强。

而我也看到了我的各种缺点：
   1、喜欢把自己的想法强加给别人
   2、说话不讲究方式方法，导致别人接受不了
   3、作为领导者，并没有估计到团队成员的感受
   4、理论知识的严重缺乏，想法很多，就是实现不了
 我针对这些缺点，会尽快做出改变。
 经过这个小项目，不仅学习了技术，更是学会了如何为人处世！