限界プログラマーの備忘録

安心してぐっすり眠りたい

「ちょうぜつソフトウェア設計入門」読んでみた感想文

概要

タイトル:ちょうぜつソフトウェア設計入門――PHPで理解するオブジェクト指向の活用

詳細:SoftwareDesign誌での連載と技術アドベントカレンダー24回ぶんに収まらなかった関連知識を徹底解説。いわゆる「オブジェクト指向」と呼ばれる考え方から発展した分野は、どのようにソフトウェア設計の役に立つのかを、よく知られた原則、テスト駆動開発デザインパターンなどを通じて理解できる一冊です。

ちょうぜつソフトウェア設計入門――PHPで理解するオブジェクト指向の活用

この本に向いている人

  • 実務である程度プログラミングをしたことあるがいまいちオブジェクト指向の考え方をつかめていない人
  • 今より効率的な設計を行いたい人
  • 初心者⇒中級者のプロセスを歩んでいる人
  • 頭を整理した中級者や上級者

書籍目次

  1. クリーンアーキテクチャ
  2. パッケージ原則
  3. オブジェクト指向
  4. UML(統一モデリング言語)
  5. オブジェクト指向原則SOLID
  6. テスト駆動開発
  7. 依存性注入
  8. デザインパターン
  9. アジャイル開発

要約・感想

まとめ

SOLID・TDD・デザインパターン・クリーンアーキテクチャの目的を振り返ることができました。 「AとはBではない」という主張が多くアーキテクチャオブジェクト指向設計において 正解は存在しない(無数にある)が不正解は存在するのだと思います。

「リーダブルコード」からコードの品質を向上させる

はじめに

プログラミング初心者でも理解しやすく、実践的なアドバイスが詰まった「リーダブルコード」という書籍。コードを書く上で、可読性の重要性を理解しているものの、具体的にどうしたらよいかわからず、悩んでいる人も多いはず。本書は、そんな人に向けた、コードの可読性を向上させるための実践的なアドバイスが詰まった書籍です。

内容

1.コードの可読性とは何か

「リーダブルコード」における可読性とは、コードを読んだ人が、コードの意図や目的を理解しやすく、簡単に変更できることを指します。例えば、変数や関数の命名が適切であること、コメントが適切に記述されていること、コードの構造が見やすいことなどが挙げられます。

2.クリーンなコードの書き方

クリーンなコードとは、可読性が高く、理解しやすく、保守性に優れたコードのことを指します。クリーンなコードを書くには、適切な命名規則を使い、重複したコードを排除し、コメントを適切に活用し、コードを単純にするなど、明確でシンプルなコードを書くことが重要です。

3.コメントの書き方と活用法

コメントは、コードの可読性を高めるための重要な要素の一つです。コメントを書く際には、どのような情報を記述するか、誰がそのコメントを読むかを考慮し、適切な長さと詳細さで書きましょう。また、コメントはコードの理解を助けるために使われるべきであり、コードの動作を説明するために使われるべきではありません。

4.関数の書き方とベストプラクティス

関数は、コードを組織化し、再利用可能で保守性の高いコードを作成するために重要です。関数を書く際には、適切な名前をつけ、単一の目的を持ち、必要な引数を持つようにし、適切なエラー処理を実装することが重要です。

5.変数と定数の命名規則と活用法

変数と定数の命名規則は、コードの可読性と保守性に重要な影響を与えます。変数や定数の名前は、その目的を簡潔に説明し、明確かつ一貫した規則に基づいて命名する必要があります。また、変数のスコープを制限することで、コードの意図を明確にすることができます。

6.コードのレイアウトとフォーマットのベストプラクティス

コードのレイアウトとフォーマットは、コードの可読性を向上させるために重要です。適切なインデント、スペースの使用、改行の使用などを適切に行うことで、コードを見やすく、理解しやすくすることができます。

bad

def calculate_sum(num1, num2):
if num1 < 0:
    return None
result = num1 + num2
return result

good

def calculate_sum(num1, num2):
    if num1 < 0:
        return None
    result = num1 + num2
    return result
