Reddit mentions of Working Effectively with Legacy Code (Robert C. Martin Series)

This is great. i'd like to add:

- it's very handy to keep your unit tests and integration tests in separate files like ModuleName.Unit.tests.ps1 and ModuleName Integration.tests.ps1 to keep things organized as your tests grow over time. If you don't do this, someone reading your code may have to read through every test to determine if a system is being changed each time they are executed.

- When writing integration tests, I've found the pester commands BeforeEeach and AfterEach are very useful for adding live data into external systems before executing the test itself. Some examples might be: Inserting rows into a database, creating AD objects or creating a file. Once the test has completed, the AfterEach function should be used to cleanup or fix any data that may have been left as a side effect of the test. (You might want to clone parts of your prod environment into an isolated test environment using powershell )

- Unit tests should be run frequently and finish executing extremely quickly (ideally in milliseconds.) Integration tests will take longer because they are supposed to deal with external systems/the outside world.

- Automated tests can themselves be refactored to keep them DRY and maintainable.

- It's fine to write utility functions to assist with reducing the amount of test code, as long as readability is not affected at all. "Clever" test code is so much worse than "clever" code without any tests. Been there, done that.

- I haven't properly dived into the Pester / classes problem yet but it looked messy a few years ago and required boilerplate. Would love to hear more about this.

- Object dependencies from 3rd party code is a separate issue, but they will be Integration tests. If objects don't have public constructors / interfaces then they weren't designed to be mocked or tested. Some code may not be possible to test.

For reference:

A really good book i've been reading is xUnit Test patterns: https://www.amazon.com/xUnit-Test-Patterns-Refactoring-Addison-Wesley-ebook/dp/B004X1D36K/ref=mt_kindle?_encoding=UTF8&me=

And the classic Working Effectively with Legacy Code which is amazing https://www.amazon.com/Working-Effectively-Legacy-Robert-Martin-ebook/dp/B005OYHF0A/ref=pd_sim_351_3?_encoding=UTF8&psc=1&refRID=JQG9XXQCMQ2R1K56JNWC

> on the product backlog to be prioritized and scheduled, or are those the kinds of things that should go on an impediment list?

Impediments are what make the team move slower. Sounds like Python or Jenkins has little impact on the team's productivity, so they should go in the product backlog. Jenkins related tasks could be considered impediments if the developers end up doing what automation is supposed to take care of.

> we've been actively trying to improve for a while now, but

Try proposing a Team Sprint

> the code is difficult to work with, not particularly maintainable, very complex, quite buggy in places and huge in scope

Working Effectively with Legacy Code proposes installing testing harnesses around modules before altering their implementation.

> Or is it possible for things that are on the impediment list to then also go on the product backlog? When are things on the impediment list worked on? Just when somebody has some slack time?

a Sprint Backlog is a continuation of small items, breaking down a PBI into smaller increments, and it belongs to the development team, not the PO. In this spirit, an impediment can be in the sprint backlog, but not in the product backlog. The scrum master owns the impediment backlog and the development team commits to this in planning (the Daily Standup is for planning, so it's a good time to commit to tackling an impediment).

It seems like your team handles impediments as second-class to PBIs. In Lean/TPS, there's a rule. If there's a choice between a task to be completed, and a task that can remove the blocker/impediment to that task, then by default, choose to remove the impediment first. Swarming and [Andon](https://en.wikipedia.org/wiki/Andon_(manufacturing) help with this.

Honestly from what I've seen, and I've been coding professionally for over a decade, no such an ideal environment with everything you describe applied everywhere doesn't really exist.

The best I've come across is organisations where the company culture is one of passion, continuous learning and improvement. In a place where people are skilled and care, not everything sucks, and the things that suck tend to get better over time.

All code seemed like a good idea to the author at the time they wrote it. They may have had goals that weren't explicitly "make this clean", or the one-clean code may now have enough other code around it that applying some additional abstractions would simplify things. If these abstractions had been applied earlier, it's highly possible that they would have been overengineering. Like it or not, a lot of development is working with and hopefully improving legacy code.

It can be hard sometimes but resist the urge to rewrite everything. Instead, when you come across some code you don't like, try to identify exactly what you don't like about it. There may be multiple things.

Pick whichever is the smallest, simplest change you can make. Implement only that change and nothing more. Initially this might be as simple as cleaning up some conditional logic, writing a missing test, or extracting a method or interface. Over time, the parts of the codebase you work with most frequently will be in better shape and it should be easier to change higher level structure where appropriate.

Sometimes chucking things out and rewriting is inevitable but being able to make small changes is important for several reasons.

• It's less risky. A small change has much less chance of making incorrect assumptions that burn you later.
  
• It's easier to back away from if it doesn't work out.
  
• All the code in the codebase provides value (almost) all the time. It's harder to end up in situations where you're blocked on writing code that provides actual business value (clean code in itself doesn't provide business value).
  
• It's easier for other people on your team to understand and learn from.
  
  You'll have a much easier time, and much more fun if you can get comfortable getting dirty with code you don't like.
  
  There's a couple of good books I always suggest to people in this situation.
  
  Working Effectively With Legacy Code by Michael Feathers https://www.amazon.com/Working-Effectively-Legacy-Robert-Martin-ebook/dp/B005OYHF0A/ref=mt_kindle?_encoding=UTF8&me= and Refactoring: Improving the Design of Existing Code by Martin Fowler https://www.amazon.com/Refactoring-Improving-Existing-Addison-Wesley-Technology-ebook/dp/B007WTFWJ6/ref=pd_sim_351_1?_encoding=UTF8&pd_rd_i=B007WTFWJ6&pd_rd_r=VAYMVGWBAJ19REZTVRE8&pd_rd_w=sBy2z&pd_rd_wg=wTZty&psc=1&refRID=VAYMVGWBAJ19REZTVRE8 are both worth checking out.