【从开公司到开发全平台产品】3.软件开发设计阶段的思考、实践-UPUPMO

  • 本文视频版已发到 Bilibili：https://www.bilibili.com/video/BV1ut4y1W7eL/
  • 大家好，我是 UPUPMO.com 的作者 Meek，欢迎观看 《从开公司到开发全平台产品》系列。
  • 希望通过该系列可以帮助新手，快速了解全栈软件产品的一些思路、应用。
  • 如果你心中有创意，也想独立开发产品，可以在视频或文章的最后，查看联系信息加我好友。
  • 本期我们讲解第三章：《软件开发设计阶段的思考、实践》
  • 我们将会从以下5个小节进行探讨：
1. 竞品分析
2. 原型设计
3. UI 设计
4. 架构设计
5. 基础数据准备（爬虫）
6. 项目管理

1. 竞品分析

3

1.1 总结

  • 目标： 通过竞品了解其背后的用户群体、应用场景、推广策略、运营策略
  • 长度： 竞品分析是一个持续性的过程，需要跟进产品的迭代、发版
  • 注意： 如果你不喜欢的这一行，你很难投入热情去做，最好是知道自己喜欢什么。

1.2 步骤、细节

3

  • 准备思维导图，用于制作功能点图
  • 区别：直接竞品、间接竞品、潜在竞品
  • 区分：核心功能点、特色功能点、次要功能点，排出优先级
  • 把所有竞品的功能点、流程等信息先用思维导图客观罗列出来，不用急着分析。因为分析竞品很容易有主观情绪，所以一开始先客观罗列即可。
  • 摸索各个功能点的开发动机，它们要解决用户什么问题，怎么触发、怎么流转
  • 画出核心主体 ER 图：一对多、多对多、一对一等关系，用传统数据库方式思考，可以有效约束思考范围
  • 画出核心、高频操作的流程图
  • 截图交互亮点（流程步骤、提示逻辑等）
  • 截图视觉感光亮点（UI 配色、字体等）
  • 询问周边的人对竞品的第一印象
  • 制作 Excel 对比不同竞品之间的优缺点
  • 了解竞品公开市场报告，包括：
技术架构
行业报告
人才招聘
社区交流
动态新闻
官方文档、博客
客户咨询
用户存量
日活
活跃时长
产品营收
产品版本发布记录
融资情况
商业合作
国家政策

1.3 输出用户故事

XXX 产品的 XXX 功能，是希望能解决 XXX 类用户能在 XXX 场景下能解决 XXX 问题，能解决 XXX 数量问题
XXX 产品的 XXX UI 做了 XXX 改动，为了解决 XXX 问题
XXX 产品的 XXX 交互做了 XXX 改动，为了解决 XXX 问题
XXX 产品新增 XXX 功能，为了解决 XXX 问题
XXX 产品删除 XXX 功能，为了解决 XXX 问题
XXX 产品 XXX 版本和 XXX 版本之间的变动，透露了 XXX 意图

2. 原型设计

  • 如果是个人开发，精细度不用太高。时间没有那么多，能表达出要做什么、怎么做即可。
  • 有突发灵感时候建最好立刻议记录下来。
  • 我不是很推荐现在的产品经理还需要专门再写一个《需求文档》，而是借助原型的备注，在上面备注满你想表达的细节。
  • 让原型作为产品经理的唯一文档、唯一工具，这对团队协作有至高的帮助。
  • 行业早期，网络不好，云协作不存在的时候需要本地化 Word 文档，是大家都不得不做的事，可是现在的时代变了啊。
  • 如果需要落盘存储做证据，现在云协作也是可以导出 Word、HTML、PDF，完全也可以作为最终交付物的。

2.1 客户端软件

3

  • Axure，中规中矩，网络上免费模板很多，但因为不是 Web 架构，所以协同效果不好

2.2 网页端软件

3

  • 墨刀，免费额度很低，基本等于收费。但是素材广场有很多模板可以直接使用
  • VIP 用户还可以导出安卓 APK，可以分享观看，可以多人协同
  • 还有一些其他懒得介绍了

3. UI 设计

3.1 客户端软件

