优百信息

目标产品

这是最重要的维度。产品本身的特征将影响技术选型时的很(hěn)多(duō)因素。

短生命周期产品和長(cháng)生命周期产品

短生命周期的产品通常要求快速起步：门槛低、书写自由、不强制遵循任何最佳实践。当它的使命结束时，代码会被直接抛弃。所以，对于这类产品，“快糙猛”的技术是较好的选择，当然，能(néng)做到“快精猛”更佳。

而長(cháng)生命周期的产品则会强烈要求可(kě)维护性，因為(wèi)它们在很(hěn)長(cháng)时间内都是不可(kě)报废的。甚至对于一些生命線(xiàn)产品，连重写都会要求在重写期间線(xiàn)上系统平稳过渡，一点点迁移到新(xīn)技术。

这种要求对团队的工程化能(néng)力是个极端的考验。如果没有(yǒu)相应的工程能(néng)力，其代价甚至会高于用(yòng)新(xīn)技术重新(xīn)写一个功能(néng)相同的系统。

探索型的产品和守成型的产品

探索型产品往往也是短周期产品，但是同时也有(yǒu)自己的特点。它要求快速，但往往同时会要求高质量。探索型的产品如果证明了可(kě)行性，那么过渡到長(cháng)生命周期的可(kě)能(néng)性很(hěn)大。

这就要求它最好是一个微内核系统，提前留出一些扩展的空间。当然，设计微内核系统对架构师的能(néng)力具有(yǒu)相当的考验，如果没有(yǒu)一个优秀的架构师，建议还是不要刻意做任何预留，优先保障系统的简单性。

除此之外，探索型产品的技术栈必须支持可(kě)靠的、自动化的重构。因為(wèi)探索型产品的迭代速度很(hěn)快，如果完全靠人工去添加功能(néng)并手动重构，那么一旦出现 BUG，将给此产品的用(yòng)户體(tǐ)验带来严重的负面影响。

所以，除非由于人才储备等原因而被迫做出折中，否则探索型产品的技术栈一定要快速而严谨。

当然，“大力出奇迹”定律也是成立的。也就是说，如果你有(yǒu)决心也有(yǒu)力量在将来对这个探索型产品进行彻底的重写，那么采用(yòng)快糙猛的技术快速把它搭建起来，也未尝不可(kě)。如果你的业務(wù)确实能(néng)如预期般爆发，那么只要把重点放在系统延展性等方面即可(kě)；但是如果不能(néng)如预期般爆发，可(kě)能(néng)就会导致维护成本在中期开始飙升，在竞争中处于劣势。这是一种“不成功便成仁”的策略。据我所知某独角兽企业就是在业務(wù)起来之后通过巨额投入来偿还技术债的。但这对于 CTO 的技术直觉是一项极大的考验，不要轻易效仿。

而对守成型产品的选型则会侧重于与现有(yǒu)技术栈的相似程度和无缝整合能(néng)力。如果整合时需要借助很(hěn)多(duō)技巧，那么可(kě)能(néng)你就是在给自己挖坑。

在引入新(xīn)技术的过程中，要尽可(kě)能(néng)符合现有(yǒu)的开发流程、基础设施和开发习惯。当然，如果现有(yǒu)的这些已经严重过时，那么应该找新(xīn)老技术的专家，共同帮你设计一个路線(xiàn)图，让你可(kě)以平稳地引入新(xīn)技术，这份投资绝对值得。如果老技术已经有(yǒu)新(xīn)版本，则应该优先考虑升级它。不要幻想换个技术栈就能(néng)解决一切问题，事实上，它带来的问题往往会更多(duō)。

边缘产品和生命線(xiàn)产品

在人员的學(xué)习能(néng)力和意愿允许的前提下，边缘产品是最佳的试验场，适合探索各种候选技术，试验各种激进方案，积累经验教训。其影响范围可(kě)控，即使失控也不会带来太大的损失。当然，即使探索，也应该有(yǒu)计划地探索，不要每个边缘产品都采用(yòng)不同的技术方案，那样会给人才供应带来巨大的挑战。

而生命線(xiàn)产品则应该稳妥优先，采用(yòng)保守方案。所以应该优先采用(yòng)团队内部积累了一定经验或具有(yǒu)稳定的强力外援的技术。

