电子商务网站的可持续发展

总结了一下LZ的解决方案，大概如下：
1.要包容别人的代码，现在不是找出是谁造成的，而是要从自己接手这一刻，开始改进。
2.每个公司的每个项目组，都应当向HR部门学习，制订一个良好的新员工入门索引。
3.在平时，就要强制性的review代码
4.从开发，到测试部门，都可以不要对立，坐下面交流，来去考虑如何改进。测试部门可以指导开发树立测试的意识、思想、技巧，开发人员必须要承担测试，不仅要写单元测试，也要做功能测试，也要会自动化测试
4.从全局的基础上，对系统的服务基础设施建立一套共同的抽象规范，从架构师的层面，进行控制。
5.就是要去主动的重构，对系统和代码的复杂度降维，轻装上阵，在一个更有利的位置，拥抱变化。
6.招聘人，要招self-proactive的人，能够带来变化，能够解决问题，而不是抱怨的人。
7.架构师要有责任，要有技术领导能力，要去Push别人。

说的很好，也很全的
现在就想针对自己的情况发发牢骚

开发人员、team leader、开发部、测试部、架构师
每个人都应该将自己的责任扩大，又有多少人能看清责任后面的好处呢？
很多人，特别是更新换代非常迅速的IT，会愿意挪一下自己的位子，去接受原本不属于自己的责任，或者松开自己原有的权力呢？

我在现在的公司之中，很想改变一下，给原来的沉闷增加一些敏捷
于是针对原来的软件过程，参考了不少scrum的思想之后（个人感觉改变已经很温和了），设计了一套过程模型
项目小组成员以及项目负责人都很赞同
结果被经理一票否决，继续维持原来缓慢的过程，甚至还在某些事情上面掣手掣脚，或许是想让我认清自己角色吧
于是，目前我们还是维持着原来事不关己，高高挂起的老样子
很失败

很多问题，讨论一下又到了态度或者人性这个很虚无的概念
人性是善是恶，我不晓得，但自私的成分肯定不少
如果不能有利于自己，多少人会愿意去放远眼光，寻求改变？更何况改变意味这一段时期的混乱和权力的不习惯

都说改变是由里及外，内部改变了自然外部也会改变
可不能由上及下，有多少改变能顺利执行？
可要由上及下，又有多少局外的上级能看清迷局，主动寻求改变？
这是一个矛盾么？

说得比较消极，可生活还是要继续...
每个人还是要把握机会自我激励一把

 

楼主的帖子很经典，我喜欢，复杂项目中，对于各个层次的人来说，问对问题比自己想出答案更重要

小小见解，你们的问题出在开发部经理或者开发总监身上，跟架构师和开发人员其实关系不大，当然，架构师脱不了干系，开发人员嘛，通常都是承担责任的人，但实际上责任应该由领导来承担，一支队伍打不好仗，只有一个原因：领导有问题

 

1、老实说，j2ee项目的代码膨胀主要问题在于数据失配，有人叫它“阻抗不匹配”，借用几句话：在一个j2ee项目中，你同时要处理多种数据失配：服务器端的RDBMS和浏览器展示出来的HTML之间，需要Servlet的渲染，数据经历了RDBMS Row ，ResultSet, 若有若无的DTO和浏览器Form数据这几个步骤，让数据变得支离破碎。实际上所有的Java框架的核心都是解决不同层面的这些破碎。核心问题在于OO和面向数据或面向展现的不匹配，DTO？忘了它吧，原始的Map<String，List>？嗯，很方便，你能保证类型或数据不被滥用吗？自己写一个适合自身项目的面向数据或面向表现的存储结构也许会让你的项目更轻松。

2、找了半天没找到你的第二点在哪里

3、换手的问题，主要不在技术上，而是在心理上，项目经理这时候在哪里？好项目是安排人的艺术，换手处理的不好，就打他屁股

4、沟通如此重要，方法讲了千千万：手册，培训，review，结对。。。，可总是做不好，为什么会这样？因为项目经理从心理上惧怕沟通

5、你有3个第五点，我只好分开5-1、5-2和5-3了

5-1、不愿意使用自动化测试脚本来测试的电子商务平台项目注定要倒大霉的，测试部门和开发部门要是不乱你要好好谢谢上帝，不过用了自动化测试脚本就不是说不倒霉了，该乱还是会乱，关键是看怎么设计组织流程以及怎么进行知识管理，这不是QA部门和开发部门这个层面能够解决的问题，CIO呢，实在不行CTO也行啊。

5-2、这里面楼主说了两个很重要的问题，1、服务基础设施的抽象设计，如果不设计这个，一个电子商务项目会乱成一麻袋麻绳。2、团队技术积累，必须保证在某一领域的积累，所谓“搭班子，带队伍”，搭好了班子下一步就是带出一只好队伍，一只能把三八大盖用得出神入化枪枪中眉心的队伍也比什么高级枪都揣着但就是准头差的队伍强。

