ken1flanのブログ

自己紹介・最近やってることなどを書くつもりです。

「良いコード／悪いコードで学ぶ設計入門」読書会 第20回を開催しました

「良いコード／悪いコードで学ぶ設計入門」読書会 第20回 を開催しました。

academist-reading.connpass.com

みんなで書いたホワイトボード

「良いコード／悪いコードで学ぶ設計入門」読書会 第20回 ホワイトボード

感想・気づいたことなど

  • 否定の!
    • 文字が細いと聞いて、めっちゃうなずいちゃいましたw
  • テスト
    • ユニットテストは…構造的な変化には無力かも。
      • そのときには上のレイヤーのテストが担保してくれる…と信じてます。
    • プロジェクトによって、どの程度テストを書くのかは考えてもいいかも。
      • ユニットテストまでは書いてないというところも、ざっくり正しいことを確認するスモークテストはやってるとのこと。
      • 自分は…自身の書いたコードを見直す意味でも書いていたりします。だってひとりで、レビュワーもいないんですもん…。
  • ベストプラクティス
    • （自身の開発するソフトで）リファクタリングするフェーズな気がするんだけど、目指すべき姿がわからないので困っている、という話が出ました。
    • いろいろ失敗する前に目指すべき姿、ベストプラクティスを知りたい…。
    • デザインパターンやアンチパターンは抽象的すぎて…
    • ひとつひとつのソフトには違った背景があるので、理想を目指しながら試行錯誤するしかないのでは…。
    • （あとから思ったこと）
      • もしあればですが、作っているソフトに近いOSSプロジェクトを探してみる、みたいなこともあったかも。
  • どの発言だったかわすれてしまいましたが…なんか質問を聞き取り間違って変なこと言っちゃったかなーと思ったときに、周りからいろいろと言ってもらえてスゴく助かりました。

運営としてのふりかえり

KPT方式で。

Keep

  • 時間前に会場を開けておけました。
  • 常連の方がきてくれました！
  • リピートしてもらえてます…！常連になってもらえるとうれしい…。
  • 短いかな…と思ったのですが、おもしろい質問が出て、盛り上がったと思います。

Problem

  • ちょっと時間をオーバーしてしまいました。
    • 5分程度だったので、まぁヨシとさせてください…。

Try

  • 引き続きがんばります…！

おわりに

参加してくれたみなさん、ありがとうございました！ あとでざっと見直しても、一人で読むより圧倒的に気づくことが多いので、今後も継続してやっていきたいと思います！

参照

情報セキュリティ対策自主研修 第1５回 「その警告メッセージ、信じて大丈夫？ ブラウザの“偽警告”にご用心！」を観よう！を開催しました

academist-reading.connpass.com]

情報セキュリティ対策自主研修 第1５回 「その警告メッセージ、信じて大丈夫？ ブラウザの“偽警告”にご用心！」を観よう！を開催したので、簡単な感想を書きます。

題材

  • その警告メッセージ、信じて大丈夫？ ブラウザの“偽警告”にご用心！

感想

運営としてのふりかえり

KPT方式で。

前回のTry

  • 次回のネタを決めます…！
    • 決められていませんでした。うーん、どうしよう？

Keep

  • 思った以上に動画がよかったです。

Problem

  • 社内メンバーだけでした。
  • 次回何をやるか、まだ未定でした…。
  • あちこちリンクが間違っていました…。
    • まとめて作成できなかったからかも。
    • リンクなどを揃えてから作成します。
  • 早く終わりました。
    • もうちょっと何かを準備しておいてもよかったかも。

Try

  • 次回のネタを決めます…！

おわりに

参加してくれたみなさん、ありがとうございました！ あとでざっと見直しても、やっぱりひとりで見るより、圧倒的に気づくことが多いので、今後も継続してやっていきたいと思います！

メモ

  • 終わったあとにやること
    • [x] 前回のjamboardの削除
    • [x] Google Meetのメッセージの保存
    • 謝辞と感想
      • [x] twitter
      • [x] facebook
      • [x] mastodon
      • [x] bluesky
      • [x] threads
      • [x] connpassのイベントメッセージ
      • [x] ブログ
  • 次回準備
    • [ ] jamboard
    • [ ] カレンダー/Google Meet URL
    • [ ] connpassイベント
    • [ ] ネタぎめ
    • [ ] 告知
  • 直前
    • [ ] 告知
    • [ ] リマインドメール

良いコード／悪いコードで学ぶ設計入門 14章のメモ

gihyo.jp

