SOLID 是一套原则。它们主要是关心代码质量和可维护性的软件专业人员的指导方针。 React 不是面向对象，但这些原则背后的主要思想可能是有帮助的。在本文中，我将尝试演示如何应用这些原则来编写更好的代码。 在前一篇文章中，我们讨论了单一责任原则。今天，我们将讨论 SOLID 的第二个原则: 开闭原则。 本系列其他文章 如何应用 SOLID 原则在 React 中整理代码之单一原则 什么是开闭原则？ Robert c. Martin 认为这个原则是面向对象设计最重要的原则。但他不是第一个定义这个概念的人。Bertrand Meyer 于1988年在他的《面向对象软件构造》一书中写到了这一点。他解释了开放/封闭原则: 软件实体(类、模块、功能等)应该对扩展开放，但对修改关闭。 这个原则告诉您以这样一种方式来编写代码，即您能够在不更改现有代码的情况下添加其他功能。 让我们看看我们在哪里可以应用这个原则。 让我们从一个例子开始 假设我们有一个 User 组件，其中我们传递用户的详细信息，这个类的主要目的是显示该特定用户的详细信息。 这是一个很简单的开始。但是我们的生活并不是那么简单。几天后，我们的经理告诉我们系统中有三种类型的用户: SuperAdmin、 Admin 等等。 它们每个都有不同的信息和功能。 一个糟糕的解决方案 第一个也是显而易见的解决方案：在组件中包含一个条件，并根据不同的用户类型呈现不同的信息。 import React from 'react'; export const User = ({user}) => { return <> <div> Name: {user.name}</div> <div> Email: {user.email}</div> { user.type === 'SUPER_ADMIN' && <div> Details about super admin</div> } { user.type === 'ADMIN' && <div> Details about admin</div> } </> } 你知道这里出了什么问题吗？...

关于开发是否应该深入了解业务，听到两种我觉得不正确的类型： 「我是开发，我就做好开发就行了，业务交给产品和运营同学」。不懂业务，完全不想了解型。 「懂业务之后就可以跟产品 PK 了，方便砍需求」。懂业务，目的不正确型。 我的观点是要想当一个优秀的开发者，必须懂业务，不是为了跟产品 PK，而是为了预判未来的发展方向，好指导自己写的代码可以适应未来更久的时间。 懂业务，目的不正确型。 作为一个开发，不知道多少人经常会在耳边听到这么一句话：多了解业务，多了解业务。 但是大部分情况下并没有告诉你为啥要了解业务。 可能有些人心里会有这么一个答案：懂了业务可以在需求评审的时候可以跟产品 PK，指出他的需求不合理，然后给出一个合理的方案，这就是你对于业务的价值，然后就可以体现你的业务思考了；另外对于你觉得不合理的需求，还可以砍掉。 这是我听到最多的关于为什么开发要懂业务的观点了，我以前也是这么认为的，但是当我真正的作为一个业务 owner 之后，逼得我不得不去了解业务，我才觉得这个观点不完全对，方向都是错的。 上面观点的核心目标就是跟产品 PK，把产品作为开发的敌人去看待。现在网上很多这样的调侃，产品和程序员是对立的。 在产品的眼里，程序员天生就是爱砍需求。 而在程序员的眼里，会因为不会砍需求被老板教育，不要啥需求都接，要学会砍需求。 实际上，懂业务不是为了去指导产品设计，而是为了预判未来的发展方向好指导自己写的代码可以适应未来更久的时间。 懂了业务之后是去发现前端的“价值点”，不是为了跟产品 PK。。。。 你如果去指导产品做产品，反过来想想如果让产品指导你做开发，那能靠谱吗? 我很赞同玉伯说的专业度的问题，作为开发就是要在开发的专业度上表现出来，效率让产品业务都觉得不可思议。而不是让你的产品、业务能力表现出来让他们觉得不可思议(不是不行，但是这样很难，先把自己专业的搞好再说)。 不懂业务，完全不想了解型。 另外还有一些是基本不怎么了解业务，就喜欢专研技术，这种想法基本是工作年限不超过三年的同学。刚毕业，对业务没有什么感知，觉得做技术的技术才是王道，整天喜欢研究各种新技术，处于一种被动接需求的状态。 这种情况就很容易在晋升的时候无法说清楚业务价值，到底自己做的东西有什么用，给公司带来了什么价值，因为在做需求的时候本来没有去思考过业务价值，所以没办法形成闭环，仅仅只是零散的需求。 实际上，我们应该这样做，在业务的背景之下，我们可以主动的**发现问题、定义问题、解决问题、优化效果，拿到结果。**这才是创作个人业绩的正确路线。 如果不懂业务，怎么将技术放到业务里去？不放到业务里去怎么体现技术的价值？ 你不能光讲我做了一个什么东西，这个东西多么多么好，这个业务价值如果没有体现出来，那就是没用的。 总结 上面分析了两种思维模式的差别，以及我觉得正确的思考方向。 作为一个在业务团队的开发者，我们做一件事的时候，需要时刻提醒自己，要想清楚三个问题： 弄清楚，为什么做这件事？做这件事的价值是什么？ 去思考，如何做这件事？ 完成后的产出是什么？明确衡量标准。 你们觉得作为一个业务团队的开发，业务和技术的关系应该是什么样的呢？

