最近公司的主要产品做改进，我的partner是从baidu跳槽过来的一个小伙。当初介绍给人事和技术主管的时候，评价是：人很聪明，比较谦恭，code经验丰富，理论知识虽有欠缺，但可塑性良好。工作3个月后，小伙确实不负众望，学习也很快，我也为之欢欣。考虑到之前小伙javascritp架构方面欠缺较大的锻炼，故而这次该产品的架构工作给他锻炼，我跟随。
开头第一周，该小伙实现了很多关键的函数方法，充分表现出极强的code能力，这样大家都很happy。第二周开始，小伙每天下班总是很迟走，架构提供的公用方法开始出现各种不一致、各个模块交叉引用（强耦合），导致业务实现的逻辑相当复杂。“乱”，RTX（公司内部IM）上小伙给我发了句。我感觉到问题的严重性。于是第二周周五快下班时候和小伙商量“能否暂时让我接手做一下架构的整理，先把2个小功能上线了，回头你要乐意再扔给你”，小伙同意了。我以为就此没事，于是第三周我花了三天时间放心地大刀阔斧，边做架构、边做业务实现，做了一些重要的剖离调整。这样一来，小伙那边也要做很多的代码修改，小伙有点不明白了，RTX经常发来“你这样老是变来变去，我总是跟着你变来变去”。我的主要改进是四点：
1，方法的一致性改进（到现在仍然有不少地方不一致，但相对提高了很多）；
2，重要公用逻辑，重复逻辑的剖离、封装；
3，模块（Namespace）之间的交叉引用改为单向引用，由强耦合变为弱耦合；
4，将一个小的换肤模块升级到通用模块（这个只是想法，处于时间因素代码上并未完美完善，还好并未造成使用上的麻烦）；
“变动肯定是要有的，大的思想没问题，只是小的细节上重构”，我不断的反复给小伙讲这个理由，并且针对每一个他临时提出的疑问给以解答，但我仍然忽略了他“修改代码”的懊恼心情。所以到最后上升到他对我的“人身评价”阶段了^^：“你太固执”、“你太强势”。做为年纪稍大的“兄长”，我只能提醒他：“只谈事”、“你看看哪些地方没法下手，我们先解决了”。我的策略是“针对当前问题做解法，莫谈太远”。然后小伙又提出自己的架构构想，认为这块代码应该放在那，那块应该放在这。结果两个人在这上面讨论了很久，虽然我有足够的理由解释为什么这么做，但是开发进度停滞不前。我认为当初商量好了，两个人各自分工，而且我改进后的架构确实也能实现各种功能，为啥一定要在这个关键时刻纠缠呢（因为还有四个工作日就要阶段性交付了）。当时我就感觉这是对彼此工作是否支持的问题了。
周五上班的时候，我因为要带小孩打H1N1预防针上午没去公司，期间小伙拉上产品经理和开发经理把牢骚和各种疑问发了一通，不知为啥后来产品经理在RTX群里面影射我搞“个人英雄主义”（微笑了之，不了情况嘛，情有可原）。但这充分让我认识到问题的严重性。
周五下午我去公司后，开发经理、产品经理、我和小伙四个人开了个会。会上小伙提到了五点疑问，这五点疑问都一一解决了（其中有两点不是问题，他自己想通的）。然后小伙找到很多细节上的小问题（非结构性问题）指出来，以证明他的正确和我的疏忽，我当然会根据经验、对这种迫切需要肯定的情况表示赞扬，RTX上连发一系列大拇指，并道歉说自己疏忽，“当时未考虑到这些细节问题”（我也确实很难短短几天内考虑各种细枝末节，只能尽量保证结构没问题）。
小伙说现在的架构“抽象得不痛不痒，还不如不做”，其实我并未做多大的抽象，只是做了之前所述四点调整，这种调整思路的前三点（架构的原则），是经过人类软件工程几十年千锤百炼的验证，我感觉有经验的程序员/架构师是不应反对的。
小伙认为模块间的解耦可以通过让javascript实现oop的“继承”来解决。解耦本质上需要解除彼此的牵连（引用)。我认为javascript模拟oop来写程序，现有的JS引擎下，执行效率可能不会特别高，而且javascript纯oop会影响生产力。但也未否认小伙的观点，所以跟他说有机会实践一下。求同存异还是必须的。
小伙觉得my.baidu.com那种六千多行的js裸奔，什么规则都没有的，namespace也没有的编码很值得推崇，并说“尽信书不如无书”，认为我们的javascript没有必要搞那么多namespace。对于这种想法，我在RTX上说：“嗯，条条大道通罗马”。希望公司有机会让他实践下“于多人合作开发复杂项目”时采用这种思想。
为了找到我们开发迟缓和沟通断层的原因所在，所以下午的讨论会上，我请更年长的开发经理谈谈建议，他直觉的发现了问题的根源：“你可能需要更多地听一下他（小伙）的意见和建议，考虑他的感受，不然沟通上会有矛盾，碰到其他人也会有矛盾，会让他们带着一种博弈的心理和你沟通”。
成员确实是优秀的，人是优秀的人，沟通的问题，很微妙。
本周五稍晚我和开发经理又聊到了传统开发(RUP)和敏捷开发。我需要敏捷起来，我们的团队需要敏捷起来。(未完待续)