良いコード／悪いコードで学ぶ設計入門 の読書メモです。

長いので章ごとにしてます。

14章 リファクタリング ー既存コードを成長に導く技ー

  • 実務では未熟な設計やコードでスタートするので、この章に期待…！

14.1 リファクタリングの流れ

  • また読みにくいコードが…。
  • この順番通りに処置していくのがオススメとかあるのかな？

14.1.1 ネストを解消し、見通しを良くする

  • せやな。

14.1.2 意味のある単位にロジックをまとめる

  • せやな。

14.1.3 条件を読みやすくする

  • Rubyは標準ライブラリも否定のメソッドがいっぱいあるので、扱いやすいし、真似たくなります。

14.1.4 ベタ書きロジックを目的を表すメソッドに置き換える

  • プログラミングは…要約の作業かも？
  • Customer.isShortOfPoint って、ちょっと微妙感ありません？
    • PurchacePoint.isShort とかダメですかね…？

14.2 ユニットテストでリファクタリングのミスを防ぐ

  • 悪魔を呼び寄せるようなコードにはテストがない……わかる……。
    • テストを書いてると、アレ？ってなって、コードを改善したくなるから、ひどくなりにくいかと思ってます。

14.2.1 コードの課題を整理する

14.2.2 テストコードを用いたリファクタリングの流れ

  • あるべき構造のひな形をつくっておくのはなるほど、ちょっとよさそう…！
  • ひな型のクラスに対してテストを書くのは、無駄にならなくて、精神衛生上かなりよさそうです！
  • レッド、グリーン、リファクタリング！

14.3 あやふやな仕様を理解するための分析方法

14.3.1 仕様分析方法1:仕様化テスト

  • テストコードって、繰り返し実行しやすいから、仕様を探索するのに使いやすいのはわかります…！
    •  …だけど、こんなに少ない引数のだったら、コードを読むのも苦労しなそう。
    • 複雑なときもいけるのかな…？
    • 繰り返しやすいから、やっぱりやりやすそうです。

14.3.2 仕様分析方法2:試行リファクタリング

  • 読みやすくするためのリファクタリングかあ。
    • 捨てる勇気がなかなか…。わかってはいるんですが…。

14.4 IDEのリファクタリング機能

  • IDEのリファクタリング、まだあんまり使ったことないんですよね…。
    • IntelliJ IDEA、よさそうですが、高いんですよね…。
  • ひとつのファイル内なら、copilotにやってもらえるかも。（練習中）

14.4.1 リネーム（名前の変更）

  • これ、めっちゃほしい…けど、VSCodeでRuby使ってるときにはないようで…？
    • 「シンボルの変更」を試したけど、同一ファイル内しか…。
    • 結局、grepして置き換えかあ…。
      • それでも、レビューとテストでガードしてれば、ある程度怖くないかも。

14.4.2 メソッド抽出

  • こういう細かいのも、やってもらえるならアリなのかなあ？

14.5 リファクタリングで注意すべきこと

  • 速いテストと小さい改善は相性がよさそう…。
    • テスト、前50分くらいかかってました…。今25分…。

14.5.1 機能追加とリファクタリングを同時にやらない

  • 同時にやってしまう理由は…？
    • プルリクエストがマージされるまでの時間がかかってしまうこと？
    • ほかにはなにかありそう？

14.5.2 スモールステップで実施する

  • コミットログでストーリーを語る…やりたいけどなかなかできないです><

14.5.3 無駄な仕様は削除することも視野に

  • やるやる、めっちゃやる！

Column Railsアプリのリファクタリング

  • ReadyForのことですよね。
  • 型のある言語だと、確かにリファクタリングはしやすい…ですね。
  • Rubyの型を使いこなせるようにしていかねば…。

「良いコード／悪いコードで学ぶ設計入門」読書会 第19回を開催しました

「良いコード／悪いコードで学ぶ設計入門」読書会 第19回 を開催しました。

academist-reading.connpass.com

みんなで書いたホワイトボード

良いコード／悪いコードで学ぶ設計入門」読書会 第19回 ホワイトボード