大家好，我是桃翁！ 之前有小伙伴留言让我聊聊「希望聊一些在大厂工作是什么体验，想听如何融入，如何适应，如何成长的规划，遇到过的哪些比较棘手的问题和怎么处理的，期待」。 他这里这么多问题，我准备每个问题都写一篇文章来聊，首先咱们要聊的就是「大厂的工作体验」。 身边牛人多 可能很多想去大厂的同学，第一驱动力觉得大厂肯定很多大佬，然后进去了可以带带自己。 其实这句话不全对，也别抱太大希望，进来了可能跟你的想法是不一样的。 我的体感是：前半句是对的，大厂里确实很多牛人，但是不会带你的，或者说不是你想象中那么带。 在阿里这边一个新同学刚进来的时候，会在组内分配一个师兄，来协助你顺利度过试用期。但是不是那种事无巨细的关注你的那种，大部分时间师兄每天也很忙，一个新人来了还要帮你解决问题，所以师兄就会更忙了，所以师兄主要是帮你解答一些问题。 再说说身边其他的牛人，牛可以很多方面的： 比如 学校牛，在杭州这边浙大的比较多，我们组才 12 个人就有三个浙大的，还有在国外上大学的。 网红，可以接触到很多之前只能在知乎、或者一些大会里才能看到或者听说的一些大牛，来了之后就可以见到，甚至面对面交流，每次交流都会受益匪浅，比如我在蚂蚁体验技术部就可以接触到玉伯、偏右这种超级前端网红。 技术牛， 不管是 P5、P6、P7 哪个层级的，你都会发现每个人在一个甚至多个方面技术很厉害，说两个我们组的 P5，工作才一年多，早已经是 React 或者微前端方面的专家了，更高层级的那就更不用说了。 总之，大厂里有非常多的优秀的人，意味着你有很多可以学习的榜样，如果有一些技术上的问题，以前可能只能在开源项目的 issue 上提问，现在你可以通过钉钉甚至直接面对面的进行交流。 但是我还是秉承着一个观点，身边的人优秀，并不意味这自己优秀，也没人会主动带着你变成优秀的人，需要自己主动去跟他们学习，让自己成为别人眼中优秀的人。 做项目成就感强 既然是大厂，不管是员工和用户相对都比较的多，做的东西反馈也会很多，不管是好的还是差的，都能感觉到有很多用户在使用，能感觉自己再为这么多人服务，能获得价值感。 像我现在做的项目虽然是给内部小二(小二就是内部员工)用的，但是每天 UV 也有好几千，PV 也是上百万的，这跟我之前在上家公司做的内部系统就不太一样，之前做的东西不管好还是不好，没有什么人反馈，所以总是在找需求做，做出来也不知道有价值，存在感就比较低。 如果能做 C 端用户的项目，比如像五福、双十一、双十二这种运营活动，虽然过程很艰苦，但是我相信做完了之后一定是满满的自豪感。 做项目的成就感就来自于给自己、给别人带来了价值，能服务别人，如果你感受不到这份价值，这个项目估计不久就凉了。。。 压力大 我以前在蘑菇街的时候每天正常作息上下班，基本没在工作上感受到过压力。 但是在蚂蚁无处不在的压力，有时会把自己压得喘不过气，不过大部分时候会把压力当做动力，努力向前。 一方面来自于项目压力，据我了解，在蚂蚁的业务团队相对于技术团队来说会忙一些。我们组现在主要是做业务，我们这边发布频率基本上一周一个迭代，一个迭代里可能还包含好几个需求，布频率极其高，项目周期又都很紧。 偶尔还有项目紧急到需要倒排工期，就是不管你怎么搞，就是要在某一天上线。 另外一方面来自于周围同事压力，前面也说了，周围的牛人很多，每个人身上你都能发现比自己优秀的地方，比自己级别低的、一个级别的要想着不要被别人超越，比自己级别高的，需要考虑怎么才能跟他们一样优秀。 对于项目压力大的正反馈就是逼着自己去做一些可以提效的技术方案，对于周围同事压力正反馈就是逼着自己去像他们学习，让自己变得越来越优秀。 后记 这次主要聊的是环境和项目上的感受，下一篇会介绍一些关于技术上的一些体验。如果你之前没呆过大厂，你可以聊聊你想象的大厂是什么样子。如果你之前在待过，或者现在正在大厂里，可以聊聊你的感受是什么。 同一个环境可能由于自己的心态不同，感受也会有差别，我只是分享我的感受，希望给你带来帮助。

