第一千二百二十一章 效率

    周至這一刻感動得一塌糊塗，要求老學人將觀念轉變過來，實在是太難了。

    但是老學人也有兩個特別優良的作風，第一就是實事求是，第二就是聞過即改。

    知道不對還因爲面子，因爲“尊嚴”死當犟種，這種事兒他們也做不出來。

    後世人少了他們的嚴謹，也少了他們的調查和研究，拿着所謂的“邏輯分析”就認爲萬能，殊不知前提條件不足或者不對的情況下，邏輯越正確，結果往往越荒謬。

    然而犟種們往往還振振有詞，你看我的條件一二三是正確的吧？我的邏輯推導是正確的吧？那我的結果，怎麼還可能是錯誤的呢？

    他就完全沒有考慮到雖然條件一二三是正確的，但是還有他不知道的四五六會予以持續修正，把所有條件都帶入完備後，還是用他自己那套邏輯，推導出來的結果都可能完全不同。

    舉個簡單的例子，關於古代科舉，有人經過調查，發現絕大多數舉子家裏田地十幾畝到百畝佔了百分之七八十，因此就得出古代能夠有條件參加科舉的人都是大地主階級，因此選拔出來的官員都是維護地主階級利益的集團成員，這就是封建王朝得以維繫的關鍵。

    然而只要他再查一查書籍就能夠發現，佔地十幾畝到一百畝，在近現代倒勉強夠得上地主的資格，在古代卻完全不是這麼回事兒。

    唐代授田一丁百畝，一戶五口三丁，就得是三百畝一家。

    宋代太祖巡視京周，發現一丁三十畝就焦慮得不行，回到宮裏坐立不安。

    所以在這兩個朝代裏，家裏有田產十幾畝到百畝的，最多只能算是那個時代的中產之家而已。

    而中產之家在任何時代，都是國家的韭菜，也是社會的中堅，這才是歷史的正確結論。

    因此要是不知道古代田畝制度，就是缺少了條件四，然後用他有限的認知去套邏輯推演，那就是條件也正確，邏輯也正確，結果偏偏卻是錯誤的。

    後世網絡上的種種爭議，其實很多都是由此而起，到後來大家也開始變得聰明了一些，那就是“讓子彈多飛一會兒”，等待條件充分後再推導結論。不然一不小心就要被打臉。

    但這也是吃虧吃多了學會的自我修正，現在網絡時代都還沒有開始呢，因此麥明川能夠及時修正自己的認知，站在周至這一邊來，就屬實是難能可貴。

    幹技術的人還有一個好處，那就是只認效果，認能力和本事兒。

    周至無疑是具有能力的，明明是一個文科生，可無論是提起大字庫的概念，還是提前搞起字碼，搞起識別程序，不管是搞工程管理還是編寫代碼，居然都算得上是一把好手。

    周至第一次來機房，給自己的字碼識別程序上機，當場改寫接口程序並且一次性編譯通過的故事，都要給軟件組傳成神話了。

    剛剛幾個大佬說的那一堆，到現在了幾個組長要是都還不明白其中的道理，那都配不上考進大學來的智商。

    的確，要是沒有周至反復強調要求他們準備的那些工藝文件，估計UNICODE組織都不會瞧上他們，而微軟和IBM也不會這麼好說話。

    要是沒有國際專利這一手，人家直接將瀚文字庫拿去當成自己的，反手給你來個搶注，用蜀中的老話講，那才真是“捏着鼻子打不出噴嚏”，只能安慰自己爲人類進步做貢獻了。

    現在的效果就完全不一樣，光專利授權和周邊產品合作生產，大家都獲益豐厚，周至甚至需要建一個公司來“消化利潤”，將之變成產學研一條龍的樣板。

    俗話說的“吃人嘴短，拿人手短”，在座的對周至基本都是又吃又拿，平時插科打諢的嘲諷，思想碰撞討論激烈了拍桌子打板凳都沒問題，但是大家都是在就事論事，真正做到只論對錯不講輸贏，目的都是爲了找到最佳的問題解決方案，然後就是散會約飯找地方的事兒。

    都不是笨人，主要是之前游擊戰打滑手了，不太習慣正規軍陣地戰的模式，經過瀚文大字庫一期的培訓，用周至的話說那就是換頭豬來老子都手把手教會了。

    再加上現在形勢緊迫，也由不得大家自由散漫了。

    之前周至幾次想要推動這項工作，但是架不住任務緊張，加上習慣沒有養成，常常不得不採取妥協辦法，讓自己累一點，把軟件組交上來的那些一看就敷衍了事狗屁不通的玩意兒，修改到可以進入工程文檔庫。

    這東西其實也是有套路的，可以套用模板，爲了教會這羣豬，周至又將各種工程文件的模板給歸納了出來，讓豬們使用起來感覺和編程差不多，方便快捷。

    到現在也差不多到了能夠脫手的時候，接下來周至又將幾個工藝文件的模版給大家翻了出來，給大家再做一次培訓。

    其實這已經是在引入後世著名的“面向對象”的開發理念。

    早期的軟件工程項目實施中，很難用設計文檔對程序員進行編碼編寫加以約束，只要能夠完成分解需求，程序員們愛怎麼寫代碼都可以。

    這樣就會帶來許多問題，比如軟件設計風格不統一；可讀性不連貫；代碼風格、結構不規範；甚至連註釋的寫法都各整各的，主打一個亂七八糟。

    以前只要軟件工程組一句“太忙”，這部分工作就是監督組的事兒，周至再氣也沒有辦法。

    好在將心比心，至少目前胡立冬和安春佳的兩個小組也開始漸漸養成周至要求的風格，胡天宇那個組差點，但是總體也在進步。

    這事兒相當的重要，因爲說到底，一切都是爲了效率。

    舉一個簡單的例子，數據庫的訪問方式，各個程序員都有各人的習慣，爲了提升個人效率，大多數程序員都會寫自己的訪問接口，設定自己的參數，用於自己訪問數據。

    但是這樣的人多了，系統的數據庫訪問接口就亂了，出了BUG都不知道是誰的接口出的。

    要解決這個問題，最好的辦法就是找一個專門的程序員，負責編寫一個大家都覺得不錯的數據庫訪問接口出來，所有的程序員訪問數據庫，都統一使用這一個接口。

    這樣就把其他人編寫接口的時間節約了出來，提高了效率；

    出了BUG也立刻就能知道是哪個程序出了問題，還是提高了效率；

    接口工程師對這個程序能夠專精，所有有關數據訪問的問題都歸他處理，很快就會積累出豐富的相關經驗，再來解決問題就能夠輕車熟路，還是提高了效率。

    這就是工程的“模塊化”，每一個小模塊，在工程裏就稱作一個“對象”，將編程分拆爲面向對象編程後，一切同質化的工作，在一個系統當中理論上只需要開發一次，大量的冗餘性工作完全不再有必要，依舊是提高了效率。

    這裏提高一點，那裏提高一點，綜合起來那就不得了，再加上一個好的工程管理軟件，就能夠加快百分之六十以上的項目進速，降低百分之四十以上的項目成本，提高百分之七十五的協作效率。

    老美當年的曼哈頓工程，就是靠這套先進的模式，在研發上很快就超過了本來先行了幾年的德國，最終給小日子種下了兩顆蘑菇。

    (本章完)