- Code is complicated, hard to test, difficult to understand and can frustrate others.
- Writing cleaner code can save you from reimplementing software simply that you cannot understand.
- It’s an iterative process and there’s several principles to help you do that.
- Keep it Simple Stupid (KISS) tells us to avoid unnecessary complexity and reduce moving parts. The idea is to write for maintainability.
- Don’t Repeat Yourself (DRY) is about avoiding redundant implementations of the same function. You should think about refactoring.
- You Aren’t Gonna Need It (YAGNI), an Extreme Programming principle, says we should stick with the requirements and avoid adding unneeded features or functions.
- Composition over Inheritance asks us to take care when applying classes an inheritance in your design because it can lead to inflexible code.
- Favoring Readability reminds us that writing software is like writing prose. Organize your code as if you’re writing a novel.
- Practice Consistency tells us to stick with our decisions throughout the project. Keep the same format, implementation flow and design principles.
- Consider How to Test a solution before writing it, or at least while writing. It helps you avoid traps that can unnecessarily complicate the code base.
- Data models change and evolve with your application.
- There’s plenty of tools that keep track of database schemas and automatically generate scripts to upgrade or downgrade them.
- It’s common for developers to run a migration at the start of their app before running app code.
- Our author explains two common problems with this approach.
- Modern day production deployments and horizontal scaling can get you into a race condition.
- You start assuming that new code will only ever run with the new schema.
- You can decouple migrations from code changes by disabling parallelism during this time.
- Make it a separate command or lock the database during the upgrade.
- We can easily implement locking ourselves in any language.
- Use Redis locks if you’re ok with something external to the DB.
- Use the DB itself by writing to an extra table to say that you’re upgrading it.
- Plan your deployment appropriately so you can run old code with new by making migrations additive in the short term.
- Using a script at startup that optionally performs the migration based on an environment variable integrates wel with Docker and cloud services.
- Upgrades of both code and data should be part of your testing BEFORE releasing to production.
- It’s up to us to learn how to apply design patterns and industry trends to our projects.
- What’s an Object Relational Mapper (ORM)?
- Why do I want to use one?
- Unexpected quirks of using ORMs. What are the tradeoffs?
- What about scalability?
9 Organizational Test Practices Guaranteed to Lower Quality and Customer Satisfaction
A contribution to freeCodeCamp.org examining test practices opposite to our usual goals.
I’ve been using some form of a database throughout the entirety of my career. Sometimes single-file databases, sometimes full servers. Sometimes testing them, sometimes designing them, but a lot of times I was optimizing them. Even when learning programming with my dad, most of the apps I built were about storing and managing some type of data.
With all those years of experience, I definitely understand enough to know that I’m by no means an expert at any of it. There are several (an understatement) mechanisms by which folks make the best use of their database servers, almost all of them are tradeoffs in memory usage, space, look-up times, results retrieval, backup mechanisms, etc.
As expected, each database mechanism has their own quirks and optimizations, but the common theme is the language which you use to retrieve information: Structured Query Language (SQL). Different database engines implement different extensions to this language, some of which add powerful functionality, some of which just add confusion. But in general, SQL has been very successful in standardization across the industry.
This next chapter in the Practicality Beats Purity series covers the tradeoffs when using direct SQL queries to a database vs programming language abstractions that do it for you, like ORMs.Continue reading
In recent years there’s a growing trend to move away from large all-in-one applications. These “monoliths”, developed with one codebase and delivered as one large system, are hard to maintain. In their place, the industry now favors splitting-off the component systems into individual services. As separate “microservices”, they perform the smallest functions possible grouped into logical units. They are independent deliverables, deployable, replaceable and upgradeable on their own.
Going further into the Practicality Beats Purity series, this article will cover the implications of transitioning to a microservices architecture.Continue reading
Continuing on the Practicality Beats Purity series, today we’re talking about modularity. While written with python in mind, the discussion here applies to any language that’s highly modular and with a large ecosystem.
As is touted frequently, python is quite famous for being a “batteries included” language with a vast ecosystem of modules and packages that provide almost every possible utility or function you’ll ever need. When building large applications, it’s a great idea to make use of this environment and not reinvent the wheel. This makes rapid development and prototyping real easy.
However, you must keep in mind that every new dependency added is one more variable that you have little to no control over. While you may not write the code yourself, there’s still cost incurred in keeping up with the most recent versions of your dependency and watching for security flaws and their respective fixes. It’s also important to pay attention to the size of the community around those dependencies, their interaction with other modules, responsiveness to reported bugs, and the size of supporting documentation both official (like read-the-docs) and unofficial (like stack overflow).
Following we discuss some of the costs.Continue reading
A few hours later, I find myself sitting in the “comforts” of my cubicle. The discussion replaying over and over in my head: “An interface with this behavior will integrate with most common language libraries, with no special client code”, I said. The response was: “But then it’s not a
I’ve spent many years of my career involved in buzzword dogma discussions. It’s present at all levels of software development, from basic principles, to scheduling, to implementation, its interfaces, its tests, the execution, the infrastructure that runs it and its release mechanisms. Most of the time, people lose track of why or what they are building in favor of claiming they are using some common buzzword, regardless of the effects on architecture, ease of use, customer experience or maintenance costs. My experience shows they don’t even know why the buzzword technology does things a certain way or why someone chose it in the first place. Factual or data-based counterargument results in an almost “religious” discussion and even shaming.
Given today’s ease of communication and the ability to share our experiences, it’s great that we try to educate other folks on the problems we typically face throughout our lives and careers. Especially the principles used in managing their solutions.Continue reading