影响我技术选择的二三原则

在通过让技术解决问题并且赢利的公司里，技术团队对于公司的影响是很小的，说不上什么话。（最好也别乱说话，尤其是搞不清楚状况乱说话）

技术选择并不会影响公司赢利。在当前技术方案不灵的时候 才会影响项目验收 才会影响公司赢利。比如 用个 wordpress 就帮忙把公司的事给办理了（技术方案通过验收了），公司还特别领情。

那么是不是不要进行技术选择了呢？不是的。技术选择本身是为了应对技术问题，尤其是当你预感到当前进行的项目在有一天会爆炸的时候。当然 有一些人从来不会有这种感觉，因为他们从来不做 testing ，因为他们从来不想明天。

技术选择的坏处：太 opinionated. 在公司里，一个人的本事 仅仅体现在出事情时 他人不能解决时 你能不能解决。在技术世界的技术版图里，一个人的本事 不在于他用什么先进的库，而在于他的个人成果是否喜人。 —— 你用什么先进的库，那是造库的人牛逼，不是你的牛逼，切记。在公司里，你把公司弄得离不开你了、一旦离开你了公司就转不了了或要高风险运转了，是你的牛逼。在技术版图里，你把自己弄得是一个项目离开你就转不了了，是你的牛逼。别人慢 耽误事，你快 及时解决问题，也是你的本事：即使这没有技术创先 技术创新，也是你的本事，因为你在苛刻条件之下解决问题并成功的人 是你。
要给真正(看到问题)解决问题的人尊重。别太不要脸了。
处理特别棘手的问题时 才显得这个人特别重要。这就是为什么你看着一个人看着像扫地僧，结果公司里的人们都特别尊敬他的原因。你看看他过去的故事，看看他过去多少次拯救了谁、于危难之中。别去对这些人做一些不要脸的事情。你可能遇不到这些人，但很可能有一天你会遇到。

技术选择的坏处：大厂的技术标准和小厂的技术标准是不一样的。而这你是去了哪个厂的就按哪个厂的来为好，入乡随俗，但俗不沾身。一个更倾向于稳健，因为它没有船小好掉头的资本；一个是在没人管的情况下 就爱引入新东西 引入不确定性，大不了以后是推翻重写。大厂的人和小厂的人也是不一样的，不一样的标准之下的人是不一样的，也就无法看出一个人在若没有大厂小厂制约的情况下的真实想法是如何的。在某个交点之下，大厂人容易和小厂人起争论，小厂也不惮于派出人来应战 也容易和大厂人起争论，除了这个交点本身争议性的火药桶问题(容易招来隔着台湾海峡对骂的人, 一届一届的毕业生都在这上面互相对骂过又和解、扛山头扛红旗似的，让俗气沾身)，也有一个人对自己的自身认识不足的问题：若他们有自己更深刻的原则，就不会在这话题的聊法上浪费时间；若他们在这话题上浪费时间，又怎能相信他们有更深刻的原则？(仿佛仅是一颗棋子，背后却没人在下棋，就像儿戏：一个甘做人家棋子样子的人 谁在下棋都不知道)。

没有原则是真的不太好：纵使一个人可以面对其它因素而妥协原则，一个人也应该有原则 有过一套，即使是妥协了，也能在不妥协时候 说出一套来。有 或者有过、定义过、确认过，这样就很不同。如果一个人没有原则 那么他根本没有妥协原则的机会 你无法妥协一个你不存在的东西；一旦妥协原则，他至少知道自己妥协了什么吧，可以找机会再拾起来。

没有原则是真的不太好：会因为小事而乱了方寸（真的是别人随便说说而已 谁却当真了 继而为小事乱吃夸、也为小事乱方寸），继而无法很好定义问题（无法定义问题所在的层面），盖因增加了无用的束缚。他不是弃牌的人，他变成了那张牌。他也变成了那张牌。