3

  • PhotoShop
  • Sketch
  • Adobe XD
  • 我个人倾向于 Adobe XD 的跨平台，并且网上素材也很多

3.2 网页端软件

3

  • MasterGo
  • 蓝湖
  • Figma
  • 我个人倾向于 Figma，但是可惜是在外网，所以只能选其他。
  • 国内推荐 MasterGo。

3.3 代码设计

3

  • 如果对细节要求不高的话，可以直接堆代码来代替设计。现在的 UI 框架样式美观，基础组件齐全。
  • TailwindCSS
  • Element Plus
  • Vant
  • Ant Design Vue

4. 架构设计

3

4.1 架构是什么

  • 架构目前可以为：软件架构、硬件架构、业务架构、应用架构、基础架构、数据架构等等各种架构。
  • 不管你是怎样的定义架构的，我只认为：架构是一种人类分工能力的体现，是作为高级工具人的体现，是 5W2H 一种体现。
  • 马克思说过：分工作为一切特殊的生产活动方式的总体，是从物质方面、作为生产使用价值的劳动来考察的社会劳动的总体形式
  • 附 5W2H 解释：
what     >>> 是什么？目的是什么？做什么工作？
why      >>> 为什么要做？可不可以不做？有没有替代方案？
who      >>> 谁？由谁来做？
when     >>> 何时？什么时间做？什么时机最适宜？
where    >>> 何处？在哪里做？
how      >>> 怎么做？如何提高效率？如何实施？方法是什么？
how much >>> 做多少？做到什么程度？数量如何？质量水平如何？费用产出如何？

4.2 为什么要做架构设计?

  • 因为要服务的客户越来越难伺候，市场同类产品竞争越来越激烈，要求越来越高，复杂需求越来越多，团队成员需要更多协调
  • 技术上的复杂，一般我们可以概括为：
高性能：我这个不能等，那个不能等
高可用：这个为什么点不了，那个为啥访问不了
可扩展性：为什么加个新类型要开发一周
低成本：为什么 Go 的项目就是比你 Java 用的内存低
安全：一失足千古恨
规模：数据越来越多，功能越来越多
体验：这个要能搜索，那个要优雅
  • 以上的种种本质都是为了以尽可能以最低的代价服务好用户。
  • 我们看待问题尽可能抓本质，所谓的各种优化、缓存、MQ 等等都是手段，要不要用，怎么用，就是架构师的核心。
  • 事情永远是做不完的，要懂得排列优先级顺序。
  • 学东西尽可能系统化，不要片段化。

4.3 好的架构可以带来什么?

  • 清晰性
  • 扩展性
  • 可维护性
  • 安全性
  • 稳定性
  • 可控性
  • 复杂性
  • 高性能

4.4 架构的核心：人

  • 企业、公司等社会组织都是个壳，最终做事的是人，最终决定成就、决定问题的根本都是人。
  • 是人决定技术，是人写了代码，所以面试挑选出适合团队文化的人是非常非常非常的重要的一件事。
  • 架构的前期也是围绕着人来，要识别出项目相关干系人，围绕这些人进行思考
  • 人是重要的，但是人又往往是不靠谱的，能用程序执行的，最好别用人。
  • 人都是有惰性的，如何制定规则，彼此鞭策，让彼此之间能一起勇往直前是门学问
  • 人要高效的前提是需要信息透明化（包含：自我透明化、项目透明化、关系透明化），透明的信息是让同事、领导信任你的基础。

4.5 领导力

  • 做领导核心能力：教导能力，协调能力，全局能力
  • 领导是决定船向的人，领导技术不行、管理不行，理论上不存在下属行的，除非历史原因遗留的人。
  • 做领导该授权的时候大胆授权，不应该什么事都身体力行，时间是有限的
  • 做领导最忌讳的就是只会提这个，要那个，无法给团队提供帮助，无法给成员赋能，无法系统性思考问题。
  • 做领导最应该制定好目标，协调好资源，确保合适的人在合适的时间做合适的事情，保证成本最低也是最高效。
  • 做领导的最好是每天晚上花半小时筛选简历，招聘很是看缘分。并且备选人才多了，也不用担心下面的人不够用，不用担心刺头。

