10x程序员工作法
郑晔
火币网首席架构师,前ThoughtWorks首席咨询师 ,TGO鲲鹏会会员
立即订阅
7942 人已学习
课程目录
已完结 56 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 程序员解决的问题,大多不是程序问题
免费
思考框架 (1讲)
01 | 10x程序员是如何思考的?
以终为始 (11讲)
02 | 以终为始:如何让你的努力不白费?
03 | DoD的价值:你完成了工作,为什么他们还不满意?
04 | 接到需求任务,你要先做哪件事?
05 | 持续集成:集成本身就是写代码的一个环节
06 | 精益创业:产品经理不靠谱,你该怎么办?
07 | 解决了很多技术问题,为什么你依然在“坑”里?
08 | 为什么说做事之前要先进行推演?
09 | 你的工作可以用数字衡量吗?
10 | 迭代0: 启动开发之前,你应该准备什么?
答疑解惑 | 如何管理你的上级?
划重点 | 关于“以终为始”,你要记住的9句话
任务分解 (11讲)
11 | 向埃隆·马斯克学习任务分解
12 | 测试也是程序员的事吗?
13 | 先写测试,就是测试驱动开发吗?
14 | 大师级程序员的工作秘笈
15 | 一起练习:手把手带你分解任务
16 | 为什么你的测试不够好?
17 | 程序员也可以“砍”需求吗?
18 | 需求管理:太多人给你安排任务,怎么办?
19 | 如何用最小的代价做产品?
答疑解惑 | 如何分解一个你不了解的技术任务?
划重点 | 关于“任务分解”,你要重点掌握哪些事?
沟通反馈 (12讲)
20 | 为什么世界和你的理解不一样
21 | 你的代码为谁而写?
22 | 轻量级沟通:你总是在开会吗?
23 | 可视化:一种更为直观的沟通方式
24 | 快速反馈:为什么你们公司总是做不好持续集成?
25 | 开发中的问题一再出现,应该怎么办?
26 | 作为程序员,你也应该聆听用户声音
用户故事 | 站在前人的肩膀上,领取属于你的高效工作秘籍
27 | 尽早暴露问题: 为什么被指责的总是你?
28 | 结构化:写文档也是一种学习方式
答疑解惑 | 持续集成,一条贯穿诸多实践的主线
划重点 | 一次关于“沟通反馈”主题内容的复盘
自动化 (12讲)
加餐 | 你真的了解重构吗?
29 | “懒惰”应该是所有程序员的骄傲
30 | 一个好的项目自动化应该是什么样子的?
31 | 程序员怎么学习运维知识?
32 | 持续交付:有持续集成就够了吗?
33 | 如何做好验收测试?
34 | 你的代码是怎么变混乱的?
35 | 总是在说MVC分层架构,但你真的理解分层吗?
36 | 为什么总有人觉得5万块钱可以做一个淘宝?
37 | 先做好DDD再谈微服务吧,那只是一种部署形式
答疑解惑 | 持续集成、持续交付,然后呢?
划重点 | “自动化”主题的重点内容回顾汇总
综合运用 (7讲)
38 | 新入职一家公司,怎么快速进入工作状态?
39 | 面对遗留系统,你应该这样做
40 | 我们应该如何保持竞争力?
答疑解惑 | 如何在实际工作中推行新观念?
划重点 | “综合运用”主题内容的全盘回顾
总复习 | 重新审视“最佳实践”
总复习 | 重新来“看书”
结束语 (1讲)
结束语 | 少做事,才能更有效地工作
10x程序员工作法
登录|注册

35 | 总是在说MVC分层架构,但你真的理解分层吗?

郑晔 2019-04-01
作为程序员,你一定听说过分层,比如,最常见的 Java 服务端应用的三层结构,在《15 | 一起练习:手把手带你分解任务》中,我曾提到过:
数据访问层,按照传统的说法,叫 DAO(Data Access Object,数据访问对象),按照领域驱动开发的术语,称之为 Repository;
服务层,提供应用服务;
资源层,提供对外访问的资源,采用传统做法就是 Controller。
这几乎成为了写 Java 服务的标准模式。但不知道你有没有想过,为什么要分层呢?

设计上的分解

