Posted by: Phodal Huang July 8, 2019, 1:01 p.m.

过去的几个月里，我和花仲马一直在讨论某件很重要的事情——大家都懂的。我也一直在思考：未来的几年内，我要成长为一个怎样的人。

be what ？

成为你想成为的人？ 这个问题真的很难。

工作了 5 年，我开始有重复使用经验的趋势。在流行的框架/技术上，能吸引我的东西越来越少。倒是可维护的架构变得更加有吸引力，架构的效果也是肉眼可见的有一定成效。

与此同时，越来越多的毕业生、年轻人，拥有了比你还强的技术实施经验——实现同样一个功能，同样只需要半天，虽质量上不一定如你，但是速度上达到了。优秀的年轻人和我们一样，尝试了各种 DD，诸如于：TDD（测试驱动开发）、BDD（行为驱动开发）、DDD（领域驱动开发）、UDD（用例驱动开发）等。这样的压力之下，有的人选择了管理，有的人选择了新的行业，还有的人要在技术的路上继续往下走。

过去，我自称是一个快速的追赶者，而现在我已经成为了被追赶者。靠现有的技术、能力，只能让我们在未来 5 年里，重复上一个 5 年里发生的事情。于是乎，我们还需要继续成长，重新调整一下方向。

定位

在过去的 5 年里，随着知识广度与深度的提升， 我已经从一个热度驱动开发的程序员，变成有机会触发热闹出现。最典型的几个代表有：前年写的 开源电子书《Serverless 架构应用开发指南》，和去年写的开源电子书《微前端那些事儿》。尽管仍然和国外存在短期的代差，但是我的新书《前端架构：从入门到微前端》已经证明了，在一些技术实践上，我们可以站在他们的前面了。这种落差也表明了，我们可以在更多的技术、架构理论上，尝试去领先国外。

所以，我制定了这么一个远景：未来 5 年，我希望我能再给整个行业带来一些变化，并且不限于国内，走向国际。

于是，我重新定位了自己：专注于开发出更好（易于维护、易规模化）的软件系统，并协助技术社区、组织进行创新，并提升相关的能力。

基于这种身份，我会有多重定位。

（PS：存在先后顺序）

创新者（Inventor）

1. 多个领域的技术专家，以在不同的领域里 Copy / Paste 相关的思想。如过去的微服务 -> 微前端，APP 的 MVP 架构到前端的 MVP 架构。
2. 全新领域的探索者。新的领域，可以带来新的可能性，有机会参与新的
3. 革新者（Innovator）。Innovation，拥有将创新的成果落地的能力
4. 创新者（Inventor）。Creativity 创造一些新的技术成果。路还有点长，但是可以尝试去做。

技术倡导者（Technology/Architectue Advocate）

1. 走向国际化
2. 让人起而行动的布道师
3. 探索更好的技术架构，对架构进行抽象
4. 在组织层面影响架构采用与实施

开发者教练（Developer Coach）

1. 帮助开发人员构建更好的软件系统
2. 快速指导他人的技术发展
3. 成为有效地发展他人的 Coach
4. 构建开发者团队

FLAG 就立到这里了。

小结 1

事实上，它有一条主线，设计出更好的软件架构（创新者、革新者），将新的软件架构应用到项目中（倡导者、布道者），让大部分开发人员使用新架构（赋能开发者、实施者）。而这也是大部分公司采用的模式，了解-布道-试用-采用。

其实吧，简单的一句话总结就是：我要成为一个更棒的技术 KOL——那样就会有更高的影响力，带来更高的收入。就像那个 Blabla 一样，有一天我要取代他，哈哈。而这一些的前提是，我要有更好的技术、落地能力和鼓舞人心的技巧。这一切都是因果循环。不过，当你看到你能影响到好多人，让他/她们去做正确的事情，就会觉得：买不起房的人生，还是有点意义的。

还有，这些 FLAG 并不重要，计划总是会变的。我没见过我有哪个计划是成功实施的，它们都没有变化来得快。但是在没有变化之前，先拥有一个长期的计划，不是一件坏的事情。当然，它可能也不是一件好事情。不过，计划对于我说，永远不是定死的。我去年说今年要做一些非技术性写作，到现在一篇也没有，我能说些什么呢呢呢呢呢——估计也是实现不了的。

