r7raul 2008-03-24 13:00
现在我们公司的流程如下：
1、确定使用的框架技术（架构师的责任）
2、写需求（他们叫UC)（Project Designer）
3、设计数据库（DBA）
4、TestCase评审(QA)
5、开发
6、测试(QA)
7、功能演示
8、发布
最近因为看了J道，知道了前期架构的重要性，有一次开会，我建议最好推到现有的东西，好好设计重新来一编，但是得到的答复是“已经不可能了”。看来我只能继续在乱码中穿梭了，工作相当郁闷，而且出了问题往往会归结于我们这些程序员，有点不堪忍受，有换工作的冲动。我该怎么办BANQ老师？我是否应该找个架构好的公司，这样是否对我的发展更有帮助呢？还是安于现状？
banq 2008-03-24 14:55
第三步设计数据库 做法就不是OO的，在OO分析设计中，根本就不会存在“设计数据库”这个阶段。

正是有了“设计数据库”，破坏了代码的OO纯洁性，破坏了代码的可重构性，这样你的系统越编越乱，理了还乱，根本无法重构。

为什么会造成这样情况，说白了一点，因为这些学习数据结构长大的人根本不会做软件，他们以为做软件就是做数据库，所以，他们做出的软件根本无法维护，所以，东大软件才转行去做仪器软件，企业软件维护成本都超过利润了。

你已经认识到这个问题，很显然物以类聚，人以群分，那么就找一个适合你观点生存并允许一试的公司吧，这样的公司愚昧而固执，不待也罢。

或者你认为这个公司强项在市场，而不是旧技术，那么你有希望说服领导用新技术一试。

killer 2008-03-24 19:50
让业务专家成为业务建模专家不太现实，因为他需要额外掌握非常专业的技术问题。相对而言业务建模人员通过建模逐渐成为业务专家要容易许多，运用正确的思维方法我们应该是可以抓住业务领域的核心的，业务领域的核心是很少变的，在这个基础上我们可以慢慢扩展掌握业务领域的全局。这里其实主要还是要学会分类和比较，在共同中找出不同，在不同中找出相同，看似简单，其实很难。记得有一句话：“业务需求其实很少变，经常变的是我们对业务需求的理解”，个人感觉还是很有一定的道理的。
fnet 2008-03-25 00:32
就拿我以前的公司来说吧，举些名言：

WEB2.0，做最COOL的网站，最眩的Layout。

Javascript， Ajax太少啦，改改改。

我们要让用户用网站就像在用windows一样。

性能，结构其次吧，我们要先实现功能，效果。你只要告诉我能不能做吧。

这很简单，压栈？？？，javascript压栈。

数组，你把“这个”东西取出来...，依次遍历，在把“哪个”取出来...再遍历...，就这么简单。别告诉我你没听懂。


从老板到经理到销售都是这个想法：没有不能实现的效果，只有懒惰的coder


结果...可想而知。

[该贴被fnet于2008-03-25 00:38修改过]

hanyong37 2008-03-25 14:30
技术人员的悲哀：

开发了这么多年的烂系统，才发现技术人员对软件架构的热衷都是一厢情愿，没有一个好的商业环境，凭什么能产生好的软件？大家都急功近利，10w的单子5w拿下，100w的50w拿下，单子一签就跟公司销售商务没啥关系了，剩下的就是玩命压PM的时间，快点验收！ 可怜的PM们，面临上面下面左边右边的各种压力，所谓软件的结构，就是第一个被忽视的因素，有几个人关系你系统的质量？他们看到的是用最少的时间赚最多的钱？ 那就干呗，草草验收，维护工作甩给毕业生，客户做烂了不要紧，关键要尽快找到下一家，继续做一锤子买卖！

-就是这样，我已经出离郁闷了。

oojdon 2008-03-25 19:22
>>没有一个好的商业环境，凭什么能产生好的软件？草草验收，维护工作甩给毕业生

外面的世界真的这么恐怖吗？在jdon呆久了，毕业后进公司如果发现一起合作的程序员全是古老陈旧的思想，我会不会跳槽频繁？
组织一个全新的开发团队，所有成员用DDD思想武装，手握OO设计模式之利器不知道有没有可能。

someboyok 2008-04-01 11:57
http：//soyframework.com 好的框架是项目随需应变的基石。
leafsilver 2008-04-11 20:11
也不能总想着怎么消除IF-ELSE，这样的结果是冗余设计，任何设计都是个度的问题，而怎样把握这个度就是软件设计的艺术所在
freebox 2008-05-18 12:38
没有高明的技术，现有软件照样运行，没有软件，现有业务照样运行。业务才是关键，只关注框架或技术所带来的技术上的优胜，是不能够完成最终的有用的软件的。
有了业务模型做基础，余下的就是代码，到最后能说明问题的只有代码，不断的测试它们才能更好的维护。
判断过多就扔进策略里。
fantasybei 2008-05-24 13:56
"很显然物以类聚，人以群分，那么就找一个适合你观点生存并允许一试的公司吧，这样的公司愚昧而固执，不待也罢"

banq 老师，这样的公司不好找啊，哎，郁闷了

sleepinglord 2008-06-04 18:47
是的，但是其实不是所有的项目都在一开始明确方向或者能拿出一个架构设计来的。

比如我那篇贴的项目，我觉得在初期基本上不可能做出很好的架构设计来。

freebox 2008-06-04 20:01
我认为应该先深入了解领域，然后再设计。
不能坐着空想一个概念，并始终认为因为概念优秀而应该让它存在于本不应该存在的领域当中。
opjk 2008-06-11 17:30
其实读一本书就可以了java编程思想。下面5章包含了丰富的设计架构思想，相信理解之后就不一样了。

1: Introduction to Objects
2: Everything is an Object
7: Polymorphism
16: Analysis and Design
B: Java Programming Guidelines

r7raul 2008-12-22 11:27
一年了，项目虽然乱，但是通过俺们每日每夜的干活，项目依然充满了活力 - -！！！
BinnyJ 2008-12-22 18:16
我接收的项目也算是挺大的项目,某个 领域也算是No,1. 和楼主的项目开发方式非常相似,纯数据库编程.随着业务的变化系统越来越复杂.虽然项目在我们努力维护下,跑得还算稳稳当当,但总是有 如履薄冰 的感觉.有时候程序原修改一个功能,很容易导致bug出现,数据库设计原因导致一些修改关联太多地方,开发人员无暇去分析所有涉及的修改,客户投诉,老板把责任推到开发人员生上.

重新设计,老板觉得投入太大.目前人力只能应付项目维护工作,无法进行重构.只能小范围的 小打小闹.

虽然如此,项目依然推广,老板当然不肯投入人力重新设计,因为之前开发已经投入的很大的成本,中国项目,做得差无所谓,只要维护得过来,及时处理用户提出的问题 ,就行了.