以下场景是否在你的影像里出现过!
天下大事和久必分，分久必合！
很多情况下当一个项目结束，项目的成员都会分散到其他项目中，继续谋生。
比如原先的一个成熟项目（假设代号为A）有富有经验的架构师、系统设计师等等，当这个成熟项目结束的时候，除了一部分留守外，很多可能被安排到其它的项目（假设代号为B）作程序员，怎么，人的角色变了，对。
这个B项目已经进展到编码阶段，时间紧迫，而且很不幸，B项目的系统设计和架构出之新手，很多原先超简单的功能被极大的复杂化。所以当这两个系统架构师和系统设计师进入这个B项目Coding的时候，总是抱怨连连，感觉身心疲惫，靠巧合编程，看不到项目的尽头，感觉一群聪明人在一起做蠢事！
继续：现有的设计和架构可能导致程序员筋疲力尽，很努力了也看不到终点，维护极困难。
停止：重新设计和架构，时间上不允许，有令人发狂的最后期限呢？还有奖金。
继续还是停止，这是一个问题？
如果公司里有专家组成的架构设计评审团，这个问题根本不存在!可是没有!
问题又摆在眼前,很多人可能会离职!
何去何从?
posted on 2006-10-19 14:05
MasterCai 阅读(1335)
评论(13) 编辑 收藏 所属分类:
软件工程 、
程序员文化
发表评论
“感觉一群聪明人在一起做蠢事”有时候的确会有这种感觉。
不过做项目不是做技术，最终项目的成品和投入市场是最重要的。没有项目是完美的，最终要的是“能跑”，跑得好。用户在使用时谁关心内部作的如何呢？虽然我喜欢追求所有的都最好，但是也不得不承认上面这点。
嗯，有点像我们公司的情况，每个人在某一方面都是很优秀的，但是由于部门壁垒的原因，Web项目由不懂Web的人来做，或者反过来。结果弄得开发也累，项目质量也差。
嗯，说得比较现实。做一个项目，大家经历了风风雨雨，也由摩擦变成了患乱兄弟。但是当项目结束的时候，大家都散了，感觉再也找不到很好的人一起合作。面对别人的乱摊子，心里充斥着埋怨
如果按照比较规范的模式来开发，还好点
最烦，代码注释少的可怜的，有没有任何说明的破烂玩意
郁闷到内伤啊
没有进行过。大的协作。
我个人认为，不可能对一个系统推倒了重来。但是对那部份必须重来，是必须明确的，而不是任其发展。
@Go On... OR Stop...
“感觉一群聪明人在一起做蠢事”
有点经典
有同样的感觉，觉得都挺优秀的，就是项目质量上不去。
写出了很多人的境况，我们需要进步，公司同样需要进步。
推倒重来是肯定不可能的，最多是在这个基础上进行改善，如果有条件就一步一步的拉回到正常的轨道。
这个主要是人员安排的因素造成的，一个公司里面不可能大家都有比较高的技术能力，要根据人员的情况和公司的需要有一个合理的分工。如果公司里面的项目很多，应该有几个人脱离具体的项目，不必让这些人每个项目都从头到尾钻下去，应该每个项目都了解一点，参与一点，再搞一点基础的东西。如果这些项目涉及的业务领域又是比较接近的，这样做的好处就更加明显了。
一些模块的重构其实也不是那么可怕，这主要看具体开发者的素质（愿不愿意承担眼前多出来的工作）。整体框架的深度耦合才要命，搞得牵一发动全身，那就真的歇菜乐。