设计模式之美
王争
前Google工程师，《数据结构与算法之美》专栏作者
立即订阅
18222 人已学习
课程目录
已更新 26 讲 / 共 100 讲
0/6登录后，你可以任选6讲全文学习。
开篇词 (1讲)
开篇词 | 一对一的设计与编码集训，让你告别没有成长的烂代码！
免费
设计模式学习导读 (3讲)
01 | 为什么说每个程序员都要尽早地学习并掌握设计模式相关知识？
02 | 从哪些维度评判代码质量的好坏？如何具备写出高质量代码的能力？
03 | 面向对象、设计原则、设计模式、编程规范、重构，这五者有何关系？
设计原则与思想：面向对象 (11讲)
04 | 理论一：当谈论面向对象的时候，我们到底在谈论什么？
05 | 理论二：封装、抽象、继承、多态分别可以解决哪些编程问题？
06 | 理论三：面向对象相比面向过程有哪些优势？面向过程真的过时了吗？
07 | 理论四：哪些代码设计看似是面向对象，实际是面向过程的？
08 | 理论五：接口vs抽象类的区别？如何用普通的类模拟抽象类和接口？
09 | 理论六：为什么基于接口而非实现编程？有必要为每个类都定义接口吗？
10 | 理论七：为何说要多用组合少用继承？如何决定该用组合还是继承？
11 | 实战一（上）：业务开发常用的基于贫血模型的MVC架构违背OOP吗？
12 | 实战一（下）：如何利用基于充血模型的DDD开发一个虚拟钱包系统？
13 | 实战二（上）：如何对接口鉴权这样一个功能开发做面向对象分析？
14 | 实战二（下）：如何利用面向对象设计和编程开发接口鉴权功能？
设计原则与思想：设计原则 (9讲)
15 | 理论一：对于单一职责原则，如何判定某个类的职责是否够“单一”？
16 | 理论二：如何做到“对扩展开放、修改关闭”？扩展和修改各指什么？
17 | 理论三：里式替换（LSP）跟多态有何区别？哪些代码违背了LSP？
18 | 理论四：接口隔离原则有哪三种应用？原则中的“接口”该如何理解？
19 | 理论五：控制反转、依赖反转、依赖注入，这三者有何区别和联系？
20 | 理论六：我为何说KISS、YAGNI原则看似简单，却经常被用错？
21 | 理论七：重复的代码就一定违背DRY吗？如何提高代码的复用性？
22 | 理论八：如何用迪米特法则（LOD）实现“高内聚、松耦合”？
23 | 实战一（上）：针对业务系统的开发，如何做需求分析和设计？
不定期加餐 (2讲)
加餐一 | 用一篇文章带你了解专栏中用到的所有Java语法
加餐二 | 设计模式、重构、编程规范等相关书籍推荐
设计模式之美
登录|注册
23 | 实战一（上）：针对业务系统的开发，如何做需求分析和设计？
王争 2019-12-25
对于一个工程师来说，如果要追求长远发展，你就不能一直只把自己放在执行者的角色，不能只是一个代码实现者，你还要有独立负责一个系统的能力，能端到端（end to end）开发一个完整的系统。这其中的工作就包括：前期的需求沟通分析、中期的代码设计实现、后期的系统上线维护等。
前面我们还提到过，大部分工程师都是做业务开发的。很多工程师都觉得，做业务开发没啥技术含量，没有成长，就是简单的 CRUD，翻译业务逻辑，根本用不上专栏中讲的设计原则、思想、模式。
所以，针对这两个普遍的现象，今天，我通过一个积分兑换系统的开发实战，一方面给你展示一个业务系统从需求分析到上线维护的整个开发套路，让你能举一反三地应用到所有其他系统的开发中，另一方面也给你展示在看似没有技术含量的业务开发中，实际上都蕴含了哪些设计原则、思想、模式。
话不多说，让我们正式开始今天的学习吧！
需求分析
积分是一种常见的营销手段，很多产品都会通过它来促进消费、增加用户粘性，比如淘宝积分、信用卡积分、商场消费积分等等。假设你是一家类似淘宝这样的电商平台的工程师，平台暂时还没有积分系统。Leader 希望由你来负责开发这样一个系统，你会如何来做呢？
你可能会说，只要产品经理给我产品设计文档（PRD）、线框图，我照着实现就可以了。我觉得，这种想法有点狭隘。我认为，技术人员应该更多地参与到产品设计中。在 Google 工作的时候，我很明显能感受到，Google 工程师跟其他公司工程师有一个很大区别，那就是大部分人都具备产品思维，并不是完全的“技术控”。所以，Google 很多产品的初期设计都是工程师来完成的，在产品发展壮大到一定程度的时候，才会引入产品经理的角色。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《设计模式之美》，如需阅读全部文章，
请订阅文章所属专栏。
请订阅文章所属专栏。
立即订阅
登录 后留言
精选留言(50)
沉淀的梦想个人觉得，如果对当前工作不满意，想要找更好的工作的话，应该多花点时间在技术上，但是如果对当前工作很满意，想要继续在当前岗位上发展的话，还是应该多花时间在业务上2019-12-25 1 17
黄林晴首先我非常赞成，技术人也要有产品的思维，但是悲催的是，对我这种喜欢和产品经理讨论需求的技术人其实说多了怕是觉得找借口……
课堂讨论:
一般面试的时候都是注重技术，但是进去公司后都是以业务为核心，我一直觉得程序猿甚至公司的竞争核心不止于技术上，如果你看好公司前途想脚踏实地干一番，那么久好好熟悉公司业务系统，如果觉得想找更好的出路就多学技术争取很好的出路✔2019-12-25 1 5
阿玛铭不懂业务（需求）是做不好业务系统的，不懂技术是做不好软件系统的。重技术作为底层通用模块，在跳槽的时候可以发挥作用，让自己的选择面更广，但也是有代价的，意思是如果跳到不同行业，以前的业务积累就没有意义了。工作性质决定，我目前和以后业务、技术时间精力投入占比分别是20、80。终身学习是人无法避免的趋势，为了增加个人综合能力和生存韧性，还会投资一些非IT相关的通用软技能。2019-12-25 3
下雨天相辅相成，缺一不可！如果说业务是场景，技术是招式，没有场景的招式是无意义的，没有招式的场景是苍白的！不同场景下选用有效招式才是最终目的！2019-12-25 3
Chen技术能力是敲门砖，是比业务能力更下层的东西，扎实的技术能力能应用于各种业务场景。我认为应该优先提升技术能力，当然当你有技术话语权的时候业务能力能够让你如虎添翼！2019-12-25 3- 大饶Raysir技术是基础，也是程序员市场的硬通货，这条路走下去可以选择架构师、技术总监；业务能在公司或团队内持续发展、转型产品项目经理、晋升团队leader，也是一条康庄大道，看性格咯~2019-12-25 2
辣么大积分系统设计第一种方案和争哥第12节实战的虚拟钱包设计思路很像呀！2019-12-25 1
陈华应个人更倾向于技术，但是并不表示不需要花心思在业务上，技术就是用来解决业务需求的，业务的复杂度也能反过来推动个人技术的成长，再总结，提炼出自己的套路，也就是经常挂在嘴边的常用架构设计方案。
做得多，技术储备丰富，应对新的业务也就更有思路和合理的技术方案2019-12-25 1 1- Geek_86269430岁之前多研究技术，30岁以后如果技术上没有什么特别突出的地方就多花点时间在业务上2019-12-25 1 1
shniu赞，这篇文章解决了我很多迷糊的东西。
对于问题，我觉得业务和技术不是哪个更需要多花时间，这两者应该辩证的看。
首先，业务和技术是共存的，相互促进的，离开业务场景单纯的技术没有意义，业务也需要先进的技术来做创新；
其次，对于个人，哪个是短板就应该补哪个，业务理解不够会影响需求分析、功能实现、架构设计、对未来的判断、对当下的判断、对扩展点的判断等，所以做技术选型权衡和设计权衡就会有很大偏差，有可能就是过度设计或者设计不当；但如果技术能力不足，就会碍手碍脚，无法施展2019-12-25 1
桂城老托尼技术同学具备产品思维是对的，但并不是说技术同学可以越俎代庖，就像文章中提到的那样，系统之间，模块之间高内聚，低耦合，彼此之间有同步，异步的交互方式。技术和PD之间的关系也应该类似，技术同学具备的产品思维我认为最主要是和PD高效沟通的目的，反之亦然，PD也应该具备一些技术思维。
回到课后讨论主题，业务复杂分为两种，一种是本身极其复杂，这种需要对应的专家型人才，无论是技术还是业务。一种是人祸造成的，代码可读性差，无业务文档或严重滞后，我见过的全部属于这一种。 两种情况技术同学选择的路径是不同的，要区别对待。
技术同学本身要把自己培养成可插拔的人才，做好高内聚，对外“接口”沟通也要有对应的练习(比如:产品思维，设计模式，软技能等，都是你和别人交互的协议，易懂高效能大幅提高自己的工作学习幸福感。)2019-12-25 1
业余爱好者永远不能忘了我是谁。我是一个程序员，技术是我吃饭的家伙，是我赖以生存的东西。无论何时我都选技术，除非我转行。2019-12-25 1
成葛格如果对目前从事的行业非常感兴趣，应该多花点时间了解有业务，否则就多了解些技术更稳妥些。2019-12-25 1
daniel李想问老师，那如果说用户需要知道自己的积分来源，那这个计算逻辑应该放在什么地方呢？
我最近在为业务开发一个调价模块(adjustment)，主要是对订单总价进行调整，调价的原因可以是营销折扣、订单属性、下单日期、供需指数、承接订单商家等级等原因，我把这些封装成多态的调价规则类(adjustment rules class)。在订单的这个生命周期，系统都必须能把adjustment按照adjustment rules分类计算出来显示给用户。
一直在思考这个计算逻辑应该属于下层还是上层，我也觉得应该是在上层，但吃不准应该由一个统一模块来计算还是让有用到调价的模块来自己计算。2019-12-25
Yes业务是锤炼技术很好的地方，只有充分了解业务，熟悉当前业务场景的需求，才能运用对技术。
并且技术结合业务的落实，在之后的面试或者工作中能更加游刃有余，有的放矢。
业务需要技术的支撑，技术需要业务来施展2019-12-25
李小四设计模式_23
这个问题太有感触了，不熟悉业务当然做不好系统，但业务理解的深度与技术能力并没有直接的对应关系。
我们先讨论一下另外一个问题：
技术人员创造的价值是什么呢？我们的技术最终体现某一个商业的业务上，解决用户的问题，从而创造价值。我们去面试，去找新的工作机会，目的是更好地实现自己的价值，目的并不只是换个涨点工资的工作。比如王争老师，现在也是在教育的这个具体的业务上闪闪发光。
这里引用一下吴军老师的“五级工程师模型”
> 第五级：能独立解决问题，完成工程工作；
> 第四级：能指导和带领其他人一同完成更有影响力的工作；
> 第三级：能独立设计和实现产品，并且在市场上获得成功；
> 第二级：能设计和实现别人不能做出的产品，也就是说他的作用很难取代；
> 第一级：开创一个产业
可以看到，在更高级别的工程师中，对于产品和商业的理解变成了一种要求，因为他是技术与现实生活的桥梁。2019-12-25
不似旧日阅2019-12-25- Randy Liu技术、业务相当于物质文明与精神文明，两手都要抓，两手都要硬，因为他们之间不是选择题，而是两个复选框都要勾选的事实，可以问下自己2个问题：1.学技术干嘛？解决实际业务问题啊！2.要懂业务吗？没有业务怎么验证你的技术掌握使用、理解情况？又怎样来验证技术的可行性与合理性？有怎样证明你拥有的技术，就值你Boss给你的那份口粮？
从技术的发展、技术的创新历史上看，大部分的技术是为业务而生。当然有时也是有了技术，才推动了技术的市场化推广。
我理解的，面试官问你业务，除了问你的业务掌握程度，你的表达能力，你的思路是否清晰？其实他们更
想听到的是一个故事，一个技术实现贯穿在业务中的故事。
而单单地问下你哈希一致性，然后照本宣科地解答下，这只是中国式教育的答题重现，我想除了知道是什么，还要知道怎么用，用在哪里，解决了什么，还存在哪些不足与弊端。
这样我们就不要堆砌形容词，自我介绍：我是一个热爱技术的人，我是一个学习能力很强的人，我是一个业务精通的人，我还有产品思维，我还懂点管理，我还懂点心理学。我，我，我。。。。。。
其实这些都是些苍白，换位思考下，你是面试官，你喜欢形容词堆砌，还是希望应聘者娓娓道来。
像化骨绵掌一样，将技术化入业务，又能将业务化入技术。
而能有“化骨绵掌”之功者，是万万不可二元地看待技术与业务。不是重技术，也不是重业务。技术业务是个孪生的，或者说是雌雄同体的，缺一不可。个人观点，仅供参考。2019-12-25 
debug两手都要抓，两手都要硬2019-12-25
Kang打卡2019-12-25
收起评论