2018/12/13
よもやま
PlantUMLのやつ
今日も今日とて。みんな大好きPlantUML！をやっていました。
シーケンス図とアクティビティ図を使ったよ☺
いわゆる「ドキュメントづくり」って、そんなに大きくないチームやプロジェクトなら別にいらなくね？派であり楽観派なのですが。(なぜならコードがそこに有るんでしょ？)
いつ「作成するべきか」っていうと、何かしらやっていて「あったほうがいいな」って思うタイミングが来るものと思っていて。心の声に従いながら作成をし始めるのが良いのでないかなーくらいの気持ち。
例えば、再実装や実装の移転をする際に、「最初に作った人を含めて、そのコードを読み解く3人目のメンバーが現れたとき」など。1人目は実装した本人、2人目はその時に本人から伝承をされつつレビューしたりで関わっている人。「2人目から3人目」の時が1つのタイミングかな、と思うのが「実装者が直接関わらなくなる」というタイミングだから。この時点で、「誰が触っても安心できる」という再現性を固めにいこう〜みたいな。
私が今やっているのは、「過去実装アプリケーションの移行」ということで、まぁ古い方のアプリケーションも直接読んだし触ったしで「十分に知っている」状態ではあるのだけど、いかんせん「久しぶりに触ったら凄い思い出しながらの作業になった」のと「リファクタ可能な箇所(要件的に、実装的に)を明確に洗い出したい」という2つのモチベーションにて。
ドキュメント化・・・というか「実際のコードと別の実体での説明」は、メンテしていける？というのが1番の問題ではあるよなー今後どうなっていくやら・・
Trait置き場
Traitをディレクトリ掘って隔離したいときって、「Trait」ではなく複数形で「Traits」になるのがベターなのかな？
気になった記事・読んだ記事など
- ビジネスインフラエンジニアの好きなところ｜土屋 雅章｜note
- ユニットテストにまつわる10の勘違い ｜ DevelopersIO
- こういうのはザッと読むと「ははは、わかってるよ当然さ！」って気持ちになるけど、定期的に自分の胸に手を当てて考え直したい系だと思う
- ユニットテストの綺麗な書き方 - 超ウィザード級ハッカーのたのしみ
- ユーザ情報を保存する時のテーブル設計 - そーだいなるらくがき帳
- この「テーブル移す」は、(この記事の内容について〜ではなくて)パターンや手法として名前ってなんか付いてるのかな？っていう感じで情報探していたら。久しぶりに見たなっておもって改めて読んだ。。
便利ツール・ショートカット
公開したもの
ひとこと
明日は夜に予定が入ったので、Adevntは朝！！！