http://technet.microsoft.com/en-us/library/cc707802.aspx

How to code review ?
Over the years of being the code reviewer or me being the reviewee have noticed a few things which i feel are worth mentioning for an effective and pain free code review to happen.

What exactly is a code review i guess everybody knows that , ill try and point out some of the things which should be taken care of for a productive and pain free code review to happen.

• Objective: Make sure the objective behind the code review is well known to the developers involved: Developers need to understand that the code is being reviewed and not the developers ability to code.

• Coding Standard: Make sure you have a predefined set of coding standards circulated with the team before coding. Developers wont have any clue as to what you as a reviewer feel is the right coding standard unless they know what needs to be followed before they start coding.

• Dont Accuse:Code review shouldn't be used to accuse the coder, but to point out the improvement areas in the code.

• Ask / Discuss: Ask reasons for deviation that have happened than assuming: Its better to let the developers explain the reason for deviation rather than assuming.Lets face it many time there are some theoretically correct statements which cant be possible practically.Hence ask reasons for deviation, understand the developers thought process.

• Listen: Remember the coding approach you use isn't like the ten commandments.Just because you feel reaching point C is better by going via point A not necessarily everybody will think the same.Let the developer explain why he felt going via point X was better as per him.

• Understand: Remember the code review is about the coding style not about you.: Dont get offended if there are any improvement areas in your coding.Keep one thing in mind the person reviewing your code has also gone through the same phase as you currently.and till the time one understands the improvement areas we wont be able to improve and do coding expected by a seasoned developer.

• Contribute: The coding standards wont contain all the development situations we face under the sun Hence contribution from the developer is absolutely necessary.Just because the person reviewing your code is a TL or PL doesn't mean he is right all the time.Express your view, understand the reasons why there are improvement areas.Keep one thing in mind we do those things best in which we believe in!!! hence if you do not understand why we are doing certain thing in a certain expected way you will never do it correctly so discuss and understand.

• Appreciate: Code review isn't just about finding improvement areas. Utilize it also to appreciate someones coding style/Approach.

Lets face it whether we like it or not we have to go in for code reviews some because their leaders make it mandatory while some because they understand the importance of code review.As long as code review happens in the right manner and for the right reasons it is always healthy for the complete team.

Have seen or rather experienced developers who would argue over coding standard violation with pointless reasoning.reasoning that would be treated as childish excuses.Listen and explain to them anyways try and make them understand.Ofcourse in many cases you as a TL/PL need to put your foot down or do a little booting to make the developer sunderstand that crappy excuses wont be tolerated.

Also one good thing to do beyond the coding standards document of what to do is to create a coding standard checklist for developers to check against as when they are coding.

Copyright © Shounak Pandit

These are my views, my thoughts need not necassarily be the same as yours.....

I remember back then when i was an intern and i was assigned to a project in which my PM was a guy working in our US branch...people having worked with US bosses might be knowing thr are 2 types of techies our there... one who have less knowledge than you and the other lot who has so much knowledge than you that they make you feel like you are learning the alphabets of development while they are shooting out complex phrases after phrases of sentences....

man how i hated that guy i can still recall his words "Shounak, Dont even show me the functionality i dont care about it, first make sure you have it as per the coding standards" and i used to think what kind of a weirdo have i got as my boss ..he doesn't even want to see if the requirement has been met but cares about some stupid code review.....and i used to laugh at his code review obsession...

but over the years as i grew into a techie...into what they call a seasoned developer ..i realised the importance of code review

Code review isnt a tool to find mistakes in others code...its a tool by which one ensures the code is going to meet the standards expected of a seasoned developer.

There are various technical ways of achieving our requirements...or rather let me put it this way there are abundant ways of screwing up the way you meet your requirement.and there are some ways in which you meet the requirement in one of the optimum ways...and code review is a tool that helps us walk on the optimum path or close to the optimum path...

for an example check my post on string builder usage vs string concat... at String Builder Vs String concat/

Code reviews are important for a developer to understand how to keep improving his coding style ..

there are various good tools used for having automated code checking one that i have used extensively in my development days is FxCop and one more that i can't recall the name of...these were tools which would use the assembly n metadata as source and parse the assembly for any coding style /optimization errors

will try and write up about one of them soon

Cheers

