松本行弘的程序世界-怎么理解解决方案
解决方案概念
上个季度有一个刷leetcode的计划，这个季度本来想延续，但是同时给我的建议是：刷题偏向于解决方法，现在增强的应该是出解决方案的能力。我很疑惑，解决一个现有问题不是算吗？我刷题能拓展我的思维，我觉得它是对我有好处的。现在的公司是做nlp的，我记得当时说的是：平台提供的是机器人平台，用户在这上面只要配置keyword或者流程，就可以解放客服的双手。他说这个不是，那到底什么才是解决方案呢？为龙湖提供的个性化回复属于解决方案。有痛点，有场景，结合现有的能力，出一个方案来解决这个痛点。
为什么会出现ruby
最近恰好在读松本行弘的程序世界，松本是ruby语言的作者。在ruby出现之前已经有java、c++这样的语言了，那为什么还要再创造一个新的语言呢？左耳朵说过我觉得很有道理的话：一门新技术的出现，无非是三个目的：降低技术门槛、提高开发效率、提升稳定性。我仔细想了想，没毛病。c++的门槛很高，java很重。说到这里，对于下面的代码
class Person {}
class Solution {
viod handle(Person person) {}
}
我拿着代码去问写过java的同事，问preson的传值是不是引用传值，他十分确定的说不管在哪个语言中，一定是引用传值。然后我又拿着代码去问了写c++的算法同学，他告诉我只要传值的不加&，再c++里面都是复制。这是多么令人迷惑的代码啊！
回到书上，当你准备写一门新的语言，已经有优秀的语言出现了，那么你创造一门新语言的初衷是什么呢？作者设计这个语言的目标是：简洁性、扩展性、稳定性。上一家公司用的是ror，有幸写过一些简单的ruby的代码，当时第一感觉是只有你想不到的，没有他做不到的。js很让人诟病的是，有一些package竟然只有一行代码。作为语言，js可能提供的太少。所以当时写ruby的代码的时候，特别幸福，常见的处理函数，它都有，常见的功能，社区也有gem去做，你只要在原来的基础上扩展一下即可。简洁性和扩展性都有感受到，但是一直没接触过稳定相关的。
简洁性和扩展性，我觉得很多是元编程的功劳，我在一个class中，仅仅增加几行代码即可。在我久远的记忆中，java对private的变量加getter和setter方法，我记得编辑器有快捷键能做这个事情，那如果加上元编程的话，是不是可以更简单一下：在定义变量的时候，直接指定上知否需要getter和setter即可。
在书中，能看出来作者一直为这三个目标努力，结合各种编程思想，考虑怎么才能出一个更好的方案。是选择静态还是动态语言？是要面向oop还是函数式？怎样同时享受便利？让我想来，真是难题啊。其实对于oop，我还是偏爱函数式编程，怎么说呢，它更倾向于解决问题的本质，但如果项目一大，oop的优势就凸显了，它有一个明确的概念：对象，可以帮助梳理思维，组织项目。
解决方案的实践和理解
恰好最近在落地微前端的概念，这个概念提出好久了，但是到现在还是没有一个完整的方案。最出名的single-spa，怎么说呢，感觉它只是微前端中的一环，它不单独成立，它仅仅是体系中的一部分。但是现在的开发者都在你努力基于它，在完善概念。在基于现有概念，去做拆分的工作，拆成完全解耦的，发现现有的满足不了（好沮丧），于是又去找了刚开始提出微前端方案的文章，由看了后端的微服务的解决方案，感觉有一丝丝不一样。如果前端要做一个gateway完全解耦，现在的根本满足不了（qiankun中不能多个应用和url绑定），这样的话，平级只能调整成嵌套，但是一旦gateway包含了其他功能，稳定性就保证不了了，啊，纠结。带着疑问去问了别人，说我拆的太细了==😒。一时间不知道如何消化冲击，目前只能是先基于现实条件，先做出来一个雏形吧。
所以解决方案是什么？发现痛点，结合当前的条件，出一个方案来解决这个事情。这是我目前的理解。