谈谈跨服聊天 | 寂静花园

写在前面

跨服聊天是指交谈双方，不在同一语境下进行交流。多因双方的兴趣爱好/知识差异或聊天内容本身容易引发歧义引起。
双方使用语言的环境不同，对语句的理解也不同。同一句话，在不同的主题会产生不同的理解。以「你幸福么？」为例：我姓曾。
跨服聊天 – 萌娘百科

跨服聊天通常会出现在作品中用来提供笑料。如此的话，直觉上跨服聊天应该离我们很远。真的么？以前我这么认为，但是现在我觉得离我很近。

作为一个写代码的秃头人士，合作项目是很正常的事情，不过我的经历大都是和身边的人合作，双方都比较了解，有了问题直接面谈，基本不会出现跨服聊天这种情况。

今年我尝试与云游君合作一个项目，大概是由于从未谋面，互相不了解，涉足的领域差距比较大，导致跨服聊天变成了家常便饭，很多时候商量了半天的事情，后面会发现讨论的根本不是一个东西。

我们在整体架构上出现了分歧。出现分歧很正常，沟通么，交换一定量的信息后通常就可以达成一致了。但是因为跨服聊天的原因，沟通效率十分低下（相对于和身边人的沟通），这段时间大概一周左右，后来因为所使用的库作者表示要进行大的改动而暂停开发，现在这个项目已经咕掉了。

虽然是因为外部原因暂停的开发，但是如果按照当时的沟通效率做下去的话，恐怕最终也搞不出什么好的项目来，能跑起来就是神迹了。

讨论过程中常见的现象是说着说着出现了分歧，然后沟通讨论，发现没有达成共识的机会，最后发现双方虽然说的是同一个功能，同一个模块，但是细节上却不同。分析后我认为是双方对需求的理解不一致。

因此我提出使用数据流图来协助讨论，云游君也同意了。于是我们合作完成了一张数据流图，期间又发现了许多分歧，但是都解决了。

但是你以为这就完了么？可怕的事情还在后面。没多久我们就开始了初期的编码，结果还是出现了很大分析，期间又是大型跨服聊天现场。在我们还在想怎么提高交流效率的时候，我们所使用的库的作者表示要大改，我们就顺势暂停了开发，然后因为一些原因，这个项目就彻底停下来了。

接下来复习一下，传统方法学的软件生命周期中的三个时期和八个阶段是什么？软件定义时期、软件开发时期和软件维护时期；问题定义、可行性研究、需求分析、概要设计、详细设计、编码和单元测试、综合测试和运行维护。

由于双方从未对发起这么项目的目的产生过任何分歧，由此我认为问题定义与可行性研究是没有问题的。而万恶之源显然就是需求分析了。

传统方法学中要求在需求分析过程中建立软件三种模型：

回到我与云游君的讨论中，发现了问题后我提议合作完成一张数据流图，也就是希望建立一个双方都准确地了解并认可的数据模型，客观来看，这推动了我们的初次编码的进程。

但是编码没有多久就被迫停下来，一个模块的都有哪些方法，哪些属性？各个模块之间如何联系，这些问题被摆到了讨论桌上，如果不是因为外部原因还不知道要跨服聊天多少次。

看起来这次是因为功能模型和行为模型并未建立，所以我们对对方的想法了解的不够准确，就算是准确也未必认同。

那么如果三个模型都建立了是不是就没问题了？不知道，但是根据现在的情况来看，基本不可能。事实是虽然我们合作完成了数据流图，但是这张图许多地方需要分解。分解后会出现什么分歧也是未知的，这项工作是需要在概要设计中做的。

上文不是什么深入的分析，只是很表层的东西，却让我不得不重新审视《软件工程》这门学科。

仅仅是两个人合作，就出现了这么麻烦的事情。双方因为经历、涉足领域、之前并不认识和其它未知的原因导致了跨服聊天大量出现。如果实行切实有效的措施，在企业中这种现象只会更加频繁，后果也会更加致命。

我也发现了一个情况，就是我们似乎更加重视《数据结构》、《XX 语言开发》这种课程，相对来说对《软件工程》的重视程度就要低很多了。

软件工程(Software Engineering，SE)软件工程是一门研究用工程化方法构建和维护有效的、实用的和高质量的软件的学科。
软件工程 – MBA 智库百科

这是软件工程的定义之一，当初看到的时候没有什么感觉，认为这是一句说了和没说一样的话。

现在我似乎能看到这句话的背后可能有无数的开发组遇到了我和云游君一样的问题。为了解决问题，前辈们殚精竭虑地总结出了一套行之有效的工程化方法，帮助后人在开发维护过程中少走弯路，提高效率。

起初我没有理解这些，被现实教训了一顿。不过学习之路似乎就是这样的，当初并不知道这些有什么用，为啥要学，直到身临其境的时候才会感叹前人的智慧。

要说这些工程化方法有哪些问题？一大问题就是许多企业尤其是中小企业无法承受严格按照流程进行开发的成本，可能是时间或者金钱上的成本，或是两者兼有。

个人的小软件大多数情况下完全没必要严格按照流程来，更多的是灵光一现立马开始编码，小几百行甚至几十行代码就能实现的功能。

应对需求频繁变化的场景前辈提出了极限编程；为了提高需求分析的质量前辈提出了快速原型；以及现在的微软过程等。每个都是对这门的学科的发展，使其适应新时代的变化，提高生产效率。

不过这不是说以后开发软件都要严格按照流程来，能解决问题的方法就是好方法，而且这个方法没准以后也会成为《软件工程》的一部分。毕竟科学界从来都没有真理存在，有的只是能让人信服的证据，以及推翻那些曾经被信服的证据的证据。