Code review!

A common practice in software projects is peer code review. The general view is that code review helps identifying potential bugs and enforcing a project’s coding standards. While I do not disagree with this, I believe code review can mean much more for a project and its team. Consider code review embraces four regions where your, the reviewer’s, ability to learn and teach crosses technical and domain knowledge.

Teaching + Programming: Code reviews gives you an excellent opportunity to share your programming knowledge with your peers. The goal here is not to show off the latest tricks you learned but to improve the skills of an another developer. You can actively contribute to a person’s growth as a programmer by providing valuable feedback. Coaching novices in a particular technology or introducing people into the specific practices of your project are just two ways of achieving this.
Teaching + Domain: Most software projects built in teams are characterized by a non-trivial domain. A non-trivial domain requires a significant amount of modeling to represents its behavior and attributes in code. Since the modeled behavior and attributes are inseparable of the code it seems more than reasonable for the domain aspect to be included in a code review. The reviewer can play a significant role in overall domain modeling by thinking along.
Learning + Programming: Reviewing code exposes developers to different ways of solving problems. Observing and understanding code written by other programmers is an effective way to ameliorate your coding style and techniques, get to know new libraries and learn patterns. Moreover, it provides inspiration for solving problems yet to come and ideas for improving existing code.
Learning + Domain: The information captured in the code makes it a primary resource for learning about domain concepts and the overall functionality. Code is de facto the most detailed documentation of a software system. Reading it with comprehension extends the understanding of a system beyond the parts one was involved implementing.
Most developers will move between the code review regions as they become better programmers and learn more about certain domains. While some will have the opportunity to learn more often; others will frequently fulfill the teaching role. If a developer is new to the technology used in a project, but an expert in the domain, he might have two roles. In some cases the reviewer will find himself in the four regions at once. The advantage of recognizing these regions is that doing a code review is always valuable regardless of the reviewer’s seniority level.
Expanding your regular code review to the fours regions described above can contribute to your project and team by:

• making the code the property of all developers in the team – As developers we like to feel at home in a codebase. Reviewing code switches the code ownership from the author to the team and turns it to a common good. It makes the whole team responsible for the code quality and enables any team member to introduce changes. This is also related to shared code (or collective code ownership) in Extreme Programming.
• gradually improving developers’ programming skills – Peer review will raise the average skill level of a team. Furthermore, it introduces a subtle pressure which motivates developers to write their best code.
• spreading domain knowledge – Understanding the functionality captured in the code helps spreading the knowledge about the whole system between all team members. It makes the team more confident as a whole, enables any developer to work on any part of the system which as result makes story “cherry-picking” less likely to happen.
• fostering collective intelligence – The quality a team can achieve together is greater than the sum of what developers could achieve when working alone. Every developer brings different skills to the table and ideally a team achieves programming synergy by picking everyone’s best qualities.

Code review is one of my favorite team building exercises. It is not only about the code but very much about growing into a great team. It is worth mentioning that pair programming can be seen as an extreme form of code review. Depending on the frequency of pairing it can be used as complimentary to code review or as an entire replacement.

Loading AngularJS Components With RequireJS After Application Bootstrap

Posted November 5, 2013 at 9:40 AM by Ben Nadel

Tags: Javascript / DHTML

Yesterday, I looked at loading AngularJS components after your AngularJS application has been bootstrapped. In that experiment I simply waited until DOM-Ready before I registered said components. That didn't really make them lazy-loaded, it only demonstrated that the components could be registered post-bootstrap. Today, I wanted to play around with using RequireJS in order to make the components truly lazy-loaded.

View this demo in my JavaScript-Demos project on GitHub.

When I think about a cohesive set of AngularJS components, I think about two things: the JavaScript parts and the HTML parts. In order for RequireJS to lazy-load some aspect of our AngularJS application, it will have to load both the JavaScript objects and the HTML templates. In this demo, I'm using the RequireJS plugin - text.js - to load said templates.

Because RequireJS is asynchronous in nature, the code that lazy-loads the AngularJS components must also be asynchronous. This means that it must operate within some callback-based workflow. Since AngularJS already has $q - a Deferred / Promise library - I decided to encapsulate the RequireJS behavior behind a $q promise. This has the added benefit that multiple sources can listen for the resolution of the lazy-loaded components.

Simply loading and executing the "lazy" JavaScript file will register the JavaScript components. The HTML templates, on the other hand, require a little bit more work; once they have been loaded by RequireJS, the Script tags (type="text/ng-template") have to be explicitly injected into the AngularJS template cache.

That said, the following demo is yesterday's demo, refactored to use RequireJS:

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295

ng-app="Demo"> charset="utf-8" />

ng-controller="AppController">

 

Loading AngularJS Components With RequireJS After Application Bootstrap

 

ng-click="toggleSubview()">Toggle Subviews

 

ng-switch="subview">

 

ng-switch-when="before">

 

Before app bootstrap.

 

 

ng-switch-when="after" ng-include=" 'after.htm' ">

 

 

 

 

view rawangularjs-requirejs.htm hosted with ❤ by GitHub

As you can see, the controller that wants to make use of the lazy-loaded module must use the "withLazyModule()" function. This function returns a promise; however, it also accepts callbacks which will be automatically wired into the underlying deferred resolution. When the promise has been resolved, the lazy-loaded components have been injected into the AngularJS application and are ready to be consumed.

The two files that are loaded via RequireJS are the HTML templates:

1234567891011121314

view rawlazy.htm hosted with ❤ by GitHub

... and the JavaScript components:

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475

// This component collection is intended to be all the controllers, // services, factories, and directives (etc) that are required to // operate the "Lazy" module. // -- // NOTE: We are not actually creating a "module" (as in angular.module) // since that would not work after bootstrapping.     // Lazy-loaded controller. app.controller( "LazyController", function( $scope, uppercase, util ) {   $scope.message = util.emphasize( uppercase( "After app bootstrap." ) );   } );     // Lazy-loaded service. app.service( "util", function( emphasize ) {   this.emphasize = emphasize;   } );     // Lazy-loaded factory. app.factory( "emphasize", function() {   return( function( value ) {   return( value.replace( /\.$/, "!!!!" ) );   } );   } );     // Lazy-loaded value. app.value( "uppercase", function( value ) {   return( value.toString().toUpperCase() );   } );     // Lazy-loaded directive. app.directive( "bnItalics", function() {   return( function( $scope, element ) {   element.css( "font-style", "italic" );   } );   } );

view rawlazy.js hosted with ❤ by GitHub

As you can see, the lazy-loaded components are registered in the same way that any of your AngularJS components are registered. We didn't use a "module" here (as in angular.module()), since the new module wouldn't populate the correct dependency injection container.

There's so much more to think about here, but this is pretty exciting! I love the idea of being able to lazy-load parts of your AngularJS application. It definitely requires some more thinking and more organization; but, it could really be great for load-times.