VISASQ Dev Blog

ビザスク開発ブログ

A Philosophy of Software DesignとClean Codeを対比する

こんにちは、検索チームのよこやまです。 近所にとても良いカフェを見つけたのですが、あまりにもお客さんがいないので潰れないかハラハラしております。

先日 A Philosophy of Software Design (以下 APoSD と記載) を読みました。 日本語訳がまだ出版されていない本ではあるのですが、これまでなんとなく思っていたことを言語化してくれていたり、いくつかの方法論やドキュメントを対比に取り上げており非常に面白い本でした。他ではあまり見ない意見も見受けられるため、他の方法論と見比べるのも面白そうな本です。

今回は APoSD と、APoSD 内で時折対比として触れられる Clean Code を取り上げ、共通していること・異なっていることを確認します。

この記事ではどちらが正しい、間違っている、という観点では取り上げず、取り扱っている意見についてのみ触れます。また片方のみで記載されているテーマは触れません。 加えて、各書籍で紹介されている概念や詳しい内容にも触れません。 既に片方を読んでいる方・読もうとされている方が、もう片方を読むきっかけになれば幸いです。

共通している部分

まずは共通している部分から確認します。

設計・クリーンなコード

どちらも設計もしくはクリーンなコードを重視するべき旨が記載されています。 (どちらもそのための本なので当然ではありますが)

共通して、設計を重視しない・粗悪なコードは長期的には生産性の低下をもたらすと述べています。

Clean Code

粗悪なコードによって生じる、経過時間における生産性の減少について触れています。

読者に対して下記の様に問いかけた上で、「有名で深い経験のあるプログラマ」に「クリーンコードとは?」と訪ねたときの回答を記載し、クリーンコードとは何であるかを提示しています。

コードがひどい状態のため、本来なら数時間で終わるような仕事に数週間かかった経験がありませんか?

APoSD

「Working Code Isn’t Enough」(動くコードは十分ではない)と述べた上で、「Tactical programming」(戦術的プログラミング)と「Strategic programming」(戦略的プログラミング)という概念を紹介しています。

APoSD では、戦略的に作業時間の 10-20%を投資に費やし、良いデザインを考えるべきだと述べています。 また、序盤においては戦略的なアプローチは戦術的なアプローチと比べて多くの時間を使うが、戦術的アプローチは時間の経過とともに複雑性によって生産性が低下するため、投資したコストは十分取り返せる、と述べています。

命名

命名に関しても両者で重要視されていることが伺えます。 どちらも命名だけで 1 つの章があり、大きく異なる内容は述べられていない印象です。

Clean Code

命名に関する具体的な tips を多く記載しています。

数が多いため全ては触れませんが、個人的に面白い(=明確に触れていて良い)と感じたのは下記 2 点です

  • 発音可能な名前を使用する

    名前は発音可能なものにしましょう。もしも発音可能な単語を使わないと、その単語について話をする際に間の抜けた音を発する必要があります。

  • 気取らない

    あまりに巧妙な名前を付けると、名前を付けた人と同じセンスとユーモアを共有する人にしか、覚えられないものになってしまいます。

APoSD

良い名前はコードを理解しやすくし、他のドキュメントの必要性が減り、エラーの検出が容易になる。一方で、不適切な名前はバグに繋がる可能性があると述べています。

Good names are a form of documentation: they make code easier to understand. They reduce the need for other documentation and make it easier to detect errors. Conversely, poor name choices increase the complexity of code and create ambiguities and misunderstandings that can result in bugs.

加えて、著者の過去の開発における変数名が起因のバグを例に上げつつ、名付けをするときの指針を提供しています。

また、著者とは違う意見として Go の style guide を取り上げています。

一貫性

どちらも一貫性を重要視しているように見受けられます。

APoSD では一貫性に関して 1 つの章があります。Clean Code では一貫性について取り上げた章はありませんが、名付けの章において一貫性を重視する内容が見受けられます。

Clean Code

「意味のある名前」という章において「1 つのコンセプトには 1 つの単語」「ごろ合わせをしない」と述べられています。 それぞれ、複数の単語を同じ意味で提供しないこと、1 つの単語を 2 つの目的で使用しないことが推奨されています。

APoSD

「Choosing Names」という章において、「Use names consistently」と述べられていることに加え、「Consistency」(一貫性)に関する個別の章があります。

