綺麗なコードを書くためのコードレビューチェックリスト PR出す前にこの観点は必要だよねリストまとめ 1. 設計と仕様の整合性 コードが既存のシステム設計に一致しているか確認します。 例えば、MVCアーキテクチャを採用している場合、モデル、ビュー、コントローラーが適切に分離されているかをチェックします。 機能要件 コードが仕様書に記載された機能を正しく実装しているか確認 テストケースを使って期待される動作を検証すると効果的 非機能要件 パフォーマンス、セキュリティ、拡張性などの非機能要件も満たしているかをチェックし YAGNI（You Aren't Gonna Need It）の原則 必要な機能だけを実装し、将来の要求に備えて無駄な機能を追加しない。これはコードの複雑さを減らし、保守性を高めます。 オブジェクト指向設計の原則 単一責任の原則 (Single Responsibility Pr
これはなに 8.0.0 Milestoneを見て気になったものをまとめています マイルストーンは先週くらいにできたのですがもうマージされているやつもたくさんあります DHHが年末年始にめっちゃ働いている 気になったものたち Ruby3.3以上のサポート DHHは最初3.3以上で、という気持ちだったんだけど流石にみんな大変やろ、という意見が出て結局リリース時(2024年の予定)にサポートされているRubyのバージョン、つまり3.1以上に落ち着いた PR: Bump the required Ruby version to 3.1.0 by byroot · Pull Request #50491 · rails/rails ↑のPRでは「メジャーバージョンアップ時にRubyのサポートを落とす」だとRails自体のメンテも大変だしアプリケーション開発者も大変なので、毎回マイナーバージョンアップ
こんにちは、クラシルリワードのSRE担当のjoooee0000です。 私はクラシルリワードのサービスローンチの約3ヶ月後にサーバー兼インフラエンジニアとしてjoinし、サービスの成長と共に、開発速度とシステムの信頼性の向上を目指してシステムの改善を行ってきました。 その中で、特に開発速度と信頼性向上に寄与したと思う3つの改善を紹介したいと思います。 改善を行う際に「コスト(金額、導入共に)と効果のバランス」「運用しやすいシンプルな設計」に特に気をつけたので、参考なると幸いです。 (話すこと: 取り組んだ施策の概要紹介、 話さないこと: 細かいhow to) やってよかったこと3選 ブランチ戦略の見直しとシンプルな検証環境の維持 ログの構造化とNewRelicログUIの導入 インシデント管理ツールの導入 それぞれ、改善前にどのような課題があったか、改善後のメリットなどを紹介していきます。 1
So We've Got a Memory Leak… | Steven Harman — Maker & Breaker of Things
Memory leaks happen. And if you’re here, reading this, I’d bet you’re dealing with one. First things first - are you sure it’s a leak, and not bloat? Okay, so it’s a leak. Much has been written about various tools for profiling a leak, understanding heap dumps, common causes of leaks, work being done to improve Ruby’s memory layout, and so much more. Ben Sheldon’s recent “The answer is in your hea
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
綺麗なコードを書くためのコードレビューチェックリスト - Qiita
Rails8.0.0マイルストーンの現状 - おもしろwebサービス開発日記チラシの裏
小さいチームで実践する!開発速度・信頼性向上のためにやってよかったシステム改善3選 - dely Tech Blog