Це відео не доступне.
Перепрошуємо.
Avoiding Legacy. Keeping your Codebase Evergreen🌲
Вставка
- Опубліковано 14 сер 2024
- Nobody wants their codebase to turn into a brownfield mess having to use outdated technology. Here are 3 tips for keeping your codebase evergreen.
🔗 EventStoreDB
eventsto.re/co...
🔔 Subscribe: / @codeopinion
💥 Join this channel to get access to a private Discord Server and any source code in my videos.
🔥 Join via Patreon
/ codeopinion
✔️ Join via UA-cam
/ @codeopinion
📝 Blog: codeopinion.com
👋 Twitter: / codeopinion
✨ LinkedIn: / dcomartin
📧 Weekly Updates: mailchi.mp/63c...
My architect would really need to watch this video
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.
DISTRIBUTED Micro TurdPiles please 😁
@@michaelrall8142 to be fair turd pile is a great illustrative phrase to substitute for encapsulation and coupling.
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.
Often times I would create a shim.
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.
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.
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)
Thank you for the great tips as always 😊
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.
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 :)
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.
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.
Thanks for the great videos
I wish this video had more about testing though.
Same, I appreciate the notes on dependencies and boundaries but was really hoping to hear Derek's perspective on regression test automation.
Good suggestion! I'll get a video out there about that topic
@@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.
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?
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.
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! :)
Too obvious: do good things, don't do bad things. Do it your own way that nobody knows.