读书记录--架构

2024-12-31

记录

架构师成长第一步：如何做需求分析（方法经验总结，纯干货系列） - 云飞龙行2021 - 博客园 (cnblogs.com)

1：理解业务，要准确、全面、深入

　　这是需求分析阶段最最重要的工作。

　　准确的意思就是：对每个功能点的理解，要没有歧义，不可再分。

　　如果一个功能点，不同的人有不同的理解，这就是有歧义；另外这个功能点，里面还有很多小功能点，是可以再分的，这也是不行的。

　　可惜咱们在需求文档里，看过太多这样的坑，往往一两句话，就一笔带过好大一个功能块，最后为了填坑，多耗费出上月的人力和时间。

　　因此，架构师在做需求分析的时候，对每一个功能点，一定要准确，要求理解到没有歧义，不可再分，基本要到最细粒度的操作，比如：新增、修改这样的功能。

2：识别重难点业务

　　这个算是架构师的一个基本功，拿到需求后，架构师要能识别出里面的重难点业务，对它们的分析和设计，可能会影响到后面的技术选型和具体的架构设计。

　　毕竟，软件只是工具，是用来帮助实现业务活动的工具；而架构设计是为软件服务的，是为了更好的开发和制作软件这个工具。

　　因此，对于重难点业务的把握，可能直接决定了架构设计的成败，一定要非常重视。

3：识别非功能需求和质量约束

　　非功能需求：就是除去业务功能需求之外的需求，通常也是软件质量约束的一部分，比如对系统：性能的要求、可靠性的要求、可扩展性要求、可维护性要求、安全要求、备份恢复的要求等等。

　　这些要求对于架构设计的影响是非常大的，很多都是架构设计要重点考虑的问题，比如：性能、可靠性、可扩展等等。

4：业务架构

　　这个通常是以产品人员设计的业务架构为主，但技术架构师需要在准确、深入理解的基础之上，按照技术人员能理解的方式，对业务架构进行微调，输出一个技术落地实现的业务架构。

需求分析告诉我们到底要做什么，连这个问题都没有解决，谈何架构设计。如果要做什么都不清楚，请问这个架构设计为谁做，做来干什么呢？

现在有一些所谓的架构师，轻业务而重技术，成天高谈阔论各种技术，名词满天飞，为了技术而技术，却忘了架构设计的初心，这是很不可取的。

可以毫不客气地说，这些人根本算不上是真正的架构师，称之为“伪架构师”或者“PPT架构师”。

做需求分析的基本方法

1. 明确系统边界
2. 采用模拟业务运转的方式加深对业务的理解
3. 采用不断问问题的方式，进行业务挖掘和深入理解
4. 不断进行功能分解，把复杂的、较大的功能，分解为颗粒度较小的功能，直至不可再分 -- 那得对代码和业务多熟悉，很难啊？
5. 逐字逐句地去读需求说明书，读出显示的或者是隐含的功能点
6. 换位思考
7. 对于非功能性需求，需要尽量明确到指标，并准确理解相关的约束条件

程序员突破内卷大法：聊聊软件架构师成长之路（干货系列，说人话接地气） - 云飞龙行2021 - 博客园 (cnblogs.com)

问题

缺失

• 非功能指标 ➕ 2024-12-31
  • 我们是什么业务
  • 我们的业务涉及的指标有哪些
  • 这些指标影响到的组件、流程有哪些
  • 如何具体测量
  • 常规的指标是多少
  • 常规的提升方法是什么
  • 涉及的功能点，需求点有哪些
  • 如何排期，推动优化

总结