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

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

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

読み終えるまで約3分

 

 

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

今回も、プログラミングに関する投稿です。

 

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

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

 

前回記事の続きとなっています↓↓↓ 

 

chan-naru.hatenablog.com

 

 

 

 

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

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

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

  1. コーディング規約を自動化する(No. 4)
  2. 美はシンプルさに宿る(No. 5)
  3. リファクタリングの際に注意すべきこと(No. 6)

 

①コーディング規約を自動化する

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

「チームのみんなでコーディング規約を守り、開発プロセスを円滑に進めよう。コーディング規約の適用を自動化することで、適用漏れをなくすのが良い。」

ということです。

 

以下、要約です。

 

何か新しいプロジェクトを開発する際、最初にコーディング規約を設けると思います。

もちろんチームの全員が規約を守るつもりで開発を進めていくでしょう。

しかし、完成したプログラムを見ると、所々規約が守られてないことが往々にしてあります。

 

なぜでしょうか…?

 

その理由は主に以下の通りです。

  • コーディング規約に無関心な人がいること
  • なぜ規約が必要なのかを理解してない人がいること
  • 規約が明文化されていないこと
  • 規約のコードへの反映を手動でやろうとしていること

対策としては、コーディング規約の重要性・有効性をチーム全体に説明することや、ドキュメントにまとめて共有すること、自動コード整形ツールの導入が挙げられます。

 

コーディング規約を守ることは、どんなメリットがあるのでしょうか?

それは、チーム全体の開発速度が向上することです。

 

規約を守ると、どのプログラムを見ても同じような記述の仕方になっており、自分が書いたプログラムを他者が見る場合や、他者が書いたプログラムを見る場合にすんなり理解できるようになります。

チーム全体の生産性向上につながるのです。

 

1つ覚えておいて欲しいことがあります。

 

それは、『コーディング規約は固定的ではなく、変化していくべき』ということです。

プロジェクトが進むにつれて、そのプロジェクトへの要求も多様化するでしょう。

プロジェクト立ち上げ時に賢明と思っていたことが数ヶ月後にそうではないということがあるのです。

 

②美はシンプルさに宿る

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

「シンプルなコードに勝るものはない。」

ということです。

 

以下、要約です。

 

プログラマがコードを書く際に留意すべきことはいくつかあるが、まとめると次のようになります。

  • 可読性
  • 保守性
  • 開発効率
  • 美しさ

4つ目の『美しさ』とは何でしょうか?

これは『シンプルさ』です。

 

著名なプログラマの作るオープンソースソフトウェアのソースコードを眺めてみてください。

Githubで探すといいでしょう)

きっと、「シンプルで美しい!」と感じることでしょう!

 

美しい、シンプルというのは主に主観的判断となりますが、本書では以下のような主張がされています。

メソッドのコードはどれも5行から10行くらいの長さにすべき

(本書11ページより)

言語によってはこの長さの範囲に収めるのが難しい場合もあるでしょう。

しかし、極力収めようとすることが大切です。

 

シンプルで綺麗なコードは、テストがしやすく、開発速度を落とさずに長期にわたる運用・保守がしやすいです。

 

リファクタリングの際に注意すべきこと

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

リファクタリングは必ず行うが、その際に意識するべきことがいくつかある。」

ということです。

 

以下、意識するポイント。

 

1. 初めにするべきは、既存のコードの確認とそのコードに該当するテストコードの洗い直し

2. ゼロから書き直したいと思っても、やらない

3. 一度に大幅な変更を加えず、少しずつの変更を数多くする

4. 各リファクタリング作業後には、必ず、既存のテストコードの動作確認をする

 

1の理由:

リファクタリングする際は、必ず既存のコードの粗探しをしてそれを修正します。

その際に、修正箇所のテストコードがあれば、必ず修正しましょう。

テストコードが更新されないままプロジェクトが進んでしまうということがあるのです。

 

2の理由:

過去の努力や時間が無駄になり、また、既存のコードでは気づけたはずのバグを気づけなくなってしまうからです。

既存のコードはコードレビューをくぐり抜けてきたものであるため、慎重に、大切に扱うべきです。

 

3の理由:

これはプログラミング全般に言えることですが、一度に大幅な変更をかけるのはNGです。

変更の一部にバグがあった場合、変更が多いとバグ探しが大変になります。

また、コードレビューにも時間がかかり、開発者たちの生産性を下げかねません。

 

4の理由:

1の理由でも触れましたが、既存のテストコードの修正忘れをする場合があるからです。

リファクタリングによって既存のテストが落ちる場合もあるでしょう。

しかし、この時やみくもに既存のテストを削除して新規のテストを追加してはいけません。

まずは、なぜ既存のテストコードが存在したのか、とその存在意義を見直してみましょう。

 

まとめ

①コーディング規約をチームの皆が守ることにより、チームの生産性が上がります。

そのため、メンバーの全員が『コーディング規約の意味』を理解する必要があります。

また、規約の遵守漏れが減るような仕組みづくり(リンターやフォーマッターの利用など)をしましょう!

 

②シンプルなコードが最も美しいです。

各メソッドは5〜10行にすることを意識してコーディングしましょう。

 

リファクタリングは必ずやる作業です。

既存のコードとそのテストコードの存在意義を考えるところからスタートです!

 

 

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

書籍情報

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

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

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

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

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

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

【出版社】オーム社

【出版日】2010年12月

【ページ数】243ページ