I think Google even has a policy that almost all parts of code in their mono-repo needs to be rewritten (not just refactored) every 2 years or sth like that.
I guess nobody felt like rewriting Google Reader!
Refactor vs. Rewrite
91–100 of 123 posts
Re: Refactor vs. Rewrite
#92IME whether you rewrite or refactor, the lesson is the same: You have to grind your way into the good architecture. It doesn't become good because the code is fresh, but because you have battle scars to show. And a success story in that case comes from having a complete learning loop. In a lot of orgs the learning itself is argued against for one reason or another - development proceeds with as little feedback on qua…
Have you heard of our lord and savior, Domain Driven Design? Here are the blue and red books.
Are these books Evans(blue) and Vernon(red)?
Re: Refactor vs. Rewrite
#93> ... We had very poor test coverage in the areas most in need of refactoring because they were the oldest code, written before we established good test practices.
That's probably not a coincidence. I like to ask those most strongly opposed to test-first development how they refactor code. I have yet to get an answer the leads to anything other than a rewrite at some point.
Of course, the rewrite might be coming for the test-first codebase as well. But in that case, the test suite can be leveraged to great effect as a detailed specifications document. This is one of the benefits of test suites that doesn't get enough attention.
Re: Refactor vs. Rewrite
#94Earlier quoted context omitted.
The lack of static typing does not make refactoring incredibly hard or difficult. In fact, I would argue it's even easier due to the way dynamically-typed languages pass around data. Really, as long as you follow some basic rules and don't propagate complexity into your system too-much, refactoring is a breeze. When I do it, the types are inconsequential almost. The things I do worry about when refactoring is develop…
Any halfway decent static type system would capture that nullability and prevent accidentally using a null value without checking, so you seem to have slightly undermined your own argument here.
Static type systems don't necessarily prevent accidental null value usage. Not sure where you get that impression?
However, for initialized variables, nulls (or None) was an example I used as that is the common one in python and conveys the point rather than language details. All of the "decent static type" systems I'm aware of have the same issue with undefined values that break behavior. E.g. zero's as integers, empty strings.
Heck even in C# where where you have a Nullable type, it gets abused more often than used legitimately and is seen as a nuisance by most developers. Not only that, but even with that static type system you mention, initialized variables are a big problem. Hence all the null-reference exceptions that are all-too common.
Re: Refactor vs. Rewrite
#95> ... We had very poor test coverage in the areas most in need of refactoring because they were the oldest code, written before we established good test practices. That's probably not a coincidence. I like to ask those most strongly opposed to test-first development how they refactor code. I have yet to get an answer the leads to anything other than a rewrite at some point. Of course, the rewrite might be coming for…
How is this a test-first argument? You can write tests at anytime, bad discipline is bad discipline. I've never worked somewhere that didn't write tests because "they didn't write them first", they didn't write them because they were an immature organization.
My current job leaves it up to the developers, and most don't write tests first. Its no miracle that despite us not writing tests first, all changes have their unit tests, integration tests, and end to end tests. This is due to the fact its baked into our SDLC and enforced in code review.
Re: Refactor vs. Rewrite
#96> ... We had very poor test coverage in the areas most in need of refactoring because they were the oldest code, written before we established good test practices. That's probably not a coincidence. I like to ask those most strongly opposed to test-first development how they refactor code. I have yet to get an answer the leads to anything other than a rewrite at some point. Of course, the rewrite might be coming for…
Wait, this is confusing. By test-first do you mean TDD? Even if you don't do TDD you gotta have tests before refactoring, I've never seen anyone writing tests after refactoring. I don't think this is controversial at all. Anyone please correct me if I'm wrong.
(I've seen refactoring without testing but that's another matter)
Re: Refactor vs. Rewrite
#97A really undervalues idea in software development is architecting software for rewriting it in the future. If you make your software small and well defined, then it becomes a reasonable investment to simply rewrite it from scratch. This is a great talk about this idea: https://vimeo.com/108441214
Optimise for Deletion! I always say this, but it's difficult to get people to understand just how important a concept this is.
Re: Refactor vs. Rewrite
#98So they got off of Elixir and microservices, but their introduction of Typescript and GraphQL didn't pay off like they hoped, and now they need to get off GraphQL. I think the lesson of "Choose boring technology" applies here. One of the reasons rewrites are risky is that very often the new tech doesn't live up to expectations.
If the business model is boring, you’ll need complex technology to compensate. If your business model is complex like in a lot of enterprise software, you should strive to keep the technology as simple as possible. Simple doesn’t mean to not use complex or cutting edge things IMO but to be conservative in using things that push the cognitive load of your collective team. A 10 person company probably doesn’t need a K8S cluster for a mobile app but I’d be surprised if there isn’t one for a 10k+ software company.
Re: Refactor vs. Rewrite
#99IME whether you rewrite or refactor, the lesson is the same: You have to grind your way into the good architecture. It doesn't become good because the code is fresh, but because you have battle scars to show. And a success story in that case comes from having a complete learning loop. In a lot of orgs the learning itself is argued against for one reason or another - development proceeds with as little feedback on qua…
I feel like you have denied the existence of people who are capable of writing down a good architecture on the first try, without all the grinding.
[deleted]
Re: Refactor vs. Rewrite
#100So they got off of Elixir and microservices, but their introduction of Typescript and GraphQL didn't pay off like they hoped, and now they need to get off GraphQL. I think the lesson of "Choose boring technology" applies here. One of the reasons rewrites are risky is that very often the new tech doesn't live up to expectations.
Yes but they were able to add lots of keywords to their resumes so it wasn't a complete loss.