前两篇文章中，我们介绍了软件开发的时间线索，和软件系统的空间关系，
这使得我们可以将自己的工作，看成为历史长河中的一瞬，
或者看成庞大软件体系中的一个部分。
然而，如果考察软件设计的话，只考虑软件自身是还不够的，
还要考虑人的因素，因为软件终究还是要由人来做出来的。
所以本文就来探讨一下，语言、模式、工程 和 领域分层。
看看这些方面的内容，在软件设计过程中起到了什么作用。
语言
在我看来，自然语言是用来传递信息用的，编程语言也是如此，
编程语言在将开发者大脑中的想法，转换为机器实现的这个过程中，起到了桥梁作用。
因此，应该着眼于合理的信息转换方式，而不是特定的编程语言。
编程语言也不是孤立存在的，
选用不同编程语言，等于选择了一个社区，一套软件生态，
会认识不同的人，跟现有的不同系统进行对接。
但不论怎样说，有能力使用多语种编程语言进行编程，是至关重要的，
这会让我们思考问题的方式从一开始就能摆脱宗教迷信，
没有哪一种解决方案是最好的，只有最适合于当下的。
最后，在职业生涯的某个阶段，我们很有必要去学习编程语言本身相关的知识。
一方面，能帮助我们了解编程语言到底是如何工作的，
另一方面，在必要的时候，能够发明自己的语言，让信息转换变得更加直接。
模式
有一些设计模式相关的资料，容易给人一种错觉，
认为设计模式只是有关于软件内部结构的，
毕竟工厂模式和适配器模式，它们最容易看到的区别是实现方式不同。
我不这么认为，我更倾向于把模式实现当做现象，
而把模式要解决的问题，以及模式所固化下来的解题套路，看成本质。
有什么样的问题，就有什么样的解决方案，而不是反之。
人为之物，之所以是这样而不是那样，是因为有不同的动机。
所以从人的角度来设计模式，只考虑模式的内部表现则只看到了三分之一，
剩下的三分之二是，特定模式所暴露出来的接口，
以及人们选用这个模式背后的用意。
因此，设计模式是一种人们使用特定方式解决特定问题的套路。
特定方式：接口设计，
特定问题：用意，动机，问题，
套路：实现方式，代码结构。
我更关心接口层，因为接口是系统的界面，告知我们如何与现有功能进行交互。
工程
广义上来讲，工程是一群人为达到某种目的，
在一个较长时间周期内，进行协作活动的过程。
所以，工程必然会涉及到的要素有：人，目标，时间，协作。
现实中的工程，所能利用的资源也都是有限的。
所以，工程化应考虑这样一个问题，
哪些人以怎样的协作方式，在资源有限的情况下，达成什么目标。
不同领域的工作，体力劳动与知识劳动的占比会有不同。
体力劳动的成果容易量化，而知识劳动则不然，
体力劳动经常能直接创造成果，而知识劳动的成果不能直接被看到。
软件开发是一项知识密集型工作，开发活动是知识的创造过程。
知识工作具有不确定性，没有人能预先评估一项知识工作需要多久才能做完。
所以，软件工程中的各种方法论，都是在用不同的方法回答，
如何对不确定性进行管控。
不论是敏捷开发，精益看板，极限编程，都能看到不确定性被管控的影子。
分层
首先，分层是架构模式的一种，它将软件分成若干个水平层，
每一层都有清晰的角色和分工，不需要知道其他层的细节，
层与层之间通过接口通信。
其次，开发者之间的合作，也可以用分层的方式来划分，我称之为领域分层，
人们常说的 “上层开发”、“底层开发”，就是这个含义，
指的是软件生产的上下游关系。
每一层的开发者，都会用到下一层次开发者提供的 “软件材料”，
经过加工处理，添加业务逻辑，向更上层提供新的服务。
开发者的价值并不在于自己的工作处于哪个层次中，
而在于如何更好的完成本层次的 “加工” 工作。
对下层资源是否熟悉，加工过程是否可控，以及向上提供的服务好不好用。
因此，“底层开发” 并没有什么神秘感可言，
也不是非要每个人亲自动手才行，
须知底层开发，也不是从零开始，他们同样是站在了巨人的肩膀之上。
所以，对自己所在层次的工具或库熟练掌握，并对当前领域有深入思考，
这才是一个工程师的核心竞争力，才是专业的人做专业的事。
结语
软件开发是一项由人参与的知识生产活动，所以千万不能只看软件不看人。
人，才是决定软件研发活动的核心要素。
本文从编程语言，设计模式，软件工程，领域分层，四个角度来进行探讨，
从新的视角进行观察，着重看它们是如何与人产生关联的。
以人为本，则知识的创造和传递过程，才会更加顺畅，
才能避免过分依赖技术武器而走弯路。
这可能是一件有趣的事情吧。