因為工作需要，當年曾參加了一個相當大的編程項目，項目“遺產”后來被“DCS大二”之一“繼承”成為他們的主力產品了，我則有幸參加當年的架構設計。
我的老東家是干化工的，不是干DCS的，更不是干IT的。但我們有長期的用戶端經驗，不僅對于功能設計有自己的想法，對于架構和模塊設計也出于長期使用、維護、擴充經驗有自己的想法。再說，我們不是甲方嘛。
在架構設計初期，就和對方的研究中心掛鉤，去他們那里參觀的時候，大門赫然擺著“歡迎F-22團隊xxx”。那是90年代中期。但研究中心在“40000英尺之上”，不接地氣，還是需要落實到具體的硬件、軟件、可見產品原型才行。
干大設計也要自己先動一遍手。把架構搭起來，主要模塊寫起來，大致跑通，然后才能和乙方談。否則輕易就get snowed。也就是說，被對方的花言巧語或者術語套話哄暈了。
作為原型（prototype），用Visual Basic寫，容易上手，容易驗證，容易展示，盡管效率比VC低。在后來的產品化中，VB留下來了，依然作為基本編程環境。想過改VC或者Java，一來二去，VB還是保留下來了。
結構化原則大家都學過，沒有秘密。
初步的架構、模塊經過一番艱苦奮戰，最終有點樣子了。總體設計看起來高瞻遠矚、云淡風輕，實際上高度費腦子。不僅要站得高看得遠，還要4萬英尺高空一路看到地面，否則一致性甚至可實現性最終會給你狠狠的打臉。具體的功能模塊劃分既不能太粗獷，又不能太細碎。這跟造房子一樣，瑣碎到磚塊或者粗略到樓宇的層次就談不上模塊化了。這些都是干一遍才能真體會的原則，而不是書本上的空談。那其實也不是空談，只是沒法說清楚那個“度”，只有面對實際問題、干過，才真有體會。
有了初步的架構，就可以和乙方談了，然后他們找到了印度的塔塔集團，作為最終具體執行的外包商。塔塔有經驗，開價低，就是他們了。
然后就是不斷的反饋、評審、再反饋、再評審。
每一次反饋都有詳細的文檔記錄，要求修改的東西，最后修改了什么，都有詳細記錄。
每一次評審不光要在機器上跑一遍，我們還要讀代碼，力圖理解，有時還有糾錯，更有時忍不住優化一下。
必須說，印度人挺仔細的，文檔很規范、很全面，但讀起來也很乏味，要不睡著真是大挑戰。但讀和審代碼才反映了中印工程教育思維的差異。
中國和印度學生在北美都以理工科強而著稱，都號稱數學好。數學有兩大特點：
1、嚴謹
2、抽象
嚴謹大家都沒問題，不嚴謹的數學過不了關，誰也騙不了誰。抽象是不同的問題。在解題層面，不需要抽象能力。但要從已知推導到未知，需要抽象能力，以“提煉精髓”，才能更上一層樓，看到以前看不到的東西。否則頂多是新的推論，不是新的定理。
中國式工程教育長于從first principles出發，強調基本概念和基本理論，以及體系和思路，所以“中國式編程”常有“過度優化”的問題：從first principles出發，不必要的東西一概砍掉，這種極簡主義符合中國式工程師的“審美”，但未必符合模塊化、可擴充性的要求。
印度式工程教育說不好是否重視first principles，但特別注重在現有架構下添磚加瓦，反映到編程，高度強調結構化和模塊內的完整性，尤其是對現有架構和模塊的絕對尊重，不惜疊床架屋。為了標準化，可以同樣的東西反復declare，可以同樣的功能反復build in。中國同行看到會忍不住優化一下，但實際上還真是可能損壞模塊的通用性和portability。
最后比較塔塔他們反饋回來的軟件，他們幫我們重新梳理了整體架構，這是必須的，我們只是幾個人手搓、用來示意的prototype，他們有更加完整的團隊和產品化經驗，這個要聽他們的。prototype也只需要很小的case base，實際工業軟件需要面對大得多的輸入輸出、調用時間、運行可靠性等挑戰。這好比模型飛機和轟-20的差別。
但印度人的編碼感覺有濃濃的comformity味道，對等級、規則的敬畏和尊崇。原則、架構、規矩就是原則、架構、規矩，“管用、好用”當然重要，但要是“管用、好用”影響原則、架構、規矩，那就修改什么才是“管用、好用”。這或許是一種“過程導向”思維。
相對來說，中國人的編程里就有“我的程序我做主，極簡才是最美的”。原則、架構、規矩都是“參考”，一切以“管用、好用”為準則。要是原則、架構、規矩影響了“管用、好用”，那就修改原則、架構、規矩。這是典型的“結果導向”思維。
這可能是從first principle出發的工程思維和從對架構的compliance出發的工程思維的差異？
其實，我自己都沒有想清楚我想說啥，隨手寫下來，準備接受批判。說不定在被批判中，反而想明白自己到底想說啥了。
