爱吱声

标题: Best Practice [打印本页]
作者: 老兵帅客    时间: 2011-9-27 22:11
标题: Best Practice
这里干软件开发，经常会遇到迷信Best Practice的家伙，一说起来什么都要遵循这个，否则就要不依不饶跟你扯，实在是烦人啊。
0 S: a; T7 K* {
$ L/ U; n# M. S9 V/ V举个例子，一个web应用，给分成了presentation layer, business layer, data access layer等等。这个分法倒是很合理，问题是人家认为数据的校验也是每层都要做的，理由是各层都有可能被替换，你如果不做如何保证数据是符合要求的？很对，但是实践中就有很多问题不好办了，问题出在了测试上。8 u7 B( |8 C5 Z2 K$ H7 y
/ K/ A* }$ H/ L" p
具体说来是这样的，presentation layer包括浏览器部分和服务器的对应接口部分，前者的校验用javascript而后者用java，这就是两层测试了，再加上business layer的那层，起码就是三层了。这三层测试所做的工作，或者说所依据的规则一般是一样的，因为就是一个java bean在那里传输数据嘛。可是问题是如果第一层已经做的完善了，第二层又怎么可能检测出问题来呢，因为可能的错误已经都在第一层被发现了嘛，于是为了让第二层检测能够工作，你必须关掉第一层检测，这意味着修改代码，而任何修改都意味着可能带来新的bug，这个怎么检测？第二层和第三层之间的问题跟前面是一样的，也就是你必须关掉第二层的检测来让第三层的检测有机会干活，这里同样存在前述的可能带来新的bug问题，同时这三层检测在交付以后需要同时存在重复检测，这开销怎么算？) Z+ t- d: K  `- I' D
# J8 d$ i- ~. s* g
有人可能会说，那是必要的代价，因为各层都有可能被替换，因此各层自己的检测是必不可少的。理论上这话完全对，可是现实中几乎不存在替换的可能，因为那意味着整体结构的大修改，即使出现这样的情况，交付以后的其他各层检测还是没机会干活的。于是一个看起来完美的方案，现实中只是在浪费资源而已，因为同样的数据要被检测三次，而只有第一次有可能被检测出问题来，后面那两个都是白忙乎。
0 y6 D& D9 j$ C7 L
# S; L$ w" q: e. W. C4 v这方面的另外一个例子就是ESB领域，这个领域的用户普遍都是些大用户，具体实践就是一大堆的web service在那里以workflow的方式运行，这点没问题，问题是每个web service的设置都有着全套的安全规范，例如双向SSL和WS-SECURITY之类的，哪怕是这堆web service都运行在同一台逻辑机器上也一样，于是就是大量的开销却没换来任何安全上改进。
作者: 小绿爷    时间: 2011-9-27 22:17
隔行如隔山，对我而言基本看不懂
作者: 老兵帅客    时间: 2011-9-27 22:43
小绿爷 发表于 2011-9-27 09:17
! n  T5 P  b8 v5 r4 ^/ v0 J  W; O8 ?0 p隔行如隔山，对我而言基本看不懂

4 O1 F6 ~) t. c* b5 C没关系，重在参与嘛
作者: 旅途愉快    时间: 2011-9-27 23:32
同意一楼意见。。。
# R% }5 |& ^  i7 Z囧，什么都没看懂。。哈哈
作者: 老兵帅客    时间: 2011-9-27 23:33
旅途愉快 发表于 2011-9-27 10:32 2 W3 P: a6 L/ B  |/ @6 G
同意一楼意见。。。
& u( \/ N( U) l5 y' V2 ]囧，什么都没看懂。。哈哈

" g- T6 c$ Y: n  ^3 G7 `* K又是一个重在参与地
作者: tonyxu    时间: 2011-9-27 23:49
我家倒是有本书，Thinking in JAVA，是LD的，不过她现在在搞ORACLE。。。
作者: 老兵帅客    时间: 2011-9-27 23:51
tonyxu 发表于 2011-9-27 10:49
  u% r4 x3 i) @9 V我家倒是有本书，Thinking in JAVA，是LD的，不过她现在在搞ORACLE。。。

