浅谈我心中的软件开发

很多时候，在 上看到了很多人的代码，以及代码中的错误；

觉得，很多人的开发方式似乎还是，自己写代码，自己写SQL，自己调试，甚至自己写界面！

——我之前也有过类似的开发方式，完成一个功能：调试次数至少 20，一般40，多则 N次

——每次调试该会浪费多少时间！/strong>

上也有人说：不要重复造轮子！

但是冒似很多程序员对这句话的理解一般（我强调了“一般”的）是：将代码公有化，或者 将代码 Ctrl+C+V；

却很少看到有人将 代码 组件化（我这里说的 组件化，不是 Asp.Net 的用户控件，而是 组件控件）；

——好吧，解释一个 我所表述的 “用户控件”和“组件控件”有什么不同：用户控件不能实例化，不能动态创建；

当一个功能完成了，有些人的代码往往可能超过 几千行，超过 2000行的话，VS2010 就往往被卡死！

维护起来，光找到需要修改的代码都往往需要几分钟；

维护完之后，还需要调试，浪费时间——靠，我怎么对调试这么没有好感呢！

其实，软件开发中，谈谈我感觉最好的方式是什么：

在我所见过的程序员中，我看到了这么几种程序员：

有一家，汽车工厂，这家工厂有一个Ctrl+C+V 车间，可以将已经成型的东西迅速复制一份；

工人们，都在按照客户的需求制造汽车；

客户A要求：黑色车身，白色轮子；

X01流程：工人们于是，制造了黑色车身，白色的轮子——为了不重复造轮子，工人们没有给模板轮子上色；

A客户满意了；

B客户来了：白色车身，红色轮子；

X02流程：工人们庆幸：幸好模板轮子没有上色，于是，复制了大量轮子，再涂成红色；

B客户满意了；

这时客户007来了：黑色车声，黑色车轮，防弹玻璃；

X03流程：工人们除了防弹玻璃外，其他部件复制出来，给轮子上个颜色；交付了；

007在一个黑暗的隧道因为全黑色的车声，所以被卡车撞成伤；

于是007说：黑色不安全，给我全部换成白色；

X04流程：工人们重复了 X03流程，只是上了不同的颜色；

007 在一次执行任务过程中，完成任务准备离开时，在高速公路上被人盯上：“老大，007 的车牌是多少——“SB007”——“我看到了，火箭弹准备发射…”…..最后，病床上的007大喊，SB的汽车公司呀！！

于是007说：这个车牌不安全，我要可以换车牌的车；

X05流程：工人们换了个车牌，且将车牌的 码放到了配置文件中；

007在一次任务中，前方大桥被人炸断，“靠…..Shit…..你这个恐龙想干什么——“我在水里看到你，将你救起来，给你做人工呼吸…”

——最后，007觉得一世英明，保留几十年的初吻，毁在了一个恐龙嘴上；于是举枪自杀！

再继续说下去：

因为这件事之后，工厂也认识到工人只针对业务进行生产有点浪费效率；

于是聘请了顶尖专家：开发了一个机器人生产线：

生产线出来的汽车可以在生产线上配置：座位数，车长；

——针对不同的客户选择长度，座位数，颜色；

工人们还是要针对 不同客户，涂不同的颜色，还是要做事——但肯定少很多！

——不是有 Ctrl+C+V 车间么！——但是这个车间不能改变 座位数，车身长度！

007上了天堂，在天堂遇到另外一个汽车厂；

这个汽车厂有点不一样；这个汽车厂卖的是 汽车人（变形金刚）！

007在天堂，坐着自己的座驾，时而变化自己的颜色，时而改变车牌，时而变成飞机，时而隐身….

——于是007 在天堂以为做着维护一方安定的英雄的生活，最后遇到了邦女郎，两人从此幸福的生活在一起！

（End）

从“007最初的杯具” 中，我们看到了 那家汽车厂的生产中的流程；

工人们偷懒了吗—没有，工人们克勤克俭，完成任务且没有质量问题；

工人们SB吗—不，工人们将可以公用的东西都进行了公用，比方说轮子；

这时的工人是在针对业务做事：就像程序员在针对具体业务写代码一样，他们知道将公共的程序代码（轮子）提取出来，供以后使用；

后来，工厂改进生产线；

工人们需要做的事情减少了，对于不能公用的部分（座位数，车长长度）都可以用生产线控制了：

就像是程序员突然有了代码生成器，你在生成器中指定参数，生成器就会给你指定的代码；

——但是生成器生成的代码太大众化；不能针对特殊需求：比如需要飞行的需求！

希望汽车可以飞的客户只有 1/100000 ，为了这么少的客户群，改进生产线是多么SB的行为——当然，改进了更好！

最后，在天堂；

天堂的工厂只生产一种汽车人！——通过Ctrl+C+V 车间无限复制！

客户要什么形态，客户自己拨动开关，自己控制！

就像是程序员突然有了核心框架，核心组件，配置式编程；

大部分，或者全部的事情在框架，组件，或者配置中已经包括了；

需要修改时，只针对 产品进行变形修改——而不是修改生产线！

我看到的很多朋友，都冒似还在针对具体业务写代码

——当然，这是必然的：再厉害的架构师，毕竟也很难将 人类 和 岩浆 这两种东西联系起来，且抽象出公公属性和方法！

（当然，人类和岩浆的 共同点是，都可以运动，都可以发热，都有生命周期）

就是说，有些不能抽象的东西，还是要针对具体业务了；

但是，针对某些可以抽象的：

轮子——完全可以将颜色，直径 抽象出来，让用户自己控制的；

很多时候，抽象的力量可以将一切变得如此的简单！

我想，这就非常考验架构师的设计能力了！

架构师给出一个好的框架，组件和配置模式——将可以让程序员的工作变得异常简单，维护也会异常方便！

                                                                                                                                                                                                                                                                                                     舒小龙

                                                                                                  2012-03-08 10：51