5-3、现今的电子商务网站的复杂度是客观存在的，服务融合嘛，就光几家大接口就够你改出N版程序来，所以类似于ESB这种的转换集散地是必须前期规划设计到位的。另外，架构师必须做大量的技术决策，跟踪整个日常设计和编码工作，以便贯彻自己的设计思路，绝不能浮在水面上不停的鼓吹和引入新技术，那样只会让团队更糟糕，波兰闪击战打成百团大战，把家底都打没了还得咬着牙大书特书，这样的指挥官还是趁早红牌罚下。

6、这个问题在所有的公司都存在，招聘的人不认真，招来的人自然不认真，人力资源部的审核也不严啊，还是文化和管理的问题，价值观没有贯彻到位，顺便问一句：咱这公司的有提出什么价值观吗？

7、这个嘛...架构师们也许有自己的考虑（莫非只有一个架构师？神仙姐姐，我先拜拜），这事实际上责任也不在他们，他们向谁report，失败了谁的利益损失最大就是谁的责任

 

 

最后还要说一句，技术上乱套的项目未必商业上就不成功，修修补补也是过日子嘛，只要商业上做的好，大家都有饭吃，总比技术上先进的饿肚子部队要好，没有油再好的坦克也走不动啊。IBM的大型服务器代码不也乱的跟麻绳一样，有的代码写的，看了之后哇哇吐，不照样卖的蛮好。

 

 

我不直接就楼主的论述发表看法，因为就事论事的做法在这里行不通。
首选网站的开发到底是应该属于项目开发，还是产品开发，这就是一个关键性的差异。我的观点是网站开发，特别是商业网站的开发，是一种特殊的产品开发，而不是项目开发。当然你可以以阶段划分，使用项目管理的手段处理问题，但是从整个的流程和所处的环境来说网站开发还是更加类似于产品开发。不过网站开发，又与传统的产品开发有许多细节上的不同。
网站开发会产生一个很突出的问题，那就是随着网站运行时间的增加，特别是商业网站，其业务目标，功能需要，代码结构，都会发生快速的熵反应。而如果仅仅从单一的层面思考问题，并不能取得突出的效果。这一点也就是我在上面一个帖子中，强调功能与代码联系的重要性的一个原因。
网站开发的组织，人员流动性要普遍大于普通的软件公司，这一点是受互联网行业的整体风格的影响。这一点不仅仅会造成技术和业务接手的频繁出现，无疑也是熵反应的一个促进因素。而如果没有一个结构化的系统将业务和技术进行整合，其熵反应将更加明显。
网站的测算和测试，都需要很大的成本代价。而有些关键要素的测算，又会给成本带来深刻的影响。同时这些测算也需要有技术的手段结合，并且也需要对其继续进行测试。同时测试在网站开发中就会同时需要在对网站本身的技术构成进行测试，也需要对网站关键指标测算的技术手段进行测算。这两者的测试要求和测试的环境并不相同。而另外一个方面，测试其实也有熵反应。本身测试应该是熵的降低者，但是往往随着时间的增加，其会向熵反应的加速方向发展。
就管理和运营来说，网站经营比传统行业简单的多，但是变化的速度要快的多。这种情况下的熵反应，又会与传统的情况有所不同。
而深入讨论，我觉得还需要很多条件。过一段时间，我会在将产品开发和策划流程总结以后，专门在这个方向进行讨论。目前由于需要的基础知识还不统一，展开讨论会很困难。

o6z说了半天，是什么个意思？没看明白。

我也是做电子商务的，不会我们的情况没楼主说的这个样子。

不会代码的不断重构也是必需的。

从全局看问题，再从局部出现的问题来重审整个系统的架构。

恩，考古学家一说，非常有代表性。
新员工如果进入一家已经发展了3－4年的电子商务网站，业务知识足有1年的消化时间。

这对于新员工来说，是一种挑战。呵呵！

不知道大家开发过程中的开发规范落实到什么程度？其中一部分问题可以通过开发规范（当然是在开发人员遵守的情况下）解决

授人一鱼，不好授之以渔
  这样的人很狭隘

我也在做电子商务，一个字，烦

不是我不能，而是变化太快。
现在网站很少会有固定的模式，今天流行blog明天流行视频网站，这完全都是不相干的网站构架。我觉得不要因为不停的去构架系统而害怕，要适应变化。敏捷开发里面就有许多适应变化的开发方法。当然，说得到与做得到还是有不少的差距。我想windows从3.1做到vista里面的变化估计不小，不过还好，微软的操作系统还是世界上卖的最多的操作系统。