ソースコードを脳に収める準備 - 脳に収まるコードの書き方② - ReadLog

2024年8月12日 20:07

前回からの続き、ではありますがここから読んでも大丈夫です。
でも、読まれたいので前回のリンクを貼らせていただき奉りますね。

概要

タイトル：脳に収まるコードの書き方
ジャンル：技術書（情報系）, ソフトウェア開発, プログラミング技法
備考：重要語句を出してくる割に説明が遅い。生成AIに対する予測は甘～い。

ここは本の紹介と記録を目的としたマガジンです。
時間がない人や面白い本を探している人向けです。
本の一部を引用しながら、少しでも興味を持ってもらうことを目指してます。

※ややこしいですが、本文中の「著者」というのは紹介する本を書いた人のことを指します。本文を書いた奴のことは「私」と書きます。

2章のタイトルは「チェックリスト」です。
やることはリストアップして1つ1つ潰していこう。
という話…

…は章の最初の2ページで終わります。

この章は「著者オススメの開発チェックリスト」の説明が大半です。
そのチェックリストは以下の通りです。

著者はあくまでも、このチェックリストに従うかはあなた次第です。
と言いますが、これから全16章のこの本を読むならこの著者に合わせたほうが楽です。

バージョン管理にはGitを使いましょう。
ローカルでコードをいじってもすぐ戻せるので。
集中管理型のアレとかコレはやめてください。
ベストではないけどベターな選択肢です。
（ベストなのが出たらすぐに乗り換えること）
※あくまで著者の主張です。

ビルド・デプロイはストレスにならないように自動化しましょう。
CI/CDのサービス継続的インテグレーションはお金を払ってでも使いましょう。人件費よりは安いので。
※あくまで著者の主張です。

コンパイラ警告をエラーとして扱ってください。リンター、静的コード解析の警告もエラーとして扱いましょう。

p.23 2章チェックリスト

警告をエラーとして扱うとどうなるかというと、本来プログラムとしては動作するコードもコンパイルできなくなります。
1行の文字がちょっと多かったり、自動生成された空っぽのメソッドが残っていたりすればコンパイルが通らなくなります。

感覚的には問題が増えてしまいますが、警告の出ない綺麗なコードを保ち続けることで大きな問題の発生を抑えることができます。
新規開発で最初からコードを綺麗にできていれば、対応はそんなに難しくないはずです。
※あくまで著者の主張です。

ひとつずつ警告の原因を解決して、最終的にすべての警告を有効化しましょう。
既存コードだからいいじゃん　というわけにはいきません。

プロジェクトのマネージャーが「そんなこといいから早くやれ」とか言ってきたならこう返しましょう。

「すみません、でも、そうやらないとコンパイルが通らないんです」

p.25 2章チェックリスト

※あくまで著者の主張です。
コードを人質に、コードを綺麗にするわけですね。
この返しは涙声で言うのが効果的な感じがします。
あくまでも私はコンパイラの被害者です、というスタンスで。

…できるかぁそんなこと！

コードは綺麗に美しく♪
コード清掃にご協力ください♡

先ほど紹介した2章の（表向きの）主題は、「チェックリストを使って忘れないようにしよう」ということでした。3章もその話が続きます。

そもそも、人間は忘れっぽいものです。（やたら主語が大きい？）
例えば今読んでいるこの文章も、一言一句何と書いてあったかは覚えていないでしょう。
この文章を書いた私も、覚えてません。

それはソースコードも同じです。
キーボードを叩いている間は、実装しようとしている機能についての知識が頭の中にあって、変数の名前の意味やあるクラスのメソッドについての知識があるでしょう。

コードが完成してしまえばそんな記憶はたやすく消えてしまいます。
そして…

コードは書く回数より読む回数のほうが多い。

p31 3章目的

コードは書かれるにあるものではありません、読まれるためにあります。
一番の読み手はコンピュータではありません、未来の自分を含んだ他の人間です。

読みやすいコードを書くための方針として、著者はこんな条件を挙げています。

具体的なことは後の章で語られます。お楽しみに。
サイクロマティック複雑度の説明も後です、関連するコトなんだから近くに書いてほしかった。

次：

この記事が気に入ったらサポートをしてみませんか？