© Shounak Pandit

]]> http://ranjtheseeker.wordpress.com/?p=110 Thu, 04 Sep 2008 02:35:14 +0000 ranjtheseeker http://ranjtheseeker.pl.wordpress.com/2008/09/04/pointer-to-issues/ Well,  I wanted to note down one of the most silliest bugs I have done in my coding. I started off my code thinking that I will create a array of string pointers and allocate memory for each string dynamically. I did my coding initially with that assumption and everything was working fine. Now, as time passed I had forgotten that i had started off that way and started assuming that I had declared a char pointer of fixed length.

And the size was declared to be 355. So, basically this array could hold 355 strings. I did my entire code assuming that I am handling an array of string pointers but overlooked the basic declaration where I had declared it to hold 355 records. So, what happened was at one point of time the code had to handle more than 355 recs and my code was going for a toss. I didnt do the stress testing and this didnt come up in the Test Env. It came up once but I was looking for the issue elsewhere.

Then I had to come to the client place to Mexico to support the go-live and the code bombed. Imagine the client sitting on top of your head and you had to deliver and had none to reach out to. And not one issue but 'n' number of issues. I was thinking and working for about 30 hours without going anywhere near the solution. I had already sent a SOS to my manager at India and at Mexico and we were trying to reach out to different people. Then finally one of the client techie questioned me why I had declared it that way. And asked me to recheck. I did a quick recheck and changed the size of the constant and lo!! the code worked.

I cursed myself for this blunder. But sometimes this is how you learn. And I can never ever forget this in my life. It gave me a good teaching of all the loopholes that you should expect in a code. And the importance of quality reviewing. And good testing too!!! Finally one correct question saved the day for me and the client as well. The code is working fine now and I can do a lot of tweaking now to increase performance. But, the biggest of blunders at the least unexpected place, just because you forgot to look at the header file for the size. I am such a moron!!!!

Automate the review where possible. A review conducted by a computer has several benefits:

• Reduced manual cost of code reviews
• Fast, consistent, and repeatable
• Removes emotion from the reviews: pride, ego, and ownership need to be constantly recognized when conducting a review. When offering a critique you should take care to not to step on the author's feelings. Using an automated process abdicates this responsibility.
• In some cases you have tools that allow for real-time reviews, such as the Eclipse plug-in CodePro Analytix. These tools perform an examination of the code as it is being written. This is the holy grail of fixing broken windows.

The benefits notwithstanding, it must be acknowledged that the scope of automated reviews is limited to rules and conventions and are hard to extend to study business logic. The latter have to be handled by manual (or peer) examination.

Manual Reviews

From the prior sections you have seen that interactive and build-time tools at your disposal, while a great boon to the review process, cannot substitute for manual review for a certain class of problems. You have to manually review for certain types of improper coding practices. Tools cannot highlight errors of omission as described in the earlier section. Given that, let's see how a manual review must be conducted.

Participants: The review must focus on different facets of code correctness. Therefore, the participants of a code review must be chosen to satisfy a diverse set of roles.

• Technical lead: S/he plays the role of the facilitator and moderator
• The author(s)
• Quality Assurance: This role focuses on ensuring that the code under examination satisfies the set standards
• Functional expert: The person who is an expert in the business domain being reviewed

How to conduct: The technical lead will work with the authors to coordinate the review. This process includes:

• Identifying the participants in the review
• Determining the amount of preview time
• Providing the participants the necessary information
• • Requirement/bug fix that was implemented
  • CVS location of the files affected. The lines in the file that were affected by this change.
  • Project reports with coverage and complexity details
  • Review time duration
• Setting up a meeting to discuss the results of the preview
• • Moderate the meeting – During the actual review the authors will describe the intent of the code and provide an overview of the implementation before the code is examined
  • Capture comments
  • Repeat above steps if necessary

Addressing the requirements One of the key goals of a code review is to ensure that the code under scrutiny is feature-complete. Beautiful code that fails to meet user requirements is useless. The review must ensure that the logic does what it is called upon to do.

Code correctness Ensure that the authors are following proper programming techniques as appropriate:

• Object orientation: Be on the lookout for monolithic, jack-of-all-trades methods.
• Code reuse: Promote the use of tried and tested (and debugged) APIs and avoid code duplication by recommending the use of available APIs.
• Adequate and proper documentation: Ensure that the code is amply commented. This is especially important when the logic is complex. Such inline documentation must explain what is being done and not how it is being done.
• Defensive coding practices: See any number of online resources.
• Maintainability: The ability to maintain the code is assessed from documentation and code organization.

