很久没有写涉及技术方面的文章了，其实是最近实在是没有接触什么高深的技术。今天写这么一片文章，说实话也跟技术扯不上太深的关系，纯粹是对最近的个人体会的发泄。
最近我看到的一些人写的代码，实在是不怎么样：命名规则胡乱一气，基本的安全意识没有，数据库结构不符合规范。在这样的代码里面，你根本就不要指望找到什么Template Method、MVC、Factory模式（有，很少，大部分限于早期的代码）。我开始觉得很不以为然，觉得这样的东西会对整个产品的发展带来灾难性的影响，比如不容易维护等等。然而在这样的一个情况之下，这个公司以及他的产品仍然在顽强的生存着、发展着。为什么会这样呢？
原因有两个：
首先，对于一个不断发展的产品来说，会经常面临大幅度的修改。这些修改可以是从UE到UI，从需求到美观等各个层次的。有的时候一些合作的开始，会导致要求以最快的时间完成工作。而一些项目的暂停或者终止，则可能导致一些代码被弃置在一边。大家可能会说了，这个是现代软件工程的课题之一，叫做需求是不断变化的，而这时正是设计模式以及一些企业级应用框架等试图解决的问题。可是事实情况是，这些东西在我所看到的这个例子里面，几乎不适用。原因如下：
1、企业级框架对于如此高的需求变化速度与频率来讲，显得过于笨重。比如说，一个管理后台需要在15天内架设完毕，其中包括一大堆原来不存在的业务逻辑以及双方服务器之间的同步问题等。在如此紧张的开发进度之内，根本无法进行这种笨重级别框架的配置和调试；
2、企业级框架的部署和应用具有极高的风险成本。很多时候，对于一个创业阶段的小公司，其生存能力取决于他的应变能力和执行能力。打一个比方说，某天突然中国移动和你达成一个合作意向，前提条件是你能够提供该服务。这种合作背后有两个潜在的逻辑：a)很可能某天突然有第三家插进来，比你更早提供该服务，于是正式的合作合同就泡汤了；b)更重要的是，即使你提供了该服务，出于其他客观原因，最终该意向还是很有可能不了了之。于是，你可能辛辛苦苦做出来的东西，最后却是毫无作用。要知道，庞大的东西如果毫无作用，反而可能会是一种负担，这个时候就会很尴尬：拆除他还是不拆除？通过做Branch的方式也许在面对一个这样的合作还有可能，如果同时不定期的进行多个项目，用Branch来避免拆除问题就比较不切实际了；
3、企业级框架，甚至设计模式对于很多开发人员来说仍然是一种天书。千万不要以为开发人员都会像那些搞出设计模式或者TDD开发模式的先知那样聪明，如果真那样的话恐怕你我之间都是比尔盖茨了。根据我的经验，以一个小企业所能够找到开发人员来说，能够理解这些东西的人不会超过33%。也就是说，你在这里面如果应用这些设计模式、开发模式，无非就是面对如下两个结果：a)那66%的人需要你去告诉他你写的到底是什么（对于他们来说，你在写天书）；b)那66%的人会干脆绕过你的代码，重新写一堆很烂的代码，这种情况居多。这实在不是一件什么好事，比如你会看到一堆恶心你心情的代码。此外你可以想象原本好好的MVC代码，一层层剥离的很好，没过一段时间可能就会有人直接在V上面写一堆的SQL语句和业务逻辑。我在这个时候宁愿没有MVC结构，这样我就不会浪费时间调试M层明明正确的Sql和C层明明正确的业务逻辑了，更不会搞不清楚他到底什么地方乱写一气，什么地方有突然调用了底层的代码了。当然，这是最糟糕的情况。在最好的情况下，随着时间的推移，乱写一气的代码总会不断的堆积并占绝对多数。也就是说，你的努力最终都是白费的。
其次，对于一个作产品的公司是否能生存，取决于产品卖得如何。而产品卖得如何，不取决于技术是否漂亮优雅。说到这里我想说两个故事：
第一个故事是我听一个大老板讲的。曾经有一次他好不容易做通了各项工作，说服了拥有决策权的一位领导，拿下了一个大项目。在前往签合同之前，他打了一个电话确认对方是否有空，结果对方说：“哎呀，我忘了告诉你，我今晚上要坐飞机去外地考察。如果你实在着急，你现在就过来，甚至来机场找我都可以。非常抱歉！”这位大老板一听，觉得还是不要催得那么紧了，反正人家都同意了，等人家回来照样还是会签的。结果事情就是那么凑巧，该领导出去考察的时候出车祸罹难了。后来新上任的领导上任三把火，把上一任所有的做法都否认了，包括那个改签却没有签的合同。如果签了，有法律文件在，那就不可能发生这样的事情。这位大老板如是总结，如果这件事情在发生一次，他就是要到机场也要先把这个合同签了。做生意就是这样，机会稍纵即逝。像刚才提到的那种意向，一定要以最快的速度提供，这样你的公司才会有生气，才会赢得生存的机会，这是为什么部署一个企业级别框架显得那么不适用的缘故。说到这里我想大家应该能够理解，为什么我会说迅速的进行第一波的开发非常重要！以我的经验来看，有Bug不要紧，功能很弱质不要紧，甚至有些不是最基础的功能暂不提供都不要紧，因为你三寸不烂之舌是可以圆过去的。比如说为了快速推进项目，避免不必要的东西造成对方项目拖后，我们先实现最基本的功能，现发布一个最简单的版本再说。通常人家都可以接受这样的说法，甚至乐意接受这样的说法。但是千万不要因为未知原因，或者不可控的原因，造成进度停滞不前！而偏偏大型的第三方框架的部署调试最容易发生这样的状况。顺便说说这一个故事的结尾，该大老板后来就在关键项目的洽谈时，带着公章合同整天泡在对方那边，某一天指不定他一高兴松口说这事成，他立刻就从怀里掏出合同公章，一分钟也不耽误。
第二个故事是DiscuzNT，这个故事我不太了解，只是最近这两天正好dudu聊到了，我就稍微看了一下。我感兴趣的倒不是那些技术的细节，而是官方博客说的“站长通常不具备很好的技术知识”，其实这就是现实。现实是，你如果用Atlas去做一个平台，那么二次开发也绝对不能让人感觉到这样的技术存在。因为客户不懂！千万不要提供客户不懂的东西，那样的东西是卖不出去的。一个产品是否好卖，取决于你的东西对于你的客户来说是否是他想要的东西，而绝对不是你用了什么样的技术。相信这一点稍微了解软件工程的人都会知道，就是要贴近客户的需求嘛！显然，如果你选择用某一种技术是为了这个产品更好卖，那基本上可以说你不上道。这个故事扩展来讲，一个开发模式或者设计模式，是否适合引入到你的项目中，也不取决于这个设计模式多先进，而是取决于使用这些模式的客户，也就是开发人员是否能够理解和掌握它们。如果不行，那就不是一个合适的技术。这个时候你有几个选择：1、教育你的员工；2、换一批员工；3、放弃这个技术。对于一个新公司来说，可见选项1和2成本都是非常高的，而选择3也许会让你很不爽，但是却是一个较为可行的方案。不知道大家是否听过这么一个故事：有一个老乞丐，捡了一个发霉的食物就往嘴里塞。路人甲看不过眼，说你吃了肯定要闹肚子，说不定明天就要了你的命了！老乞丐说：“我知道吃了也许明天就会没命，但是今天我要是不吃今天就会饿死！”对于小公司、新公司来说，就是那个老乞丐的情况。你根本就没有资本去选1和2，选1你要花费大量的时间，选2要花费大量的金钱，这对于新公司小公司来说都是极其致命的。这个问题之能够逐步的改善，而且要求你有良好的经济基础。
顺便说一句，我的意思并不是不用这些那些高级玩意，我还是支持尽可能使用的。但是要搞清楚，你有没有能耐，有没有资本去使用这样的东西。或者当你评价其他人的时候，也不要一味得以技术上如何来做评价，万事皆有因。人家这么做，也许就是站在他的角度，在他的境地下的最佳决策。
结束之前，想解释一下，希望大家不要对号入座。尤其是文中提到各位，其实我只是看到里面的某些东西有感而发。实际上甚至跟这些事件本身毫无瓜葛，绝没有对这些事件进行评论的意思，而仅仅就自己的一些经历有感而发而已。
P.S.:
@dudu
要是本文质量不高就挪别处吧：）