Refactor vs. Rewrite • Hacker News Board

Re: Refactor vs. Rewrite

#121

Post by twhitmore » Thu, Jun 04, 2020, 11:02 PM UTC

sdenton4 wrote: post #14

jeffbee wrote: post #12

Earlier quoted context omitted.

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.

No good plan survives first contact with the enemy... Less pithily, the good architecture will almost certainly end up with arbitrary patches and madness after 2 years of active use, if anyone cares about it at all... And then somebody will join and say 'This is a mess, we should refactor and/or burn it to the ground.'

Nonsense. Competent designers with 8 or 10 years experience should absolutely be capable of architecting a solid system that is cleanly extensible for forseeable business requirements.

Probably one huge confounding factor, however, is the continual drive by juniors (or supposed seniors who think like juniors) to use the latest & shiniest technologies. These of course these are unknown to the team, of questionable long-term suitability and introduced without knowledge of the "right" way to use them.

In the article the OP describes using Elixir without A) needing it or B) being able to handle its downsides. Plus many random versions of Angular and React. Plus the overheads of an excessive focus on SOA.

My emphasis in architecture is on using simple & strong tools, and delivering great architecture in the problem space. Configurability, extensibility and DSLs are my forte. I don't need a new language -- I know how to use the ones I've got.

Re: Refactor vs. Rewrite

#122

Post by r4mbini » Fri, Jun 05, 2020, 8:04 PM UTC

arkh wrote: post #119

r4mbini wrote: post #92

Earlier quoted context omitted.

Are these books Evans(blue) and Vernon(red)?

Yes. I think Vernon's is the best as it has more emphasis on the process and organisation instead of the code.

Interesting. I’ve only read the blue one, will get a copy of red. Thank you!

Re: Refactor vs. Rewrite

#123

Post by Chris_Newton » Sat, Jun 06, 2020, 12:07 AM UTC

jillesvangurp wrote: post #118

Chris_Newton wrote: post #83

Earlier quoted context omitted.

It seems to me that what you’re talking about there has more to do with having clear rules in the language for scope and modularity than to do with the type system.

Those clear rules are called the type system. The fact that it's static means the same stuff that the compiler uses to tell what is what may also be used to build syntax trees to facilitate transforming your code base from one valid state to another. It's impossible to do that with dynamically typed languages and at best you get some partial guarantees combined with some string replacing.

A crude but correct algorithm for renaming all instances of an identifier that refer to the same entity (variable, function, type, etc.) could be something like:

1. Locate all occurrences of that identifier in your code base.

2. In each case, determine whether this is the place the underlying entity is defined or a reference to an identity defined elsewhere. If defined elsewhere, locate that definition.

3. Change all occurrences of the identifier that relate to the same definition as the one you started with.

If you have clear rules for things like the scope of an identifier and how identifiers may be imported and exported across modules, there is nothing in that algorithm that is necessarily specific to static or dynamic types.

It’s true that knowing the types statically can make a difference in some cases. A common example would be object.method notation, because there the context matters: the method being identified depends on what type of object you have. If you can’t identify the type of the object in some way, via a static type system or otherwise, then maybe you can’t identify the method and its underlying definition either.

However, it’s worth noting that in these sorts of late-binding environments, the operation of renaming all occurrences of an identifier that relate to the same definition probably isn’t well-defined anyway. Before you can automate a refactoring operation, you need to specify exactly what it means, and in a situation like this, the specification is ambiguous.