Archivi tag: best-practices

ALM DOs & DON’Ts – Definition of done

We all have been in this kind of situation: someone in the team states that a feature is done but in reality there is that little thing to figure out and the coding is completed the day after. Why is that? Because every person has a different definition of done inside his mind.
How can we protect a team from this? Simple! With a Definition of Done.

definition-of-done.png

A good definition of done explicits what activities has to be done before declaring that our coding activites are over.
For example:

  • All unit tests are green
  • Coding style and conventions are respected
  • UI respects the specs validated by the Customer.

Every team and every project will create a different definition of done. The very important thing is that you and your team discuss such a definition to remove wrong expectaions about the status of work in progress.

SOLID principles by examples: open/closed

This post continues the analisys of the SOLID principles started some blog posts ago. This is the turn for the Open Closed Priciple (OCP).

The definition

An object/entity should be open for extension but closed for modification.

What we are basically talking about is to design our modules, classes and functions in a way that when a new functionality is needed, we should not modify our existing code but rather write new code that will be used by existing code.

Continua a leggere SOLID principles by examples: open/closed

SOLID principles by examples: introduction

SOLID is a common acronym in the software development world. It’s useful to remeber five best practices to design classes in a object oriented language. It means:



Initial

Stands for

Concept

SRP Single Responsability Principle A class should have only a single responsability.
OCP Open Closed Principle Software entities should be open for extension but closed for modification.
LSP Liskov Substitution Principle Objects in a program should be replaceable with instances of theri subtypes without altering the correctness of that program.
ISP Interface Segregation Principle Many client-specific interfaces are better than one general purpose-interface.
DIP Dependency Injection Principle

One should depend upon abstractions, not concretions.

These concepts are easy to understand when we read them, but what does it mean to apply them in our daily coding activities? What do we have to do?

In the next posts we’ll go through each concept with coding examples because as someone much smarter than me said:

Tell me and I’ll foget, show me and I might remember. Involve me and I will remember. – Confucius

Gold-plating

Qualche settimana fa non conoscevo questo termine.

Avete presente quel momento in cui si sta sviluppando qualcosa e il pensiero comincia a prendere la tangente: “Ma se succedesse anche questo allora c’è bisogno di quest’altro. A questo punto all’ora potrei implementare questa funzione!”. Oppure: “Aggiungiamo anche questa funzione perché magari può succedere che…”. Quando sentiamo queste frasi dette da qualcun altro o che girano per la nostra testa dovremmo immediatamente tirare il freno a mano. Quello che sta succedendo è, molto probabilmente, gold-plating. Stiamo facendo più del richiesto.

Quando sviluppiamo un software che sia su commessa o che sia per essere proposto nel mercato, dovremmo fare ogni sforzo possibile per implementare solo ed esclusivamente quelle funzioni che sono state analizzate e confermate in fasi precedenti allo sviluppo. Se stiamo affrontando un esercizio accademico, o per studio, allora ci può stare ma non esistono altre eccezioni.

I motivi?

  • Potremmo sviluppare qualcosa di non gradito;
  • Potremmo addentrarci nello sviluppo di qualcosa che, involontariamente, peggiora la situazione del progetto perché più complessa del previsto;
  • Si compromette la buona riuscita del progetto perché si sta dedicando tempo a qualcosa che  non era stato inserito nella pianificazione;
  • Potremmo scatenare effetti collaterali in altre parti del software a cui non abbiamo pensato;
  • Aumentano i costi;
  • Il committente non sta pagando per quelle righe di codice.

Il concetto del gold-plating non si applica solo a livello di progetto ma a tutti gli strati di una progettazione software:

  • Se stiamo sviluppando una classe potremmo inserire funzioni non strettamente di sua competenza;
  • In una interfaccia utente potremmo mettere troppe funzioni che ne complicano l’utilizzo;
  • In una tabella di un db potremmo mettere colonne che causano ridondanze che devono essere mantenute per niente.
  • Un metodo di una classe potrebbe voler fare troppe cose e diventare un monolite.

Come programmatori dovremmo sempre essere sull’attenti quando stiamo implementando qualcosa: meno scriviamo e meno danni facciamo, meno danni facciamo e più è alta la probabilità di fare qualcosa che funziona.