作者: Phodal Huang 2020年11月22日 15:01

最近在和我一同事一起，使用 Rust 来创造一门新的编程语言：Charj。而在实践方面，我们都是这方面的新手，所以不得不经历一番尝试。而作为其中的一部分，必然就是由一个 hello, world 开始的。由于在这个过程上，遇到一些小坑，所以我决定写篇文章记录一下。

作者: Phodal Huang 2020年11月16日 20:31

开发者即服务，是（Developer-as-a-Service）的，亦可称为 “按需即用的开发者”。即当开发者使用某一工具、库，遇到任何相关的问题，可以随时找开发者为我们提供服务。哪怕是使用者使用了我们的 A 框架，但是遇到 B 框架有问题，他/她们也会觉得 A 框架有问题 ——因为 A 框架的开发者们是一种服务，一种开箱即用的服务。

作者: Phodal Huang 2020年11月9日 19:58

在我短短几年的 TW 生涯里，我经历了多次的角色转换，经历了不同的地域，感觉了不同的文化氛围。

作者: Phodal Huang in 杂谈 2020年11月2日 20:38

在我当前所在项目里，其中的某一个子系统是用 Groovy 中的 Gradle 插件。Groovy 作为一个运行在 JVM 上的脚本语言，天生具有胶水的特性。加之，它支持 DSL 与其程式的简洁语法。嗯，如果不考虑性能问题，这真的是不一个不错的语言。

作者: Phodal Huang 2020年10月26日 20:25