前言 2020 年真的是不平凡的一年， 疫情夺走了很多人的生命，还夺走了我的工作(公司因为疫情被迫裁员)，所以今年换了工作来到了蚂蚁，在蚂蚁的工作经历跟之前在蘑菇街完全不一样。。。 工作 来蚂蚁这半年我觉得在工作上的成长比我之前在蘑菇街一年半的成长都还多，经历比较丰富。 阿里一直都有拥抱变化的文化，我来大概五个月的时候就换了三个主管，经历了好几次的组织架构变动，我刚进来的时候同组的同事（之前组内大概 12 人）到现在还跟我一组的仅剩一名。 不过随着每一次的变动，我的分工也越来越清晰，从最开始哪里缺人就去哪里，再到负责一块模糊的业务线，再到一个人带着 3 个合作伙伴负责一整个业务线，再到现在有了 3 个正式加 6 个合作伙伴的阵型。 作为整个业务线的 owner 不仅要接需求还要去预测业务未来的走向，这样才能在技术上做好提前的准备，当业务真的来了，才能快速的支持。这个是我在试用期答辩的时候面试官给到我的期望，这个我在之前试用期结束后有写过。 原来我是个业务性选手？？？？ 只不过那个时候我只是觉得这个话说得很对，并没有体感，但是当我在负责整块业务的，以及带着一群人在做的期间，作为业务 owner 必须得去思考这些了，因为我们这里业务发展得很快，虽然我们业务团队成员变多了，但是需求也越来越多，所以如果不提前去做一些业务上的预测，技术上的沉淀，当业务发展再快点，需求再多一些我们目前的这些人就消化得很吃力，甚至吃不下，这是我今年非常大的一个收获。 对于这个收获其实我之前想过我为什么可以得到，我刚开始把原因归结到了运气，因为我能有机会负责一条业务线的东西是由于我的师兄以及其他大部分同事都走了，现有的业务只能由留下来的人去承担，所以我当时想到了那些得到晋升或者 375 的同学是不是运气好，可以做到好的业务或者技术。但是又细想如果机会给你了，如果没有把它当机会，而且他这块重重的东西当做负担，或者平常心看待，可能也做不出什么优秀的成果。 但是一件平凡的事情如果交给一个优秀的人去做，大概率还是会做出优秀的东西。 所以最后我得出的结论是运气可以让一个准备好了，有实力的人加速成功，但不会让一个平凡的人获得成功。 学习与写作 当我在准备写总结的时候，我本以为今年读的书(去年 20 本)会比去年要少，没想到今年还略多一点，读完的都有 29 本了，但是我明显能感觉到今年花在读书上的时间变少了，特别是在入职蚂蚁之后，属于自己的时间更少了。 我想可能是渐渐的找到了读书的方法，越读越快了吧。 下面是我今年读书列表：豆瓣主页 在写作方面今年公开文章产量就很低了，只有 13 篇，基本都是上半年写的，下半年入职蚂蚁之后就基本没怎么写了，一方面是因为确实工作太忙了，另一方面需要在公司内部写不少的文档。 文章列表见博客：前端桃园 技术 很遗憾今年对技术没有做什么深的研究，主要是业务太忙，把我对技术的追求抹平了，整天就想着如何能把业务支持下去。 来蚂蚁半年没写过 React，大部分时间写钉钉小程序和支付宝小程序，另外还写了将近两个月的云凤蝶。 在我没怎么接触过小程序前，对小程序有刻板的印象，总觉得小程序限制太多，很简单，没有什么意思，当然也不知道其原理，所以对小程序比较抵触。 但是当我写了两三个月之后，对小程序了解得越来越多，但是另一方面发现自己对小程序了解得越来越少，为什么这么说呢？ 当我还没怎么接触小程序的时候可能想到的就只有 小程序的语法是什么样的，小程序是怎么运行的，但是写得越来越久，发现自己以前的视野太小了，整个小程序生态还有很多东西可以去研究，越写越发现自己不会的越来越多，这些不知道反而让我对小程序产生了兴趣，感觉可以有新的东西值得去研究。 比如小程序他是怎么运行的，跟原生、H5 之前的区别在哪里，关联是什么，view 层是怎么渲染的，逻辑部分的 js 是怎么执行的，与客户端，容器是怎么通信，怎么打包的，怎么编译的，编译出来的东西又是什么，怎么发布上架的，以及什么情况下使用小程序技术栈、什么情况下使用 h5 技术栈，等等等，这些没有搞明白的问题深深的让我对小程序产生了兴趣。 所以明年在技术上的一个目标就是深入小程序。 生活 家人 生活方面最令我开心的就是女朋友在 11 月份从上海辞职，来到了杭州，结束了 3 年的异地恋，每天下班后有个人在家里等的感觉真好！ 旅游 西安旅游 国庆去西安旅游了，在去西安之前我们还先去南京溧水参加了【咪豆音乐节】。这次是准备得最充分的一次，还做了一些攻略。 重庆 Outing 重庆三峡博物馆 江景：重庆洪崖洞夜景...

