Category Archives: Programming

Programming

Why code reviews are good for you

1 Comment

Over the years, I have had the opportunity to work with various code review systems, and I have come to believe that one particular approach works better than the other.  Here is what I’ve learned.

There are basically three ways to approach code reviews:

  • No code review.  Everybody checks in code liberally, and while everyone is welcome to examine change lists as they please, there is no incentive and no obligations to do so.
  • Non-blocking code reviews.  When code is submitted, a reviewer is associated to the change list and they are expected to review the changes at some point, but this review does not block the submission of the code, which gets incorporated in the depot right away.
  • Blocking code reviews.  In this scenario, submitters associate a reviewer to their change list but that change list does not get submitted until the reviewer gives their approval.

Let’s get rid of the first case quickly:  I strongly believe that projects that work without any peer review will end up with code of significantly worse quality, regardless of how talented or experienced the developers are.  It doesn’t matter how good you are, you can’t produce top quality code all the time.  We all get sloppy at time, and code reviews are here to address these times.

When the code reviews are blocking, the committer is not allowed to check in their code until the reviewer has responded with a positive comment.

When they are not blocking, the code gets checked in right away but the reviewer still receives an email giving all the details about the code so that it can be reviewed later (I suggest setting up a nag system that will remind lazy reviewers to do their reviews at least once a week).

In my experience, the only system that works is non-blocking code reviews, but before I go into details, let’s examine exactly what code reviews do, because I found that very often, the perceived benefits are different from the real benefits.

Here are a few facts about code reviews:

  • Code reviews don’t reveal critical flaws in your code.This is disappointing, but it’s the sad truth.  As the system becomes complex, so do the change lists, and you won’t often hear a reviewer say “If the servlet receives more than twenty connections, you will have a deadlock between A.java:723 and B.java:1410”.

    More likely, reviewers comments will be cosmetic (“Please rename mI to midIndex, it makes the intent clearer”) or they will request more comments.

  • Code reviews do keep you honest.  They force you to take some extra time to make your code more readable, because you know for sure that someone will be reading it with a critical eye very soon.

I found that proponents of blocking code reviews usually feel very strongly that anything more liberal is bound to be the cause for a significant drop in quality as well.  The argument often goes like “If reviewers do not feel a strong obligation to review the code, they will slack and the review won’t be done”.

First of all, my experience tells me that this is incorrect.  I found that even in the most liberal non-blocking code review systems, reviewers were very diligent with their reviews and they usually got done in a fairly short amount of time (less than a week, and usually within a couple of days).

But what’s inherently flawed with this assumption is that it fails to recognize that both blocking and non-blocking code reviews rely on the honor system, so saying that one will work while the other won’t doesn’t make sense.

In the blocking code review scenario, when you submit your code, you rely on the reviewer realizing that you are now unable to perform any additional work (or at a considerable price, see below) until the review comes in.  Despite this pressure, it’s not uncommon to see reviewers take several days before reviewing code, because they are just swamped and they also know that the committer is taking measures in order not to stay inactive while she’s waiting on the review.

Problems with blocking code reviews

I haven’t had good experiences in environments that mandate blocking code reviews.  Here are the main drawbacks to such a system:

  • While they wait for the review, developers are stuck and have to work on something else or put in place a system of patching, which they will have to resolve next time they do a sync and try to commit their approved code changes.
  • Developers know that they will be stuck as soon as they commit, so they accumulate huge change lists in order to keep working and “stay in the zone”.
  • These huge changes lists become problematic for reviewers who decide to not take a look at the change list until they can carve out a significant portion of time, which delays the review even further, therefore creating a vicious cycle.

While non-blocking code reviews work better

I strongly believe that non-blocking code reviews address all the problems listed above and come with their own set of good properties.  Here are some of them:

  • Being a reviewer when the review is not blocking works well, because a conscientious developer will be aware that reviewing the code as soon as possible is part of their job, just like writing tests or comments.
  • I am much more likely to take an extra ten seconds to write a comment if I know for sure that somebody will be reading my code, and possibly comment on it (which is why I said above that “code reviews keep you honest”).  Conversely, I have very often noticed that code that was never reviewed by a peer is usually harder to follow because it is more sloppy and less commented.
  • Reviewing code written by colleagues forces me to a daily and healthy exercise.  I have to change my mindset and get familiar with idioms and styles that are not mine.

What about pair programming?

