We all know about best practices. But what does it take to really mess up a project? Well, for starters, you do EVERYTHING wrong. You don’t just ignore one or two best practices, you ignore them all. By evaluating the mess you can get yourself into by ignoring best practices, I think we can all learn better why these recommendations exist.
Several weeks ago, I was talking to a programmer and we got into a discussion about the importance of software architecture. I maintained that having a defined architecture is important regardless of the team size, the person I was talking to asserted that architecture wasn’t necessary when there was just one person involved.
But here’s the thing. All software has an architecture. Even the most junior of programmers has an idea of how code should fit together. At issue isn’t really about architecture. It is about having a defined architecture, based on experience and best practices, that will allow the team to develop the software in question as efficiently as possible. Software architecture, at its core, says, “this is how we build software.”
To find the reasons why software architecture matters, it is helpful to think about what happens when there isn’t any defined architecture in place. For the purposes of this article, I’m going to generalize on how architecture impacts teams and where appropriate show why that is also important when your team is just you.
Have you ever noticed how, when QA reports a “defect” developers tend to bristle? I first noticed this in myself a few years ago. Now that I’m functioning as a Scrum coach, I’m noticing it in others. Is there a way to have some kind of quality checking in our code that doesn’t make the whole process feel so adversarial? I think so.
I believe there are some adjustments that need to be made organizationally and personally that will bring these two groups together.
But first, why does this problem exist in the first place?
The story goes that there were two men, Joe and Frank, who were camping out in the woods when a bear showed up in the camp. Terrified, they decided the best they could do would be to stay perfectly still until the bear left. Hopefully, the bear wouldn’t notice them. As the bear was poking around, Joe says to Frank, “What are we going to do if this doesn’t work?” Frank says, “Run!” Joe says, “You really think we can out run a bear?” Frank says, “I don’t need to out run the bear. I only need to out run you.”
I’ve written that I’m using Angular to write a couple applications before. One at my main contract and a couple side projects. I know I’m kind of late to the game, but one of my frustrations with the documentation around Angular is that very little of the sample code that you can find on the Internet shows the sample using anything close to a best practice. That’s the danger of writing about something you are too familiar with.
So, in this post, I’d like to cover a few best practices that I’ve discovered, or implemented in my own code, and explain in a bit more detail what is going on inside the controller. I concentrate on the controller because this is a place that will be used the most. Once you understand it, the rest of what you need to know will trickle down to services, factories, and directives.