Windows PCを置き換えたので、VS Codeの設定も吹っ飛んだ。いろいろと溜まってサイズも大きくなっていたので、心機一転で再セットアップした。拡張をいくつも入れていた以外は、複雑なカスタマイズはやっていなかったのだけど。
デフォルト状態で、自分の癖と合わず、生産性に影響を与えるのがキーバインド。普段からEmacsのキー操作でやっているので、Emacs配列にしておく必要があった。前に使っていたものは、なんだったか忘れた。今回は、「Awesome Emacs Keymap」を入れた。
Awesome Emacs Keymap
https://marketplace.visualstudio.com/items?itemName=tuttieee.emacs-mcx
カーソル操作がメインなので、「Awesome Emacs Keymap」を入れて、快適に使い始めている。次に変更するときに何を使っていたのか忘れるので、メモとして残す。
シュモクザメを見に葛西臨海水族園にいってきた。葛西臨海水族園は、35周年を迎えていたようだ。いいポスターだった。
下の子と二人で、水族園にいったので、まともに魚は見れなかった。あちらこちらを歩きまわり、ちょっと見たら次の場所へ。少しだけ落ち着いて見れたのは、マグロ水槽のところくらいか。それに、人が多くて人気の水槽には近づくのも大変だった。落ち着いてみようと思うと、平日に一人で行く方が良さそうだ。
読了。やっぱり、どこの会社もシステムの設計ドキュメントの課題はあるのか。課題がない方が怪しい。
開発の運用上、少しずつ仕様が変わっていくところには、ADR（Architecture Decision Records アーキテクチャ意思決定記録）は、良さそう。どうしてその仕様にしたのかを記録し、OK/NG判定で残るので、シンプルでいい。もとのExcelとかの設計を直すよりもいいのかも。テキスト形式で行うので、Gitで管理、Pull requestでワークフロー化して、承認フローにしていく運用をしているところが多いようなので、管理もやりやすそうだ。関係者が多かったり、大きいプロジェクトでも使えそうなのがいいのかも。改修要望のチケット管理に参照を貼るのも良さそうだし。
あとは、そもそも設計書を作らずパターンもあるのか。コードの冒頭に設計を書いてしまうパターン。改修後の状態を記録していくならば、もしかしてこれが一番楽かも。どうせドキュメントの修正が頻繁に行われないのであれば、詳細設計にあたるような部分は、ソース上に書いてしまい、抽出するか、直接参照したほうが早そう。ソースの肥大化につながるがテキストならば、そこまで大きくないし、PC側のパワーが解決してくれるだろうし。関係者が多くなければ、手っ取り早い手法で良さそうだ。
それから、設計でつかうツールも多種多様。企画段階はMiro、画面系はFigmaでツールの切り替えが行われていくところが多いのか。それぞれのシーンでの専用ツールも。その工程の生産性をたかめるためだとは思うけれど、使い勝手のよい万能ツールはなさそうだ。あとは、オーソドックスなWord、Excel。
いろいろと参考になった。読んでよかった。
Amazon: https://amzn.to/4gMZd17
やっと彼岸花が咲いていた。今年（2024年）は、残暑が厳しくて、なかなか彼岸花が咲かなかった。10月に入って、やっと生えてきて、咲いた。やっと秋が始まった感じがする。
あまりにも彼岸花が見つからず、散歩コースなので、だれかに刈り取られたのかと思っていたくらいに遅咲きだった。
