Blog

Blog

PHODAL

未来 5 年:构建第二个工作 5 年的计划

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

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


或许您还需要下面的文章:

关于我

Github: @phodal     微博:@phodal     知乎:@phodal    

微信公众号(Phodal)

围观我的Github Idea墙, 也许,你会遇到心仪的项目

QQ技术交流群: 321689806

新书《前端架构:从入门到微前端》

《前端架构:从入门到微前端》是一本围绕前端架构的实施手册,从基础的架构规范,到如何设计前端架构,再到采用微前端架构拆分复杂的前端应用。本书通过系统地介绍前端架构世界的方方面面,来帮助前端工程师更好地进行系统设计。

前端架构包含以下五部分内容:

  • 设计:讲述了架构设计的模式,以及设计和制定前端工作流。
  • 基础:通过深入构建系统、单页面应用原理、前端知识体系等,来构建出完整的前端应用架构体系。
  • 实施:通过与代码结构的方式,介绍如何在企业级应用中实施组件化架构、设计系统和前后端分离架构。
  • 微前端:引入6种微前端的概念,以及如何划分、设计微前端应用,并展示了如何实现这6种微前端架构。
  • 演进:提出更新、迁移、重构、重写、重新架构等架构演进方式,来帮助开发人员更好地设计演进式架构。
comment

Feeds

RSS / Atom

最近文章

关于作者

Phodal Huang

Developer, Consultant, Writer, Designer

ThoughtWorks 高级咨询师

工程师 / 咨询师 / 作家 / 设计学徒

开源深度爱好者

出版有《前端架构:从入门到微前端》、《自己动手设计物联网》、《全栈应用开发:精益实践》

联系我: h@phodal.com

微信公众号: 与我沟通

标签