2019-12-30没有经历过大型系统的全过程（设计，开发，实现，维护）。自己开发一些功能时，比较喜欢“用户故事”，这样能基本能做到一次交付一个可用功能。干就是了！先有一个原型，然后再迭代优化。最后“纸上得来终觉浅”，照着争哥的代码还是自己实现了一下：https://github.com/gdhucoder/Algorithms4/tree/master/designpattern/u025 3 15
2019-12-30老师，本文中的案例统计时间时对业务代码是侵入式的，有没有非侵入式的案例呀？作者回复: 可以使用类似spring aop 做到无侵入
2 10- 2019-12-31打卡似懂非懂 4
2019-12-30手机听读终觉浅，归来PC撸代码.。
GET完。代码：https://gitee.com/MondayLiu/geek-design.git 4
2019-12-30我觉得技术人需要一些产品的思维，这样即使在做已经设计好的产品的时候，也能提出一些不同的看法和见解，而不是一味的做一个执行者，别人说啥就做啥，而且框架的设计我觉得也是一个产品，需要我们技术人自己去推敲去打磨。 4
2019-12-30一直没有做过关于统计和监控的项目，希望老师可以出一个小的MVP🙏🙏🙏作者回复: 39 40讲 会给出完善的代码
3 4
2019-12-30感谢争哥分享，先看了第一段过来作答，完了再回到文章验证想法。
统计接口各维度信息的框架设计思路如下，
1，确认框架职责，框架的用例。采集原始数据(标准埋点日志)，加工原始数据(时间窗口内)，提供外围消费(适配各种style)
2. 细分每一职责，采集原始数据，围绕框架提供能力，确定原始数据标准，甚至原始数据标准的定义也开放给业务系统，解析关键信息的规则由业务系统自己把控。框架负责制定规则的枚举，和规则解析。
3. 加工原始数据，其实就是使用规则对原始数据流进行解析和统计，这里可以给出默认时间窗口和更新周期，业务系统可配置变更。
4. 提供外围系统消费，框架给出指标数据，自己默认展示样式，自定义样式留好扩展，交给业务系统自己扩展，框架也可以管控起来，形成类似于“主题市场”的东西。
总结下来，就是确定职责边界，高内聚框架职责，低耦合业务系统，对修改关闭，对扩展开放。基于这些原则，再往上走就是各种xx设计模式了，这时候就是水到渠成的事儿了。
-----回去再看下文章验证下猜想，不被打脸才好 。展开 3- 2019-12-30老师，后面有TDD相关的内容讲解和练习么
作者回复: 有单元测试的讲解
3 
2020-01-02目前在维护和开发营销插件系统，对于产品思维算是有一点感悟吧。
营销插件多种多样，每个插件都有一些共性的地方，也有特性的地方。插件于插件之间还有叠加互斥关系，比如说有了满减送也可以使用优惠券等等。不同的产品定义不同的插件规则，后来就出现了在同一个点上，不同插件的理解都不一一致，商家理解使用费劲。还有针对某个插件定义一些奇怪的功能，极少商家在用，但是还不允许去掉这个功能。这就为后来的优化产生了极大的阻碍，设计和开发的人都走了，奇怪的功能还涉及好几个团队，尝试过沟通，无结果，保持现状。
还有在开发新功能的时候，产品拍脑袋说这个手机壳的颜色要随心情变化，你说这能给做吗。
技术人员一定要有产品思维，代码是你写的也是你维护，某个功能是不是屎坑一定要三思，产品拍脑袋，技术不能拍脑袋，最后掉的是自己的头发，走的也是自己。一定要把风险都给他讲明白，我们不生气，我们讲道理！！！展开 2
2019-12-30像这种统计频次的功能，是通过集成框架去实现好，还是说通过mq由消费服务去实现好 1 2
2019-12-30使用线框图，采用最小原型模式，先做出一个模型，画出模型图，然后再迭代优化，使抽象的东西变得看得见摸得着，这确实是一个好方法，实际项目中也不知不觉用到了这种思想，做非业务类的需求如此，业务类的也一样。还有留言里说的用户故事也是很不错的方法，通俗点就是技术要有产品的思维，站在使用者的角度看问题。 2
2020-01-08对于复杂的业务系统，我倾向于先构思，用相关画图软件如processOn画出来流程图，再列出一个一个功能点，先面向过程实现功能再调整打磨完善代码。
技术人必须得有产品思维，懂得从用户的角度出发，才能不断打磨自身代码、程序以及产品。不然一切都是空中楼阁，再好的程序也是毫无意义的。 1
2020-01-06复杂的系统设计，首先应该梳理出功能点，整理架构设计，画出架构设计图，有了总体的规划，做下去才更顺畅。对吗老师作者回复: 是的，先做设计，后写代码。先做顶层设计，再做细分设计。
1
2019-12-30最小原型是很棒的方法，跨出第一步就成功了一半 1
2019-12-30还没有看文章的方案，先来留个言：
运行时：框架的接口是注解；通过mq将统计的数据发出到实时计算引擎例如flink，编写udf统计各种特征数据
管理时：核心是数据存储和查询模块；渠道接入放在独立的模块 1- 2020-01-31问题1：要重视设计，但是可以采取不同的方法，有的人喜欢用本文中的方法——先写一个简单的原型，在写的过程中理清楚对问题的理解和设计；也有的人喜欢将设计作为一个单独的流程，先用一些抽象的线框图推到清楚再动手。我的观点是，两者不冲突，可以两者一起使用，如果是团队项目，建议先各自有个深度的思考然后再进行碰撞合并，应该可以产出大方向没问题的设计
2020-01-16在设计一个系统的时候，不需要也不能100%都考虑到了才开始，要先设计一个能简单实现的系统，先编码实现了这个简单系统，然后逐步迭代完善；在这个过程中能用图示画出来的要画出来，图示能给人以十分直观的方式；在学习其他的课程的过程中，通过画系统的流程图就能让自己可以很清晰地了解系统的执行流程，尤其是自己总结流程图很重要！并且当时间长了来回顾复习的时候，流程图更直观，更容易复习
2020-01-1325：对于负责需求的开发，要用产品思维，首先对需求进行需求设计，然后开发出原型和画出模型图，最后迭代优化。
需求设计
1. 分为功能性需求设计和非功能性需求设计。功能性需求设计是以完成需求的基本功能进行设计；非功能需求设计是考虑功能的扩展性，通用性，性能等。
2. 具体方法可以将需求拆解，按顺序用简短的语句罗列出来，清晰有条理。
初步开发设计：在复杂需求开发时，不方便入手，有如下方法
1. 可以根据Prototype(最小原型)的思想，聚焦一个简单的应用场景，实现一个简单的原型。
2. 画出初步的系统设计图
3. 根据原型和设计图做迭代优化。展开
2020-01-13打卡
针对非业务通用框架的需求分析：
一、功能性需求分析
1、最好把信息整理成短的、罗列比较规整、分门别类的信息。
2、挖掘隐藏的需求
二、非功能需求分析
易用性、性能、扩展性、容错性、通用性
框架设计：
聚焦一个简单应用的场景、实现一个最小的原型，有一个看得见，摸得着的东西，之后进行迭代和优化。展开