关于商家后台v3.0项目的一些思考
商家后台v3.0项目从立项到今天一个多月的时间，一个月的时间要用新技术（nodejs+angularjs+bootstrap）重构一个类似于淘宝商家后台的项目；最终目的是重新梳理功能模块，减少页面刷新，减少用户操作成本，优化页面视觉效果，增加商家中心可持续维护性。
必须感谢每一个参与到这个项目中的协作伙伴：尤其是四个主力军，这种创业似的工作激情在这两年多的工作经历中从来没有遇到过；还有很给力的五个QAmm，甚至还有怀着身孕帮忙测试。
虽然项目并没有能按预期在14号前全流量上线，但是项目过程中体现的正能量让整个团队凝聚力更强，待上线的v3.0版也也让接下来的工作充满期待。而且在此期间的不少经验也难能可贵，必须记录下来。
1月3和4号花了两天的时间做了商家后台的设计初稿，第二天跟大家确认的时候从每个人眼神可以看出来更多的是惊喜。紧接着就是与设计和产品沟通细节，确认新版设计在基本UI规范和功能层面不会有任何问题。
此前一周，其他确认三位其中的两位协伙正再抓紧时间处理手头正在进行的任务（但事实上零碎的项目是永无止尽的，所以前期在准备工作中遇到不少问题）。本周同时进行的还有确认了技术选型（angular+angular-ui），所有的开发介入进来，在angular-ui的bootstrap项目的基础上，根据商家中心的业务订制自己的交互组件。
第二周是非常关键的一周，开始在现有的底层nodejs架构（hornbill）的基础上，构建适用于angularjs的项目脚手架。并且出一个初步的DEMO，和代码规范。同时准备一个适用于angularjs和传统类似于sea.js的wrapper，以防备重构成本太大的页面的整体UI风格与新版保持一致（后来证明这个兼容方案起到了非常实用的角色）。
另外一个很重要的工作就是风险评估，例如，新版但页面web应用上线之后，之前的nodejs模板引擎报错监控就失效了；还有URL修改成由客户端JS通过URL中的hash控制路由的方式之后，之前通过URL控制用户权限的也会有失效的风险。
第三周所有的开发（前端）介入，正式着手开发。正式重构的功能仅限于之前多次沟通确认下来的高优先级页面。
第四周周末开始加班，并根据当前进度评估后续项目总体成本，并实时调整计划。第五周的周四提测，周末加班配合QA测试，也就是现在的状态。
项目过程中很有多可圈可点的地方，例如：项目准备期间考虑到了不少“坑”，避免了正式开发中会影响项目进度的风险。当然也有很多问题，开发时间压缩太少根本没有时间太注意细节，导致提测后发现不少功能性细节问题。
下面简单列出一些在整个过程中的一些一闪而过的思考：如果这么做，如果站在那个角度去评估，今后能不能再做成那样……引以为鉴。
1、不要让外界的无关因素干扰自己的思路，但是也不能完全专注于项目本身，而使得无关因素被无限放大；反其之成为最大的累赘。
在最近两周除了这个项目还有一个非常头疼的事情，租房。
本来这两个完全不相关的事情可以完全不用掺和的，但是因为在一个月前很简单地认为：要把所有精力放在这个项目，其他无关紧要的事情尽可能不要占用自己的时间和精力，这样会更专注。这本来也是自己做时间管理的一个思路，但是从上周到现在那些“无关紧要”的事情慢慢地，然后突然变的至关重要：房子快要到期，本来可能准备续租的室友因为特殊原因不再续租，加上房东各种琐事，决定重新找房子落脚。这样一来，本来认为可以续租了事的简单事情变得没那么容易。
如果之前稍微放一点心思在房子上，跟每个人沟通清楚，早作打算也就是一个周末就可以搞定的续租还是重新租事情；足足拖了一周。
2、提前计划好自己的生活和惯常行为，不能因为项目而使身边的人受到冷落
这是一个很容易被“工作狂”忽视的问题；比如本来原本每周五下班跟家人通一次电话，突然有一个周五不再打电话了，必定会让自己对工作的专注转变为家人的挂念和担心。
第二天还要极力跟家人解释这周都在忙什么，为什么这么幸苦，能不能休息得好，让他们不要担心等等；如果能提前告之，事实上是更能获得家人的支持和理解，会顺心很多。
3、紧急项目开发中如果遇到问题，是探讨式的去寻找解决思路，还是尽量独立思考，避免一个问题占用更多人的时间：独立思考与团队协作发散思维的矛盾。
在第一周项目开发过程中遇到不少这样的问题，比如在设计网页中表格的过程中，因为新版的UI设计中优化了表格的布局，表格框没有那么单一，开发成本变得更高了，还有一些表格的border的浏览器兼容性遇到些问题。然后大家就开始聚集起来讨论这个问题的解决方案，每个人都有自己的解决思路，脑洞大开，启发很多。但事实上讨论差不多十来分钟下来，谁都说服不不了谁。
类似的场景很多很多，但事实上这样的讨论最大的问题就是：一个问题如果由四个人同时来讨论的话，就会浪费三个人的时间；如果是在有充裕时间的常规项目中，完全没有问题：第一可以扩展团队中每一个角色解决问题的思路，另外可以找到最优的解决方案，同时其他人在做其他项目中就会很顺利的解决问题，还有就是使团队氛围更活跃。但是在敏捷开发过程中这样的问题就是浪费时间的罪魁祸首。最后的解决办法是：每个人负责独立的子模块，把这样的问题留给一个人去解决，并且如果时间允许的话，写好通用文档和DEMO，并且在讨论组里通知大家更新代码即可。
所以敏捷项目的开发过程中，需要尽可能避免技术层面的发散思维，同时高效沟通（文档+DEMO+群消息通知），避免问题被重复讨论浪费大量时间。
4、做好合理的项目规划：先列出大纲，然后规划模块，最后反复斟酌细节，把每一个节点形成文档；同时也要灵活应对项目中的变更；立刻做出更合理的规划。
项目准备期间思考的最大的问题是：是在现有的类sea.js的框架下做优化，还是使用angularjs；如果使用angularjs，是在在现有的底层架构上做优化，以满足angularjs的构建需求，还是放弃当前的架构，完全重构。对这个问题反复跟前端高工室友聊过，如果要使用成熟的解决方案必定需要放弃现在的架构。但事实上自己需要的是现成解决方案的思路而已，所以最后确认的方案是，确认使用angularjs，同时在现有的架构上升级，使现有的hornbill兼容两种模式。
在这个基础选型确认之后紧接着引申而来的各种未知的成本，我们拆分为：整体页面功能梳理，确认需要重构的页面优先级、技术架构调研（angular版本，UI库的选用）、需要独立订制UI组件list等（注：这部分工作感谢 @艳明）。这些拆分仅限于把所有能想到的问题罗列出来，具体开发工作需要继续分配。这样由浅入深，很合理地规划了项目整体所需要的成本；这个过程每个人都通过短会的形式参与进来，项目整体思路在每个人心里就清晰很多。
即便是很合理的规划，在正式开发中也会遇到很多问题：例如，在第三周重构高优先级的页面的之前，我们根据需要重构的页面数大致评估，按每人每天全人力投入是每周需要开发15个页面（事实上这对一个相当成熟的angularjs程序员来说，在现有基础上重构都是不太可能的）。事实上在第三周开发的时候就发现，这是根本不可能再年前开发完成的；所以立刻转变思路，我们的计划从80%页面重构变成了仅仅表格页面用angular重写，其他页面套壳优化细节面包屑，按钮和字体样式即可（这时候之前写的兼容性wrapper组件就起到了相当大的作用）。
5、在敏捷开发过程中保证细节
其实每个经历过敏捷开发的工程师都知道，敏捷开发过程中是很难保证每个功能和样式细致入微的。一般这种情况下，都是都过敏捷开发，高效迭代的方式。但是对于这种UI重构，必须要保障在第一版上线就能保证每一个交互比老版本更贴心，至少细节样式和功能不能出任何问题。但是如果要求每一个人都做到如此，那这项重构将会是基本不可能完成的任务。
所以在真正开发过程中，只需要让一个人专门去梳理细节样式，而其他的开发只需要保证自己的功能基本可用，不用在意细节。事实上这也类似于。
6、协调和调动各类资源，使得每一个协作伙伴从被动角色转变为主动角色
在项目后期，1月底的周末两天已经进入测试。QA参与进来，当然这也是之前的一个疏忽；因为1月28日到3月2日测试四天基本没有太大问题，虽然改动很大但是仅仅限于前端侧的改动，所以之前也没有特别声明需要后端开发参与进来。但是在3月1日的特殊case的测试中却发现，不少测试case需要在特定的条件下才能触发。
紧急的处理方案是，立刻打电话给对应角色的负责人，幸好对应的负责任很愿意配合我们的工作，立刻安排了两个人手。当然，这期间的麻烦事儿不止这些。因为在配合测试的时候作为负责人，同时也需要在回家之前把租房的事情搞定；所以当天上午并没有在公司。一边打电话帮忙协调人力，一边安排测试和我们自己组的小伙伴。
跟室友开玩笑说：“这是IT男北漂过程中最苦逼的两件事儿同时遇到了，一个是改bug，一个是找房子”。
其实后来想想，如果是协调的配合测试的事情，更应该让QAmm提前去协调；没想到事事躬亲，不仅难很好把控细节，而且非常浪费精力。所以，如果是需要其他角色参与进来的，尽可能使自己转变为统筹的角色，把对应协作伙伴的角色由被动合作，变成主动参与即可。
这个主题中还有一个不得不提到的细节是，当每个人都觉得我们的做出来东西比以前高了不知道多少个档次的时候；就必须要一些真正的反对的声音。当一个环境下从A到Y的人都在为你叫好的时候，但是Z却莫不做声；这时候一定需要放下自己对项目前景的任何期望，平静下来与Z了解其所思所想。QAmm团队中其实大多数还是充当A到Y的角色的，有一个QAmm对她映像很深，因为从测试到3月1日晚上，听到的一直是她的吐槽。
在亢奋状态当然能工作效率大增，但尤其是在亢奋状态而且是被一致的声音冲昏头脑的时候，越是需要冷静。
7、如何使得团队中的每一个人感觉到自己的努力被肯定，同时平衡每一个协作伙伴的劳动成本，从而使团队总体效率更优（并不需要让一个人发挥到最大价值）
知乎上看到一个很好的问题，大概意思是，除了说“辛苦了”还能的有什么方法可以让别人的工作成果得到肯定。当然，工作成果分两类：一类是确实被采纳的成果，另外一类是没有被采纳的。
由此，有联想到大学期间不少协助过其他同学做过一些毕设，那些我在帮别人做的时候他却把我撂在一边儿自己出去闲聊的另当别论；还有就是自己做完之后，得不到任何回复，那种场景非常悲哀。当然，事实上所有的工作都被人采纳了。更悉心一点，就是感恩情怀了。所以，自那以后自己谨记感恩，让任何付出都有回报：不管是荣誉，还是物质。
另外一个场景是，在商家中心v3.0项目中，组里有一个小伙伴（@lusir）提了不少有创意的点子。大多数情况下，他的想法都能让自己非常惊喜。可是，有一次，他在商家中心右上方的用户头像上，加了一个页面CSS3特效，然后很兴奋的跟我说。我知道，商家中心的用户并不是大多数能这样的细节特效感到惊喜的。但是，这时候必须要拍掉这个设计，也需要让他的劳动成果得到肯定。
我的做法是，赞美他的想法和行动力，然后了解下他是不是真的掌握了这个特效的原理。最后告诉他，我们乍一看别有趣味，但是我们商家并不一定会为我们这样的特效买账；但是，我们的用户组和活动页确实非常需要这样的设计，让他可以做成DEMO，沉淀下来。这样一来，至少他没有那么失望。
商家中心v3.0我算是过足了当设计和产品经理的瘾，同时还要设计angular在hornbill下的脚手架；没有那么麻烦，但是花了不少精力。一开始没有进入开发阶段的时候，自己基本能hold住所有的事情。但是在进入开发的时候，发现一些问题并没有自己想象的那么容易，而且一些细节的问题让自己分身乏术。
等下班回家想想才发现，很多东西自己根本不需要面面俱到的。第二天，也就是进入开发第一周的周四，就开始把游戏性工作分散出去；需要大改动的angular页面自己集中精力优化细节，至少面子工程不能随随便便嘛。然后安排组里一个对商家中心产品和技术非常得心应手的小伙伴（感谢@小曾）帮忙设计在新的框架的基础上最安全稳定的把没有时间重构的页面修改下样式，至少样式上统一起来。
最终，以他的协调能力，一天之类设计出方案，弄了一个页面测试下完全正；剩下的页面也交给了他全面协调，重构进度立刻赶了上来。
有些问题其实完全可以发挥到极限价值，比如就让小曾搞定所有的传统页面（当时小曾的效率是一天优化20页面，其他小伙伴一天5个左右），然后其他小伙伴跟我把angular页面搞定就行；当然，这样做的后果可想而知。项目中尽量避免一个人一家总览所有的细节，把梳理的模块分配给对应的协作伙伴，每个人各司其职。
8、保证项目中遇到的问题解决思路成为之后同类问题的可复用方案
技术项目，尤其是重构项目踩坑填坑再正常不过了。记得之前在做钱包项目时遇到一个头疼问题，项目已经到待上线状态，周日晚上十点，沙盒回归的时候发现有一个流程始终走不通。再一查，发现问题没那么简单。我们在QA环境都是使用的一个测试库，但是线上就不一样了不同的库存在不同机房，如果这个流程要走通，就必须跨机房。因为机房同步做得并没有那么完美，在线上环境跨机房的数据访问是明令禁止的。经过多次讨论，也没有很好的解决方案，为了项目排期只能硬着头皮上线，然后再做迭代。
项目中最怕遇到这样的情况，上线前遇到问题，这个问题还没法解决。所以，这样的问题一定要在项目准备期间考虑到，如果考虑不周全就只能硬着头皮上线，或者delay寻找解决方案。
商家中心v3.0项目确实的提前考虑到了不少坑，而且的都在项目开始前已经考虑好了解决方案。但依旧有一些漏网之鱼，比如权限管理，线上和线下需要两种不同的url逻辑；但是因为项目上线预期临时调整，需要小流量。这样的话，小流量的两状态就必须共存，但是线上的数据库只有一套，必须有一种方案。再去思考，事实上商家后台到现在其实并没有进行小流量上线过。所以，现在需要的解决方案，并不是仅仅能满足本次小流量的需要，而且需要一套通用的小流量方案。
其实没有多少冗余开发成本，基于cookie的小流量还是很容易做的。线上机器摘出一台，单独部署最新代码；nginx层通过不同的cookie状态分发到不同机器。后端也是一样的道理，通过请求头信息中的cookie判断返回那种数据结果。简单粗暴可依赖。而且这种方案作为以后的商家中心的小流量解决方案留存了下来。
9、项目中的零碎问题先mark下来，以避免成为重要问题的阻碍；但是有些被mark（忽视）的问题可能成为下一步问题的阻碍。
这是商家中心v3.0项目中遇到的很严重的矛盾：在开发时总有些细节在开发前不能考虑周全，真正开发的时候发现有些小而微的问题并不能立刻解决，所以项目期间一直鼓励把这样的问题留下来，不要为一个小微问题影响项目整体进度。但事实上，有一些“小微”问题，不仅仅很难解决而且很容易被忽视，而且会影响到项目整体观感。
最好的解决方案当然是评估问题重要度和紧急度，然后安排一个人集中精力去解决，而且解决方案必须敏捷而可靠。例如，项目开发初期决定只对表格页进行整体重构，表格中有一个很关键的交互需求是操作前置；但是按照以前的思路，操作前置就是指，把以前需要打开新窗口在另外一个页面操作的功能移到了当前页面的中心的弹框里。事实上，页面中心遮罩弹框这种交互元素并不是能适用于所有的交互需求的。这时候需要一套dropdown、tooltip、popver实现悬浮提示，鼠标旁弹层提示，鼠标旁弹层操作的功能。然而，这三类交互中，最后一类并没有现成的angular driective，只能实现提示，无法操作模板。
按照惯性思维，只能将该功能delay，依旧用弹框代替。但是如果这样，整体交互并不会有多大的改观。所以，我的建议是：尽可能使用鼠标胖谈曾操作。有一个小伙伴自告奋勇接下来了这个任务，但是最终的结果依旧没有那么完美。如果这个功能不能及时开发出来，接下来其他所有的表格页中的操作功能都无法继续。然后此功能导致列表页面操作功能难以进行，浪费了不少时间（注：感谢lusir及时提出问题）。
所以，mark零碎问题集中火力解决主线任务，同时也需要足够的判断，如果是影响项目整体进度的问题，集中火力解决；不要让“小微”问题得逞。
10、需要什么样的项目管理工具
商家中心v3.0没有用任何项目管理工具，所有的沟通和项目进展通过IM工具和文档汇总。其中有一个很大的问题，每个人的项目进度必须去工位上一个一个地确认。一个高效率的团队亟需一个的适合团队的项目管理工具，比如worktile之类。
11、做好预上线前期准备
这次小流量遇到一个问题从1/2小流量即将进入全量时竟然不知道这二分之一的小流量中有多少用户主动升级了新版。所以必须立刻加统计策略，统计主动升级数，升级后退回到老版本数这些关键数据。
当然不止于此，在上线前还是做了一些准备的。比如上线时间公告以通知商家，好让商家有个心里准备；还有必要的统计，还有用户反馈入口。
12、时刻给自己充电：“知而获智，智达高远”
从高中开始的座右铭：知而获智，智达高远。清清楚楚地记得当时在中央10套看到这8个字的时候，第二天特地去问语文老师这8个字的意思。当然，语文老师给的答案从字面上完全解释了其意。但是自己真正领悟这八个字，依旧还需要很久很久。项目期间，很多时刻自己大脑里会突然冒出来这八个字，然后自己为之一动。比如，一个功能点，一些技术方案，设计，产品……的一些东西融汇贯通的时候，就会发现到一些新的东西。
13、一些决定并不是沟通和投票越多越好
团队前期，作为主导侧，FE组中我和另外一位小伙伴把初步设计方案拿出来之后。另外一位小伙伴的提出，我们要不要再联合各个角色一起评审下。他的提议非常有道理，项目开始前，为确保每个角色都能把握好项目细节，一般都需要有一个项目评审，一般情况下由产品经理发起。但，有些情况有一些决定必须通过一方面的角色甚至一个人来决定即可；这次我们并不需要进行项目评审。
此外，还有类似dashboard的商家中心v3.0的外壳。当一类角色或一个人对一个项目有足够的把控力的话，鉴于时间因素可以由一个人完全操作所有的工作而不需要过多的团队民主。过多的民主反而会让简单问题复杂化，浪费太多时间去解释，此时只管去做即可。最初，页面中可能即要采用angular也要采用原生的形式；但是这个外壳是需要再两种页面下完全保持一致的，这就需要有一种外壳方案在两种页面下共存或者对两种页面写两种不同的方案。如果几个人坐下来去讨论，这将是一个几乎无解的过程。其实，最终只需要以一人之力做出来，然后在此基础上再做优化即可；过多民主讨论反而无益。
14、后续技术文档的沉淀，平台化
大型项目做完后多少会有很多技术积累，也就是现在正在进行的工作。写文档，整理DEMO，完成技术沉淀是一项很有成就但是也非常耗时耗精力的工作。商家中心目前有三项主要的后续工作：一项是light-ui,light-ui是ui-bootstrap的一个分支，更适合我们的商家中心项目，重写了不少组件，但是DEMO，文档依旧没有完善；一项是hornbill下的angular脚手架，在hornbill环境下考虑商家中心的模块划分，简单UI重构层级下无法修改URL，导致模块划分并不能在这次升级中做得更彻底，从而导致不同的模块冗余代码过多，后续不仅仅要优化再当前模块划分场景下的脚手架更要形成文档；还有一项是目前商家中心的dashboard的外壳，需要沿用商家中心的外壳到其他项目。
至于平台化，更重要的是开源思路：能让项目中积累下来的东西有更强的生命力，需要后人修葺和优化。所以，需要更便捷的平台以供延伸。比如，light-ui可以更方便的开发更多组件，而且几乎没有什么操作成本，立刻集成。比如hornbill可以做到在现有的架构上继续构建另外一种模块划分方式的转型。
15、不甘平庸，同时也要“接地气”
这是在前期产品和设计阶段时刻提醒自己的一个point，高大上和接地气肯定不是矛盾的。做一个互联网产品就像跟做艺术一样，在使用这个产品前用户自己都不知道自己究竟想要什么样的产品。所以有一种做产品的思路是，用户怎么想就怎么做，结果发现做到最后，产品越来越目不忍视。毕竟作为项目的主导者，设计者，对这个产品最了解的还是自己，整体还是得由自己来把控。此外，当一个人当机立断做出策略做出了新版的初步设计；当每个人都对新版的设计很满意的时候，一定要思考我们心中的商家中心的设计和商家想要的设计能不能够很好的吻合。
真正好的设计不会打扰到用户，也不会让产品的整体观感破烂不堪。从这个角度讲，任何产品和设计都是无私的因为你会绞尽脑汁去想如何设计会让用户觉得贴心。而越是贴心的设计正应该是用户再使用是就觉得很畅快，进行一个操作玩之后，我想要找的东西现在正在我的视觉中心，没有任何打扰。
16、产品设计对用户，是宠溺还是引导；如何想到用户没有想到的，从而引导用户使用通用的解决方案
比如检索功能，可能1000个用户就有1000个搜索需求。像如果要搜索一个特定的订单，A用户可能想直接通过买家昵称搜索，B用户想根据商品标题搜索，C用户想通过买家的手机号搜索；但事实上，如果过分的宠溺用户，导致的后果就是产品形态复杂，开发和响应成本增加，不能使用户形成统一的操作体验……而且这些问题带来的总体成本是随着搜索选项的数量增加而成指数级增加的。
这时候产品设计要做的就是规范用户的搜索需求，推荐用户使用订单编号来搜索；这样一来，UI更统一了，开发成本变低了，检索耗时降低了……用户习惯性思维就是ID检索。
17、什么时候该停下来，及时say no
把这一项放在最后也是最关键的一个经验，就是要思考什么时候该停下来了。很多时候，写代码的时候遇到麻烦，构思一个思路去解决问题；还有做项目管理的时候，定了一个短期目标，大家齐心合力却遥遥不可及的时候；当项目进展到一种地步却发现，越走坑越多的时候……
什么时候该停下来思考，而不是一味的往前冲；如果真的是一条死路肯定会越冲越疲。比如，再项目中期，我们发现按照之前拟订的重构页面的计划，再年前重构完商家后台是异见不可能完成的任务。这时，幸好有个小伙伴站出来提出问题。大家一起商讨，有两个方案，第一个是项目delay我们依旧按照之前拟订的项目预期去做；另外一个方案也是我更倾向的方案：做减法，把之前拟订的目标砍掉，只需要重构完全为表格的页面。最终采取了第二种方案，项目在年前顺利上线。
此外，在测试后期发现重构项目中太多BUG，怎么办，之前的设想是重构完之后直接全流量上线。看来要不测试时间delay，要不采取小流量的方案。其实上文也提到了，最终通过小流量方案解决，部分白名单用户可以自由再新老版本中切换。
一直想要多多了解下易经，其实这也是典型的中庸之道。把控风险，寻找解决方案无非是在完美状态和问题域去一个中间方案。当然，前提是到了这个时候一定要敏锐察觉到，然后立刻做好对策。
明天，3月5日，元宵节项目即将进入全流量，两个月的时间感慨很多，潦潦草草记下来这17点感触；接下来还有更重要的事情要做，相信未来。