Posts

In Coding, Nothing is Trivial

Image
  Imagine you're reviewing some code, as part of a Pull Request, and the developer has misspelt a variable. Or added a magic string instead of a constant. Or put the expected/actual parameters in an assertion the wrong way around (although it kinda doesn't matter because they're the same)? You can politely comment on it, and perhaps they will fix it up. But sometimes you might be met with resistance.  "It's not that important." To a degree, they're right. These are pretty trivial observations. There are probably bigger things to address, such as the logic, the architecture, the test coverage etc.  However, in coding, these trivial issues tend to come back to bite you, either as bugs, or as maintenance headaches. You don't want to nag people. You don't want to become a "clean code nazi". But you can firmly assert that you think a mistake is being made and that a potential issue could arise.  There are some things in coding that are a perso

Writing Good Acceptance Tests

Image
Acceptance tests can be used to verify end to end functionality in a way that is understandable to the business. They are very broad compared with unit tests, and when automated via a tool like Specflow, are based on a more natural language. It's important that we use this natural language to keep tests simple and concise, rather than trying to write long-winded "functional" tests. Good Gherkin Before writing Acceptance tests, learn about Acceptance Criteria Best Practices . The ability to write good Acceptance Criteria translates directly to Acceptance testing. They both follow the same standards and they can be written in the same way. We should attempt to apply these best practices apply to Acceptance tests as much as is practically possible, especially when it comes to grammar as this helps us stick to a standard. The most important thing is to remember that Acceptance tests should be written with the Given, When, Then syntax where: Given sets up a state, When is an a

Clean coding Tips: Access Modifiers

It seems to be by default that classes, methods, etc are created with the public access modifier. This is not actually the case, the default is internal class/private members, but public seems to be the de-facto choice by a lot of developers. If you're creating a public class - you have a big responsibility. Your code can now be used by anything else in the application, or even outside it. This means if you change the internal working of it, you will affect everything that uses it - and you have no control over what that is. This means a couple of things. Naming is always super important Naming of public classes and methods and their expectations should be crystal clear. Don't rely on comments to convey intentions. It must be highly obvious what the class is for, what it does, and how method parameters are used. It should be specific and adhere to the Single Responsibility Principle - one reason to change. If someone comes along and adds a parameter to one of your methods t

Why should I care about Quality? I'm a developer!

Image
OK, no developer wants to create bad quality code. But for most developers, quality is seen as something separate from development, something that is checked after the work has been done. It is something that QA do, after you throw your code over the fence. Thinking about quality at during development is a burden, slowing down the creation of functionality, holding up new features. Thinking about quality before development, well that's just crazy talk. Old Habits Die Hard In the Agile world, this is starting to change. Quality is being baked into the development process and there is more interaction between development and QA during the development phase. At least, that's the theory. In practice, we often slip back into bad habits of throwing code over the fence. The reason we keep falling back into bad habits is because the attitude around quality is the same as it always was. It is still seen as something separate from development, separate from design, separate from pla

Being a Senior Developer is more than being a long serving developer

Like many people, I started my development career from another role. I taught myself coding and then built software to help the business and myself. It was well received, but I did not feel like a "real" developer yet. This experience convinced me that software was what I wanted to do, so I looked for a junior developer role. This wasn't easy, most companies want people who can come in and start being productive right away, and there were many skills I lacked from not working in a "true" software development environment. Eventually, after much persistence, I was taken in as a junior developer for a large finance company. When handing in my resignation to my non-dev-shop company, I was offered a pay rise to more than I would be getting in the new role at the finance company. I was also offered a new position, the position of "Senior" developer. Now I had a choice. I could stay, and drive development projects, leading a team of newly hir

Ways to Spot Single Responsibility Violations

Classes should only have one reason to change. We should attempt to increase cohesion between things that change for the same reason, and decrease the coupling between things that change for different reasons. Classes should do one thing and one thing well. Violations of the Single Responsibility Principle can cause code to be difficult to test and maintain, and can make it easier for bugs to manifest. There are a few symptoms of SRP violations which can give warning signs of these issues. Large classes/methods Obviously large classes and methods do not always point to SRP violations as there may be a requirement for a significant amount of logic. However, it is usually a good sign. Large methods are more likely to point to an SRP violation than large classes, or at least too much cyclomatic complexity. You'll become aware of this when you attempt to cover the method with test cases, and realise there are excessive test combinations required. Too many injected depe

Hololens: What Kind of Applications Can We Build?

Image
The creative potential of Hololens and "Mixed Reality"is huge. There are a wide variety of applications we can develop for it. I believe the demos shown so far are barely scratching the surface of what we can do with the Hololens. Once the imagination of the development community warms up, we're going to see world changing ideas. Industries will be turned upside down, lives will be changed, and millionaires will be made. I'm going to make some assumptions on its abilities, but try and highlight some of the many directions we can take in creating for the interface of the future. Presence Sharing One of the most interesting uses for the Hololens is allowing others to share your experience, and interact with it. This opens up many prospects for communication and collaboration in virtually every industry. Think about how cool GoPro cameras are and what we're able to do with them. Now imagine seeing the video live and being able to interact with it. This