Refactoring Workflow
Refactoring Workflow Skill
Systematic refactoring with tracking, validation, and completeness verification.
Quick Start
# 1. Record what you're refactoring
record_refactoring "Payment" "Transaction" "class_rename"
# 2. Update files, track progress
update_refactoring_progress "Payment" "app/models/transaction.rb"
# 3. Validate no old references remain
validate_refactoring "Payment" "Transaction"
1. Refactoring Log Functions
record_refactoring()
Start refactoring by recording what's being changed:
record_refactoring() {
local old_name=$1
local new_name=$2
local refactor_type=$3 # class_rename, attribute_rename, method_rename, table_rename
if [ -n "$TASK_ID" ] && command -v bd &> /dev/null; then
bd comment $TASK_ID "π Refactoring Log: $old_name β $new_name
**Type**: $refactor_type
**Started**: $(date -u +"%Y-%m-%d %H:%M:%S UTC")
**Status**: β³ In Progress
### Changes Planned
1. **$(echo $refactor_type | sed 's/_/ /g')**: \`$old_name\` β \`$new_name\`
### Affected Files (Auto-detected)
\`\`\`bash
# Ruby files referencing old name
$(rg --files-with-matches \"\\b$old_name\\b\" --type ruby 2>/dev/null | head -20 || echo "None detected")
\`\`\`
### Validation Checklist
- [ ] No references to \`$old_name\` in Ruby files
- [ ] No references in view templates
- [ ] No references in routes
- [ ] No references in specs
- [ ] No references in factories
- [ ] Migration files checked (if applicable)"
fi
}
# Examples:
# record_refactoring "Payment" "Transaction" "class_rename"
# record_refactoring "user_id" "account_id" "attribute_rename"
# record_refactoring "payments" "transactions" "table_rename"
update_refactoring_progress()
Track progress as files are updated:
update_refactoring_progress() {
local old_name=$1
local file_updated=$2
if [ -n "$TASK_ID" ] && command -v bd &> /dev/null; then
bd comment $TASK_ID "β
Refactoring Progress: Updated \`$file_updated\`
Old references to \`$old_name\` in this file have been updated.
Remaining files: $(rg --files-with-matches \"\\b$old_name\\b\" --type ruby 2>/dev/null | wc -l || echo "?")"
fi
}
validate_refactoring()
Validate all references have been updated:
validate_refactoring() {
local old_name=$1
local new_name=$2
echo "π Validating refactoring: $old_name β $new_name"
# Check for remaining references
local remaining=$(rg --count "\\b$old_name\\b" --type ruby --type erb 2>/dev/null | wc -l)
if [ "$remaining" -gt 0 ]; then
echo "β Refactoring validation failed"
echo "Found $remaining files still referencing '$old_name':"
rg --files-with-matches "\\b$old_name\\b" --type ruby --type erb 2>/dev/null
if [ -n "$TASK_ID" ] && command -v bd &> /dev/null; then
bd update $TASK_ID --status blocked
fi
return 1
else
echo "β
Refactoring validation passed"
echo "All references to '$old_name' successfully updated."
return 0
fi
}
2. Complete Refactoring Workflow
Workflow Steps
- Start: Record refactoring with
record_refactoring() - Update: Update files incrementally, track with
update_refactoring_progress() - Validate: Before phase completion, run
validate_refactoring() - Fix: If validation fails, update remaining references
- Re-validate: Run validation again until it passes
- Complete: Only close task after validation passes
Example: Class Rename Workflow
# Phase starts: Renaming Payment to Transaction
# Step 1: Record refactoring
record_refactoring "Payment" "Transaction" "class_rename"
# Step 2: Update model file
mv app/models/payment.rb app/models/transaction.rb
# Update class name in file
sed -i 's/class Payment/class Transaction/g' app/models/transaction.rb
update_refactoring_progress "Payment" "app/models/transaction.rb"
# Step 3: Update associations in other models
# ... update files ...
update_refactoring_progress "Payment" "app/models/account.rb"
# Step 4: Update controller
mv app/controllers/payments_controller.rb app/controllers/transactions_controller.rb
# ... update class name and references ...
update_refactoring_progress "Payment" "app/controllers/transactions_controller.rb"
# Step 5: Update views, specs, factories, routes
# ... update all remaining files ...
# Step 6: Validate completeness
validate_refactoring "Payment" "Transaction"
if [ $? -eq 0 ]; then
echo "β
Refactoring complete"
else
echo "β Refactoring incomplete, fix remaining references"
fi
3. Cross-Layer Impact Checklists
Class Rename Checklist
When renaming Payment β Transaction:
Ruby Layer:
- Model class definition
- Associations in other models (
has_many :payments) - Controller class name
- Controller instance variables (
@payment) - Service class references
- Job class references
- Serializer references
- String references (polymorphic:
"Payment")
View Layer:
- View template paths (
app/views/payments/) - View helpers and form objects
- Partials and layouts
Routes:
- Route resources (
resources :payments) - Named routes and path helpers
Tests:
- Spec describe blocks
- Factory definitions (
:payment,:payments) - Fixtures (if used)
JavaScript/Frontend:
- Stimulus controllers (
payment_controller.js) - Stimulus class names (
PaymentController) - data-controller attributes (
data-controller="payment") - data-action attributes (
data-action="payment#submit") - JavaScript imports and references
- Event names (
payment:updated) - Turbo frame IDs (
#payment-form) - Importmap pins
I18n:
- Locale keys (
activerecord.models.payment)
Configuration:
- Initializer references
- Environment configs
Attribute Rename Checklist
When renaming user_id β account_id:
Database:
- Migration (column rename)
- Run migration:
rails db:migrate - Verify in schema.rb
Model:
- Attribute references
- Validations
- Associations (
:foreign_keyoption) - Scopes and queries
Controller:
- Strong params
Views:
- Form fields
- Display references
Tests:
- Spec let statements
- Factory attributes
API:
- Serializer attributes
- API documentation
JavaScript:
- data-{controller}-{attr}-value attributes
- Stimulus value definitions
I18n:
- Attribute keys (
activerecord.attributes.model.user_id)
Table Rename Checklist
When renaming payments β transactions:
- Migration (table rename)
- Run migration:
rails db:migrate - Verify in schema.rb
- Model
table_namedeclaration (if explicit) - Foreign key constraints
- Indexes
- Raw SQL queries
- Database views (if any)
JavaScript/Stimulus Refactoring Checklist
When renaming payment β transaction in frontend:
- Controller file rename (
payment_controller.jsβtransaction_controller.js) - Controller class name (
PaymentControllerβTransactionController) - data-controller attributes in views
- data-{controller}-target attributes
- data-action attributes
- JavaScript imports
- Event names and dispatching
- CSS class names that reference the controller
- Turbo frame IDs
- Importmap pins
Namespace/Module Move Checklist
When moving Services::Payment β Billing::Transaction:
- File path (
app/services/payment.rbβapp/billing/transaction.rb) - Module/namespace declaration
- All references to the old namespace
- Autoload paths (if custom)
- Spec file path
- Factory namespace
- Route namespace (if applicable)
4. Intentional Legacy References
Create .refactorignore to exclude files from validation:
# .refactorignore - Files to exclude from refactoring validation
# Legacy compatibility layer
lib/legacy_api_adapter.rb
# Historical documentation
CHANGELOG.md
docs/migration_guide.md
# Rename migrations (reference old names by design)
db/migrate/*_rename_*.rb
# External API contracts (can't change)
app/serializers/api/v1/*_serializer.rb
5. Integration with Beads
Refactoring workflow integrates with beads for:
- Task Tracking: Creates comments for start, progress, completion
- Status Updates: Sets task to
blockedif validation fails - Audit Trail: Full history of what was changed and when
# Set TASK_ID before starting refactoring
export TASK_ID="PROJ-123"
# All functions will automatically log to beads
record_refactoring "Payment" "Transaction" "class_rename"
update_refactoring_progress "Payment" "app/models/transaction.rb"
validate_refactoring "Payment" "Transaction"
6. Quick Reference
| Function | Purpose | Example |
|---|---|---|
record_refactoring |
Start tracking | record_refactoring "Old" "New" "class_rename" |
update_refactoring_progress |
Track file update | update_refactoring_progress "Old" "path/file.rb" |
validate_refactoring |
Check completeness | validate_refactoring "Old" "New" |
| Refactor Type | Key Layers to Check |
|---|---|
class_rename |
Model, Controller, Views, Routes, Specs, JS |
attribute_rename |
Model, Controller params, Views, Specs, JS values |
table_rename |
Migration, Schema, Raw SQL |
method_rename |
All call sites, Specs |
namespace_move |
File paths, Autoloading, All references |
More from kaakati/rails-enterprise-dev
flutter conventions & best practices
Dart 3.x and Flutter 3.x conventions, naming patterns, code organization, null safety, and async/await best practices
55getx state management patterns
GetX controllers, reactive state, dependency injection, bindings, navigation, and best practices
52tailadmin ui patterns
TailAdmin dashboard UI framework patterns and Tailwind CSS classes. ALWAYS use this skill when: (1) Building any dashboard or admin panel interface, (2) Creating data tables, cards, charts, or metrics displays, (3) Implementing forms, buttons, alerts, or modals, (4) Building navigation (sidebar, header, breadcrumbs), (5) Any UI work that should follow TailAdmin design. This skill REQUIRES fetching from the official GitHub repository to ensure accurate class usage - NEVER invent classes.
39mvvm-architecture
Expert MVVM decisions for iOS/tvOS: choosing between ViewModel patterns (state enum vs published properties vs Combine), service layer boundaries, dependency injection strategies, and testing approaches. Use when designing ViewModel architecture, debugging data flow issues, or deciding where business logic belongs. Trigger keywords: MVVM, ViewModel, ObservableObject, @StateObject, service layer, dependency injection, unit test, mock, architecture
36rails localization (i18n) - english & arabic
Comprehensive internationalization skill for Ruby on Rails applications with proper English and Arabic translations, RTL support, pluralization rules, date/time formatting, and culturally appropriate content adaptation.
34rspec testing patterns
Complete guide to testing Ruby on Rails applications with RSpec. Use this skill when writing unit tests, integration tests, system tests, or when setting up test infrastructure including factories, shared examples, and mocking strategies.
31