概要
2022 年 11 月の振り返りです。
以下を目標に掲げていました。
目次
勉強関連
勉強関連 概要
今月も、Kotlin と設計について勉強していました。 Kotlin は RealWorld 作成によってインプットし、週 1 回の技術記事投稿によってアウトプットしていました。 設計は、「ソフトウェアアーキテクチャの基礎」と「Google のソフトウェアエンジニアリング」を読むことによって、知見を深めていました。
勉強時間
勉強時間の結果です。 今月は、約 128時間でした。 10 月も同じぐらいの時間だったのでキープできて良かったです。 勉強時間のアベレージを保ちつつ、より効率的な方法を目指します。
| 項目 | 1 週目 | 2 週目 | 3 週目 | 4 週目 | 5 週目 |
|---|---|---|---|---|---|
| 平日朝の勉強時間 | 約 5.83 時間（14 ポモドーロ） | 約 14.6 時間（35 ポモドーロ） | 約 11.7 時間（28 ポモドーロ） | 約 9.58 時間（23 ポモドーロ） | 約 8.33 時間（20 ポモドーロ） |
| 平日夕方の勉強時間 | 0 時間 | 約 0.5 時間 | 0 時間 | 0 時間 | 約 0.83 時間 |
| 休日の勉強時間 | 約 15.4 時間（38 ポモドーロ） | 約 10.8 時間（22 ポモドーロ） | 約 7.5 時間（18 ポモドーロ） | 約 12.9 時間（31 ポモドーロ） | 0 時間 |
| RealWorld ペアプロ | 4 時間 | 約 5 時間 | 約 4 時間 | 2 時間 | 2 時間 |
| 「ソフトウェアアーキテクチャの基礎」/「Google のソフトウェアエンジニアリング」勉強会 | 2 時間 | 2 時間 | 2 時間 | 2 時間 | 2 時間 |
| connpass の勉強会 | 2 時間 | 0 時間 | 0 時間 | 約 1 時間 | 0 時間 |
| 合計 | 約 29.2 時間 | 約 32.9 時間 | 約 25.2 時間 | 約 27.5 時間 | 約 13.1 時間 |
注力分野
Kotlin
今月も RealWorld の実装をしていました。そして実装が完了しました。 先月末から、以下の 2 つに取り掛かり完了したら、RealWorld が全体として完了だと想定していました。
O/R マッパの選定もおこなっていましたが、ちょうど良さそうなものがなく、結局やめてしまいました。しばらくは素の SQL で実践していきます。
知人と自分の 2 人でやっていたのですが、あたらしく共通の知り合いが Kotlin に取り組もうとしていることから、次の勉強段階に移ろうとしています。 自身も教える立場になり、学び方のベクトルが変わるので、学んだことをまとめつつ、教えられるように意識をかえていきます。 関連として、これを機会に Kotlin で Web API のアプリケーションを作る方法を書籍としてまとめたくなりました。 そのため、12 月末まで、週 1 回 Kotllin の技術記事投稿を目標にしていましたが、中断することにしました。
月初に目標を掲げていた、『「Functional Programming in Kotlin」の読書計画を作成 & 計画的に読む』は、実践できませんでした。どうしても時間がとれませんでした。それにもかかわらず、「Kotlin in Action, Second Edition」を購入してしまったので、どれから読もうか考えています。
別件になりますが、社内で PHP の API を置き換える議論について考えています。 個人的には Kotlin で置き換えたいのですが、自分のやろうとしていることが、「事業のための仕事」と「人のための仕事」どちらなのか考えています。 Java と Kotlin を比較した際に、明確に Kotlin の方が優位である理由を示せずに困っています。 しかし、Kotlin が選ばれなかったら、組織的の考えと個人の考えが一致しなかったことを理由に辞める可能性があります。
設計
今月の 2 週目に「ソフトウェアアーキテクチャの基礎」を読み切りました。 主にアーキテクチャを選定するときや評価するときの決定基準について学びました。 今まで、コードレベルでの意思決定しかしていなかったので、他人を納得させるためにどのような要素が必要になるのか参考になりました。 特に、印象に残った点は、リスク評価と ADR です。 ビジネス側が持つ重要な関心事の 1 つのはずなのに、今までリスク評価を書き出したことありませんでした。 今後、実務レベルで導入するには必ず必要だと思いました。 もう 1 つは ADR です。 アーキテクチャの技術的な意思決定をどのようにまとめるのかわかっていませんでした。 社内ドキュメントに体系的にまとめるのも良いですが、スナップショット的なまとめ方もできると良いと思い、今後導入しようと思えました。 本書を読むことで、ソースコードレベルに止まらない、アーキテクチャについて考える良い機会になりました。
今月の 3 週目から、「Google のソフトウェアエンジニアリング」を読みました。 エンジニアリングについての話だったので、まとめるのが非常に難しいです。「エンジニアリング」として学ぶのは初めてなので興味深いことが記述されています。 現場、公平性や、チームビルディング、生産性といった普段考え直すことのない部分を読んでいます。 特にスタイルの強制やコードレビューについては、当たり前のようにやっているのに、改善できない部分だったので、今一度考え直しました。 今まで読んできた本の中で最も鈍器なので、負担が重いですが、頑張って 8 週間で読み切ります。
読書
読書概要
今月も、設計と Kotlin 関連の書籍を主体に読んでいました。 後輩との勉強会で Go を学んでいるのでついでに Go の書籍も読んでいます。
読んだ本
「ソフトウェアアーキテクチャの基礎」
「プログラミング言語 Go」
引き続き、職場の後輩と 2 人で読んでいました。内容的に 7 章までで読むのをやめました。
「初めての Go 言語」
「プログラミング言語 Go」の副読本として読んでいます。 いつ読み返しても非常にわかりやすく、名著だと考えています。
「読みやすいコードのガイドライン」
こちらの書籍は Kotlin でサンプルコードが書かれていたため読みました。 しかし、想定していたより書籍の難易度が高く感じられたため、途中で読み飛ばしてしまいました。
「オブジェクト指向設計実践ガイド」
オブジェクト指向の勉強がしたくなったので、本書を読むことにしました。 読了予定時期は未定です。
「Kotlin in Action, Second Edition」
MEAP で売っていたので技術書作成の参考にする目的で購入しました。 第 1 版と比較して、Kotlin 自体についての説明が増えており、歴史の流れを実感しました。
技術記事の作成
Kotlin 縛りで 1 ヶ月間投稿できました。 そろそろネタが厳しくなってきたのと、技術書を作成したいので、12 月末まで続けるか未定です。
「Kotlin（Spring Boot）の API テスト（MockMVC）で CustomComparator を用いて独自の比較方法を作成」
「Kotlin（Spring Boot）+ MockMVC + DatabaseRider で簡単 API 結合テスト」
「Kotlin（Spring Boot）のテストコードで @SpringBootTest を利用して DI する」
「Kotlin（Spring Boot） に ArchUnit を導入する」
その他
connpass の勉強会
JJUG を視聴しました。
まとめ
今月も Kotlin と設計に注力した 1 ヶ月でした。
Kotlin については、約半年間取り組み続けてきたプロジェクトだったので、やりきれて良かったです。 個人開発なのに、この規模で最後までやり切れたのは非常に良い経験になりました。共同して作ってくれた知人に非常に感謝しています。 次は、3 人目として Kotlin 初学者の知人も参画し新しい学習用のプロジェクトを作成します。 今回は自分も教える側になります。これを機会に Kotlin で Web API のアプリケーションを作成する技術書を作成しようと思いました。 技術記事の投稿は習慣化していましたが、より体系化された文章構成を考える必要があります。難しそうですが頑張ります。作成期間は三ヶ月程度で一旦公開を考えています。 そのため、12 月末まで技術記事の週 1 投稿を必ずやるのは、一旦やめようと考えています。
設計は「ソフトウェアアーキテクチャの基礎」を読み切りました。 今回も分厚い本でしたが、勉強会で読み切れてよかったです。 以前の本でもそうですが、さまざまなメソッドを学び、まずは実践すること、そして保守運用することが重要だと考えています。 それに加えて、「今までは異なるパラダイムを持つ人たちにどうやって納得感を持って取り組んでもらえるか」というのが課題になっています。 自分にとっては当たり前のように感じるやり方を相手に受け入れてもらえないのは技術料以外の部分に依存していると考えています。自分は、エンジニア感性（個人的に名付けたもの）に依存していると考えています。 「感性」とは、印象を受け入れるの能力のことです。主に芸術領域で使われる言葉だと考えています。 苦しんだ経験やうまくいった経験が異なることにより、直感的な理解や説得に齟齬が生まれてしまう現象が、エンジニア感性の違いだと考えるに至りました。 感性の違いを説得するには、ロジックを組み立てて説得したり、単に指示したりするだけでは、不十分であることを実感しています。 感性を可能な限り一致させるためには、チームビルディング、ペアプロ、コンテキストの説明、体験学習などがより重要になります。 さらに、どちらかに偏ってしまうとうまくいかないので、言語化と行動の両輪を揃えなければなりません。 これらの活動や理解もアーキテクトやリーダーに必要なの要素だと考えるようになりました。
今年もあと 1 ヶ月になります。 毎月おこなってきた振り返りを 11 ヶ月継続し、四半期ごとの振り返りも 3 回行えました。 来月は年末なので、それに加えて 1 年の振り返りもおこないます。 最後まで継続して来年の目標を立てます。
