2020 作業日誌

本日のタスクは、HDMAPMDK-1199への対応でした。以前、この問題を忘れてしまっておりました。

結局、午後8時にようやく完了しました。

HDMAPMDK-892（経験軌跡の提供）をレビューしました。

MDKがまだ対応するアダプテーションを行っていないことが分かり、本日午後はそのアダプテーションを実施しました。

アダプテーションが完了し、大変疲れました。

引き続き、自分のArchの設定を進めており、マシン構築の手順を自動化の一部として記録しようと試みています。

本日は以下のタスクを予定しておりました。

1. HDMAPMDK-1199 RoadMark をサブクラス化し、より豊富な情報を提供する
2. HDMAPMDK-892 経験軌跡を提供する

余力があれば、バージョンリリースのドキュメント作成にも取り組みます。

結果として、892を完了しました。

少し調子が戻ってきて、Archをインストールしました。使い心地はMacよりも快適に感じるでしょうか？

瑀璋としばらく酒場戦棋を遊んでいました –

土曜日に北京に引っ越してきて、仕事を始めました。

再び北京で働くことになり、正直なところ少し戸惑っています。すべてが変わってしまいました。まず、自分の席がなくなりました（シュウユンがインターンを一人採用したため、仕事の都合上、そのインターンに席を譲ったのです）。これは、あらゆる喪失感の中で最も適応しづらいものでした。それはちょうど、高校2年生のときに1組に編入し、新しい席に座って誰も知らず、誰とも話したくなかったあの感覚に似ています。ここにいる人たちはみな、知っているようでいて、実は知らない人たちです。私はここに友人がほとんどいないように感じられますが、これは理性で判断すると錯覚だと分かっています。しかし、誰とも話したくなくて、隅っこにこっそりいたいという気持ちは本物で、実際に私はそのような隅（ウショウの隣）を見つけました。なぜ人と交流したくないのでしょうか？この理由はまだはっきりしません。もしかすると、正当な理由がないからでしょうか？なぜ北京に来たのか、どれくらい滞在するのかと聞かれると、私は「しばらく、一、二ヶ月くらいです」と曖昧に答えるだけです。あるいは、本質的に自分は内向的な人間で、面倒を起こしたくなく、他人の目に自分が愚かに映るのをとても気にしているからかもしれません。しかし、書き進めるうちに、後者の要素の方が強く、かつ不必要だと感じるようになりました。第一に、愚かに見えることは、本当に愚かであることよりはましです。たとえぎこちなくても、真剣に他人に教えを乞う方が良いのです。怖がらないで。若いうちは怖がらないで。どんな時でも怖がらないで。All is well.

仕事について少し述べます。この期間、納品を終えましたが、主にTLM（typed lane model）のリファクタリングでした。今回は目標を明確にし、自分を制御して、衝動的にリファクタリングしないようにしなければなりません。戦略的に、自分の進捗をコントロールしながら進めます。

また、デスクトップPCもセットアップしました。以前ずっとネットに接続できなかったのは、パスワードを変更したためでした。ある停電の後、ネットワークが完全に切断されてしまったのです。それで、もう一度マシンをセットアップする必要がありました。今回は優先順位を次のように定めました。

1. 生産性
2. かっこよさ
3. 見た目

今日は長い間、王垠さんのブログを読んでいました。デトックスを続けているようなものです。以前の私は狂信的な宗教信者のようで、物事の本質を見極めることができませんでした。何か特定のものが全ての問題を解決する究極の手段だと思い込んでしまうことがよくありました。しかし実際には、そのような「究極の手段」は非常に稀であり、ほとんどの場合は単なる宗教的熱狂に過ぎません。例えば、

• Vim vs Emacs
• OOP vs FP
• Go vs Rust

などなど…。かつてOOPに触れたばかりの頃は、OOPは無敵で、全ての問題を解決できると考えていました。しかし結局、汎用的なクラスを一つ書いただけで、そのクラスがなくても問題はなく、本当に役立つのはそのクラス内の個々の関数でした。その後（この2年間）、FPに触れるようになり、FPこそ全ての問題を解決する銀の弾丸だと思うようになりました。しかしScalaでしばらくプログラムを書いてみると、生産性が向上したとは感じられず、むしろ文法やイミュータビリティに悩まされて効率が低下してしまいました。

緊張感のある一日でした。HDMAPMDK-1347とHDMAPMDK-1352を完了し、大規模なリファクタリングも行いました。

貴重な教訓を得ました。納品間近に大きな変更を行うべきではないということです。なぜなら、十分なQAテストがない状況では、どれほど優れたリファクタリングでもリスクをもたらす可能性があるからです。また、設計のレビューを行う時間が十分にない場合（自分自身のことを言っています。というのも、書き進めているうちに設計が間違っていることに気づくことがあるからです。ただし、実装中に設計の問題に気づくのは別の問題です。つまり、着手が早すぎるということです）。

月曜日の補足：この緊張感あふれるリファクタリングの日、私はほぼ休む間もなく、考える余裕すらありませんでした。ただ慣れとフロー状態に頼って、非常に高い効率でコードを書いていました。実は、先に述べた「納品前に大規模なリファクタリングをすべきではない」という原則を考慮しなければ、私はこの状態を非常に楽しんでいました。しかし、すべてには目標と意味がなければなりません。自分だけが気持ちよくなってはいけません。そうでなければ、その気持ちよさは低級な楽しみになってしまいます。

今朝は以下の3つの作業を行います：

1. データのクリーニングと、最終0605データのアップロードを行います。
2. 幅の異常問題を確認します。これは、該当位置に車線が存在しないためです。
3. 差分点が誤った車線に割り当てられている問題を確認します。
4. 再確認を行います。

朝一番に、逸銘が昨夜発見した問題を解決するために行きました。具体的には、信号機が取得できないという問題です。

午後から来ました。镱铭をデプロイさせるために、いくつかのバグを修正し、逸铭の夜間のデプロイに間に合いました。

今朝、出社したらすぐに逸銘さんのところへ行き、問題を分析しました。午前中ずっと分析していました。その結果、以前から既知の問題（旧バージョンのコンパイラの差により発生した点の欠落）が原因で、別の問題が発生していました。道路を取得する際に、欠落した線分の近くにあたってしまい、lane offsetが負の値になったのです。

結局、深夜4時まで作業することになりました。非効率的で苦しい徹夜の後でした（現在の状態では、徹夜をするとほぼ確実に非効率に結びつくように感じます）。