- Java锁的逻辑(结合对象头和ObjectMonitor)
- 还在用饼状图?来瞧瞧这些炫酷的百分比可视化新图形(附代码实现)⛵
- 自动注册实体类到EntityFrameworkCore上下文,并适配ABP及ABPVNext
- 基于Sklearn机器学习代码实战
三天研发,两天设计; 。
01 。
【优先做设计方案】 。
职场中的那些魔幻操作,研发最烦的是哪个?
作为一个数年且资深的互联网普通开发,可以来说明一下为什么是:缺乏设计; 。
面对业务需求的时候,可能都听过这样一句话:
这个很简单,直接开发,三天内上线; 。
产品听了流泪,测试见了崩溃,研发眉头一皱直呼什么鬼; 。
如果没有听过,那么职场的经历可能是不完美的,但是幸运爆棚; 。
这种魔幻般的神奇操作,逻辑在哪里?底线在哪里?唯独离谱在这里; 。
从实践经验上来看,产品研发抛开业务设计所带来的反伤,也许会迟到,但绝对不会缺席; 。
所谓的简单业务流程,仓促上线之后,后续补坑的成本可能高的离谱; 。
相对于完整的研发周期来说,设计、落地、一次性的高质量完成,就是成本最低,效率最高的决策; 。
对于研发角色,方案设计通常就是围绕技术和业务两个核心; 。
02 。
【常用的方法论总结】 。
在做方案设计时,必然要运用一些基础的方式方法; 。
有关方法的经验总结很多,但是真正常用的并不多,以下只围绕个人在工作中常用的几个来分析; 。
理解本质的时候,必须明确在一定的空间和时间范围内,需要有边界约束; 。
如果范围扩大,考虑的因素太多,相互间的影响和关联过度复杂,脱离实际太远,很难得出符合现状的结论; 。
在工作中时常会说:透过现象看本质,理解不同事物的共性和个性,判断发展逻辑; 。
那么,如何理解产品研发的本质?
基于业务的供需关系,持续打造优质的产品服务; 。
这个描述只是个人的实践体会,对于事物的本质理解,应该简单明了,直击核心内容; 。
矛盾是指事物内部以及事物之间的对立统一关系,虽然概念很抽象,但现象几乎是无处不在; 。
用通俗的方式来理解,就是需求和利益之间的冲突且统一的关系; 。
以常见的平台商业形式来思考; 。
平台方:希望以低成本的服务获取更高的营收; 。
客户方:希望以低成本获得更好更优质的服务; 。
平台与客户双方,都希望低成本付出,获取更高的回报,矛盾就这样产生了; 。
但是,平台失去客户,没有持续生存的能力;客户本身又依赖平台服务,关系既统一又存在冲突; 。
双方的合作,随着不同阶段的核心问题被解决,即事物的不断发展变化,新的问题和矛盾也会出现; 。
理解事物的全貌,横向扩展的广度,纵向发展的深度,在时间空间的变化中,以动态的思维应对事物的变化; 。
简单的说就是:全面的看事物,系统的解决问题; 。
以实际的研发案例来分析; 。
面对并发业务的复杂流程时,比较经典的就是抢单场景,处理的思路有很多种; 。
如果资源足够,直接扩展以支撑请求处理; 。
如果资源不足,可以限制请求端的放行比例,服务端只处理少量请求; 。
或者服务端对请求异步解耦,快速失败掉大量的请求; 。
所以在面对问题时,不必只片面的看一个方向,围绕问题的矛盾多方,统筹寻找平衡的解决方法; 。
在周期现象中,存在事物的发展和演变规律; 。
即事物在运动、变化的发展过程中,某些特征多次重复出现; 。
比较经典的现象就是业务的发展周期:孵化期、验证期、成长期、成熟期、衰退期、转型或者消亡期; 。
理解事物的发展周期,可以在不同的阶段把握核心事项,解决关键问题; 。
分而治之是研发的核心能力之一,强调对复杂事物的拆解能力; 。
随着技术水平的成长,面对的业务问题也更加复杂,必须具备拆分能力,分而治之; 。
流程的分段管理;技术与业务的分离;代码工程的分层维护;系统的分布式架构; 。
这些都是研发过程中常用的分治手段; 。
面对诸多的方法论,首先围绕几个基础方法进行思考和实践,从而理解其内涵和精髓; 。
然后,再借鉴其他的方法,形成自己的方法体系; 。
基于一些核心的方法论之上,再去思考业务和技术的设计,在思路上就会成熟很多; 。
03 。
【如何分析业务】 。
想要分析业务,首先要深刻的理解和洞察业务整体; 。
在个人习惯上会考量三个层次:首先理解业务全貌,其次理解负责的业务板块,最后理解具体的业务需求; 。
理解业务全貌,本质就是明白公司在做什么,组织架构的协作流程,团队的工作方向; 。
业务的常规定义:行业的基本模式,运作的流程,具体的事务执行; 。
在实际的工作中,职级越高越是需要具备对业务全貌的分析能力; 。
行业分析并非普通玩家所能理解的,需要极其顶级的思维和知识储备,以及对各个信息的统筹分析; 。
作为研发来说; 。
应该理解业务的投入和营收,并且能意识到这种模式是映射到产品设计或者服务中的; 。
必须理解业务模式所对应的产品矩阵设计,各个核心功能的流程和路径; 。
个人的工作习惯,并不是常规的流程机制; 。
明确自己负责的业务板块,把握工作重心,不同阶段中调整能力的输入(学习)和输出(生产价值)策略; 。
产品矩阵的设计与业务模式有直接关系,也是梳理自己工作板块的核心依据; 。
对于产品来说,常见的拆分有两种; 。
例如以端口为依据划分的C端和B端,以系统为依据划分的业务应用和数据应用; 。
对于业务来说,拆分的模式则更加灵活; 。
在运营概念上可能有多个业务线,但是对于研发来说,各种业务线之间存在诸多的流程交互; 。
对于个人来说,可以从业务、技术、数据三个基础的方向梳理,或者根据具体的运营模式梳理; 。
理解业务全貌和个人的负责板块,以此明确工作重心和方向; 。
理顺业务全貌与自己负责板块,更偏向于内在的务虚方向; 。
研发对于职场的真正价值,还是在于各个版本的具体需求实现; 。
分析具体的业务需求时,依然有一个对齐的过程; 。
将具体的业务需求向业务全貌对齐,理解其价值所在; 。
将业务需求向自己的工作板块对齐,理解自己的价值所在; 。
实现版本的业务需求,既要对齐大的业务框架,也要理清需求本身,把握版本落地的质量; 。
04 。
【理解技术架构的演进】 。
对于技术规划来说,通常分为:业务和技术两个方向; 。
可以分析一个复杂系统的迭代过程,从而理解技术方案在规划设计上的演变规律; 。
从架构的概念来描述:单服务、集群模式、分布式服务、系统级分拆; 。
横向扩展,其映射的是业务流程和模式的复杂度,随着业务的不同发展阶段,需要进行不同级别的服务拆分; 。
从单个系统架构的纵向来分析:展现层、应用层、业务层、组件层、存储层; 。
纵向深入,其映射的是业务逻辑的复杂度,在纵向上进行分层设计,可以降低逻辑管理的难度; 。
基于常规的分布式系统来看,业务研发在演变的过程中,也会拆分为应用级业务,公共业务两大板块; 。
应用业务实现的是具体需求场景,而公共业务则是大多数应用都依赖的基础业务能力; 。
基于常规的分布式系统来看,合理的架构设计,必然会追求技术与业务的分离; 。
在代码工程的分包上,可以独立封装技术层面的组件应用,以便于统一维护和升级; 。
在服务级别上,可以将组件服务拆分为业务(侧重业务解决方案)与技术(侧重技术解决方案)两个层次; 。
分析业务,把握技术架构的演进历程,将二者进行统筹结合,就是方案设计的主线; 。
05 。
【统筹技术和业务方案】 。
设计研发方案,自然需要把握业务的整体,规划技术架构,确保业务和技术双线推进; 。
方案的核心则是围绕当前阶段的具体业务需求,设计实现流程、目标、指标; 。
分别把握整体与阶段的核心目标,作为方案设计的基础指导原则; 。
从业务整体上看,系统建设与技术架构应该围绕大的业务目标去考量,支撑或者驱动业务发展; 。
从业务阶段上看,把握当前阶段的业务本质,关键问题与核心矛盾,在版本需求中有序解决; 。
分析业务的运转流程和特征,映射为技术的实现过程,作为方案设计的核心思想; 。
业务的运转流程,围绕客户、产品、组织协作来设计,侧重于场景的分析; 。
业务映射的系统流程,将业务流程和特征转化为系统实现的流程,侧重于两者的统筹分析; 。
核心逻辑的实现流程,围绕具体需求,设计逻辑时序图,侧重于关键问题的分析; 。
围绕具体需求,设定相应的目标和指标拆解,作为方案执行结果的考量标准; 。
版本需求立项之时,就对结果有明确的预期,目标贯穿业务需求的完整周期,在组织协作中是关键导向; 。
指标用来衡量目标达成的执行过程和最终完成度,侧重于对目标进行验证; 。
综合来看,对于业务和技术的方案来说; 。
有业务的整体思考,技术的系统性架构,具体需求的核心设计与落地执行,以及目标和指标的衡量标准; 。
06 。
最后,回到工作实践中来,做事虽然有很多方式方法,但是从来没有绝对的标准; 。
业务也好,技术也罢; 。
在周期演进的过程中,始终受到组织架构和团队人员的最根本影响; 。
所以在输出业务和技术方案时,要围绕环境的真实现状,做出相应的调整优化,把握核心即可; 。
最后此篇关于设计「业务」与「技术」方案的文章就讲到这里了,如果你想了解更多关于设计「业务」与「技术」方案的内容请搜索CFSDN的文章或继续浏览相关文章,希望大家以后支持我的博客! 。
关闭。这个问题需要更多focused .它目前不接受答案。 想改善这个问题吗?更新问题,使其仅关注一个问题 editing this post . 4年前关闭。 Improve this questi
.NET 框架:4.5.1 我在 Blend for visual studio 2015 中遇到一个奇怪的错误,我找不到它的来源。 如果我在 VS 中打开我的 WPF 解决方案,它会加载并运行良好。
我经常遇到这样的问题,与 Hierarchical RESTful URL design 非常相似 假设该服务仅提供用户上传文档。 POST, GET /accounts PUT, DELETE /a
在 Rails 应用程序中,我使用 devise 来管理我的用户,而我用来销毁 session 的链接不再有效。它正在工作,现在我添加了事件管理员,但没有。 我的链接是 :delete, :clas
我已经坚持了超过 24 小时,试图按照此处发布的其他解决方案进行操作,但我无法使其正常工作。我是 Rails 新手,需要帮助! 我想让我的/users/edit 页面正常工作,以便我可以简单地更改用户
Devise 在以下情况下不会使用户超时: 用户登录,关闭选项卡,然后在超时 + X 分钟内重新访问该 URL。用户仍处于登录状态。 如果选项卡已打开并且稍后刷新/单击,则超时可以正常工作。这意味着
我想使用这样的 slider 我希望该 slider 根据提供给它的值进行相应调整。到目前为止,我只能应用具有渐变效果的背景,但无法获得这种效果。请通过提供样式代码来帮助我。
您应该为每种方法创建一个请求/响应对象,还是应该为每个服务创建一个? 如果我在所有方法中使用它,我的服务请求对象中将只有 5 个不同的东西,因为我对几乎所有方法使用相同的输入。 响应对象将只有一个字典
我正在尝试在 REST 中对实体的附件进行建模。假设一个缺陷实体可以附加多个附件。每个附件都有描述和一些其他属性(上次修改时间、文件大小...)。附件本身是任何格式的文件(jpeg、doc ...)
我有以下表格: Blogs { BlogName } BlogPosts { BlogName, PostTitle } 博客文章同时建模一个实体和一个关系,根据 6nf(根据第三个宣言)这是无效的。
如果 A 类与 B、C 和 D 类中的每一个都有唯一的交互,那么交互的代码应该在 A 中还是在 B、C 和 D 中? 我正在编写一个小游戏,其中许多对象可以与其他对象进行独特的交互。例如,EMP点击
关于如何记住我与 Omniauth 一起工作似乎有些困惑。 根据这个wiki ,您需要在 OmniauthCallbacksController 中包含以下内容: remember_me(user)
设计问题: 使用 非线程安全 组件(集合,API,...)在/带有 多线程成分 ... 例子 : 组件 1 :多线程套接字服务器谁向消息处理程序发送消息... 组件 2 :非线程安全 消息处理程序 谁
我们目前正在设计一个 RESTful 应用程序。我们决定使用 XML 作为我们的基本表示。 我有以下关于在 XML 中设计/建模应用程序数据的问题。 在 XML 中进行数据建模的方法有哪些?从头开始然
我正在设计一个新的 XSD 来从业务合作伙伴那里获取积分信息。对于每笔交易,合作伙伴必须提供至少一种积分类型的积分值。我有以下几点:
设计支持多个版本的 API 的最佳方法是什么。我如何确保即使我的数据架构发生更改(微小更改),我的 api 的使用者也不会受到影响?任何引用架构、指南都非常有用。 最佳答案 Mark Nottingh
关闭。这个问题是opinion-based 。目前不接受答案。 想要改进这个问题吗?更新问题,以便 editing this post 可以用事实和引文来回答它。 . 已关闭 4 年前。 Improv
我想用 php 创建一个网站,其工作方式与 https://www.bitcoins.lc/ 相同。确实,就每个页面上具有相同布局但内容会随着您更改链接/页面而改变而言,我如何在 php 中使用lay
我有一个关于编写 Swing UI 的问题。如果我想制作一个带有某些选项的软件,例如在第一个框架上,我有三个按钮(新建、选项、退出)。 现在,如果用户单击新按钮,我想将框架中的整个内容更改为其他内容。
我正在尝试找出并学习将应用程序拥有的一堆Docker容器移至Kubernetes的模式和最佳实践。诸如Pod设计,服务,部署之类的东西。例如,我可以创建一个其中包含单个Web和应用程序容器的Pod,但
我是一名优秀的程序员,十分优秀!