技術研究部 活動レポート 2022/07/28

発表（浅野さん）

第2回 リーダブルコードの要点と活用法

参考記事から 4 ～ 6 章を紹介

対象者：実務 1-3 年目の若手エンジニア、コードレビューの機会が増えてきた実装者
この勉強会の目的：
普段の業務ではコーディング規約に沿ってのコーディングをしているが、
リーダブルコードの概要を共有することで、コーディングをする上の参考にしてもらう。

4 章 美しさ

コードを書く上で美しさを意識することが大事

• インデントをそろえて適切に改行する

• フォーマッタを活用するのが better

5 章 コメントすべきことを知る

• コメントすべきではないこと

  • コードからすぐに推測できるようなこと

// ユーザープロフィールを取得する
const profile = getUserProfile();

• コメントのためのコメントをしない

// これはコメントアウトです
// ユーザープロフィールを取得する
const profile = getUserProfile();

• コメントすべきこと

  • 自分の考えを記録する。TODO、FIXME…など

• 読み手の立場になって考える

  • 処理の中にブロック単位で要約コメントを残す。
    処理を全て追わなくても処理の概要が理解できれば良くなる

6 章 コメントは正確で簡潔に

• 指示語（いわゆるこそあど言葉）の使用は避ける

× // データをキャッシュに入れる。ただし、先のそのサイズをチェックする
→「その」がデータ・キャッシュのどちらを指しているか不明
〇 //データをキャッシュに入れる。ただし、先のデータサイズをチェックする

• コードの意図を書く

×コードの処理をただコメントする
// ループ内で配列の中身を逆順に並び替える
→なぜ逆順に並び替えてるんだ？の謎が残る。何を意図して書かれたコードかわからないのでリファクタがしにくい

〇コードの意図を書く
// 値段が高い順に並び替える

発表（阿部さん）

AWS テクニカルサポートから学ぶトラブルシューティングの極意

参考記事から Step1 ～ Step2 を紹介

勘や経験に頼りすぎたトラブルシューティングによって問題解決のスピードが落ちてしまう

• 関係のない情報を調査（昨晩起きたエラーの調査のために、昨日全部の時間帯のログを漁る）

• 推測による曖昧な原因分析（前に似たことが起きたから今回もそこだろう…のような決めつけ）

系統的なトラブルシューティングのステップを取ることが大切

• Step1．問題発生個所の特定
  5W1H に沿って問題発生個所を特定をすることで適切に情報が整理できる

• Step2. 事実を基に仮設を立てて調査
  　仮説演繹法のアプローチ（演繹法と帰納法の組み合わせ）によって、事実＋仮説・予測・検証のサイクルを回して原因を絞り込む。

①観察による問題の発見
②問題に対する仮設を作る
③仮設から実験可能な命題である予測を演繹する
④予測を実験によって検証もしくは反証する
⑤実験結果に基づいて仮説を受け入れるか修正する
①の結論が正しいものとは限らないので、③～⑤で正しさを検証する必要がある

高岡先生のコメント

今回例に挙がったインフラの監視だけではなく、さまざまな場面で「仮説を立てて検証をしていく」プロセスは活用できる。
仮説を立てること自体も難しく経験や知識によって精錬されていくと思うので、日ごろから実践してみると良い。

所感（佐々木さん）

リーダブルコード勉強会

まさにエンジニア 2 年生ぐらいのときに超お世話になった書籍です。。
1 度読んだだけで身につけるというよりは、何度か読み返して都度コードに反映させて…をやっていくことで糧になっていく知識かと思うので、私も初心を忘れずやっていきたいと思います。

トラブルシューティングの極意

担当している案件での監視業務にすぐに取り入れられそうな内容でした！
エラーが出ているところが心配になってとりあえず見に行く…ではなく 5W1H による状況の整理を癖づけるようにしたいです。。