所有(yǒu)的生命線(xiàn)产品几乎必然是長(cháng)周期产品，所以其可(kě)维护性同样是重中之重。

产品维度总结

在目标产品维度上，低价值产品优先考虑门槛低的技术，但是高价值产品应该尽早进行投资性技术积累，优先考虑天花(huā)板高的技术，这样才不至于在若干年之后被迫重写。如果工程化能(néng)力不足，这种重写往往会成為(wèi)灾难。

目标用(yòng)户

用(yòng)户的特点对于技术选型具有(yǒu)显著的影响，甚至可(kě)能(néng)会导致产品不可(kě)用(yòng)。

浏览器版本

在前端领域，浏览器版本是永遠(yuǎn)的痛，但这是需要权衡的。高版本浏览器甚至是单一的低版本浏览器会显著节省开发成本，但是可(kě)能(néng)会损失一些用(yòng)户。该怎么解决呢(ne)？当然不能(néng)拍脑袋决定。

如果你们已经有(yǒu)同领域的線(xiàn)上系统，那么应该统计这些線(xiàn)上系统的访问情况，得出一个最准确的、针对目标客户群的统计，然后分(fēn)析一下不同版本的浏览器有(yǒu)多(duō)大价值，有(yǒu)没有(yǒu)可(kě)能(néng)通过非技术手段让用(yòng)户使用(yòng)你们的目标浏览器。即使没有(yǒu)線(xiàn)上系统，也可(kě)以随机对目标用(yòng)户群发一些调查问卷，确定他(tā)们的实际使用(yòng)情况，以及安装新(xīn)版浏览器的可(kě)能(néng)性。

下下之策是查一下百度公布的全网浏览器数据，然后说“我们要支持某某浏览器，它还有(yǒu) 10% 市场占有(yǒu)率呢(ne)！”，这是懒。

用(yòng)户带宽

同样是前端领域，文(wén)件的下载體(tǐ)积可(kě)能(néng)会被一些人当做亮点进行宣传，但是你要清楚，现在已经是 4G 时代了，更不用(yòng)说很(hěn)多(duō)企业内部应用(yòng)都是千兆带宽。就算能(néng)比候选技术小(xiǎo) 100k，在 4G 带宽下（假设现实带宽是 2MB/s）也就是 100 毫秒(miǎo)，有(yǒu)谁能(néng)感觉到这部分(fēn)差异？ 这就是一个明显的“误导读者”的例子。

可(kě)访问性

在产品的用(yòng)户群體(tǐ)中，不但有(yǒu)健康人，还有(yǒu)色盲以及盲人等残疾人。特别是对于面向消费者的产品，尽可(kě)能(néng)的考虑这些人的需求不但能(néng)體(tǐ)现出产品的“人文(wén)关怀”，而且也在一定程度上扩大客户群。比如苹果和微软等大公司都把可(kě)访问性放在了核心位置。如果你决定要实现可(kě)访问性，那么就应该把它作為(wèi)一项需求，纳入到选型时要考虑的因素中。

之所以要把它纳入到技术选型过程中，是因為(wèi)添加可(kě)访问性支持的代价比较高，而很(hěn)多(duō)第三方库并没有(yǒu)提供这方面的支持。所以应该提早考虑。

國(guó)际化

与可(kě)访问性相似，國(guó)际化也是一个后期添加代价比较高，但很(hěn)多(duō)候选技术却没有(yǒu)提供支持的特性。

如果你的产品在预期生命周期的相当一段时间内需要供多(duō)语言用(yòng)户使用(yòng)，那么，在初期选型时，就要把候选技术的國(guó)际化能(néng)力和质量纳入你的主要考量。

访问频度

用(yòng)户的访问频度对前后端的技术选型都有(yǒu)很(hěn)大影响。

比如说一个一年只用(yòng)一次的功能(néng)，考虑其性能(néng)很(hěn)可(kě)能(néng)是没有(yǒu)必要的，在一小(xiǎo)时内跑完和在一分(fēn)钟内跑完往往没有(yǒu)显著的价值差异。但是这两种技术方案却可(kě)能(néng)有(yǒu)着硬盘占用(yòng)、编程复杂性、运维复杂性等方面的成本差异。你需要考虑：那种能(néng)在一分(fēn)钟内跑完的技术是否能(néng)给你带来足够的价值。

