Best Practice

sky100

看你怎么看这个问题了。现代的软件工程都是多人甚至多团队合作型，万一其中的一个模块外包到印度去，那边的开发人员乱写一气，污染了数据，然后下一级别的模块没有做数据效验怎么办？现实世界中总是有各种意外的。当时觉得没必要的事情，过几年之后可能会觉得是重要的。

从架构设计的角度来说，这样做对于扩展性很有好处。比如，现在你只用一台机器跑所有的web service.可是明天用户忽然增多，一台机器撑不住了，必须多台机器集群作战。这时这样做的好处就出来了，软件层面基本上不用作修改就可以分布到多台机器上用。如果象你想的那样内部通讯不需要安全验证，那么扩展起来还需要重新作安全验证，这样又会从另一个方面来增加工作量。是机器便宜还是开发人员的工资便宜呢？Really depends.
+ t. C4 E# L4 s: f3 \. g
) ^- H) |1 j% \. c' V( O很多时候设计决策本身就是一个trade off.

; `3 D% n; [5 q* M  }

sky100

老兵帅客 发表于 2011-10-2 04:15
* h: w  K/ b% @" i1 ^1 e% g第一。测试是干什么的？

第二。如果那堆web service根本不可能被deploy到外网呢？

+ ?% |' P0 T: e, ^, B
第一，绝大多数测试不可能覆盖所有的可能性。如果代码测试后放到生产环境中，结果因为某个特殊的情况，数据效验没有做而导致出了问题。应该是没有听从架构师要求去添加效验的开发人员的错，还是测试人员的错呢？
: F3 M- i% g/ M! _  Q: `
3 U* l8 o$ h! k9 B* L& b第二，我的看法是，除非公司的ceo拍胸脯给打保票，否则你never know.商业需求总是在不断变化的。从架构设计的角度，假设你是架构师，你是宁肯多加些冗余来保证系统的鲁棒性和可扩展性呢？还是为了减少开发人员的
* E8 q$ H- P# k工作量并给人力资源部制造裁员的借口而不重复校验呢？

3 }( Z3 A" ~: j; t老兵兄，你所提到的事情设计者未必没有想到，只不过他可能得到的信息和考虑的可能性要比你多，权衡之下采取的这个决策。而有些信息和可能性不适合公开讨论而已。换句话说，很多问题之所以不可以使用简单直接的方案是因为这个问题不仅仅是技术问题而且也是一个政治问题：）

我个人的一点陋见，搏大家一笑，请轻拍：）

/ S$ J( ?2 ]; o8 ?1 \. \: D4 y4 Z9 |

7 J0 q3 W. R' F