90 篇博文 含有标签「工程实践」

“接口和抽象类怎么选”几乎是每个 Java 学习阶段都会碰到的问题。
很多回答会从语法、继承、默认实现这些点切入，这些都没错。但 2017 年我在项目里慢慢形成的判断是：真正决定选择的，常常不是当前写起来哪个方便，而是未来变化会往哪个方向长。

Java 8 刚出来那阵，很多人讨论接口默认方法，讨论点常常是“它是不是打破了接口的纯粹性”。我后来在项目里真正用过几次后，反而觉得更实际的问题是：哪些重复代码适合放进去，哪些不适合。

以前我也干过那种事：线上着急同步代码，一句强制拉取就把本地改动全盖掉。问题是这种做法虽然快，但太依赖运气。只要本地还有没整理完的文件、临时调试记录或者还没想好是否提交的修改，一次粗暴覆盖就可能把自己坑到。

2016 年接手 Java 项目时，我遇到过一种很典型的混乱：同样是处理用户逻辑的类，有的叫 UserDao，有的叫 UserMapper，有的叫 UserServiceImpl，还有的直接叫 UserManager。项目还能跑，但只要需求稍微一变，大家就会先花时间猜“这个类到底管什么”。

很多人一说文章迁移，会先想到正文是不是完整、标题和日期有没有带过去。
这些当然重要，但 2016 年我在整理和迁移一批 Markdown 内容时，最让我头疼的反而不是纯文本，而是那些看起来像细节、丢了却很影响阅读体验的东西。

Grunt watch 刚接进项目时，体验真的很好。改一个文件，自动检查、自动编译、自动刷新，前端开发节奏会立刻顺起来。但 2013 年我在几个页面项目里把它用深之后，也很快遇到另一个问题：watch 一旦开始什么都监听、什么都触发，最后开发环境会变得越来越重。

工具链越丰富，越容易让人产生一种冲动：项目只要稍微多一点脚本和命令，就赶紧引入一层更复杂的构建工具。2013 年我在接触 npm scripts 这套能力时，也有过这种心态，总觉得直接用 scripts 显得有点朴素，好像不上点额外工具就不够“工程化”。

2013 年做前端页面时，很多交互都离不开 jQuery Ajax。搜索、保存、翻页、校验、局部刷新，看起来只是多写几个请求，可页面一旦复杂起来，真正先失控的往往不是接口本身，而是页面状态和回调关系。

GitHub Issues 一开始用起来很简单，谁发现问题谁就开一条，评论、补充截图、贴 commit，都很顺手。可只要项目稍微多一点需求，Issue 一多，列表就会迅速变成一锅粥。到了 2013 年我自己开始比较频繁地用它协作时，最明显的感受就是：Issue 系统如果没有最基础的标签约定，很快就会从“记录问题的地方”变成“堆问题的地方”。

刚开始接触 Git 时，很多人最自然的提交信息就是 update、fix bug、change 这种短句。我自己早期也这么写过，因为那时候觉得重点是“先提交上去”，信息只是顺手带一句。但真把代码历史翻回来看时，就会立刻意识到这种写法几乎没有帮到未来的自己。