Distributing complexity in huge python projects.
summary
Argues that when full redesign is impossible, complexity is best measured and redistributed rather than blindly refactored; uses tools like radon, SonarCloud and a custom dependency-instructor to count lines, functions/classes, imports and dependency coupling; demonstrates extracting single entry points to produce standalone modules (example: 2700 files/21 apps → 750 files/11 apps) and shows type-hint cleanup cutting ~40,000→30,000 lines and external deps (560→500), with container-friendly builds and measurable gains.
AI-written summary · about
chapters (10)
- 0:00Introduction and speaker background
- 1:51Understanding complexity types
- 8:57Measuring project complexity
- 18:09Refactoring strategies and pitfalls
- 23:43Increasing abstraction levels
- 25:30Modularity and monolith breakdown
- 30:54Import control and structural clarity
- 33:53Type hints and their impact
- 38:09Documentation and LLM role
- 40:35Final recap and Q&A
related talks
32mKeeping your code strong
45mConquering complexity: refactoring JavaScript projects
39mArch. App: Prioritizing Technical Debt as if Time and Money Matters
40mConquering Complexity: Refactoring JavaScript Projects
21mTeach Your Old Code New Tricks: Automating Code Quality in Large Projects
32mPrioritizing Technical Debt as if Time and Money Matters
51mSoftware Archeology and The Code Of Doom
50mGuide Refactorings With Behavioral Code Analysis