电子商务网站的可持续发展
2007年终于过去了，从焦油坑里爬出来幸存的人们，互相握手庆幸，喜极而泣，纷纷在博客上写工作总结与来年展望，而我终于厌倦了期权的精神鸦片，难得的坐下来，远离自己负责的网站，想一想来年的布局。
在国家大力宣扬环保，可持续发展的时候，从企业，从网站，就我个人，都要讲一个可持续发展，一夜暴富的思想只会浪费精力，没有方向，而只有平时注重积累，厚积薄发，终会有从量变到质变，扭转局面的时候。
我们发力在向前奔跑的时候，也要适时的停下来，倒掉鞋子里的沙子，让自己的步伐更轻快。
我所经历过电子商务网站都面临的下面的问题，如何让自己步子慢下来，解决这些问题，持续发展，是一个从管理和技术层面上，都比较有挑战、让人兴奋的问题：
2008-1-8 16:18 vunhbb
1.膨胀
公司业务向好，代码越加越多，原来一个人写一个类时，只是完成一两个单一的功能，随着需求的变化，一个核心类的代码，不知不觉膨胀到一两千行，有的Action代码，也会超过1000行。接手的人，一般不敢动，也不愿意动接手的代码，也就是说，他不会去重构以前的代码，一般就是线性的随着需求的增加，代码也不断的增加，同时在开发时，总是八股文开发，很机械、迂腐的套用一些重型的、所谓的J2EE设计模式，如Factory, DTO, Proxy等等，代码量和代码复杂度最终是线性增加。
则代码复杂度和行数的膨胀，会是负面循环，反过来影响你面对需求变化时态度。
举一个例子，从用户角度来讲，订单上增加一个字段的小需求，应当是很简单的一件事，但是对开发人员来说，增加一个字段，则要确认所有与订单相关的页面（相关的界面可能有十几个）都要修改、重新布局，这个工作量可不小，而且容易漏改。这不是一个容易避免的事情，不仅是页面，类也要修改。很多人写的关联查询，结果放在DTO类而不是Map,扔到页面上的话，则DTO类也要修改。
一般的性能问题，总是由开发人员的代码造成的，而不是由架构的Scalability瓶颈所造成的，累积的代码，就像电器上日积日厚的灰尘一样危险，随时会短路。以前的僵尸代码，会在数据量和访问量慢慢增长到某一个临界值的时候，突然复活，搞得你灰头土脸。 如果你只会批评开发人员不小心，那种永远也解决不了问题，让谁写，都不能保证不会踩上地雷。领导不出BUG，只是因为他们不写程序。
2008-1-8 16:18 vunhbb
3.铁打的营盘，流水的兵
第一个人下棋，下到中途，离开了，第二人接手，接着下，以后可能会有第三个人，接手的人，怎么下怎么不顺，这时总想重新下一盘，但没有选择，只能一边问候着前人的老妈，一边继续走。最后，我们再把这盘棋复盘来看，做成一个棋谱，会有什么的感觉？
这一般不是两个人能力差异的问题，是一个心理的问题，每个人都不愿意看别人的代码，都觉得别人的代码写的烂，不愿意花点时间，来review同事或者前人代码，他们认为这是考古学家的事情。这样的结果，如果不了解别人的代码，就无从重构，在此基础上增加功能或修改，只能说是乱上加乱。
要包容别人的代码，现在不是找出是谁造成的，而是要从自己接手这一刻，开始改进。
打江山的人，所基于的环境，是非常恶劣的，是非常不容易的，从无到有的创建一个网站的老员工，一个人做三个人的活，是非常值得尊敬的，接手别人，再怎么说，也是站在别人的肩膀上考虑问题。其实让你先下，让第二人再接手，他也会这么有同样的思维，我们需要的是宽容，宽容与谅解应当是自上而下的，而不是自下而上，不然就变成，项目经理说：我体谅你们，可领导不体谅我啊。
2008-1-8 16:18 vunhbb
4.新来的员工不是考古学家
新来的员工抱怨个不停，确实是很讨厌人，另一方面，从他的角度上来讲，没有选择的权力，必须在别人代码的基础上增加新的功能或修正一些BUG，你不能用你最擅长的东西，当别人的代码是JSP+Servlet，你就用这个，你必须要遵守这个规则，同时也要遵守别人的开发习惯。
新员工就像一个考古者，站在一段象形文字的文物面前，来想出前人的意图，确实非常的艰难。
所以每个公司的每个项目组，都应当向HR部门学习，制订一个良好的新员工入门索引，这个索引有什么内容，每个人根据自己的项目，自己来考虑。这样的索引目录可以重用，不用来一个要讲一遍，占用项目经理的时间。
一般的人，都是被动的，8个小时，怎么过，都是过，平时不会去看别人的代码，只是在自己承担一个任务时，才会去看那些相关的代码，这样就会时间太紧了，手忙脚乱的，容易出错。所以在平时，就要强制性的review代码，是必须要的，你不能信赖别人的主动性，否则的话就是自食苦果。
2008-1-8 16:18 vunhbb
5.脆弱的测试体系
长期膨胀，得不到改进、重构的代码，每有新功能开发，测试的代价非常、非常的高，因为非常容易犯错。
很多的公司并没有一个良好的自动化回归测试体系，所带来的人工成本就是非常高，测试人员所做的工作，就是民工扛水泥包，又脏又累，测试覆盖的效率又差。
频繁ReOpen的BUG，会牵累process当中每个环节的人，配置管理员，测试人员，开发人员，TeamLeader，也会影响到考核。带来的众多的参与其中的人，随着运转，打标签，提交测试，打回，修改、再打标签、再提交测试（此时所有开发人员的BUG都要改完才能提交），测试人员重新测试（原来已经测试通过的功能，还要再测试一遍），重复N次。
其实我们自己从开发，到测试部门，都可以不要对立，坐下面交流，来去考虑如何改进。测试部门可以指导开发树立测试的意识、思想、技巧，开发人员必须要承担测试，不仅要写单元测试，也要做功能测试，也要会自动化测试，这些除了可回归的单元测试，很艰难，不容易做，但可以一步步的改进，其它的比如自动化的界面测试，其实是很容易的，花个两天时间，把成员关在会议室里，搞Win runner界面测试，编写可重用的测试脚本，定制有效的、覆盖关键路径的、可重用的数据源，还是能收到成效的，这样当需求变化时，那些没有变化的功能，其脚本也不变，都可以在短时间内回归的测试一遍，而不要把成本直接转嫁到测试部门。
2008-1-8 16:19 vunhbb
关键是要不要走出第一步。 不知道为什么领导总是愿意相信冶百病的偏方，相信永动机，相信不会犯错，项目不会延期、百战百胜的神人。 不要再花钱找一些天桥说书、卖大力丸的QA了。其实没有一个人可以驱动一个庞大的团队，还是要靠团队中的核心都行动起来。
5.缺乏从宏观层面技术标准的概念统一和定义
随着业务的发展，有很多的合作型的项目，子系统越来越多，同时要外接的系统越来越多， 做为一个分销的平台，可能要和外接的B2B系统对接，即要给别人在公网上发布接口，又要从第三方的系统获取产品数据源，这种系统与系统之间的数据交换，缺乏统一的标准，各种各样的技术都可能有，又有不同的项目组负责，各自为政，这不是他们的问题，他们不是CTO，不是架构师。
2008-1-8 16:19 vunhbb
从全局的基础上，对系统的服务基础设施建立一套共同的抽象规范，从架构师的层面，进行控制。
主要有：
1.服务的分类（支付网关、消息网关、中央工作流引擎、中心缓存服务、外部数据源对接服务、B2B订单预订接口服务等），以及各类服务的设计原则和建议
2.服务的技术标准定义与约束，耦合关系和原则的设计规范等
3.服务调用的接口详细定义与约束，如此服务所支持的并发数的限制、超时调用的限制等。
4.统一技术标准和约束（如统一使用spring, ibatis, struts2, jquery等），不滥用，注重有效积累， 减小对后来的人增加维护难度，但确定下来的技术，新来的人都要强制先学习，从心理上接受这些技术，先期消化这些技术曲线，避免临阵磨枪，好事变成坏事。
2008-1-8 16:19 vunhbb
5.被动的迎接变化,缺乏主动
规划是很重要，但总有跟不上变化的时候，不可能有一劳永逸的架构和平台，初期业务和业务系统都是不成熟的，你在做一个系统时，可能只有两三个人的团队，所做的也只是一个初期的业务，你不可能想到，未来我的系统可能要与114合做，要与某某网站合做，当这个变化来时，你才能去做这个设计。
例如你只知道大陆酒店的业务，当你的业务要扩展到香港、海外的时候，他们的业务规范与国内的差别非常大，新的业务有可能在推翻你前期的设计。
你的系统要和某某网站一个合作业务，要个某某银行合做一个信用卡联名卡业务，这些合做型的项目，对方都是强势的，你不是规则的制订方，你是接受规则的一方，你在欣喜公司的业务蒸蒸日上的同时，恭喜你！你的系统的复杂度，也在蒸蒸日上。
唯一的办法，就是要去主动的重构，对系统和代码的复杂度降维，轻装上阵，在一个更有利的位置，拥抱变化。当然重构不是阳春白雪，不慎会带来新的不稳定因素，只要是对代码进行变动，都会引入风险，特别是遗留代码, 你在擦拭灰尘的时候，却不小心把桌上的瓷器给打破了，这时候主人肯定不会表扬你的勤劳。不管怎么样，这是你负责的项目，你跑不了，主动一点，总比束手待毙强。
2008-1-8 16:19 vunhbb
6.人力的焦油坑
人月神话这本书，只是给出版业带来了繁荣，平时的我们总是一遍又一遍的从一个焦油坑出来，又掉到另一个焦油坑里去，可见看书是没有用的。
由于难以维护的系统，总是拖累正常配置的人力，使你感觉到人手总是他妈的紧，连正常的需求开发、BUG修正都满足不了，那有时间重构。所谓人力恶性循环，就是好不容易一个熟悉代码的人，培养起来，他也厌倦了，拍屁股走人了，再招人，就得招两个人，因为系统的复杂度又增加了，需求又增加了。
这样的结果很可怕，没有时间来与时俱进，没有时间做提高用户体验、有价值的、增强用户粘性的功能了，没有创造性的工作，那些有创造力的人最终会含狠而去。
增强人力资源的储备和技术储备，是一个有效的措施，在平时做，而不是到关口了才想起，手忙脚乱的。
招聘人，要招self-proactive的人，能够带来变化，能够解决问题，而不是抱怨的人，等着妈妈把饭嚼完送到嘴里的小鸟，否则就是效果相反，就造成了，加人，越加越累，因为你所加的，都不是解决问题的人，而且加人的时机也不对，平时，都没有储备，关键时候，才想起要人，太晚了。
考虑一下，随便招一个普通的程序员，对于周围关联人的影响和所带来的成本： 增加一个测试人员的工作量（可能他的BUG增多），增加美工的工作量（他不会写页面，不懂JS,不懂CSS），增加项目经理的工作量，增加TeamLeader的工作量（做培训计划,讲需求，讲技术)，增加DBA的工作量（因为他不懂数据库，老写一些让服务器心脏博起的SQL 代码）。
2008-1-8 16:19 vunhbb
7. 松散的组织架构
一个网站，大的网站，几十个频道，一般的也有十几人项目组，他们在维护同一个网站，彼此之间的联系很多，共同点也很多，看起来应当统一，都是自己人，也不难统一，但是现实却是非常的艰难，却如此的松散。
任何东西，自下而上，所带来的必然是混乱和无序，考虑一下从组织架构上来改变，建立CTO team，从全局的范围内，自上而下的推动、控制，加强全局控制力，改变各个频道或项目组各自为政的情况。将复杂的东西控制在上层，而不是程序员中间，任由其蔓延。
改变架构师缺位，吃白饭的现状，公司不是养着架构师，学习新技术的，满口之呼者也，酸腐的人，谁都要学习，但要去一线解决问题。
架构师要有责任，要有技术领导能力，要去Push别人，当开发人员在造轮子的时候，首当其首，责任就是架构师，如果开发人员在重复，还要你架构师做什么？很多开发人员自己写，是因为没有办法，他也不想写，但是现有的代码库当中，没有，或者没有他适合用的东东。