对于前端来说，频繁访问的、面向消费者的应用(yòng)通常会要求更高的流畅度，那么在技术选型时，就要选择流畅度更高的技术。但是这个流畅度一定要设计一个仿真的场景，亲自验证一下，甚至做一些灰度发布在现实场景下进行验证，而不要只看其官网宣称的流畅度。比如阿里的闲鱼团队就对 Flutter 技术进行了長(cháng)时间的灰度验证，最终替换成了完全使用(yòng) Flutter 的版本，堪称对新(xīn)技术进行选型的模范。

用(yòng)户维度总结

要特别小(xiǎo)心，不要根据错误的、片面的信息作出决策。很(hěn)多(duō)第三方的技术选型指南背后都有(yǒu)着它们自己的场景，但大多(duō)数都不会给你写清楚，有(yǒu)的甚至复杂到想给你写清楚都做不到。甚至有(yǒu)些选型指南还有(yǒu)着强烈的主观立场，為(wèi)了证明自己的预设立场甚至不惜造假。所以，你要先清点出你们的产品最应该重视的那些指标，然后拿(ná)这些指标对候选技术进行可(kě)行性测试，甚至為(wèi)此专门开启一些 SPIKE 项目，而不要迷信第三方选型指南。

目标团队

目标团队的因素确实很(hěn)重要，但并不像你认為(wèi)的那么重要。除非你的人才供应真的有(yǒu)问题（难道不应该先反思一下是不是钱给少了？），否则应该优先考虑提升团队能(néng)力，而不是削足适履。

技术背景

目标团队的技术背景对新(xīn)技术的选型确实很(hěn)重要，但是没必要去精确匹配。

比如 Java 团队要做前端，选择 GWT 看似很(hěn)好，但 GWT 也有(yǒu)自己的问题，几乎完全无法利用(yòng)前端生态。他(tā)们更好的选择可(kě)能(néng)是 Angular：从语言上，TypeScript 跟 Java 有(yǒu)诸多(duō)相似之处；从架构模式上，对 MVC 的理(lǐ)解稍微往前推一步就是 Angular 的 MVVM 模式；从特性上，依赖注入不要太熟悉；从生态上，你可(kě)以自由决定是否使用(yòng)前端生态，取長(cháng)补短。

同样，前端团队如果打算自己写 BFF，也不一定非要在 Node 生态下打转。你完全可(kě)以使用(yòng) Java 世界的 Reactor 或者 WebFlux 进行响应式编程。这样可(kě)以和后端的其它 Java 體(tǐ)系更好地进行集成，并减少运维的复杂度。

团队规模

团队规模可(kě)能(néng)是团队维度中对技术选型影响最大的因素。

四位开发人员以下的小(xiǎo)规模团队，如果大家都很(hěn)专业，那么其沟通成本就很(hěn)低，在技术选型上可(kě)以更倾向于选择灵活的技术，因為(wèi)较高的人员能(néng)力和较低的沟通成本，可(kě)以让灵活的框架更好地发挥其作用(yòng)，最终更加高效、高质量的推出产品。这种场景通常出现在由牛人组成的创业团队中。

如果开发人员经验不足或者做事不够专业，就需要更强的约束，特别是对于职场新(xīn)鲜人，在早期养成好的开发习惯是非常重要的。而开发习惯中最重要的一点就是：约束 —— 知道不该做什么。这时候，偏向自由的技术可(kě)能(néng)会一时爽，但最终会构筑一个玻璃天花(huā)板，导致迟迟无法突破到下一个层次。

如果团队规模过大，那么首要的选择是用(yòng) DDD 等宏观技术把问题域细分(fēn)，使其可(kě)以被小(xiǎo)规模团队承接。如果暂时还做不到，就要考虑建设完善的基础设施和交付纪律，来為(wèi)团队协作提供自动化保障。如果这些都做不到，就应该选择强约束性的具體(tǐ)技术，让大家避免犯错，或者尽早发现错误。在争取到时间之后，再逐渐深入化解根本性原因。

组织架构

康威定律深刻地影响着很(hěn)多(duō)方面，技术选型也不例外。特别是做宏观技术选型时，必须考虑它在最终技术架构中的位置，以及与团队沟通结构的匹配程度。即使是一项很(hěn)先进的技术，假如它与體(tǐ)系中的其它技术栈不匹配，也可(kě)能(néng)导致翻車(chē)。