. W8 t% j& g6 P) J" a8 L! O还是个重在参与地
作者: tonyxu    时间: 2011-9-27 23:53
老兵帅客 发表于 2011-9-27 23:51 ! D' S9 Z3 Y; G+ H
还是个重在参与地

9 L1 R/ B  L' J! r; @absolutely...
作者: 飞翔的芦苇    时间: 2011-9-27 23:54
不懂，坐等懂的人来谈。
作者: 老兵帅客    时间: 2011-9-28 00:00
飞翔的芦苇 发表于 2011-9-27 10:54
! j! A% _9 v* o/ ?5 Z( v2 d& _不懂，坐等懂的人来谈。
* y3 \7 U* r. f- ~# ?% r1 F
怎么就剩下重在参与的了，干这行的都哪里去了？
作者: fareast    时间: 2011-9-28 07:11
软件中检测部门大部分都是女性吧，华为的软件研发我很清楚，全球采购便宜的，再加上核心数据集成。
作者: 老兵帅客    时间: 2011-9-28 07:58
fareast 发表于 2011-9-27 18:11
# ?! r! Y" a7 B. ]$ c% ~软件中检测部门大部分都是女性吧，华为的软件研发我很清楚，全球采购便宜的，再加上核心数据集成。 ...

- d/ f! `9 L1 B你说的是做QA的，我说的是软件开发过程中写的检测程序，两回事。
作者: 四处张望    时间: 2011-9-28 11:32
esb那个如果不是全是自己搞，不好这么算，用效率和实效的角度考虑防止扯皮是想不透的。. j- `# J- Y0 m, c
第一个问题其实也是两说，就是不知道这么提倡的家伙是从哪个角度考虑了。
作者: 空气精灵    时间: 2011-9-28 11:50
个人认为, 每一层的检验是必要的,但是,重点应该在于本层所生成的数据,而不是检查前一层送来的数据.
' Q) e) U4 Q4 j9 ~也就是说,需要假设,前一layer/flow送来的数据都是准确的." `. Q1 a7 ?0 f7 B
当然,必要的入口参数exception还是需要设一下的.如果真的发生了exception,那么可以推论是前一layer/flow出错了,让前一层自己去查吧.
作者: mark    时间: 2011-9-28 12:09
老兵说得很有道理的。不过这个还是要看放在什么应用环境下。
5 j/ s9 F4 e" r( L
% j- k0 i0 S% X% T1 {5 T% @对每层数据都校验，有个应用的地方就是中间层和数据层的复用。从复用的角度来说，如果中间层有校验，那么在写表现层时排查错误，处理异常就会相对比较方便。不过我遇到的这种场景情况很少。
" f% j6 [. D' E4 O9 r, w" y* c# @( F8 u& C/ m2 a, I
一般的应用我觉得数据库的内生校验加上表现层的校验，应该基本上足够了。程序能卖钱是因为程序能WORK，而不是因为检测的代码写得多。: _6 ~9 _' K: }( u

: ^! b) Z1 X7 l
! m2 V6 u' |8 a4 d
, {) ]3 n  [. F4 S: U, }
; N3 E$ T# ?' I7 @; h9 g
作者: 大黑蚊子    时间: 2011-9-28 12:46
前Cobol程序员飘过~
作者: 明月回春    时间: 2011-9-28 12:56
。。。
2 n* I0 J7 y5 w我是来重在参乎的5 a; a; [# o2 U7 Y. a3 e
作者: 老兵帅客    时间: 2011-9-28 17:13
本帖最后由 老兵帅客 于 2011-9-28 04:13 编辑 : }  Y9 Z4 ~) X  d% Y+ r
四处张望 发表于 2011-9-27 22:32 ; }. P+ G; Z+ [8 V
esb那个如果不是全是自己搞，不好这么算，用效率和实效的角度考虑防止扯皮是想不透的。) l& g4 B3 E2 s
第一个问题其实也是 ...
; y/ \$ S  z0 e