感想・気づいたことなど

  • 13.1のユーザクラスのサンプル、ありがちな例でめっちゃよかったので、本文でちゃんと使ってほしかったです><
  • OOPでいきない設計せずに、データ設計からはいることが多いです、という話が出て…そういえば自分もそうなんだと気付かされました。
    • ヒアリングとかをするときに、モデルで話すよりは、オペレーションの現場で使っている帳票を下に、正規化などを施したものを確認していく、みたいな進め方してました。
  • モデルをどこに書くのがいいか、どうやってメンテナンスしたらいいか、みんなに訊きました。
    • mermaidなどに限定してしまうとチーム内で描ける・描けないが出て、本末転倒なので、あえて限定しない…！
      • この視点はとても大事にしたいと思いました。
    • 更新漏れは…起きますね！
      • 仕方ないかも。都度直せばいいかも。
  • 13.3.1 Userとシステムの関係で、「システムの中にユーザがいない」は納得でした。ちょっと書きにくいと思ってたので…。あるのはユーザに関する情報、かも。
  • 値オブジェクト、言語やフレームワークによるやりやすさとプロジェクトでの必要性を踏まえて、判断するのがよさそう、という空気感になりました。
    • 実際にいれるかどうかは別にして、サンプルプロジェクトで書いてみることだけはやっておきたいです…。

運営としてのふりかえり

KPT方式で。

Keep

  • 時間前に会場を開けておけました。
  • 常連の方がきてくれました！
  • リピートしてもらえました！

Problem

  • 今日の章、やりにくかったです…。
  • ちょっと時間をオーバーしてしまいました。
    • 5分程度だったので、まぁヨシとさせてください…。
  • ホワイトボードの付箋の配置がよくなく、13.4を取り上げ忘れました><

Try

  • ホワイトボードの付箋紙の並びは前と同じにします。

おわりに

参加してくれたみなさん、ありがとうございました！ あとでざっと見直しても、一人で読むより圧倒的に気づくことが多いので、今後も継続してやっていきたいと思います！

参照

「良いコード／悪いコードで学ぶ設計入門」読書会 第18回を開催しました

「良いコード／悪いコードで学ぶ設計入門」読書会 第18回 を開催しました。

academist-reading.connpass.com

みんなで書いたホワイトボード

良いコード／悪いコードで学ぶ設計入門」読書会 第18回 ホワイトボード

感想・気づいたことなど

  • 12章全体が以前の章の振り返りのようになっていました。
  • 12.5.1 引数は不変にすること
    • 基本的に引数は値渡しですが…オブジェクトはそうでなかったりします…。
    • Rubyだとfreezeがありますが…毎回やる？やったらやったでfreezeしっぱなしでは…。
    • 値オブジェクトはfreezeしちゃってもよさそうですが、エンティティのようなものは…？
    • どうしたら現実的に運用できそうなのかさっぱりわからないということが、ここでわかったことかもしれません。
    • 「引数が単純に参照渡しになるような言語設計の失敗がプログラマにしわ寄せされているだけ」という付箋紙になんとなく自分も同意です。
  • 12.6.1 「型」を使って戻り値の意図を表明すること
    • 型があるlintやコンパイル時にエラーがわかっていいですよね、などという話が出ていました。
    • Rubyも外部から型情報を渡せるようになってきたので、試したい！と思いつつ、自社環境がまだ3.0なので、3.2にしたらやろうと、決心したところです。
  • 12.6.3 エラーは戻り値で返さない、例外をスローすること
    • ここの文章だけだと、何でもかんでも例外にしちゃおう、みたいに読めました。
    • 参加者の中では、エラーと例外を分けたほうがいいんじゃないか？ということになっていました。
  • 全体的によい議論ができて、とても楽しかったです！！

運営としてのふりかえり

KPT方式で。

Keep

  • 時間前に会場を開けておけました。
  • 常連の方がきてくれました！
  • 新しい元気な方が参加してくれました！
    • connpassで見つけてくれたようです。
    • 有名な本を題材に読むのはやっぱりいいですね。

Problem

  • 落ち着きのない進行になってしまいました…。
    • 新しい方が来てくれて、ちょっと舞い上がってしまっていました。
    • だって、うれしいんですもん。

Try

  • 新規参加しやすいよう、呼びかけの種類を増やしたいです。

おわりに

参加してくれたみなさん、ありがとうございました！ あとでざっと見直しても、一人で読むより圧倒的に気づくことが多いので、今後も継続してやっていきたいと思います！

参照

良いコード／悪いコードで学ぶ設計入門 13章のメモ

gihyo.jp

良いコード／悪いコードで学ぶ設計入門 の読書メモです。

長いので章ごとにしてます。

13章 モデリング ークラス設計の土台ー

13.1 邪悪な構造に陥りがちなUserクラス

  • うわあ……ありがちw いいサンプル！

13.2 モデリングの考え方とあるべき構造

  • 突然説明パートになっちゃいました？

13.2.1 システムとは何か

  • ですね！