4.6 做架构的优先原则是什么?

  • 服务于现实，脱虚与现实
  • 合适原则：适合当下，适合当前企业的人力情况、成本、业务等条件，而不是说 Rust 比 Java 内存低、性能强，我就要。
  • 简单原则：在满足需求的情况，越简单越好，能不用微服务就不用，能不用 K8S 就不用，能不用 Hadoop 就不用
  • 演化原则：大多数事情都是无法一步到位的，人最喜欢变化

4.7 架构必经之路：语言之争

  • 我不忠于某个语言，我只终于其生态。从找工作角度上考虑，Java、JavaScript、HTML/CSS 这类长期多。
  • 语言学得越多，有对比才会有伤害，在学习过程中必然会在自己心中产生一个最适合自己的语言
  • 能做全栈是最好的，做个产品不会求着别人支持。
  • 产品不一定是要某一类，可以是类 Linux 系统，也可以是微信生态的一小个产品等等，只要是有人用，愿意掏钱，或者可以有广告收入、赞助就是可以的，过程是艰辛的，需要不断摸索。
  • 我自己写过 Java、Scala、JavaScript、HTML/CSS、Python、Go、Dart、SQL、Shell
  • 我写 Java、Scala 是因为我需要 Spring Boot、Spark、Flink
  • 我写 JavaScript、HTML/CSS 是因为我需要前端展示
  • 我写 Python 是因为我需要爬虫、数据分析
  • 我写 Go 是因为我需要轻量微服务框架、容器化
  • 我写 Dart 是因为我需要 Flutter 做移动端
  • 我写 SQL 是因为我需要查询数据库
  • 我写 Shell 是因为我需要运维应用
  • 我不是为了学习语言而学习，我只是要它们的生态而已，我其实很希望这个世界只有一个完美的跨端操作系统、开发生态。只是这不可能会发生。
  • 目前行业没有办法用一种语言干所有事，只能一直学习。
  • 学习多了，知识点多，全记脑袋肯定是没办法的，要边学边做笔记边练习，善于用搜索。
  • 虽然我写 Java 较多，但是从微服务角度来讲目前我更加看好 Go、gRPC、CNCF 一系列生态。
  • 微服务讲究的就是微，Go 确实很适合，也适合做些工具类。目前它就差一个类 Pivotal 企业专注在 Web 框架领域的公司。
  • 现在很多企业根本没到微服务的阶段，并且他们也负担不起一年二十万的服务器费用，所以不要为了架构而架构。大多数企业都是没钱、没能力。
  • 更加长期看我比较认可 Rust 这种编译期就能解决99%问题的死板语言，就是目前生态还太弱了，需要继续观察。
  • 虽然 Spring 也在努力，比如在尝试 Spring Native，但是毕竟晚了太多，我还是相信未来 10 年，在微服务领域一定是以 Go 为主导。

4.8 架构设计流程

  • 识别系统复杂度之处，也就是系统的难点。需要优先做调研、预研
  • 多种方案评估原则：性能、复杂度、成本、可扩展性、可用性、部署迭代成本

4.9 DDD 的借鉴（领域驱动设计）

  • 声明：不是什么项目都可以上 DDD 的。如果只是简单的 CURD 就可以解决的业务系统。业务逻辑简单，模块彼此关联不多系统，都是不应该用 DDD 的。
  • DDD 适合指导复杂微服务服务，因为 DDD 的限界上下文适合指导微服务的划分。
  • DDD 是可扩展的业务架构方法论，它的核心诉求就是将业务架构映射到系统架构上，在响应业务变化调整业务架构时，也随之变化系统架构。不是为了高性能、高可用等技术问题而设计的。
  • DDD 强调从需求分析到代码实现到测试的整个过程各人员之间的沟通需要使用一致的无歧义的领域内通用语言。该通用语言必须能够准确反映业务需求和领域知识，而不是反映技术实现。
  • 所以 DDD 对整体团队要求都很高，不建议小团队使用。
  • 即使是传统的 MVC 结构，我也特别推荐大家学习 DDD 的实体、聚合根、值对象、各种 api 入口要严格区分，虽然代码量会增加好几倍，但是这个业务复杂度会直线下降。代码量可以考虑通过生成器来解决。

