不迁就，不将就

（原文写于2016.5.2.）

1

两周前的一天早上，程序员先生突然在办公室里疼到发抖，被基友送去医院。彼时我刚搬完家没几天，基友的老婆给我发消息开玩笑说，XX给你搬个家都累病了？（龇牙笑）

正好当时公司特殊时期，上午不用坐班，二话不说打了个车从浦西直奔浦东，看他疼得呻吟扭曲，无可奈何，待到下午挂完了水，把他送回了家。

以上都不是重点。

重点是，在他打开房门的一瞬间，我倒吸了一口冷气。

我真傻，真的，从前只知道男生房间乱，但从不知道原来能乱成那样。

2

我妈常说，两个人谈着恋爱出去吃喝玩乐自然开心，只有住在一起才会有矛盾。

那天看到程序员先生的房间，我内心瞬间浮起了这句话。

可我当时噗嗤就笑了出来，告诉他，你的房间表示你的生活里缺一个女人啊。

3

我和程序员先生有好多好多的“差异”，而且在第一次同他见面时，我就已经感受到。

比如他喜欢看爆米花肾上腺素片、无厘头的吐槽，我则更愿意静下来一个人欣赏一部两三个小时的社会片；

比如他看新闻偏重商业与科技，品牌发家史说得头头是道，我每天关注的却多半是文化类的内容，哪个名字长不啦叽的家伙又出了什么极其拗口的书；

比如他家庭虽不算完全和睦，但也是磕磕绊绊的“正常”家庭，而我的成长史混乱不堪；

比如他在高中时是个地道的“学渣”，而我那时虽不算学霸，但成绩怎么着也算得上优异；

比如后来我才发现，他喜欢吃硬硬的米饭，睡硬硬的床，而我喜欢软软的米饭和软软的席梦思；

他起床从不铺被子，我却觉得被子不铺好，整个房间都乱糟糟；

他喜欢做完了饭再刷碗洗锅，我喜欢做完饭就顺手洗了锅……

前阵子一度因为了解之后产生的越来越多的“差异”而困扰，可现在每每被这些“差异”打击，我都会想起程序员先生那乱糟糟的小房间，以及当时机智如我的那句“生活中缺个女人”的吐槽=w=。

4

我现在大抵觉得，人与人之间的矛盾并不来源于“差异”，而来源于对那些差异的不接受。

过去我不谈恋爱，一大理由是我这么懒的人，要么遇上各方面节奏相似不费心的对象，要么还是一个人过得比较爽。恋爱即生活，让我生活质量下降的人或物，我一概不想将就着跟他们在一起；

直到遇到程序员先生，我才发现，原来有朝一日我竟会遇到一个人，这个人与我有这样那样的差别，可若是彼此心智都成熟，就可以做到互相理解接受，我不用迁就他，不用因为他改变自己工作的节奏、忠诚的爱好，原来多爽的日子如今还是多爽，顶多是在看日剧前多招呼他一句“要不要一起看”。

5

租房子的时候在中介门口遇到一对夫妻吵架，我问程序员先生，你说这世上有没有人一辈子不吵架？

中介阿姨接话道，不可能存在的。

我看了程序员先生一眼说，咱俩试一下呗。

比如觉得衣服堆得乱，说上一句，那里有点乱哦，他若能自觉整理了自然是好，不愿整理大不了顺手帮他整理了就是，不要埋怨；

抑或觉得做菜太淡，也可以适当沟通，沟通不成，大不了单独给自己做道菜，像不要钱一样地加盐嘛，也不是什么大不了的事儿；

也许觉得他游戏玩得多，我也可以坐在旁边默默地看，不想看游戏，自己随手从书架上抽一本书，边看书边偷瞄认真打游戏的他，说不定还会觉得有点小帅；

我喜欢这样没有压力的相处，谁也不会逼着谁改变，也不必为谁改变。

那么，中介阿姨，您能不能教教我，该怎么吵架？

6

不过头脑简单的程序员先生大概不会像我感受到这么多、想这么多，我猜想，对他来说，喜欢就是全盘接受；全盘接受就是……

“哥选中的女人什么都好。”

好吧（搂住。

7

程序员先生是靠直觉活着的少年，有时候我会笑他就像二次元热血漫的男主，被他安利着看《排球少年》的时候，我甚至说，我要是四眼，也一定看男主不爽，凭什么我们一生悬命走到今天，你这家伙却总能笑呵呵地轻描淡写？真欠抽。

比如工作上若是一个人手上的任务出了错，我往往会想着结果为什么会变成最后那样，有时候的确是一些难以避免的巧合促成的失误，但我也会在安慰TA时说，我理解你觉得自己没有错，但是这个责任还是必须你担。

