1.2.1 服务环模型
从上一篇文章 1.1 什么是客户端 中得到客户端的定义：
客户端，就是服务商使用操作系统提供的统一接口编写出来的，为用户提供操作界面的一套软件。
我们从中可以找出三个关键字：服务商、用户、客户端
从这三个关键字中找出联系，并对他们进行一个关联排序：
- 服务商 》客户端 》用户：服务商通过客户端为用户提供服务
- 用户 》客户端 》服务商：用户通过客户端寻求服务商服务
- 第一种排序，服务商通过市场调研，统计分析工具，去主动发现需求，创造需求，开发新产品，从而售卖给用户。
- 第二种排序，用户总结发现自己的痛点，通过互联网、广告等方式寻求帮助，这些信息最终反馈给市场，当这样的需求越来越多，成为一种趋势时就会有人有团队来提供服务。
我们把这两种排序做成一个闭环：
服务商 》客户端 》用户 》市场 》服务商
服务环模型
用户将自己的需求通过市场反馈给服务商，服务商开发服务，并提供客户端产品为用户提供操作界面。
客户端作为服务商连接客户的第一道门，它的产品体验直接影响用户的购买意向，所以作为开发者的我们肩负着重大使命。
这里我为了后续的描述方便，在这里我把这个闭环叫做服务环模型。
备注：因为我们是主讲客户端开发的，所以我这里忽略了服务器上面的开发，所以并没有把服务器加入其中。
1.2.2 工程化开发
在文章 客户端工程化开发，打开你通往高薪的一条大道 中，我列举了软件工程化的八个阶段，结合服务环模型，我们来将其与服务环模型对应起来：
软件阶段与服务环对应关系
此图应立体的去看，每个分支之间并不是相互独立的，而是一个有机的整体，客户端开发只是其中一小部分，为了直观，我画了如下的工程化开发四象限图
工程化开发四象限
1.2.2.1 纵向观察
首先我们先纵向来看，把整个图分成上下两个部分
1） 处于下层的市场调研、需求分析和持续交付：这是开发客户端依赖的基石，客户端要朝着用户、市场的方向着力，这样才能够活到更久，更能为用户创造价值。所以我一直强调的是，一切需求都要先从用户，使用者的角度去挖掘分析，识别出用户真正的需求是什么，要解决什么样的问题，列好问题空间和解空间的映射关系。所以作为开发者虽不需要把所有精力放在这里，但也需要腾挪出一部分时间来思考这些，而不能总是陷在代码中，能真正解决问题的代码才是好代码，而只顾代码设计华丽不顾解决真正核心问题的代码，那都是没有任何价值的。
2） 处于上层的5个阶段：这是要在市场用户需求基础上进行开发设计，这是本系列分享的重点，详细内容会分布在后面的各个章节中，我这里就不展开描述了。
1.2.2.2 按象限观察
1） 第一象限包含架构设计、编码开发和质量管控
这是我们这一系列分享的重点，也是我们开发者需要重点掌握的东西，所以我把它放在了第一象限。
a. 架构设计，要想做好软件开发，让软件能够具有良好的扩展性，隔离性，稳定性等，这些都跟架构设计有着莫大的关系，一般架构设计可以分为：
a1. 业务架构，这一部分一般是交给产品经理做的，虽然是交由其他人做，但这一部分作为开发基础的业务知识必须要懂，否则会被牵着鼻子走，沦为纯粹的编码机器
a2. 技术架构，这一部分交给架构师做，这也是很多开发想要努力的方向，一般情况下我们在做一个大一点的系统或模块设计时，都至少要包含概要设计和详细设计，关于这部分内容，我会专门拿出几节内容，和您分享关于如何对系统进行分析，技术调研和实现方面的思考方法。
关于架构的东西，太多太散了，我并不会专门拿出一章来讲，我会在介绍某些技术时会穿插进去一些知识。想要详细了解，还请看有关方面的书籍。
b. 编码开发，这是我们这一系列分享的重点，产品经理每天都有新点子蹦出来，客服实施经常的向我提出需求，抱怨我为什么一个小需求就需要很多天的开发时间，面对种种问题，我会在第2章介绍如何创建一个具有较高可扩展性的程序框架，为我们的代码进行分层，分层的依据，如何组织类，如何面向对象编程，如何面向切面编程。在第3、4章介绍稳定程序设计，使用多进程开发客户端，如何方便的打印和收集日志，如何管理不同环境，环境切换以及如何处理环境不一致带来的种种问题。
c. 质量管控，我这里之所以叫质量管控而不是测试，因为质量把我们的视角放在了一个更高更全的维度来看待产品。例如一个手机产品的生产，如果是测试，那测试员只会关心要测试的某一部分功能有没有达标。而如果放在质量的角度，我们不仅仅关注质量是否达标，还要关注整个产品的全周期是否满足标准，包括售前和售后，例如手机中的某个功能是否是必要合理的，手机的外观是否美观，是否有好的用户体验，所以质量管控更多的是站在客户角度来看问题的。除此之外，我们还需要对产品进行充分的性能测试，为提高测试人员的人效还要进行自动化测试，这些内容我会在第6章进行分享。
2） 第二象限，包含发布更新、运维监控
a. 发布更新，客户端的更新并不同于B/S架构，不同于SaaS模式，客户端是分布在每个端系统中的，这样就产生了以下几个问题，安装包体积应尽量小，安装包和应用程序应能够支持不同的操作系统版本，位数，arm或x86这种的体系结构，当发布有问题时，如何让发布影响面积最小，这些内容将在第8章为大家介绍
b. 运维监控、客户端在不同的端系统中，我们需要对整体客户端的运行状况有个全局的监控，健康检查，用户埋点等，这些也将在第8章中给大家介绍
3） 第三象限，包含市场调研与需求分析
这部分不是我们的重点，我会在第1章中给大家讲讲我的理解
4） 第四象限，持续交付，持续集成（CICD）
这部分对于客户端，要有一套快速响应部署的机制，这样才能保证业务连续性，保证发布版本的时候所有人都不需要花费很长的时间就能顺利发布。在我和几个朋友交谈中，我发现有不少团队每次发布版本都会搞一次通宵，这是让人很崩溃的一件事情。这在本系列分享中您都会找到答案。
1.2.2.3 整体视角来看
在图的左上角我写了devops
devops是开发（Development）和运维（Operations）的组合词，一开始是被用来处理开发和运维协同工作的一个概念，但从整个devops发展历程来看，现在更多的是面向了更广的领域，即在整个产品交付价值流上所提倡的一个理念，更快更好的向用户交付价值。所以要想做到此，必须懂得合理运用devops的理念，我们可以开发或购买各种各样的工具来帮助我们达到此目的。
至此，总结下工程化开发，我们使用devops提供必要的工具，制度，文化及资源，串联起整个软件周期的各个阶段，让每个阶段协同共进，高效沟通，从而达到为客户持续提供高质量服务的目标。这就是我所讲的工程化开发。
最后，喜欢本文的大家就点个赞吧。
我的公众号会专门更新一些独家干货文章，您可千万不要错过哦
微信号：小豆君编程分享 （关注后，可加入小豆君交流群进行学习交流，也可以和小豆君一对一进行专业咨询哦）
头条号：小豆君编程分享
