ソースコードはパッと見で分かるべき - 脳に収まるコードの書き方⑤ - ReadLog

2024年9月2日 23:35

前回からの続きですが、ここから読んでも大丈夫…じゃないかも

概要

タイトル：脳に収まるコードの書き方
ジャンル：技術書（情報系）, ソフトウェア開発, プログラミング技法
備考：7章で書籍タイトルの目的を果たしてしまった。あとは消化試合?

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

プログラマは一生の中で命名をする回数がかなり多い人々だと思います。
変数に名前を付け、関数に名前を付け、ファイルに名前を付け…
面倒になって適当な名づけをしたら、あとから読んだときに解読困難なコードになってしまいます。

よく言われることですが、機能が分かる名づけをしましょう。
codicみたいな翻訳&命名ツールもあるので有効活用したいところです。

しかし勝負（?）はそれ以前に始まっています。
処理で使うデータ型/クラスの命名です。
まさか、整数型とか文字列型みたいな原始的な型を使ったりしてないよね？（文字列型がプリミティブなデータ型かの議論はしたくないので許して）

メソッド名をXで置き換えても、メソッドが何をするかが想像できるかどうかを確かめてみましょう。

p.126 8章 API設計

例えばこんなメソッドがあったとしましょう。（疑似コード）

文字列　名前から住所を取得するメソッド（文字列）｛
　　// いろんな処理
　　return 文字列
｝

メソッド名を見れば、「名前を入れたらその人の住所が返ってくる」というプライバシー皆無な処理が行われることが分かります。
ではこの本の教えに従ってメソッド名をXにしてみましょう。

文字列 X（文字列）｛
　　// いろんな処理
　　retun 文字列
｝

このメソッドはいったい何をやってくれるんでしょうか…
住所を入れたら名前が返ってくる関数かもしれません。名前を入れたら苗字が返ってくる関数かもしれません。
そもそも文字列を入れたら文字列を返す処理なんてありふれたものです。

この問題を引き起こしている主因は、名前や住所の情報を単なる文字列型で管理していることです。

名前クラスと住所クラスを導入するとこの問題は改善します。

住所クラス X（名前クラス）｛
　　// いろんな処理
　　return 住所クラスのインスタンス
｝

名前を入れたら住所が返ってくる　という情報がパッと見で分かるようになりました。

先ほどの例のメソッドには暗黙の了解があります。
それは、「（住所）データ参照にあたっていかなるデータも変更されない」ということです。

住所を確認しようと思って名前を入れたら勝手にリボ払いの契約をされる、とかいう処理だったら最悪です。（変な例）

コマンド（データ変更）とクエリ（データ参照）の処理は明確に分けましょう。
※コマンドメソッドの返却値はvoid型が良いでしょう。処理に失敗したら例外を投げるのです。

コードを正常にビルドできたら、そのたびにコミットしてください。

p.146 9章チームワーク

ふ～んと思うかもしれませんが、実はとんでもないペースでのコミットを要求しています。後述される例を若干意訳して引用するとこんな感じ

前半はまあわかります。
問題は最後の4つ、処理的には何も変わらない変更も独立したコミットにすることを要求しています。

とんでもないコミット数になってしまいますが、コードを戻しやすくするメリットがあります。
ローカルで何度コミットしてもいいんです、そう、Gitならね。
※リファクタリングしやすくなったり、後の章で出てくるトラブルシューティングをしやすくする効果が見込めます。

コードレビューが答えるべき一番根本的な質問は、「自分はこれのメンテナンスを問題なく行えるか？」です。

p.153 9章チームワーク

非常に分かりやすい基準です。
将来的に押し付けられたらイヤなコードには指摘が必要です。
黙って受け入れたら苦しむのは未来のあなたかもしれません。

ま、今が苦しいんだよ!!!っていうことはよくあることですが。

次回：

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