アドベントカレンダーのために20本近く記事を書いてきた中で、自分が大事にしていることが浮かび上がってきたように感じられました。
本記事ではそれらを書いていきたいと思います。
調査編
調査の対象は「まずメインから」でいい
調査をしようとしても、まず調査の対象が複数出てきてどれを選ぶか、の選択を迫られる場面があります。
今回のアドベントカレンダーの中で、「命令セット」の意味はわかっていても「命令セットアーキテクチャ(ISA)」の意味は分かっていないな、と思い調査することにしました。
具体的なISAを一つ決めて調べていくのが良さそうと考えたときに、選択肢が「MIPS」「x86」「ARM」など複数出てきました。
このようなときに、以前だと片っ端から調べようとしていました。しかし今は、とりあえずメインのものをしっかり調べるを重視しています。今回だと自分がメインターゲットとしているWindowsで標準のx86_64です。
こうすることで、目的を素早く達成することができます。今回であれば命令セットアーキテクチャとは何か(単なる命令セットとの違いは何か)を理解することであり、「レジスタの個数やサイズなど、物理的な制約を含めた仕様」と理解できました。
コードベースからソースを読むときも同じです。例えば複数のモードがフラグ指定できる関数を調べる場合は「今気にしているもの」とか「適当にデバッガで動かしてみたときに動くモード」にまず絞ってみます。
モジュール階層ごとのAPI(横の関係)を意識する
上の話と似ていますが、ソースを読んで調査する時はこれも意識しています。
もっとも単純な例は「getとsetが対になっているだろう」とか考えてあたりをつけるような感じです。ソフト全体の設計思想やデータ構造が関わってくる部分も大きいとは思いますが、割と一般に有効だと思います。
今回のアドベントカレンダーの中では適した具体例があまりなかったので、詳しくは今後書ければと思っています。
楽しむコツ「これはどういう仕組みなのか」純粋な疑問を持つ
以前は「どう/いかに速く目の前の調査項目を終わらせるか」しか頭になく、そのような調査はなかなか苦しいものでした。
しかし今は、「これはどういう仕組みなのか」という純粋な疑問とともに調査を進めていき、調査に楽しさを感じることが多いです。
冷静に考えると、OSのような巨大で複雑な構造物でさえも、ソースに全てが書いてあるわけです。しかもそのソースが公開されている。これはロマンだな、と感じます。
まあすべてのソースを読んでいては時間が足りない、というのもあるのですが。
ソフト開発編
データと処理には「どういうものか」の位置付けがある。
こちらに関しては、以前の記事で書きました。
また、直接関係はないですがこちらの記事でも設計について重要だと考えていることを書きましたのでここで触れておきます。
「A案vs B案」に終始しない。メリットデメリット論では浅くなる。
何か処理を実現するときに、案が複数出ることがあります。
このとき、単にそれぞれの案のメリット/デメリットを比較するだけで決めたくなりますが、それは良くないです。(もしくは決まらないです)
この記事でも書いたように、プログラムやモジュール構造は意図を埋め込むものであり、「そうする理由」を考えることが重要です。
「2つの案の違いは何か」「どういう意図を埋め込むべきなのか」を根本から考えていくことで、いい処理方式を練り上げることができます。これが重要だと考えています。
しかしこちらも良い具体例がアドベントカレンダー内にないため、今後この主張を補強するようなものを生み出せればと思います。
最後までお読みいただきありがとうございました。