はてなブックマーク

はじめに チーム開発をしていくと、メンバーひとりが持つ実装力の高さによるアウトプット よりも コミュニケーションや協調の重要性を理解したメンバーで補完しながらのアウトプット の方が効果が高いです。実装力の高さとチームでの視点で思考する感覚は付随して習得できるものではないため、チーム開発でしか学べないスキルや立ち回り方があるでしょう。 この記事では、経験年数1年6ヶ月の Web まわりをさわっているエンジニアが、PrAha Challenge [1] で 戦術DDD やアジャイル開発手法を取り入れながら、チーム開発をした振り返りをしていこうと考えています。(かなり独断と偏見が入っています) 想定読者 Web領域 で経験年数1~2年目のエンジニアの方 PrAha Challenge に参加している方 要約 面識のないメンバー同士でチーム開発をする難しさについて チームの開発フローを形成する方法

はじめに コード上での問題を正確に認識しておかなければ、問題を繰り返すのです。Reactを使用したプロジェクトに参画したり、OSSプロジェクトのソースコードを散見すると複雑な仕様に立ち向かったUIに出会うことがあるでしょう。 複雑な仕様に立ち向かったUIは以下の特徴があると考えています。 bundle size が肥大している 保守や維持の管理が高い 他開発者にこのUIは何をやっているのか、質問をしなければならない。 質問の回答を聞いてもそのUIが実行していることが多様で理解しづらい。 再利用性が低い そのUIを利用するために満たさなければならない条件が多く、新しく似ているUIを実装することになる。 複雑なAPI 片手の指の数では溢れる props の数が存在している ユースケースを満たすために、既存の機能を使えば実装ができるのか、判断がしづらい 上記のようなUIを見かけた場合、どのような

はじめに 最近では、多様なテスト手法や開発者向けツールを散見します。 エンドツーエンド（E2E）テストだけでも、「Cypress」「Puppeteer」「Playwright」「Selenium」などのツールがあります。単体テストでは「Vitest」や「Visual Studio」のビルトイン単体テスト機能など、テストの準備を容易に自動化できます。 ですが、多様なテストツールを導入しても、「When」、「How」を押さえてなければ、テストの効果を有効に得ることができないと考えています。 まず、静的テスト、単体テスト、統合テスト、E2Eテストを実装コスト、実行時間と信頼性の観点で見ていき、無駄や漏れのないテスト戦略を立てていきましょう 。 テストを実装コスト、実行時間と信頼性で考える どのテストを使用するかの選択する観点として、テストをする実装コスト、実行時間と、テスト結果の信頼性のトレード