= 概要 : author 結城洋志 : institution 株式会社クリアコード : content-source 実践リーダブルコード : date 2022-11-02 : allotted-time 30m : theme clear-code = 全体の流れ * 概要と進め方の説明 * 実装 * 実装を交換、続きを実装 * 全体で結果を共有 == ノート まず最初に、全体の大まかな予定を示すが、ここはサッと流す。 進行の進行度合いによっては、実装作業の時間を長めに取る可能性があることを伝える。 = 講師紹介 (('tag:center'))(('tag:margin-bottom * 2')) 結城洋志（ゆうき ひろし）\n aka Piro * 株式会社クリアコード所属 * FirefoxやThunderbirdの\n 法人サポートに従事 * トラブルの原因や対策を探るため\n ソースコードを調査することが多い == ノート Mozilla FirefoxはWebブラウザー。 Mozilla Thunderbirdはメールクライアント。 開発元のMozillaは、企業ユーザーからのトラブル問い合わせなどに回答するサービスは提供していない。 そのため、クリアコードのような事業者が、ある意味で勝手にサポートサービスを行っている。 クリアコードは10人未満の小規模事業者で、エンドユーザーからの電話問い合わせに対応するといったビジネスはできないので、そうではなく、企業の情報システム担当者や、大学であればシステム管理者といったレベルの方が、ある程度までは自分達で対応した上で、それでもまだ分からないことを問い合わせる（エスカレーションする）先としてテクニカルサポートを提供している。 FirefoxもThunderbirdも、自分達が作っている物ではないし、作っている人達は企業ユーザーの実際の利用の仕方を知らないので、企業ユーザー向けの技術資料といった物も特にない。 よって、問い合わせを受ける度にソースコードを読んで調査することになる。 「リーダブルなコード」の恩恵を非常に強く受ける立場だと言える。 = アジェンダ * ((*講座の目的*))を確認 * リーダブルコードの\n ((*必要性*))を確認 * リーダブルコードの\n ((*実践方法*))を紹介 * 実践方法を((*練習*)) = 講座の目的 * 自分の開発チームに * (('note:注：個々人の話ではない')) * ((*リーダブルなコードが\n 当たり前な文化の作り方*))を * 持ち帰る (('tag:center')) (('note:→ 「解説」に書いていることの実践方法を学ぶ')) = 目的でないこと * 実践前の不安のケア * 「やる」と決めないと理解が進まない * テクニックをたくさん覚える * 難しいプログラムを実装する * 早解きや実行時性能の追求 * 奇抜な方法で目立つ = ワークショップ後 * ぜひ実践を！ * 今日の資料はすべて再利用可能 * チーム内で同じ講座を再現できる = 　 = そもそもの話 * リーダブルコードは\n なぜ必要か = リーダブルコードのニーズ チーム開発を\n 無理なく\n 続けるため = チーム開発でのニーズ * 既存のコードを読んで\n ((*素早く内容を把握したい*)) * 既存のコードに\n ((*素早く手を加えたい*)) * ((*開発速度*))を落としたくない = 読みにくいと開発が遅くなる * 既存のコードを\n 理解しにくいと…… * 修正・機能追加に時間がかかる\n (('note:（理解しないと変更できない）')) * 後退バグが発生しやすい\n (('note:（理解しないまま変更すると問題発生）')) (('tag:center')) →((*コストがかかる*)) = 時間が経つほど影響大 # image # src = images/readable-code-reasonability.svg # relative_width = 90 (('tag:center')) (('note:（注意：グラフではなく概念図です）')) == プロパティー : enable-title-on-image false == ノート 「保守性を犠牲にして開発する場合と、保守性を高く保って開発する場合に、曲線が交差する点（つまり損益分岐点）には1ヵ月くらいで到達する」と言われている。 1ヵ月という数字の出典： 質とスピード（2020秋100分拡大版） / Quality and Speed 2020 Autumn Edition https://speakerdeck.com/twada/quality-and-speed-2020-autumn-edition = つまり * 現実的なコストの範囲で * 既存のコードを継続的に、\n 無理なく改良・修正したい (('tag:center')) →なので、リーダブルコード = 　 = リーダブルコードの実践 (('note:どうすれば無理なく実践できる？')) = リーダブルコードの実践 コードを((*読む*))\n 習慣を作る = 読む？書くじゃないの？ * リーダブルコードを書くには\n コードを読むことが欠かせない * なぜ？ (('wait')) (('tag:center')) ↓\n 読まないと\n 何が「読みやすい」か\n 分からないから = 何が「良い」かは受け手の状況次第 * しょっぱいのが好きな人と\n 甘いのが好きな人で\n 「おいしい」の基準は違う * 自分はどんな味が好みか？ * 日常の運転とレースでは\n 「乗りやすい」の基準は違う * 自分はどんな乗り方をするのか？ = リーダブルコードも同じ * チームの状況によって\n 「リーダブル」の基準が違う = リーダブルコード 「読む人」が\n 読みやすいなら\n リーダブル = 読む人 * 多くの場合、いない * チームのコードを読んでいますか？ * 読む人（チームメンバー）毎に\n リーダブルの基準は違う * 背景が違うので当たり前\n (('note:（背景：使ってきた言語・今の知識）')) = チームでのリーダブル * 1つずつ見つけていくしかない * 各メンバーの読んだ感覚を\n チームで共有 * 既存の基準をベースにするのはアリ\n (('note:（基準：本の内容やコーディングスタイルなど）')) (('tag:center')) チームでのリーダブルコードは\n 育てていくもの = リーダブルの基準の育て方 * コードを読む文化を作る\n (('note:（最初の難関）')) * チームのコードの中から\n リーダブルなコードを見つける * リーダブルなコードを\n チームで共有 * ↑の繰り返しで基準を増やす = コードを読む文化を作る * まず自分が読み始める * 仲間がいると心強い * リーダブルなコードを探す * 読みにくいコードは今は置いておく\n (('note:（チームにコードを読む文化ができてから！）')) * 見つけたリーダブルなコードは… = リーダブルなコードは… * 他のメンバーに共有する\n (('note:（例：話しかける。チャットに書く。Wikiにまとめる。）')) * 「○○さんの△△という書き方、\n 　◇◇な所がリーダブルですね」 (('tag:center')) ↓\n 読みやすさの基準を共有\n コードが読まれているという自覚 = 読むことを「当たり前」に * 「あいつはコードを読むやつ」\n という認識を広める * 自分だけからチームへ * 「このチームはコードを読み合う」\n という認識を広める (('tag:center')) …続きはセミナーの最後に = この後の実践 (('tag:center')) 開発を続けるために\n ((*他の人のコードを読む*)) * まず自分が読み始める * リーダブルコードを探す\n (('note:（読みにくいコードは今は置いておく）')) * リーダブルの基準を共有\n (('note:（チームでのリーダブルコードができる）')) = やること 読む文化作りの\n 体験 = 読む文化作りの体験 * 10:45-12:15 課題を実装 * リーダブルコードを書く * 13:30-14:45 実装チェンジ\n 　　　　　　→開発継続 * 「まず自分が読み始める」 * 「リーダブルコードを探す」 * 15:00- グループふりかえり * 「他のメンバーに教える」 = おさらい * この講座の目的 * リーダブルコードの必要性 * この講座でやること = この講座の目的 * 自分の開発チームに * ↑注意：個々人の話ではない * ((*リーダブルなコードが\n 当たり前な文化の作り方*))を * 持ち帰る = リーダブルコードの必要性 * チームの開発速度の維持のため * 継続的に改良・修正したい * それも現実的なコストの範囲内で = 変更コストと開発速度 # image # src = images/readable-code-reasonability.svg # relative_width = 90 == プロパティー : enable-title-on-image false = この講座でやること * コードを読む文化作りの体験 * まず自分が読み始める * リーダブルコードを探す * 他のメンバーに教える = ここまでの説明 腑に落ちましたか？