本帖最后由 sky100 于 2011-10-3 05:46 编辑
老兵帅客 发表于 2011-10-2 04:15 static/image/common/back.gif
第一。测试是干什么的？
第二。如果那堆web service根本不可能被deploy到外网呢？
第一，绝大多数测试不可能覆盖所有的可能性。如果代码测试后放到生产环境中，结果因为某个特殊的情况，数据效验没有做而导致出了问题。应该是没有听从架构师要求去添加效验的开发人员的错，还是测试人员的错呢？
第二，我的看法是，除非公司的ceo拍胸脯给打保票，否则你never know.商业需求总是在不断变化的。从架构设计的角度，假设你是架构师，你是宁肯多加些冗余来保证系统的鲁棒性和可扩展性呢？还是为了减少开发人员的
工作量并给人力资源部制造裁员的借口而不重复校验呢？
老兵兄，你所提到的事情设计者未必没有想到，只不过他可能得到的信息和考虑的可能性要比你多，权衡之下采取的这个决策。而有些信息和可能性不适合公开讨论而已。换句话说，很多问题之所以不可以使用简单直接的方案是因为这个问题不仅仅是技术问题而且也是一个政治问题：）
我个人的一点陋见，搏大家一笑，请轻拍：）
sky100 发表于 2011-10-2 16:34 static/image/common/back.gif
第一，绝大多数测试不可能覆盖所有的可能性。如果代码测试后放到生产环境中，结果因为某个特殊的情况，数 ...
说了这么多，其实很简单，决策者在逃避责任而不是保证质量与效率。因为重复的检测不会提高质量而却会增加开销和降低性能，但是在出了问题推诿的时候，那就是个优点了，因此这不是技术人而是政客考虑的事情。
这里的关键在于你所说的那些可能性在现实中几乎不可能出现，而成本却是必然而无法减免的，这样有成本而无收益的把戏除了出于政治需要谁会喜欢？
再多就变成政治扯淡了，到此为止吧。
看来楼主并不明白什么叫最佳实践
其实，说到底就是一个权衡的问题
1：如果一个系统重要到影响到公司的生死存亡，面面俱到，行万全之道不算为过
2：如果预算允许，多做一点检查也不错
3：如果用户需求没有要求，架构师加冗余来保证系统的鲁棒性和可扩展性，就有点画蛇添足。
4：Best Practice和Guideline，SOP还是有差别的。
5：很多情况，不是技术决策，而是管理决策。
sharepoint 发表于 2011-10-3 01:11 static/image/common/back.gif
其实，说到底就是一个权衡的问题
1：如果一个系统重要到影响到公司的生死存亡，面面俱到，行万全之道不算为 ...
right, right
说一下我为什么写这篇东西吧。
各位的回复我都看了，道理上完全对，但是现实中就不一定了，为什么，听我说哈。
我现在的项目组，来了位高人，动辄Best Practice，一套一套地，什么framework跟什么类库搭配，都说得很清楚。只有一个问题，大家都知道那些东西不能搁在一起滴，否则会有版本不兼容问题，而公司又不允许未经充分测试的修改版投入使用，于是真要用的话就只能是一塌糊涂喽，而这位不知道，还在那里狂侃。可是老板还信他，要求大家听他的，于是大家就难受吧，因为根本就配不通，更不用说具体去用了。
我们这里有一位狠主在给他挖坑，我们看着，谁也不说话，就等着开壶那天看热闹。
当然了，这位高人叫嚣的可不是我上面写的那点东西，充分的模块测试、重复的安全设置对他来说太小儿科了，显不出他的水平。那么干的都是些庸人，人家根本看不上滴，人家要干就干大的，或者一家伙把自己臭大街完事。
老兵帅客 发表于 2011-10-5 06:22 static/image/common/back.gif
说一下我为什么写这篇东西吧。
各位的回复我都看了，道理上完全对，但是现实中就不一定了，为什么，听我说 ...
最恨这些纸上谈兵的家伙。
我原来公司有两个家伙忽悠老板引入RATIONAL ROSE做项目，把大家搞得苦不堪言。最后项目没做好，那两个家伙倒是长了经验值，直接跳槽走人。
老兵帅客 发表于 2011-9-28 17:21 static/image/common/back.gif
我的想法是每层有各自的任务，重复检测没有意义。
认同。 讨厌重复的代码，讨厌重复的逻辑。UI层尽量少的biz logic。