01 前几天我试用期转正答辩了，老板也给过了，给到我的评价大概是：业务型选手，接下来一两年很关键，如果能够在业务中深入挖掘，会是个好苗子，否则就比较平了。 这个评价其实我还是没想到的，或者说我之前根本没想过结果。 其实我从大学毕业以来，都觉得自己是个**技术型选手，**之前在蘑菇街的时候我也是按照技术路线走的。在蘑菇街的时候工作不是很忙，所以也有时间去研究技术，也乐于分享然后才经常写文章，才做了公众号。 02 不过在我年初的时候，我对技术的追求稍微弱了一点，这是在蘑菇街的时候准备晋升答辩过程中的一些变化。我的前辈呀、主管呀、HR 呀，在我准备 PPT 的期间都不断的给我灌输，你做的东西到底有什么业务价值？ 在这期间，我的 PPT 找了好几位前辈包括自己的主管都 review 过，也给他们进行试讲，每次的给到我的建议都会有，要注重业务价值。 之后我的脑海里就深深的有了这么一个意识，技术是为业务服务的，技术的价值源之于业务的价值，而不是技术本身的价值。 所以我在后面的工作中，会更注重业务价值，在做需求的时候不再去追求高大上的新技术，热技术，而是花更多的心思去问这个需求的背景，能解决什么问题，能为用户带来什么价值，能给公司带来什么利益。 ** 03 没想到我把这个意识也带进了蚂蚁，在蚂蚁的工作是非常忙碌的，我后面会写文章记录一下在蚂蚁有多忙，但是现在我只想说一点，反正忙到没时间去折腾新技术，注意是折腾不是学习，因为我在蚂蚁做的东西对于我来说，一直都是新的技术，但是没有时间去专研，学习新技术是为了完成需求。 在答辩的前三天我还在跟我的老板说，业务太忙了，没时间写总结了，目前只写了一个总结的目录(可能就 50 个字左右)；老板跟我说，在 9 月 2 号前一定要提交总结，不然系统会自动试用期不通过，在那时我快要崩溃了，项目这么急，哪有时间写总结呀，还要答辩。 真的是抽不出时间来写总结，每天加班到凌晨两三点，回家就想睡觉，根本没精力写。 在答辩的前一天晚上，大概 8 点多的时候，其他伙伴在工作的时候，我就抽了大概一个半小时的样子按照我之前的目录写完了，感觉写出来毫无亮点，看起来就是自己的血泪史。反正就当完成任务了，明天毕竟要答辩了，不可能啥都没有吧，然后写完继续改 bug。 那天我也回去得比较早，大概 12 点回去了。在这个点其实还是有点精力的，我就寻思着，我感觉自己写的总结很 low，没有亮点，给面试官留不下太多的印象。 04 回来之后我就思考怎么才能让面试官觉得我做的东西有价值呢？想了半天没想出来，但是突然想到一个点，我当时不知道这个点该不该讲，但是我很想讲，那就是我现在所做业务的大图。我们整个组都在做一个叫 xx 的项目(应该说是一个很大，很复杂的业务，是很多的项目)，每个人都负责其中的一块，我刚开始来的时候就对这个项目很好奇，因为我完全不能理解 xx 这个项目是一个什么样的项目，是用来干啥的。 甚至在我已经做了两个月的项目之后，我也仅仅只对我自己做的这块了解，对其他的人做的东西不知道有什么关联，但是我还是知道跟我肯定是有关联的，所以其实一直处于一种比较难受的地步，因为我不知道这个项目到底有多大的价值。 直到我在第三个月做了另外一部分的需求之后，我才慢慢的了解了这个 xx 项目到底是个什么样子的，我们的目标是什么，我们要做成什么样子，我们现在已经有了哪些能力。 那几天每天上下班的路上我就在思考这些东西，真的是每天想，后面终于想清楚了每个人做的东西之间的关联，感觉很舒服。 我觉得这个东西对于我来说价值很大，虽然他是纯业务的，或者说根本都不是我一个人做的，但是这真的是我的收获，所以我觉得站在更高的视角去介绍我们组现在做的 xx 业务，我就画了整个业务架构图，包含了我们组每个人所做的业务以及他们之间的关联。 然后就去介绍整个 xx 业务的背景，能解决什么问题，能为用户带来什么价值，能给公司带来什么利益(是不是觉得似曾相识)，最后再去介绍我做的东西在整个大图的意义的时候就很容易了。 在答辩的时候我差不多一半的时间都在讲这个，最后也给面试官留下了深刻的影响，说我提供的视角让他学到了新东西，他之前从来没有这么想过。 05 最后面试官给到我当面的评价也说到了我是一个善于思考的同学，喜欢去专研业务，还有其他的好的坏的评价，已经记不得了。 但是最后老板给我的试用期总评里直接说道我是一个**业务型选手，**这是我没想到的。但是我从他的评语中还得出，我在技术上的研究不够，如果后面我不深入业务的话，技术也没研究，那就真的很平了。 我后面多次思考了一下，我到底应该去做一个业务型选手还是技术型选手呢？我目前的答案是我应该去做业务型选手，因为我的理想是去创业的，感觉业务型选手更适合创业，如果以后想去做 CTO 啥的，还是选技术型选手比较好。 06 想一想你们自己是想做业务型选手还是技术型选手呢？欢迎在评论区说出你们的答案，最好能带上理由。