13.2.2 システム構造とモデリング

  • 「特定の目的達成のために最低限考慮が必要な要素を備えたものがモデル」
    • どうやって構成をまとめた文書をメンテナンスし続けたらよさそう…？

13.2.3 ソフトウェア設計におけるモデリング

  • なんでも書いちゃうと目的がぼやける、というのはわかります。
    • 絞って書いたほうが確かに目的がわかりやすいです。
  • メンテナンスするんでしょうか…？

13.3 良くないモデルの問題点と解決方法

  • 辛辣ですねぇ…。
  • 「社会活動や目的の理解が必須」
    • わかります！…が、辛辣ですね。

13.3.1 Userとシステムの関係

  • 「システム内にユーザがいない」なるほど、なんか書きにくい気持ちもしていました。

13.3.2 仮想世界を表現する情報システム

  • まぁ…せやな。

13.3.3 目的別にモデリングする

  • 実世界とシステム上のユーザが1:多って何事かと思いました。
    • 目的によっていろんなモデルに分かれるよ、ということですね。

13.3.4 モデルはモノではなく目的達成手段

  • まぁ、わかりますが…。

13.3.5 単一責任とは単一目的

  • いい言い換えかも。
  • 「共通利用可能な、汎用的な部品」…そんなことを言ってるのもあったんでしたっけ……。

13.3.6 モデルの見直し方

  • ひとにシステムを説明するときには確かに全部は書きませんが…。

13.3.7 モデルと実装は相互にフィードバックする

  • ううむ…じゃあ、モデルは今後どうやっていくの…？
  • 図13.10 … ああ、そうか、値オブジェクトがいっぱいあるからですかね…。

Column クソコード動画「Userクラス」

  • プロジェクト最初期からモデリングに心を砕けって…ムリでしょ…。どんな恵まれたメンバーなんですか…と思ってしまいました。
  • 今自分がその場になったら、気にしてやりますが…なかなかそういうこともないもので…。

13.4 機能性を左右するモデリング

13.4.1 裏に隠れた真の目的を見破る

  • 「法的な顔」
    • 最初からわかってれば！は同意です。
    • ドメイン知識も乏しい中で、どうやって最初から引き出せるのか、方法を知りたいです…。

13.3.2 機能性をイノベートする「深いモデル」

  • 目的によって分類の仕方が変わるのはたしかに…。
    • 自然にやってると思いますが…。
    • スーパーのアプリとかやってたら、魚類の前に青魚、白身、赤身みたいに入れるかもしれないし。
  • 深いモデル…うーん、プロダクトチーム全体で日々の議論が必要な感じが…。
  • 会社でちょくちょく議論するときに、情報の構造をホワイトボードに描くようにしてますが、たしかに効果を感じてます。

第52回Software Design (2024年2月号) 輪読&座談会 に参加してきました

いつもおせわになっている52回Software Design (2024年2月号) 輪読&座談会に参加してきました。

softwaredesign.connpass.com

  • 今回スゴイ人数で、めちゃくちゃ賑わってました…！
    • そういえば危うく参加登録できないところでした…。
    • チャットも大盛り上がりで…しゃべっているのを聴きながら読むのは無理でした…。
      • Zoomの機能でダウンロードできたので助かりました。あとからゆっくり読もうと思います。
  • ひみつのLinux、今回のFはFin.のFだそうで…読み落としてました。なるほどです…！
  • 第一特集のテストの著者の方や、テストに詳しい方が多く、大変学びになりました。
    • チームのテストスキルの底上げ方法は？と訊いたところ、みんなで同じ課題に対して、テストを書いて比べたりしながら、議論しているとのことでした。
    • TDDのテストは作るものが動作するかどうか行うチェッキングで、QAのテストはこうしても壊れないだろうか？と確認するテスティング
      • t-wadaさんの資料に合った言葉だそうです。
        • もうちょっと正確な出典を教えていただきました :pray:
    • テストが十分どうかのチェック
      • すべての状態を通っている or すべてのアクションを行っている が目安
    • 状態遷移表を作ったときに、空欄になる部分が仕様の定義されないことが多い…。
    • いろんな立場の人を集めて、よく議論するのが大事だそうです。
      • うちは人数が少ないから、必然的にできているかもしれません。
  • ハピネスチームビルディングもだいぶ盛り上がっていました。
  • 毎回自分のメモを開いてくれるので…ちょっと章立てを見直します…。
    • 上にまとめて訊きたいことを書いてあると、混乱されがちで :pray:

今回は特に刺激的な会でした。 また次回も行こうっと。