Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

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

ShirayanagiRyuji

January 27, 2021
Tweet

More Decks by ShirayanagiRyuji

Other Decks in Technology

Transcript

  1. 賛同者が集まらない
    俺流
    『リーダブルコード』
    白栁 隆司
    2021年1月27日
    リーダブルコードLT会

    View full-size slide

  2. 今回の趣旨
    ● SESいっぱい経験しました(約20年)
    ● 言語やコーディングルールが変わる中で得た知見
    ● 白栁の個人的なコーディング哲学
    ● それらをまとめて「俺流リーダブルコード」
    として公開します

    View full-size slide

  3. 自己紹介
    エンジニアカウンセラー 白栁 隆司
    Youtubeに平日毎日動画投稿中! #ほぼ日ITエンジニアニュース
    @IT 自分戦略研究所 エンジニアライフにて「コレがワタシの生きる様」連載中(木曜日)
    4つのことを、ITエンジニアに勧めてます
    1. 傾聴によるコミュニケーション
    2. メンタルヘルス(セルフケア)
    3. セルフマネジメント
    4. 日々の生活の中からエンジニアリングを学ぶ

    View full-size slide

  4. アジェンダ
    1. 何故リーダブルにするか
    2. 『リーダブル』のレベル
    3. コードにすべてを書く必要はない
    4. コードに書くべきもの
    5. 『リーダブル』に正解はない

    View full-size slide

  5. 1. 何故リーダブルにするか
    一般的に言われる「リーダルブル」な意味
    ● 他人が読んで理解しやすい
    ● メンテナンス性の向上
    ○ メンテナンスの工数の減少
    ● シンプルな方が故障率は低い
    ○ バグ発生頻度の減少

    View full-size slide

  6. 1. 何故リーダブルにするか
    一般的に言われる「リーダルブル」を嫌う理由
    ● めんどくさい
    ● 意識して書いてたら手が進まない
    ● 自分がわかればいい
    ● 一定の技術力があれば読めるから問題ない
    ● 「リーダブル」なんてもんわからん

    View full-size slide

  7. 1. 何故リーダブルにするか
    ある人は言った。
    「このシステムは自分か触らないから、
     自分だけが解るコードで書いておけばいいんだ」
    さて、これでいいのでしょうか?

    View full-size slide

  8. 1. 何故リーダブルにするか
    白柳「3日前に書いたコードは他人のコードと思え」
    金曜日に書いて、月曜日に読むと意味がわからない。
    そんなコードを書いた経験はありませんか?
    想像してください。
    半年後、一年後に書いたコードはどうなるか?

    View full-size slide

  9. 1. 何故リーダブルにするか
    僕がリーダブルにする唯一の理由
    だって、そっちの方が「めんどくさい」から。
    後で読んだときに脳みそ使いたくない

    View full-size slide

  10. 2. 『リーダブル』のレベル
    Lv0. コードが書けない人でも解る
    Lv1. チーム外の人でも解る
    Lv2. ベテランなら解る
    Lv3. (今の)自分が解る
    ※白栁独自分類による

    View full-size slide

  11. 2. 『リーダブル』のレベル
    Lv0. コードが書けない人でも解る
    極論ではあるが、流石にここまでする必要はない。
    コード内にコメントで仕様書の丸写しがあったり、
    1行ごとにコメントが有るレベルを想定。
    逆に読みにくい!!

    View full-size slide

  12. 2. 『リーダブル』のレベル
    Lv1. チーム外の人でも解る
    「チーム」とは、同じ言語・同じコーディングルールを共有す
    る集団のこと。
    一般的な「新人でも読めるコード」のレベル。
    理想論だがここを目指したい。

    View full-size slide

  13. 2. 『リーダブル』のレベル
    Lv2. ベテランならわかる
    業務知識なり、そのチームでの開発経験なりが一定量貯
    まるとスイスイ読めるようになるレベル。
    一般的なコードはだいたいこの辺り。
    つまり「習うより慣れろ」のケース。

    View full-size slide

  14. 2. 『リーダブル』のレベル
    Lv3. (今の)自分が解る
    もうコレは『リーダブル』とは言えない・言わない。
    「自分が読めるからいいだろ」は『読める』とは言わない。
    色々考えてる「今」だから解るだけ。
    10年後に同じコードをすぐ理解できるか?

    View full-size slide

  15. 3. コードにすべてを書く必要はない
    実装時に仕様書の概要をコメントで書くことはある。
    (忘備録代わりになるから便利:賛否ある案件)
    しかし、実装後にそれを全て残しておく必要はない。
    必要な部分を残し、不要な部分は削る。
    ドキュメント化用のコメント程度で十分。

    View full-size slide

  16. 3. コードにすべてを書く必要はない
    処理の詳細を理解しやすくするために、1行ずつコメントを
    書くか? → 逆に可読性を下げる。
    1行ずつ説明しないと理解できないなら、
    それはロジックが悪いということ。
    情報量が多すぎると可読性を下げる。

    View full-size slide

  17. 3. コードにすべてを書く必要はない
    プログラマは「全てのコードを意識する」必要はない
    システムに必要な全てのことを
         「コードに落とし込む」必要はない
    そして

    View full-size slide

  18. 3. コードにすべてを書く必要はない
    ライブラリや、外部処理のことはそれらに任せる。精々「○
    ライブラリに□処理を任せた」コメント。
    ライブラリの問題は、ライブラリ側が解決する。
    車輪の再発明は必要ないし、
    なんでもやりたがる必要もない。 FW全否定かよ

    View full-size slide

  19. 4. コードに書くべきもの
    1. ドキュメント化できるIFコメント
    2. 曖昧なものを明確化する為の手がかり
    a. ループ変数の命名をはっきりする
    b. boolean値の省略をしない
    c. 項ごとに括弧で括る
    3. 忘れるもの、間違えやすいものを明記する
    Javadoc とか DocComment とか
    SQLだと特に有用!

    View full-size slide

  20. 4. コードに書くべきもの
    1. ドキュメント化できるIFコメント
    Javadoc や DocComment 等、APIのIFをドキュメント化で
    きるもの。IDEと連動できるなら必ず書くべき!
    もし、なくても処理の前に1~3行程度で書い
    ておくと、とても便利。

    View full-size slide

  21. 4. コードに書くべきもの
    2. 曖昧なものを明確化する為の手がかり
    最初にコードを書いている時には意識できないもの。
    後で読み返すと曖昧な意味をもつことに気付く。
    予め手がかりを残しておくことで、
    後で迷うことを防ぐことができる。 習慣化しよう!
    多々ある。

    View full-size slide

  22. 4. コードに書くべきもの
    2-a. ループ変数の名前をはっきりする
    work や hoge 等、意味のない変数名の禁止はある。
    同じことをループ変数にも適用する。
    i, j, k, x, y, z 等は使わない。
    idx, index は状況次第?

    View full-size slide

  23. 4. コードに書くべきもの
    2-b. boolean値の省略をしない
    True / False の2値を持つ boolean型。
    この値を比較する時や演算の時は省略ができる。
    T/F値を条件式に明示する。
    論理否定式を使用しない。

    View full-size slide

  24. 4. コードに書くべきもの
    2-c. 項ごとに括弧で括る
    【項】とは、数式の最小単位 ※数学の項とは異なる
    計算する項ごとに括弧でくくれば、演算の優先順位等の意
    識を軽くできる。
    SQLだととても有用!

    View full-size slide

  25. 4. コードに書くべきもの
    3. 忘れるもの、間違えやすいものを明記する
    例えば「普通ならこうする」を意図して外した処理。
    「~の理由でこの処理にする」と書いておく。
    例えば、条件に応じてアクセス先が変わる時。
    条件とアクセス先を書いておけば確認が楽。

    View full-size slide

  26. 5. 『リーダブル』に正解はない
    Q. 万人に読みやすい文章はありますか?
    A. ありません。
     文字が多く細かく書かないと分からない人がいる
     絵本程度の文字量じゃないと読まない人もいる
    →「日本語の文章」でもこういう感じ。

    View full-size slide

  27. 5. 『リーダブル』に正解はない
    日本語より難しい「プログラムのコード」が
                 読みやすいわけがない。
    所詮は個人ごとの感覚。
    『リーダブル』=幻想

    View full-size slide

  28. 5. 『リーダブル』に正解はない
    正解がないからこそ、追い求めることができる。
    完璧がないから、その場ごとに対応を変える。
    他人に説明できるコードを書くこと。
    常に自問自答が必要。他人の力もアテにする。
    意識していれば変わる。意識することが大事!
    コードレビューしてみよう!

    View full-size slide

  29. まとめ
    個人ごとに『リーダブル』の基準が違うのだから、
    『俺流リーダブルコード』に
         賛同者が集まらないのは当然だと言える!
    だからといってやめるつもりはない。
    今後も自分を信じて続けていくだけ。 それぞれのリーダブル!

    View full-size slide

  30. ご清聴ありがとうございました
    エンジニアカウンセラー
    白栁 隆司
    このはてしなく遠いリーダブル坂をよ...
    @ShirayanagiRyuj

    View full-size slide