Development ★ 140,637

request-refactor-plan

Kullanıcı görüşmesi yoluyla ayrıntılı bir refactor planı oluşturun, küçük commitlerle düzenleyin ve GitHub issue olarak kaydettirin. Refactor planlaması, refactoring RFC oluşturma veya refactorı güvenli adımlara bölme gerektiğinde kullanın.

cd ~/.claude/skills
git clone https://github.com/mattpocock/skills.git skills

Bu skill, kullanıcı bir refactor isteği oluşturmak istediğinde çağrılacaktır. Aşağıdaki adımları izlemelisiniz. Gerekli olmadığını düşünüyorsanız adımları atlayabilirsiniz.

  1. Kullanıcıdan çözmek istedikleri sorunun uzun ve detaylı bir açıklamasını ve olası çözüm fikirlerini isteyin.

  2. Repo'yu explore ederek onların iddialarını doğrulayın ve codebase'in mevcut durumunu anlayın.

  3. Başka seçenekleri göz önünde bulundurmuş olup olmadıklarını sorun ve onlara diğer seçenekleri sunun.

  4. Kullanıcıyla implementation hakkında görüşün. Son derece detaylı ve kapsamlı olun.

  5. Implementation'ın tam kapsamını belirleyin. Neyi değiştireceğinizi ve neyi değiştirmeyeceğinizi çalışın.

  6. Codebase'de bu alan için test coverage'ını kontrol edin. Yetersiz test coverage varsa, kullanıcıdan test planlarının neler olduğunu sorun.

  7. Implementation'ı küçük commit'lerin bir planına bölün. Martin Fowler'ın "her refactoring adımını olabildiğince küçük tutun, böylece program'ın her zaman çalıştığını görebilirsiniz" tavsiyesini hatırlayın.

  8. Refactor planı ile bir GitHub issue oluşturun. Issue açıklaması için aşağıdaki template'i kullanın:

Problem Statement

Developer'ın karşılaştığı sorunun, developer'ın perspektifinden açıklaması.

Solution

Soruna çözüm, developer'ın perspektifinden.

Commits

Uzun ve detaylı bir implementation planı. Planı düz İngilizce'de yazın, implementation'ı mümkün olan en küçük commit'lere bölün. Her commit, codebase'i çalışan bir durumda bırakmalıdır.

Decision Document

Alınan implementation kararlarının bir listesi. Buna şunlar dahil olabilir:

  • Build edilecek/modifiye edilecek moduller
  • Modifiye edilecek bu modüllerin interface'leri
  • Developer'dan gelen teknik açıklıklar
  • Architectural kararlar
  • Schema değişiklikleri
  • API kontratları
  • Spesifik etkileşimler

Spesifik dosya yollarını veya kod snippet'lerini EKLEMEYIN. Bunlar çok hızlı eski haline gelebilir.

Testing Decisions

Alınan testing kararlarının bir listesi. Şunları dahil edin:

  • İyi bir test'in ne olduğunun açıklaması (sadece external behavior'u test edin, implementation details'i değil)
  • Test edilecek moduller
  • Test için prior art (yani codebase'deki benzer test türleri)

Out of Scope

Bu refactor için kapsamı dışında olan şeylerin açıklaması.

Further Notes (optional)

Refactor hakkında herhangi bir ek not.

Benzer skill'ler

Daha fazla: Development →