Errors and omissions A well-written code fragment that abides by all the departmental norms, satisfies requirements, and otherwise "stays within the lines" could still be in error. It is the task of the reviewer to make sure that the code does not make incorrect business/usage assumptions and that all possible usage scenarios are taken into account. A business process expert helping with the review will be quick to spot logic that presupposes the state of the application while the logic is executed. For example, an application that allows guest users cannot be guaranteed to know the current user's identity.

Test for coverage. Test coverage is a measure of the quality of testing. Tools like Maven and CruiseControl simplify the process of testing and auditing coverage reports. The reviewer must understand the significance of branch and path coverage.

Silo-busting pedagogical aid This tool exposes others in the team to the code. The reviewer gets to read, analyze, and discuss someone else's work. Such cross-pollination is an excellent way to raise the skill of the entire group. This approach has the added tangential benefit of busting silos of expertise that projects tend to unwittingly foster.

Best Kept Secrets of Peer Code Review

Peer code review is happening behind the scenes at your competitor's shop. Are they wasting their time or gaining a competitive advantage? What type of review actually works?

Go here to get free book… and many additional whitepapers on this aspect of software engineering

(Yes, this is a "sell" for a product but what isn't these days?)

Purpose:

To provide general guidelines to carryout coding phase

Process Requirement:

1. Coding:

Entry Criteria:

Ø      Approved Technical Design Documents

Ø      Approved Project Plan

Ø      Coding Standards

Activity:

Ø      Development process begins with the implementation of the Technical Design by the developer assigned.

Ø      Developers design and create source code following SDLC coding standards / guidelines provided by the Development Team Leader

Ø      Completed Code shall be compiled and the errors/ bugs shall be fixed.

Exit Criteria:

Ø      Compiled error free Code

2. Code Review and Unit Testing

Entry Criteria:

Ø      Compiled Error Free Code

Activity:

Ø      Developer Team Leader Conducts walkthrough on code at formal or informal agenda based upon the review process.

Ø      Verifies with the checklist and RTM against the working product/code.

Ø      Unit Testing will be done and if any issues are identified then it as to get closed before release to the system or integration test

Records Retention:

Ø      Code Review

Ø      Unit testing issue report

Exit Criteria:

Ø      Updated baseline code (SCM Plan)

I'm inviting the Python developer community to try out the tool on the
web for code reviews. I've added a few code reviews already, but I'm
hoping that more developers will upload at least one patch for review
and invite a reviewer to try it out.

To try it out, go here:

    http://codereview.appspot.com

The following guidelines should help you develop an overall approach to performance tuning.

Remember the law of diminishing returns: Your greatest performance benefits usually come from your initial efforts. Further changes generally produce smaller and smaller benefits and require more and more effort.

Do not tune just for the sake of tuning: Tune to relieve identified constraints. If you tune resources that are not the primary cause of performance problems, this has little or no effect on response time until you have relieved the major constraints, and it can actually make subsequent tuning work more difficult. If there is any significant improvement potential, it lies in improving the performance of the resources that are major factors in the response time.

Consider the whole system: You can never tune one parameter or system in isolation. Before you make any adjustments, consider how it will affect the system as a whole.

Change one parameter at a time: Do not change more than one performance tuning parameter at a time. Even if you are sure that all the changes will be beneficial, you will have no way of evaluating how much each change contributed. You also cannot effectively judge the trade-off you have made by changing more than one parameter at a time. Every time you adjust a parameter to improve one area, you almost always affect at least one other area that you may not have considered. By changing only one at a time, this allows you to have a benchmark to evaluate whether the change does what you want.

Measure and reconfigure by levels: For the same reasons that you should only change one parameter at a time, tune one level of your system at a time. You can use the following list of levels within a system as a guide:

Hardware
Operating System
Application Server and Requester
Database Manager
SQL Statements
Application Programs

Check for hardware as well as software problems: Some performance problems may be corrected by applying service either to your hardware, or to your software, or to both. Do not spend excessive time monitoring and tuning your system when simply applying service may make it unnecessary.

Understand the problem before you upgrade your hardware: Even if it seems that additional storage or processor power could immediately improve performance, take the time to understand where your bottlenecks are. You may spend money on additional disk storage only to find that you do not have the processing power or the channels to exploit it.

Put fall-back procedures in place before you start tuning: As noted earlier, some tuning can cause unexpected performance results. If this leads to poorer performance, it should be reversed and alternative tuning tried. If the former setup is saved in such a manner that it can be simply recalled, the backing out of the incorrect information becomes much simpler.

That team was special because we built a product from scratch and we developed a lot of trust in each other. Today was the last day at work for Philippe, a guy who wasn't on that team but who worked on the security products development group at my company.  As I had developed an interest in building secure software, I had some interaction with him during the security code review process that he and his team conducted on our product. I took the recommendations that they made and designed and implemented a plan for handling as much of it as was possible in our impossible schedule .  When I said goodbye today, Philippe told me that he really enjoyed working with me back then because I took seriously the engineering of security into the product.

As I was flipping through my aggregator (Google Reader) tonight, I came across Joe Duffy's blog post on multi-threaded code review. Joe is one of the key members of the Microsoft team building the Parallel Extensions to the .NET Framework, and is currently writing a book on concurrency development for Addison-Wesley. His blog post is fairly long but then, writing concurrency code is difficult and making sure that it is validated is of critical importance. There is too much to re-state here. Even listing highlights doesn't give it enough justice. If you're writing multi-threaded code, go read this blog entry.

Back on security, related to code review I thought I'd point out that the Microsoft Patterns & Practices group has come up with security guidelines for WCF that includes a lot of how-to and application scenario documentation as well as videos. It is crucial to be aware of the common security traps such as buffer overflows and cross-site scripting attacks.  With WCF, however, there is a whole boatload of additional concerns because of the C: Communication.  A WCF service may need to impersonate the caller in order for a component on the receiving end can authorize them for some activity. The P&P team has nicely written docs for explaining how to do this. Or you can watch the video if you're so inclined. This is great material for identifying questions and concerns for use in a security code review.

Search for "debugging" on the internet and most entries will tell you the first step is to reproduce the problem (properly called "the software failure") and the second step is to create the simplest configuration that also reproduces the problem.

I agree that it is essential to reproduce the problem, because you need to know you're working on the right problem.

Fun to Run, or "the thrill of the chase"

But programmers, myself included, like to run things—to let the computer do the work—so there's a great temptation to reproduce the problem, change something, run the software, add some "debugging statements", and run it again. And there goes an hour of valuable time.

Does readability fit in here somewhere?

If the code is written clearly, and by that I mean that it's readable, with meaningful variable names and the proper levels of abstraction, then the second step might be to actually read through the code.

A short debugging story

Today, I showed myself both the wrong way, and the right way, to respond to a "bug report".

Where I work, I've turned out to be the owner of a small set of text-parsing scripts, written in awk. We use them to pull out compiler warning messages from the long build logs, so that developers can see them and address them. These parsing scripts are short—half a page of code including comments—and are tested only with the few build logs that I've had time to try. Given limited time (it is not my main job to write parsing scripts!), I have to hope that all the build logs for a given compiler are pretty similar, so whatever pattern I've identified will be followed in other build logs. It isn't always so.

A developer noticed (first by eye, confirmed with a simple "grep") that there were more compiler warnings in his build log than in the parsed csv (comma-separated-value) output file. Not good. I set about debugging!

It took about 5 minutes to reproduce the problem. Really just gathering the sample input and bad output files, and setting up a copy of the relevant scripts. One run (takes about 2 seconds) showed that, indeed, some warnings were missing.

My next step, by the standard debugging technique, was to start printing all the partial results, run the script over and over again, and look to see where it was failing. Then some more time to adjust the failing script and retest.

Haven't I seen this somewhere before?

After the first 5 minutes (reproducing the problem), I already had a pretty good idea of which script was failing. A sed one-liner that adds newlines after each compilation command line, and before the first warning message, so that the awk script would be able to separate the first warning message as a record and select it. What was odd was that when I opened that script (just one executable line—the rest is comments including change history), the last modification comment was about how I had fixed exactly the same problem before. Briefly I wondered about that, but rushed onward to more than half an hour of running parts of the script pipeline to prove to myself exactly what was failing and why.

I could have saved myself the time.

Debugging: How to Start (the code-reading method)

After reproducing the initial problem (again, just 5 minutes), and arriving at the suspect script with the worrisome comment, I should have stopped running the code, and started reading it. After all, if my last modification was to fix this same problem, then apparently that modification was either wrong, or insufficient.

It turned out, and this was visible by comparing the one-line script and the new build log on which it failed, that it was insufficient. The new build log had some extra spaces at the end of the compilation command line, and the sed one-liner, designed to identify such lines, was unprepared for the extra spaces.

It did take me another 15 minutes to verify that most new build logs had a random number of extra spaces, and thus to pick the right two-character adjustment to the regular expression. Regression testing took another half hour.

But I could have saved myself almost an hour in the middle of "debugging-by-running" if I had applied a few minutes of "debugging by reading the code".

Even better would have been reading it out loud, or reading and explaining it to someone else.

"The largest case study ever done on lightweight
code review process; data and lessons"

We believe our results allow us to conclude the following:

• LOC under review should be under 200, not to exceed 400. Anything larger overwhelms reviewers and defects are not uncovered.
• Inspection rates less than 300 LOC/hour result in best defect detection. Rates under 500 are still good; expect to miss significant percentage of defects if faster than that.
• Authors who prepare the review with annotations and explanations have far fewer defects than those that do not. We presume the cause to be that authors are forced to self-review the code.
• Total review time should be less than 60 minutes, not exceed 90. Defect detection rates plummet after that time.
• Expect defect rates around 15 per hour. Can be higher only with less than 175 LOC under review.
• Left to their own devices, reviewers’ inspection rate will vary widely, even with similar authors, reviewers, files, and size of the review.

Drawback:
Comments are saved as XML in a folder, which must be shared with all other developers (SVN(each comment = new Revision) /Samba)

Conclusion:
Make 1 review on 1 checked out source and commit OR create a samba server and link it to the review-data-folder, so reviews can be shared without commits.

Most of the times we are content that our code is of the right quality, if somehow, we manage to get the Static Code Analysis (SCA) tools like Checkstyle, PMD etc. report less number of severe violations. As an example if we see that the class is big in size then we conveniently split it into two or more classes to get rid of the violation. The tool is happy and so are we and most of the times that is the end of the story.

However more frequently than not getting an SCA violation is the start of the story. If you start associating the question “Why’ with every SCA violation found then the real reasons start unfolding.

This is similar to the way we resolve impediments on an Scrum project. The impediments rarely represent the isolated incidences of inefficiency. Rather, most of the times they are a part of a larger problem. The way to work out an impediment is fix it so that the team can work effectively and then to look at the root cause which caused the impediment so that the main cause can be fixed. This is called “Bottom-up process re-engineering.”

Similarly the way to work out an SCA violation is to remove it so that the code looks clean and good and then to hunt for the real cause.

I got first hand insight into this when I was doing an audit for a large system which is being used online by millions of people. While doing the analysis my co-auditor suggested that let us look for hot spots which are highlighted by the SCA tools. Then, let us dive into the code at those places to find out bigger issues. At that time I was skeptical if that approach would work however now I am a firm believer of his philosophy.

The SCA tools do a great job of pointing out the hot spots. You can either patch the hot spots to make the SCA tool happy or you could look at the bigger issues so that the root cause of the problem is eliminated.

I would take some examples from my audit to make it more clear. Let me warn you that these problems look too simple for any deeper analysis but believe me once you do the analysis you do manage to uncover some unexpected thought provoking findings. And of course these are just a few examples for illustration, you could apply this to ideally every violation that you get.

1. Size violation: We found that there were servlets in the application which were more than 3000 lines, having methods more than 800 lines each. A quick fix to this might have been to reduce the method size by splitting the methods and moving some methods out of the class to a helper class so that the class size and method size violations are taken care of.

   However, when we looked deeper to answer the question “Why do the servlets have so much lines and such big methods?” we realized that all of the business logic was present in the servlets. There was a bigger violation of Single Responsibility Principle where all the logic was present in the single class. The presentation logic, business logic and data access logic were all clubbed together thus leading to fragile design which is hard to change without breaking. There was no layering and no separation of concerns.

   The design of the system was a culprit here and probably none of the developers or the architect on the project felt so.

2. Methods with large number of parameters: A quick way to solve this and make the SCA tool happy would be to introduce an object and populate the object with the required parameters.

   However, when we took a deep dive we realized that the system did not have any abstraction. There were no domain objects in the system either. When data had to be passed between method calls, all of that would be passed as primitive data, mostly strings. There was no focus on domain driven design. The methods were overloaded with every extra parameter that would be required in a different situation which suggested that the system was open for modification and closed for extension. For any small change a new method had to be written. This violated the Open Close Principle.

   Again design was the culprit here.

3. Large Cyclomatic complexity and NPath: We were baffled to see CC numbers > 50 for some methods and NPath figures of > 1.7 million.

When we dived deep we found that the methods in question had a lot of nested if..else logic. So far so good, but what is the reason for the nested logic? We found that the method contained all the dispatch logic for the request. If the request has these attributes do this else do that and so on. This also explained why the system had low code coverage by unit tests. A unit test to test 1.7 million possible paths would take weeks if not months to write.

Clearly nobody had thought about introducing one of the many readily available MVC frameworks. When we questioned the team on why they did not use a MVC framework we were told that they did not feel the need in the beginning because the system was too small. Once it started growing they never had the time to refactor and introduce a framework.

This could have several causes ranging from lack of communication between the client and the vendor about realistic time lines, refactoring not being a part of the standard development process, lack of interest of the team in project, lack of interest in achieving the right quality and focusing on just getting the work done.

4. Missing braces and wrong variable naming: This is probably one of those violations which is immediately reported by a SCA tool and is easy to correct.

   However, when we started looking at it deeply we found that certain modules of the application reported huge violations as compared to others. When we compared two modules with highest number of violations we found that both of them were using very different naming strategies. Further investigation revealed that there were no coding standards which were used on the project. Every module and each developer was free to use a nomenclature which went well with his taste. There was no conceptual integrity and no uniformity in which the entire software was built.

   Improper software development process along with lack of coordinated communication between the teams were the obvious culprits in this case.

5. Large number of unused imports, variables and methods: This is again something which is readily reported and is easy to fix.

   However, when we questioned the developers about the reason to have unused code, we were told that they never removed the unused code lest they should need it some day. It would save them time in the future.

   Obviously nobody was thinking about the time lost when we had to scroll through tons of unused code and probably they were never educated on the principle of YAGNI.

   Again improper development process and lack of developer education were the culprits here.

You would concur with me that all these violations were very small and could have easily been fixed without resolving to deeper analysis. However, if you try to dig deeper then most of them would point to bigger issues which need a more focussed approach to fix. We saw that relatively small problems reported by the SCA tools could be attributed to bigger issues like improper design, sub standard development process, lack of communication and lack of proper education towards effective software development for the development team.

Hence though doing a root cause analysis for small violations might sound like an overkill but a lot of times the small violation is just the tip of the iceberg!

Next time when you are resolving the SCA tool reported violation just pause for a moment and ask “Why do I have this violation in the first place?”

Hoy Rodrigo Corral hacía un llamamiento en su blog, preguntándose cómo se podrían calcular las horas que han pasado desde principio de año hasta una fecha dada.

También habló Ricardo sobre revisiones de código en Subversion hace algún tiempo, y aún espero con ilusión que algún caminante deje un comentario a ese post sobre alguna herramienta que yo desconozca.

Hoy alguien ha mandado unas simples optimizaciones para la clase Int32 a la lista de desarrollo de Mono, un proyecto muy maduro, por lo que me sorprende que esta optimización no se haya realizado hace tiempo.

Por lo que se me ocurre una pregunta... ¿Cuántos ojos ven tu código?
Da igual la licencia que tenga, que el código esté disponible no significa que alguien lo lea.
¿Qué soluciones usas para las revisiones de código? ¿Es el Pair Programming algo realmente factible para un negocio?

Od pewnego czasu pracuję z grupą pięciu developerów nad aplikacją webową pisaną w Pythonie oraz Rubim (powód takiej mieszanki to temat na zupełnie inny post). Większość naszego zespołu to początkujący programiści tych technologii, wiec kod który produkują wymaga szczególnej uwagi i kontroli. Ponieważ nie jestem wstanie przydzielić każdemu juniorowi - seniora konieczne stało się wdrożenie narzędzia do recenzji kodu (ang. code review).

Pierwszym pomysłem jaki przyszedł mi do głowy było wykorzystanie rozszerzenia do Eclipsa o nazwie Jupiter. Niestety, nie wszyscy członkowie zespołu podzielają moją miłość do tego IDE, a że programistów nie można zmuszać do wyboru narzędzi pracy, to wdrożenie zakończyło się fiaskiem a my problem tymczasowo rozwiązaliśmy poprzez mailowanie plików różnicowych. Dość bolesna i czasochłonna metoda.

Poszukując innego rozwiązania znalazłem video o Google’s Mondrian. Po jego oglądnięciu od razu wiedziałem iż jest to rozwiązanie mojego problemu, dodatkowo zostały w nim wymienione inne problemy z narzędziami standalone o których wcześniej nie myślałem. Niestety Mondrian jest projektem wewnętrznym Googla i jak wynika z prezentacji dość mocno zintegrowanym z całą infrastrukturą tej firmy więc szanse na to iż pewnego dnia zostanie on udostępniony szerszej publiczności są raczej nikłe, choć można przeczytać w kilku miejscach iż takie plany istnieją. Jednym z dostępnych przeglądarkowych rozwiązań jest CodeStriker.

CodeStriker to napisane w perlu narzędzie, które nie zachwyca interfejsem i możliwościami - nie posiada opcji recenzji kodu który nie znajduje się jeszcze w repozytorium. Aplikacja ta jest darmowa, co odróżnia ja od Crucible, narzędzia twórców FishEye'a, rekomendacje tego produktu można było usłyszeć choćby w jednym z odcinków Podcasta JavaPosse.

Crucible oferuje bardzo przyjazny interfejs i dość rozbudowane opcje jeśli chodzi o reviewu kodu. Narzędzie to jest ściśle zintegrowane ze wspomnianym już FishEyem. Jako ze nie miałem właściwie innej alternatywy poza CodeStrikerem, którego interfejs mnie naprawdę odstraszał, zaczęliśmy używać Crucible. Nielicząc kilku przypadków, kiedy to przestał on chwilowo odpowiadać i wymagany był restart serwera aplikacji, całość działała dość szybko i sprawdzała się w naszym zespole mimo iż nie możliwa była recenzja kodu jeszcze nie w repozytorium (problem ten został rozwiązany poprzez stworzenie oddzielnej gałęzi dla każdego z programistów).

Kiedy skończył się darmowy okres i mieliśmy już wykupić licencję na rok dość przypadkowo natknąłem się na ReviewBoard.

Reviewboard to darmowa aplikacja stworzona przez kilku programistów z firmy VMware napisana w Pythonie z wykorzystaniem frameworka Django. Autorzy na pewno zanim przystąpili do prac widzieli wspomniane wcześniej video o Mondrianie, jak również spotkali się z wymienionymi tutaj projektami. Z ich blogów wynika również iż poprzednio przechodzili przez takie męki jak nasza firma, zaczynając od przesyłania plików różnicowych, a kończąc na szukaniu gotowego rozwiązania. Projekt ten jest w dość wczesnej fazie, ale jak widać z poniższych ekranów charakteryzuje go dbałość o detale i przyjazny interfejs:

ReviewBoard oferuje dwie możliwości tworzenia recenzji - z pliku różnicowego i na podstawie zmian w repozytorium. Ponieważ bardzo zależało mi na posiadaniu opcji automatycznej weryfikacji kodu jeszcze nie dodanego do repozytorium to w niespełna 5 godzin zmodyfikowaliśmy ten projekt tak aby pobierał on zmiany z serwera developerskiego (siła open source oraz Pythona). W efekcie czego otrzymaliśmy produkt zbliżony do Mondriana. ReviewBoard posiada dodatkowo "integrację" z Traciem, który jest przez nas wykorzystywany do zarządzania zadaniami więc na dzień dzisiejszy posiadamy stabilne i szybkie rozwiązanie które możemy łatwo rozbudować.

Swoja drogą od dłuższego już czasu chodzi mi po głowie napisanie narzędzia podobnego do wspomnianego Mondriana całkowicie w Rubim. Idealny dla mnie produkt generował by pliki różnicowe raz dziennie z katalogów roboczych programistów oraz repozytorium kodu, a następnie na podstawie ustawień projektu przypisywał by zmiany do odpowiedniego recenzenta. Ciekawą opcją mogła by być również integracja z Google Gears - pozwalało by to na recenzje offline.

Prevent Errors, Fix Defects, Describe Failures

There are many definitions of those terms, but since when we fix problematic code we close "defects" in the "defect tracking system", I started with that word in the middle. Leads to these definitions:

Error: The mistake someone made. (The root cause is the earliest error in the chain.)

Defect: The wrong code (missing, extra, or incorrect).

Failure: The unacceptable behavior of the code when running.

Detect each as early as possible

Each can be detected with appropriate tools. Detect earlier to minimize cost and annoyance.

Meanwhile, do it right

How?

With tools, learning, and discussion for writing good code.