🦔
普通のプログラマの普通の設計
概要
2022/01/26に開催された下記勉強会のメモです
セッション
「普通の設計」をするということ
「普通の設計」：美しいコードを探求するための営み
- 脳内でイメージを作る
- コードを書く->許容できる違和感ならクソコードと書き記す、コレジャナイなら全消し
- クラス図におこす->ツールは使わず手書き、配置や依存が意図通りにできる
- 試行錯誤する->クラス図をコードにフィードバック
- 繰り返す->最初に書いたコードは大体間違ってる、理解してるつもりでわかってない
美しいコードの条件
- 簡潔さ->脳内テストできる大きさ、50行以内
- 統一性->表現のブレなど
- 読みやすさ->文章として読める
- 「リーダブルコード」のいくつかを実践
- テストしやすさ
- 形式美->見た目から美しさを感じられるか
どんなことを考えながらやっているか
- パッケージングに気を配る->構造や境界を表現
- パターンは極力使わない->金槌を持つとなんでも釘に見えちゃう人にならない
- コードと真摯に向き合う->コードに語らせるために
- クソコードを許容する->スケジュールは待ってくれない
- 逃げない、負けない、諦めない->理想は持ち続ける
ふつうの設計の基本要素
ふつう＝驚き最小の原則に従う
ふつう≒プロとして
全体を設計・実装と分けるモデル
->全部プログラミングで設計・文書化・コード化に分かれる（けど被る）
->文書化・コード化しながら設計してる
->全部やってる時がリファクタリング
過去の言語化は役立つ
特定のモデル導入時は強めの制約があるツールをおすすめ
- 書ける内容が矯正されたものは不慣れな時こそ良い
- 上手く書けないものは慣れてくるとそんな書き方がよくない・書くじゃでないとなる
設計のコア
- 名前
UMLとかERDは伝えたいことが伝われば十分
設計の勉強->とにかくやれ
- 三振制で学ぶものを取捨選択するという方法
勉強会グループで開催したイベントの記事まとめ
Discussion