Today, I started to work on the blue CCD degree. It is the 5th and last sectional one.

Thus, I currently focus on these principles and practices:

  • Principles
    • Architecture and Implementation do not overlap
    • Implementation reflects Architecture
    • YAGNI (you ain’t gonna need it)
  • Practices
    • Continuous Integration (Setup & Deployment)
    • Iterative Development
    • Component-oriented Development
    • Test First

Here, we find a perspective slightly apart from the mere coding. Principles and practices both point out in their own way the relation of design/architecture on the one hand and realisation/implementation (in terms of program code) on the other. Design/architecture may be regarded as being one abstraction level higher than realisation/implementation.

The principles make you keep an eye on the distinction between architecture and realisation. In my point of view, at least the component-oriented development practice can be seen as a result of the implementation reflects architecture principle.

Besides architecture, other aspects of the software development process are involved here. Iterative development and test first address specification: Tests can be regarded as some sort of specification; iterative development results from continuous specification refinement. Finally, continuous integrations reminds you to install an automated setup and deployment mechanism here.

Just to mention it: The YAGNI principle is quite important, so it is repeated within the blue degree.

In summary, this CCD degree focuses on the embedding of the coding part in other aspects of the software development process such as specification, deployment, and architecture.

I have reached the upper half of the ladder. (I do not count the CCD black degree.)

Green is the 4th CCD degree and emphasises:

  • Principles
    • Open Closed Principle
    • Tell, don’t ask
    • Law of Demeter
  • Practices
    • Continuous Integration (Build & Test)
    • Static Code Analysis (Metrics)
    • Inversion of Control Container
    • Share experiences

The principles focus proper class design and lead to loose coupling. The same is true when making use of a container. Continuous integration and metrics increase productivity, for they check your software quality automatically. Once more, there are no rules at this degree.

I think I can rush through this degree, because I use these principles and practices (almost) every day. There is one exception: I have to get more interested in the code metrics, for I have really lost sight of that.

Sharing experiences - that is what a blog is for, isn’t it?

I started to wear my yellow CCD wristband today. So my focus is on the principles and practices of the 3rd CCD degree currently.

The yellow degree emphasises:

  • Principles
    • Interface Segregation Principle
    • Dependency Inversion Principle
    • Dependency Injection (without Locator or Container)
    • Liskov Substitution Principle
  • Practices
    • Automated Unit Tests
    • Mockups
    • Code Coverage Analysis
    • Partiticipation in technical conferences and meetings

Here is my attempt of a very short subsumption as I did in my post on the previous degree: The principles of the yellow degree support proper design and architecture, they enhance testability in the same way. This is required for the practices (except the participation in conferences), for these concentrate on (automated) code testing. (There are no rules here.)

Stefan Lieser told me, that together with Ralf Westphal he tried to build thematic bundles for each CCD degree. As I can see so far, they did a good job.

Once more, I am aware of almost all the elements focussed at my current degree. In general, most of the principles, rules, and practices presented on CCD are well-known. The purpose of a CCD degree is to concentrate on the elements of that degree and to try not to violate them. By this, they hopefully will become second nature to you.

A few weeks ago, we started to use a new tool by Ayende: The NHibernate Profiler (currently beta). It is a real-time debugger to debug and improve the usage of NHibernate in our modules.

The NHibernate Profiler provides a lot of valuable (technical and statistical) data on the current activity:

  • SQL statements per session with additional information: Details, stack trace, and alerts. Alerts are some warnings which Ayende explains on his website.
  • A session usage report: Number of entities loaded, entities loaded, duration, etc.
  • A session analysis, e.g. View by Method which displays all SQL statements generated by a particular method of a module.
  • Statistics not only on the sessions, but also on the session factory.

We have used it several times to see, what our modules using NHibernate internally do. In particular, the alert information have been extremely valuable for us.

Obviously, there are still some minor bugs in the beta version of the tool. For example, we get a Use of implicit transactions is discouraged alert although we only have explicit transactions.

Usage

In order to debug an application, the client for monitoring the activity has to be started. This client provides all the information explained above.

The best way to make your application communicate with the client is to use log4net, for the application (and the solution/project) does not need to be changed in any way in this case (provided that you already use log4net in your application). Just add an appender in the log4net.config file and make the required loggers use that appender.

Example:

<appender name="NHibernate.Profiler" type="HibernatingRhinos.NHibernate.Profiler.Appender.NHibernateProfilerAppender, HibernatingRhinos.NHibernate.Profiler.Appender" >
  <sink value="tcp://localhost:22897/NHibernateAppenderLoggingSink" />
</appender>
 