而程序员先生往往不假思索地说那人应该负责。

比如编辑推翻我的稿子让我改，我会一边不开心一边告慰自己一定能从经验丰富的编辑要求的这次推翻中学到很多东西，然后心甘情愿地开始动笔。

程序员先生听说我要推翻重来，却只会说上一句，那就写呗。

有时候觉得自己绕了那么大一圈最后得出的竟是和程序员先生一样的结论，真是……生气啊。

所以对于“差异”这件事，虽然我一度害怕自己有朝一日难以接受某些差异而爆发矛盾，时间久了，才终于完全接受认同，但程序员先生，大约自始至终都没放在心上吧。

我活得真累。

8

不过说到底，这也是一种差异，而且还是一种挺美好的差异，他靠着直觉A TO D，我负责缜密地串起那些BBCC，常能殊途同归，毕竟皆大欢喜。

因为有差异，所以才有趣；因为心智相当，所以相互理解不疲惫。

一个中二的热血青年，教会我的对待差异的态度，比学习采访和田野调查还要多。

9

《心灵捕手》里，马特达蒙饰演的天才少年说自己爱上了一个完美的姑娘，可是不想有进一步接触，因为这会破坏他心中“完美”的形象，已故的罗宾·威廉姆斯饰演的老教师则回答了一段深得我心的名言：

“打电话给她，罗密欧。”

“为什么？让自己发现她其实没那么聪明吗？发现她其实很无聊吗？这女孩现在很完美，我不想破坏。”

“或许是你不想破坏自己的完美。”教师说，“我太太一紧张就放屁，她有各种奇妙的小特质。她睡觉会放屁，抱歉跟你讲这种事，有天晚上声音大到把狗都吵醒了，她醒来说，是你吗，我说是，我不忍心告诉她，天哪。”

“她把自己臭醒？”

“是的……天哪，她去世两年了，而那是我记得的事，像那样的小事很奇妙，那是我最想念的事，这些小特质让她成为我的太太，她也知道我所有的小瑕疵，人们称之为不完美，其实不然，那才是好东西，能选择让谁进入我们的世界，你并不完美，我不吊你胃口，你认识的女生也不完美，问题是你们是否完美地合适，亲密关系就是这么回事。”

10

不用将就，不用迁就，不用完美，只要能完美契合。

此生能认识程序员先生，真是太好了。

B/S结构跟C/S结构的区别所谓B/S结构，就是只安装维护一个服务器（Server），而客户端采用浏览器（Browse）运行软件，即浏览器/服务器结构。

B/S结构的优点是维护方便，能够降低总体拥有成本。客户端运行软件，就像我们平时上网浏览网页一样，有个浏览器（通常是IE5.0）就行了，不用安

装其它软件。而且通过电话线也可以运行软件。B/S结构的软件所有的维护、升级工作都只在服务器上进行，而客户端就能获得最新版本的软件。

相对于C/S结构，尽管C/S结构相对于更早的文件服务器来说，有了很大的进步，但与B/S相比，缺点和不足是很明显的。

首先，B/S比C/S的维护工作量大大减少了。C/S结构的每一个客户端都必须安装和配置软件。假如一个企业共有50个客户站点使用一套C/S结构的

软件，则当这套软件进行了哪怕很微小的改动后（比如增加某个功能），系统维护员都必须进行这样的维护；将服务器更新到最新版本；将客户端原有的软件卸载，

再安装新的版本，然后进行设置，最为可怕的是客户端的维护工作必须不折不扣的进行50次。若其中有部分客户端是在另外一个地方，则系统维护员还必须跑到该

地方再进行卸载、安装、设置的工作。 若某个客户端，忘记进行这样的维护，则该客户端将会碰到版本不一致的问题而无法工作。

而B/S结构，客户端不必安装及维护。如果我们将前面企业的C/S结构的软件换成B/S结构的，我们看看软件升级后，系统维护员如何维护：

系统维护员只要将服务器的软件升级到最新版本就行了。其他客户端，只要重新登录系统，使用的就已经是最新版本的软件了。

其次，B/S相对C/S能够降低总体拥有成本， C/S软件一般是采用两层结构的。而b/s采用的是三层结构。

两层结构中，客户端接受用户的请求，客户端向数据库服务提出请求，数据库服务将数据提交给客户端，客户端将数据进行计算（可能涉及到运算、汇总、统计等等）并将结果呈现给用户。

在三层结构中，客户端接受用户的请求，客户端向应用服务提出请求，应用服务从数据库服务中获得数据，应用服务将数据进行计算并将结果提交给客户端，客户端将结果呈现给用户。

这两种结构的不同点是，两层结构中客户端参与运算，而三层结构中客户端并不参与运算，只是简单的接收用户的请求，显示最后的结果。由于三层结构中的客户端并不需要参与计算，所以对客户端的计处算机电脑配置要求是比较低的。

