【ちゃんなるぶろぐ】社会人1年生が日々の学びをアウトプット!

>>> 読書・遊び・プログラミング・アプリ開発などを通して学んだことを、文章という形で出力 <<<

3分でわかる!「プログラマが知るべき97のこと」その⑩

読み終えるまで約3分

 

 

どうも、ちゃんなるです! 

今日も”デキる”プログラマになるべく勉強していきましょう!

 

今回は、次の書籍の一部を要約します。

プログラマが知るべき97のこと』

 

下の記事の続編です↓↓

chan-naru.hatenablog.com

 

 

 

今回選択した3つのテーマ

本書はタイトル通り97のことについて書かれています。

今回は、28~30番目の項目についてまとめます。

  1. 「魔法」に頼りすぎてはいけない(No. 28)
  2. DRY原則(No. 29)
  3. そのコードに触れてはならない!(No. 30)

 

①「魔法」に頼りすぎてはいけない

このテーマで述べられていたことは、

「自分の知らない仕事は無意識に簡単と思ってしまい、まるで「魔法」のように錯覚してしまいます。しかし、その魔法を見せてくれているのは他人の仕事ぶりであり、もしその魔法が溶けてしまえば他の誰かが直さなくてはならない。」

ということです。

 

以下、要約です。

 

他人のする仕事は、遠くから見ていると実際より簡単に思えてしまうものです。

自身が開発を経験していないマネージャは、プログラマの仕事を簡単だと思ってしまいます。

反対に、プログラマはマネージャの仕事を簡単だと思ってしまいます。

 

プロジェクトには必ず、我々プログラマが関わらない作業もたくさんあります。

例えば以下のようなものでしょう。

  • ユーザの要件を確認する
  • 予算を申請する
  • ビルドサーバーをセットアップする
  • QA環境や本番環境へのアプリケーションのデプロイをする
  • 業務プロセスやプログラムを新しいバージョンに移行する

自分の関わらない仕事は無意識のうちに簡単だと思ってしまい、まるで「魔法」のように自動的に行われているように錯覚してしまうのが私たち人間です。

その裏では担当者が必死に動き回っていることを知らずに…

 

全て順調なときはいいのですが、問題は『魔法が解けたとき』です。

途端にプロジェクトは滞り、混乱し、誰か別の人がその魔法を直さなくてはいけません。

 

自分の知らない仕事、自分の直接関わってない仕事をする人を敬いましょう!

これをチーム全体でお互いが意識することが大切です。

そして、忘れてならないのは、「魔法が解けてしまったら、誰かが直さなくてはならない」ということです。

 

 

DRY原則

このテーマで述べられていたことは、

DRY原則はシンプルかつ高品質で、保守もしやすいアプリケーションが作れるルールである。必ず守るようにしよう!」

ということです。

 

以下、要約です。

 

