ken1flanのブログ

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

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

gihyo.jp

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

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

16 設計を妨げる開発プロセスとの戦い

  • コードそのものじゃなくて、コードを作る環境に問題があるだろうと…。わかる…。

16.1 コミュニケーション

16.1.1 コミュニケーションが希薄だと設計品質に問題が生じる

  • せやな…。

16.1.2 コンウェイの法則

  • コンウェイ作戦で失敗してるケースを実際に見たということでしょうか…。だとしたら結構ツライですね…。

16.1.3 心理的安全性

16.2 設計

16.2.1 「早く終わらせたい」心理が品質低下の罠

  • とにかく早く書ける……それはそれで大きな価値ですが…。
    • 前職でも現職でもそういうコードを引き受けることに…。結構たいへんですよね💦

16.2.2 粗悪なコードはきれいなコードを書くより常に遅い

  • アプリケーションが小さくて、仕様が単純、テスト環境を作るのに慣れてない…みたいなことが重なったときはそれにあたらないので、常にはダウトかと…。
  • だいたいなら真だと思いますw

16.2.3 クラス設計と実装のフィードバックサイクルを回す

  • うーん…サボってますね…。改修時にちゃんと組み込むようにしてみます。

16.2.4 厳密に設計しすぎず、サイクルを回し続けるのがコツ

  • 運用し続けること自体が一番大事、というのは自分も賛成です🙋‍♂

16.2.5 「パフォーマンスが落ちるからクラスを追加しない」は正しい?

  • 大規模テキストファイルを処理するようなところではあるかもしれませんが…全部じゃないと思います…。
  • どう分割したらいいかわからないだけ、なのかも。

16.2.6 設計ルールを多数決で決めるとコード品質は最低になる

  • そうなの?そんなもんなの?
    • あんまり大きなチームじゃないことが多かったので、そんなことになったことがなく…。

16.2.7 設計ルールづくりのポイント

  • あー…確かにルールを自分たちで作るとひどくなりそうです。
  • すでにある静的解析のルールを読み合わせる、くらいが今は適当かも?

16.3 実装

16.3.1 割れ窓理論ボーイスカウトの規則

  • あー…よくないのに限ってコピーされたりするんですよね…。
  • ボーイスカウトの規則 、これいいですよね。明記しておきます…。

16.3.2 既存コードを信用せず、冷静に正体を見破る

  • 「これが先輩のお手本」…やめてくれ!
    • でも、これに気がついたの、そこそこに経験を積んでからだったと思います。
  • 知覚できるようになるのが大事なので、アンチパターンを書いてみるのもおもしろいかも。

16.3.3 コーディング規約を利用しよう

16.3.4 命名規則

  • キャメルケースだ、スネークケースだ、そういうのは大丈夫ですが…クラスやメソッドの名前の付け方とかに指針を出したほうがいいかもしれない気持ちです…。やらねば…。

16.4 レビュー

16.4.1 コードレビューをしくみ化しよう

  • セルフアプルーブ、できるようにしてほしい…。
    • 常勤が自分だけなので…明確に「セルフだけどレビューした」印がほしい…。
    • これがないせいで、アプルーブなしをマージ禁止にできないです><
  • プルリクのテンプレート、入れてもいいかも。
    • ひとことプルリクで、あれこれ訊かされるのがツライ><

16.4.2 コードを設計視点でレビューしよう

  • テストや静的解析をCIに組み込めたおかげで、欠陥の有無やコーディングスタイルについて気にしなくてもよくなったのがめちゃくちゃ大きいです…!

16.4.3 敬意と礼儀

  • (クソコードとか悪魔とか書いてあって、どうなの?感はありますが…)
  • 敬意と礼儀は大事にしたいと思っています。
    • ダメなところがあったら言ってほしい…。
    • ちゃんと理由書けてるかなぁ……がんばってるつもりだけどなぁ…。
      • あと、こっちは理由を書いてがんばって説明したことに対して、どういう思いでそうしたのか、なるほどと思ったのか…返信はほしい……。
        • コードを書いている人に比べれば、レビュワーは向き合っている時間が短いはずなので…。
  • 気をつけていることが全部書いてある…!
    • レビュー以外でも言えることだけど、守れているひと少ない気がする…。

16.4.4 定期的に改善タスクを棚卸しすること

  • コードの健全性を測るのに、fixmeの数を入れてもいいかも。

16.5 チームの設計力を高める

  • このやりとり…ありますね><

16.5.1 影響力を持つレベルにまで仲間を集める

  • 10.9%…少ない?と一瞬思いましたが、案外あっていそう。小さいチームなら一人仲間がいるだけで、状況が動きますもんね。

16.5.2 基本はスモールステップ

  • わかる…。(だから読書会してる。)
  • つい、「自分の知っていることは相手も知っていて当然!」みたいな気持ちになりがちで…。
  • 新しいひとが入ったときにどうしたもんか、的な。

16.5.3 実感が大事、手を動かしてみよう

  • プロダクションコードに適用してみる…は確かにそうかも。
    • 対象箇所を探すのが大変そうではありますが…。
    • やってみたい。

16.5.4 フォローアップ勉強会を開いてみよう

  • なるほど…。
  • このフォローアップ勉強会、どれくらいの頻度でできるかな…。

16.5.5 勉強会のバッドノウハウ

  • 設計手法の紹介だけだと、ほえ〜で終わっちゃうのは…わかります。
  • 時間があるなら、取り上げた話題のリファクタリングするの、よさそうですよね。
  • 成果物を否定されたら良い気分はしない
    • わかる…。気をつけています。
    • しかし…この章の前までクソコードとか悪魔とか言ってたのに…と若干思いました。

16.5.6 リーダーやマネージャーに設計と費用対効果の話をする

  • マネージャーと意思疎通が大事…はわかります。
    • 聴いてくれるひとだとやりやすいんですが…実世界はどうなんですかね…?
    • 自分は…比較的小さいところなのでそこまで困ったことはないけれど…。
    • 前職のリーダーはうまく説明していたと思います。
      • そして、なぜやりたいのかはっきりしないような企画も来ないようにもしてました。

16.5.7 設計責任者を立てる

  • 形から入るのはいいかも。
  • しかし、この予算はどこから…?