Neowin:

Microsoft has announced that they have released the Visual Studio ’14’ CTP 3 for download and also an early build of the .NET Framework vNext. If you have been following along recently, you will know that the Visual Studio team has been releasing updates at an extremely fast pace, so quickly, in fact, you may have missed the last release that came out earlier this month.

Sweet.

One of the things I pushed for after I got back to project management and development is code review. Poor coding has bit me countless times so I’ve decided to proactively fight it. Projects where code smell often leads to firefighting. Firefighting is costly and personally, I just hate it. Desperately trying to save a project where you could’ve done something from the beginning is the worst feeling.

Code review can help you mitigate this problem. Code review is controversial because some developers don’t believe in its benefits. It takes too much effort but with very little (visible) effect on the project. Additionally, it can be really daunting. Review results typically spell huge code change and endless regression testing. However, I think with proper implementation, it can provide compelling benefits to a team. In just a few months of implementation, I’ve witnessed dramatic improvement in our development cycle. We are more confident with our code. Bugs are solved in a straightforward manner. Modifications are treated and implemented same way initial features were implemented, no hacks, no magic. Here’s how we do it:

  • Build guidelines and conventions for your team — code reviews are pointless if you do not establish ground rules.  For every technology stack, come up with a set of rules. For example, web applications involve several technologies. Create one for each stack and make sure every team member agrees with it. Put them in your intranet CMS or wiki for easy access. This makes the whole process objective: they stick to whatever was agreed on.
  • Do it quick, do it often — often, code reviews are exercised just a few times in a project cycle. Worst, it is performed at the end of the cycle. This is very problematic because by that time any code modification will most likely break a lot of things. The best thing is to do it as often as possible, as short as possible. This divides the whole endeavour into tiny little chunks and makes the effort tolerable. For example, it’s a lot easier to review code on a per task basis than per module or per application basis. By doing this, code review should not take more than 15 minutes.
  • Pick a review point — depending on how often you want to do it, picking the perfect timing for code review is critical. In our team, we encourage to commit codes as often as possible. Reviewers are notified whenever a developer commits (we use Slack!) so they can react instantly. They can choose to review it later but they should not let it go to the next day.
  • Involve everyone –— conventions and guidelines practically make everyone a candidate to be a reviewer. When everyone is involved, it creates team discussion. It opens up engagement. This is one of the best thing you can do to a team as you put them in a certain cadence. This increases productivity.
  • Pick a tool — so what happens next once you get the team fully on  board with the code review process? How do you monitor their progress? How do you give reviewers power over the process? How do you convert them into metrics? Pick a tool. Fortunately, most repo-hosting sites come with it and should be suffice for any code review processes. In our case, the ability to view and comment down to the code level is the most important feature. Developer notification comes close second. Importance of features may vary from organisations to organisations so I would suggest to check them out first. If you record KPIs for your team, the tool should give quantified result of the code review.

A lot has been written about the benefits of code review so I will not touch them here. In case you (or your boss) need convincing, here’s a good rundown of its benefits.

Rappler has a good piece about the whole Jollibee #ChickenSad fiasco. I know a little about what happened but let me say it upfront that I am no in way involved in the project. Some of my friends jokingly asked me if we were the reason why the stores are out of chicken. I would be mortified if we were.

I cannot tell what I know (I’m under NDA) but I agree to most of the points that the author made (I distinctly remember suggesting some of these to them). You would think that these are Project Management 101 but you’d be surprise how often and rampant project managers, business process owners and system integrators etc. overlook these things.

I would add one more:

5. Focus on understanding the business and not too much in the technology. Technology alone will never solve a problem at this scale. The more you understand the business, the better you know what the problems are, who are the people you need to solve the problems and what are the ways in can be solved. Technology should not be viewed as universal panacea:

Knowing what the problems are — by knowing the business, problem identifications come naturally. When you know the problem, mapping software features to solve them would be less difficult. Our strategy typically involves immersing our BAs (business analysts) with their existing manual process. It’s a gruelling task but a very important one. Once we are confident enough that we understand their existing process, that’s the only time we move on to the next phase.

Knowing the people you need — domain knowledge engineers are very critical in the success or failure of the project. These are the people who know the business to the guts. They know the pain points. They have ideas on how to solve them (always take them with a grain of salt) and they are the ones who will actually use the solution so involve them as much as possible, as often as possible.

Knowing ways to solve the problems — pure automation is often too complex. Most people just want to do their job and be done with it. Often, this can be achieved by applying what works from an existing process to the new one, even manual process. Case in point, we were asked to add a feature to a certain project where the system would allow them to compose email and send the reports generated by the application. I told them, “Why not just copy the link of the report and send them as a regular email”? After a few convincing, they realised what I suggested makes sense.

If you worked on an enterprise app before you probably know that JavaScript files (or style sheets) quickly grow in size and in number. The loose nature of JavaScript is inherently problematic and developers haphazardly take advantage of it. For example, letting developers decide whether JavaScripts are inline, external or page-wide could easily bog down a project’s code base. I have been burned repeatedly by letting developers run amok with their own JavaScript conventions. It starts unsuspectingly harmless. As the project grows, code begins to rot. Debugging becomes painfully hard. Bugs crop up all over the project and the team’s capability to troubleshoot problem quickly dives. The last part is the most terrifying. You could easily lose countless hours just for tracing bugs.

To mitigate this, I have written a JavaScript guidelines and conventions(among others) for my team and enforced it. I also religiously monitor them during code review. This two-pronged approach is necessary because without the other, it is very challenging to make developers create clean JavaScript code. I don’t intend to paste the entire thing here but below are the important details:

Go Unobtrusive JavaScript all the way—I cannot stress this enough. Unobtrusive JavaScript enforces a clean separation between HTML page and JavaScript. This is really valuable during troubleshooting and modification.

One JavaScript file per view (HTML)—this may sound a little obsessive, and it is, but it pays off in the long run. This strategy encapsulates the functionality of the page in one file and isolates possible problem from the other. The performance hit this entails should be negligible for enterprise applications.

One JavaScript file for common codes—be vigilant as this will be abused. A good rule of the thumb here is to count the number of page that a code affects. If it does not reach a certain number, do not allow developers to put it in the file.

Define a file naming convention—this Stackoverflow discussion enumerates some of the common JavaScript file naming conventions. Most of the suggestions are superfluous for an enterprise project but you can definitely take something away from the discussion.
We use the format [module-name].[view-name].js. It’s clear and straightforward. Enterprise apps are typically comprised of modules so this way they are grouped together. Avoid using folders to group files as this impedes locating files.