Pair programming is definitely one way to do code review, but it suffers from a few limitations that, in my opinion, make it a less desirable option than non-blocking code reviews:

  • Pair programming only catches micro-errors.  Contrast this with non-blocking code reviews that expose your reviewer to an entire change list, which will force them to see a bigger picture than they would have if they were pair programming with you.
  • Pair programming naturally forces the two participants to converge toward the same thinking.  Once you both decide that you need a class A, you will naturally agree that it implies the creation of classes B, C and D, and after a while, you have a “design of a single mind”.
  • Pair programming can also take longer.  The usual argument to defend pair programming is to say that programmer A can do task X in three minutes and task Y in twenty-five minutes, while the times will be reversed for programmer B.  Put these two programmers together and they’ll be able to complete tasks X and tasks Y in three + three minutes.This is nice, but quite idealistic.  In reality, the outcome of pairing A and B can have vastly varying results, such as a task that would take three minutes by programmer A alone suddenly takes thirty minutes to accomplish with B in the picture.  Or A and B spending a lot of time arguing about the “right” way to solve the problem, while ultimately, there are more than one right way and A would have solved the problem much faster on their own.

Anyway, the point of this post is not to criticize Pair Programming but simply to make it obvious to everyone that the full impact of Pair Programming hasn’t been studied very well so far, and that it’s not a very good substitute to simple peer code reviews.

Finally, Brian Slesinsky wrote an interesting entry praising Pair Programming and criticizing code reviews.  Take a look if you want to get a counter-opinion to mine, but in general, I find that Brian’s arguments are a demonstration that blocking code reviews are not optimal much more than he demonstrates that pair programming is the right solution.  I think that non-blocking code reviews have all the characteristics of a happy medium between these two radical approaches.

What about code ownership?

Shared code ownership is vastly over hyped.

Shared code ownership is presented as a desirable consequence of Pair Programming and it simply means that since at all times, there has always been at least two people working on the same region of code, the entire team has a much better knowledge of the code base and that everyone can therefore step in at any time to fix a problem even in the absence of a key member.

First of all, reasonable shared code ownership can be reached with peer reviews.  It’s pretty easy to see why:  when you spend some time reviewing a teammate’s code, you gain a very familiar knowledge of it, and it won’t take you long to dive back in if you need to.

But more generally, shared code ownership is simply unnecessary if the code has been written by competent developers under careful code reviews.  It is very common for me (at least once a week) to stumble upon an area of code that I’ve never seen before, and I usually have no problem finding my way around it if the developer has followed some simple rules (commenting, naming the classes, methods and variables appropriately, using design patterns, etc…).  Code reviews will buy you a micro-knowledge of the code, but I find that I usually don’t need to know the code in so much details most of the time.

Finally, if you need a proof that code ownership is vastly over hyped, look no further than open source projects.  In typical open source projects, reviews are not mandatory and everyone can check in code at their will.  New developers come and go and they don’t seem to have much problem learning the new code base, assuming that’s it’s been commented and written with good design principles.

Conclusion

If your organization is not mandating code reviews, you should reconsider this decision and, ideally, opt for non-blocking code reviews.  There are various other ways to implement code reviews that I did not cover in this document, but whatever you choose, make sure that members on your team regularly get exposed to code coming from other members, even if superficially.

How about yourself?  Are you doing code reviews in your company?

via: http://beust.com/weblog/2006/06/22/why-code-reviews-are-good-for-you/

Programming, Tools

Introducing node.js Tools for Visual Studio

Leave a comment
node.js and Express running in VS

Just when you thought it couldn’t be crazier in Redmond, today they are introducing node.js Tools for Visual Studio!

NTVS runs inside VS2012 or VS2013. Some node.js enthusiasts had forked PTVS and begun some spikes of node tools for VS. At the same time the PTVS team was also working on node.js integration, so they all joined forces and made NTVS a community project. NTVS was developed by the same team that brought you PTVSwith help from friends like Bart Read from Red Gate (he did the npm GUI), and Dmitry Tretyakov from Clickberry for several debugger fixes & features.

NTVS is open source from the start, and has taken contributions from the very start. It supports Editing, Intellisense, Profiling, npm, Debugging both locally and remotely (while running the server on Windows/MacOS/Linux), as well publishing to Azure Web Sites and Cloud Service.

It’s actually pretty freaking amazing how they did it, so I encourage you to download it and give it a try because some of the stuff (even given this is an alpha) is very very clever.

Blank Express Application

Node.js Tools for Visual Studio takes advantage of V8 Profiling API’s as well Visual Studio’s Reporting features to give you a sense of where your program is spending its time.

NOTE: See that File | New Project dialog up there? Visual Studio organizes things by language, so node.js is under JavaScript. But you’ve also got Python and Django, iOS and Android via C#, TypeScript, VB, F#, all in Visual Studio.

