分享我的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的角色）
写到这里大致就这样了，再说下去应该是和开发无关的话题了，应该下次还会再说说！
