Open hello2dj opened 5 years ago
要务实，不能盲目，要考虑成本以及效率而不是一拍脑袋
产品的完成度，是否能胜任项目的需求，设计的还原度,是否能在成本和效率之间有个良好的平衡，或者两者都能达到最好
是否有其他人能使用，不能说只有你一个人会用能用就可以了，对其他人协作是否友好
是否有技术前景，不能说今天用了，明天就没人用了，是否有良好的社区环境，否则对后续的产品支撑就会很弱，无论是招人(较好的技术前景会让后续人员补充良好),还是一些底层bug(良好的社区环境会让库或者框架有bugfix,让依赖项目保持健康)
造轮子的痛点是啥，一定要了解痛点是啥，一定说3遍 用轮子的瓶颈在哪，就像上面的图，你拿了个轮子给人用，这里就有两个问题
...
一定是以项目本身为出发点，一定是要能满足当前项目的需求，如性能，兼容性，迭代快，稳定性等等，抛开项目谈选择就是耍流氓（我加的）
依赖库不是说加就加了，增加了一个就意味着增加不可预知的问题，依赖的崩溃往往是难以发现以及debug的，切记不要轻易hack以及使用私有的api即未公开的api(因为这类api极易发生改变) #### 避重趋轻，避繁趋简，避虚就实（奥卡姆原理：如无必要，勿增实体） 库的轻重不是以size来决定的，而应当是api简洁型的，易于使用，易于调试，易于发现以及解决问题的，典型的就是tj的作品, 简洁易于稳定，使用 轻量的库要好过于大而重的库，若没有必须的理由就不要新增库 #### 可替代性 库的使用易于被替换，而不是说一定会被绑死的除非你确定你非此库不用，但应当尽量做到库的易替代性，随时可以更换，而且库的引入有时会引入一些无形的机制，因此应当尽量避免这种无形的机制的引入，这种说法又叫抽象渗透，就是说你依赖的库的某些抽象，渗透入了你的代码中，导致你也必须使用，举栗子就是async/await就是一种抽象渗透的典型，污染范围扩展到了你的整个代码中，一旦底层库使用了async/await你的代码就必须使用，否则就会出现代码执行顺序混乱的情况。这是时候就要用到solid中的一个原则了，叫做依赖反转，
从上述图中可以看出，高层不在依赖底层，他们都依赖接口（好比图IOC容器，关于IOC又可以讲很多了），总之这样做了以后可以让我们的代码与底层库解耦，就是说我们在引入库的时候是可以适当的包裹一下，使得库代码的污染区降到最低
没有银弹，没有什么是可以搞定一切的，一切都是以适合现在，能够拥抱未来为主，主框架的文档是否良好，api是否简洁易用，稳定性如何
不拥抱未来是没有前途的，一定要对未来有所见解，但也要看清楚当前业务，因果论理有一句话是： 了解现在才能洞察未来（原话是不是这么说的忘了，大致这意思吧），一是利于招人，二是有利于技术成长，三是不落后的架构才有可能支持未来的业务（这三条是我加的。。。）
当你在多个选择中间无法抉择时，此时，可以使用此原则，经验价值高，去猜测可能遇到的坑，然后抉择
框架总是会过时的但他的理念在延续，好比react会过时，但他的虚拟DOM的理念一定会存在，软件工程一个最重要的问题就是管理代码复杂度，而架构就是为此而生的，意味着如果你的架构有优势，那么你的代码的复杂度就会得到良好的控制，这个框架的模式是否有优势，框架带来的规约是否有效，按照框架的模式来走是否能将代码规约到一定的复杂度，这里的规约还有一个问题就是大家是否都按照这种规约来走，或者说在框架的基础上做出适合自己的规约方式。
再此有一句话（原作者说的就是李安在选演员时，还没确定时就已经然演员在脑中表演了，然后看效果）那么对于代码来说选择库或者框架时，没确定前就应当在脑中运行了，看看会是什么样，能是什么样，有什么好的效果，有什么弊端等等（这个得修炼）
前面有讲
一个库只做一件事
使用的人多
前面对轻量型有介绍
库本身的依赖足够少
通俗的说就是一个系统的混乱程度，而有一个定理就是一个系统的熵一定是越来越大（没有外部能量干扰），若是想要维持熵值就一定得有外部能量注入 看下面两个图
架构良好的系统
反之没有人维护
这是在说什么？架构的重要性以及优势，自行领悟吧！改天继续说说这个（这也是原作者讲的一个哦，只不过是捎带了一下）
克军篇，如何再项目中选择库和框架， 一切的一切都是要以项目本省为出发点，不要耍流氓 克军slides
基本前提： 成本和效
要务实，不能盲目，要考虑成本以及效率而不是一拍脑袋
实现目标的成本和效率
产品的完成度，是否能胜任项目的需求，设计的还原度,是否能在成本和效率之间有个良好的平衡，或者两者都能达到最好
团对协作的成本和效率
是否有其他人能使用，不能说只有你一个人会用能用就可以了，对其他人协作是否友好
后续迭代的成本和效率
是否有技术前景，不能说今天用了，明天就没人用了，是否有良好的社区环境，否则对后续的产品支撑就会很弱，无论是招人(较好的技术前景会让后续人员补充良好),还是一些底层bug(良好的社区环境会让库或者框架有bugfix,让依赖项目保持健康)
另一条路自己造轮子
造轮子的痛点是啥，一定要了解痛点是啥，一定说3遍 用轮子的瓶颈在哪，就像上面的图，你拿了个轮子给人用，这里就有两个问题
经常谈到的(但是作者不想谈的)
模式
体量
性能
前景
普及率
...
选择的原则
妥适性原则
一定是以项目本身为出发点，一定是要能满足当前项目的需求，如性能，兼容性，迭代快，稳定性等等，抛开项目谈选择就是耍流氓（我加的）
库的选择
缩小依赖范围和稳定方向依赖
依赖库不是说加就加了，增加了一个就意味着增加不可预知的问题，依赖的崩溃往往是难以发现以及debug的，切记不要轻易hack以及使用私有的api即未公开的api(因为这类api极易发生改变) #### 避重趋轻，避繁趋简，避虚就实（奥卡姆原理：如无必要，勿增实体） 库的轻重不是以size来决定的，而应当是api简洁型的，易于使用，易于调试，易于发现以及解决问题的，典型的就是tj的作品, 简洁易于稳定，使用 轻量的库要好过于大而重的库，若没有必须的理由就不要新增库 #### 可替代性 库的使用易于被替换，而不是说一定会被绑死的除非你确定你非此库不用，但应当尽量做到库的易替代性，随时可以更换，而且库的引入有时会引入一些无形的机制，因此应当尽量避免这种无形的机制的引入，这种说法又叫抽象渗透，就是说你依赖的库的某些抽象，渗透入了你的代码中，导致你也必须使用，举栗子就是async/await就是一种抽象渗透的典型，污染范围扩展到了你的整个代码中，一旦底层库使用了async/await你的代码就必须使用，否则就会出现代码执行顺序混乱的情况。这是时候就要用到solid中的一个原则了，叫做依赖反转，
从上述图中可以看出，高层不在依赖底层，他们都依赖接口（好比图IOC容器，关于IOC又可以讲很多了），总之这样做了以后可以让我们的代码与底层库解耦，就是说我们在引入库的时候是可以适当的包裹一下，使得库代码的污染区降到最低
主框架的选择
没有不二法则
没有银弹，没有什么是可以搞定一切的，一切都是以适合现在，能够拥抱未来为主，主框架的文档是否良好，api是否简洁易用，稳定性如何
拥抱未来
不拥抱未来是没有前途的，一定要对未来有所见解，但也要看清楚当前业务，因果论理有一句话是： 了解现在才能洞察未来（原话是不是这么说的忘了，大致这意思吧），一是利于招人，二是有利于技术成长，三是不落后的架构才有可能支持未来的业务（这三条是我加的。。。）
经验价值高
当你在多个选择中间无法抉择时，此时，可以使用此原则，经验价值高，去猜测可能遇到的坑，然后抉择
架构上的优势为重
框架总是会过时的但他的理念在延续，好比react会过时，但他的虚拟DOM的理念一定会存在，软件工程一个最重要的问题就是管理代码复杂度，而架构就是为此而生的，意味着如果你的架构有优势，那么你的代码的复杂度就会得到良好的控制，这个框架的模式是否有优势，框架带来的规约是否有效，按照框架的模式来走是否能将代码规约到一定的复杂度，这里的规约还有一个问题就是大家是否都按照这种规约来走，或者说在框架的基础上做出适合自己的规约方式。
选择的原则（新手版）
妥适性原则
前面有讲
库的选择，尽量同时满足一下条件
单一性
一个库只做一件事
普遍性
使用的人多
轻量型
前面对轻量型有介绍
依赖少
库本身的依赖足够少
主框架的选择： 做足调研和实践，多喝老司机交流
code review十分必要
最后讲个名词 熵
通俗的说就是一个系统的混乱程度，而有一个定理就是一个系统的熵一定是越来越大（没有外部能量干扰），若是想要维持熵值就一定得有外部能量注入 看下面两个图
架构良好的系统
反之没有人维护
这是在说什么？架构的重要性以及优势，自行领悟吧！改天继续说说这个（这也是原作者讲的一个哦，只不过是捎带了一下）