60 lines
6.4 KiB
Plaintext
60 lines
6.4 KiB
Plaintext
---
|
||
title: 总得给自己留下点什么
|
||
slug: leave-some-by-myself
|
||
date: 2017-12-13 18:41:55
|
||
updated: 2021-11-23 18:15:12
|
||
tags:
|
||
- 思考
|
||
- 代码
|
||
category: 杂思
|
||
cover: /images/2019/05/2019050902332168.jpg
|
||
summary: 网易云音乐一直是一个值得吐槽的地方，比如，它常常会认为你懂五国语言，动不动给你日推一些稀奇古怪的歌曲。因为我会日语，所以日推的大部分都是日文歌，还可以接受网易云音乐一直是一个值得吐槽的地方，比如，它常常会认为你懂五国语言，动不动给你日推一些稀奇古怪的歌曲。因为我会日语，所以日推的大部分都是日文歌，还可以接受。但最近网易云音乐开始变本加厉，给我日推俄文歌，这实在是不能接受。
|
||
---
|
||
|
||
|
||
|
||
网易云音乐一直是一个值得吐槽的地方，比如，它常常会认为你懂五国语言，动不动给你日推一些稀奇古怪的歌曲。因为我会日语，所以日推的大部分都是日文歌，还可以接受。但最近网易云音乐开始变本加厉，给我日推俄文歌，这实在是不能接受。
|
||
|
||
一般我熬夜时，都喜欢开着网易云音乐听歌，不是说我多喜欢音乐，而是为了防困。精力专注的时候，歌曲就像是一种微噪音，你根本感知不到。有时也会听到一些不错的歌曲，下载收藏。
|
||
|
||
<NeteasePlayer id={812400} />
|
||
|
||
周一时听到一首名为 **[「PLANET」](http://music.163.com/#/song?id=812400)** 的歌曲，前奏就十分抓耳，当时就立刻点击下载，可惜这歌竟然要付费。生在天朝，仗着自己从事 IT 相关的工作，最大的好处便是能免费搞到一些数字出版物。但我在谷歌、百度上查找甚久，竟找不到此曲的 320 Kbps 版本，不禁有些沮丧。
|
||
|
||
在网易的「チーズ牛丼」(沙拉牛肉)上找到一篇关于「PLANET」的创作组合**「ラムジ」**的[介绍](http://music.163.com/#/topic?id=17639053)。 22 岁的山下佑树在过生日的时候，只因想要唱点什么东西来到东京，和报复不得施展的井上慎二郎桑如童话般在雨中相遇，并开始了长达 8 年的演艺事业。
|
||
|
||
>当時、井上慎二郎に初めて出会ったとき、雨に濡れて震える子羊のような容姿だった為、当時の山下のイメージから羊を連想し、アニメの子羊キャラクターからラムジと命名。
|
||
>
|
||
>当时山下佑树遇到井上慎二郎，看到他被雨淋湿的姿态，联想到了动画《ラムヂーちゃん》里“子羊”这一角色，因决定采用ラムジ这一名字为组合名。
|
||
|
||
一切都是那么巧合、随性，连乐队名都是以上面这么哭笑不得的[缘由][wikipedia-link]命名。然而，不是每个梦想都能瓜熟蒂落，ラムジ在 12 年便[宣布 13 年解散][oricon]。我翻遍他们为数不多的专辑、单曲，喜欢上的，也只有那首「PLANET」。
|
||
|
||
可我还是不死心，我能感受到歌曲里那种热情和呼唤，那种渴望展露头角被大众所关注认识的心情。因为现在的我和当时的主唱山下佑树年龄相近，我更能感受到山下先生的期盼与绝望，两种矛盾心情交织下的悲伤心境。我翻遍脸书、推特、所有我所知道的社交网络，却没有找到任何关于山下佑树的信息。他随着ラムジ的解散，消失在大众眼里。即使是推特上，也很少有人提起。
|
||
|
||
可是我还记得，就和他们的歌还在被人听被人唱一样，我还记得这么一个乐队，如流星般存在过。
|
||
|
||
---
|
||
|
||
前些天翻推特，看到有人说，大部分代码的存活时间只有 5 年不到。回想自己目前接手过的很多老项目，的确如此，在 OneAPM 上班的时候，兄弟部门的系统，一年重写了 2 次。自己维护的系统，也因个人的审美变化，在一年内留下了 3 种不同风格的代码。
|
||
|
||
如果说乐队的解散，还能留下当时传唱的歌曲，那么程序的重写，可能就是彻彻底底的消失。那么，作为程序员，我们还能留下什么呢？
|
||
|
||
**我想，只有编程思想吧。**
|
||
|
||
记得 4 个月前带小弟写的 [SQL Generator](https://github.com/byWeaponLin/sql-generator)。核心的思想便是对当时业务 DSL 的抽象封装，还有函数式的变换思想。即使后面这部分代码废弃，我想它的定义还是能好好传递给每个维护过它的人吧。这个设计思路再精进，便是在[Language Implementation Patterns](https://pragprog.com/book/tpdsl/language-implementation-patterns) 里面提到的解析与生成的两种形态，虽然SQL Generator 独立于底层的解析器开发，但是最后二者的抽象结构，是惊人的一致的。
|
||
|
||
同样的说法可以应用于程序设计的很多地方，比如说单元测试。我以前一直不知道什么是测试，怎么写测试。后面有意识地学习模仿后发现，单测无非也就是三大步。构造测试对象、测试数据，调用方法，断言。
|
||
|
||
测试对象有些可能是 Mock 的接口，但一定不能是 Mock Static 的对象，存在的话说明你的代码抽象存在问题。测试数据，也叫样本，关键在于能命中边界条件。而断言，无非就是各种 `true` `false` `equals` 的判断，hamcrest 之类得无非是简化了判断过程而已，但切记慎用 Mock 里面的 `verify` 做断言。
|
||
|
||
所以说，测试代码，再怎么变，逃离不了上面的编程方法，即使是别的编程语言，亦是如此。我很费解的是，在苏宁，看到我的同事写测试的时候，写的是一个 `main` 方法，用 `System.out.print` 输出结果人肉判断。因为上线有单测覆盖率要求，竟写出了针对实体 `Getter` `Setter` 方法的测试代码。这种测试代码，有存在的意义么？
|
||
|
||
有时我觉得，编程就是一种体力活，想好了怎么设计，后面的编码加测试，纯粹是一种[肝][moegirl]的状态。有时候又觉得很多代码纯粹是套路（模板代码），只是因为某些需要不得不这么写。正如标题所言，总得给自己留下点什么。我希望给自己留下的，是那些有意思的设计思路，而不是那些**「垃圾代码」**。
|
||
|
||
|
||
|
||
[wikipedia-link]: https://ja.wikipedia.org/wiki/%E3%83%A9%E3%83%A0%E3%82%B8_(%E6%AD%8C%E6%89%8B)
|
||
[oricon]: https://www.oricon.co.jp/news/2020043/full/
|
||
[moegirl]: https://zh.moegirl.org/%E7%88%86%E8%82%9D
|
||
|