# Q3 p# R" |5 ~! Gesb那个全是自己搞的，而且预先知道就放在自己的内部机器上。7 j' J' z! v0 }( B# F7 T3 p
( Q4 d- Q, g5 g0 [
作者: 老兵帅客    时间: 2011-9-28 17:18
空气精灵 发表于 2011-9-27 22:50 3 W; y# O' u6 j
个人认为, 每一层的检验是必要的,但是,重点应该在于本层所生成的数据,而不是检查前一层送来的数据.; E5 ?  v1 y! |" ^
也就是 ...
  H3 r4 q( t3 c- P# A& }
嘿嘿，你说的是检测自身的数据而不是前层传递来的数据，这是design by contract的概念，也就是pre-condition。我文中所说的是每一层都重复检测前层的数据，这就是另外一种思路了，没有pre-condition而是边界之外是险恶的世界。
作者: 老兵帅客    时间: 2011-9-28 17:21
mark 发表于 2011-9-27 23:09
. g% W* l0 w/ I( X9 B% ~( C老兵说得很有道理的。不过这个还是要看放在什么应用环境下。  D" Z: K" B0 Z/ n' R5 w

  [) r' O. I1 a8 i对每层数据都校验，有个应用的地方就是中间层 ...

+ [1 K; b& j/ u! q; s我的想法是每层有各自的任务，重复检测没有意义。
作者: 胖子    时间: 2011-9-28 17:33
老兵提到的问题，是不是有一个前提：各层校验的对象是一致的？既从逻辑上来说，数据在各层次间流动时，不发生改变。
( D; o/ H1 T0 |* J: E# v
& l9 W6 z- J; o/ c如果是这样的话，倒确实不用每层都校验。而应把关注点放在数据传递安全上，也就是防篡改。
: C; F4 X0 S" w2 v4 e  M
3 |8 M) c' a0 d  B% s" f% B3 [如果数据流动过程中会变动，那我同意空气精灵的观点。
作者: 四处张望    时间: 2011-9-28 17:41
老兵帅客 发表于 2011-9-28 17:13 0 V; g: {# H5 N$ M
esb那个全是自己搞的，而且预先知道就放在自己的内部机器上。
5 w5 q0 {7 z, t" D! Q3 P! @
理解不能，除非ssl这类都是缺省实现，懒得去掉，否则多个ssl多讨厌。
作者: 老兵帅客    时间: 2011-9-28 19:01
胖子 发表于 2011-9-28 04:33
) ]& p8 w; n8 l4 x. P2 F老兵提到的问题，是不是有一个前提：各层校验的对象是一致的？既从逻辑上来说，数据在各层次间流动时，不发 ...
( {0 [, e5 \6 p3 ^
各层的校验数据是一样的，就是从表示层那里得到的同一个java bean，内容不变。同时因为这是个在同一个java ee server下面运行的web app，不存在数据在中间遭到篡改的可能。
作者: 老兵帅客    时间: 2011-9-28 19:02
四处张望 发表于 2011-9-28 04:41
2 E1 @4 m! O, X( W6 ~( S: W理解不能，除非ssl这类都是缺省实现，懒得去掉，否则多个ssl多讨厌。

2 X( y  P/ H7 W2 h不是的，ssl设置都是要单独做的，而且还是双向ssl，也就是双方互相验证再建立ssl。
作者: 四处张望    时间: 2011-9-29 09:52
老兵帅客 发表于 2011-9-28 19:02
4 T1 `! e0 G) T1 {& k* t; D6 b不是的，ssl设置都是要单独做的，而且还是双向ssl，也就是双方互相验证再建立ssl。 ...

; P/ }! h: g5 n; E6 \& M/ J这个不就是等于保险箱里面再加吧锁吗，追求小数点后面的几个0呢？
作者: 老兵帅客    时间: 2011-9-29 09:59
四处张望 发表于 2011-9-28 20:52
' `- m7 q0 Z* o- B这个不就是等于保险箱里面再加吧锁吗，追求小数点后面的几个0呢？
0 M4 I2 z5 c- k4 N$ p! ^" W- B) b
没办法，安全这个领域太敏感了，多些安全总比少些强
作者: 四处张望    时间: 2011-9-29 10:14
老兵帅客 发表于 2011-9-29 09:59 . q: w1 l; h$ w9 I
没办法，安全这个领域太敏感了，多些安全总比少些强

4 B. y$ j; W/ \, [! ]/ q- O. c+ ?0 w不过计算性能开始不值钱了，多点安全拖累性能无所谓，不要多人工就好。
作者: 猫元帅    时间: 2011-9-30 08:47
专业词汇一个不懂，但是意思大概明白了。  A/ `  Y: p  g) \

5 X0 q8 _1 j5 x4 k$ \. ~! d就是帅克同志认为在1－2－3递进的情况下，2和3不会发生超出1的BUG。所以只要1做得完善，检测1就足够了，用同样的方法检测2和3是一种浪费。不能为了检测而人为改变1的设置，因为1－2－3是递进的关系。
* [/ |! V% b/ N: _1 \! b
* _8 o( b" x! T% N. U) M- B( H2 e简单说就是不能为了检测而检测。
作者: 老兵帅客    时间: 2011-9-30 09:16
猫元帅 发表于 2011-9-29 19:47 0 u4 c- F5 C* S! e( K" ~8 t5 Z, |/ [
专业词汇一个不懂，但是意思大概明白了。
0 N9 O1 I; z9 d: P6 l' `* @. M
2 N8 L9 O( o' Y& y! C* }$ x1 Q就是帅克同志认为在1－2－3递进的情况下，2和3不会发生超出1的BU ...
2 y; ^* H  ]" Y' i
对，不应该做多余的事情
作者: ImaNut    时间: 2011-9-30 21:46
小绿爷 发表于 2011-9-27 22:17
/ F! @( c* |& k. X. A隔行如隔山，对我而言基本看不懂
! I! d" u% y; c7 [* A
就好比一座办公楼，大门口一把门的，电梯一守卫，你办公室门口又是一位，连厕所那儿也摆一位，进出都查ID。理由是有人能钻窗户进来。
作者: 老兵帅客    时间: 2011-9-30 22:40
ImaNut 发表于 2011-9-30 08:46 # J5 @  z- _, m. Y' p* d
就好比一座办公楼，大门口一把门的，电梯一守卫，你办公室门口又是一位，连厕所那儿也摆一位，进出都查ID ...

) {! u% |8 P: X# W5 `$ @$ t5 [% d问题是这大楼根本没窗户也要这么干，那就是多此一举了。
作者: 牌牌    时间: 2011-10-1 17:01
作为一个前C++程序员表示理解起来压力不大。
# y* Z/ ?5 Q) C& m现在的软件工程为了提高代码的重用性和可靠性，要求各个代码模块对所有的输入都进行合法性检查以保证业务逻辑的正确运行，所以CPU内存增长的再快，也不扛不住做总是在做无用功的软件啊。
作者: 老兵帅客    时间: 2011-10-1 20:29
牌牌 发表于 2011-10-1 04:01
' ]$ {0 R" W% Z- V9 \作为一个前C++程序员表示理解起来压力不大。1 Q8 @' c$ }  D4 @" l3 u' R
现在的软件工程为了提高代码的重用性和可靠性，要求各个代码模 ...

$ }% {  T% ^$ b! N( U6 j的确如此。
作者: ekid    时间: 2011-10-1 21:10
怎么软件也像协议分层吗？
作者: sky100    时间: 2011-10-1 23:55
看你怎么看这个问题了。现代的软件工程都是多人甚至多团队合作型，万一其中的一个模块外包到印度去，那边的开发人员乱写一气，污染了数据，然后下一级别的模块没有做数据效验怎么办？现实世界中总是有各种意外的。当时觉得没必要的事情，过几年之后可能会觉得是重要的。
2 Q$ U% b9 @$ V, C- n& K! G1 V! Q/ T2 W) Z
从架构设计的角度来说，这样做对于扩展性很有好处。比如，现在你只用一台机器跑所有的web service.可是明天用户忽然增多，一台机器撑不住了，必须多台机器集群作战。这时这样做的好处就出来了，软件层面基本上不用作修改就可以分布到多台机器上用。如果象你想的那样内部通讯不需要安全验证，那么扩展起来还需要重新作安全验证，这样又会从另一个方面来增加工作量。是机器便宜还是开发人员的工资便宜呢？Really depends.6 w, N5 E: _, z5 U* G: b
# P3 @/ x& S: k+ w  z
很多时候设计决策本身就是一个trade off.
1 I  d* \8 k! i2 a+ @' ?% a3 G4 n3 s7 _: s' q8 ]$ _

; d  T. L: f# Z! t) B
作者: 老兵帅客    时间: 2011-10-2 04:13
ekid 发表于 2011-10-1 08:10
8 G1 n. f1 o0 [怎么软件也像协议分层吗？

: s7 J6 @$ O6 p; ?是啊，一直都是这样做的
作者: 老兵帅客    时间: 2011-10-2 04:15
sky100 发表于 2011-10-1 10:55
  X* Z1 L: g) `5 w' r看你怎么看这个问题了。现代的软件工程都是多人甚至多团队合作型，万一其中的一个模块外包到印度去，那边的 ...
. O! ]& Q9 ~. g$ @% F2 Q, ~# w
第一。测试是干什么的？
! H' q8 B' a+ s7 k( k' s+ @/ t! g* q' D6 e- B9 q. ]
第二。如果那堆web service根本不可能被deploy到外网呢？6 C4 y; P) R) K' ~% f7 o

; h& ]" a3 c% g$ d我明白你的意思，但是这个trade off理论上很合理，现实中则根本没有得益的时候，而成本却肯定在那里。
作者: 一瞬无尽    时间: 2011-10-2 17:53
这种每层都验证数据的做法我觉得没错& S/ Y% ~+ `2 Q0 l5 d- B1 D
测试的做法我觉得似乎可以改进：通过修改下层的实际代码进行测试，这似乎过分了些
& o- N! _6 m; l0 V0 r( Z我不了解实际情况，觉得似乎可以干脆另写测试代码，模拟下层专门发送错误数据给上层，不然每次测试都修改生产代码，太麻烦太浪费了' C' V5 g  m1 K4 p- W

& @" j& q% X& A4 L" I$ X4 n' a我如果是上层写代码的，宁愿自己写这个测试也说不定，当然能安排给下层是最好了
作者: 老兵帅客    时间: 2011-10-2 18:56
一瞬无尽 发表于 2011-10-2 04:53 & e* H* n: s( t: q8 z) s8 w5 a) y+ d
这种每层都验证数据的做法我觉得没错
4 p/ M/ K1 {/ U% H& p: p测试的做法我觉得似乎可以改进：通过修改下层的实际代码进行测试，这 ...

0 Y: c% e$ J0 H1 x( _8 H% NGood, you do that
作者: 老兵帅客    时间: 2011-10-2 20:51
一瞬无尽 发表于 2011-10-2 04:53
" q! I1 Z9 S; C7 ]这种每层都验证数据的做法我觉得没错
) Q2 q2 B4 {; Q7 Q; Q4 s测试的做法我觉得似乎可以改进：通过修改下层的实际代码进行测试，这 ...

" t9 ]+ K. j. M- z8 [6 A0 r其实说起来，这个就看怎么做了，做得好的话是可以灵活配置的，也就是需要的话enable检测代码，否则disable掉就是。具体说来就是利用framework的能力，例如struts2的interceptor，可以做出几乎不带来额外开销而非常实用的检测程序来。
作者: sky100    时间: 2011-10-3 05:34
本帖最后由 sky100 于 2011-10-3 05:46 编辑 + O. b$ Z: Q, I8 n/ ?1 P) b  c) Z
老兵帅客 发表于 2011-10-2 04:15 1 Z7 a: c9 j, _; u1 `# k
第一。测试是干什么的？; }# P+ h" R2 @: b; k# U2 E! D

0 U" L: ]) m5 u5 Y7 ?8 T7 g  E第二。如果那堆web service根本不可能被deploy到外网呢？
1 p; ^' y4 J7 ^

. e  Q# A; S( `7 B: r, r第一，绝大多数测试不可能覆盖所有的可能性。如果代码测试后放到生产环境中，结果因为某个特殊的情况，数据效验没有做而导致出了问题。应该是没有听从架构师要求去添加效验的开发人员的错，还是测试人员的错呢？" l: h& n& \2 k; u7 F6 i

) e! K1 p, n. m9 ^7 K, z第二，我的看法是，除非公司的ceo拍胸脯给打保票，否则你never know.商业需求总是在不断变化的。从架构设计的角度，假设你是架构师，你是宁肯多加些冗余来保证系统的鲁棒性和可扩展性呢？还是为了减少开发人员的
4 Y3 q1 S. S% _9 c# K工作量并给人力资源部制造裁员的借口而不重复校验呢？
" D9 R4 i& I: N+ R/ u9 y$ {% V* }$ r5 Y2 g: ^+ Q
老兵兄，你所提到的事情设计者未必没有想到，只不过他可能得到的信息和考虑的可能性要比你多，权衡之下采取的这个决策。而有些信息和可能性不适合公开讨论而已。换句话说，很多问题之所以不可以使用简单直接的方案是因为这个问题不仅仅是技术问题而且也是一个政治问题：）
+ i0 U9 P7 m; @/ O# H. ]) Y, _
2 G5 t  n; C# l* n2 G; l& ~$ Q我个人的一点陋见，搏大家一笑，请轻拍：）
" J; `, I% H/ E& m1 S! W0 S9 ]5 w
, s" f& z7 {+ _! v) P+ u
; l: z1 _/ y1 A* M% ~3 v
' j( J7 p& n# S4 Z! c  U
* }, ]7 N, ?* b7 v0 M
  Z5 s1 G( Z) x9 ^: M
, Q# `! D& ~! v& t- q( r3 f. Y
作者: 老兵帅客    时间: 2011-10-3 05:40
sky100 发表于 2011-10-2 16:34 4 b# X1 K  ~' g# [" T  y
第一，绝大多数测试不可能覆盖所有的可能性。如果代码测试后放到生产环境中，结果因为某个特殊的情况，数 ...
' q8 P# y, S- N" t0 g" e
说了这么多，其实很简单，决策者在逃避责任而不是保证质量与效率。因为重复的检测不会提高质量而却会增加开销和降低性能，但是在出了问题推诿的时候，那就是个优点了，因此这不是技术人而是政客考虑的事情。' ?- }0 ^( K. N; V! L! j8 J

# d& }* d8 q7 {, I这里的关键在于你所说的那些可能性在现实中几乎不可能出现，而成本却是必然而无法减免的，这样有成本而无收益的把戏除了出于政治需要谁会喜欢？
3 c, U+ v+ P# Z2 n: }6 s2 F
1 P# J0 z! Q8 p" ^再多就变成政治扯淡了，到此为止吧。
作者: wolfsquare    时间: 2011-10-3 08:46
看来楼主并不明白什么叫最佳实践
作者: sharepoint    时间: 2011-10-3 14:11
其实，说到底就是一个权衡的问题
' W$ t6 r3 y1 J6 j1：如果一个系统重要到影响到公司的生死存亡，面面俱到，行万全之道不算为过
  S( u. ]& R. G% M& B2：如果预算允许，多做一点检查也不错+ B1 \, n8 s3 h/ o/ a0 g6 h& p
3：如果用户需求没有要求，架构师加冗余来保证系统的鲁棒性和可扩展性，就有点画蛇添足。
9 b. g3 K  I4 ]* W5 o0 U4：Best Practice和Guideline，SOP还是有差别的。
" _# y1 y* z9 F0 m6 d5：很多情况，不是技术决策，而是管理决策。
作者: 老兵帅客    时间: 2011-10-3 19:57
sharepoint 发表于 2011-10-3 01:11 + I8 `* }& j  g1 Q( W! D
其实，说到底就是一个权衡的问题! ]* Z. ?( O+ v( }' _1 f" ]! ~
1：如果一个系统重要到影响到公司的生死存亡，面面俱到，行万全之道不算为 ...
7 B# a6 d: c: [6 e8 A' N
right, right
作者: 老兵帅客    时间: 2011-10-5 06:22
说一下我为什么写这篇东西吧。6 t' i) y4 w; }" g1 ^2 }
2 u3 C2 S9 b8 K1 k
各位的回复我都看了，道理上完全对，但是现实中就不一定了，为什么，听我说哈。+ u: h+ f5 H4 G* r' Z( u

; N) Q' R5 }, t" E1 R( v我现在的项目组，来了位高人，动辄Best Practice，一套一套地，什么framework跟什么类库搭配，都说得很清楚。只有一个问题，大家都知道那些东西不能搁在一起滴，否则会有版本不兼容问题，而公司又不允许未经充分测试的修改版投入使用，于是真要用的话就只能是一塌糊涂喽，而这位不知道，还在那里狂侃。可是老板还信他，要求大家听他的，于是大家就难受吧，因为根本就配不通，更不用说具体去用了。
6 n% e; W# L0 u/ E, k8 V
# }  r2 N( ?# I! m6 M我们这里有一位狠主在给他挖坑，我们看着，谁也不说话，就等着开壶那天看热闹。* @9 q6 L) y- j

$ `: R; u; O0 B当然了，这位高人叫嚣的可不是我上面写的那点东西，充分的模块测试、重复的安全设置对他来说太小儿科了，显不出他的水平。那么干的都是些庸人，人家根本看不上滴，人家要干就干大的，或者一家伙把自己臭大街完事。
作者: mark    时间: 2011-10-5 16:44
老兵帅客 发表于 2011-10-5 06:22 6 h" [/ f) n+ v- X$ b3 W7 l/ N
说一下我为什么写这篇东西吧。
, p2 S3 _9 J+ f' K  \3 B4 `( X" z2 L9 s3 L# _3 z& A8 k( U
各位的回复我都看了，道理上完全对，但是现实中就不一定了，为什么，听我说 ...
2 j3 [5 O; g- V( W( `7 `, G
最恨这些纸上谈兵的家伙。; I9 v5 t! ]/ }2 @! N# }

$ \: A7 V- Q$ T; T; G我原来公司有两个家伙忽悠老板引入RATIONAL ROSE做项目，把大家搞得苦不堪言。最后项目没做好，那两个家伙倒是长了经验值，直接跳槽走人。
作者: Radiohead    时间: 2011-10-5 23:40
老兵帅客 发表于 2011-9-28 17:21 , W* X! Z7 O4 Q7 i, |5 q+ E
我的想法是每层有各自的任务，重复检测没有意义。
: r& h2 K2 }% }+ Q4 L
认同。 讨厌重复的代码，讨厌重复的逻辑。UI层尽量少的biz logic。



欢迎光临 爱吱声 (http://aswetalk.net/bbs/) Powered by Discuz! X3.2