ソースコードの可読性とその競争優位性について
>100 Views
November 26, 25
スライド概要
ダイキン工業 アジャイル内製センターの外部登壇資料を掲載しています
関連スライド
各ページのテキスト
可読性 競争優位性 Generated by Chat GPT4 2024/5/13 Takeshi Morinibu
導入 本講演のゴール ソースコードの可読性がなぜ重要なのか腑に落ちてもらう 研究や分析においても有効な知見を持ち帰ってもらう アジャイル開発について身近に感じてもらう 2
導入 • 森鳰武史（Morinibu Takeshi） • 経歴 • 2016 - 2019：データサイエンティスト（Python、R） • 2019 - 2024+：ソフトウェアエンジニア（Python、TypeScript） • 2020 - 2023：大阪大学 博士後期課程 森田研（データ包絡分析法） • 所属等 • アジャイル内製化チーム/ チームリーダー • バックエンド、フロントエンド、インフラ、テスト 3
導入 • 2022.11 EdgeTech+ 2022 「未経験のITエンジニアがアジャイル開発で内製化したら大変な目にあった話」 • 2023.06 JaSST'23 Kansai. 「ゼロからはじめるカオスエンジニアリング」 • 2023.07 開発生産性カンファレンス 「大手製造業のアジャイル開発促進」 • 2024.01 RSGT 2024 「激録・開発密着10ヶ月！！〜消えたスプリントゴールの行方〜」 • 2024.03 JaSST Tokyo 「QA不在のスクラムチームは品質改善の夢を見るか」 ※チーム全体ではさらに多くのカンファレンスに登壇 4
導入 本発表の動機と背景 • 修士⇨企業研究⇨（企業開発、博士課程）⇨企業開発 • 企業研究、コーディングに課題はないと思っていた • 企業開発、コーディングの課題を発見 https://github.com/NibuTake/ • 博士課程、研究に対する継続的開発のスキルの有効性を実感 開発経験がない人にもこの有効性を伝えたい 5
アジェンダ 前半 ‣ コードの可読性 ‣可読性の重要性 ‣過不足のない情報（長期記憶） ‣認知負荷（短期記憶） ‣ワーキングメモリの節約 後半 ‣継続的開発 ‣ユビキタス言語 ‣アジャイル開発 ‣競争優位性 ‣Q＆A 6
なぜコードの可読性が重要？
プログラマーは 何に一番時間をつかっている？
コードの可読性 可読性の重要性 プログラマーの約60%の時間は、コードの理解に費やされる > ̶̶ Measuring Program Comprehension: A Large-Scale Field Study with Professionals. IEEE Transactions on Software Engineering (2018) Our study nds that on average developers spend ~58 percent of their time on program comprehension activities, ... ▶︎ fi https://ieeexplore.ieee.org/document/7997917 9
コードの可読性 可読性の重要性 読む時間が多いなら読みやすさの改善は効果的 > ̶̶ 『ハッカーと画家』 ソフトウェアは、それを見ればすぐに使い方がわかるものであるべきだ。だ から、良いソフトウェアを書くには、ユーザがどれだけ何も知らないかとい うことを理解する必要がある。 ユーザーに対する共感だけでなく、コードを読む人に対する共感も必要だ。 それはあなた自身のためでもある。あなた自身もあなたのコードの読者だか らだ。 読む人に対する共感が読みやすさにつながる ▶︎ 10
コードの可読性 可読性の重要性 なんのためにコードを理解する必要があるのか コードに変更を加えてより価値を高めるため ▶︎ https://github.com/NibuTake/PyDEA/pull/16 11
コードに変更を加える
コードの可読性 可読性の重要性 広義の意味では頻繁にコードを変更（追加）している • たとえば • 分析結果を可視化する • 可視化の観点や設定を変える • 学習モデルの機能を改善・追加する • 分析や学習モデルに前処理を加える ソフトウェアに限らず、研究や分析も変更を伴う ▶︎ 13
コードの可読性 可読性の重要性 より広義の意味では常にコードは理解され変更されていく 書いたコードに基づいて（理解して）次の行を書く（変更する）ため ▶︎ 14
コードを書くのが 速いプログラマーとは？ Generated by Chat GPT4
コードの可読性 可読性の重要性 読みやすい（扱いやすい）コードを書く開発者とも言える > ̶̶ 『レガシーコードからの脱却』 最高の開発者がいちばんきれい好きな開発者であることに気づいたとき、 私はびっくりした。速いプログラマーは雑なプログラマーだと思っていた からだ。だが、実際は正反対だった。 私が会った中で最速のプログラマーは、コードを扱いやすいように保つこ とに特に注意を払っていた コードの品質を高く保っていた「にも関わらず」速いのではない。 コードの品質を高く保っていた「からこそ」速いのだ。 ▶︎ https://amzn.asia/d/dEZn5lq 16
コードの可読性 可読性の重要性 すこし辛辣な指摘もある > 事実は、短期的にも長期的にも、崩壊したコードを書くほうが クリーンなコードを書くよりも常に遅い ▶︎ https://amzn.asia/d/iHvYExL https://twitter.com/voluntas/status/1014316381041381376 17
コードの可読性 可読性の重要性 コードを扱いやすいように保つ、とは • ソースコードの情報量に過不足がない ‣ 長期記憶に関連 • コードを読む際に認知負荷が少ない ‣ 短期記憶（認知負荷）に関連 • 設計など（今回のスコープ外） ▶︎ https://learning.oreilly.com/library/view/the-programmers-brain/9781617298677/ 18
コードの可読性 可読性の重要性 コードを扱いやすいように保つ、とは ソースコード St 規約 R Filter 短期記憶 Lt 長期記憶 （スキル） ワーキングメモリ コーディング F(St, R, Lt, . . . ) = St+1 規約とスキルの質を上げて、ソースコードの質を上げる ▶︎ 19
過不足のない情報
誰かから コードを 引き継いだ経験 Generated by Chat GPT4
長期休み後に 自分が書いたコードが 理解できなくなった経験 Generated by Chat GPT4
コードの可読性 過不足のない情報 三ヶ月前の自分 = 他人、説 他人度合い 長期記憶情報量 書いた当初 頭の中にしかない情報量 他人 ソースコードに 情報量が不足している！ 自分 時間 今 三ヶ月後 ▶︎ 23
コードの可読性 過不足のない情報 例）コード化されていない記憶情報 • statusとは何？ • processとは何？ • statusとusernameを更新するのは何 を示していたのか ▶︎ 24
過不足のない情報 例）コード化されていない記憶情報 • statusとは何？ is̲bookedとして具体化 • processとは何？ resetとして具体化 • statusとusernameを更新するのは何 を示していたのか 関数化して処理を閉じる 25 ▶︎ ▶︎ ▶︎ ▶︎ コードの可読性
コードの可読性 過不足のない情報 1. コメント • コメントのデメリット • 実装と齟齬が発生し得る • 無意味な情報になり得る コメントは実行され得ないコード ▶︎ 26
過不足のない情報 1. コメント • コメントのデメリット • 実装と齟齬が発生し得る 処理の内容は書かない コメント以外で可読性を高める • 無意味な情報になり得る 直交していない情報は消す Whyを書く コメントにはコードに記載されていない情報を残す 27 ▶︎ ▶︎ ▶︎ ▶︎ ▶︎ コードの可読性
コードの可読性 過不足のない情報 1. コメント ＞̶̶ 『レガシーコードからの脱却』 コードはそれ自体で表現されているべきである。追いかけやすくて明確な名前 や一貫したメタファーを使うことで実現する。 過度なコメントは良い品質のコードを書いていない言い訳になる。 ▶︎ 28
コードの可読性 過不足のない情報 2. 命名 • 不適切な命名の影響 • 認識齟齬を発生させ得る • 無意味な情報になり得る 抽象的、広い命名は意図しない使われ方を招く ▶︎ 29
過不足のない情報 2. 命名 • 不適切な命名の影響 • 認識齟齬を発生させ得る 誤解のない表現を用いる • 無意味な情報になり得る 名前に意味を込める 最善の名前は誤解されない名前である 30 ▶︎ ▶︎ ▶︎ コードの可読性
コードの可読性 過不足のない情報 2. 命名 ＞̶̶ 『レガシーコードからの脱却』 プログラムにおいていちばん重要なドキュメントは、ソフトウェア自身だ。エ ンティティやふるまいには、どうやってやっているかではなく、何をやっている かを示す名前をつける。意味のある名前を保ち、メタファーは一貫したものに する。こうすることで、ソフトウェアは理解しやすく扱いやすくなる。 ▶︎ 31
コードの可読性 過不足のない情報 3. 型 • 型がない場合 • 存在しないメソッドに気づかない • 引数の中身が想定し辛い 構造の情報は容易に失われ得る ▶︎ 32
コードの可読性 過不足のない情報 3. 型 • 型がある場合 • 補完で全て完了する • 引数の中身が想定できる 構造をソースコードに埋め込む ▶︎ 33
コードの可読性 過不足のない情報 3. 型 ＞̶̶ 『プログラマー脳〜優れたプログラマーになるための認知科学に基づく アプローチ〜』 ハーネンベルグ氏の実験では、コンパイラがエラーを指摘した場所は、動的型付 けの言語で書かれたコードにおいて、実行時にクラッシュする場所と同じであ ることが多かったのです。そしてもちろん、コードを実行するほうがコンパイル よりも時間がかかるので、実行時のエラーに頼ると開発速度は遅くなってしま います。 ▶︎ 34
コードの可読性 4. まとめ 過不足のない情報 情報量に過不足がない表現 表現したい情報 表現したい情報 命名 コメント 命名 コメント 型 過剰 型 不足（長期記憶が補完） 命名、コメント、型で情報を線型独立に表現するイメージ ▶︎ 35
コードの可読性 4. まとめ 過不足のない情報 情報量に過不足がない表現 • ̶̶ 『達人プログラマー』 DRY（Don't Repeat Yourself）原則 「すべての知識はシステム内において、単一、かつ明確な、そして信頼できる 表現になっていなければならない」 多くの人々はこれがコードの話だと受け止めてしまったのです。... DRY原則は「知識」や「意図」の二重化についての原則です。つまり、異な った場所に同じことを表現するという問題を避けるための原則です。 ▶︎ 36
コードの可読性 過不足のない情報 補足：コメントの過不足について Mutually Exclusive, Collectively Exhaustive (MECE) ▶︎ https://twitter.com/t̲wada/status/904916106153828352 https://amzn.asia/d/9MmxhPZ 37
コードの可読性 過不足のない情報 補足：コメントや命名についてはこの本 ▶︎ https://amzn.asia/d/cUbuor9 38
認知負荷 Generated by Chat GPT4
コードの可読性 短期記憶（認知負荷） 二種類の認知負荷 • 構造的なアンチパターン（コードの臭い） • 1999年、Martin Fowler氏が使い始めた • バグを起こす可能性が高い※ • 言語的なアンチパターン • Venera Arnaoudova氏によって定義された • 構造的なアンチパターンより認知負荷が高い ※An empirical study of the bad smells and class error probability in the post-release object-oriented system evolution ▶︎ リファクタリング、※An empirical study of the bad smells and class error probability in the post-release object-oriented system evolution 40
コードの可読性 短期記憶（認知負荷） 言語的なアンチパターンの認知負荷 > ̶̶ 『達人プログラマー』 名前には深い意味があるという考え方には科学的な根拠があります。人間の 脳は単語を目にした際に、脳内における他のどんなアクティビティーよりも迅 速に知覚し、理解するという力を持っています。つまり、何かを近くしようと する際、単語は最優先で処理されるのです。これはストループ効果という有名 な現象でも示されています。 ストループ効果 赤 ▶︎ 41
コードの可読性 短期記憶（認知負荷） 広義（日常的）の言語的なアンチパターン 🆗 マック マクド マック M マインドマップとのギャップ ▶︎ 42
コードの可読性 短期記憶（認知負荷） 広義（コード的）の言語的なアンチパターン 🆗 Book Reserve マインドマップとのギャップ ▶︎ 43
コードの可読性 短期記憶（認知負荷） 言語的アンチパターンに対する対抗 > ̶̶ 『プログラマー脳〜優れたプログラマーになるための認知科学に基づく アプローチ〜』 コードレビューとその中で命名に関する指摘についての研究を行なったアラ ニマス氏も、よい命名について考察しており、よい命名を行うために最も重 要な考え方は、コード全体で一貫したルールで名前が付けられていることだ と述べています。 認知負荷を抑えるためには一貫したルールが効果的 ▶︎ 44
コードの可読性 短期記憶（認知負荷） 命名の自由度 • xに部屋の許容人数を示す変数名を与えてください ▶︎ 45
コードの可読性 短期記憶（認知負荷） 命名の自由度 • xに部屋の許容人数を示す変数名を与えてください • capacity • max̲occupancy • room̲size • occupancy̲limit • max̲capacity • room̲capacity • limit̲of̲people • number̲of̲people 色々な命名の可能性がある ▶︎ 46
コードの可読性 短期記憶（認知負荷） 何かの基準がなければ命名はバラつく > ̶̶ 『プログラマー脳〜優れたプログラマーになるための認知科学に基づく アプローチ〜』 フェイテルソン（Dror Feitelson）は、曖昧さのない名前を付けることがい かに難しいかを理解するために、ある実験を行いました。... この実験で、２人の開発者が同じ名前を選択する確率は非常に低く、変数、 定数、データ構造、関数、パラメータを合わせた47個の命名の対象に対し て、その確率の中央値はたった7%に過ぎませんでした。 命名のバラつきは問題なのか？ ▶︎ 47
コードの可読性 短期記憶（認知負荷） 命名のバラつきは可読性を低下させる • システム１とシステム２ • 利用可能に関する表現 • free̲room • • not is booked 検索性も落ちる ▶︎ 48
コードの可読性 短期記憶（認知負荷） 命名のバラつきは可読性を低下させる • 利用可能に関する表現 • 利用可能 = available • not is̲bookedを置き換え 統一された概念でコードが記載され整理される ▶︎ 49
なんらかの基準によって 一貫性をもたせたい
コードの可読性 短期記憶（認知負荷） 二種類の一貫性 • 作法の一貫性（例） • 真偽値は、is̲状態, has̲物, can̲動詞で表す • カウント値は、n̲任意で表す • 用語の一貫性（例） • 予約できる ⇨ 利用できる = available • 部屋の最大人数 ⇨ 許容人数 = capacity ▶︎ 51
コードの可読性 短期記憶（認知負荷） ソースコードを規約によって良い状態にしたい ソースコード St 一貫性 規約 型保護 R Filter 短期記憶 Lt 長期記憶 （スキル） 価値あるコメント ワーキングメモリ コーディング F(St, R, Lt, . . . ) = St+1 コーディング時に気にすることが多くなってしまう ▶︎ 52
ワーキングメモリを節約する Generated by Chat GPT4
コードの可読性 ワーキングメモリの節約 ワーキングメモリが占有されると重要な情報を見逃す • システム１とシステム２ • システム１＝直感、経験則 • システム２＝論理、注意力 人間が考えなくても良いことを、人間から分離する ▶︎ https://amzn.asia/d/eNReESw 54
コードの可読性 ワーキングメモリの節約 1. スペルチェック • Typoを防ぐ • TypoをWarningで表示 • 固有名詞は登録 • 割れ窓とならない運用 スペルミスに注意する ▶︎ ▶︎ https://github.com/streetsidesoftware/vscode-spell-checker SpellCheckerの状態を見る 55
コードの可読性 ワーキングメモリの節約 2. Formatter、Sort • ファイル保存時、スタイルで制約する • 最大行数 • 改行数 • Import 順 ルールを意識する 56 ▶︎ f ▶︎ https://github.com/astral-sh/ru 適当に書いて保存する
コードの可読性 ワーキングメモリの節約 3. Linter • ファイル保存時、脆弱な書き方を抑える • 未使用変数の削除 • 未使用Importの削除 • 同名変数、関数の再定義 脆弱な記法を探す 57 ▶︎ f ▶︎ https://github.com/astral-sh/ru Linterに怒られたら直す or 勝手に直る
コードの可読性 ワーキングメモリの節約 規約をワーキングメモリ以外で抑えていく ソースコード St 価値あるコメント 一貫性 規約 R Filter 短期記憶 Lt 長期記憶 （スキル） ワーキングメモリ コーディング F(St, R, Lt, . . . ) = St+1 アウトソース 型保護 （自動化） スタイル 重要な観点に注力して継続的に改善する ▶︎ 58
サイクル全体を 継続的に改善していく
継続的開発
継続的開発 一貫した共通言語 一貫性の観点から > ̶̶ 『ルールズ・オブ・プログラミング』 一貫性を保つための鍵は、全てが可能な限り機械的であることだ。チームで の命名規則が、主観的判断や熟慮を要するなら、そういう規則はうまくいか ない。別々のプログラマーは、別々の主観的判断をすることになる。そして、 全員別々の名前を付けることになるだろう。 みんなが自然に、同じ物には同じ名前を選ぶような、幸せなところにいる方 がマシだ。みんなのコードを扱うのがずっと楽になるからだ。 ▶︎ 61
同じ物には同じ名前を選ぶような 幸せなところ、とは
継続的開発 一貫した共通言語 ドメイン駆動設計 • ユビキタス言語（用語の一貫性） • ビジネス領域の専門家、開発者含めチーム全体で作り上げる共有言語 • 会話やコードにおいてもこの言語を用いる •例 • 予約可能 = 部屋が利用できる ＝ available • 部屋に入る人数＝許容人数＝capacity ▶︎ 63
継続的開発 一貫した共通言語 ユビキタス言語は成長し続ける • ̶̶ 『実践ドメイン駆動設計』 もっとも長期間ユビキタス言語の現状をきちんと表し続けるのは、チームでの 会話やコード内のモデルだ。 きちんと議論した上での合意と妥協を経て、そのプロジェクトにとって最善 の用語を見つけることになる。普段話す言語と同様、ユビキタス言語も常に 育ち続け、大なり小なりのブレイクスルーを経て変わっていく。 コード内のモデルを継続的にメンテナンスする必要性 ▶︎ 64
変更容易性 = ETC（Easy To Change）原則 • ̶̶ 『達人プログラマー』 名前の付け方がなぜ重要なのでしょうか？それは優れた名前はコードの可読性 を向上させ、変更時にはその名前を手がかりにする、つまりはETC原則です！ ものごとは、それを使う人に適応できる場合にうまく設計されていると言えま す。コードの場合、それは変化に対応できなければならないことを意味してい ます。このため、我々はETC（Easy To Change）原則を信じています。 ETC原則を実現するためには 65
アジャイル開発
認知負荷の低減 アジャイル • システム１とシステム２ • システム１＝直感、経験則 • システム２＝論理、注意力 人間が考えなくても良いことを、人間から分離する https://agilemanifesto.org/iso/ja/manifesto.html 67
継続的開発 アジャイル開発 V字モデルではドキュメント重視 R&D 開発者 受入テスト 要件定義 リリース 想定顧客 ベンダー 基本設計 結合テスト SE 詳細設計 開発者 単体テスト 実装 もとになった論文（Royce）の指摘は後工程にリスクを残すこと ▶︎ 68
継続的開発 アジャイル開発 ウォーターフォールモデルに対する反応 • ̶̶ 『ハッカーと画家』 プログラムの仕様に完璧さを期待するなんて非現実的だ。そのことをまず認め て、仕様がプログラムを書いている最中に変わっていっても、それを受け入れ られるような書き方をすべきなんだ。 （大企業の構造にはこれをやりにくくさせるものがあり、これもベンチャー企 業に利する点だ） ▶︎ 69
継続的開発 アジャイル開発 ウォーターフォールモデルに対する反応 • ̶̶ 『レガシーコードからの脱却』 まとめて何かをするのは非効率なだけでなく、さまざまなリリースサイクルの 流れを見るのも非効率であることも触れるつもりだ。こういうやり方は変更 不可能なものを作ることを強いられる。 結合を最後まで先送りにすると、成功するためにルーレットで10回連続して 勝たなければいけないのと同じことになる。 ▶︎ 70
継続的開発 アジャイル開発 V字モデルで修士論文を書くならこうなる 筆頭著者 ビルド 研究案 構成仕様 修論発表 仕様通りか 共著者B 文章仕様 共著者A 仕様通りか Tex実装 本番直前のはじめてのビルド一回に全てをかける？ ▶︎ 71
継続的開発 アジャイル開発 研究の進め方はアジャイル（分野による） ゼミ ゼミ ゼミ 中間発表 ゼミ 修論発表 筆頭著者 共著者A 専門用語による対話 教授 准教授 収益逓減 VRS ゼミでフィードバックを受け、修正して改善する ▶︎ 72
継続的開発 アジャイル開発 アジャイルでは協調・対話・動くソフトウェアを重視 R&D チーム リリース リリース リリース リリース リリース リリース 開発者 共通言語による対話 事業部門 オーナー 顧客 フィードバックを反映して小刻みにリリース ▶︎ 73
アジャイルは 大規模でもできるのか
継続的開発 アジャイル開発 大きいものを大きいまま開発しようとするなら、難しい > ̶̶ 『マイクロサービスアーキテクチャ』 システムを設計するあらゆる組織は、必ずその組織のコミュニケーション構造 に倣った構造を持つ設計を生み出す。 この記述は、「コンウェイの法則」としてさまざまな形で引用されています。 ...Net ixはこの例から学び、最初から小規模な独立したチームを中心とした構 成にし、作成したサービスも互いに独立するようにしました。 大きいものは適切な小ささに分ける ▶︎ fl 75
継続的開発 アジャイル開発 マイクロサービスアーキテクチャ > ̶̶ 『マイクロサービスアーキテクチャ』 マイクロサービスは、協調して動作する小規模で自律的なサービスです。 そして、このサービスが明示的な境界を念頭に置くようにすることで、サービ スを大規模にしすぎてしまう衝動とそれに関連して生じるすべての複雑さを回 避します。... 他にも、月並みですが「十分に小さく、ちょうどいい大きさである」と答え ることもできます。 ▶︎ 76
良い開発、悪い開発 そんなの人の勝手
継続的開発 アジャイル開発 アジャイルもDDDも銀の弾丸ではない > ̶̶ 『実践ドメイン駆動設計』 DDDを使おうとするときの最大の課題のひとつは、今までに比べて時間や労 力が余計に必要になることだ。... コンピューター用語を使いまくってコードを書いていくほうが、手間はかか らないだろう。でも、DDDをきちんと実践して最大限の事業価値を産み出し たいのなら、考える時間はさらに多く必要になる。まあ、そういうものだ。 以上。 トレードオフがあるからこそ競争優位性がうまれる ▶︎ 78
一つ一つの技術選定 組織文化の組み合わせで 最適なバリューチェーンを形成
継続的開発 競争優位性 競争優位性、優れた戦略の条件 • 特徴ある価値提案 • ライバル企業とは異なるトレードオフ • 長期にわたる継続性 • 特別に調整されたバリューチェーン • 適合性 戦略＝競争を避けるためのもの ▶︎ https://amzn.asia/d/hCtefDa 80
競争優位性 競争優位性、優れた戦略の条件（例） • 特徴ある価値提案 コアドメインの選び方 • ライバル企業とは異なるトレードオフ コアドメインに投資すること（ドメイン駆動設計） アーキテクチャ（マイクロサービス） プログラミング言語選定 • 長期にわたる継続性 アジャイル開発 https://amzn.asia/d/hCtefDa ▶︎ ▶︎ ▶︎ ▶︎ ▶︎ ▶︎ 継続的開発 81
競争優位性 競争優位性、優れた戦略の条件（例） • 特別に調整されたバリューチェーン チームに適応したプラクティス（ペアプログラミング） リリースまでのフロー（CICD） • 適合性 シナジーのある選択 https://amzn.asia/d/hCtefDa ▶︎ ▶︎ ▶︎ ▶︎ 継続的開発 82
戦略性をもって 可読性を高める
さいごに プログラマーとしてのスキルを高めるには ＞一番重要で一番やっかいなスキルはシステムを設計するための判断力だ。限 りなくシンプルなデザインというのはなかなか教えられるものではなく、大 方経験を重ねて覚えるものだ。 ＞この「判断力」は、プログラマーにとって非常に重要なのだが、そう簡単 に教えられるものでもない。ぼくが知る限り、判断力をつける一番の方法 は、自分で設計したシステムを長い間メンテすることだと思う。 フェイスブックのエンジニアで史上ベスト３に入るといわれる Evan Priestley氏 https://knoh.jp/answers/d65c7a82/ 84
Q&A Generated by Chat GPT4 2024/4/16 Takeshi Morinibu