book: クリーンコードクックブック
2025/05/11
オライリージャパンの本「クリーンコードクックブック」を買ってきた。 買ったばかりでまだ最初の方しか見てない。
長年、設計が下手というか、うまく設計できないというのが悩みである。
勉強してこなかったというのもあるし、何を勉強したらいいんだというのもある。
あと、小さい組み込みだと設計が最初から決まっていてあまりやれることがなかったというのもあるかもしれない。
SES の仕事でプロジェクトが長くても 1年とかなので、設計を自分でやることが少なかったのも拍車を掛けたか。
言い訳だ。。。
この本のサブタイトルは「コードの設計と品質を改善するためのレシピ集」である。 設計といっても切り口がいろいろあるが、この本は結構コードに近いところの話をしているようだ。
3章からレシピが載っているようだが(まだそこまで読んでない)、
1章 と 2章にこの本がどういう書き方をしているか載っているので、辞書的にレシピを読む前に眺めておいた方がよさそう。
私はまだ 2章を行ったり来たりしながら読んでいるのだけど、全単射とか写像とか出てきて頭がついていってないのだ。
たぶん、クリーンアーキテクチャとは関係がない。
この本はいろいろ考えて買ったわけではなく、本屋さんのオライリージャパンのコーナーに並んでいて、
目次をパラパラ眺めたときに「result という変数名を使わない」みたいな項目を見つけたのだ。
その数時間前、ちょうど名前が思いつかずに result という変数を作ったばかりだったので妙に気になり、
これも何かの縁だろうと思って買ったのだった。
リーダブルコードもまだ読んでないのに、似たような本を買って・・・。
経費にするからちょっと気は楽なのだが、納税額に影響するだけで出費は出費だ。
私も全然若くないので、なるべく独自で何かやるのではなく
ルール的なところは若い人たちに合わせていかねば、という焦りがある。
部下とか同僚がいるわけではないのだが、人にコードを見られることはあるだろうから
不評にならない程度にはしておきたいのだ。
身についた習慣というか、身についてしまった習慣というのは、自分でそれを疑うことができないので、
特にフリーランスで他に人が絡んでこない作業をしていたりすると指摘されないので、ね。。。
今だと AI でレビューしてもらったりできるようなので、そういうのも考えないといかんのだろうなー。
2025/05/13
いちいち反発しながら読んでしまうせいか、なかなか進まない。
反発といっても「間違っている！」とかじゃなくて「ええ、そうなの～」というやつだ。
「身につけたい」とか言っておきながらなのだが、まあ仕方ない。
それに著者も、そのまま受け入れるのではなく考え方を理解しよう、みたいなことを書いていた。
なので、自分だったらこうするのだがなあ、という気持ちで読むのは悪くなかろう。
現実世界と一致するように、みたいなことを書いていたので「えー、ソフトウェアなんだから現実に縛られず自由にやろうぜ」と思った。
しかしこれは、モデル開発のモデルとして現実世界を選んだというだけだと考えた。
また、モデルとしてどういうものを使っているかを共有するので、それなら現実世界がよかろう、ということになったのではなかろうか。
もし現実にはないようなモデルにするなら、その部分さえ共有できる形にしておけば良いのだろう。
例えば 2章で、属性が ABC な Alice と 属性が DEF な Alice は、現実としては Alice という人物は一人しかいないので別々のオブジェクトにすると更新漏れなどありそうでよくない、みたいなことを書いていた(手元に本がないのでうろ覚えだが)。 時代が進んで、人間クローンとして 1人につき 3体までクローンを許可する、みたいな時代がやってきたら状況が変わるだろう。 はっ、これはもしかしたら現実世界というあやふやさをも示唆していたのか？
今読んでいる 3章でも「えー、そんなことするのー」という気持ちでいるのだが、 たぶんこういうことを言いたいのだろう、と読み替えている。
個人的にはオブジェクト指向はあまり好きではないというか、 データの公開・非公開を切り分け、操作する関数は局所的にして、 あとはメンテナンスしやすいように同じような機能のソースコードをまとめておけば それでいいんじゃないの、と思っている。
継承の善し悪しはちょっとよくわからん。
便利なときは便利で良いのだけど、オーバーライドされていくとエディタがないと見た目で分かりづらいし。
などなど、いろいろ考えながら「自分はこう」という意思を持つのにはちょうどよいかもしれない。
あんまりこだわりとかないので、いつも気分で実装してたりするからねぇ。
「なんでこう実装(設計)したの？」って聞かれたときに「なんとなく…」以外の答え方ができるようになりたいものだ。
2025/05/14
getter や setter をなくそう、みたいな主張があった。
setter の方は本質的な情報を一部だけ書き換えるようなのは不自然なので、
意味がある変更メソッドにすべき、ということだろう。
本質的なデータはコンストラクタでしか設定できないようにしよう、というレシピもあったし。
Point を例にするのはわかりにくい(座標って変化させるものよね？)と思うのだが、
まあわからんでもない。
getter の方がよくわからん。
内部の構造をそのまま表に出すのは止めよう、ということだろうと思っている。
ただ getWidth() がダメで width() ならよい、というのがわからない。
名前が違うだけで実装は同じやん。
ゴニョゴニョ考えていたら、そういえば C# にはプロパティという扱いがあるのを思いだした。
C++ や Java にはそういうのがなかったので、取得するなら関数名がどうあれ get 系にしかならないのだ。
私としては、プロパティって概念はいらないんじゃないの、と思っている。
単に考える要素が増えるだけでやること変わらんし。
もしかしたら最適化するのが楽なのかもしれないけど、最近のコンパイラは賢いから書き方くらいでどうにかなったりはしないと思う。
C# でのプロパティしか知らないのだが、そういえばオブジェクト指向でのプロパティとはなんだろう？
なるほど、プロパティを言語機能として持っているものと持っていないものがあるのね。
C# でなんで set とか get とかわざわざ別に書かないといけないんだろうと思っていたが、
フィールドと同じ感覚で操作できるというのが売りなのか。
なくせ、というほどのことではないと思うけど、フィールドと同じように操作できる点だけがメリットなら使わなくてもよいかなあ。
が、このレシピで言っているのはプロパティをやめようではなく、getter をやめよう、だ。
もしかして、 getter って値を取得する系のメソッド全部を指すのではなく、
フィールド値をそのまま返すだけのメソッドを指しているのかな？
そうだとしたら、著者のプレフィクスに get を付けるのがダメなのは、
著者が getter はプレフィクスに get を付けるというルールだからと思っておけば良いのか。
私の英語のボキャブラリーが貧困なので、軽く取得するなら get、設定するなら set、計算して取得するなら calc、くらいのルールなのだ。
いつもわかりづらいと言われてしまうんだけどね。。。
ともかく、この人の名前ルール的に get がつくものは getter としているから get ということにしておこう。
コメント(Google Formへ飛びます)
Homepage