业务思考与整理

最新推荐文章于 2022-05-31 22:56:21 发布

毛毛哈

最新推荐文章于 2022-05-31 22:56:21 发布

阅读量1.6k

点赞数 2

分类专栏：业务涉及文章标签：产品设计

本文链接：https://blog.csdn.net/qq_31109797/article/details/109349893

版权

业务涉及专栏收录该内容

1 篇文章 0 订阅

订阅专栏

前言

不知觉中自己已经从事后端开发3年多了，从浙大网新到后面的酷家乐。技术栈的变化、开发模式的变化、合作方式的变化等等，都是从最新的新奇趋于平淡。慢慢的自己也对身处的业务产品有了一定的思考。

一、为什么要写这个文章？

从事开发的时间慢慢地增加，刚开始的时候总是无脑的接产品经理那边给出的需求，自己就像是一个机器人一样，或者说是一个写代码的工具。

做了一段时间以后我开发意识到了程序的性能问题瓶颈，也就开始做一些技术层面的优化，前瞻性设计技术架构、模块化代码设计、适量引入合适的中间件、代码优化等等等等。

再到现在，我有时候就在想，我写的这个代码是为谁写的，我的甲方究竟是谁（反正最起码不是产品经理，他充其量是一个需求的缓冲池和筛选器），我写的这个代码究竟是要承接公司的那一块业务。总之就是我的代码是什么人，在一个什么样场景，以一个什么样的姿势操作，获得一个什么样的结果，最后解决了一个什么样的问题。

二、工作思考

1.程序思想来源生活，应用于生活

不知道什么时候开发，我开始发现我在程序开发用到的那些理念在真是的生活场景中，不能说百分百，至少百分之九十九都已经验证了。

我是一个都市天际线游戏的忠实粉丝，我在这个游戏里面花了一定的时间，我喜欢那种在虚拟世界中建设自己的城市的那种感觉，建造一个城市最难的就是道路设计，那我们就以道路设计来举例。

相信路口大家都不陌生，道路交汇就会形成路口，有道路交汇就会有资源公用的情况，一般流量较少的小路，类似于乡下的小路，车辆行人较少的时候，发生资源争抢的概率比较低，可能我们就直接保留现状就行。但是到了车流量大的城市道路呢？最简单的方法就是加锁，红绿灯的概念应运而生，刚开始的时候我们可能给整个路口加一个大锁，后面的话可能发现这种的效率实可能有点低，可能我们会把各个车道单独设置锁，每个车道独立控制，只要保证在同一时间没有多辆车要用同一个资源就行。

然后后面流量又变大了，整个路面乱成一锅粥，这个时候我们是不是希望所有车辆都按照一个固定的队排好，做一个消息队列，这样的话可以保证绿灯亮起的最大通过率。如果车子还是在增多呢？车子可能后面队伍已经排了几条街了，难道要让大家早高峰排队，半夜的时候消费队列吗？这肯定不行，这个时候我们就要做一种更为复杂的技术选型了，是不是可以彻底消除红绿灯呢？我是不是可能做一个更为复杂的立交桥呢？或者说是不是这条道路的流量实在过大，我是不是可以做第二条道路，让两条道路做负载均衡呢？或者说我是不是可能从车辆根本入手，可以针对车辆错峰限行，或者去压缩车子的人员密度呢，这样是不是他们就可以坐公交出行，将本来几十辆车的人给压缩到同一辆公交车里面呢？

我们开发的过程方案选型越大越好吗？这个肯定是不是的，我们生活中的难道每一个路口都会设计成立交桥吗?这个方案选型的越复杂是不是会增加的程序的故障率，立交桥的建设成本是不是会远远高于红绿灯，立交桥占用地面的面积是不是会远远高于红绿灯路口，维护成本、开发成本、空间成本等等，刚开始做开发的时候往往经常会犯一个毛病，就是总是喜欢在代码中潜意思地多使用各种中间件、设计模式，但是这种东西的引入往往会把代码往复杂化的路上带偏。我们使用复杂的技术的选型的时候我认为还是要做一个完整的流量调研，就像一个基本上都没几个请求的接口，QPM都过不了10的这种，是不是就不用引入消息队列了。

2.业务高于技术，技术承接业务

以前经常能听到同事说，我这个技术框架多么多么牛逼、这个语言多么多么好。但是慢慢的我也发现了，真正为公司创造现金收益的往往都是一个产品的本身。一流的公司定标准、二流的公司做品牌、三流的公司做产品。反正说一千道一万，都没有技术啥事情。具体的技术只是这个产品的实现者。可能理解为业务定义了一个接口，具体的技术是下面的某一个实现，我这个实现可以是Java实现，也可以是PHP实现，甚至更多。我觉得技术往往都是锦上添花的一个公司，只有一个公司到达了一定的规模，才会一直注重技术的稳定性。技术往往是一个单点、业务能把这些单点串联起来，做成别人想要的一个东西，去在一个细分市场中解决用户当前遇到的具体问题。