4.10 微服务

  • 微服务是服务组织结构的，组织结构不满足，微服务是无法落地，或者做得很痛苦
  • 微服务不是拆分得越细越好。拆得越细，改动起来牵扯的外部关联系统越多，协调起来很难，可靠性也低，排查问题困难。
  • 做微服务就必须上链路跟踪、监控平台，要把排查问题流程要规范化，不然一出问题就会很耗时间。
  • 微服务很依赖基础设施，如果基础设施不完善，整个过程生不如死
  • 微服务中单个服务可以紧贴业务快速迭代，最主要的是也可以更好地管理庞大开发人员
  • 去中心化组织和部署结构，减少不必要的协同；
  • 数据和商业逻辑受同一个服务控制，从而在商业逻辑快速变更的同时，保障数据模型的
  • 数据和状态独立封装，保障一个业务快速演变的同时，还不污染其他业务；
  • 服务本身的独立部署能力使得容错和容量弹性最大化；
  • 细粒度服务发布回滚和故障响应能够有效隔离，出了问题可以迅速降级或回滚。

4.11 核心图

3

  • 声明：不要死扣 UML 规则，比如一定要按 UML 的某某形式来画图。
  • 我们要提取这些图本身要表达什么，至于画图是用图标、文字、圆圈、椭圆等等啥根本不是重点，但是不能瞎画。
  • ER 图
  • 时序图，核心业务流程一定要有时序图
  • 业务架构图
  • 系统架构图
  • 部署架构图
  • 核心功能有时序图、流程图

4.12 数据库设计

3

  • 主推 Navicat Premium 16，可以直接与数据库互相转换，支持显示字段注释
  • 次推 PDManer

4.13 YApi 接口设计（重要）

3

  • 这个我认为是最重要的一个环节，理由如下：
  • 后端不应该先急着写代码，而是跟着模型、前端页面开始写注释来表明开发思路，在备注中写明这个 API 接口应该是怎样的逻辑，这些会被代码生成器作为注释生成到代码里面
  • API 的请求参数、响应参数都会生成代码
  • 写完的 API 可以直接给前端开发初期联调使用
  • 如果中间有某个环节 API 写不出来，那就说明这里需要继续沟通、协调，尽可能在项目初期发现问题
  • 然后代码生成器根据 API 生成前、后端大部分基础代码，开发人员再去完善细节

4.14 做好压力测试

3

  • 不一定要强调测试结果要如何如何，但是至少要有数据，作为初始基准
  • 每一次底层框架升级、JDK 升级都会做相同条件的压力测试，确保这次升级是否有必要，不要听别人说怎么怎么好

4.15 做好 A/B 测试

  • 微服务系统建议最好 A/B 测试，确保没问题，数据可行再发布

4.16 做好监控

3

  • 不管是单体、微服务都要做好监控
  • 首推 Prometheus

4.17 提早做用户画像、智能推荐

  • 小团队没有过多服务器，可以定时日志下载到本地电脑做离线分析
  • 只有了解自己的客户才能知道后续要往哪里走
  • 小团队方案：服务器调度任务 > 服务器 coscmd 上传日志 > 本地下载日志 > filebeat > kafka > Flink、Spark > MySQL、ClickHouse

5. 基础数据准备（爬虫）

5.1 Web 方向

3

  • 抓包：Charles
  • 自动化：Scrapy、Selenium

5.2 APP 方向

3

  • 安卓 ROOT：TWRP、Magisk、Move Certificates
  • 抓包：mitmproxy
  • 自动化：Uiautomator2、Weditor、AirTest

6. 项目管理

3