计划：个人篇

国际化

国际化，在这个阶段指的是，在英语技术世界产生影响力。

过去，受限于我的英语能力——四级没过，并且没有时间练习。我可以轻松阅读技术内容，但是要写出来，又或者是讲出来并不容易。不管怎样，先迈出第一步，练习英语写作。

首先，开始编写一些英语技术文章。它可以是先写中文技术文章，再翻译成英文。又或者是，先写出英文版本的文章，再翻译成中文。随后，尝试将英语技术文章整合成电子书。也许有一天，也就会产生对应的纸质书籍。

再慢慢进入英语世界的技术社区——当然了，现在也在 GitHub 上，只不过要扩展到更大的维度上去。

好了，刚去创建了：https://github.com/phodal/entry

重新学会编程

学会编程，指的是，用脑子编译一遍。

• 预先编译。作为一个前端程序员，我一直在使用浏览器编程，因为手速快。直接，修改-保存-等刷新，比直接阅读代码要快得多。也因此，我怀疑我仍然有其它一些不良的编程习惯。基于这样的目的，我得寻找一些方式来改善这些不良习惯。
• 业余 TDD -> 项目上的 TDD。不过，说真的我在写一些工具的时候，压根就不想写测试——时间有限，坑位还有很多未填。
• 关注于输入和输出。输入和输出的优先设计，本身是瀑布流的预先设计模式。边实现功能，边设计接口，存在一个明显的缺点：有可能存在多余的输入与输出。所以，这一点和现在流行的 DDD 一样，有待我们发掘和改进。
• 寻找更好的编程实践方式。

再说一下 TDD。每隔一段时间，我似乎就会重复使用 TDD，不用 TDD，继续使用 TDD，继续不用 TDD 的过程，哈哈。TDD 虽好，但是写测试要时间。过程中，出现的问题是，TDD 降低了我的开发效率——因为对于 UI 编程来说，TDD 带来了一系列的负作用。不过，至少在有些层面上，我们还是可以继续 TDD 的。TDD 的优点在于：演进式的设计系统逻辑。

既然找到了问题，那么要解决起来就会轻松一点了。

造轮子

未来，我还得进一步完善个人开发工具集。

• 新技术实践。使用新技术、新架构造轮子，几乎成了我对于自己项目的最佳实践。
• 常用工具自制。
• ……

输入法。事实上，随着国家管控的加严，我一直想着去除输入法周边的工具。我一直对国内的输入法有强烈的不信任感，诸如于拼音输入法会在你输入的时候，随时推测判断你的下一个字，相当的危险。但是我用的又是五笔，要找到合适的工具没有那么容易。与此同时，这种工具要求的又是原生（诸如于 C 和 C++）开发能力，我得考虑使用诸如 Rust 这类的语言。不过，这种坑还是以后再慢慢考虑吧。

与时俱进

当你关注于架构，关注于设计，就会忽视于一些新的技术 / 框架。学习使用框架有可能是浪费时间的，但是框架之中，可能出现一些值得学习的设计思想。所以，这个问题相当的让人纠结。

• 学会工作上的框架。工作上用的工具，只要好好看看文档，不使用旧的实现方式，那么就可以用得很好，诸如于 RX.js、Rambda 等。
• 偶尔试用新工具、框架。作为一个 “老人”，我们的时间和精力都是有限的。
• ……

类似的事情还有很多，尝试，以使自己保持学习。

时间管理

一年年，继续往下走的时候，我们便不得不解决一个问题，如何快速地学习？—— 快速复用现有的知识，并将其应用到新的领域里？ 就这一点来说，我倒是没有那么大压力，我还有一套学习的方法论，与此同时也还没有孩子。所以，在未来的几年里，如何利用时间来学习？会变成一个新的挑战。 我们的时间会因为各种琐事，不断被分割成碎片。

虽然，我们很忙，但是我们仍然有足够的时间看手机。

