6 ms·

> I love legacy codebases. > A legacy codebase means that the product is performing well. It means that I can often make immediate and impactful improvements.

> I love legacy codebases. > A legacy codebase means that the product is performing well. It means that I can often make immediate and impactful improvements. Wow. This person must have worked on very different legacy codebases than me. Legacy Javascript code, to me, is something that I do not want to touch with a 10 foot pole, because every little piece of it can be intertwined with and used by many other hidden places. Plus, I've never found a legacy JS codebase that has a robust test suite, so any refactoring I do can be hard to test and verify. From a practicality perspective, I get that the best programming language is the one you can use to build your product, but I tend to long for languages like C# or even Go when I'm trying to deliver a product on a team with 10+ people. Static typing really helps when you're interfacing with someone elses code, and Typescript only aids this point. Maybe if your target audience is genuinely 10 year olds learning to code, fine. But also if you're building a serious product for a company, please don't choose a "Janky programming language" because I really don't want to have to debug it after you left before really thinking about sanitizing user input. I feel like, in the hands of a really talented programmer, they can be super productive in PHP or Javascript or really anything. But I've just had a lot of bad experiences with quickly written, undocumented code.

nicoburns 4y ago
They said impactful champagnes, and that the product is performing well. Nothing in your comment contradicts that.
- slater 4y ago
  champagne, ey? :D
larve 4y ago
Author here, thank you for reading the article and taking the time to comment. Every legacy codebase I have worked with was actually a successful business. That probably plays a big role in why I enjoy working with them. The job is not easy, and in one case (800kLOC of PHP without a single function), I had to rewrite everything from scratch. Legacy JS with its strata upon strata of framework du jour and jquery and porous language are indeed notoriously annoying. To be fair, I just isolate the legacy JS to its own little DOM sections, and then introduce a new framework in parallel until I can nuke the old code out. Revamping a legacy JS codebase often comes with a design revamp as well, so it often becomes a matter of strangling [1] out the old API. I do really enjoy how typescript allows me to gradually introduce typing and leverage static analysis for more adventurous refactoring. I use golang, rust and typescript as my daily drivers lately, but I must admit that my most horrendous legacy codebase experience was a tiny 20kLOC go program that was just a mess of concurrency nonsense. PHP codebases have a certain "flatten it out and don't be clever" style to them that make for easy strangling [1]. Highly abstracted codebases where the abstraction doesn't fit the use case anymore, or the abstraction was thoroughly eroded by generations of misinformed developers are much trickier. What language I would use to greenfield a new application would depend highly on the experience of the team, but my usual approach is "whatever we are already using". [1]: https://www.redhat.com/architect/pros-and-cons-strangler-architecture-pattern#:~:text=The%20Strangler%20pattern%20is%20one,system%20pass%20through%20the%20facade https://www.redhat.com/architect/pros-and-cons-strangler-arc....
- CTmystery 4y ago
  You have to be the most sensible programmer I've run into here. If I could plus one a single section of your post it would be the "Good software is <bullets> none of which depends on the language". Had me nodding excitedly in agreement, subduing the urge to shout YES at my screen.
droptableorders 4y ago
> From a practicality perspective, I get that the best programming language is the one you can use to build your product, but I tend to long for languages like C# or even Go when I'm trying to deliver a product on a team with 10+ people. Static typing really helps when you're interfacing with someone elses code, and Typescript only aids this point. This. Languages like Java and C# are great for teams and codebases starting to scale out. Hence their popularity in enterprise.
- larve 4y ago
  I think Java and C# are indeed my favorite languages for huge projects with wildly varying developer competence. Python is probably my most hated for that situation.
SicSemperUranus 4y ago
> never found a legacy JS codebase that has a robust test suite, so any refactoring I do can be hard to test and verify. Wouldn't you just... make a test suite?
- phailhaus 4y ago
  If there is no pre-existing test suite, it is extremely difficult to know what is the right expected behavior that should be tested, and what is incidental to the implementation.
  - resonious 4y ago
    Hopefully there is a product team or actual internal users you can interface with to know the expected behavior. I'd expect to at least be able to write some integration-style tests that can ensure everything works from the user's perspective. If you're so disconnected that you don't know the user's perspective or have no way to see the program in action, then ..best of luck!
    - madeofpalk 4y ago
      Defining big obvious functionality is usually easy to get from people. It's all the finer details that people might not know. You might have a feature that's been relatively untouched for a while, but people still use, so the devs have either left or forgotten from their past "drive-by development".
