做一个有产品思维的研发：课程架构

每天10分钟，解决一个研发问题。

如果你想了解我在做什么，请看《做一个有产品思维的研发：课程大纲》传送门：https://www.cnblogs.com/hunttown/p/10490965.html

 

一、是什么杀死了我们的初创项目

1. 将军难打无兵之仗
案例：小A曾在多家一线互联网公司呆过，技术上也有不少积累。16年，他加入了一家创业公司，老板非常常识他的才化，让他带几个人做数据分析为公司的运营提供决策依据，于时小A按照一线互联网标准做了一套方案，方案中包括：一套数据仓库、一套算法建模工具、一套数据可视化系统等，预算大概在100万左右。他把方案发给了老板，当老板看了他的方案以后，一口鲜血喷在电脑屏幕上——遂卒！
总结：没那么多人，却想干那么多活。如果你招人、招人、招人，那么死法就是另一个：过早的扩大规模。

 

2. 罗马不是一天建成的
案例：小B在技术圈里混迹多年，阅博客无数，对各种技术说来头头是道。小B所在公司由于业务发展，需要对原有系统进行优化、改造。于是，老板找到见多识广的小B，让他出一套解决方案。小B发挥他的毕生所学，终于在三天天夜的奋战后给出了他的方案：新方案可以日处理MQ十亿条以上，日处理订单100万单以上，采用组件化、微服务、分步式架构。小B满意得将他的作品发给了老板，老板满意得点了点头，说道：“方案不错，你去落地吧！”，于是小B连夜逃回了老家。
总结：没有积累那么多“资源”，却想一步登天（细节请看《亿级流量网站架构核心技术》）。

 

3. 冰山下面才是关键
案例：小C是一家小企业的技术骨干，经手开发了许多业务系统，最近干得挺闹心的，准备辞职了，原因是：他新来的Leader总是Diss他，说他做的系统为什么跟BAT的差那么多？为什么没这个功能？为什么实现不了那个？
总结：优秀的解决方案都是被业务“逼”出来的！说人话就是，“业务”发展到一定阶段，量变导致了质变，出现了新的问题，已有的方式已经不能应对这些问题，需要用一种新的方案来解决，通过创新和尝试，才有了业界领先的方案（细节请看《淘宝技术这十年》）。没有那么卓越的业务场景，却幻想灵光一闪成为天才。

 

4. 人心不足蛇吞象
还有一个杀死初创项目的错误源于产品，而非工程。“经验丰富”的产品经理，他们的产品路线图通常会超出团队的能力。这种乐观情绪导致了过多的招聘、过多的开发，最终精疲力尽。在管理层看来，这似乎是因为“工程师表现不佳”，但实际上是因为管理层没有设定好清晰的愿景。

 

二、架构设计中的原则
1. 单一职责原则：简单的来说，一个模块只实现一个功能，哪怕这个模块只有两行代码，这样可以保证各大个模块大家分工协作，互不影响，各做各的事情。
4. 最少知识原则：说人话就是：低耦合，高内聚。
2. 无环依赖原则：当 A 模块依赖于 B 模块，B 模块依赖于 C 模块，C 依赖于 A 模块，导致的结果就是：循环依赖。
4. 共同重用原则：不要让重复的代码到处都是，要让它们足够的重用，所以要尽可能地封装。
5. 好莱坞原则    ：我们不需要在代码中主动的创建对象，而是由容器帮我们来创建并管理这些对象，比较有名的就是“控制反转”（或称为“依赖注入”）。
6. 大道至简原则：界面简洁，功能实用，操作方便，要让它足够的简单，换言之就是你得保证你的系统马云也会用。

只记住这简单的6条原则就够了，说多了一个也记不住也没啥用！

 

三、课程的整体架构

下面的框架结构画得比较简单，目的只是让浏览者更直观的了解整体架构。事实上，一个研发生态远远不止于这么简单！比你想象的还要复杂。

 

 

今日总结：

理想很丰满，现实很骨感。那我们面对一个项目具体应该怎么办？这里我给三点建议：

1、“做多少饭，架多大的锅”： 如果你的项目只服务于几百个用户，那么缓存可以不要；如果服务几千个用户，那么前后台分离可以不要；如果服务于几万个用户，那么中间件也不用上用场。

2、最小产品上线，根据使用反馈不断优化、迭代开发。

3、好的系统是业务不断逼出来的，不要一开始就设计面面俱到的系统，否则很有可能你在是浪费时间。