我们玩手机只是因为需要休息一会儿。而休息的最好方式是转移注意力，而不是消磨时间。所以，如何快速地恢复精力？也是一个新的问题。 。就目前而言，我掌握的最好的休息方式是，闭上眼睛休息几分钟。其次，是转移注意力到别处，比如画画。不过，我在第二点一直做得不好，所以我会有那么多的时间在玩手机上。

所以，哪怕是我在过去再怎么高产，可在在业余时间的管理上，我还是有一定的提升空间。

1. 碎片时间，可以用来收集资料。
2. 代码疲倦时间 / 蕃茄休息时间，可以寻找不那么眼疲劳的事件——比如运动。
3. 提升午休时间（限于有午休的地方）效率，以腾出部分时间。

但是最难的地方，还在于眼睛的疲劳，它意味着你用不了电子设备。那么，是否存在更好的用眼方式？比如眯眼的时间稍微长一些。

计划：社区篇

未来的一段时间里，除了继续输出高质量的文章，还应该能让人起而行动（就好像软文一样，笑），除此还需要提供一定的可操作性。

带来创新

创新，可以是：进入到一个全新的领域。也可以是在一个领域里，实现另外一个领域的同样内容。它也是我在上面所强调的，了解多个领域，以将自己的知识扩展到多个领域。我们便可以将其它领域的知识，复制到一个不同的领域里。在某些领域的最佳实践，不可照搬到另外一个领域，但是也有一定的参考价值。

按照这样的定义，以及我最近的一些兴趣，会有一些的方向：

• 无代码编程
• 前端架构守护
• 自制高级的 DSL

它们都依赖于更深的技术深度，也算是一个不错的尝试。

引发变革

写一篇文章，引发大家的注意很难；写两篇文章， 大家可能会看一眼这是什么东西；写三篇文章，大家可能就会稍微关注一下……。直到有一天，越来越多的大咖都在说这个技术，那么大家才会真正关注。

为了引起更多的关注，需要产出更大的影响力，常见的形式有：

• 技术文章
• 社区分享
• 大会讲师

传播自己探索新的架构、技术，引发起人们的关注，继而让开发者开始采用它们。

设计生成

Design System 是过去我们考虑的一个重要因素，而 DesignOps 在最近一年里，成为一种新的风潮。而作为一个工程师，我们是实施 Design System 和 DesignOps 的关键因素，它也让我们开始思考两者间结合的可能性。

设计是影响前端的关键一环，跨出前端领域来考虑设计，将会成为一个非常有意思的因素。不过，我目前还没有一个好的计划，只是有一个远景，和一个想法。

计划：组织与业务篇

好的技术，不一定带来好的效益。所以，技术好的人，不一定工资就高。带来的价值，决定了一个人的收入，也决定了一个人的影响力，笑 ~

效能与赋能

实施难度高的技术，往往难以带来价值，反而会带来巨大的负作用。所以，一方面我们在技术、架构上要探索新的、复杂架构，一方面要能通过它们带来价值。

如我们在之前《前端困境：组织篇》所说，从组织的角度来考虑，它们要做的事情有：

• 批量化提升开发人员水平
• 构建技术生态（基础设施，技术氛围）
• 平衡速度与质量
• ……

问题太多了，有待于我进一步研究。

不过，从某种层面上来说，其中的一些问题可以由架构来解决，诸如于 Clean Architecture。对应的，还依赖于我们寻找简易实施、长久的架构，并寻找可靠的持续改善方案。与此同时，还需要保证架构实施的准确性——架构守护。

业务抽象

业务抽象，指的是将业务转化为代码的能力，并寻找有效的方式持久化。

因此这个目标，可以分为两部分。第一部分，寻找合适的方式来抽象化前端业务，为此需要：

• 设计前端的 DDD。设计行之有效的方案，来存储业务知识，诸如于将模型与业务逻辑，沉淀在业务组件、通用组件中。
• 架构无关。让前端的代码摆脱框架的依赖，使之能更加独立于框架存在。
• ……。有一些，我可能还没想到。

总之，就是要提升业务转化效率。至少业务的持久化，这是一个悬而未解的问题，仍有待进一步地研究。

模式策略

TBD

可能的模式有：

• 架构快速落地。
• 考虑更大规模的组织。
• 架构远景。

赚钱篇

TBC