|
本帖最后由 晨枫 于 2025-8-19 17:13 编辑 % U- U( T+ A* G$ v3 Z& J
8 ^( l" {1 c5 F
因为工作需要,当年曾参加了一个相当大的编程项目,项目“遗产”后来被“DCS大二”之一“继承”成为他们的主力产品了,我则有幸参加当年的架构设计。
5 b6 A' j' q% z
# E. O2 y6 Z/ J我的老东家是干化工的,不是干DCS的,更不是干IT的。但我们有长期的用户端经验,不仅对于功能设计有自己的想法,对于架构和模块设计也出于长期使用、维护、扩充经验有自己的想法。再说,我们不是甲方嘛。
' H$ |8 P' w6 J' M2 k& s$ z/ J! V8 E) S' k- y+ a2 Z! `1 o) i9 k
在架构设计初期,就和对方的研究中心挂钩,去他们那里参观的时候,大门赫然摆着“欢迎F-22团队xxx”。那是90年代中期。但研究中心在“40000英尺之上”,不接地气,还是需要落实到具体的硬件、软件、可见产品原型才行。
# b2 z2 L, j7 S% f/ e" O y: C7 E' D2 m5 m; q# j1 {5 o6 [( o" k
干大设计也要自己先动一遍手。把架构搭起来,主要模块写起来,大致跑通,然后才能和乙方谈。否则轻易就get snowed。也就是说,被对方的花言巧语或者术语套话哄晕了。! C1 {4 l' `4 Q6 ~. q; W
7 j% M$ O5 P* S9 Q! O z' ~* R( k C9 N2 r作为原型(prototype),用Visual Basic,容易上手,容易验证,容易展示,尽管效率比VC低。在后来的产品化中,VB留下来了,依然作为基本编程环境。" r* J) r9 H. r$ p6 X
. s7 a; K+ S4 b3 v4 R
结构化原则大家都学过,没有秘密。
# O+ z( ^5 E: L* a y4 R9 N( o% Z7 g9 _& M' c, G9 s8 X
初步的架构、模块经过一番艰苦奋战,最终有点样子了。总体设计看起来高瞻远瞩、云淡风轻,实际上高度费脑子。不仅要站得高看得远,还要4万英尺高空一路看到地面,否则一致性甚至可实现性最终会给你狠狠的打脸。具体的功能模块划分既不能太粗犷,又不能太细碎。这跟造房子一样,琐碎到砖块或者粗略到楼宇的层次就谈不上模块化了。
8 Y, ~$ \* [* _( v8 ~2 x* G2 E& l1 r
6 u3 b9 X5 r! [; x F# k+ f有了初步的架构,就可以和乙方谈了,然后他们找到了印度的塔塔集团,作为最终具体执行的外包商。塔塔有经验,开价低,就是他们了。( f5 f6 ^& z$ H, s: j5 I4 p7 M
1 V, z' }9 W* ^然后就是不断的反馈、评审、再反馈、再评审。2 c( D; G( k) w& c
; m/ l) ~# p C" b+ j: J, _6 g# M& E5 w每一次反馈都有详细的文档记录,要求修改的东西,最后修改了什么,都有详细记录。" P; s7 q) q W8 p2 D; X
" j% M9 o/ R2 a: L v+ o' A每一次评审不光要在机器上跑一遍,我们还要读代码,力图理解,有时还有纠错,更有时忍不住优化一下。
/ `0 H3 _. R8 O3 g% C: ?5 ?7 {% ~
6 @0 k# n2 c2 z4 n必须说,印度人听仔细的,文档很规范、很全面,但读起来也很乏味,要不睡着真是大挑战。但读和审代码才反映了中印工程教育思维的差异。, {( C3 l* D5 E" h5 j6 l' J
! @' h5 H4 t& U5 B2 K+ G M
中国和印度学生在北美都以理工科强而著称,都号称数学好。数学有两大特点:6 i$ G- {# }0 l1 b9 o( G+ \
1 g$ j. W/ O$ F: q( e2 ]9 a1、严谨
' s8 K4 K6 j% N0 r2、抽象
& V% H/ }$ Y) j6 q; k8 f2 G3 B6 t0 V/ Z" V, E
严谨大家都没问题,不严谨的数学过不了关,谁也骗不了谁。抽象是不同的问题。在解题层面,不需要抽象能力。但要从已知推导到未知,需要抽象能力,以“提炼精髓”,才能更上一层楼,看到以前看不到的东西。否则顶多是新的推论,不是新的定理。
! ?8 @& ?, N4 B7 t9 g- O4 s
; y( B9 P# d! W中国式工程教育长从first principles出发,强调基本概念和基本理论,以及体系和思路,所以“中国式编程”常有“过度优化”的问题:从first principles出发,不必要的东西一概砍掉,这种极简主义符合中国式工程师的“审美”,但未必符合模块化、可扩充性的要求。
+ g/ K$ Y4 [9 w- y$ i! I* Q
5 n$ V) _# I+ J) a' K印度式工程教育说不好是否重视first principles,但特别注重在现有架构下添砖加瓦,反映到编程,高度强调结构化和模块内的完整性,不惜叠床架屋。为了标准化,可以同样的东西反复declare,可以同样的功能反复build in。中国同行看到会忍不住优化一下,但实际上还真是可能损坏模块的通用性和portability。
, o, T; s, ]' L/ N; L$ {% x! V! r7 w8 h
最后比较塔塔他们反馈回来的软件,他们帮我们重新梳理了整体架构,这是必须的,我们只是几个人手搓、用来示意的prototype,他们有更加完整的团队和产品化经验,这个要听他们的。prototype也只需要很小的case base,实际工业软件需要面对大得多的输入输出、调用时间、运行可靠性等挑战。这好比模型飞机和轰-20的差别。5 H; v, q7 ~! Y
V7 I, }1 a; n* P# H& q+ \9 g但印度人的编码感觉有浓浓的comformity味道,对等级、规则的敬畏和尊崇。原则、架构、规矩就是原则、架构、规矩,“管用、好用”当然重要,但要是“管用、好用”影响原则、架构、规矩,那就修改什么才是“管用、好用”。这或许是一种“过程导向”思维。
, S8 S5 _1 P3 I) J( s- i1 G) {7 X9 f4 S" ]: y- q, W# ~0 [
相对来说,中国人的编程里就有“我的程序我做主,极简才是最美的”。原则、架构、规矩都是“参考”,一切以“管用、好用”为准则。要是原则、架构、规矩影响了“管用、好用”,那就修改原则、架构、规矩。这是典型的“结果导向”思维。& o D+ B! U/ a! D4 _+ t
0 U( |7 o5 b6 B# \+ b8 G1 U! ^这可能是从first principle出发的工程思维和从对架构的compliance出发的工程思维的差异?
6 P2 c6 L+ C, n5 v4 a8 O3 Q1 i6 U* r1 d. ]( J
其实,我自己都没有想清楚我想说啥,随手写下来,准备接受批判。说不定批判着,反而想明白自己到底想说啥了。 |
评分
-
查看全部评分
|