另外，由于从应用服务到客户端只传递最终的结果，数据量较少，使用电话线也能够信任。而采用C/S两层结构，使用电话线作为传输线路可能因为速度太慢而不能够接受。

采用三层结构的b/s的配置可以是提高服务器的配置，降低客户端的配置。这样增加的只是一台服务器（应用服务和数据库服务可以放在同一台计算机电脑中）的价格，而降低的却是几十台客户端机器的价格。起到了降低总体拥有成本的作用

C/S、B/S及三层结构（下） 谢攀 (转帖)

上一期，作者在本文上半部分介绍了对C/S结构、两层模式、三层模式的看法，以及实现三层模式的技术手段，接下来作者将探讨B/S结构

和三层模式的实现方法。

三层结构编程要点

对此笔者不想讲太多理论，只给大家一句经典名言，这句话每个程序员都应该牢牢记住：All business logic in the Middle Tier（所

有的商业逻辑处在中间层上）。如果不这样，你开发的三层结构程序就不专业，或者只是C/S模式的翻版产品。这句话虽然很简单，要达

到这一境界却需要大量的经验积累。

另一个要领是: 一定要尽量减少应用服务器与前台程序的数据传递量以及Round Trip。因为如果你的三层结构存在频繁的Round Trip，那

么你开发的应用服务器效率一定非常低下，当同时进入10个连接时，你就会发现应用服务器接近瘫痪。

在开发三层结构的系统时，应该养成一种好习惯，就是在系统分析或者设计报告中，较为详细地描述如何解决商业逻辑、如何有效降低数

据传递量，以及只使用必要的Round Trip。只有这样，别人才能与你一起探讨你的解决方案是否合理，是否有更有效的实现方式。同时，

经过不断归纳，提高自己的系统分析能力。

在开发大量用户连接的应用服务器时，多线程技术是必要的，否则当应用服务器在处理一个用户的请求时，另一用户只能等待，如果这种

等待的时间太长了，用户就会对软件失去信心。还有一个是分布式的概念，你可以根据商业逻辑来切分，开发并发布多个应用服务器解决

不同的商业逻辑；或者你可以将运行应用服务器的多个进程分布在不同的服务器中，并根据访问流程自动引导用户到合理的应用服务器

中。

正是因为三层结构比C/S复杂，所以你要成为三层结构的高手，一定要经过一段较长的时间和大量项目的锻练。但三层结构体现了一个开

发人员与系统人员的专业素质，因为它涉及太多东西: 技术工具的选型、模块化和组件化思想、前后台功能的分割等等。从真正意义上来

讲，只有三层结构的项目才能完整反映软件项目的每个过程。

B/S模式与发展

主流的软件架构B/S与N Tier模式都有一些缺点，所以现在出现了许多B－N Tier的系统，就是基于Web浏览器的多层结构开发模式，它吸

收了两者的优点。

我们知道单纯的B/S方式，虽然很令人兴奋，并且最终用户使用成本几乎为零，但它存在许多不足，它的功能较弱，无法非常容易地实现

你的理念。比如你要实现一种商业模型，你会发现实际上Web方式是不安全、不可靠的，比如，用户可通过页面回退或前进来改变你所有

希望的结果、报表制作能力不足等。

为什么Web会造成逻辑实现上的困难？因为它是基于Stateless（无状态）的。打个比方，Stateless就是这样一种情形：你与你的用户中

间有一道墙，你并不知道墙另一边的用户长得什么样子，甚至是男是女你都不知道，然后你通过墙上的一个小窗递给他一件礼物，至于礼

物最终的流向，你也一无所知，这就是Stateless。所有基于HTTP的东西都是Stateless的。而Socket的魅力就在于它是有状态的。

笔者以为现在发展起来的ASP、JSP、Java技术，都是在弥补HTTP协议存在的无状态缺陷，但即使有了这些工具，仍会觉得网页编程无法随

心所欲，因为这些技术再先进，也无法解决HTTP协议基于Stateless的事实。

也许有人会问，这些动态网页开发技术是如何在一定程度上避免了Stateless的弊端的？以基于IIS的ASP技术来说，它使用Session变量来

实现State。但是不管什么技术，最终都落在了COOKIE上，也就是使用COOKIE来保留客户端状态。

这里还要提一下Socket。Socket目前应用十分广泛，ICQ、QQ等即时通讯软件，还有许多网络工具，大都基于Socket，因为Socket协议是

有状态的，所以才能做到这一点。可以这么说，是Socket让网络生活更精彩！

目前基于Web的多层结构采用的底层技术主要有SOAP＋State类协议或者HTTP＋State类协议。这里有一个Delphi程序员的好消息，从