技术选择的好处：筛人。如果两个人有一样的技术选择原则，那么他们很可能会遇上。这样两个人就会在同一个团队里，意气相投。这样你秉持一个技术选择原则就有助于你会遇到有相同技术选择原则的人，这样工作配合起来会顺利很多。
—— 一个纯粹的解题人，仅仅由几个原则就可以堆起来（不需要考虑商业，也不需要考虑具体会面对的问题，仅仅考虑解决技术问题的方法论/通行方法的通行原则，the very basic，并相信由这些原则领导则一定能解出来，并借此做好应对未知问题的准备）。

影响我技术选择的二三事，我对应会总结为二三原则。

第一件事：关于 OO 范式里，当有千百个对象需要实例化的时候，需要考虑依赖注入这回事。
说实话，如果一个软件没考虑 DI 那么它在我眼中就算不上软件，因为这样的软件它无法驾驭复杂度。典型的就是 python 和数据科学家什么的那些玩意，如果你想遇见又一个会写代码的打杂员(在什么高大上的实验室里 -- 记住他去那里是因为他的科研研究背景才去的 不是因为他会写 python 才去的，更不会因为他会写一个无法驾驭复杂度的简易软件才去的 -- 这种软件 我一天能写一百个)，你可以放弃这个原则。
第一个原则：多看有依赖注入相关的东西和周边资料 1

第二件事：对于 maintenance 这回事的关注，当你接手了一个新项目，你就会感叹之前的人怎么没有把 maintenance 重视起来。
说实话，你是希望你接手的一个项目都写好各种充分的 testing 的，甚至把本软件用到的 design pattern 和本软件具体的软件设计图都交接给你了，以至于他们在当初设计软件的时候就像是为了容易交接，就像是就想设计出一个容易 maintenance 的软件（一个容易测试的软件就是一个容易交接的软件）。作为一个接手他人软件的人，你当然希望这样。可如果作为一个让他人接手你的软件的人，如果你就是那个甩下一堆代码就跳槽了的，你可以放弃这个原则。如果你就是那个设计出一个不容易测试的软件的人（然后甩下一堆代码就跳槽了，或者）最开始 你是这个公司里唯一懂得这些代码的人 然后 连你也不懂你写的这些代码了：你无法交接给你自己，你可以放弃这个原则。
第二原则：多考虑 test 的事 感受从 maintenance 的不易 带来的恐惧，继而 为了避免这份恐惧，从设计阶段就考虑去设计出一个容易测试的软件（比如在软件设计时候就考虑 OO 对象初始化问题和 FP 里的状态管理）。不给自己挖坑 不给后人挖坑。

第三件事：对于服务器端开发 服务器端并发这个问题，你很可能知道它的原理，也知道这是一个值得关注的问题。但实际上会出这个问题的公司是很少的，因为大流量网站很少，全球你可能十个手指就数得过来，若手指不够则加上脚趾。对 90% 的程序员而言，average Joe 他们是遇不到这个问题的。对别人而言，讨论并解决高性能高流量应对是正常的；对你而言，因为你遇不到这个问题，如果你用了他们的方案而却没有他们所要应对的问题，那么你就是 over engineering ，这是预算不会批准的。你不应该考虑别人的问题，你应该考虑自己的问题；你不应该考虑别人接手的问题，你应该考虑自己接手的问题；你不应该考虑别人的客户所面对的问题，你应该考虑自己的客户所面对的问题；你不应该考虑别人面对的问题，你应该考虑处理自己面对的问题。别人的问题，作为 90% 的一员的你可能一辈子都遇不到：痛点驱动解决问题，更好的编程只是解决问题的一种方式、加钱买服务器也是解决问题的一种方式，引入 lib 或采取某个解决方案只是编程办法，而你或你的客户可能没有这些痛点（既然不用更好的编程、也不用加钱买服务器），因为你没有这些痛点：别人的痛点 别人解决，你不需要解决，别人对别人的问题的解决方案 你看了也会忘记。
第三原则：不要多看服务器端因为流量而带来的奇怪问题，比如 服务器端并发问题，多看看 average Joe 会遇到什么问题，每个人每天会遇到什么问题。一个人是先学会走再学会跑，可一个网站很可能几十年了就那么点儿流量，没什么遇到服务器端并发问题的机会。这就像技术版图、全世界的版图，你踏不上那个版图，你就没有那个任务，你就不会(领取)那个任务(的必要)。你也不会有他们解决他们那个任务的开心，不要试图抢夺他人的快乐！在 over engineering 里 over 的含义是当你试图抢夺不属于你的快乐，最终你会哭泣。over engineering 本身是不快乐的事情。

