理解编程原理,看这篇文章就够了~

产品狗聚集地

共 3516字,需浏览 8分钟

 ·

2023-08-03 22:38

之前有小伙伴问,如何更简单的理解编程呢?我珍藏了一篇帮助你理解编程原理的文章。分享出来:

编程,没有你想象的这么复杂。
什么是编程?——就是通过算法逻辑串联数据结构来解决具体问题并实现业务诉求的过程。
也就是:编程 = 算法逻辑 + 数据结构

算法逻辑是一步步解决问题的过程;
数据结构就是数据的呈现/存储方式。比如书放到书架,书架就是一个数据结构,把书放到箱子里,箱子就是一种数据结构,那书架和箱子都是数据的不同存储方式。

举个例子:
你18:30下班到家,怎么让家人在20:00之前吃上饭?你有两种算法,可以先煮饭然后去买菜,也可以先买菜再煮饭,哪种方式更好呢?咱来分析下:
目标:18:30到家,让家人在20:00之前吃上饭算法a:先煮饭然后去买菜算法b:先买菜回来再煮饭

这里做饭是一个程序实体(程序实体:程序中所包含的各种元素,如变量、函数、数据结构、类等),这里包含煮饭、买菜、切菜、做菜,那表达方式是:
做饭 = {  煮饭() {},  买菜() {},  切菜() {},  做菜() {},}

中文翻译成英文不就行了么?不复杂吧~
接着咱继续看,在做饭的过程中,会有很多异常情况,以下是新手的编程处理:
做饭 = {  开始() {    煮饭(); 买菜(); 切菜(); 做菜();  },  煮饭() {},  买菜() {},  切菜() {},  做菜() {    if (家里没有油了) {     买油(); 炒菜();     }     else { 炒菜(); }  }}
做饭->开始();

咱解读下:
程序实体是做饭,包含四个步骤:开始→煮饭→买菜→切菜→做菜,对吧。
做饭,可以称之为对象,这五个步骤称之为方法,然后一个个地去调用它。
首先调用【开始】方法,在【开始】方法里,又依次调用【煮饭】、【买菜】、【切菜】和【做菜】。
然后在【做菜】方法里,有一个判断:“如果家里没有油了”,新手处理方式是:先去买油,然后炒菜(这就需要再出门一趟,又浪费了时间)。如果在做菜的过程中没有调料呢?卒……

高手处理方式就不一样了。他的编程处理是这样的:
做饭 = {  开始() {    煮饭();     检查结果 = 检查();    买菜(检查结果); 切菜(); 做菜();  },  检查() {    if (家里没有油了) { 买菜的时候要买油 }     if (家里没有辣椒了) { 买菜的时候要买辣椒 }   },  煮饭() {},  买菜() {},  切菜() {},  做菜() {},}
做饭->开始();

你针对性的比较下,高手步骤中多了一个方法叫【检查】,也就是在买菜之前先检查下我要做菜缺少啥东西并记录,在买菜的时候一并买上。
你看,这就是把问题想清楚,不留任何细节。解决如何消耗最小的资源解决最大的问题。这也就是技术为什么要深入的了解业务,是为了更便捷的做技术策略。
简单吧~《编程从入门到放弃》,理解上面的,就表示你入门了。接下来就是放弃时刻了~

如果要做小炒肉、鱼香肉丝、剁椒鱼头等等好几个菜,咋办?
如果是新手,常用的处理方式:
做饭 = {  煮饭() {},  买菜() {},  洗菜() {},  切菜() {},  做菜() {},}
做饭->煮饭();做饭->买菜();
做饭->洗菜(小炒肉);做饭->切菜(小炒肉);做饭->炒菜(小炒肉);
做饭->洗菜(鱼香肉丝);做饭->切菜(鱼香肉丝);做饭->炒菜(鱼香肉丝);
做饭->洗菜(剁椒鱼头);做饭->切菜(剁椒鱼头);做饭->炒菜(剁椒鱼头);

程序本身没有问题,但是如果做要做10个菜,那程序就十分冗长,这对后续性能会有大影响。而高手会用“抽象思维”来解决问题。(把相似的步骤抽象成相同的行为,然后重复就好
他是这么处理的:
做饭 = {  开始(菜单) {    煮饭();    买菜(菜单);    菜单->逐一(做菜);  },  买菜() {},  煮饭() {},  做菜(菜品) {     洗菜(菜品);     切菜(菜品);     炒菜(菜品);   }}
菜单 = 小炒肉、鱼香肉丝、剁椒鱼头;做饭->开始(菜单);

你看,会把做饭分为三个步骤:煮饭、买菜和做菜,首先想好了一个菜单,然后抽象一个做菜的方法,这个方法里面包括洗菜、切菜和炒菜三个步骤,每一道菜都执行相同的步骤即可。
如果有10道菜,直接扩展菜单就行了,因为在程序中设置了“逐一”的逻辑。

以上是前端的业务逻辑,可以通过业务流程+业务逻辑梳理出来,和后端的存储呢?
后端可以通过一张数据表梳理:
1.整理“角色→场景(必做事项)→业务流程(输入-操作行动-输出)”来出发,用Excel完整的整理出来; 
2.接下来再往下拆一层:
  • 输入的数据包含哪些?  
  • 具体操作哪些内容(过程中是否有数据流向)?
  • 输出的结果包含哪些? 
3.再去梳理角色的功能权限和数据权限。

前端产生的业务数据存储到数据库,后端调用通过主键逐一关联数据,形成有效的数据表。至此,操作层和数据层才形成有效闭环。
而其中,业务理解是非常非常核心的。所以技术大大其实比你还想知道业务。因为怕你各种改业务需求,你一调整,他就白做了。
就好比一桌饭菜做好了,却发现家人已经在外面吃了……咋办?

看完清晰了,还是迷糊了?

希望能带给正在做产品的你一些思考。觉得还不错,帮忙在看分享吧。感谢。

这两个专辑帮助很多人提升了自己:

产品经理工作流(点击可以访问)

产品方法论和思考(点击可以访问)

浏览 1134
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报