<logger name="NHibernate.Transaction.AdoTransaction">
  <level value="DEBUG"/>
  <appender-ref ref="NHibernate.Profiler"/>
</logger>
<logger name="NHibernate.Loader.Loader">
  <level value="DEBUG"/>
  <appender-ref ref="NHibernate.Profiler"/>
</logger>
<logger name="NHibernate.SQL">
  <level value="DEBUG"/>
  <appender-ref ref="NHibernate.Profiler"/>
</logger>
<logger name="NHibernate.Impl.SessionImpl">
  <level value="DEBUG"/>
  <appender-ref ref="NHibernate.Profiler"/>
</logger>
<logger name="NHibernate.Persister.Entity.AbstractEntityPersister">
  <level value="DEBUG"/>
  <appender-ref ref="NHibernate.Profiler"/>
</logger>

As this example shows, the profiler appender class has to be referenced and a TCP sink for the communication with the client has to be declared. The defined loggers redirect the required information to the profiler. Finally, the DLL containing the profiler appender class has to be stored in the application directory. That’s all. When running the application, the NHibernate activities are monitored by the client.

You can (and due to the licence, you probably must) ship your application without the profiler appender class DLL. There is no need to modify the log4net.config file, though. The profiler appender does not have to be removed. log4net just complains (within its log file), that the particular appender could not be instantiated (because it was not found). If you do not want that message in the log file, you have to ship your application with a log4net.config which does not contain the profiler appender.

Another way to use the profiler is to reference the HibernatingRhinos.NHibernate.Profiler.Appender.dll and make the following call within the application startup:

HibernatingRhinos.NHibernate.Profiler.Appender.NHibernateProfiler.Initialize();

But as this means a change of the application code and requires a reference within the project, I do prefer the first kind of usage. Additionally, the application cannot be shipped when modified in this way. (Remember, you may not ship the profiler appender class DLL with your application.)

,

I have mentioned the Clean Code Developer (CCD) and its idea earlier. After having worked on the red (1st) degree so far, I am currently focusing on the principles, rules, and practices of the orange (2nd) degree.

The orange degree emphasises:

  • Principles
    • One level of abstraction
    • Single Responsibility Principle
    • Separation of concerns
  • Rules
    • Source code conventions
  • Practices
    • Issue tracking
    • Automated integration tests
    • Read, read, read
    • Reviews

A two sentences subsumption: The principles and rules of the orange degree support readability and understanding of source code. The practices are related more or less to the soft skills of a software developer.

The first degree was comparably easy, because I was already aware of most of its elements. Nevertheless, it took me almost two months not to violate the 21 day rule, which says, that you may not violate any of the aspects of your current degree for that time span before you go on to the next degree.

Just one remark: CCD defines professionalism for a software developer. The application of what is said there leads straight to better (i.e. higher quality) software. It was not expressed that explicitly in my first post on CCD. But it seems important to me.

As a software developer, don’t we seek for more professionalism? But the question is rather: What does professionalism mean in this context?

The Clean Code Developer (German website) can be an answer for the latter question. That site was initiated by Stefan Lieser and Ralf Westphal. For them, there are two aspects which define a professional software developer. Such a professional

  • reflects, if he is satisfied with what he does and has done, and therefore
  • has an internal value system.

Ralf and Stefan want to define what the attitude of a professional programmer towards his work should be and how he should work. This definition is expected not to be complete, i.e. they expect changes of it due to new insights. But it should be mentioned that one of the very basic concepts is reflexion.

Ralf and Stefan took their ideas from the book Clean Code by Robert C. Martin, which I already had in my shelf before I got notice of the Clean Code Developer site. The content of this (very good) book is not really new. Rather, it is a compilation of known principles, rules, and practices for the field of software development. And so the purpose of the Clean Code Developer site is to gather these concepts and thus to be a guideline for developers who want to be professional.

A Clean Code Developer (CCD) runs through different degrees. Each degree sets the focus on a subset of the principles, rules, and practices. The degrees are represented by colours, starting with black and ending with white. If you have the feeling, that you really regard all the aspects of a certain degree, you can go on to the next one. (There is no exam to pass. You are responsible for yourself.) Currently, I am working on the red degree, which of course is the real entry point for a prospective Clean Code Developer. I am convinced by what Ralf and Stefan are trying to establish as well as I was by Robert’s book.

Keep your code clean!


Worth to be read:

Clean Code CoverMartin, Robert C.: Clean Code. A Handbook of Agile Software Craftsmanship.
Prentice Hall, 2009.
ISBN-13: 978-0-13-235088-4
ISBN-10: 0-13-235088-2