周至这一刻感动得一塌糊涂，要求老学人将观念转变过来，实在是太难了。
但是老学人也有两个特别优良的作风，第一就是实事求是，第二就是闻过即改。
知道不对还因为面子，因为“尊严”死当犟种，这种事儿他们也做不出来。
后世人少了他们的严谨，也少了他们的调查和研究，拿着所谓的“逻辑分析”就认为万能，殊不知前提条件不足或者不对的情况下，逻辑越正确，结果往往越荒谬。
然而犟种们往往还振振有词，你看我的条件一二三是正确的吧？我的逻辑推导是正确的吧？那我的结果，怎么还可能是错误的呢？
他就完全没有考虑到虽然条件一二三是正确的，但是还有他不知道的四五六会予以持续修正，把所有条件都带入完备后，还是用他自己那套逻辑，推导出来的结果都可能完全不同。
举个简单的例子，关于古代科举，有人经过调查，发现绝大多数举子家里田地十几亩到百亩占了百分之七八十，因此就得出古代能够有条件参加科举的人都是大地主阶级，因此选拔出来的官员都是维护地主阶级利益的集团成员，这就是封建王朝得以维系的关键。
然而只要他再查一查书籍就能够发现，占地十几亩到一百亩，在近现代倒勉强够得上地主的资格，在古代却完全不是这么回事儿。
唐代授田一丁百亩，一户五口三丁，就得是三百亩一家。
宋代太祖巡视京周，发现一丁三十亩就焦虑得不行，回到宫里坐立不安。
所以在这两个朝代里，家里有田产十几亩到百亩的，最多只能算是那个时代的中产之家而已。
而中产之家在任何时代，都是国家的韭菜，也是社会的中坚，这才是历史的正确结论。
因此要是不知道古代田亩制度，就是缺少了条件四，然后用他有限的认知去套逻辑推演，那就是条件也正确，逻辑也正确，结果偏偏却是错误的。
后世网络上的种种争议，其实很多都是由此而起，到后来大家也开始变得聪明了一些，那就是“让子弹多飞一会儿”，等待条件充分后再推导结论。不然一不小心就要被打脸。
但这也是吃亏吃多了学会的自我修正，现在网络时代都还没有开始呢，因此麦明川能够及时修正自己的认知，站在周至这一边来，就属实是难能可贵。
干技术的人还有一个好处，那就是只认效果，认能力和本事儿。
周至无疑是具有能力的，明明是一个文科生，可无论是提起大字库的概念，还是提前搞起字码，搞起识别程序，不管是搞工程管理还是编写代码，居然都算得上是一把好手。
周至第一次来机房，给自己的字码识别程序上机，当场改写接口程序并且一次性编译通过的故事，都要给软件组传成神话了。
刚刚几个大佬说的那一堆，到现在了几个组长要是都还不明白其中的道理，那都配不上考进大学来的智商。
的确，要是没有周至反复强调要求他们准备的那些工艺文件，估计UNICODE组织都不会瞧上他们，而微软和IBM也不会这么好说话。
要是没有国际专利这一手，人家直接将瀚文字库拿去当成自己的，反手给你来个抢注，用蜀中的老话讲，那才真是“捏着鼻子打不出喷嚏”，只能安慰自己为人类进步做贡献了。
现在的效果就完全不一样，光专利授权和周边产品合作生产，大家都获益丰厚，周至甚至需要建一个公司来“消化利润”，将之变成产学研一条龙的样板。
俗话说的“吃人嘴短，拿人手短”，在座的对周至基本都是又吃又拿，平时插科打诨的嘲讽，思想碰撞讨论激烈了拍桌子打板凳都没问题，但是大家都是在就事论事，真正做到只论对错不讲输赢，目的都是为了找到最佳的问题解决方案，然后就是散会约饭找地方的事儿。 都不是笨人，主要是之前游击战打滑手了，不太习惯正规军阵地战的模式，经过瀚文大字库一期的培训，用周至的话说那就是换头猪来老子都手把手教会了。
再加上现在形势紧迫，也由不得大家自由散漫了。
之前周至几次想要推动这项工作，但是架不住任务紧张，加上习惯没有养成，常常不得不采取妥协办法，让自己累一点，把软件组交上来的那些一看就敷衍了事狗屁不通的玩意儿，修改到可以进入工程文档库。
这东西其实也是有套路的，可以套用模板，为了教会这群猪，周至又将各种工程文件的模板给归纳了出来，让猪们使用起来感觉和编程差不多，方便快捷。
到现在也差不多到了能够脱手的时候，接下来周至又将几个工艺文件的模版给大家翻了出来，给大家再做一次培训。
其实这已经是在引入后世著名的“面向对象”的开发理念。
早期的软件工程项目实施中，很难用设计文档对程序员进行编码编写加以约束，只要能够完成分解需求，程序员们爱怎么写代码都可以。
这样就会带来许多问题，比如软件设计风格不统一；可读性不连贯；代码风格、结构不规范；甚至连注释的写法都各整各的，主打一个乱七八糟。
以前只要软件工程组一句“太忙”，这部分工作就是监督组的事儿，周至再气也没有办法。
好在将心比心，至少目前胡立冬和安春佳的两个小组也开始渐渐养成周至要求的风格，胡天宇那个组差点，但是总体也在进步。
这事儿相当的重要，因为说到底，一切都是为了效率。
举一个简单的例子，数据库的访问方式，各个程序员都有各人的习惯，为了提升个人效率，大多数程序员都会写自己的访问接口，设定自己的参数，用于自己访问数据。
但是这样的人多了，系统的数据库访问接口就乱了，出了BUG都不知道是谁的接口出的。
要解决这个问题，最好的办法就是找一个专门的程序员，负责编写一个大家都觉得不错的数据库访问接口出来，所有的程序员访问数据库，都统一使用这一个接口。
这样就把其他人编写接口的时间节约了出来，提高了效率；
出了BUG也立刻就能知道是哪个程序出了问题，还是提高了效率；
接口工程师对这个程序能够专精，所有有关数据访问的问题都归他处理，很快就会积累出丰富的相关经验，再来解决问题就能够轻车熟路，还是提高了效率。
这就是工程的“模块化”，每一个小模块，在工程里就称作一个“对象”，将编程分拆为面向对象编程后，一切同质化的工作，在一个系统当中理论上只需要开发一次，大量的冗余性工作完全不再有必要，依旧是提高了效率。
这里提高一点，那里提高一点，综合起来那就不得了，再加上一个好的工程管理软件，就能够加快百分之六十以上的项目进速，降低百分之四十以上的项目成本，提高百分之七十五的协作效率。
老美当年的曼哈顿工程，就是靠这套先进的模式，在研发上很快就超过了本来先行了几年的德国，最终给小日子种下了两颗蘑菇。
(本章完)
但是老学人也有两个特别优良的作风，第一就是实事求是，第二就是闻过即改。
知道不对还因为面子，因为“尊严”死当犟种，这种事儿他们也做不出来。
后世人少了他们的严谨，也少了他们的调查和研究，拿着所谓的“逻辑分析”就认为万能，殊不知前提条件不足或者不对的情况下，逻辑越正确，结果往往越荒谬。
然而犟种们往往还振振有词，你看我的条件一二三是正确的吧？我的逻辑推导是正确的吧？那我的结果，怎么还可能是错误的呢？
他就完全没有考虑到虽然条件一二三是正确的，但是还有他不知道的四五六会予以持续修正，把所有条件都带入完备后，还是用他自己那套逻辑，推导出来的结果都可能完全不同。
举个简单的例子，关于古代科举，有人经过调查，发现绝大多数举子家里田地十几亩到百亩占了百分之七八十，因此就得出古代能够有条件参加科举的人都是大地主阶级，因此选拔出来的官员都是维护地主阶级利益的集团成员，这就是封建王朝得以维系的关键。
然而只要他再查一查书籍就能够发现，占地十几亩到一百亩，在近现代倒勉强够得上地主的资格，在古代却完全不是这么回事儿。
唐代授田一丁百亩，一户五口三丁，就得是三百亩一家。
宋代太祖巡视京周，发现一丁三十亩就焦虑得不行，回到宫里坐立不安。
所以在这两个朝代里，家里有田产十几亩到百亩的，最多只能算是那个时代的中产之家而已。
而中产之家在任何时代，都是国家的韭菜，也是社会的中坚，这才是历史的正确结论。
因此要是不知道古代田亩制度，就是缺少了条件四，然后用他有限的认知去套逻辑推演，那就是条件也正确，逻辑也正确，结果偏偏却是错误的。
后世网络上的种种争议，其实很多都是由此而起，到后来大家也开始变得聪明了一些，那就是“让子弹多飞一会儿”，等待条件充分后再推导结论。不然一不小心就要被打脸。
但这也是吃亏吃多了学会的自我修正，现在网络时代都还没有开始呢，因此麦明川能够及时修正自己的认知，站在周至这一边来，就属实是难能可贵。
干技术的人还有一个好处，那就是只认效果，认能力和本事儿。
周至无疑是具有能力的，明明是一个文科生，可无论是提起大字库的概念，还是提前搞起字码，搞起识别程序，不管是搞工程管理还是编写代码，居然都算得上是一把好手。
周至第一次来机房，给自己的字码识别程序上机，当场改写接口程序并且一次性编译通过的故事，都要给软件组传成神话了。
刚刚几个大佬说的那一堆，到现在了几个组长要是都还不明白其中的道理，那都配不上考进大学来的智商。
的确，要是没有周至反复强调要求他们准备的那些工艺文件，估计UNICODE组织都不会瞧上他们，而微软和IBM也不会这么好说话。
要是没有国际专利这一手，人家直接将瀚文字库拿去当成自己的，反手给你来个抢注，用蜀中的老话讲，那才真是“捏着鼻子打不出喷嚏”，只能安慰自己为人类进步做贡献了。
现在的效果就完全不一样，光专利授权和周边产品合作生产，大家都获益丰厚，周至甚至需要建一个公司来“消化利润”，将之变成产学研一条龙的样板。
俗话说的“吃人嘴短，拿人手短”，在座的对周至基本都是又吃又拿，平时插科打诨的嘲讽，思想碰撞讨论激烈了拍桌子打板凳都没问题，但是大家都是在就事论事，真正做到只论对错不讲输赢，目的都是为了找到最佳的问题解决方案，然后就是散会约饭找地方的事儿。 都不是笨人，主要是之前游击战打滑手了，不太习惯正规军阵地战的模式，经过瀚文大字库一期的培训，用周至的话说那就是换头猪来老子都手把手教会了。
再加上现在形势紧迫，也由不得大家自由散漫了。
之前周至几次想要推动这项工作，但是架不住任务紧张，加上习惯没有养成，常常不得不采取妥协办法，让自己累一点，把软件组交上来的那些一看就敷衍了事狗屁不通的玩意儿，修改到可以进入工程文档库。
这东西其实也是有套路的，可以套用模板，为了教会这群猪，周至又将各种工程文件的模板给归纳了出来，让猪们使用起来感觉和编程差不多，方便快捷。
到现在也差不多到了能够脱手的时候，接下来周至又将几个工艺文件的模版给大家翻了出来，给大家再做一次培训。
其实这已经是在引入后世著名的“面向对象”的开发理念。
早期的软件工程项目实施中，很难用设计文档对程序员进行编码编写加以约束，只要能够完成分解需求，程序员们爱怎么写代码都可以。
这样就会带来许多问题，比如软件设计风格不统一；可读性不连贯；代码风格、结构不规范；甚至连注释的写法都各整各的，主打一个乱七八糟。
以前只要软件工程组一句“太忙”，这部分工作就是监督组的事儿，周至再气也没有办法。
好在将心比心，至少目前胡立冬和安春佳的两个小组也开始渐渐养成周至要求的风格，胡天宇那个组差点，但是总体也在进步。
这事儿相当的重要，因为说到底，一切都是为了效率。
举一个简单的例子，数据库的访问方式，各个程序员都有各人的习惯，为了提升个人效率，大多数程序员都会写自己的访问接口，设定自己的参数，用于自己访问数据。
但是这样的人多了，系统的数据库访问接口就乱了，出了BUG都不知道是谁的接口出的。
要解决这个问题，最好的办法就是找一个专门的程序员，负责编写一个大家都觉得不错的数据库访问接口出来，所有的程序员访问数据库，都统一使用这一个接口。
这样就把其他人编写接口的时间节约了出来，提高了效率；
出了BUG也立刻就能知道是哪个程序出了问题，还是提高了效率；
接口工程师对这个程序能够专精，所有有关数据访问的问题都归他处理，很快就会积累出丰富的相关经验，再来解决问题就能够轻车熟路，还是提高了效率。
这就是工程的“模块化”，每一个小模块，在工程里就称作一个“对象”，将编程分拆为面向对象编程后，一切同质化的工作，在一个系统当中理论上只需要开发一次，大量的冗余性工作完全不再有必要，依旧是提高了效率。
这里提高一点，那里提高一点，综合起来那就不得了，再加上一个好的工程管理软件，就能够加快百分之六十以上的项目进速，降低百分之四十以上的项目成本，提高百分之七十五的协作效率。
老美当年的曼哈顿工程，就是靠这套先进的模式，在研发上很快就超过了本来先行了几年的德国，最终给小日子种下了两颗蘑菇。
(本章完)