6.1 敏捷开发方法

  • 大多数公司都谈敏捷，但敏捷不是银弹：敏捷方法论是无法直接转换为技术生产力，敏捷解决不了技术问题，写不出代码。
  • 敏捷作用是：能增强团队效率，提早暴露问题，从而降低开发成本，提高产品质量的一种管理技术、一种团队文化。
  • 敏捷框架很多，没有说一定要照搬那些框架的规规矩矩，而是借鉴学习，能根据自己的团队进行适配是最好的，抓住其管理本质。
  • 敏捷开发诞生在 2001 年，其中有一个主张的 工作的软件：高于详尽的文档
  • 在 2012 年后，Markdown 开始大面积流行之后，我个人是不认可这个主张的。
  • 我认为传统的 word 文档应该尽可能避免，全部转向 Markdown，转向各类云协作软件
  • 我个人不古板地倾向于任何敏捷框架
  • 让客户尽早介入，参与其中，看项目是否变形（只是有些甲方确实很蛋疼，外行并且喜欢做爷，不是认真想做事的）
  • 敏捷开发适合沟通能力较强的成员，因为主张多沟通、协作。闷声写代码的其实并不是一个优点。
  • 结合极限编程、Scrum、看板、精益等框架，我比较认可点如下：
站立会议
编码规范
迭代演示
定期汇报
任务看板
头脑风暴
回顾总结
消除浪费
技术分享
统一协作语言（DDD）
座位集中，方便直接面对面沟通
用户故事：做一位<XXX角色>，我想要<XXX活动>，以便于实现<XXX商业价值>
复杂业务、流程尽可能结对编程（两人水平要差不多）
对新员工进行 code review
攻关时刻可以考虑：租个小别墅封闭开发 2~3 周左右，不以太长。
  • 6.2 头脑风暴的时候需要注意：
中间不许评价
异想天开
越多越好
每个人都参与（但不是人越多就越好，有些人只会扯蛋的，做领导的需要直接当面教训，要嘛就是直接让人滚动。做领导没魄力，影响团队整体氛围就是领导的责任。）
  • 6.3 精益的消除浪费说明：
只有部分完成的工作：只有部分完成但没有最终落地的工作。
未应用特性：开发完成但没有被客户应用的特性。
额外过程：开发过程中不需要的流程和中间产物。
再次学习：人员、环节变动导致反复重新学习。
信息移交：隐性知识信息的传递，总是伴随信息丢失。
任务切换：多任务工作会导致效率下降。
资源依赖：因任务或资源相互依赖而导致工作停滞。
系统缺陷：解决缺陷活动本身就是浪费。
无效的会议：讨论与其他人无关的事情。

6.4 分工模式

  • 小企业，我偏向垂直分工，也就是一个项目对应一整个团队，这个团队有产品、开发、测试、运维，他们需要坐一起，全力为几个项目服务。
  • 中、大型企业，我偏向垂直、水平两者结合，类似管理里面的轮值制度。
  • 可以有技术预研团队，有业务团队之分。但是每个人都需要周期性轮换，做项目的时候以项目为核心，做预研以预研为核心。
  • 能在这个转换过程中快速适应，学习能力强的就是最好的人员。
  • 不同人可能会擅长不同的业务模型，也需要在过程中了解成员的想法。
  • 一些复杂的业务模型，需要能力较强的人来执行，比如基础架构、会员中心、营销规则等

6.5 认知、原则

3

  • 5W2H
  • 5 Why
  • FMEA 方法
  • 木桶理论
  • 逻辑树法
  • 麦肯锡7步分析法
  • 金字塔原理

6.6 工具

3
3

  • TAPD + 企业微信（推荐）
  • 飞书一整套
  • 码云一整套

推荐几本书

book

  • 这几本书都是以人、技术角度进行综合探讨，是我比较推荐的
  • 《架构即未来》
  • 《软件架构师的12项修炼》
  • 《从零开始学架构：照着做，你也能成为架构师》
  • 《系统架构设计：程序员向架构师转型之路》

下期预告

  • 下期我们将介绍《后端开发的思考、实践》，分别从以下 4 个方面进行讲解：
1. 后端行业中常见争议
2. 后端企业级架构标准
3. 各类数据库应用场景
4. 如何挑选技术、框架

最后

  • 如果你心中有创意，想自己开发产品，可以微信联系我。
  • 如果你觉得视频、文章对你有帮助，欢迎点赞、收藏、转发。我们下期见。
posted @ 2022-06-05 19:59  UPUPMO  阅读(80)  评论(0)  编辑  收藏  举报