賛同者が集まらない俺流『リーダブルコード』

2021年1月27日 リーダブルコード LT会 での登壇時に使用した資料です。
https://rakus.connpass.com/event/199845/

『リーダブルなコード』について、【俺流】の考え方をまとめています。

Transcript

1. 賛同者が集まらない 俺流 『リーダブルコード』 白栁 隆司 2021年1月27日 リーダブルコードLT会
2. 今回の趣旨 • SESいっぱい経験しました（約20年） • 言語やコーディングルールが変わる中で得た知見 • 白栁の個人的なコーディング哲学 • それらをまとめて「俺流リーダブルコード」 として公開します
3. 自己紹介 エンジニアカウンセラー　白栁 隆司 Youtubeに平日毎日動画投稿中！ #ほぼ日ITエンジニアニュース @IT 自分戦略研究所 エンジニアライフにて「コレがワタシの生きる様」連載中（木曜日） ４つのことを、ITエンジニアに勧めてます 1. 傾聴によるコミュニケーション 2. メンタルヘルス（セルフケア） 3. セルフマネジメント 4. 日々の生活の中からエンジニアリングを学ぶ
4. アジェンダ 1. 何故リーダブルにするか 2. 『リーダブル』のレベル 3. コードにすべてを書く必要はない 4. コードに書くべきもの 5. 『リーダブル』に正解はない
5. 1. 何故リーダブルにするか 一般的に言われる「リーダルブル」な意味 • 他人が読んで理解しやすい • メンテナンス性の向上 ◦ メンテナンスの工数の減少 • シンプルな方が故障率は低い ◦ バグ発生頻度の減少
6. 1. 何故リーダブルにするか 一般的に言われる「リーダルブル」を嫌う理由 • めんどくさい • 意識して書いてたら手が進まない • 自分がわかればいい • 一定の技術力があれば読めるから問題ない • 「リーダブル」なんてもんわからん
7. 1. 何故リーダブルにするか ある人は言った。 「このシステムは自分か触らないから、 　自分だけが解るコードで書いておけばいいんだ」 さて、これでいいのでしょうか？
8. 1. 何故リーダブルにするか 白柳「３日前に書いたコードは他人のコードと思え」 金曜日に書いて、月曜日に読むと意味がわからない。 そんなコードを書いた経験はありませんか？ 想像してください。 半年後、一年後に書いたコードはどうなるか？
9. 1. 何故リーダブルにするか 僕がリーダブルにする唯一の理由 だって、そっちの方が「めんどくさい」から。 後で読んだときに脳みそ使いたくない
10. 2. 『リーダブル』のレベル Lv0. コードが書けない人でも解る Lv1. チーム外の人でも解る Lv2. ベテランなら解る Lv3. (今の)自分が解る ※白栁独自分類による
11. 2. 『リーダブル』のレベル Lv0. コードが書けない人でも解る 極論ではあるが、流石にここまでする必要はない。 コード内にコメントで仕様書の丸写しがあったり、 1行ごとにコメントが有るレベルを想定。 逆に読みにくい！！
12. 2. 『リーダブル』のレベル Lv1. チーム外の人でも解る 「チーム」とは、同じ言語・同じコーディングルールを共有す る集団のこと。 一般的な「新人でも読めるコード」のレベル。 理想論だがここを目指したい。
13. 2. 『リーダブル』のレベル Lv2. ベテランならわかる 業務知識なり、そのチームでの開発経験なりが一定量貯 まるとスイスイ読めるようになるレベル。 一般的なコードはだいたいこの辺り。 つまり「習うより慣れろ」のケース。
14. 2. 『リーダブル』のレベル Lv3. (今の)自分が解る もうコレは『リーダブル』とは言えない・言わない。 「自分が読めるからいいだろ」は『読める』とは言わない。 色々考えてる「今」だから解るだけ。 10年後に同じコードをすぐ理解できるか？
15. 3. コードにすべてを書く必要はない 実装時に仕様書の概要をコメントで書くことはある。 （忘備録代わりになるから便利：賛否ある案件） しかし、実装後にそれを全て残しておく必要はない。 必要な部分を残し、不要な部分は削る。 ドキュメント化用のコメント程度で十分。
16. 3. コードにすべてを書く必要はない 処理の詳細を理解しやすくするために、１行ずつコメントを 書くか？ → 逆に可読性を下げる。 １行ずつ説明しないと理解できないなら、 それはロジックが悪いということ。 情報量が多すぎると可読性を下げる。
17. 3. コードにすべてを書く必要はない プログラマは「全てのコードを意識する」必要はない システムに必要な全てのことを 　　　　　「コードに落とし込む」必要はない そして
18. 3. コードにすべてを書く必要はない ライブラリや、外部処理のことはそれらに任せる。精々「◦ ライブラリに□処理を任せた」コメント。 ライブラリの問題は、ライブラリ側が解決する。 車輪の再発明は必要ないし、 なんでもやりたがる必要もない。 FW全否定かよ
19. 4. コードに書くべきもの 1. ドキュメント化できるIFコメント 2. 曖昧なものを明確化する為の手がかり a. ループ変数の命名をはっきりする b. boolean値の省略をしない c. 項ごとに括弧で括る 3. 忘れるもの、間違えやすいものを明記する Javadoc とか DocComment とか SQLだと特に有用！
20. 4. コードに書くべきもの 1. ドキュメント化できるIFコメント Javadoc や DocComment 等、APIのIFをドキュメント化で きるもの。IDEと連動できるなら必ず書くべき！ もし、なくても処理の前に1～3行程度で書い ておくと、とても便利。
21. 4. コードに書くべきもの 2. 曖昧なものを明確化する為の手がかり 最初にコードを書いている時には意識できないもの。 後で読み返すと曖昧な意味をもつことに気付く。 予め手がかりを残しておくことで、 後で迷うことを防ぐことができる。 習慣化しよう！ 多々ある。
22. 4. コードに書くべきもの 2-a. ループ変数の名前をはっきりする work や hoge 等、意味のない変数名の禁止はある。 同じことをループ変数にも適用する。 i, j, k, x, y, z 等は使わない。 idx, index は状況次第？
23. 4. コードに書くべきもの 2-b. boolean値の省略をしない True / False の2値を持つ boolean型。 この値を比較する時や演算の時は省略ができる。 T/F値を条件式に明示する。 論理否定式を使用しない。
24. 4. コードに書くべきもの 2-c. 項ごとに括弧で括る 【項】とは、数式の最小単位 ※数学の項とは異なる 計算する項ごとに括弧でくくれば、演算の優先順位等の意 識を軽くできる。 SQLだととても有用！
25. 4. コードに書くべきもの 3. 忘れるもの、間違えやすいものを明記する 例えば「普通ならこうする」を意図して外した処理。 「～の理由でこの処理にする」と書いておく。 例えば、条件に応じてアクセス先が変わる時。 条件とアクセス先を書いておけば確認が楽。
26. 5. 『リーダブル』に正解はない Q. 万人に読みやすい文章はありますか？ A. ありません。 　文字が多く細かく書かないと分からない人がいる 　絵本程度の文字量じゃないと読まない人もいる →「日本語の文章」でもこういう感じ。
27. 5. 『リーダブル』に正解はない 日本語より難しい「プログラムのコード」が 　　　　　　　　　　　　　読みやすいわけがない。 所詮は個人ごとの感覚。 『リーダブル』＝幻想
28. 5. 『リーダブル』に正解はない 正解がないからこそ、追い求めることができる。 完璧がないから、その場ごとに対応を変える。 他人に説明できるコードを書くこと。 常に自問自答が必要。他人の力もアテにする。 意識していれば変わる。意識することが大事！ コードレビューしてみよう！
29. まとめ 個人ごとに『リーダブル』の基準が違うのだから、 『俺流リーダブルコード』に 　　　　　賛同者が集まらないのは当然だと言える！ だからといってやめるつもりはない。 今後も自分を信じて続けていくだけ。 それぞれのリーダブル！
30. ご清聴ありがとうございました エンジニアカウンセラー 白栁 隆司 このはてしなく遠いリーダブル坂をよ... @ShirayanagiRyuj