One of the things that’s impressed me about the way they integrated node.js into Visual Studio was that they didn’t try to recreate or re-do things that already worked well. It’s node, it runs node.exe, it uses the V8 debugger, it uses the V8 profiler because that’s what people use. Duh. But, for example, NTVS can take the output from the V8 profiler and display it using the Visual Studio Profiler Reporting Tools. No need to reinvent the wheel, just use the right tool for the job.

HACKING ON THE GHOST BLOGGING ENGINE WITH NODE.JS FOR VISUAL STUDIO

Let’s look at an example.

From within Visual Studio, go File New Project, click JavaScript, then “From Existing Node.js code.”

From Existing node.js Code

Point NTVS to your Ghost folder.

Create from Existing Code

Then tell node.js for VS that the startup file is index.js, hit Next, save the project file and Finish.

Create New Project from Existing Code

At this point, you’ve got Ghost inside VS.

Random: that since I have Web Essentials I also get a nice split-screen markdown editor as well.

From here, just hit F5 to Debug, or Ctrl-F5 to start without Debugging. Also notice the properties of the Project in the lower right corner there showing the node path and port as well as the Startup File. You can change these, of course.

Ghost inside Visual Studio with NTVS

Here’s me running Ghost locally. You can see the path to node, the ghost.js file and my browser.

Running Ghost in VS with node for VS

You’ll get good intellisense for completions and help for method signatures.

Intellisense example

DEBUGGING

Node.js Tools for Visual Studio includes complete support for debugging node apps. This includes support for Stepping, Breakpoints, “Break on exception”, as well as Locals, Watch, Immediate and Call Stack tool windows.

You can manage Exceptions just like any other language service. See in the dialog below node.js exceptions are listed along with other exceptions in managed and unmanaged code.

Managing Exceptions in node.js for Visual Studio

The debugging still happens like it always has, with the node V8 debugger, except Visual Studio connects to the debugger over another socket (remember, you can even debug node.js remotely running on a Linux or Mac like this!) and translates how V8 thinks into how Visual Studio thinks about debugging. The experience is seamless.

See in this screenshot, you can see node.exe is being debugged, I’m running Ghost. You can see my Call Stack, and the Locals in the Watch Window. I can inspect variables, step around and do everything you’d want to do when debugging a Web App.

Debugging Session of Ghost in VS with Node Tools for Visual Studio

NPMVISUAL STUDIO

The npm experience is pretty cool as well. Node.js for Visual Studio is always watching the file system so are more than welcome to run npm from the command line or from within the node immediate window and Visual Studio will see the changes.

You can also use the npm Package Management dialog and search the repository and install packages graphically. It’s up to you.

npm package management within VS

Here’s a package installing…

Installing a module

The physical node_modules and how modules are handled is pure node…VS doesn’t touch it or care. However, the Solution Explorer in Visual Studio also presents a logical view on top of the physical view.

image

NOTE: I really like this. I think it has potential and I’d even like to see references in .NET treated like this. The physical and the logical, along with a dependency tree showing NuGet packages. It helped me understand the project much better.

There’s lots more. There’s an REPL interactive window, and you can just publish like any other web project using the same Publish Wizard that ASP.NET projects use. You can publish node.js apps directly to Azure as well, either with Git or with Visual Studio publishing.

You can also remotely debug node instances running on other machines by starting node with the included Remote Debugging Proxy.

image

node.exe RemoteDebug.js -machineport 5860 script.js

As mentioned, you can do remote debugging between Visual Studio and node running on any server OS.

CONCLUSION

I’m personally pretty happy with the way that Visual Studio is turning (in a short amount of time, seems to me) into quite the competent language and environment factory.

Node.js Tools for Visual Studio is entirely open source under the Apache license and they welcome contributions and bug reports. It’s Alpha and it’s early but it’s awesome. Go get it. Big congrats to all involved!

via: http://www.hanselman.com/blog/introducingnodejstoolsforvisualstudio.aspx

Programming

ASP.net MVC Vs ASP.net Web Form

1 Comment

Software Architects have been involving lot of debates about different approaches and architectures. Some of the examples are ORM Vs Store Procedures, REST Vs SOAP, etc. There is a debate happening inside the Microsoft community about ASP.net web form Vs ASP.net MVC. Many people thinking that ASP.net MVC will be replace webforms at least eventually and others are thinking that ASP.net MVC will not be replace webforms. Will ASP.net MVC replace webforms?. ASP.net MVC is an alternative approach to webforms rather than a replacement. It will not replace webforms and webforms will not replace ASP.NET MVC. The fact is that ASP.NET MVC and webforms will co-exist and that ASP.NET MVC is not a replacement for webforms. If you prefer ASP.net MVC use it and you feel webform is more comfortable, you can use it. . Both approaches are just choices and different approaches and choices are good things. Different choices are available for other platforms especially in the Java platform.

