How should I validate code when there is no one to do code review? [duplicate]

Question

I'm used to working in a large development environment where code is peer reviewed and tested by the client, who is usually an IT person themselves. I am now working at a very small company where I'm not just the only developer, but the only IT person at all.

I'm inclined to have my coworkers and/or boss take a look at my work every time I finish a agile story, so they can either accept it or reject it, as is the pattern I'm used to. However, too often my coworkers either don't understand my work well enough to judge it or they misunderstand it and accept bad code or reject good code based on surface looks alone, like the color of links.

So I'm wondering how I should decide when to accept/reject tests now? Should I try to assess my own code like an outside person? Should I just skip it and accept everything? Should I try to educate my coworkers a bit and get them to do proper tests?

Answer 1

User stories should be written in conjunction with the customer.

Are you the customer?

If so, then accept your own stories. If not, schedule review/writing time with the customer.

Answer 2

If you are developing an online system for your company, that would imply that somebody besides you must have an idea of how it supposed to work at least at the UI level. So that would be the level at which your work can be reviewed by others within the company.

Unfortunately, that means that there is nobody to review your code. One possibility is that you can review your own code. It may be helpful to go back and look at your code a week or so after you finish it, and see if you can still understand it. Alternatively, you can try to get your company to hire another developer.

Answer 3

As the sole developer, I think you just have to let go (hopefully temporarily) of some of of the professional techniques bigger teams has. But you CAN make some substitutes!

You should always use repositories. You should probably make more tests than before (since there is no other person who can catch mistakes).

If you are able, make each feature or addition a separate changeset / shelveset (or branch in git), so that you can create some feature, test it and then ignore it for 1-2 weeks(longer is probably better). Then read through the entire shelveset. Now: If you have no problems understanding every line of code immediately, consider it acceptably code reviewed(as 1 person I think this is the best you can do). If there are parts of the code where you do not immediately understand every aspect of the code, spend some extra time to see if you can make it simpler, or more understandable.

Better than everything above is to get your boss to hire another programmer and peer review each others code.

Good luck!

Answer 4

Welcome to the world of micro-management.

The place where the boss lose money, and the technicians made ​​coffee for others

Most of the agile development techniques that you have learned up to now, in this moment become non-applicable. The main problem is that in the absence of a development team, what remains is perhaps "extreme programming". My advice is to make it clear to the company (no matter the size of this one), this situation is sustainable only if the software is developed to an amateur level. This has nothing to do with your role, you can continue to develop by applying all the techniques you know, but only at the level of software design and development. Continue, perhaps, to develop using TDD, drawing use cases in UML, etc.. But a product, it needs more members to be developed, debugged, tuned, deployed, advertised...

Do not forget that the development of a product, must pass through a strong criticism, survive this, and then have its path of continuous integration. as programmers, we do not digest well the criticism of others and we often need a brilliant idea from others, BUT when they are not there, we become omnipotent and all the errors becomes ours.

I believe that the boss (as defined), has a rejection to the explanation of a technical, these normally lead to the need to spend money, and in a company where there is not a defined budget for the technical department, this can generate conflicts between administrators and technical.

My advice is to invest in training managers, without giving much explanation and even in small projects, organize your work ready to welcome new members in the development team.

Some tips

1. Always use repositories, maybe a nice project on github, with your code organized as Super Project
2. Spend your time in at least define what are the milestones of the requests that are made to you;
3. Organize your milestone in simple online spreadsheets, now you do not need great project managers, Gantt diagrams, resource control, money flows, etc.
4. Always communicate the progress of your work via e-mail, and attach the status of your milestone in PDF;

I think the method that you choose today, must show what you do, and how much time do you spend on.

last consideration

if you show to a Boss, 10 milestone, 3 of these were writing code, and the other divided between, debug, design, install, test, at that moment you have a great tool for dialogue with the administration...

at that time, you speak their language.

Answer 5

I'm not just the only developer, but the only IT person at all. I'm inclined to have my coworkers and/or boss...

Sometimes in that situation it is useful to invite a friend even if he knows absolutely nothing about computers. You could meet at home, or another place, and you can show him your code, or he can show you his code. In my experience he was my friend, and usually poked at a piece of code, whereafter I often found an error.

Also a good approach can be that you just try to forget somehow what the code does. Just sleep, go for a walk, or even change the project. When you completely forget the completed task, try to get back into the project, read the code and reconstruct the purpose of the code. Try to understand the code again, you will see many new ideas, and even mistakes in it. Don't wait too long, though!

This approach can also be applied when you write an article.

Answer 6

To assess your code you can use automated tools like PMD, Findbugs, Sonar, etc. Which one of these have a set of rules that evaluate your code against best pratices and design patterns. They also let you create new rules to match your patterns and architecture design. You can run them integrated on your IDE, on a CI Server (like Jenkins) or on a simple batch script.

They are not perfect but can give a help while you don´t have another developer to review your code. They are free and can be scheduled to run every night so you get a fresh report every morning. :)

Answer 7

If you are the only IT worker, then there's little point in getting anyone around you to review the code. Nobody will have any idea what it means, and will just point out trivial stuff like spelling mistakes.

Make extensive use of unit tests. Take heed of compiler warnings, and consider using automated code quality tools (but be prepared to ignore or turn off many useless warnings from them).

Only bother asking the people around you whether or not your code does what they want. If it's confusing, or doesn't work for them, fix it. If they are happy, then your code must be OK.

Answer 8

When you are working in small companies, its normal to have to wear several hats. Take the most extreme example, when the company is first created, you still have developer, tester, analyst, sales, book keeping, marketing etc... roles, but probably only 2 or 3 people to share the work.

In this case, its quite possible that you are doing the analysis of what is required, developing, testing, deploying, maintaining and supporting. Whilst its preferable for there to be multiple people covering these roles from both a quality and business continuity perspective, in a small company that may be an expensive luxury.

The best advice I can give is to always be clear about what the roles are, and to think as though you are performing each of these roles when you are performing their tasks on the project. Over time this process will become more fluid, and you will become more comfortable with thinking ahead and handling the competing responsibilities.

If I was currently your manager, I would be looking to see if you can step up to the challenge ahead and take ownership.