|
|
本帖最后由 晨枫 于 2025-8-19 17:13 编辑 . @+ Y2 D6 E- Q; f7 c i8 O
; d9 l; [7 r( l! P3 c7 \" V9 h6 |因为工作需要，当年曾参加了一个相当大的编程项目，项目“遗产”后来被“DCS大二”之一“继承”成为他们的主力产品了，我则有幸参加当年的架构设计。# U3 W5 a y, i b0 p4 h3 m9 `
# P4 C, f9 u. C" Z2 [- w: }
我的老东家是干化工的，不是干DCS的，更不是干IT的。但我们有长期的用户端经验，不仅对于功能设计有自己的想法，对于架构和模块设计也出于长期使用、维护、扩充经验有自己的想法。再说，我们不是甲方嘛。
# A7 ?4 z' v& K" S3 ?
5 p0 D7 t: j3 t- |1 r+ X$ ~* _在架构设计初期，就和对方的研究中心挂钩，去他们那里参观的时候，大门赫然摆着“欢迎F-22团队xxx”。那是90年代中期。但研究中心在“40000英尺之上”，不接地气，还是需要落实到具体的硬件、软件、可见产品原型才行。
+ e6 v% p* W) F
9 f$ X0 w" x- Z. I9 B干大设计也要自己先动一遍手。把架构搭起来，主要模块写起来，大致跑通，然后才能和乙方谈。否则轻易就get snowed。也就是说，被对方的花言巧语或者术语套话哄晕了。- e4 J3 ~! F0 D1 \8 X3 E5 F$ K8 l& V
* J$ |2 X, `/ i6 Z5 }
作为原型（prototype），用Visual Basic，容易上手，容易验证，容易展示，尽管效率比VC低。在后来的产品化中，VB留下来了，依然作为基本编程环境。
- l0 K; T9 F% r _6 I+ g; T
, d0 V8 l v# C' A) T1 z$ |# o' V结构化原则大家都学过，没有秘密。5 X# h. p0 u, e: S9 W
% W. m& y9 ?6 x* o6 d' w
初步的架构、模块经过一番艰苦奋战，最终有点样子了。总体设计看起来高瞻远瞩、云淡风轻，实际上高度费脑子。不仅要站得高看得远，还要4万英尺高空一路看到地面，否则一致性甚至可实现性最终会给你狠狠的打脸。具体的功能模块划分既不能太粗犷，又不能太细碎。这跟造房子一样，琐碎到砖块或者粗略到楼宇的层次就谈不上模块化了。2 c7 t- Z) `* {( d3 x* O1 H
) f, M! a$ q3 ?# b/ [! K有了初步的架构，就可以和乙方谈了，然后他们找到了印度的塔塔集团，作为最终具体执行的外包商。塔塔有经验，开价低，就是他们了。$ z F8 _9 [' l. w$ v
% Y, x r( L. E4 V, F" I然后就是不断的反馈、评审、再反馈、再评审。* h8 G3 k- u# \
0 k2 q( [& s( t2 U: i' U; J每一次反馈都有详细的文档记录，要求修改的东西，最后修改了什么，都有详细记录。) \" d6 \3 k+ K9 R) _# X- @& w$ G7 O
2 _, l& J0 g9 C! M* e1 r2 N7 F
每一次评审不光要在机器上跑一遍，我们还要读代码，力图理解，有时还有纠错，更有时忍不住优化一下。
. a3 k3 |& {6 r7 B3 H5 ?% K' Q& C6 e% H2 J
必须说，印度人听仔细的，文档很规范、很全面，但读起来也很乏味，要不睡着真是大挑战。但读和审代码才反映了中印工程教育思维的差异。9 g7 ]4 @# R6 v1 n& k
8 l. e, b9 m) `3 u* S- l1 @0 ]1 V- J中国和印度学生在北美都以理工科强而著称，都号称数学好。数学有两大特点：
$ w7 ?& c2 ]; K+ n8 }0 D
O& E7 P- [7 q8 O$ M) ]$ X2 U1、严谨
4 U1 X t t6 r: \2、抽象
4 r- Y, g- T2 n* A" G: ?
( A+ |7 K x5 b# @4 x严谨大家都没问题，不严谨的数学过不了关，谁也骗不了谁。抽象是不同的问题。在解题层面，不需要抽象能力。但要从已知推导到未知，需要抽象能力，以“提炼精髓”，才能更上一层楼，看到以前看不到的东西。否则顶多是新的推论，不是新的定理。
0 l0 j( A& A2 n; J" g
" s5 Z+ q ], |5 `, x: c. b1 i中国式工程教育长从first principles出发，强调基本概念和基本理论，以及体系和思路，所以“中国式编程”常有“过度优化”的问题：从first principles出发，不必要的东西一概砍掉，这种极简主义符合中国式工程师的“审美”，但未必符合模块化、可扩充性的要求。' ~2 X% \% B+ F+ ] l4 k
1 [6 m# p& Q7 R4 |7 t
印度式工程教育说不好是否重视first principles，但特别注重在现有架构下添砖加瓦，反映到编程，高度强调结构化和模块内的完整性，不惜叠床架屋。为了标准化，可以同样的东西反复declare，可以同样的功能反复build in。中国同行看到会忍不住优化一下，但实际上还真是可能损坏模块的通用性和portability。+ c4 b& I. Z6 r& G
8 ?; z; F" f. @4 }/ T4 ]# H$ B1 u A
最后比较塔塔他们反馈回来的软件，他们帮我们重新梳理了整体架构，这是必须的，我们只是几个人手搓、用来示意的prototype，他们有更加完整的团队和产品化经验，这个要听他们的。prototype也只需要很小的case base，实际工业软件需要面对大得多的输入输出、调用时间、运行可靠性等挑战。这好比模型飞机和轰-20的差别。. R, h3 c+ u( H% Y1 g
: d, v" p1 N2 F( d3 u( b但印度人的编码感觉有浓浓的comformity味道，对等级、规则的敬畏和尊崇。原则、架构、规矩就是原则、架构、规矩，“管用、好用”当然重要，但要是“管用、好用”影响原则、架构、规矩，那就修改什么才是“管用、好用”。这或许是一种“过程导向”思维。: e/ U& x) x: {8 s9 a% A' V
& A! m3 _- V' J( T9 L" P/ M
相对来说，中国人的编程里就有“我的程序我做主，极简才是最美的”。原则、架构、规矩都是“参考”，一切以“管用、好用”为准则。要是原则、架构、规矩影响了“管用、好用”，那就修改原则、架构、规矩。这是典型的“结果导向”思维。
$ w% r; R( ?# ^
t+ v0 K& }+ K: d0 ~6 X这可能是从first principle出发的工程思维和从对架构的compliance出发的工程思维的差异？
" g# H3 N* A$ j% L* A. j ^2 z1 d
9 g6 F: i; }2 I( m其实，我自己都没有想清楚我想说啥，随手写下来，准备接受批判。说不定批判着，反而想明白自己到底想说啥了。 |
评分
-
查看全部评分
|
雷达卡
楼主
收藏
分享
淘帖
支持
反对
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡
发表于 2025-8-20 04:32:32
`* B+ [. W h: j1 Y) }
发表于 2025-8-20 07:37:56