- theonething 4y ago
  > just Legacy code bases are more often that not huge monstrosities. Maybe you do start with some tests and increment, but there's no "just" involved.
- jamesfinlayson 4y ago
  Where possible anyway. I tried adding tests to a legacy AngularJS application (it was in the process of being phased out but was still business critical). I sunk days into trying to get a test to run, let alone pass, before giving up and deciding that eventual replacement was going to be quicker than finding good AngularJS documentation.
Phlarp 4y ago
Everything you say is well and good, but the businesses with the legacy codebase (PHP or Javascript) are still trying to pay someone to work on their systems, and quite frankly, their money is the same shade of green.
- wiseowise 4y ago
  Their culture is different though. Prepare to fight for every minor technical improvement.
  - larve 4y ago
    That's actually not my experience. I pretty much always had complete technical freedom when brought in as a freelance on e-commerce PHP applications. As long as it enables the business, they let the nerd do the gobbledigook.
tyingq 4y ago
>Typescript only aids this point Though, being optional, it creates its own problems that are time consuming. I have spent a fair amount of time trying to find the right versions of npm dependencies and accompanying @type/whatever packages that work together and aren't saddled with open vulnerabilities, etc.
- joe_guy 4y ago
  An @type package is dev time only and contains only exploit free definition files.
  - tyingq 4y ago
    That's not what I meant. What I meant was finding a matching/working pair of xyz and @type/xyz that were new enough not to have either vulnerabilities (in the main package) and also worked with other packages that were new enough also. It introduces new dependencies and into an already chaotic chain. Like 1.2.3 of xyz has issues (or dependencies with issues), and you need 1.2.4, but the @type package won't yet work with 1.2.4. Also, not just vulnerabilities. Bugs, whatever.
irrational 4y ago
What websites are you working on that have 10+ people? In my nearly 25 years working as a web developer, I don't think I've ever worked with more than three other developers at one time.
- 8n4vidtmkvmk 4y ago
  actual webapps can have hundreds of SWEs
- madeofpalk 4y ago
  There's more than 10 developers working on Grafana (i work at grafana).
- GrumpyNl 4y ago
  Over 10 people worked on the solution for utility meter readings in the Netherlands. All PhP, MYSQL and jQuery. Over 80% of the utility companies were served through this platform.
8n4vidtmkvmk 4y ago
hella legacy js and php is the opposite of intertwined by it's very nature. every page is isolated. one php file per page. probably some inline js script tags. easy refactor. and if they're actually using frameworks and libraries.. well that's just being a good programmer. if you don't know how it works, leave it alone and go rewrite a piece that doesn't require rewriting something core
thorin 4y ago
The code you're writing right now, is a legacy codebase soon enough, if it's good and valuable enough and to survive a few years.

nicoburns 4y ago

They said impactful champagnes, and that the product is performing well. Nothing in your comment contradicts that.

slater 4y ago
champagne, ey? :D

larve 4y ago

Author here, thank you for reading the article and taking the time to comment. Every legacy codebase I have worked with was actually a successful business. That probably plays a big role in why I enjoy working with them. The job is not easy, and in one case (800kLOC of PHP without a single function), I had to rewrite everything from scratch. Legacy JS with its strata upon strata of framework du jour and jquery and porous language are indeed notoriously annoying. To be fair, I just isolate the legacy JS to its own little DOM sections, and then introduce a new framework in parallel until I can nuke the old code out. Revamping a legacy JS codebase often comes with a design revamp as well, so it often becomes a matter of strangling [1] out the old API. I do really enjoy how typescript allows me to gradually introduce typing and leverage static analysis for more adventurous refactoring. I use golang, rust and typescript as my daily drivers lately, but I must admit that my most horrendous legacy codebase experience was a tiny 20kLOC go program that was just a mess of concurrency nonsense. PHP codebases have a certain "flatten it out and don't be clever" style to them that make for easy strangling [1]. Highly abstracted codebases where the abstraction doesn't fit the use case anymore, or the abstraction was thoroughly eroded by generations of misinformed developers are much trickier. What language I would use to greenfield a new application would depend highly on the experience of the team, but my usual approach is "whatever we are already using". [1]: https://www.redhat.com/architect/pros-and-cons-strangler-architecture-pattern#:~:text=The%20Strangler%20pattern%20is%20one,system%20pass%20through%20the%20facade https://www.redhat.com/architect/pros-and-cons-strangler-arc....

