割と当たり前のことを書いてみるシリーズです
なんか最近、あんまりソフトウェア考古学的なことやらない人増えたのかなという気がして。
めちゃ忙しいとかでなくて時間があるのであればやるのがオススメかもしれないという話を書こうと思います
ソフトウェア考古学とは
以下のブログ記事が詳しかったのでこちらに委ねます
https://satob.hatenablog.com/entry/2019/07/17/003751
ここでいう、 “システムの仕様理解の補助“ の面を自分は推したいです
なぜソフトウェア考古学なのか
- 人は最新のスナップショットしか見ない
- 最新のスナップショットと自分のこれまでの経験や知識を重ね合わせて良し悪しを判断する
- 最新のスナップショットだけから良し悪しの判断をすると、何を選んで何をやらなかったかの意思決定の理解が薄く、そのプロジェクトの課題や価値といった部分の芯を食いにくい。一般的には正しいが、少し的外れみたいなことが起こり得る
- スナップショットだけでなく歴史の理解が必要
ドキュメントやコミュニケーションによる伝承があればソフトウェア考古学は不要なのではないか
- ドキュメントやコミュニケーションで網羅的に出来るチームであれば不要
- そういう意味だと不要といえば不要だが
ドキュメントの問題点
- ドキュメントは大体において読まれない
- ドキュメントは大体において何処にあるのか分からなくなる
- ドキュメントは大体において不完全
- これらはドキュメント関連のソリューションによって解決する部分もある一方、人間の認知負荷とかそういう系のアレもある気がしている
コミュニケーションの問題点
- コミュニケーションはどこかで抜けたり漏れたりする
- 退職などでコンテキストが抜け落ちると誰も知らないものが生まれる
- チーム同士の境界などは誰も知らないものが生まれる
- チーム全員が月日と共に忘れるということもある
結論
- 結論、ドキュメントやコミュニケーションの工夫である程度のカバレッジは得られるがそれを補うための考古学は必要と考える
- 考古学によって、ドキュメントやコミュニケーションの理解度が上がったり、ドキュメントの裏付けとして考古学、または考古学の裏付けとしてのドキュメントなどの試行錯誤が出来る
質問するな、自分で調べろというわけでは無い
- 質問は知の高速道路的なやつなので、仕事でチームが加速するためには大事
- 質問をより精度の高いものにするための手段として使える
- テストがない、ドキュメントがないというレガシーを助長したいわけでもない
- 「過去ログみましたか？ググりましたか？」という厳しいコミュニケーションは後世には残したくない気持ちに最近なってきている
- 考古学をするかどうかは完全に個人の判断に任せられる
- 個人の判断に任せるが、基本的にやった方がおトクなのではないかという所感が年々強まってきた
自分がなぜソフトウェア考古学を無意識にやっているか
- 原体験的には、高校時代にゲーム開発のコミュニティ掲示板みたいなとこ。誰も教えてくれないし「過去ログみて」だけ言われて、調べた上で質問したりとか
- 社会人になってすぐは、そうしないと分からないことが多い現場が多く必然的に習慣化した
- 全てはドキュメントにない、自分の未熟さや雰囲気的に聞きにくいなどがあった
- ソフトウェア考古学をすると「なぜ」とか「いつ」とか「誰が」とかが転がっているので人から聞いたりドキュメントで読んだりするのとは別の視点で強化される感覚があるので、「早く成果を出さないと」みたいな意識でやろうとすることが多い
- ここ数年はそこまで「早く成果出さないとやべえ」みたいな焦燥感はちょっと減ったけど習慣だけが残った感じがする
具体的に何を考古学するか
長々書きましたが、大したことしてません(スミマセン)
ソフトウェア考古学というと大袈裟だし、皆やっているとは思うのですが以下のあたり。
- ソースコードのコミットログを漁る
- slackなどチャットツールを漁る
- ドキュメントを漁る
- チケット管理ツールを漁る
自分が新しく入社したとして、
歴史が浅いプロジェクトであれば全て見通す。
歴史が長いプロジェクトはせめて直近半年や1年を見てみる。
余裕があるときに更に1年遡るなどする。
みたいな感覚。
昔はコミットログを文字通り、1個1個遡るみたいな感じだったのだけど
最近はコードを眺めているとそのコードがどう形作られてきたかが想像出来るようになってきた。「初めはこういう設計理想があって、継ぎ足して、途中で方向転換があったんだろうな」みたいな。たしか似たような話をbufferingsさんも書いてたっけな。
そうそうこれこれ
https://bufferings.hatenablog.com/entry/2023/06/25/133652
なので、気になった部分だけ限定してコミットログを追いかけるなどに絞ったアプローチになってきた。考古学するうちに、スナップショットからエスパーすることが出来るようになってきた（気がする。気のせいかも）
まとめ
幸いにも文章を読める、暇を潰せる、面白がれる、という人はソフトウェア考古学をやっておいて損はないと思います！
「ドキュメントがないから調べなきゃいけない・・・」
「テストがないから調べなきゃいけない・・・」
みたいなネガティブがあってソフトウェア考古学が出来ない場合はテストやドキュメントを書くチャンスかもしれません。
「ドキュメントがあるから調べなくてもいいか・・・」
「テストがあるから調べなくてもいいか・・・」
みたいなこともあると思うのですが、より深い理解をするために要所要所で潜ってみるのも良いと思います。
例えばより深く理解するための質問を誰かにしてみて、思う答えが出なかった時に自分で更に調べるなど。
(開発の優先度とか無視してやっちゃうのはアレですが！)
やってる人にとっては何を今さらというところではあると思うのですが
ぼんやり考えていることを書いてみました。
0 件のコメント:
コメントを投稿