代码改变世界

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

2019-03-08 10:05  猎手家园  阅读(867)  评论(0编辑  收藏  举报

每天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、好的系统是业务不断逼出来的,不要一开始就设计面面俱到的系统,否则很有可能你在是浪费时间。