当选择多(duō)个第三方库的时候更要加倍小(xiǎo)心，因為(wèi)它们开发时互相不知道彼此的存在，特别是对于一些较新(xīn)的技术，可(kě)能(néng)都没人把它们搭配使用(yòng)过。

除了开发架构之外，还要考虑更广泛的运维架构。假如你们引入了 DevOps，可(kě)能(néng)这个问题会得到一定程度的缓解。假如没有(yǒu)，那就要充分(fēn)考虑上下游环节的人员能(néng)力和配套设施是否完备。比如如果运维部门缺乏 NodeJS 运维技能(néng)，就不要盲目引入基于 NodeJS 的后端，一定要拿(ná)到他(tā)们“我能(néng)”的承诺之后再开始。

除非你是个前后端 + DevOps 全栈，否则就需要尽早对组织架构方面的因素进行验证并排除风险。也就是说，在一个可(kě)控的演习环境中，用(yòng)一个小(xiǎo)型案例，完整地走一遍开发、上線(xiàn)、发新(xīn)版的流程。在这个过程中，一些显著的风险将会暴露出来，要评估其影响，来决定如何选型。

人员流动性

人员流动带来的损失比大多(duō)数人所认為(wèi)的要大得多(duō)。人员流动会带走知识和文(wén)化。企业要避免损失，就要把这些知识和文(wén)化尽可(kě)能(néng)记录在代码中。

当然，这并不意味着应该要求大量写注释，而应该使用(yòng)那些能(néng)留存知识的技术，比如类型系统和规范化命名。类型系统和规范化命名可(kě)以半强制性地要求开发人员把原本只存在于自己脑子里的知识记录到代码中。如果更有(yǒu)追求一点，可(kě)以再尝试普及单元测试。这样，当他(tā)离开的时候，即使没有(yǒu)文(wén)档，这些知识也仍然能(néng)留存下来。从效果上说，代码往往比文(wén)档和注释更好。

而文(wén)化的留存则更加困难，事实上，代码中的奇葩注释往往留存的是负面文(wén)化。应该在代码中留存的文(wén)化，是严谨、专业的工作态度。虽然自由也是文(wén)化的一部分(fēn)，甚至在管理(lǐ)领域是非常值得向往的文(wén)化，但在工程领域，它往往是一种负面文(wén)化，因為(wèi)软件开发领域并没有(yǒu)公认的法律甚至道德。你可(kě)以想象一下管理(lǐ)领域中没有(yǒu)约束的自由会导致怎样的后果。

所以，要想应对人员流动的风险，除非你有(yǒu)信心留存知识与文(wén)化，否则就应该在技术选型时，倾向于选择更加严谨的、隐式信息更少的技术。

团队维度总结

鞋子好不好，只有(yǒu)脚知道。错误的选型，也只能(néng)由团队自身来承受。阿波罗神庙上镌刻着一句警世名言——了解你自己。所以，请先客观认识自己的团队，然后再据此进行选型，千万不要懒于思考，盲从潮流。

技术本身

对技术本身的考量，主要是代入其它维度之后，看其匹配程度。

技术本身在选型中可(kě)能(néng)反而是最不重要的一个维度。这些年的历史早已证明：优秀的技术未必能(néng)流行起来；很(hěn)多(duō)技术的流行，也并非是由于其优秀。

明确的定位

一项优秀的技术，应该有(yǒu)其明确的定位和发展路線(xiàn)。这些定位能(néng)清楚地表明自己要做什么、不做什么。而其发展路線(xiàn)应该至少有(yǒu)一年以上的提前规划，而且在定位上要能(néng)与其前辈做出有(yǒu)效區(qū)隔，而不是亦步亦趋，没有(yǒu)自己的特長(cháng)。

代码质量

虽然流行的未必优秀，优秀的也未必流行，但技术选型不是赶时髦。所以，在条件允许的情况下，还是应该尽可(kě)能(néng)选择优秀的技术。代码质量高的技术，将来技术本身由于维护成本飙升而被放弃的可(kě)能(néng)性也较小(xiǎo)。

衡量代码质量的标准有(yǒu)很(hěn)多(duō)，其中最常用(yòng)、也比较有(yǒu)效的是单元测试的覆盖率。而那些从一开始就具有(yǒu)比较完备的单元测试的代码库，往往优于后补测试的代码库。因為(wèi)这证明的是开发组的工程化能(néng)力和意识，而这些是该技术長(cháng)期可(kě)维护性的根本保障。当然，除非该技术特别复杂或应用(yòng)场景的容错性特别小(xiǎo)，否则也不必苛求超过 90% 的覆盖率。