其实,分层并不是一个特别符合直觉的做法,符合直觉的做法应该是直接写在一起。
在编程框架还不是特别流行的时候,人们就是直接把页面和逻辑混在一起写的。如果你有机会看看写得不算理想的 PHP 程序,这种现象还是大概率会出现的。
即便像 Java 这个如此重视架构的社区,分层也是很久之后才出现的,早期的 JSP 和 PHP 并没有什么本质区别。
那为什么要分层呢?原因很简单,当代码复杂到一定程度,人们维护代码的难度就急剧上升。一旦出现任何问题,在所有一切都混在一起的代码中定位问题,本质上就是一个“大海捞针”的活。
前面讲任务分解的时候,我不断在强调的观点就是,人们擅长解决的是小问题,大问题怎么办?拆小了就好。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《10x程序员工作法》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(19)

  • 西西弗与卡夫卡
    万维钢有期节目里提到芯片设计时讲到了分层以及模型的概念。分层或模型,实质是因为人的认知能力有限不得已而为之的。学习计算机,我们都知道晶体管,即便早就忘了它的原理。实际上晶体管涉及非常深奥的物理学知识,这是绝大多数人一辈子都不需要了解的物理学。抛开复杂艰深的物理学,晶体管的本质却很简单,它就是一个包含通和不通两个状态的开关,这就是它构建的模型。

    在开关的模型基础之上,信息论的创立者香农用一篇硕士论文构建了逻辑门这层。他证明了可以用最简单的开关,实现所有逻辑运算。

    逻辑运算层次之上,就是我们所知道的CPU模型。再往上,就是我们所熟悉的信息世界

    作者回复: 同是精英日课的读者,这篇内容还真的是受到万老师的影响写下的。

    2019-04-01
    23
  • Wei
    分享一下自己的经历,best practices 其实在不同时期有不同的理解,有时候甚至变化很大,我自己也有迷惑的时候。 我是做ror出身的,rails 就是标准的MVC,再加上一个helper目录;

    初入行时候接触的项目,controller都很臃肿,后来,提倡的是 thin controller, fat model, 于是大家又把逻辑搬到model里面;于是model又变得非常臃肿,里面包括了很多业务逻辑,耦合太高,写起测试来非常痛苦;

    另外,原本helper只应该放关于view的method, 却很快变成了垃圾桶,很多不是view相关的方法都扔在了helper目录下,甚至很多controller要include 其他controller 对应的helper, 只是因为那里定义了一个可以用到的方法。

    再后来,有了presenter的概念,helper目录基本就不用了;每个controller都有对应都presenter,再有,就是建立了service的目录,把业务逻辑从model里面抽离处理; 这样的结构稍微清洁了一点,测试也好写了很多。

    但是在我看来,我们项目presenter/services这种分层没有什么标准,有些同事还是把这种分层当作万能垃圾桶,什么都建一个,甚至业务/运算都扔在presenter里面;services 的分层也是一个问题,很多只是根据model的来分,而不是业务; 最近有看了一下elixir对应的phoenix , 它引入了context的概念,更偏重于业务划分, 我感觉这是一个比rails 更合理的分层。


    PS:非常喜欢老师的这个课程,收益良多,能否建立微信群/slack/小密圈 之类的以便课程结束后能继续与老师和各位同行交流。 谢谢

    作者回复: 多谢你的分享!后续的安排看编辑怎么协调吧。

    2019-04-04
    3
  • One day
    老师提到的直接把第三方类库的字段直接使用,导致bug层出不穷,这个真的是深受其害,线上程序莫名bug,原来是第三方修改或者擅自把字段等出现问题,改来改去,最后还是用类似老师提出那种转化本地对象再使用,最后做了类似一个防腐层那种解决问题。实际才出的坑总结到这么个东西,就是类似老师提出的模型概念

    作者回复: 道理很简单,痛过才知道。

    2019-04-01
    3
  • kevin
    从分层一步步说到领域层的设计重要性,学起来很过瘾。文末留言万老师关于晶体管的设计很精彩

    作者回复: 欢迎把它分享给你的朋友!

    2019-04-07
    2
  • 码农Kevin亮
    请问老师,在jdk的集合框架中常常会在实现类内部维护一个内部类,比如HashMap内部有个Node内部类,这算领域对象么?

    作者回复: 在通常的讨论中,这是不算的。

    2019-09-02
    1
  • desmond
    学了REST和DDD,感觉两者有相通的地方:两者都以数据(一个是资源,另外一个是领域对象)为中心,并制定一套标准的数据操作(一个是HTTP Verb,另外一个我项目主要用JPA这一套);而核心是业务建模。

    作者回复: 你的理解很棒!

    2019-04-02
    1
  • 丿淡忘
    老师你好,就是我现在在开发的时候有些困惑,我将界面逻辑层(界面数据显示)
    业务逻辑层(具体业务逻辑功能实现)分出来后,但像支持这些业务的一些服务,比如 通讯服务,数据缓存服务,这些算是工具,还是说也可以分为一些单独的层,还有像界面显示的数据我需要给界面单独提供一些界面显示的数据结构,还是直接使用逻辑层里面的数据结构,还是说这些数据结构单独拆分出来也可以作为一层

    作者回复: 看六边形架构的图,通信服务属于六边形架构的适配器。

    2019-04-01
    1
  • Jxin
    对项目中变化代码和稳定代码的拆分。按特性归类成变化层和稳定层,中间用门面或适配器对接。针对变化层提炼出抽象层用装饰者模式或抽象工厂实现多态

    作者回复: 学习 DDD,建立模型概念,你就不纠结于这里的设计模式了。

    2019-04-01
    1
  • shniu
    目前对DDD还是一头雾水,尤其对领域模型的抽象和划分,郑老师能不能分析一些实际的案例,这样能有一个更直观的体验
    2019-04-01
    1
  • 丁丁历险记
    不知道ror 死掉没。。。
    2019-11-18
  • 旭东
    分层是为了更好的抽象,区分出程序中的不变点与与易变点,集中精力优化抽象不变点,以便更好的复用不变点逻辑。尽可能的快速添加和修改易变逻辑响应业务变更需求

    个人认为:分层设计有点像代码设计模式里的模板设计模式。但分层设计更像是代码组织的模板,功能和交互层面的分组的模板。分层设计不但做到代码的分层也促进了分工合作,从而达到快速,简单,高效开发的目的
    2019-10-01
  • 春之绿野
    文章有些地方看不懂,不太懂领域对象什么的
    2019-09-15
  • 春之绿野
    很多技术都是吧,都是为了把一些通用的基础的功能抽象出来,Robot 框架也是,提供了很多实现基础功能的类库,通过这些基础的关键字可以组成新的关键字,再由关键字组成更复杂的关键字,我们只用关心怎么实现功能,而这些关键字怎么调用,编译,log和结果怎么一层层展示,这些都由框架实现了。
    2019-09-15
  • Rainbow福才
    分层架构设计的目的:
    1. 提炼抽象,构建好领域模型。
    2. 降低软件开发和维护成本。
    3. 扩展性更好。
    2019-04-10
  • Sudouble
    以前总是在追逐优雅的设计方案,全让未估计到为什么要这么设计。静下心来,去看问题的本质,这是我这一节学到的~!

    作者回复: 祝你学有所成

    2019-04-07
  • 跟过一段时间微软的silverlight,一开始听说是wpf的子集,后来又有人辟谣说除了使用xaml等形似之处外差别很大的。自己也看过两者的源码,就抽象能力和程度看还是正宗wpf强大,虽然不是业务框架,但从开发工具角度来看,它的基于自身定位及领域的体系设计还是值得称道的。曾经有一段时间里java和.net相互diss的厉害,现在看来在道的层面是可以和谐共处的,只是术上各有各的呈现罢了。
    2019-04-06
  • 大力
    微服务中的数据访问层,有可能跟访问数据库一点关系都没有,而只是一层调用http请求去访问其他微服务的封装,但它的原理其实跟传统的分层结构应该是一致的。
    2019-04-05
  • 小小
    产品,开发,测试,运维,运营等岗位也属于分层,不同技术栈的人,组成完备技术体系。

    作者回复: 这个理解比较……跨界

    2019-04-04
    1
  • hua168
    拿java来说,在MVC分层架构中,Controller 和 Service界限是怎么区别的?
    我理解是:
    M:DAO层,编写数据库连接
    C: 控制层,主要是写业务方法,方法中包含对数据库的一些操作
    V: 展示层,主要是展示

    哪服务层在哪里?服务层=Controller?也不对呀

    MVC原理图网上有很多,下面连接的对吗?
    http://i1.excel99.com/x3edf03d1838280c01dc489d36d78b81a1099d52b.jpg
    2019-04-02
收起评论
19
返回
顶部