7.テストコードの書き方と活用法

テストコードは、コードの品質を向上させるために不可欠です。テストコードを書く際には、適切なカバレッジを持つようにし、テストの重複を排除し、必要なテストデータを用意することが重要です。 、適切な規則とガイドラインを設定し、コードの品質を保証することが重要です。また、フィードバックを行う際には、具体的で建設的なフィードバックを提供することが重要です。

8.コードレビューのベストプラクティス

コードレビューは、コード品質を確保するために重要な活動の一つです。コードレビューを行う際には、適切な規則とガイドラインを設定し、コードの品質を保証することが重要です。また、フィードバックを行う際には、具体的で建設的なフィードバックを提供することが重要です。

まとめ

「リーダブルコード」は、コードの可読性を向上させるために不可欠な要素について詳しく説明している書籍です。コードを書くだけでなく、保守やアップデートなどの作業を行うためにも、可読性の高いコードを書くことが重要です。この記事では、書籍から学べることと、具体的な目次と事例について説明しました。

プログラマーが知っておくべき「Clean Code」を読んだ

「Clean Code」を読むことで、プログラミングの世界で重要なコードの品質を高める方法を学ぶことができます。しかし、初心者にとっては、コードをどのように書くかについて混乱してしまうことがあります。そんなときは、すぐに人に聞くことができないかもしれません。本記事では、「Clean Code」の基本的な考え方とその具体的な活かし方について解説します。

  • はじめに:「Clean Code」とは何か?
  • 「Clean Code」を読む前に知っておくべきこと
  • コードの品質を高めるための「Clean Code」の原則
  • コードの品質を高めるための具体的な方法
  • 「Clean Code」の原則をチームで実践する方法
  • おわりに:「Clean Code」で高品質なコードを書こう

はじめに

はじめに、「Clean Code」とは何か?について説明します。コードが読みやすく、保守しやすく、品質が高いという条件を満たすコードのことを指します。このようなコードは、エラーが少なく、スムーズな開発やメンテナンスが可能で、コードの品質を向上させます。Clean Codeは、Robert C. Martinが書いた本で、プログラマーが良いコードを書くための具体的な指南書として有名です。

「Clean Code」を読む前に知っておくべきこと

「Clean Code」を読む前には、コードの基本的な知識や開発環境、コードの品質に関する知識を把握することが重要です。また、プログラミング言語フレームワークについても知っておく必要があります。このような基礎知識を持つことで、Clean Codeをより理解しやすくなります。

コードの品質を高めるための「Clean Code」の原則

