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

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

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

読み終えるまで約3分

 

 

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

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

 

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

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

 

下の記事の続編です↓↓

chan-naru.hatenablog.com

 

 

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

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

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

  1. バグレポートの使い方(No. 37)
  2. 余分なコードは決して書かない(No. 38)
  3. 最初が肝心(No. 39)

 

①バグレポートの使い方

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

「バグレポートは簡潔に書き、バグの存在とその詳細を周りに知らせるために活用しよう!」

ということです。

 

以下、要約です。

 

バグレポートには以下の3つのことは必ず記載しましょう。

  1. バグの再現方法と発生頻度
  2. 本来の仕様(バグがない場合の望ましい動作)
  3. 実際の動作(バグを含んでいる現状の動作)

 

バグレポートは書いた人の性格が反映されることが多いです。

詳細で簡潔なレポートを書けば評価されるでしょうし、怒りをぶちまけただけのレポートでは人格を疑われるでしょう。

 

バグレポートは誰かと対話するために書くものであり、バグのあるコードを批判するためのものではありません。

さらに、書くことで、バグについてより多くの情報を得ることも目的です。

 

バグレポートを書く際は、あれこれと情報を詰め込みすぎないように注意しましょう。

また、プロジェクトに関するバグレポートが増えてくると、それを誰かが探す手間が増えるので、レポートに適切に命名しましょう。

命名規則をチームメンバーで共通認識しておくことが有用です。

 

注意すべきことの一つとして、バグレポートの数は何かの基準ではないということがあります。

コードの行数が労力を表していないのと同じです。

バグレポートによって重要度や致命具合が違うのです。

 

これはなんのバグか、どのくらい致命的かが簡単にわかるように、レポートの内容を工夫しましょう!

 

 

②余分なコードは決して書かない

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

「今書いているコードは本当に必要か?を常に考えながらコーディングする。今不要なら書かない!」

ということです。

 

以下、要約です。

 

Less is more:より少ないことは、より豊かなこと

コードの一部を削除することで、コードベースの質が向上する場合が多々あります。

 

ですがこの場合、なぜ不要なはずのコードが書かれたのでしょうか?

どうやってコードレビューを通過したのでしょうか?

おそらく次のような理由でしょう。

  • 余計かもしれないが、面白そうだと思えた
  • 将来必要になると思った
  • 必要かどうか判断に迷った。顧客に確認すべきであったがそれを怠り、実装者の判断で書いてしまった
  • 余分な機能を正当化するため、議論を経ておらず、ドキュメントにも書かれていない要件をプログラマがでっち上げた(プログラマが要件を決めるのはだめ) 

これらを常に疑ってかかりましょう。

 

大事なことは、『今必要か?』を考え、『今は不要』なら書かないに徹することです!

 

 

③最初が肝心

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

「ソフトウェアやライブラリ、アプリケーションは最初が肝心。インストール・登録が面倒であったり、チュートリアルがわかりにくかったらいい製品でも使ってもらえない。」

ということです。

 

以下、要約です。

 

私たちが何かをするときは、費用対効果が重要になります。

いくら便利なものがあっても、それを使い始めるのに時間がかかる、面倒であると判断したら私たちは別の、”もっと簡単な”手段を探すでしょう。

 

ソフトウェアの場合は、まずインストールにかかる手間が大きな問題になります。

またインストールが楽というだけでなく、関連ファイルがどこに置かれるかがインストール前に一目瞭然であると助かります。

 

GUIベースのソフトウェアなら、私たちは”操作が簡単であること”を期待します。

ごく簡単な操作をするだけで、期待している結果を得られることが重要であり、それをインストール直後のチュートリアルで示してもらえると助かります。

 

ライブラリをインストールした場合には、readmeやクイックスタートガイドの類があると楽ですよね。

そこに数行の簡単なプログラム例が載っており、実行結果も明記される場合は重宝されるでしょう。

 

同じようなフレームワークが2つあり、両者がライバル関係にある場合、その両方をダウンロードする人は多いでしょう。

それらの優劣をつけるのは、『同じ結果を得るのに、どちらの操作が簡単か』でしょう。

ソフトウェアにはチュートリアルをつけることが多いでしょうが、その内容がわかりやすいかどうかも重要です。

チュートリアルに自分の抱える問題の解決策が書かれていれば、ユーザは喜びます。

バグレポートを提出してくれるかもしれませんし、ユーザの友達に「これいいよ!」とおすすめしてくれるかもしれません。

 

ライバル製品の方が僅かに性能が高いかもしれませんが、ユーザにとっては問題さえ解決できればそれでいいのです!

ユーザが製品を使い始める段階でつまづかないよう、十分に配慮がなされているかどうかが大切です!

 

 

まとめ

①バグレポートを書く目的は、『バグの存在、重要度を知ること、知らせること』です!詳細かつ簡潔に書きましょう!

 

『今必要』なものだけをコーディングする!『今不要』なものは決して書かない!

 

③製品は、それをユーザが使い始めるまでが第一関門

ここでユーザを困らせないように工夫しよう!

 

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

書籍情報

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

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

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

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

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

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

【出版社】オーム社

【出版日】2010年12月

【ページ数】243ページ