分享我的iOS app 开发杂谈3

　　想写这东西很久了，之前因为真的事很多，几乎没有办法去思考问题，工作也不顺。

　　不顺的原因是，总觉得自己和这个team不合。

　　前几天CEO和每个IOS的engineer都说了话（感觉好阴险的样子），然后我也有一句说一句。但是，还是没有放开来说，我把这个归咎为中国式教育的恶果：不敢发表自己的意见（or总是埋藏自己的意见）。

　　在谈话结束后我就有点不甘了，因为这么好的机会，可以充分表达自己意见的机会，就这样放弃了。真心觉得机会是“稍纵即逝”的，也对自己说了，以后在合适的场合一定要展现自己！

　　好了，说完这些，其实，我感受最深的是在这个team中的冲突太多了。我之前有工作经验，所以接触过的软件组织都是非常之有“套路”，从来没有像在这个team里面所见到的那些问题的啊。。。

　　分点说：

　　1、文件组织混乱。

　　我记得现代IDE组织文件(source code,resource等)文件的方式是用一个config文件来对文件进行“索引”（可能我描述得不够好，有点像linux上的连接），所以有时候在ide工程中的文件目录树是和电脑上的文件目录树不一样的（physical path），我真心觉得这样不好，原因有如下：

　　a.你不能迅速定位那个文件到底在哪。(也就是说必须通过ide)

　　b.难以理清编译时到底在做什么（因为IDE帮了你一些“忙”）

　　所以，解决这个问题其实很简单，就是将IDE上的工程目录树组织得和文件目录树是一样的。

　　这个应该是基本需求了，不论是什么开发都应该这样的，良好的文件组织可以解决和避免很多潜在问题和未知问题。

　　深层次一点的讨论，其实就是我希望大家可以放一下IDE，虽然这可以提高效率，但是想想很久很久以前……那时的程序不是还是用emacs,vi写的吗……

---

 

　　2、【架构】组织混乱。

　　说起了【架构】，感觉好牛B的样子，抱歉了，因为我想不到什么字来形容，不妨看一下这段我要说的问题，也帮忙选一个好的词啊。（感觉架构这个词不知道什么时候起给用“烂”了……）

　　.Net技术方向的朋友一定不会陌生“三层架构”，说的就是MVC在.Net源代码下的文件组织方法（这句话不对，求纠正，其实我想表达的意思就是MVC是一个抽象概念，实际的文件组织是其“实例化”的产物……），说到这不知道会不会给口水吐死啊，但是还是要说的就是，三层架构组织起来如下图：

　　

　　M = Model

　　V = UI

　　C = BLL （DAL也可以加到这）

　　这样就好理解了，这个组织方法为的就是要“解耦”，模块化的编程好处就是可以做到精细地分工，让每个进来的人都可以找到自己的方向，找到自己的擅长，找到自己的信仰(这句纯粹吹水，不要喷)。大意就是互相工作，互不干扰。当开发完成的时候，“粘合”非常容易，冲突非常少（各自在自己的模块工作，又怎么会有冲突呢……），这样就相当于效率提高了啊。目前我工作的项目没有这样的组织架构，所以每个人都是自己写自己的模块，从UI-logic-data，都是自己完成，这样会怎样呢？列出如下：

　　a.BUG只能author修。如果其他人修的话意见很大，因为既然要问author，又要插自己的想法，我了个去的！

　　b.改进只能author改。bar,bar,bar...如上。

　　其实根本就不用列出会怎样，因为所有的怎样都是没有解耦所带来的问题而已。

　　解决方法：重新组织啊。

　　在IOS的开发组织中，我见到有朋友这样做：

　　就假设用户模块来说，这个模块有4大功能。

　　1、login

　　2、register

　　3、forget password

　　4、logout

　　好，这样在IOS中怎么组织文件呢？

　　UserManager.m

　　这个文件就是Bussines logic layer + Model （在.h文件中可以写一个model class嘛）

　　UserManager.m的内容就可以分别写四个方法对应四个功能了。

　　UserProtocol.m

　　这个文件相当于Data access layer，用来屏蔽database。(在IOS中应该多数是从server中请求数据，但是又要做缓存本地(sqlite)，这样可以屏蔽数据源到底是什么)。

　　这个文件还有一个功能，就是如果是从网络请求的数据，可以做数据校验（在父类中写一个检验方法即可）。

　　View就不说了，设计说怎样就怎样。

　　当然，要说一下这几个文件的调用关系：

　　UI ---->Manager --> Protocol

　　数据流向关系

　　UI <----Notification(Model)----Manager  <---(JSON,...)-Protocol

　　好了。说到这应该差不多了。

---

 

　　三、人员调度结构不合理

　　这里应该是和团队建设有关的。

　　只说我们IOS team，我们现在有5个人，以前的做法是大家“互相融洽”，工作的思路是跟随PD（Product Directer），PD没有编程属性，只有设计师属性。(完全不懂编程)，PD调度各种业务需求，控制软件的功能。我认为PD的工作很重心是对的，但是错误在Dev team不应该跟随PD的思路去develop（这个句子有误解，请再看解释）。现在的做法是PD去“找”那些“有空”的engineer去做功能，这真的是个大悲剧啊，我对UI层是没有兴趣的，每次PD来找我要功能我都会死在UI细节上，我了个去，直接造成PD对我的开发能力的怀疑……

　　至于我，我也就很苦逼的在修改界面细节啊。于是就进入到那个很苦逼的死loop了：

　　我不擅改界面--->界面没做好---->继续改界面---->我不擅改界面......

　　我也被技术总监叼了，我晕，我委屈！所以就造成整个dev team都对我的开发能力表示怀疑，所以在这压力好大！

　　如果说到这，就不难找出解决问题的关键了，那就是缺少一个中层领导。这是我的一位组员犀利地给我分析的（他才进公司a week）。这是非常对的，应该有一个team leader来保护我们这些可怜的engineer啊！

　　幸好，高层都不是傻B，连我这种混混都能注意的问题，他们肯定早就知道了吧。

　　解决方法：找team leader！

　　问题又来了，上面的解决方法我用了一个“找”字。目前只想到两种方法“找”：

　　1、招聘

　　中层领导怎么招聘啊，这种起承转合的角色实在是无法通过招聘这种补牢的方式来完成的。所以我也赞同我的那位组员所说，只能从team中提拔。毕竟，再招聘进来至少也要一个季度才能适应吧，那时间太长了。

　　2、内部提拔

　　这应该是最合适，合理的方法了。这个方法的一个难点就是在于，dev team里面有没有管理型的engineer，因为这种人实在是少啊。（PS：这里说一下，微软应该是有一个职位叫叫PM，但是他不是Product Manager,而是Program Manager，我想应该就是这个team leader的角色）

---

 　　写到这里大致就这样了，再说下去应该是和开发无关的话题了，应该下次还会再说说！