mirror of
https://github.com/johndoe6345789/metabuilder.git
synced 2026-04-25 14:25:02 +00:00
- Introduced DOCUMENTATION_FINDINGS.md for a detailed analysis of project documentation, covering architecture, technology stack, completed features, and known issues. - Created security documentation in README.md and SECURITY.md, outlining security policies, best practices, and incident response procedures. - Added TESTING_GUIDELINES.md to establish unit testing best practices, including directory structure, parameterized tests, and test coverage enforcement.
5.7 KiB
5.7 KiB
Code Refactoring Guide
Strategic guides for modernizing and maintaining the MetaBuilder codebase.
Documentation
- REFACTORING_STRATEGY.md - Overall refactoring strategy and roadmap
- REFACTORING_QUICK_REFERENCE.md - Common patterns and quick lookup
- REFACTORING_ENFORCEMENT_GUIDE.md - Standards and best practices
- REFACTORING_CHECKLIST.md - Implementation checklist
Key Principles
Declarative Over Imperative
Prefer configuration over code:
// ❌ Bad - Hardcoded
const user = { name: 'John', role: 'admin' };
// ✅ Good - Declarative configuration
const user = loadUserFromConfig('john');
Minimal TypeScript
Keep TypeScript components small (< 150 LOC) and generic.
// ✅ Generic component
<RenderComponent config={componentConfig} data={data} />
// ❌ Large hardcoded components
const UserProfile = ({ user }) => { /* 500+ lines */ }
Database-Driven
Move configuration from code to database:
// ❌ Hardcoded routes
app.get('/users', (req, res) => { ... });
// ✅ Database-driven routes
const routes = await db.query('routes').get();
Multi-Tenant Aware
Always consider tenant isolation:
// ✅ Good - Filters by tenant
const data = await db
.query('data')
.where('tenantId', currentTenant.id)
.get();
// ❌ Bad - Ignores tenant
const data = await db.query('data').get();
Refactoring Phases
Phase 1: Analysis
- Identify components > 150 LOC
- Find hardcoded configuration
- Locate database-ignorant code
- Review multi-tenant handling
Phase 2: Planning
- Prioritize high-impact changes
- Design declarative alternatives
- Plan database schema updates
- Document migration path
Phase 3: Implementation
- Create generic components
- Move config to database
- Update Prisma schema
- Write/update tests
Phase 4: Testing
- Unit tests pass
- Integration tests pass
- E2E tests pass
- Multi-tenant scenarios tested
Phase 5: Documentation
- Update code comments
- Update architecture docs
- Update implementation guides
- Share learnings with team
Quick Reference
TypeScript Component Too Large?
→ Read REFACTORING_QUICK_REFERENCE.md
Want to Move Config to Database?
→ Read REFACTORING_STRATEGY.md
Need to Enforce Standards?
→ Read REFACTORING_ENFORCEMENT_GUIDE.md
Following a Checklist?
→ Read REFACTORING_CHECKLIST.md
Common Refactoring Patterns
Reduce Component Size
// Before: 300+ LOC component
export const UserManager = ({ users }) => {
// Component logic, rendering, validation, formatting...
};
// After: Generic component + config
export const RenderComponent = ({ config, data }) => {
return renderByType(config.type, config, data);
};
Extract to Lua
// Before: Business logic in TypeScript
const calculatePrice = (items) => {
return items.reduce((total, item) => {
const tax = item.price * 0.1;
return total + item.price + tax;
}, 0);
};
// After: Lua script
function calculatePrice(items)
local total = 0
for _, item in ipairs(items) do
local tax = item.price * 0.1
total = total + item.price + tax
end
return total
end
Make Components Generic
// Before: Hardcoded component
export const ProductForm = ({ product }) => {
return (
<form>
<input name="name" defaultValue={product.name} />
<input name="price" defaultValue={product.price} />
{/* More fields... */}
</form>
);
};
// After: Generic form builder
export const FormRenderer = ({ schema, data }) => {
return (
<form>
{schema.fields.map(field => (
<RenderField key={field.id} field={field} value={data[field.name]} />
))}
</form>
);
};
What to Refactor
High Priority ⭐⭐⭐
- Components > 200 LOC
- Hardcoded configuration
- Missing multi-tenant checks
- No test coverage
Medium Priority ⭐⭐
- Components > 150 LOC
- Repeated code patterns
- Complex conditional logic
- Limited error handling
Low Priority ⭐
- Components 100-150 LOC
- Code duplication in utils
- Simplified logic
- Full test coverage
Refactoring Checklist
Before starting any refactoring:
- Create a feature branch
- Write/update tests
- Document your changes
- Get code review
- Update documentation
- Deploy to staging first
- Merge to main
Success Metrics
After refactoring, aim for:
| Metric | Target | Notes |
|---|---|---|
| Avg component size | < 100 LOC | Easier to maintain |
| Test coverage | > 80% | Core logic tested |
| TypeScript LOC | < 30% of project | More declarative |
| Config in database | > 90% | More flexible |
Resources
- REFACTORING_STRATEGY.md - Detailed strategy
- REFACTORING_QUICK_REFERENCE.md - Quick lookup
- REFACTORING_ENFORCEMENT_GUIDE.md - Standards
Next Steps
- Read REFACTORING_STRATEGY.md for overall approach
- Identify refactoring candidates in your codebase
- Follow REFACTORING_CHECKLIST.md
- Refer to REFACTORING_QUICK_REFERENCE.md during implementation
- Use REFACTORING_ENFORCEMENT_GUIDE.md to maintain standards
Have questions? Check the full documentation index.