一年前，在公司大佬的指点之下，我开始写系统级重构工具 [Coca](https://github.com/phodal/coca) (https://github.com/phodal/coca) 。哦，不，不对，是刚开始学习 Golang，因为我的第一次提交是从一个 Go 的 `hello, world` 写起的。 ``` commit a685d69080a7abde684e1d0707cbf410092e3173 Author: Phodal HUANG Date: Tue Oct 22 23:01:19 2019 +0800 first commit commit c6b5a0c7f174c6a0ba233a1356aca5c370ba4315 Author: Phodal HUANG Date: Tue Oct 22 23:06:04 2019 +0800 learn: add hello world ``` 时过境迁，这个小工具已经不小了 —— 即使是这个项目的作者，我也要看我写的 README，才会想起来有这么一些功能。这一年来，根据我的一些工作上的需要，陆陆续续地也添加了一些颇为有意思的特性。这些小特性除了不限制编程语言，还可用于指导重构，还可以用于写 PPT 的时候讲述故事： - 高频修改文件查找 - 包结构分析（不限于 Java，大部分的语言是以目录划分包结构的） - Todo 分析（可结合历史） 当然了，如果你的系统是 Java 语言主导的话，那么 Coca 能提供更强有力的支撑，具体见：https://github.com/phodal/coca 。只是呢，不管我们使用的是什么工具，我们方法论都是类似的。也因此《系统重构与迁移指南》（https://migration.ink/) 成为了系统重构不可多选的材料，Google 『系统重构』 和 『重构工具』会有惊喜。 ## 系统的必然之路：系统重构 or 重写 没啥说的，部分的系统都是要被重构或者重写的。那么另外一部分呢？他们被淘汰了——要么是产品，要么是公司，笑~。 真相就是这么简单。如果系统不被指南，和进行频繁的代码级重构的话，那么系统被取代的速度就更快了。 ## 重构 vs 重写 关于系统级别的重构，我们先要讨论的第一个问题其实蛮简单的：我到底是要重构还是重写？选择哪个主要取决于：你要的是技术挑战，还是业务挑战？ 哦，不，不对，它取决于你要的是 KPI 是技术 KPI，还是非技术 KPI？ 说白了，就是价值决定了一切。 对于重构而言，我们所要面对的是技术挑战；对于重写而言，我们所面对的是业务挑战。 ### 重构的技术挑战 我们所面临的主要技术挑战是： 1. 是否能确保过程的安全性？如何设计测试防护网 2. 是否能想到更好的设计来取代现有的方案？ 3. 如何做一次有效的分析与评估？ 4. 如何渐进式的重构系统？如何保持小的、快速的提交 5. 怎样支持未来业务的可扩展？即，支撑业务可扩展性 6. 是否寻找最合适的重构技巧？比如通过 IDEA 的重构 7. 如何让重构技能被传承？即，多数团队成员都能快速上手 8. …… ### 重写的业务挑战 与重构不同的事，重写时的挑战主要是来自于梳理现有业务： 1. 如何体系化的整理现有的业务？ 2. 如何剔除已淘汰的业务？ 3. 如何确保主干业务的完整性？ 4. 是否能确保细小的业务功能不被遗失？ 5. 能否设计出更完善的业务知识管理体系？ ## 系统重构的未来 在 Coca 编写完成之后，我发布了《系统重构与迁移指南》一份短小、精悍的重构手册。从这个手册快速的自然增长率（GitHub star 指标，没有经过大量宣传），并且已经在 Google 的相关关键字下（如系统重构、重构策略等）排名第一，我发现了人们缺少一份这样的指南和工具。 所以，在未来一定会有更多的相关工具诞生，并配套有大量的实践指南。 ### 方法论支撑 在开始重构之前，我们需要**设计出可行的重构方案**，这也就是方法论的支撑。 对于重构的方法论来说，实现上我们已经可以在市面上找到大量的相关书籍，只需要结合起来看就可以了： - 《重构与模式》 - 《设计模式：可复用面向对象软件的基础》 - 《重构：改善既有代码的设计》 - 《领域驱动设计：软件核心复杂性应对之道》 - 《修改代码的艺术：构建易维护代码的 9 条最佳实践》 - 《代码整洁之道》 - 《架构整洁之道》 - 《数据库重构》 - 《遗留系统重构指南》 - 《前端架构：从入门到微前端》 ### 工具支撑 市面上，已经充斥着大量代码级重构的工具，如 JetBrians 系列的 IDE。但是，对于系统级重构来说，基本上很少有工具可以直接能支撑现有的系统，哪怕是 Coca 也是有限的支持。主要原因就是：大部分的内部系统都绑定了组织中的模式。特别是对于大型组织来说，它们往往配套开发了自己的底层架构和 API。 也因此，对于系统级别的重构来说，我们要优先考虑的是定制一个工具，又或者是基于开源工具进行扩展。 ### 操作指南支撑 同样的，我们也很难在市面上找到这样的指南，因为对于大部分的公司和团队来说，重写是更好的 KPI，而重构并不会带来如此丰富的价值。除此呢，对于有过重构经验的团队来说，他们也不一定会共享出自己的经验——受能力和保密协议影响。 于是乎，我开始不断丰富我的指南《系统重构与迁移指南》。 ## 其它 > 软件开发总成本 = 开发成本 + 维护成本；软件维护成本 = 理解成本 + 修改成本 + 测试成本 + 部署成本。—— Ken Beck

标签:
• coca
• legacy-system

作者: Phodal Huang in 架构 2020年10月19日 20:45

现有的项目里，一次功能变更可能带来了大量的缺陷。于是乎，我试着回溯项目的开发过程，寻找出导致问题的根因。现阶段，我只能想到时的只有实施技术战略性投资，也暂时也想不到更好的方法，以在开发初期解决问题。

作者: Phodal Huang 2020年10月12日 20:17

或许是出自于对编写编程语言的兴趣，又或许是对于创建 IDE/编辑器的兴趣，对于『IDE/编辑器是如何提供编程语言的支持』，我充满了兴趣。其中的一个主要原因是，这是每天我们打交道最多的工具，另外一个原因可能是，咦，我们怎么没有国产的 IDE（手动狗头）。

作者: Phodal Huang in 架构拾集 2020年10月11日 15:33

最近的几个月里，一直在编写代码识别引擎 Scie ，好不容易解决了各种奇怪的问题。随后，在尝试做了一次 benchmark 之后，发现我写了的这么一些 Rust 代码，运行起来的速度非常慢。同样是对一个代码文件的分析，Scie 差不多要 12S 完成，而同样的 Node.js Addons 则只需要 200ms。于是，我开始了我的性能优化之旅。

作者: Phodal Huang in Full Stack 2020年10月11日 10:02

最近一直在编写 Gradle 以及 Intellij IDEA 相关的东西。由于市面上最复杂的相关的开源软件就是 Android 相关的，即 Android Studio 和 Android Gradle Plugin，于是我也在不断学习相关地源码。所以，我写了很多相关的文章，在介绍相关的内容。文章中包含了大量的技术细节和实现，所以这些技术文章也就只能在我的博客上看到了。

作者: Phodal Huang 2020年10月11日 08:58

最近在为新的工具 Scie 设计一个模型，以用于描述一个具体的代码工程。而刚好最近也在学习 Gradle 相关的项目模型，便想写一篇文章记录一下相关的模型，以支撑起 Scie 的开发。