迷ったときや説明が必要なときに引用する先。
- 自走プログラマー 【抜粋版】
- エラーハンドリング、ロギングが書いてある
- レビューの仕方、Pythonのユニットテストも少し書いてある
- 良いコードの書き方
- 初歩寄りのことがいろいろ書いてある
- 名付け方法、コメントの方針、変数のスコープなど
- ダメである理由が無いとこは納得感が薄いかも
- エラーを握りつぶさない。想定外のデータになっている場合は例外を発生させる。
- 🆖 来ることがない値が来た場合に、処理を行わず早期リターンする
- 🆗 来ることがない値が来た場合は例外を発生させる
ライブラリの選定はとても注意深くなる必要はないが、あまり考えずに依存するのは良くない。迷ったときのために、こちらのブログの項目に沿って、VOICEVOXとしての基準を列挙しています。メンテナが責任を持って把握・管理できる場合は例外的にOKです。基準を満たしていなくても重要なライブラリはOKなことも多いです。
- 1 メンテナンスされているか
- 変更が不要なほど枯れているライブラリはOK
- 放置されているIssueやPRが多すぎない、あるいは6ヶ月以内に更新があれば大体OK
- 2 破壊的な変更は多くないか
- 多くないほうが望ましい
- 3 使われているか
- 週数十万以上のダウンロードがあれば大体OK
- 4 リリースされてから十分な時間が経過しているか
- これはあまり気にしていません
- 5 安定版か
- 安定版が望ましい
- バージョン1未満であれば代替可能かどうか見極める
- 6 依存関係は問題ないか
- よく使われるライブラリはだいたい問題ない
- 7 アプリケーションと疎結合にできるか
- 大体疎結合にできるが、UIライブラリは引っかかりやすい
- 8 テストは十分か
- そのライブラリが大丈夫そうかの判定に意外と使えるので、わりと重視する
- 9 守備範囲が広すぎないか
- 依存したい機能に対してコード量が多すぎるものはNG（lodashとか）
- 10 学習コストは高くないか
- 唯一無二なら結構仕方ない
- 自前実装が難しくないなら、ライブラリを導入するより自前実装するほうが望ましいこともある
- 11 ドキュメントは充実しているか
- 充実していたほうが良い
- 細かい仕様が書いてないことがあり、その場合は自前実装にするか使用するか要相談
- 12 遅くないか
- 実際に使ってチェックすればOK
- 13 ブラックボックスなところはないか
- あってもOK
- 小さめなライブラリの場合、一応目を通しておくと安心
- 14 使えなくなったときの代替案はあるか
- 最悪コードコピペでなんとかなる量ならOK
- 15 ライセンス上の問題はないか
- 大体のライセンスがOK、GPLとAGPL辺りがNG
- そもそもライブラリをアプデしておくのは、脆弱性などがあったときにライブラリを更新しやすいため
- 一方でライブラリを高頻度に更新するのはメンテナー的にはどうしても手間
- 自動PRはGithubでの検索効率を落とすので生産性が逆に下がる（たぶん賛否両論）
よって、追従がめんどくさくなりがちなライブラリのうち一番更新頻度が高いものに合わせて全部更新すると良さそう。 VOICEVOXの場合、エディターのelectronが２ヶ月に１回メジャーアプデなのでこれに合わせるのが良さそう。
- メンテナンス性を下げずにできる範囲で広くサポートする
- Github Actionsのサポートが切れたらサポート対象から外しても良い
- Github Actionsのサポートが切れる半年前からは、何か理由があれば切っても良い
- 同時実行の可能性の考慮
- ユーザーが意識せず同時実行される可能性は考慮する
- 例：音声の自動停止と停止ボタン押下は同時に起こり得る
- ユーザーがほとんどの場合行わない操作による同時実行は考慮しなくても良い
- 致命的な問題が発生することは避けるべきだが、エラーダイアログ表示などの軽いUX低下は許容する
- 例：ショートカットキーとクリック押下は、あまり同時に起こり得ない
- 例：テキスト確定によるAudioQueryの取得完了とテキスト欄の消去は、あまり同時に起こり得ない
- ユーザーが意識せず同時実行される可能性は考慮する