『DRY(Don't Repeat Yourself : 繰り返しを避けること)原則』は、プログラミングに関して守るべきとされている原則の中で、最も重要なものと言えます。

これはAndy HuntとDave Thomasが、著書『達人プログラマーの中で提唱した原則です。

 

開発者は、アプリケーションの中に何らかの『重複』があれば、それを排除する必要があります。

そのための以下の方法を知り、より綺麗なコードを書きましょう!

 

重複は無駄である

すべてのコードには保守が必要です。

どのコードも将来バグになる可能性を秘めているからです。

『重複』があると、コードベースが大きくなり、バグの危険性も高まります。

そうなると、開発に携わる人間がすすテム全体を把握することも難しくなるでしょう。

また、どこかに変更を加えた場合、それとロジックが同じ箇所も同様の変更が必要かどうかを確認しなければいけません

 

DRY原則を守れば、こういった問題を抑えることができます。

DRY原則を守ることは、「全ての知識はシステム内において、単一、かつ明確な、そして信頼できる表現になっていなければならない」という条件を満たすことを意味します。

 

作業の重複は自動化で防ぐ

開発作業の多くは『同じことの繰り返し』です。

DRY原則は、アプリケーションのソースコードだけでなく、開発作業にも適用すべきです。

そこで役立つのが自動化です。

例えば、テストは同じ作業の繰り返しになることが多いので、テストは自動化するべきです。

同様にソフトウェアのビルドも同じ作業の繰り返しかつ時間がかかります。

したがってビルドプロセスも自動化し、頻繁に走らせましょう。

手作業だと負担が大きいものは、自動化の対象になります。

 

ロジックの重複は抽象化で防ぐ

この重複にはたくさんの種類があります。

if-thenやswitch文が重複しているだけなら発見・解消は容易でしょう。

 

デザインパターンの多くは、アプリケーション内の重複を減らす、あるいは排除することを目的としています。

あるオブジェクトを使用するために整える条件がほぼいつも同じなら、Abstract FactoryパターンFactory Methodパターンを使用すればいいでしょう。

オブジェクトの振る舞いに様々な種類があり得る場合には、Strategyパターンを使用しましょう。

 

デザインパターンについて知りたい!」方は下記の記事を見てみてください。

*** デザインパターンについて記事を書く ***

 

また、DRY原則は、データベーススキーマなどの構造にも適用できます。

 

関連する原則

DRY原則に関連するものがいくつかあるので、下記に示します。

  • OAOO(Once and Only Once : 1度、ただ1度)原則:これはコードの機能、振る舞いについてのみ適用される原則。
  • OCP(Open / Closed Principle : 開放 / 閉鎖原則)原則:クラスなどのプログラム単位は、拡張に対して「開いて(open)」なければならず、修正に対しては「閉じて(close)」いなければならないという原則。
  • SRP(Single Responsibility Principle : 単一責任原則)原則:クラスに変更を加える理由は2つ以上存在してはならない(1つの変更の理由は常に1つでなければならない)という原則。

 

 

③そのコードに触れてはならない!

このテーマで述べられていたことは、

「たとえシステムのどこかが壊れても、本番環境でそれを修正しようとしてはならない。」

ということです。

 

以下、要約です。

 

開発システムをステージングサーバでテスト中に自分の書いたコードに問題が見つかってしまった。

それをテストマネージャから知らされる。

 

プログラマなら誰もが経験あると思います。

このときプログラマが思うのは、「どこが悪いか見当ついてるから、修正させて欲しい!」でしょう。

 

しかし、開発者がステージングサーバを触ってはいけないのです。

 

Webシステム開発プロジェクトの環境は、次のようにアーキテクチャ分割されているのが普通です。

  • 開発者のマシン上の、ローカル開発 / ユニットテスト環境
  • 統合テストを手動、あるいは自動で行う開発サーバ
  • 品質保証(QA)チームや顧客が受け入れテストを行うステージングサーバ
  • 本番環境

(本書60ページより)

大まかに、実務は上記のようになっているでしょう。

 

このような場合、開発者は開発サーバより後の環境に触れてはいけません。

開発者はローカルマシンで最善を尽くしてコーディングをします。

SCMへチェックイン後は開発サーバに配備させて、そこでテスト・修正を行います。

ここ以降、開発者はプロジェクトの進行を『傍観』しましょう。

コードをパッケージングしてQAチーム向けのステージングサーバに配備するのは、ステージングマネージャの仕事なのです。

 

まとめ

①私たちは、自分の知らない仕事を軽視しがちです。ですが苦労しているのは相手も同じ。自分の関わらない仕事をしている人を敬い尊重しましょう!

②アプリケーションの中から『重複』はすべて排除しましょう!DRY原則は徹底するべき!

③開発者が手を加えていいのは自身のローカル環境、ユニットテスト環境のみ!ステージングサーバ以降でも修正できると思ってはならず、ローカル/ユニットテスト環境の内側で最善を尽くそう

 

*より深く知りたい方は、ぜひ本書を手にとってみてください!

書籍情報

プログラマが知るべき97のこと [ ケブリン・ヘニー ]

価格:2,090円
(2021/5/13 11:12時点)
感想(1件)

【中古】 プログラマが知るべき97のこと /ケブリンヘニー【編】,和田卓人【監修】,夏目大【訳】 【中古】afb

価格:825円
(2021/5/13 11:12時点)
感想(0件)

【書籍名】プログラマが知るべき97のこと

【著者名】ケブリン・へニー、夏目大(訳)

【出版社】オーム社

【出版日】2010年12月

【ページ数】243ページ