venerdì 27 agosto 2010

Simplify packaging to speed up software developments


Once the team wrote the source code of an application, why should split that app into many modules (assembly, jar, dll, exe, binaries in general) ?

Sometime there are no choices: i.e.
  • when different part of the applications are developed with different technologies that require different compilers or even different operative systems.

Some other time when a group of classes are used by 2 or more applications, instead of duplicating the classes they must go in a module and be reused. Here is when the REP come in use:
REP The Release Reuse Equivalency Principle The granule of reuse is the granule of release.



In all the other cases, splitting classes in modules up-front without an concrete actual needs just
  • increase the complexity: when classes are grouped in different projects they are harder to find and it become easier to duplicate existing functionality by mistake, plus the dependency graph grow more and more complex

  • increase the build time: merging 70 small projects in 5 big projects with Visual Studio reduced build times by 40%

  • does not bring any advantage: when classes that are changed and released together and are coupled together, splitting them in many modules will not reduce coupling and will decrease cohesion (fyi: namespaces should be used to logically group classes instead of projects).
Here is where CCP and CRP come:
CCP The Common Closure Principle Classes that change together are packaged together.
CRP The Common Reuse Principle Classes that are used together are packaged together.





posted @ lunedì 1 gennaio 0001 00:00 | Feedback (0)

Prova sul campo di NDepend v3 (2/2)



Ho proseguito la prova sul campo la nuova versione di NDepend v3  con le metriche del codice, con CQL e il suo editor.

Con la SuperSolution, cioé la soluzione che include centinaia di migliaia di righe di codice e tutti i progetti della azienda per cui lavoro.








Metriche: 
  • Pratica e concreta la possibilitá di avere facilmente a disposizione lo stato della coverage dei test e la complessitá ciclomatica del ccodice: due indicatori importanti dello stato generale di salute della code-base.

  • Molto interessante la presenza di metriche calcolate a livello di namespace e non solo di assembly: indispensabile per i team che hanno compreso l'uso di namespace per organizzare logicamente il codice e applicano correttamente i principi di coesione e accoppiamento dei package
  • In generale ampia scelta di metriche calcolabili sul codice.

Code Query Language (CQL):
  • Migliorato in questa versione con nuove condizioni di WHERE evolute che permettono facilmente di individuare ad esempio codice non utilizzato che puo essere cancellato in sicurezza

  • Nuovo il supporto per confrontare il trend delle metriche con le versioni precedentio del codice. Cosi é possibile vedere l'andamento della code-base e ad esempio capire se la coverage o la CC sta calando o crescendo nel tempo

CQL Editor:
  • L'integrazione con l'IDE é pratica e intuitiva
  • La velocitá di risposta del Intellisense é migliorata cosi come la visualizzazione in real-time dei risultati mentre si edita la query.

  • L'intellisense pecca ancora specialmente quando si editano nel mezzo query preesistenti. Trovo piu comodo copiare e editare i molti esempi disponibili di query piuttosto che fare affidamento e lasciarmi guidare dal intellisente


NDepend: http://www.ndepend.com/Features.aspx



posted @ lunedì 1 gennaio 0001 00:00 | Feedback (0)