清らかなほぐし水
各人が知っているソフトウェア開発時のプラクティスや経験則等を共有してください。
ソフトウェア開発の雑記帳：2024/09/01〜
TalkJunction
レスポンス一覧
-
- 2024-09-13 23:47:18, ID: 496
リグレッションテスト
※回帰テスト
・単体テストで新規実装した機能が問題ないことを確認できたとしても、システム全体としてはリグレッション（既存実装が無効になること）やデグレード（既存機能が劣化すること）が生じているかも
・リグレッションテストを自動化するまでコストが大きなかかり細部まで自動テストを書くと仕様変更やデザイン変更にもろくなる傾向になる
↓
・チーム内での稼働工数と相談しながらであるが、人力でリグレッションテストを実施することが重要
・「これまで通りシステムが動作しているのか」という目的で何本かのシナリオを書き、そのシナリオに沿ってテストを実施するのが鉄則
・タイミングとしては
・「developブランチがReleaseブランチにマージされたタイミングで検証する」
・「１週間に１回などの頻度で、定期的に主要機能を中心に全体動作を検証する」※フルリグレッションテスト -
PHPMD
静的解析ツールを導入しソースコード品質チェックツールの導入
https://tech.innovator.jp.net/entry/2023/07/12/123232 -
スロークエリ検出
MySQLでスロークエリのログを出力し遅いSQLを特定・可視化すること。
my.cnfに下記を記述し0.2s以上かかったSQLをスロークエリとして/var/log/mysql/slow.logに出力できる
ーーーーーー
[mysqld]
slow_query_log=ON
slow_query_time=0.2
slow_query_log_file=/var/log/mysql/slow.log
ーーーーーー
上記実行後、mysqldプロセス再起動（sudo systemctl restart mysqld）
スロークエリログファイルはElasticSearch+Kibanaを使って簡単に可視化する方法もあり、この可視化をしておけば開発メンバーが気軽に閲覧しスロークエリに気づけます。
このような可視化をすることで予期しない性能劣化にも早期に気づくことができます。 -
- 2024-09-01 07:47:48, ID: 355
（OS限定になるけど）http://www.uefi.org/specificationsを熟読する -
セマンティックバージョニング
・0.0.1みたいなバージョン付け
・x.y.z
x:メジャー
y:マイナー
https://semver.org/lang/ja/
z:パッチ -
ポステルの法則
・事前条件と事後条件においてポステルの法則を念頭に置く
・「送るものは慎重に、受け取るものは寛容に」
・メソッドは理解できる限り入力を受け入れるべき
・戻り値はできるだけ信頼性が高くなければならない -
コミュニケーション階層
将来の読み手に向けてコードを書く。※読み手は将来の自分かもしれない。
下記リストの優先順位にしたがって、振る舞いや意図を伝えること
・１）APIに明確な型を与えること
・２）メソッドに分かりやすい名前をつけること
・３）良いコメントを書くこと
・４）自動テストとして分かりやすい例を提供すること
・５）Gitで分かりやすいコミットメッセージを書くこと
・６）分かりやすいドキュメントを書くこと -
フィーチャーフラグ
・半日程度の作業で一貫性のある形で変更が終わらない場合にはフィーチャーフラグを使って機能を隠してリリース
・自身の変更を他人と継続的に統合する
・マージコストを下げる -
横断的関心事のためのデコレーター
・ロギング等の共通処理をビジネスロジックに注入してはいけない
・AOP
・デコレーターパターンを使って対応するとよい -
サイクロマティック複雑度
・if分岐数を計測しメソッドの複雑度を計測
・しきい値が７に設定するとよいらしい
・リファクタリングする際の目安とするとよい
レスを投稿する
レスを投稿するにはログインが必要です。 ログインする