维护团队

维护团队的规模和能(néng)力，对于一项技术在長(cháng)跑中的表现非常重要。在历史上如流星般划过的技术数不胜数，但最终能(néng)長(cháng)期留下来的却不多(duō)。维护一项技术的成本遠(yuǎn)高于创建它，所以如果没有(yǒu)一个健康、可(kě)持续的商(shāng)业模式，一个像 Linus 那样的志(zhì)愿者，以及一个愿意出钱的超级大金主，那么它在未来的竞争中落败只是迟早的事。除非这项技术的需求集足够小(xiǎo)而稳定，否则这些因素缺一不可(kě)。

社區(qū)

社區(qū)的质量，决定着这项技术長(cháng)遠(yuǎn)的未来，一些草(cǎo)根型技术的隐患就在于此。如果社區(qū)人员的素质过低，喜欢无原则的站队，而不能(néng)理(lǐ)性的对该技术提出尖锐的意见甚至批评，那么这个社區(qū)迟早会衰落。这类社區(qū)有(yǒu)一个显著地特征就是喜欢宣扬它“包治百病”，也就是说它适合一切场景，而不会先问你一些问题再决定是否要推荐给你。另一个特征就是喜欢通过刻意选取某些标准来做出片面的对比，这种行為(wèi)在學(xué)术界属于學(xué)术造假行為(wèi)，但在我们工业界却被习以為(wèi)常，这不能(néng)不说是我们的悲哀。

好的社區(qū)应该是一个君子社區(qū)。他(tā)们会自觉遵守共同的、理(lǐ)性的行為(wèi)规范。会把精力放在对技术本身做贡献，而不是通过诡辩、群殴等手段来攻击竞争技术。社區(qū)的主要领导者会对社區(qū)的不良行為(wèi)提出批评、做出约束，甚至為(wèi)社區(qū)成员的不良行為(wèi)道歉，而不是放任不管。

技术维度总结

不要把技术看得太重。对所有(yǒu)的主观性宣传文(wén)章，留一些心眼，多(duō)问一句——那缺点呢(ne)？将来决定你们是否会掉在坑里的，就是它的缺点。

对于那些会如实告诉你缺点的宣传文(wén)章，请高看一眼，因為(wèi)作者是真的希望对你们团队的未来负责。

对于功利社區(qū)，请務(wù)必小(xiǎo)心；对于君子社區(qū)，请自觉维护。

反模式

有(yǒu)一些技术选型策略可(kě)能(néng)会导致灾难性的失败，这些选型中存在一些共同的反模式，比如：

舆论驱动选型

人云亦云，盲目听信外人或者某些布道师的主观性言论，这就是舆论驱动选型。它往往会带来灾难。

做任何决策时，如果要借助参考资料，请记住：最重要的不是它告诉了你什么，而是它对你隐瞒了什么，这些隐瞒的信息最终会置你于险境。

特别是当该资料的作者对某项技术具有(yǒu)显著的倾向性时，请深入想想，他(tā)向你推荐的每一项优点是否真的“对你”有(yǒu)价值，以及它背后的代价是什么。比如，推崇“自由”的技术往往不够“严谨”，如果你的产品需要严谨，那么请把“自由”看做减分(fēn)项而不是加分(fēn)项。比如，推崇“體(tǐ)积小(xiǎo)”的技术在现在动辄几T硬盘、几M带宽的环境下，到底对你来说有(yǒu)多(duō)大价值？它是不是因為(wèi)没有(yǒu)其它的优点了才把这种细枝末节亮出来吸引你？

即使是调查报告之类的客观参考资料，也需要了解其背景。比如一份只发给程序员的调查报告，可(kě)能(néng)会发现 Chrome 的使用(yòng)率超过了 99%，但显然它对你的面向普通用(yòng)户的产品毫无价值，只会给你带来风险。同时，要注意很(hěn)多(duō)调查报告的设计是有(yǒu)主观倾向性的，甚至题目的排列顺序都会给最终结果带来 10% 以上的偏差。所以，一定要仔细分(fēn)析其中立性、客观性以及调查对象在你的目标场景下的代表性。