一貫性の章では、似たようなことを同じように行うだけではなく、似てないことを異なる方法で行うべきだと明示されています。

Consistency means not only that similar things should be done in similar ways, but that dissimilar things should be done in different ways.

単体テスト

どちらも単体テストを重要視している印象です。

Clean Code

Clean Code では単体テストに関する章があり、TDD 三原則やクリーンなテストを書くための方法論が述べられています。

APoSD

APoSD では単体テストについて詳しく述べた箇所はありませんが、ソフトウェア開発のトレンドと APoSD で述べられている原則の関係についての章において、単体テストについて触れられています。

その項目ではソフトウェア開発における単体テストの重要性や、著者の過去の開発経験で単体テストが効果を発揮した例が紹介されています。

明確に意見が異なる部分

次に意見が異なる部分について確認します。

まずは APoSD 上で明確に Clean Code が対比として挙げられている箇所を確認します。

関数・メソッドの分割基準

APoSD の「Better Together Or Better Apart?」(一緒にしたほうが良いか分けたほうが良いか?)という章において、Clean Code が取り上げられています。

APoSD では、Clean Code 上で述べられている行数に基づいて関数を短くするべき※といった主張に対して異論を述べています。

※ Clean Code 上では関数の分割方法について「1 つのことを行う」「1 つの関数に 1 つの抽象レベル」などの行数以外の指針も出てくるのですが、行数についても深く言及されています。

APoSD では、コンポーネントが小さければ小さいほど個々のコンポーネントは単純になるが、一方で細分化前にはなかった追加の複雑さが生じると述べた上で、この本で紹介している「Shallow (Deep) Module」「Information Hiding (Leakage)」などの概念と絡めながらコンポーネントの分割方法に触れています。

コメントに対するスタンス

APoSD の「Why Write Comments? The Four Excuses」(なぜコメントを書くのか?4 つの言い訳)という章において、Clean Code が取り上げられています。

Clean Code 上では「よいコメント」「よくないコメント」が多数紹介されていますが、コメント自体は必要悪であり、コードでうまく表現することに失敗したときに使用するものであると述べています。

APoSD では良いソフトウェアはコメントの必要性が減ることについては同意した上で、コメントが提供する情報とコードが提供する情報は違い、それぞれ利点があると述べています。

また、APoSD では全 21 章のうち 3 つの章がコメントに関する章であり、コメントを重要視していることが伺えます。

明言はされていないが意見が異なる部分

最後に APoSD 内で明言はされていないまでも、意見が異なるもしくは若干方向性が異なっているものを確認します。

エラー処理

Clean Code

「エラー処理」という章では、「リターンコードではなく、例外を使用する」ことが推奨されています。

エラー処理によって本来のロジックを不明瞭にしないよう、例外を使用して本来のロジックとエラー処理を分離して整理する方法が紹介されています。

APoSD

「Define Errors Out Of Existence」という章において、例外を扱う難しさについて触れています。

しかし『リターンコードを使用すべき』のような Clean Code と真反対の意見を述べているのではなく、そもそも例外を無くす考え方や、例外を下位レイヤーで処理して上位レイヤーに伝えない考え方、上位レイヤーで例外を集約する考え方などが紹介されています。

TDDに対するスタンス

Clean Code

Clean Code では TDD が明確に推奨されているわけではありませんが、TDD 三原則を紹介していたりしばしば TDD について言及されているため、TDD に対して肯定的なスタンスを持っていることが伺えます。

APoSD

「Software Trends」という章において TDD について触れられています。 著者は、単体テストは強く支持するが TDD は好きではないと述べています。

TDDの問題点として、最適な設計を見つけることより、特定の機能を動作させることに注意が向けられがちで、戦術的プログラミングになると述べています。

まとめ

両者とも設計を非常に重要視しつつ、そのための How が異なるという印象でした。 しかし意見全てが異なるわけではなく共通して述べられている内容もあり、両者を読んで比較することで理解が更に深まったように感じています。 ぜひ両方読んでみていただきたいと思える内容でした。

参考文献

  • Robert C. Martin,花井志生. Clean Code アジャイルソフトウェア達人の技 (Japanese Edition). Kindle 版.
  • Ousterhout, John K. . A Philosophy of Software Design, 2nd Edition. Yaknyam Press. Kindle 版.