! n5 ~+ E. e6 N% k; n
0 U" W. D3 J' L# B2 k; U- H G
第一，绝大多数测试不可能覆盖所有的可能性。如果代码测试后放到生产环境中，结果因为某个特殊的情况，数据效验没有做而导致出了问题。应该是没有听从架构师要求去添加效验的开发人员的错，还是测试人员的错呢？' O6 j! x; @8 T$ J7 w
( A. Z+ @4 d% j" Q6 N第二，我的看法是，除非公司的ceo拍胸脯给打保票，否则你never know.商业需求总是在不断变化的。从架构设计的角度，假设你是架构师，你是宁肯多加些冗余来保证系统的鲁棒性和可扩展性呢？还是为了减少开发人员的 3 N; `* I. r( ~& V工作量并给人力资源部制造裁员的借口而不重复校验呢？ . S0 v2 H- w# r% B5 d' L! P9 y% u * s6 l; _; h' m; F老兵兄，你所提到的事情设计者未必没有想到，只不过他可能得到的信息和考虑的可能性要比你多，权衡之下采取的这个决策。而有些信息和可能性不适合公开讨论而已。换句话说，很多问题之所以不可以使用简单直接的方案是因为这个问题不仅仅是技术问题而且也是一个政治问题：）+ L1 y3 B o2 ^* j
- Z) @0 `2 c. Z+ X
我个人的一点陋见，搏大家一笑，请轻拍：） 9 S/ e. |/ s) T8 W6 V1 u- t. ]+ L9 u
' }+ C5 K3 N! C# _$ T; ~1 A- V " T* R4 [) W/ P; `; [) F; H " h+ Y! r w' `4 b2 K- d 1 a6 U$ y- U7 t 7 l$ K; w# i2 s: V+ e
其实，说到底就是一个权衡的问题" B9 k; @2 L3 p/ l/ t3 F# U
1：如果一个系统重要到影响到公司的生死存亡，面面俱到，行万全之道不算为过; w/ b+ H+ H; `! k8 x' e" m
2：如果预算允许，多做一点检查也不错 6 B& T+ b; n9 W* z3：如果用户需求没有要求，架构师加冗余来保证系统的鲁棒性和可扩展性，就有点画蛇添足。' i, i( k4 O5 r. d O, M$ H d6 e
4：Best Practice和Guideline，SOP还是有差别的。; k0 v: |5 I% Q7 j+ i
5：很多情况，不是技术决策，而是管理决策。
说一下我为什么写这篇东西吧。 4 k! V3 R5 I" \! D. K . T3 n0 _9 R4 Y h3 f' ]) ]各位的回复我都看了，道理上完全对，但是现实中就不一定了，为什么，听我说哈。 , A' z4 {$ _7 A2 i" `1 K$ Z+ r- H% G. K3 ~! l, E9 @- W. y
我现在的项目组，来了位高人，动辄Best Practice，一套一套地，什么framework跟什么类库搭配，都说得很清楚。只有一个问题，大家都知道那些东西不能搁在一起滴，否则会有版本不兼容问题，而公司又不允许未经充分测试的修改版投入使用，于是真要用的话就只能是一塌糊涂喽，而这位不知道，还在那里狂侃。可是老板还信他，要求大家听他的，于是大家就难受吧，因为根本就配不通，更不用说具体去用了。 # M) e* J* I9 {1 J0 L0 v5 ~# b3 ~3 W: O2 h: R/ I i; ?2 o6 u q; Q/ H
我们这里有一位狠主在给他挖坑，我们看着，谁也不说话，就等着开壶那天看热闹。. s b( f0 i! q+ d5 Y4 V. C
+ |% s1 s' U' ^
当然了，这位高人叫嚣的可不是我上面写的那点东西，充分的模块测试、重复的安全设置对他来说太小儿科了，显不出他的水平。那么干的都是些庸人，人家根本看不上滴，人家要干就干大的，或者一家伙把自己臭大街完事。
[复制链接]
雷达卡
发表于 2011-10-3 05:34:45
显身卡
楼主
