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

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

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

読み終えるまで約5分

 

 

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

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

 

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

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

 

下の記事の続編です↓↓

chan-naru.hatenablog.com

 

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

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

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

  1. 単一責任原則(No. 73)
  2. 「イエス」から始める(No. 74)
  3. 面倒でも自動化できることは自動化する(No. 75)
①単一責任原則

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

「単一責任原則(SRP)は、『1つのサブシステムやモジュール、クラス、関数などに、変更する理由を2つ以上持たせてはいけない』ということである。これは各コンポーネントを独立してデプロイできる設計をする上で非常に重要な要素である。」

ということです。

 

以下、要約です。

単一責任原則(Single Responsibility Principle : SRP)は、いいデザイン設計の基本原則の一つで、「変更理由が同じものは一箇所に集め、違うもの同士は分ける」ということです。

1つのサブシステムやモジュール、クラス、関数などに、変更する理由が2つ以上あってはいけないということです。

 

下記は、ビジネスルール、レポート、データベースに関わるメソッドを持つJavaのクラス例です。

public class Employee {

    public Money calculatePay() ...

    public String reportHours() ...

    public void save() ...

}

このクラスは、3つのメソッドが全く違った理由によって変更される可能性があるため問題があります。

給与計算にかかわるビジネスルールに変更が入ればcalculatePayメソッドに変更が必要となり、レポートのフォーマットが変わるたびにreportHoursメソッドに変更が必要になり、DBA*がデータベーススキーマを変更するたびにsaveメソッドに変更が必要になります。

 

いいシステムデザインは、システムのコンポーネントがそれぞれ独立してデプロイできるようになっているデザインのことです。

独立してデプロイできるとは、あるコンポーネントに変更を加えたからといって、別のコンポーネントの再デプロイが不要であるということです。

 

先程のJavaクラスは、下記のようにコンポーネント分けしてはどうでしょう。

public class Employee {

    public Money calculatePay() ...

}

public class EmployeeReporter {

    public String reportHours(Employee e) ...

}

public class EmployeeRepository {

    public void save(Employee e) ...

}

 

*DBA:Database Administrator(データベース管理者)

データベース管理システム(DBMS)の導入や運用、記録されたデータの管理を行う人や職種のこと

②「イエス」から始める

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

「「ノー」ではなく「イエス」という返答から始めるだけで、物の見方が大きく変わり、仕事の進め方も変わってくる!」

ということです。

 

以下、要約です。

顧客に何かを要求された時、「ノー」前提で話を進める人がいます。

なんでもかんでも「イエスと言って顧客の言いなりになるわけにはいかないからです。

 

しかし、「イエスという返事の仕方にも多くの種類があるのはご存知ですか?

たとえば、誰かが「このアプリケーションのウィンドウを全部、円形で半透明にしてくれたら嬉しいんだけど」と言ってきたとします。こういう要望は、「バカバカしい」と即座に拒否することもできます。そうはせずに「どうしてですか」と尋ねるようにすると、その方がいい結果になることが多いのです。

(149ページより)

要望が出されたコンテキストがわかれば、新たな可能性に広がることがあります。

「ノー」から始めてしまうと、顧客の要望のコンテキストを理解できないでしょう。

「イエスというのは、何も顧客のいう通りに動くことではなく、顧客の要望にしっかり寄り添うということです。

要望を理解し、寄り添った結果「ノー」と言わざるを得ない場合もあるでしょう。

それでもいいのです。

 

「イエスから始めれば、人との対立は生まれず、協力関係が生まれるのです。

③面倒でも自動化できることは自動化する

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

「自動化できることは自動化すべし!」

ということです。

 

以下、要約です。

自動化できそうな作業があっても、わざわざ何度も同じ手作業を繰り返す人は少なくありません。

なぜでしょうか?

 

よくある誤解5つ:

  1. 自動化はテストだけのもの:なぜテストだけだと決める必要があるのでしょう?同じことの繰り返し作業はプロジェクトのあちこちに見つかるはずです。自動化をすれば、面倒な作業から解放されるだけでなく、作業時間が短縮され、正確さも増すのです。
  2. IDEを使っていれば自動化の必要はない:最近のIDEでは数多の設定パターンがあり得るので、完全に他者と同じ環境で開発してると言えない状況になります。しかし、「自分のマシンでは動いた、ビルドできた、テストを通った…」云々という言葉をよく聞きます。それではダメです。常に同じビルドを繰り返せるように、また全員のビルドを統一するために、AntやAutotoolsといった自動化システムを採用すべきです。
  3. 自動化のためには特殊なツールについて学ぶ必要がある:よく知られたシェル言語(bashPowerShellなど)が使えれば、自動化システム作成は可能です。
  4. 扱うファイルの形式によっては自動化できないこともある:Wordやスプレッドシート、画像ファイルなどは、確かに自動化が困難です。しかし、プレーンテキストやCSVXMLに変換することができ、これによって自動化が可能です。ほんの少し工夫するだけで作業を自動化できて効率が向上するのです。
  5. 忙しくて自動化のことまで勉強している時間はない:自動化は、bashやAntなどを十分に学んでからでないと不可能、というものではありません。自動化できる、自動化すべし、という作業が見つかるたびに都度知識を身につければ良いのです。

同じ作業を繰り返しているなら、それがいくら小さい単位でも自動化を検討してみてはどうでしょうか?

まとめ

①他のコンポーネントたちと独立させるメリットは大きい。そのためにSRPを徹底しましょう!

「イエスから始めることで、自分にはなかった考え方や物の見方を知ることができます!顧客のためだけでなく、自分やチームのためにも、「イエスから始めてみてはどうでしょう!

③自動化はしたほうが長い目で見て得です。同じ繰り返し作業は全て自動化しましょう!

 

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

書籍情報

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

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

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

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

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

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

【出版社】オーム社

【出版日】2010年12月

【ページ数】243ページ

 

***参考サイト***

DBA(Database Administrator)とは - IT用語辞典 e-Words