Gather 'round kids, story time. I was at ATI (nowadays AMD) back in 2004-2007. At the time ATI had the reputation for poor OpenGL drivers. NVIDIA was ahead in perf and features. They decided to rewrite the OpenGL driver from scratch. A terrible decision.https://twitter.com/johnsundell/status/1018101018805096450 …
-
-
Also see "Second System Syndrome" https://en.m.wikipedia.org/wiki/Second-system_effect … +1, but (occasionally) the evolutionary path can take an infinite amount of time and dynamite is truely the only way forward
-
Yes. But that's quite rare. Much more rare than "we rewrote it because we like the smell of fresh codebase in the morning" :)
-
My personal experiences don’t necessarily agree. I have seen equal amounts of a) juniors eagerly rewriting from scratch good systems because they didn’t understand complexities but also b) people terrified of making huge changes bordering on rewrote -> which resulted in code rot
-
My personal favorite was some build system without (almost) any reflection or automatic serialization glued from Perl, Python, I think some Java, few in house DSLs and many different C++ libraries and executables barely connected. Any changes were just incremental refactors
-
And they usually added even more complexity. :) This was extreme but sometimes you really have to start from scratch and problem could be orders of magnitude simpler… But reasons are same: people afraid of touching and understanding complexity
-
Yeah good point. Fear of understanding/change can cripple. I was just advocating for "if you need to rewrite, then a big refactor might be better than starting from scratch" (does not throw away knowledge). "Just do nothing" is bad as well :)
-
Refactoring when you don't understand a system is a bad idea too. Building the understanding is #1 requirement in working toward a solution.
-
But there is a difference between understanding existing system vs understanding the problem. If eg a new person who wrote 5 good production particle simulation systems in past joins company,I would not force them to spend a year reading huge hacky legacy one instead of rewriting
- 4টি আরও উত্তর
নতুন কথা-বার্তা -
-
-
And sometimes not obvious reasons can be made much more obvious with good documentation. So I guess they're doomed to remain far from obvious.
ধন্যবাদ। আপনার সময়রেখাকে আরো ভালো করে তুলতে টুইটার এটিকে ব্যবহার করবে। পূর্বাবস্থায়পূর্বাবস্থায়
-
-
-
I extract old design or implementation details by having the team walk through the codebase and add comments w/ “tags” that call out features & concerns. During design of the new system you can grep the old code for tags to ensure you don’t miss anything.
ধন্যবাদ। আপনার সময়রেখাকে আরো ভালো করে তুলতে টুইটার এটিকে ব্যবহার করবে। পূর্বাবস্থায়পূর্বাবস্থায়
-
লোড হতে বেশ কিছুক্ষণ সময় নিচ্ছে।
টুইটার তার ক্ষমতার বাইরে চলে গেছে বা কোনো সাময়িক সমস্যার সম্মুখীন হয়েছে আবার চেষ্টা করুন বা আরও তথ্যের জন্য টুইটারের স্থিতি দেখুন।
Refactoring, reworking and properly maintaining a code base is almost always the better option 