ソフトウェア工学の基礎

第2章 コードの読み取り

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

コードは書くよりも読み取りのほうが多い。

Pythonの生みの親、Guido van Rossum

のコーディング教育のあり方とは裏腹に、ソフトウェアエンジニアはコードを書く時間よりもはるかに多くの時間をコードの読み取りに費やしている。ほとんどの初心者向けコーディング講座では、すぐにコードを書く作業に飛び込み、コアとなる言語の概念やイディオムに焦点を当てる。ポーランド語やポルトガル語を同じ方法で学ぶことは決してないという事実を無視したまま。また、学術プロジェクトの多くは白紙の状態から始まるが、実務開発者はほぼ常に、現在の状態に至るまでに何年もかかったコードの制約の中で作業している。この点については章6で詳しく探求できる。

（エージェント指向／チャット指向プログラミング）の登場により、¹ソフトウェアエンジニアにとってコードの読み取りはさらに重要性を持つようになる。第一選択ではないかもしれないが、自分が書いていないコードと向き合うことになる。安心しろ、未知のコードに出会った時に方向感覚を掴むためのテクニックは存在する。この章ではコードの読み取りがなぜ難しいのかを検証し、そのプロセスを簡素化するヒントを提供する。

既存コードとの取り組みにおける課題

プログラミングをどのように学んだかに関わらず、おそらく多くの時間を「 」と呼ばれる幸福なスペース、つまりグリーンフィールド開発で過ごしたはずだ。そこでは過去の作業の重荷に縛られることなく、ゼロから始めるという仕事を体験できる。しかし、プロとしてのキャリアでは、空白のエディタからアプリケーションを構築する機会はほとんどないだろう。現役のソフトウェアエンジニアとして、時間の多くは既存のコードベースの制約の中で、レガシーコードと日々向き合う「 」なブラウンフィールド開発に費やされる。

レガシーコードの別の名前付け…

古いコードの読み取りは、多くの開発者が避けたいタスクだ。我々はしばしば「レガシーコード」という用語でこれを表現するが、この言葉が褒め言葉として使われることは稀である。レガシーコードの定義は様々だ：昨日書かれたコード、テストカバレッジが不十分あるいは過剰なコード、あるいは単に自分が書いていないコードなどである。

しかし、既存アプリケーションの成功を軽んじてはいけない。製品が何年もビジネス価値を提供し、継続的な投資を正当化してきたなら、それは称賛に値する。我々は「遺産コード」 や「既存コード」といった、より前向きなフレームを好む。この話題についてより深く知りたい場合は、第6章を参照のこと。

既存のコードに関わる問題を解決するよう求められた時、実際には四つの問題を解決しなければならない。

まず第一に、解決しようとしているビジネス上の問題を理解する必要がある。開発者が取り組むドメインは非常に要求が厳しい！ソフトウェアが世界を飲み込んでいる時代において、ソフトウェアエンジニアはますます複雑化するビジネス課題に対するタスクを課されている。いわゆる「低垂の果実」の多くは既に摘み取られてしまったのだ。

次に、自分より先に開発した人の視点で問題を見る必要がある。これがソフトウェア開発で最も難しい部分だ。開発者によって問題解決の方法は異なり、それぞれ習慣や傾向がある。おそらく前任者は、君があまり馴染みのない関数型プログラミングスタイルを好んでいたのかもしれない。あるいは、君にとって未知のパターンを使っていたり、使ったことのないライブラリを活用していたかもしれない。そのアプローチに賛同するか否かは別として、特定の問題を解決する方法は数多く存在するのだ。 ...