单一指标驱动选型

根据任何一个单一指标进行选型都会给你带来灾难，更何况很(hěn)多(duō)指标并不适合作為(wèi)选型的依据。

有(yǒu)些指标很(hěn)容易操纵，比如 GitHub 仓库上的 Star 就是很(hěn)容易操纵的，在淘宝网上还有(yǒu)专门購(gòu)买 GitHub Star 的服務(wù)，而 GitHub 的年度报告中也已经不再把 Star 作為(wèi)主要指标使用(yòng)。即使是那些不容易造假的指标，比如 commit 数量，其实也不适合作為(wèi)主要指标使用(yòng)，它可(kě)能(néng)意味着作者具有(yǒu)良好的工程习惯和足够勤奋，但也可(kě)能(néng)意味着代码库质量堪忧，因此不断推出补丁。

当然，有(yǒu)一些客观指标还是比较适合作為(wèi)主要指标来使用(yòng)的，但也不要盲目相信数字。比如单元测试中覆盖率较高的项目，确实通常质量比较好，但是我也见过一些只有(yǒu)调用(yòng)却没有(yǒu)断言的测试，那些测试的覆盖率也会很(hěn)高，但却是假的。所以，如果要评估其质量，最好还是亲自打开看一看。

即使你选出了一些主要指标，并且确信它们没有(yǒu)造假，也仍然不能(néng)简单地把它们加起来或加权平均来得出一个数字进行比较。你要综合评估这些指标对你的目标产品、目标用(yòng)户、目标团队的价值。如果技术选型只是个数字游戏，那还要你干嘛？

话语权驱动选型

这几乎是最糟的选型，但却屡见不鲜。技术栈的更迭往往会带来话语权的变化，而这将给公司带来灾难。

对于高级技术决策者，需要有(yǒu)战略定力，应该以一种规范的、用(yòng)事实说话的方式来控制技术选型的副作用(yòng)。我曾见过一帮程序员“偷袭珍珠港”导致架构师被迫辞职的惨剧，我当时的意见是：这是 CTO 的锅。团队由于选择技术栈而产生了话语权之争，说明制度设计和文(wén)化建设出了大问题，这只能(néng)由 CTO 背锅。

所以，如果你是个技术决策者，那么应该尽早站出来，发挥你的职权和非职权影响力，抑制这些负面文(wén)化，而不是任由其发展，最终破坏公司的总體(tǐ)技术路線(xiàn)，甚至技术氛围。

粉丝驱动选型

对于生命線(xiàn)产品，最糟糕的选型莫过于粉丝驱动选型了，这次可(kě)没有(yǒu)“几乎”。对于技术人员来讲，最重要的特质是客观冷静，这样才能(néng)配得上“专业”二字。而拜大神，当作玩笑尚可(kě)，如果让它影响到你的决策，那么你就应该趁早隐退了，免得将来被迫引咎辞职。

虽然也曾被人称作“大神”，但我一般会提出反对，至少不作正面回应。我已工作二十多(duō)年，太清楚业界百态了。实际上，很(hěn)少有(yǒu)人真的配得上大神的称号，举世可(kě)能(néng)只有(yǒu) Anders Hejlsberg、Bob 大叔、Martin Fowler、Jeff Dean 等少数几位。不过我相信如果你当面叫他(tā)们大神，他(tā)们也会反感的。

就算是对于这些举世公认的大神，也不应该成為(wèi)你技术选型的依据，顶多(duō)是相信他(tā)们会珍惜名誉、不会粗制滥造而已，因為(wèi)即使是精品也仍然有(yǒu)着明确的适用(yòng)范围，超出这个范围它也可(kě)能(néng)会成為(wèi)毒药。

当然，对于边缘产品，进行粉丝驱动选型也未尝不可(kě)，甚至可(kě)能(néng)更好。只是得记住，要做就请做好，别给你的偶像丢脸，更不要做好之后就觉得公司一定要把它应用(yòng)于生命線(xiàn)产品中。

决策树

如果我在这篇文(wén)章的最后部分(fēn)给你一棵决策树，你会不会很(hěn)高兴？

很(hěn)抱歉，写这一章的目的，就是為(wèi)了告诉你：我不会给你任何决策树。请根据我提供的思维框架，自行设计适合你们自己的决策树，及时更新(xīn)它，并且不要盲目相信量化的评估结果。