# 開発日記-2024-07-20 / 今日読んだ記事のメモ

## npmパッケージの公開を自動化するためのメモ

::link-card[https://gir.me.uk/posts/monorepo-npm-publish-workflow.html]

### Changesets

Changesets + GitHub Actionsの連携を調べているがまだよくわからないことが多い。

::link-card[https://roboin.io/article/2024/04/19/auto-release-to-npm-with-changesets/]

::link-card[https://dnlytras.com/blog/using-changesets]

::link-card[https://qiita.com/macropygia/items/c74d3c1f27addb70b280]

::link-card[https://qiita.com/akameco/items/1476e5aa3ba6e8781286]

## package.jsonのscriptsのプレフィックスについて

pre, postをつけると前後で実行するコマンドになる。

::link-card[https://zenn.dev/ikuraikura/articles/bd76fba0539f7fe04703]

## 今日読んだ記事のメモ

今日読んで気になった記事のメモ。

### 技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先？

::link-card[https://www.publickey1.jp/blog/24/post_301.html]

::link-card[https://www.publickey1.jp/blog/24/post_302.html]

> だから、基本的には良かれと思って既存コードとコーディングスタイルを合わせようとする。あるいは、これは善し悪しがある、まあ悪い方が多いんですけれど、機能追加の際などにレビュワーの負担を下げようとしてコードのDiffを小さくしようとするんです。
>
> 本当は、このインデントの構造を変えた方がいいんだけど、それをするとDiffが大きくなるから止めよう、とか、本当はメソッドに抽出したほうがいいんだけど、それだとDiffが大きくなるからこのif文を追加で、みたいな感じでDiffを小さくしようとする。
>
> （GitHub上などで）Diffでコードレビューするようになったことで、Diffの小ささがよしとされてしまう。これをやや俯瞰で見ると、構造的複雑さとか命名的な悪さというのが、じわじわと累積されていく形になるんですね。
>
> そういうのが何年も積み重なると、現場のレガシーコードが出来上がる。

レガシーコードの「命名的問題」「構造的問題」のどちらを優先してリファクタリングすると保守性や可読性が高くなるかの調査のレポート記事。引用はレガシーコードが出来上がる過程のあるあるを丁寧に文章にしてあって好きだった部分。