Mistakes engineers make in large established codebases - online edit of handbook/troggle/trognotes.html
This commit is contained in:
Philip
2025-01-07 20:16:32 +00:00
committed by Expo on server
parent 55181d8fdb
commit 8bf6ae1488

View File

@@ -67,6 +67,7 @@ the <a href="trog2030.html">2030 plan</a>, <a href="trogspeculate.html">architec
the characteristics of code and of organisations that mean that it is a good idea to give up, and if so how to
manage the rewrite. The answers are "almost never" and "don't": as explained in <a href="trogkill.html">this summary of the book 'Kill it with
Fire'</a>.
<p>"...you cannot split up a large established codebase without first understanding it. I have seen large codebases successfully split up, but I have never seen that done by a team that wasnt already fluent at shipping features inside the large codebase. You simply cannot redesign any non-trivial project ... from first-principles", <a href="https://www.seangoedecke.com/large-established-codebases/"><em>Mistakes engineers make in large established codebases</em></a>, Sean Goedecke.
<p>Replacing old systems, and changing their architecture, while keeping them operating continuously, is now
<a href="https://martinfowler.com/articles/patterns-legacy-displacement/transitional-architecture.html">a well-understood