Problems with ASP.net Web Form

What are the problems with webforms? In webforms, Microsoft has tried to make windows form model development for web application development. That model was attracted lot of windows form developers especially VB 6.0 developers. Many of VB 6.0 developers had moved to ASP.net web development without knowing the basics of HTTP and web. For simulating windows form model development experience, webforms introduced event-driven approach and also introduced Viewstate and Postback. The end result is that web forms breaks the stateless nature of the Web. Both Viewstate and Postbacks have been made lot of problems and increased complexity of the web application development. Many web pages having hundreds of KB size of Viewstate that affected the performance of the applications sometime. Developers do not have the control of the rendering HTML of web forms and Server controls that render html with mixed inline style and deprecated tags that does not follows standards. Another problem with Web Forms is the integration of JavaScript frameworks due to the naming conventions of rendered HTML. The page life cycle of the Web Form is too complex and has the tightly coupling between all things in the ASP.net framework and a single class is used both to display output and handles user input. So unit testing is almost an impossible task. Today unit testing is very important in modern software development especially when we following agile methodologies and practices. Since web is a stateless thing, Events, Postbacks and Viewstate are not a good way. Today many ASP.net web form developers are facing different type pf browser compatibility issues when developing public face internet applications

The ASP.net MVC way

The ASP.NET MVC simplifies the complex parts of ASP.net Web Forms without any compromise of the power and flexibility of ASP.NET platform. ASP.net MVC implements Model-View-Controller UI pattern for web application development that lets you allows to develop applications in a loosely couples manner. MVC pattern is separating the application in three parts- Model, View and Controller. A view is responsible for rendering the user interface (UI) of the application and it is nothing more than html templates that filled with application’s data passed by the controller. The Model implements the logic for the application’s data and it represents the business objects of the application that using the View for rendering user interface. Controllers are handles and responds to user input and interaction. The web request will be handled by the controller, and the controller will decide which model objects to use and which view objects to render. The MVC model replaces the Web Form events with the controller actions. The main advantages of the MVC models are clear separation of concerns, unit testing facility, and more control over the URLs and HTML. The MVC model does not use Viewstate, Postbacks, Server controls, and server-based forms that enable full control over the application and html rendered by the Views. MVC model is using Representational state transfer (REST) based URLs instead of file-name extensions used by the Web Form model so that we can make search engine optimization (SEO) URLs published by the application.

The below code shows the implementation of MVC application.

ProductsController.cs (Controller)

 


In this sample, I have used extension methods to the HtmlHelper class to display ordered list of information.

OrderListExtensions.cs


Category.aspx (View)

Advantages of MVC Model

  1. Enable clean separation of concerns (SoC) .
  2. Enable full control over the rendered HTML.
  3. Enable Test Driven Development (TDD) (built with TDD in mind).
  4. SEO and REST friendly URL.
  5. Easy integration with JavaScript frameworks.
  6. Support third-party view engines such as NVelocity, Brail, NHaml.
  7. No ViewState and PostBack events.
  8. Follows the stateless nature of web.
  9. Extensible and Pluggable framework.
  10. Ideal platform for Web 2.0 applications.

Advantages of Web Form Model

  1. Provides RAD development.
  2. Easy development model for heavy data-driven LOB applications.
  3. Provides rich controls.
  4. Familiar model for windows form developers.

Which is the best approach?

The choice would be vary on different people. If you want more control over the HTML or you want Test Driven Development (TDD), or you care about web standards, accessibility, or you want to build SEO based URLs, you can choose MVC model. If you want rich controls and state oriented event-driven web development, you can choose Web Forms model. If you feel more comfortable with MVC, choose that model and you feel Web Form model is more comfortable, choose that model. Both are just choices. If you start your career with ASP.net Web Forms and do not have full knowledge of Web, it will be very difficult moving to MVC model.

I prefer MVC over Web Forms and I feel that Microsoft is going to a right direction through MVC. Its technical features as well as the open source nature are attracted me a lot.The MVC model allows me full control over the HTML and enables Test Driven Development (TDD). We can easily integrate with jQuery and other JavaScript frameworks with MVC. Using extension methods of C# 3.0, we can make powerful and rich HTML helper methods. I believe that tesatbility, refactoring capability and maintainability are the main factors for a successful project and prefer these factors than RAD capability. The MVC model allows to build highly testable, maintainable loosely coupled applications with good practices such as TDD, Seperation of Concerns (SoC) and Dependency Injection (DI). You MUST use ASP.NET MVC for public face internet applications.

via: http://weblogs.asp.net/shijuvarghese/archive/2008/07/09/asp-net-mvc-vs-asp-net-web-form.aspx