摘要： 又做完了一个项目，经验教训不少。决定写一批文章，作总结，反思，及分享之用。先作写作大纲，然后逐渐成文：二、系统设计篇接口，分层，重构 【接口篇】分层重构三、Android开发布局篇ViewStyleR文件及id四、Andorid开发功能篇ServiceThreadAsyncTaskNetDalJNI 阅读全文

摘要： 不分层的坏处，写过那种超过万行代码的项目的人，应该都很有体会。而且，这个世界本来就是分层的，不同的层负责解决不同的问题。分层后，层可以换，当然层中的功能可以共用。在手机客户端开时，我的经验是：以包为单位，可以分为如下几个包：网络请求，数据库读写，业务逻辑，后台服务，前台UI，公用函数及配置网络请求，主要是按与服务端协商的接口，写一个负责统一收发数据的类。以后所有与网络相关数据收发的工作，都有该类完成。数据库读写,即数据层，负责数据持久化业务逻辑，负责格式化数据，即将业务数据按业务需求处理好之后，写入数据库。或将数据库中的数据读出后，格式化之后用于UI呈现后台服务，指Android的servic 阅读全文

摘要： 大型项目，我没参与过，所以暂时没见过大牛们是怎么干活的。做中小型的项目，我还参与或主主持过几个。借这次项目总结，给大家分享一下。文章主题就是标题的三个词：接口，分层，重构接口：此处的接口，主要是指服务端与客户端的交互时使用的接口。1.接口的制定，需要侧向于以满足客户端为中心。理由：1>客户端在用户手中，升级麻烦，而且每次升级必然存在用户流失2>客户端功能应尽可能简单，减少出现BUG的机会2.接口数据结构制定，有三种选择：自定义，Json，Soap自定义：好处：在以前做Symbian平台时用过，主要是为了节省用户流量。问题：当数据交互种类多，参数及返回值复杂之后，维护起来相当麻烦。而 阅读全文

摘要： 混乱的管理 之 角色错位 作为做技术的人，最痛苦的莫过于，一个项目，连目标用户都没有确定，连大体需求都没有确定，就直接被通知要做出什么东西出来。开发人员的，在项目组织里面，是最”底层”的。市场的那一步被略过了，产品需求的那一步也跳过了，直接说我们要做XX，接着所有的问题都集中在了开发身上。做XX是什么意思？要实现哪些功能？。。。。。 结果写代码的，被弄去写文档；搞系统设计的被弄去写产品需求文档；而搞需求的，被弄去搞战略或目标，而其本身没有决策的权，所以也就干脆就只做老板的复读机！ 所有人都在为被人揩屁股，做着自己所不擅长的事，项目不出问题才怪。 战略清楚的老板+定位明确市场+需求明确的... 阅读全文