CTmystery 4y ago
You have to be the most sensible programmer I've run into here. If I could plus one a single section of your post it would be the "Good software is <bullets> none of which depends on the language". Had me nodding excitedly in agreement, subduing the urge to shout YES at my screen.

droptableorders 4y ago

> From a practicality perspective, I get that the best programming language is the one you can use to build your product, but I tend to long for languages like C# or even Go when I'm trying to deliver a product on a team with 10+ people. Static typing really helps when you're interfacing with someone elses code, and Typescript only aids this point. This. Languages like Java and C# are great for teams and codebases starting to scale out. Hence their popularity in enterprise.

larve 4y ago
I think Java and C# are indeed my favorite languages for huge projects with wildly varying developer competence. Python is probably my most hated for that situation.

SicSemperUranus 4y ago

> never found a legacy JS codebase that has a robust test suite, so any refactoring I do can be hard to test and verify. Wouldn't you just... make a test suite?

phailhaus 4y ago
If there is no pre-existing test suite, it is extremely difficult to know what is the right expected behavior that should be tested, and what is incidental to the implementation.
- resonious 4y ago
  Hopefully there is a product team or actual internal users you can interface with to know the expected behavior. I'd expect to at least be able to write some integration-style tests that can ensure everything works from the user's perspective. If you're so disconnected that you don't know the user's perspective or have no way to see the program in action, then ..best of luck!
  - madeofpalk 4y ago
    Defining big obvious functionality is usually easy to get from people. It's all the finer details that people might not know. You might have a feature that's been relatively untouched for a while, but people still use, so the devs have either left or forgotten from their past "drive-by development".
theonething 4y ago
> just Legacy code bases are more often that not huge monstrosities. Maybe you do start with some tests and increment, but there's no "just" involved.
jamesfinlayson 4y ago
Where possible anyway. I tried adding tests to a legacy AngularJS application (it was in the process of being phased out but was still business critical). I sunk days into trying to get a test to run, let alone pass, before giving up and deciding that eventual replacement was going to be quicker than finding good AngularJS documentation.

Phlarp 4y ago

Everything you say is well and good, but the businesses with the legacy codebase (PHP or Javascript) are still trying to pay someone to work on their systems, and quite frankly, their money is the same shade of green.

wiseowise 4y ago
Their culture is different though. Prepare to fight for every minor technical improvement.
- larve 4y ago
  That's actually not my experience. I pretty much always had complete technical freedom when brought in as a freelance on e-commerce PHP applications. As long as it enables the business, they let the nerd do the gobbledigook.

tyingq 4y ago

>Typescript only aids this point Though, being optional, it creates its own problems that are time consuming. I have spent a fair amount of time trying to find the right versions of npm dependencies and accompanying @type/whatever packages that work together and aren't saddled with open vulnerabilities, etc.

joe_guy 4y ago
An @type package is dev time only and contains only exploit free definition files.
- tyingq 4y ago
  That's not what I meant. What I meant was finding a matching/working pair of xyz and @type/xyz that were new enough not to have either vulnerabilities (in the main package) and also worked with other packages that were new enough also. It introduces new dependencies and into an already chaotic chain. Like 1.2.3 of xyz has issues (or dependencies with issues), and you need 1.2.4, but the @type package won't yet work with 1.2.4. Also, not just vulnerabilities. Bugs, whatever.

irrational 4y ago

What websites are you working on that have 10+ people? In my nearly 25 years working as a web developer, I don't think I've ever worked with more than three other developers at one time.

8n4vidtmkvmk 4y ago
actual webapps can have hundreds of SWEs
madeofpalk 4y ago
There's more than 10 developers working on Grafana (i work at grafana).
GrumpyNl 4y ago
Over 10 people worked on the solution for utility meter readings in the Netherlands. All PhP, MYSQL and jQuery. Over 80% of the utility companies were served through this platform.

8n4vidtmkvmk 4y ago

hella legacy js and php is the opposite of intertwined by it's very nature. every page is isolated. one php file per page. probably some inline js script tags. easy refactor. and if they're actually using frameworks and libraries.. well that's just being a good programmer. if you don't know how it works, leave it alone and go rewrite a piece that doesn't require rewriting something core

thorin 4y ago

The code you're writing right now, is a legacy codebase soon enough, if it's good and valuable enough and to survive a few years.