野生码农的架构实践

一、   自传

        IT圈子重所谓“出身”。在B乎、各种码农圈子，经常看到晒学历、晒工作经历。不是BAT，就是麻省，北清。就如龙母见任何人都要报出一堆头衔，以证明自己血统的高贵。

而本人，就是一个纯野生“双非”码农：非计算机科班出身、非IT名企出身。大学学的机电自动化，毕业也是一直跟机器、图纸打交道。没有自带光环、没有拜师学艺、没有群星荟萃，全凭个人兴趣，业余爱好而已。

然而诸葛亮说过，不要妄自菲薄。兴趣是最好的老师。因为偶然机会，帮朋友设计一个进销存软件，一发不可收，经常熬夜研究，不但要理解需求，还要编写代码，从无到有，无师自通。

那时候，成功连接数据库、弹出来第一个窗体，都是极大的喜悦。虽然彼时水平极菜，自己却认为已经是“高手”了。现在想来虽然可笑，但也是这种良好的自我感觉，给了我持续的动力。

对我这种野生码农而言，没有资历可晒，资本就只有一样：码力，写代码的能力。能证明自己的，就是代码和架构的水平，比如这个。

二、   起步：看山是山，看水是水

• 我的起点

起点就是零点。大学里也“学过”计算机，C,FORTRAN。甚至图书馆里借过几本计算机书啃。然而中国的教材，你懂的，最大特长是把简单问题复杂化。当时不喜欢英语，吃了大亏。

后来逐渐明白，无论技术还是教材，还是国外原版的好。后来再没怎么研究过计算机，直到我搞那个进销存软件为止。所以开始，我就是一个软件盲。

感谢宽带，感谢百度，感谢微软。家里有了宽带，就可以百度：看博客园、看csdn、看MSDN。好在.NET门槛很低，帮助齐全，神器加持，如果是C++，陡峭的自学曲线，说不定就放弃了。

• 摸索之路

也许正因为是从一张白纸起步，虽然走了些弯路，但也没有窠臼之见。既不知道什么设计模式，也没有编程套路和规范。一切都是自己摸索，也形成了自己的“风格”。

最开始的进销存设计，我不懂代码，但是需求分析还是有的。只是彼时初生牛犊不怕虎，不知深浅。什么能实现，什么不能实现，实现的难度有多大，一概不知。

这个进销存系统虽是业余练笔之作，但最初拟定的需求，却是参照一款国内流行的管家婆软件。需求来自于管家婆的说明书。

没办法，发挥我国人民山寨的特长，管家婆有几个页面我也几个页面，管家婆有哪些功能我也来一套。

VS神器+Winform，从拖控件开始。有些控件达不到管家婆的效果，就百度。涉及到的财务知识不懂，百度。如此也练就了一身功夫：搜商。现在想找什么资料，关键字往往一击命中。

有人说C#、.NET坏就坏在拖控件上。把码农惯坏了，惯成不求甚解只会拖控件的傻瓜了。我只想说，只会拖控件的确说明你是傻瓜，但这不怪微软，只怪你自己没有追求。

这样经过若干昼夜的鏖战，总算出来几张基本的数据库表，几个还算齐整的页面。代码是吃百家饭，从百度上抠来的。比如数据库的连接啦，button的效果啦，等等。

现在看那些代码，既不是面向对象，也不是面向过程，而是纯粹为实现功能拼凑的代码。前后台代码混在一起，一个类千行代码，一个函数洋洋洒洒。

但有两个习惯让我能进入下一步，一个是追求完美主义，一个是喜欢追根究底。没有这两点，不可能进阶。

比如ADO，里面有一系列对象，什么游标、什么DataTable、什么数据库连接池，这里涉及到大量概念，我这人不习惯死记硬背，为从无到有理解ADO、数据库的一系列概念，熬夜思考若干天，终于有所领悟，理出头绪。而之后，数据结构、套接字、网络协议，这些概念自然而然就会进入你的视野，务求深入理解，磨刀不误砍柴工。我个人的经验，软件行业包罗万象，最好的学习方法就是掌握基本概念之后，用什么学什么。道理一通百通。

而追求代码完美主义，使我看着过往零碎、丑陋的代码，内心感到不满，也开始接触到一些面向对象、多层架构、UML这些概念，感觉真理就在眼前，开始考虑重构代码。

三、   思变：看山不是山，看水不是水

• 从面向“过程”到面向对象

重构的第一步，提取出共性的东西，代之以函数。

原来大量的相同、相似代码合并，放到一个大的工具类，大家共享。这样做的好处显而易见，代码精简了，可读性强了，改起来容易了。

但是重构这个事，很容易矫枉过正。尤其是我接触到“面向对象”这个概念之后。

初识面向对象，总有一种发现真理的感觉。比如订单类，原来的风格是类大而全，保罗万象。

学了面向对象，就将采购单、销售单、入库单、出库单等等继承一个总的Order类，每个Order还要分订单抬头（客户、账号、订单号、日期），明细，又各自有所继承。

那时候的代码，真是万物皆对象，为赋新词强说愁。至于这么分类有什么好处，却没有清醒的认知。所以结果就是把简单的问题复杂化了。

比如每个订单都有自己的增删改查方法，然而订单的参数不同，增删改查都要重载；人说三层架构好，就把界面逻辑中所有数据操作的部分，都塞到一个DAL层。

 

可以说，这样做的结果还是有好处的，界面部分没有数据库操作的语句。修改界面的人（不一定是自己）只需要知道接口规范就可以。不用在意太多细节。

坏处是，一旦对象发生变化，不但要改接口，还要改数据库，数据库操作的DAL层。

这一阶段，总体代码量甚至有所增加，性能甚至有所下降，但思路更加清晰了，对面向对象的理解深入了，包括它的利弊。

• 设计模式的改造

学习了设计模式之后，对面向对象的理解深入了一层。实际上，经常发现自己不知不觉中已经是设计模式的践行者。因为这些模式都是前人对某一类问题总结出来的最佳设计方案。

设计模式的目标，就是减少耦合性，提升扩展性。从哲学角度，编程并不简单的是写代码的问题。是对客观世界的抽象。牛逼的人能很快领悟到本质，用一个简洁的描述就能让人明白真相，比如