Podcast: Play in new window | Download
Subscribe: Apple Podcasts | Spotify | TuneIn | RSS
In this episode we talk about how to insulate your application at it’s boundaries? What in the world does that even mean?! We’re not talking about those boundaries where others aren’t allowed to touch your keyboard (although that’s a real thing). No, we’re talking about making sure you make your code easier to maintain over time by coding to interfaces or wrappers for third party libraries or external APIs. Come join us on another deep dive into Clean Code, and our (polluted) thoughts on the topic.
For the full show notes visit:
https://www.codingblocks.net/episode53
Video can be found on the episode page above or at:
Survey
Podcast News
Thanks to everyone that voted for us, think? we ended up in 3rd place
https://simpleprogrammer.com/podcast-awards/
Created a reddit!
https://www.reddit.com/r/codingblocks/
Grew out of the #imadesomething on our Slack channel, still figuring it out – but we’ve got some great moderators helping us out
Community Spotlight: Zac Braddy at The Reactionary
https://www.codingblocks.net/community-spotlight/the-reactionary/
Send us a SASE
https://www.codingblocks.net/swag
Winner of Clean Code for Episode 51
Philip Thompson
Clean Code – Boundaries
- Chapter written by James Grenning (Also wrote https://pragprog.com/book/jgade/test-driven-development-for-embedded-c)
- Focuses on practices and techniques to keep the boundaries of OUR software clean
- Boundaries are the separation between your code and 3p / Open Source packages, or code that doens’t exist yet (or services, interesting they don’t mention “services” as much…sign of the times?)
“We seldom control all the software in our systems.”
Using Third-Party Code
“There is a natural tension between the provider of an interface and the user of an interface”
* Provider strives for broad applicability, users have a specific need
* Advise passing around an abstraction around your system…avoid returning it from, or accepting it as an argument to public API
Exploring and Learning Boundries
- How do you start integrating a new 3p?
- Not our job to test the 3p
- Argue it’s in our best interest to write tests
- Keep the tests to validate functionality after upgrade
- Spending a day or two reading documentation to integrade a 3p? Definitely written in the days before “require()”
- Call these “learning tests”
Learning log4j Example
- End up with a reference implementation and a simple smoke test
From Will: http://www.slf4j.org/
Learning Tests are Better than Free
- The tests are “free”, you’d be doing the work anyway – and you have them around for smoke tests and future migrations
- With boundary tests, you’ll know when the 3p library changes in an incompatible way
- Without boundary, you might be tempted to not update 3p dependencies as often
Using Code that does not exist Yet
- Abstractions help work around code that hasn’t been written yet (Adapter pattern)
- Protects you from future changes
- Provides a convenient seam for testing
Clean Boundaries
- Code at the boundaries needs clear separations and tests that define the expectations
- We should limit our code’s dependencies on the boundaries using Wrappers and Adapters
- As Joe likes to say, push the weird stuff to the edges of our code
Question: When do you wrap, and when do you adapt?
https://en.wikipedia.org/wiki/Adapter_pattern
Resources we Like
“Clean Code”
http://amzn.to/2cryvJR
“Clean Code for JS”
https://github.com/ryanmcdermott/clean-code-javascript”
Tip of the Week
Joe: Hide your own selection of code in Visual Studio
Ctrl M, Ctrl H – Hide Selection: https://www.gofightnguyen.com/blog/visual-studio-shortcut-hide-selection (stolen from @Go_Fight_Nguyen and @msdevshow)
Allen: Want to create excellent reports with extreme levels of data flexibility?
PowerBI
https://powerbi.microsoft.com/en-us/
Michael: A more efficient way of deleting those pesky “orig” files from a merge conflict
find . -name “.orig” -delete vs find . -name “.orig” –exec rm {} \;
Cmd equivalent: del /s *.orig
Bonus!
“Git Aliases
https://git-scm.com/book/en/v2/Git-Basics-Git-Aliases”