d4ea931bf8
* feat(agents): add modular engineering rules from 2026 standards Add a rules directory with individual rule files derived from the Cal.com Engineering in 2026 and Beyond blog post. Rules are organized by section (architecture, quality, data, api, performance, testing, patterns, culture) following the Vercel agent-skills structure. Includes: - _sections.md defining rule categories and impact levels - _template.md for creating new rules - 14 individual rule files covering key engineering standards - README documenting the rules structure and usage Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> * feat(agents): consolidate DI and Repository+DTO docs into rules - Move di-pattern.md content to rules/patterns-di-pattern.md - Extract Repository + DTO section from knowledge-base.md into: - rules/data-repository-methods.md (method naming conventions) - rules/data-dto-boundaries.md (DTO location and naming) - Update knowledge-base.md to reference the new rule files - Delete old di-pattern.md file Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> * chore(agents): remove stub reference sections from knowledge-base.md The rules directory is self-contained with its own README, so these redirect sections are unnecessary clutter. Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> * refactor(agents): combine DI pattern rules into single file Merged patterns-di-pattern.md into patterns-dependency-injection.md to eliminate overlap and create one comprehensive DI guide. Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> --------- Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>
2.2 KiB
2.2 KiB
title, impact, impactDescription, tags
| title | impact | impactDescription | tags |
|---|---|---|---|
| Avoid O(n²) Algorithms - Design for Enterprise Scale | CRITICAL | Prevents performance collapse at scale | performance, algorithms, complexity, scale |
Avoid O(n²) Algorithms - Design for Enterprise Scale
Impact: CRITICAL
We build for large organizations and teams. What works fine with 10 users or 50 records can collapse under the weight of enterprise scale. Performance is not something we optimize later. It's something we build correctly from the start.
When building features, always ask: "How does this behave with 1,000 users? 10,000 records? 100,000 operations?"
Common O(n²) patterns to avoid:
- Nested array iterations (
.mapinside.map,.forEachinside.forEach) - Array methods like
.some,.find, or.filterinside loops or callbacks - Checking every item against every other item without optimization
- Chained filters or nested mapping over large lists
Incorrect (O(n²) - exponential slowdown):
// Bad: O(n²) - checks every slot against every busy time
const available = availableSlots.filter(slot => {
return !busyTimes.some(busy => checkOverlap(slot, busy));
});
// For 100 slots and 50 busy periods: 5,000 checks
// For 500 slots and 200 busy periods: 100,000 checks (20x increase!)
Correct (O(n log n) - scales gracefully):
// Good: O(n log n) - sort once, break early
const sortedBusy = [...busyTimes].sort((a, b) => a.start - b.start);
const available = availableSlots.filter(slot => {
// Binary search or early exit
const index = binarySearch(sortedBusy, slot.start);
return !hasOverlapAt(sortedBusy, index, slot);
});
Better data structures and algorithms:
- Sorting + early exit: Sort data once, break out of loops when remaining items won't match
- Binary search: Use for lookups in sorted arrays instead of linear scans
- Two-pointer techniques: For merging or intersecting sorted sequences
- Hash maps/sets: Use for O(1) lookups instead of
.findor.includeson arrays - Interval trees: For scheduling, availability, and range queries
Reference: Cal.com Engineering Blog