Clean Codeには、コードの品質を高めるための原則があります。たとえば、「1つの関数には1つのことだけをさせる」という原則があります。この原則に従えば、コードがよりシンプルで読みやすくなり、保守性も高くなります。また、「DRY原則」(Don't Repeat Yourself)や、「KISS原則」(Keep It Simple, Stupid)などの原則もあります。

DRY原則

DRY原則は、Don't Repeat Yourself(同じことを繰り返さない)の略語であり、ソフトウェア開発において重要な原則の1つです。DRY原則は、コードやプログラムにおいて同じ機能やロジックを複数回記述することを避け、コードの再利用性を高め、バグの発生を抑え、保守性を向上させることを目的としています。具体的には、次のような方法でDRY原則を適用することができます。

  • コードの重複を避ける
  • ライブラリの活用
  • テンプレートエンジンの使用
  • データベースの正規化

DRY原則を遵守することで、コードの再利用性が高まり、コードの保守性が向上し、バグの発生を抑えることができます。しかし、過度なDRY化は可読性の低下やパフォーマンスの低下などを引き起こすことがあるため、バランスを考慮する必要があります。

KISS原則

KISS原則とは、「Keep It Simple, Stupid.(シンプルに保て、愚か者。)」という言葉の頭文字をとったもので、コードやシステムをシンプルに保つことが重要であるという原則です。複雑な問題に対して単純な解決策を見つけることが最も重要であるとされています。

特徴

  • シンプルさを維持することで、コードの可読性、保守性、拡張性が向上する。
  • 冗長なコードや不必要な機能を排除することで、コードの複雑さを減らすことができる。
  • 実装がシンプルな場合は、バグが少なくなり、テストやデバッグが容易になる。

アプローチ

  • 機能を最小限に抑え、最も単純な方法で問題を解決する。
  • コードやアーキテクチャをシンプルに保ち、複雑な機能やコンポーネントを追加する前に、簡潔な解決策を試す。
  • 設計や実装の段階で、無駄なコードや機能を排除する。
  • 複雑なアルゴリズムや機能を実装する前に、代替案を検討する。

コードの品質を高めるための具体的な方法

コードの品質を高めるためには、具体的な方法があります。たとえば、変数、関数、クラスの命名規則には、明確なルールを設定し、一貫性を持たせることが重要です。また、コメントやドキュメンテーションの書き方、コードのフォーマットやレイアウト、エラーハンドリングや例外処理などにも注意を払う必要があります。さらに、テストやテスト駆動開発リファクタリングアーキテクチャデザインパターンなどの技術もClean Codeには含まれています。

「Clean Code」の原則をチームで実践する方法

Clean Codeの原則をチームで実践するためには、コミュニケーションやコードレビューのプロセスを改善することが重要です。また、コード規約や、自動化されたテストの実行、コード品質の分析や測定、コード品質に関する議論を促進するためのツールの導入なども有効です。さらに、Clean Codeを実践するための研修やトレーニング、メンタリングプログラムを導入することも考えられます。

まとめ

「Clean Code」は、読みやすく、保守しやすく、品質が高いコードを書くための指南書です。基礎知識を持ち、コードの品質について理解し、原則や具体的な方法を実践することで、Clean Codeを実現することができます。また、Clean Codeをチームで実践するためには、コミュニケーションやコードレビューのプロセスの改善、ツールの導入、トレーニングやメンタリングプログラムなどが有効です。Clean Codeを実践することで、コードの品質を向上させ、開発プロセスを効率化し、ビジネス上の成功をサポートすることができます。

「達人プログラマー」を読んで変わった開発スタイル

中級プログラマーでも読める本の紹介です。 印象としてはいいプログラマーになるための技術の付け方や哲学が記されている印象です。 コードの品質向上のための手法、効果的なコミュニケーションの方法、プロジェクトの進行管理のヒントなど。

概要

達人プログラマー

「達人プログラマー」とは、アンドリュー・ハントとデイビッド・トーマスによって書かれたソフトウェア開発に関する書籍です。この本は、1999年に初版が出版され、その後も多くのプログラマーや開発者たちに読まれてきました。 この本では、ソフトウェア開発の観点から、プログラミングにおけるベストプラクティスや、効果的な技術とプロセスについて解説されています。特に、プログラミングにおいて必要な「技術力」と「人間力」の両方を身につけることを重要視しており、それをどのように実現するかについても詳しく解説されています。 また、本書には、世界中の優秀なプログラマーたちが、自分たちの開発経験や考え方について語ったエッセイが収録されており、多くの読者たちからは、この部分が本書の魅力の一つとして評価されています。 「達人プログラマー」は、ソフトウェア開発に関心のある人々にとって、重要な書籍の一つであり、多くのプログラマーたちにとって、プログラミングのスキルアップや開発手法の改善に役立つ教科書として読まれています。

割れた窓を放置しない

割れ窓理論 (Broken windows theory) は、社会学者ジェームズ・Q・ウィルソンとジョージ・L・ケリングによって1982年に提唱された犯罪学の理論です。 この理論は、環境における小さな問題が放置されると、その問題は悪化し、大きな問題に発展する可能性があると主張しています。 例えば、壊れた窓がある建物があると、周囲の人々はその建物に対する敬意を失い、さらなる荒廃が進んでいくという考え方です。 コード上のあらゆる負債や欠陥を放置していると、その問題は日に日に大きくなるということです。 中長期的に放置するなという話。リファクタリングやテストを書くことが大切なのだと思います。

良い設計を意識する

良い設計は悪い設計よりも変更しやすい easy to change (ETC) 設計を行うときには、「変更容易性」を常に意識が必要あると感じました。

繰り返さない

いわゆるDRY原則の話ですね。

DRY原則 (Don't Repeat Yourself principle) とは、ソフトウェア開発において、同じ情報を複数の箇所に書くことを避けるための原則です。つまり、コードやデータベースの設計など、あらゆる部分において、重複した情報を排除することを推奨します。

DRY原則は、以下のようなメリットがあります。

保守性の向上:同じ情報が複数の場所に書かれると、変更や修正が必要になった場合に、全ての場所を修正する必要があります。一方、DRY原則に従うと、情報が1か所にまとめられるため、変更や修正が必要な場合でも、修正箇所が1か所に絞られるため、保守性が向上します。

可読性の向上:コードやデータベースの設計がシンプル化されるため、可読性が向上します。

冗長性の排除:同じ情報が複数の場所に書かれることで、冗長な情報が発生するため、DRY原則に従うことで冗長性を排除することができます。

知識を身に着ける

常に学習し続けて、知識に投資をすることが大切です。

  • 毎年少なくとも1つの言語を勉強すること
  • 月に1冊技術書を読む
  • 講習を受講する

など

偶発的プログラミングをしない

なぜコードが動いているか理解せずに、テストや検証も問題なく行えてしまった場合の危険性について伝えています。 いわゆる思考停止でのコピペでのコーディングや教えられてたままにコーディングするような状態、元のコードの考えや変更する意味を理解してコーディングを行いましょう、というお話です。 開発現場ではコードレビューを積極的に行いなぜそうしたのか聞くこと、学習時間を自分で作ることで排除できるかもしれません。

まとめ

個人的に役立ちそう内容をまとめました。プログラマー職にかかっている人なら一度読んでみると面白いと思います。

「単体テストの考え方/使い方」を読んで、テストの質の向上に繋がった3つのポイント

概要

単体テストの考え方/使い方」という本は、単体テストについて詳しく解説している書籍です。この本では、単体テストの基本的な考え方や、テストケースの設計方法、テストフレームワークの使い方、テストの自動化方法などが詳しく説明されています。

また、本書では、単体テストの重要性やメリット、実施のタイミングや頻度などについても解説されています。さらに、実際のプロジェクトで単体テストを実施する上でのノウハウやベストプラクティスなども紹介されています。

この本は、単体テストを実施するための基本的な知識や技術を学びたい開発者や品質保証担当者にとって、非常に役立つ書籍です。また、既に単体テストを実施しているが、さらに改善を図りたいと考えている開発者や品質保証担当者にとっても、有益な情報を得ることができるでしょう。

単体テストの価値(目的)

本書の第2部では「単体テストとその価値」という名のもとでテストの価値について教えてくれる。その価値の4つの要因とは「退行に対する保護」「リファクタリングへの耐性」「迅速なフィードバッグ」「保守のしやすさ」である。詳細は割愛するが、これらの4つを考慮すると、そのテストの価値だけでなく保守のコストパフォーマンスみたいなものも見えてくる。現場でのテストカバレッジよりもこれらを考えるほうが、真に価値のあるテストを生むことができるのだと思う。

細かな悩み

本書の終盤では単体テストアンチパターンがいくつか紹介されている。その中では例えば、テストのために本番コードを変更してはいけない、と紹介されいて、実際に開発現場でそういう変更を(ずいぶん昔に)見たことがあるので笑ってしまった。また、その直前ではログ出力におけるテストや日時出力のテストなど個人的には気になるトピックが紹介されていた。

カバレッジに対する考え方

本書の序盤ではテストカバレッジに関する考え方が書かれている。カバレッジとは何か、意味があるのか→実際に参考指標ぐらいで考えたほうがいいのでは、というお話。コラムにはカバレッジ100%にしようとしたプロジェクトの末路が描写されていて楽しんで読めた。そういえば、カバレッジの目安は「ソフトウェア品質を高める開発者テスト」という本に7割くらいって書かれていたような気がする。

まとめ

開発現場で単体テストを書き続けているような初心者~中級者くらいの人には、より質のいいテストを書くことを目的としておすすめできる。

勉強会の意味

プログラマーという職業についてから「勉強会をしよう」という言葉を本やSNSでよく見かけるようになったので、その意味について考えてみた。 勉強会にもオンラインでやるのか、ハンズオンでやるのか、などいろいろ形式があると思うが基本誰かが発信することが多いと思う。 まずは勉強会に参加する側の視点で

概念を知る

技術的なことの勉強会では聞いたことない言葉を聞くことができる。これは自分が持続的に成長していくための種を得るということ。正直その詳細、中身までいちいち理解する必要はないのかなと思う。というのも、勉強会で新しく知ったことを改めて自分で勉強して必要であれば吸収するし、逆に不要なら捨てるので二度手間となる。どんだけ他人に勉強会で発信してもらおうと、結局その技術を手にするかどうかはその後の自分次第なんだと思う。

問題の解決

システム開発の現場で仕事を行っていると、経験不足的な理由で問題に衝突することがある。そんな時に勉強会で教えてもらえることは手段の一つとして解決方法につながることがある。

逆に発信側として

本当の勉強

勉強会というと全員が勉強してるような響きになるが、実際その中で最も勉強を行っているのは発表している人だと思う。というのも、発表する人は間違ったことを教えられないし、一定のストーリーのもとで参加者に知識を共有する必要がある。逆に言えば、よく勉強会の発表者になる人はその瞬間、本当に最も勉強している人なのではないだろうか。

発表の練習

どんな発表でも発表するときに、内容がどれだけよくてもストーリーやスライド資料次第でうまく伝わらないこともある。それを考えると、勉強会を通して場数を踏んで発表の練習をするのは、十分に意義があると思う。

まとめ

基本的には発信者に数多くのメリットがあると思う。となれば、大人数グループよりも少人数グループにして発信者の数を増やしたほうがメリットあるのかもしれない。

「良いコード/悪いコードで学ぶ設計入門」を読んで

概要

良いコード/悪いコードで学ぶ設計入門」という書籍は、著者が実際に開発プロジェクトで経験した良い設計と悪い設計の例を取り上げ、それらを比較することで、良い設計の原則を解説するというものです。具体的には、コードの可読性、保守性、拡張性、再利用性などの観点から、良いコードと悪いコードの例を示し、その違いや改善点を説明しています。

この書籍は、実践的な視点から設計の基礎を学びたいという人や、既存のコードを改善するためのアイデアを得たいという人にとって役立つと思われます。また、プログラマーのキャリアアップにもつながる重要なスキルの一つである設計の考え方を身につけたいという人にもおすすめです。

学べる事・得られる事

詳細

  • 特に名前の設計やオブジェクト指向を利用した設計パターン
  • 値オブジェクト・ファーストクラスコレクションやストラテジパターンを用いて凝集度(関心事のロジック)を高めて表現もわかりやすくする
  • 破壊的代入に対して完全コンストラクタでできる限り不変にしたい
  • 保守面でもテクニックが掲載されている
  • 「レガシーコード改善ガイド」などのスプラウトクラスが紹介
  • 80:20の法則や木こりのジレンマなども紹介

以下感想

  • 初心者から中級者にステップアップする段階なら参考になることが多いと感じた。 初心者から中級者になる段階とはコードは書けるが保守のしやすさがいまいちという段階。ここに書かれていることを実践することで、ロジックがばらつかなくなり凝集度が高くなると思う。凝集度が高いと、再利用性が高くなり保守しやすくなる。同時に表現豊かになりリーダブルになるように思う。

  • 悪魔を排除 「なんかよくわからないけどnullチェックする」「どんな値が入っているかわからないから改めて代入しておく」という対策。あるいはそんなこともせずに、予想しない不具合が発生させている現場もあるかもしれない。しかし、そもそもそうならないようにオブジェクトで表現したり、不変にすることで不穏な匂いさえ断ち切れるということ。名前も大切。

まとめ

保守力のステップアップには最適