2021年の目標
テーマはプログラミング速度が速い分野を増やすです。
2020年は、特定のプロジェクトでのプログラミング速度の向上に成功しました。
とはいえ、今年のオープンソース活動振り返り @ 2020 | Web Scratch と見比べると大分遅く感じます。 また、2020の成功例は、プロジェクトや技術ドメインへの習熟度、プロジェクトへの関わり方に依存しているように思います。 そこで、他のプロジェクトでのプログラミング速度向上を目標とします。
サブ目標
- publicなサイドプロジェクトのプログラムを完成させる
- 「Ruby並行並列大全」のractor/fiber scheduler対応版を書く
- TOEICの最高得点を更新する（英語の学習習慣を組み立てる）
2020年の取り組み
うまくいったこと
2020年のテーマは「使う道具を増やす以外の方法で技術力を上げる」でした。
2019年のふりかえりと2020の目標 - @ledsun blogによると、当初は次のような作戦を立てていました。
理解しているレイヤーを増やすようなアプローチが必要かな？と思っています。 「作って理解するOS」を読み始めました。まだ途中です。 2020年には、実装するところまでやりきりたいです。 2017年に「RubyでつくるRuby 」を読んだときは、考え方を応用してできることがぐっと増えたので、同じような効果を期待しています。
半年ほどたって、「論理的思考の放棄」をパクる - @ledsun blogで
1日1000行のリファクタリングなら、できる気がする。
と感じて、作戦変更しました。 プログラミングそのものの速度を追求するアプローチです。
ふたたび Gitのdiffを振り返る - @ledsun blogによれば、どうやら成功したようです。 概ね次のような策を実施しました
- 論理的思考を放棄する
- コミット粒度を小さくする
- テスト実施頻度を増やす（テストを実施したらタグを打つ）
- テスト手順書をソースリポジトリにマージする
それぞれ次のような効果がありました。
- 机上で考える時間が減りコーディング作業の時間が増える。実施前に予想していたほどは、手戻りは起きませんでした。
- 手戻りが起きた際にコミット単位で戻せる。修正で予想外の影響が出たとき原因をコミット単位で特定できます。追加の修正が必要であればamendすればいいです。不要であればrevertすればいいです。
- 不具合が早くたくさんみつかるようになった。手動テストでは、テスト時に実施者の行動のブレから新しいバグが見つかることがあります。この現象はテスト実施時間を減らして、テスト実施頻度を上げた方が、よく起こるようです。また、一回のテスト実施で少ないテスト項目に集中できるので、テスト手順の修正が丁寧になります。テスト実施時間が短くなるとデバッグで、テスト実施時間を食い潰したと時に減る時間が短くなります。
- ソースコードとテスト手順を別リポジトリで管理していると、ワークスペースの切り替えコストが馬鹿になりません。これはテスト実施頻度が増えると影響が大きくなります。
アプローチを変更してから、明らかな効果が出るまで半年掛かりました。 半年程度頑張るとプログラミング速度は目に見えて上げられるようです。
あんまりうまく行かなかったこと
必要があって、2週間ほどSVGの勉強をしました。 2週間の間は、結構な時間をとって集中しましたが、成果は芳しくありませんでした。
SVGの概念の把握や周辺ツールの理解は進みました。 しかし、SVGで絵が描けません。 またSVGを操作したり、生成したりするプログラミングを書いたとして、それが仕事になるイメージができません。 要するに、新しい技術ドメインに取り組む場合、サイドプロジェクトで取り組んでも全然時間が足りないことがわかりました。
冷静に考えれば、2週間で仕事になるレベルで技術が身につかないのは、当たり前です。 ですが、知らない技術ドメインは解像度が低すぎて、不当に難易度を高くまたは低く見積もってしまいます。 メインプロジェクトとして取り組む時間が確保できれば、もう少し解像度が高くなるのでしょう。 ただ、その時点ではメインプロジェクトになる予定が延期されました。
メインプロジェクトで、技術力を上げられるアプローチを採用しました。