第四件事：人们对于高性能的吹捧，往往是 它仅仅是一个 lib 或一个 middleware ，人们之所以把它吹得像小题大做，因为它解决了他们的什么特殊痛点 而导致了他们狂吹而圈外人看它看他们都是小题大做。如果是 高性能 lib ，那么若它是在一个非 DI 软件里，谁人拿着它瞎搞一通：这不值得羡慕 因为最基本的 maintenace 都没做好、没考量。如果是 高性能 middleware ，那么若它是在一个 DI 软件里，谁人去用它 也是把它放在 DI 背景之下去用，它也仅仅是一个 middleware 而已。总之，他们这种吹捧，为什么会让人觉得小题大做呢？不是你不懂他们的喜乐，而是他们太容易喜乐：是因为他们在很大程度上都是没见过世面的表现。这些人往往会夸耀自己多少 LOC 的驾驶，多么高性能的 hit ，但是却对 DI 一无所知、对 maintenance 的重视度为零，用一个 lib 解决了他们要解决的问题之后就会拍拍屁股走人，给接手软件的人留下一团乱麻。
第四原则：不要多看关于性能吹捧的东西和周边资料。尤其当眼界狭窄的人小题大做的时候。一个调库员用上/消费一个高性能 lib 是不会增加一个人的对 DI 和 maintenance 的重视的。面对一般 lib 的吹捧者保持冷静。原谅他们：高性能中间件用户/调库员、实验室里的会写代码的打杂员、解决 1% 的程序员会遇到的问题的程序员、wordpress 程序员。

迎接他们：给出完整的解决方案的人（完整解决方案，可以把 lib 和 middleware fit 进去的那种解决方案）

综上，以上就是影响我技术选择的四个原则：

• 多看有依赖注入相关的东西和周边资料
• 多考虑 test 的事 感受从 maintenance 不易 而来的恐惧
• 不要多看服务器端并发的问题，服务器端高性能
• 不要多看关于性能吹捧的东西和周边资料

可以称之为学院风的技术选择吧

一个个体，不受市场影响，不受潮流影响，可是他也活在市场和潮流中。但市场和潮流本身也是活在时间之中的，亚热带季风气候带走谁都不一定。

和一般的潮流性技术选择不太一样，我当前这个技术选择原则的考量是以10年为单位的，希望可以遇到意气相投的人能越来越多。一个人是否有可看出一个技术有没有幺蛾子的慧眼已经成为筛选眼力伙伴的重要标准，尤其当你无法让你的足迹遍布技术版图意义上的全球的时候。当你觉得要让自己足迹遍布全球方才敢说对技术版图有把握，那时候会到来 那一天会到来，可那已经太晚了。

此技术选择原则是会变的，但大概率是随着我对于人生的理解而变，小概率是随着我对于技术解决问题的理解、尤其是对于新问题和解决问题的层次的理解而变(虽然有一些问题是我可能永远也遇不到、即使遇到 也不会把它当作技术问题来解决，毕竟若我解决不了则可以外包给别人嘛)，零概率是随着时代潮流而变，只因潮流里的水 恐怕是别人的口水组成的。

-