Tidy First? 個人で実践する経験主義的ソフトウェア設計
- オライリー・ジャパン (2024年12月25日発売)
本棚登録 : 450人
感想 : 45件
本ページはアフィリエイトプログラムによる収益を得ています
Amazon.co.jp ・本 (164ページ) / ISBN・EAN: 9784814400911
作品紹介・あらすじ
コードを「整理」して読みやすくするための理論とテクニック！
コードを整理して読みやすくするには、扱いやすい部分に分割する必要があります。本書は、XPの考案者でデザインパターンやテスト駆動開発のパイオニアであるケント・ベックが、システム全体の構造を考えて、どの段階で、どのように整理するかを提案します。たくさんのコードを含んだ大きな関数がある場合、それを論理的に小さなかたまりに分割する方法を解説し、結合性、凝集性、コード整理の費用対効果など、ソフトウェアデザインの背後にある理論を学びます。
感想・レビュー・書評
-
Kent Beck 久々の新刊。どうということのない薄い本だが、プログラムの変更を(機能を変更しない)structure changeと、機能変更(feature change)に分けて、structure changeの様々なパターンやタイミングの功罪について論じる。かつて、リファクタリングという言葉で語られた行為は、「価値を生まない」「規模が膨らみがち」「よく壊す」と、その評判は地に落ちている。structured changeは、改めてリファクタリングの重要性を説きつつ、より実践的な規模、タイミング、機能追加との分離を提言する。
一度作ったソフトウェアが永久機関のようにそのまま動き続けるというのは明らかに間違ったメンタルモデルであり、我々はソフトウェアは変更されるものであり、変更され続けるものであることを知っている。そしてどのような変更に対してどのような準備をしておくべきかを事前に知ることは難しい(言い換えると、どこを分離して、どこを結合させておくかを事前に判断するのは困難)。「いつ整頓するか」は単純な問いに見えて、ソフトウェアの複雑なトレードオフ空間における問題なのだ。
5
詳細をみるコメント0件をすべて表示 -
コードが読みづらい、一つ変更したら他のところも直さなきゃいけないので変更するのに時間がかかる。リファクタリングができればもっと良くなるはずだけど、そのためのお金も時間もない。本書はそんな開発の現場で苦しんでいる人への解決策を、整頓という形で提示してくれている。
タイトルのTidyは訳語では整頓としている。整頓はリファクタリングのサブセット。リファクタリングが重く、時には破壊的なプロセスになってしまったことに対して、整頓は自分の範囲で日々実践できる、継続的にコードを改善するためのワークフローとして定義されている。本書ではこの「整頓」をいつ、どのように、なぜ行うのか、その考え方を示してくれている。
かくいう自分も、リファクタリングというと開発を止めて行うというイメージがあったので、日々改善する整頓の考え方は新鮮だった。短い本なのですぐ読めるし、紹介されているテクニックは真新しいものではないのですぐに実践できると感じた。
5
-
TDDで有名なケント・ベックによるシリーズの第1作。「コードをいつ、どのように、どこまで整頓すべきか？」という悩ましい課題に対し、豊富な経験に基づく多くのアドバイスが得られた。薄い本だが、内容は濃い。
本書を読む前は、「最初に整頓するのが最善なんでしょ？」と予想していたが、実際は「必ずしも最初に整頓すべきとは限らない」であり、いい意味で裏切られた。単なる「整頓すべき」というべき論ではなく、経済合理性の観点で論じられているのがユニーク。
本作は個人の整頓術であり、次作はチームによる整頓術。続編が楽しみである。
4
-
ソフトウェアの改善を整理整頓の切り口でまとめた本。
第I部はTipsのような明日からもすぐに役に立つHowが書かれており。
第II部は整理整頓をいつ、どのようにやるのかを、
第III部は整理整頓をなぜやるのかということが書かれている。
細かく章が割れており、各章が短いため、サラサラと読める。
ジュニアのメンバーがリーダーブルコードのあとに読むのもオススメできる。
シニアな方にはサラッと読める技術書として、オススメしたい。
3
-
第一章は整頓するための具体的なテクニック。
第二章は整頓する際にどのように管理するか。プルリクエストを一つにまとめるのか小分けにするのかなど。信頼関係があればレビューを省けるとあったけど正直怖いな。
第三章は整頓とそれによる経済的な効果について。たぶん一番力が入ってるんだけどよくわからなかった。先に実装すればすぐに稼げるのでキャッシュフローはいい。先に整頓すれば先にコストがかかるものの柔軟性が増すので、大変な問題にも対応でき将来的に大きな利益を得られる可能性が上がる、ということかな。
個人的に刺さったのは、「自分が無限に賢かったら」という考えを崇拝してしまうというところ。まさにそう。現実にそれは無理だから、可逆的な変更を進めてできる限り不可逆な判断を遅らせよう。別の本にも書いてたなこれ。
1
-
第一部 整頓は、具体的なコードの整頓方法について。各章一ページと大変短くて読みやすい。実践も簡単。とりあえずこれらの整頓方法はできるようになっておく。
第二部 管理術は、いつ、どのくらい整頓するかについて。やり過ぎ注意。
第三部 理論は、整頓の裏にある筆者の設計の定義や、金融分野のオプショナリティを引用しての管理術の説明など。おそらく本書でもっとも力が入っている部分はここじゃないかな。
全体的に短くて読みやすいが、しばしば意図が読めない文章がある。翻訳なのか原文からそうなのかは分からない。
1
-
リファクタリング本と異なる価値としては、結合と凝縮が経済的な側面を孕んでおることを明示した点だと思う。収益性とコストにも言及しつつ、tidy first?と問うている
1
-
エントリーポイント
イグジットポイント
Chapter 1. Guard Clauses
IF などにより条件分岐がある際は、構造を複雑にネスト化するのではなく、早めに return や break できるものをできるだけ上に記載し、できるだけシンプルな形にする
Chapter 2. Dead Code
Dead Code と判断して消したコードが、実際は必要なコードであった、というケースも発生し得ます。
なので、一斉に実施するというよりは、消し間違えてもすぐ戻せるよう、小さく小さく、几帳面に (tidy に) 不要なコードを消していくことが大事です。
Chapter 3. Normalize Symmetries
プログラムは表現方法は1種類ではなく、同じ処理を行おうとしても書き方が複数あります。
ただ、皆が別々の書き方をしていると認知負荷が高まるため、ある程度対称性を正規化しましょう（書き方を揃えましょう）、という内容です。
Chapter 4. New Interface, Old Implementation
実装があって、そのインターフェースがあって、インターフェースが理解が難しかったり複雑だったりする場合、
実装はそのまま (Old Implementatino)
インターフェースだけ新しくする (New Interface)
というアプローチが有効だ、ということのようです。
Chapter 5. Reading Order
プログラムは人間が理解しやすいように、できる限り意味的に順番に並んでいることが望ましい、ということのようです。
Chapter 6. Cohesion Order
Cohesion = 凝集、という意味。
意味的に関連があるものは、近い場所に書かれていた方が良い、という意味のようです。
「凝集する」というものの意味のスコープは、本文に書いてあった内容によると以下のようなものです
同じクラスファイル内 (似たような処理は同じクラス内にいた方が良い)
同じディレクトリ内 (似たような処理は同じディレクトリ内に揃っていた方が良い)
同じリポジトリ (似たような処理は同じリポジトリにいた方が良い)
Chapter 7. Move Declaration and Initialization Together
コードの宣言と初期化は一緒に行うべき
Chapter 8. Explaining Variables
コードは最初は小さくても自然に巨大化するので、特定のコードシーケンスが最初は自明でもいずれ複雑化し、内容の理解が難しくなることがあります。
なので、変数などについては、それがどのような意味なのか、わかりやすい形にすることが大事、ということのようです。
コメントなどの付与も大事そうですが、
プログラムの構造
変数や関数の意味の明瞭化
あたりが大事なポイントになりそうです。
Chapter 9. Explaining Constants
これもよく言われるもので、マジックナンバー的な記述をするのではなく、
定数を作成した方が良い
その名前も、わかりやすくて解釈のブレがないような名前にした方が良い
という話です。
Chapter 10. Explicit Parameters
メソッドなどに明示的にパラメータが渡されてない件について書かれています。
具体的には、メソッドにパラメータを渡す際には、変数を定義したり名前付き変数などを用るべきで、配列や連想配列をそのまま渡すようなコードは良くない、という話です。
Chapter 11. Chunk Statements
プログラムが複数行ずらーーーっと並んでいると見づらいので、キリの良いタイミングで改行を入れましょう、という提案です。
Chapter 12. Extract Helper
コードの中で再利用性が高いセンテンスがある場合は、それを独立した処理として抜き出すべき、という話です。
いわゆる「Extract Method」で、リファクタリングの基本の「キ」の話で、よく語られる話ですね。
Chapter 13. One Pile
ソースコードの記述は、あまりにも細かく分散されすぎているよりは、一つのクラスなどにインラインでまとめて記述されていた方が良い、という提案です。
では、適切な粒度にクラスを分割せずに、肥大化した巨大なクラスを作れば良い、という提案かというとそうではなく、一番の要点としては
ソースコードの一番のコストは、可読性の悪さ
書きにくさではない
ということのようで、可読性の高いコードを書いていく必要がある、という提案のようです。
The biggest cost of code is the cost of reading and understanding it, not the cost of writting it.
小さすぎるコードは他のコードとの相互作用性が大きくなりがちで、可読性が落ちることがある、ということが、言いたいことのようです。
Chapter 14. Explaining Comments
適切なわかりやすいコメントを付与しましょう、という話です。
Chapter 15. Delete Redundant Comments
適切なコメントの付与は必要ですが、不要なコメントは削除しましょう、という話です。
一番あるケースとして、ソースコードを見れば何をしているか自明なのに、同じ内容を自然言語で説明している、というケースです。こういうのはムダなので削除しましょう、という提案のようです。
16章 『分けて整頓する』
コード変更には『構造変更(＝整頓)』と『振る舞い変更』があり、それぞれでプルリクを分けよう、という主張。
17章『連鎖』
整頓は連鎖するものである、というのを第Ⅰ部で紹介したそれぞれの整頓術同士がどのように連関しているのかを例示していくことで明らかにする。
18章『バッチサイズ』
整頓だけのプルリクはレビューしなくてもいい、というフレーズへの補足がしっかりとされていた。
適切に失敗から学習していきなさい、というやさしさ。
20章『絡まりを解きほぐす』
コード修正をしていると得てして発生する『整頓』と『振る舞い変更』が気づかぬうちに絡み合ってしまった状況について、その間の作業をいったんすべて捨てたうえで、『整頓』⇒『振る舞い変更』の順に修正を入れ直せ、という提案。
21章『先に整頓、あとに整頓、改めて整頓、整頓しない』
整頓するかしないか。要するにコストがペイするかどうかの軸を持てということ。
整頓したい項目に気付いてやらない時は「お楽しみリスト行き」にする。
0
-
-
『間違えないようにもっとうまく決定すればよいと考える理想主義的なギーク思考がある。私は若いころ、「自分が無限に賢かったら」という考えを崇拝していたが、幸いにもその考えは乗り越えた。』
ページ数が少なく必要なことが詰まっている。第１章の具体的なすぐできる小さなことから始まるのでとっかかりやすい。整理整頓はするのは良いが「いつするか？」と整理整頓にはどういう効果があるのか、というのが第２章、第３章に書かれている。
『本書の範囲では、お金の時間価値が推奨しているのは、先に整頓するよりもあとに整頓するほうだ。お金を生む振る舞いの変更を今すぐ実装して、あとから整頓できるなら、すぐにお金が手に入り、あとでお金を使うことになる（前述のとおり、ときには先に整頓してから振る舞いを変更するほうが整頓せずに変更するよりも安価なこともある。そんな場合は常に先に整頓する）。』
今はこれがやりやすい時代になった。でも先整頓されていないものを人に見せるのはなんだか気が引ける。
0
-
プログラムを, まず tidy (きれいに) すべきか? という内容で, tidy にする方法や, いつ tidy にすべきか? について深堀している. ただ最後まで読んでみて, これはプログラミングだけでなく日常生活にも当てはまるなと感じた. まず片付けるべきか? まず掃除すべきか? 私たちの身の回りには tidy にしておきたいものに溢れているが, 同じ考え方を適用できると感じた.
0
-
コードの整頓の本で、「リファクタリング」より少し小さい範囲を扱っている。が、この本で重要なのはそこではなくて、じゃいつ整頓するの？ どこで整頓するの？ みたいな、一つ上の視点から見ている辺りかと。短い本で、そこまで読みづらいわけではないのだけど読み切るのに意外と時間がかかった。そして、読み切ってもまだ何度か読まないと十分に理解できないだろうなと思わされる。本当に言いたいことは多分あまり多くなくて、それをじっくり丁寧に説明してはいるから、ある意味わかりやすくはあるんだろうけど……でもなんか妙に難しい。まあ、Kent Beckの本はどれも割とそんなもんか？
0
-
システムの継続的な変更や不具合対応に伴う、プログラム修正のタイミングや方法に関する示唆をくれる書籍です。
この書籍の特徴は、複雑なプログラムを前にした際の判断基準が整理されていることです。
整理してから修正するか、修正してから整理するか、いつ・どこで・どのように手を加えるべきかという悩みに有効な考え方が提示されています。
抽象的な表現や間接的な言い回しも見受けられましたが、システム開発や運用の経験が豊富な読者にとっては、有益な教訓が多く得られると感じました。
一方で、スキルや経験が一定水準に達していない読者にとっては、意図を十分に理解しきれないかもしれません。
また、オライリーの出版物としては比較的文字数が少ない一方で、価格設定はやや高めに感じられました。
気軽に読める量ではありますが、購入に際してはコストとのバランスにも留意したいところです。
この書籍は、ある程度以上の経験を積んだエンジニアがプログラム修正時の判断基準を整理する上で参考となる一冊です。
一方で、ある程度のシステム開発経験を前提とした内容であるため、購入を検討する際には、自身のスキルレベルと目的に応じた慎重な判断が望ましいかもしれません。
0
-
リファクタリング的（本書では「整頓」）なところが主題っぽく進むのですが、「ビジネス視点で見たときの技術的べき論への捉え方」という本質も示唆してくれる本。
オライリーですが文量・分量はライトなので読みやすいです。個人的にはすごくオススメ本でした。
0
-
前半は比較的細かなプラクティスが並んでおり、プログラミングに携わる人ならうんうんそうだよなとうなずきながらテクニックを学ぶことができる。…と思いながら読んでいると、ことはそう単純ではないのである。 Tidy(整理) をいつやるのか？について考えること、つまり本のタイトルが 'First?' の疑問形で終わっている意味こそがこの本の山場となっており、そこにはファイナンスにも通じる意思決定が必要になるのだ。いつやるの？の答えとしては場合によるわけだが、判断材料は提供されている。リファクタリングを始めるとき、機能を育てているとき、常に存在するトレードオフとの付き合い方を教えてくれる。 続巻にも期待。
0
-
点検読書I 3部作の最初の本。個人で、ソフトウェアの実装から設計へ昇華する方法について実践する部分についてかかれている。リファクタリングという言葉はいろいろ恣意的に使われ、「整頓」という言葉を使っている。
最初の1部は平易な方法で、書籍リファクタリングへのよい助走だとおもっていたが、2部で、整頓の管理方法、そして極め付きの3部の理論的背景は読んでいて咀嚼し、理解するにはちょっと時間がかかる。金融工学の概念がこんな所で説明をされ、理論の中心となっている。ちゃんと続く章でプログラマが噛み砕ける説明になってるので、ひとまず最後まで読み通してみるのをおすすめする。
次はチームとしてリファクタリングを扱うようでこれも期待が大きい。書籍リファクタリングを読み直してみるのもいいだろう。
0
-
早めにやっといたらいいんちゃう？コストが先か後か、という違い。
良い指標が載っていた。
cost(整頓) + cost(整頓の後に振る舞いを変更) < cost(整頓せずに振る舞いを変更)
であれば先に整頓したらいいと。
0
著者プロフィール
吉羽龍太郎の作品
