開発ログを書く意味
架空言語におけるOSの開発ログ/hsjoihsさん
夢はでかくなけりゃつまらないだろ ~セキュキャン後 6 週間の過ごし方~ - Google ドキュメント
hsjoihsさんが書いている
開発日誌の残し方としてものすごく参考になる例
意思決定の理由と時間区間をメモする
意思決定の理由
意思決定の理由を後から見返せると、なんでこうしたんだっけ?がなくなる
不備があっても再検討できるからいい
時間区間で区切る
ログを残す。
書く場所がそれぞれ独立する。
内容が混ざることがない
タスク上限決定法と混ぜると有効
僕のScrapboxでもこれを実行してみよう。
この例では、ログをドキュメントに長く連ねて書いている
Scrapboxでやるのと違い
ページ間リンク機能がない。
自然言語による明示は可能なのでそこまで深刻なのか?
内容の整理は困難そう?
内容の整理は重要か?
後の自分が思い出すのは少し困難かもしれない
Ctrl + Fで検索はできるだろうし。
前書いた内容が消去されない。
Scrapboxだと消せてしまう
historyはあるけど目立ちにくく、気づかないことも。
テロメア
開発ログとして残す場合には、不可逆性を維持すると良さそう?
まあ「開発ログ」だしなあ。
そのために時間区間を記述している。
時間区間によって独立し、その後の時間の自分が編集を加えることが難しくなる
かけるなら、その自分の身の回りのことも書くと良いのかも
なぜ開発ができてないか、うまく進んでないか納得がいく。
メンタル的な部分も言語化すべき?邪魔かも?
目標は修正しても良い/nishioで言及した方法に解決方法は似ている。
修正する場合には内容を消すのではなく、追記する。
---> 実践してみた。/kssrecorders/2023-03-29
開発日誌を書くんじゃなくて開発ログを書く?ということなのかもしれない
「日誌」だと可逆/修正可能なイメージ
ログは修正できない
開発しながらこのページを見ると、なんか同時進行していっててどこかしらモチベが上がる。
#TODO これのリンクはいずこへ
hsjoihsさん「やっぱり技術選定の理由を言語化するのって大事なんだよな」
こりーさん「ビジネスだと ADR って言うやつだ。最近人類これが大事ってことに気づき始めた」
hsjoihs「ほうほう。なんの略だろう」
こりー「architecture decision record」
hsjoihs「なるほどね」
こりー「継続的にメンテするやつをやるときって、ビジネス要件って変わるんですよね。なので、ADRが無いと、意思決定をした当時の前提が今も通用するかってのがだんだん分からなくなってくる」
hsjoihs「なるほどなぁ」
アジャイル型開発ではバックログがこれに相当しそう。
や、今目指すものをバックログは示してくれるけど、過程は示してくれないから違うものかな
Architecture Decision Record
/takker/課題をこなすまでの過程
👀 2023/08/15 19:54:32
#WebScrap #Bookmark