你写的代码是否无出安放-上

其实一直想聊一下这个话题,主要想表达什么呢?我见过公司里一些开发新人,他们总是抱着一个MVC三层架构死不放,只会将代码粗颗粒度的摆放在这三层中的某一层。因为大概率下是不会放错的,毕竟MVC的年龄可能比他们本身都大,总不会被否定吧?!

但其实在实际开发过程中,还是存在很多“到底放那一层更合适”的抉择的,如果能停下来多思考一下,对开发人员来说一定是意义的。而且就我个人的经验而言,多思考这个问题也是非常有价值的~

我知道,谈这种偏理论学术的话题,需要自身有深厚的编码功底,至少阅码百万?或编码10年?。。呃,要不还是算了我一介莽夫,怕会是谈错。不过,怕错怎么能进步呢?不是俗话说拉出来溜溜么?(主要是我的博客阅读量很少,哪怕说错应该不会有啥太大的影响

那么从哪里开始呢?之前听过一个ThoughtWorks的分享,分享者抛出一个观点,乍听起来觉得很震惊,但细品起来非常的有道理,那我们就先从“前后端分离”这个点开始吧。

前后端分离,写web项目的开发者一定非常的熟悉,毕竟现在不管是面向B端系统,还是面向C端系统,这种分离应该都已经是事实标准了,总不可能错吧?但八叉(上面提到的分享者)却偏说:在很长一段时间里,他对前后端分离这种做法持否定态度更多一些!!

纳尼?被雷到了?别急,且听一下他的解释,大概如下:
如果不考虑业务领域边界,仅仅从技术层面完成前后端分离,那这种分离一定会导致的是开发团队内部沟通成本增加,以及无法很好的完成端到端交付等相关问题。

我在听完这个解释后,细想一下还真的是没错。要想尽可能的表达我对这句话的认同感,需要随我一起回到过去~~

Long Long ago. Web世界连css都是新鲜事物,那时候所有的数据+样式(html+css)+交互(几乎无交互可言)都是一股脑的在后端服务器上计算好,然后再丢给浏览器渲染的。

随着web前端技术的不断推陈出新,当然也得益于Firefox和Chrome浏览器的不断发展,富客户端的概念慢慢成为了一个诱惑的选项,大家走到了一个技术路口!

前后端分离出现了,前几年(可能前十几年?)推广这个概念的时候,还炒过一段时间的“全栈程序员”的概念。它们可能没有什么直接关系,但就我的经历而言,还是想放在一起讲。只因为当时我已经在负责一个项目了,需求确定后,首先要确定的就是技术选型。而那时候团队里没有人会angular,ember或react这样的前端js框架,甚至都未曾听过这些陌生的名字。但如果不借助它们的能力,靠jQuery一个js库就去做全站的前后端分离,大家一定会觉得你疯了。。

所以当时我就成了团队里第一个吃螃蟹的人,最终将项目的前端部分用angular重构了一遍(当然是和组员一起哦)。之后的其他项目我又尝试过react,vue等几个前端框架,那段时间的自己,是需要解决项目里遇到的任何端(这里特指前端和后端)的问题的,也是那个时候我就开始思考:团队中需要一个角色,他必须是前后端都懂的,不需要精通,但要在理论和思维层面上则必须是有经验的。现在回想起来,假如当时的我把前端技术调研的工作交给同事去做,那我之后在做很多技术决策的时候一定是片面的,很可能会直接导致项目失败(虽然好像之前的项目最终也都终止了~~娃哈哈)。

只是那个时候我只是认知到了表象,即:需要“全栈思维”才能驾驭前后端分离。但这也只是前后端分离在技术层面对团队提出的一个小小的要求。当然随着框架的成熟和普及,这个要求慢慢的变的不再那么重要,毕竟经历过无数项目洗礼后,这些框架和使用它们的开发者也已经做了很多理论和思想的验证。哪怕你不思考,很多以前需要做的决策,也慢慢都成了业界的 SOP,被做成了框架的使用规范和最佳实践,根本就不会给你犯错的机会~~

那是不是说前后端分离就零成本了?答案就要回到八叉的观点了。确实,回想我参与过的前后端分离项目,的确存在着一个隐形的成本,尤其是在一些处理一些复杂业务的时候,没错,那就是沟通成本。你可能觉得沟通问题没什么难解决的,开会就完事儿了~~呃,确实,如果你很容易把所有相关人员都喊到会议室(需要参会的人数越多,发生个别同事请假,或不在状态的概率就会增加),并且他们的默契程度非常高,并且都有出色的表达能力,也有必要的同理心和责任感。那么恭喜你,你所在的团队真的是非常的出色,但我没有你那么走运,我所见过的团队,几乎没有符合这种条件的。。。

之前看过不少相关的文章,沟通,技术人员永远的痛。。尤其是当团队本身就存在前端工程师和后端工程师的独立岗位时,有时候调和他们之间的冲突,和调和不同团队,甚至不同公司之间的冲突没有什么两样,因为它们的共同点就是:立场不同!

科技公司的组织架构,也是经历过好几次迭代了。每个时代背景下出现的各种合适的组织架构都是服务于特定业务的,从来都不是由技术本身的要求决定的。前后端分离也不能例外,我们不能应为它的诸多优点(我非常认可它的所有优点,只是它对我们来说太熟悉了,不想重复描述了),就觉得它是银弹,对吧?那我们要怎么做才能最大化前后端分离的收益呢?

八叉也提到了这点,只要能做到敏捷开发中提到的端到端交付能力,就意味着团队在使用前后端分离的同时,也考虑到了业务领域的上下文。这样做能最大程度的减少不合适的领域知识扩散(当然这只是其中一点好处),将参与开发的人员降低到合理的数量,在这个业务领域内的所有知识,他们都需要共享,这是无法避免的,也是非常有价值的。

听着怎么像在夸微服务和 DDD 呢?没错啦,其实这些架构诞生都是为了解决存在的问题的。新的思想不断提供更好的解决方案,推动着整个软件开发行业的发展。这个世界就是这样运作的,不管是哪个领域都是如此。对吗?不过其实它们三个是在不同的层面解决问题的,完全可以相互配合来一起发力。

白霍了这么多,我的目的只是想从前后端分离的角度,引出一个思考:我的这个逻辑到底要放在前端还是后端来实现好呢?

我们排除那些完全不需要纠结的逻辑,例如“将数据存储到DB”这种的,再白痴也知道是要在后端处理的,对吧!!??请在你的编码人生中,找一下,看是否存在那么一个业务点,它让你纠结过的,如果有,真心希望你能留言分享一下,最好还能把你做的决定以及理由也分享出来~~感激不尽!

不管你以前是基于什么理由来做决策的,我都希望你以后在为某个逻辑思考这个问题时,能增加几个维度:

  • 该决策是否会造成不必要的沟通成本?
  • 该决策是否会造成性能问题?
  • 该决策是否会泄露商业秘密?
  • 该是否存在安全隐患?
  • 需求是否经常会发生变更,变更后该决策会造成哪些部署成本?

这里只是笼统列了一下思考点,希望对你有帮助,有机会我们再展开聊一下~~

Author: kazaff
Link: https://blog.kazaff.me/2021/09/23/你写的代码是否无处安放-上/
Copyright Notice: All articles in this blog are licensed under CC BY-NC-SA 4.0 unless stating additionally.
微信打赏
支付宝打赏