My architect would really need to watch this video

@victormadu1635

24 күн бұрын

I don't know why I find this funny

Yes please do the Video about the Migration !

MicroTurdPiles its going to be the next big thing.

@michaelrall8142

23 күн бұрын

DISTRIBUTED Micro TurdPiles please 😁

@awright18

23 күн бұрын

@@michaelrall8142 to be fair turd pile is a great illustrative phrase to substitute for encapsulation and coupling.

Personally speaking Hexagonal Architecture (Ports & Adapters) solved the issue once and for all for us. We picked PHP as our programming language, and we wrote our services' logic in the Domain, then we used frameworks (i.e. Codeigniter, Slim, Lumen and Symfony) and 3rd party packages/plugins in the infrastructure part of the app (Adapters' implementation) and this way we only changed/updated our "core" logic when there's a major PHP release which luckily doesn't happen quite often, besides they usually give enough notice before that happens which gives us enough time to rewrite, if need be! And, as I mentioned, we don't rely on frameworks or 3rd party packages at all inside the Domain, instead we only use them "minimally" and "carefully" in the infrastructure part.

Thank you for the great tips as always 😊

This video is informative. I say that as someone who is aligning with you because of my own experience. I think a lot of developers are sadly more used to filling in implementation rather than maintaining the structure so that it is "fresh" throughout its lifetime. They are not very used to greenfield system design.

3:40 If you find yourself in the situation in which you have a dependency and very diverse coupling to it (for example, you use 20 different classes from that dependency in 50 different cases), you can have a look into the "Facade"-pattern. The facade will make the relation between your code and the dependency become appearant. That does not only help you replacing the dependency when its time comes. It also makes your architecture more understandable.

@CodeOpinion

18 күн бұрын

Often times I would create a shim.

Great points, that also popped up during my 20y career. Actually I got a project migrating/updating (someone elses) turdpile from .NET 4.5/4.7/Core 3.1 etc. to NET8, so a video about your experience and your approach would be very interesting. Especially covering the two areas of "technical" updates and "architectual" updates and how to approach them.

2:53 One thing I do to make sure I can keep the code base clean is to make sure that tests are not coupled to implementation details. You mentioning PDF. A system I was maintaining, the code to generate PDFs would receive a data structure representing all information to go into the generated PDF. The test code would just call those functions with specific inputs, writing the PDF to file, and compare against a snapshot. Snapshot testing is generally something I avoid, as are tests that depend on saving files to the file system. But perfect for this purpose it was perfect. If I needed to change the PDF library, the tests would still tell me if I had implemented it correctly (or a package update didn't break behaviour)

Thanks for the great videos I wish this video had more about testing though.

@LarsKemmann

24 күн бұрын

Same, I appreciate the notes on dependencies and boundaries but was really hoping to hear Derek's perspective on regression test automation.

@CodeOpinion

24 күн бұрын

Good suggestion! I'll get a video out there about that topic

@LarsKemmann

24 күн бұрын

@@CodeOpinionSince you're so open to suggestions 😁 how about another video on the whole topic of software quality assurance? Like, how to systematically infuse quality into the development process. I feel like there's lots of discussion around mechanics of testing, code reviews maybe even, but there's not a lot around how to ensure that a team is consistently producing quality work.

@CodeOpinion

24 күн бұрын

Also a really good topic!

Hi Derek, thanks for this video, I would like to know more about the migration process. Can you please make a video for this?

Make it part of your planning is probably the most important part. idk for you guys but most of the time we just let our services live and forget about them until it's just too late. If you don't take the time to update your code and to keep up with dependency changes, you gonna fall behind really quick. Look at me, im still working with nodejs 8 and php 5.6 :)

@krumbergify

24 күн бұрын

Don’t pack your sprints full with feature development. Allow for some ”gardening”, it will help you understand your codebase better, keep it tidy and speed you up in the long run.

@joelv4495

23 күн бұрын

the node ecosystem is one of the worst for long-term maintenance though. Seems you can't leave something alone for more than 6 months without a ton of deprecation warnings.

In the book "Working effectively with legacy code", Michael C. Feathers defines legacy code as "code that is not tested". So, to avoid legacy, test your code! :)

Is it worth to abstract a dependency before you plan to migrate it? If that becomes a platform tool then probably yes. but if thats used only by couple of ppl? interface will get legacy-messy with time as well.

Too obvious: do good things, don't do bad things. Do it your own way that nobody knows.