Delphi 6开始引入WebSnap包（一种Web Provider产品），它的设计者被Borland公司称为Borland历史上最伟大的工程师之一。它同时支

持HTTP与SOAP协议，也采用了一种类似Session变量的模式来实现有状态(State)。它可以说是目前市面上最强大的基于平台的

Browse/Server开发工具之一，其不足是它还不能称为完全的RAD工具，而且门槛较高。为什么不是ASP或者ASP.NET呢？笔者认为ASP不是

基于平台的，它是基于脚本语言的，它的运行效率不高，而且它的调试困难。在Delphi 7中还引入了IntraWeb控件包，笔者以为它是一种

真正意义上的网页RAD开发工具，与WebSnap配合更会如虎添翼。

Web Provider、逻辑组件、多线程处理、交易机制、消息流转等组合在一起是N Tier开发的最高境界，笔者以为是大型商业软件架构的首

选。笔者在前面很少提到消息机制，主要是怕大家混淆了概念，消息机制并不一定在所有的多层结构中都存在，而且，如果要实现消息机

制，必须寻找实现手段（比如使用Socket），否则，如果在程序中强制实施大量消息流转（比如使用定时器监控和消息数据表方式），无

论是效率还是实现的复杂性来讲都是要考虑的问题。

软件开发人员的选择

笔者愿意把软件设计看成音乐艺术，它有许多流派，也有主流，但并不意味着别的思想被彻底抛弃。比如单层结构或C/S方式，许多人仍

然在用，而且很擅长。笔者不鼓励读者抛弃这些传统的东西，笔者的意思是要扩大眼界，开放思想。而多层反映的是一种集成的思想，以

安全、高效、图形方式整合系统，以组件思想逐步构架整个公司的商业逻辑，并降低最终用户使用成本。其最核心的思想是集中，所有中

间层是集中的，可以在不同的服务器上运行不同的商业逻辑组件（比如.NET），但这个逻辑组件一定是提供给所有前端程序使用的。现在

许多企业都在走系统集中的道路，集中可以带来无限的好处，但没有软件平台的支撑，集中是非常肤浅的。我们追求的不单纯是机器的集

中，机器的集中会同时带来网络带宽的压力，只有应用集中了，才能最终达到合理配置资源的目的，这也是为什么我们要用多层体系、要

用分布式思想来构建企业应用的真正原因。

笔者以为，在软件开发的今天，作为一名专业人员，如果总在单层或C/S构架下，永远形成不了系统思想，只有多层体系才能真正体会软

件生命周期的理念，从需求分析形成商业逻辑到系统设计、数据库结构设计、组件化程序编写、测试、推广，一个好的N Tier系统一定要

踏实地做好各个阶段的工作。这不像程序语言的变化或者开发环境的简单变换，因为它是一种开发思想与开发模式的完全变革，所以它也

一定是一个过程，不可能要求自己在一两个月内就能真正体会并开始驾驭N Tier模式，但商业模式变了，开发思想也要变，你必须也只能

让自己去适应新的思想，才能成为一名更加专业的开发人员。一旦你进入了N Tier的殿堂，并熟练掌握了这种开发模式，就会发现你开始

逐渐形成了软件开发的系统思想，并且在这个领域上越走越在前面，开发也会越来越有激情。

编后语：可怜的程序员

“真累！”时常听到软件开发人员这么说。软件开发是一个高强度的工作，这是共识，无论对于体力还是脑力都是一个考验，因此不少程

序员常常自嘲为“吃青春饭”的人。本人此前也做过几年软件开发，我也深谙其中的辛苦。我知道，对于软件开发人员而言，赶工期、赶

进度、封闭开发、长时间的加班加点等很多人已经习以为常，不过和心理上承受的压力相比, 这点痛实在算不得什么，软件技术的更新日

新月异，要在这一行立足，就必须时刻追踪技术发展，不然掉队事小，掉饭碗事大。C/S模式刚刚掌握，又流行起B/S架构，对高深莫测的

J2EE、CORBA还是一知半解，.NET又接踵而至。掌握VB太基础，掌握Delphi也才刚刚跨入程序员大门。要想待遇高，那得掌握VC或者BC，

若论工作机会多还数Java迷。最近又流行Web Services，也一定要弄明白，但要真正理解Web服务，掌握XML是前提。头儿有一天谈到

UML，也要补上……“可怜的程序员，何时是尽头！”

作为程序员的你是否在工作中陷入过这个误区，也为此苦恼过？或许你已经走出了这个阴影，或许你对此能轻松对付，你是否愿意让大家

分享你的经验和观点，无论如何，如果你对这个话题感兴趣，欢迎你和大家一起来讨论。

转自

---