L’esperienza accumulata, i rake raccolti e le funzionalità testate da tempo e da centinaia di sviluppatori sono il modo migliore per descrivere il significato delle librerie utilizzate nello sviluppo.

L’uso di librerie già pronte presenta pro e contro:

• + Non dovete perdere tempo a reinventare la ruota.
• + Avete già testato le funzionalità pronte e risolto i “problemi dei bambini” (se la libreria è popolare).

1. Il programmatore non è sempre interessato a come la libreria sia vulnerabile e influisca sulle prestazioni.
2.  Il modulo può essere piuttosto ingombrante se si ha bisogno di utilizzare solo una piccola parte delle sue funzionalità. Se sono necessarie solo un paio di ore di lavoro per l’implementazione, spesso non è giustificato utilizzare soluzioni già pronte. Quando si può risolvere un compito enorme con un paio di righe di codice e importarlo, non ha senso reinventare la ruota. È importante capire e stimare inizialmente le dimensioni della funzionalità prevista. Questo si ottiene con l’esperienza.

Alcune cose non si possono fare senza le librerie (o almeno si possono fare, ma sono difficili, lunghe e non hanno senso). Stiamo parlando soprattutto dell’accesso a strumenti e servizi di terze parti. Ad esempio, il pagamento all’interno delle applicazioni mobili avviene tramite lo standard, ma è comunque una libreria.

La visualizzazione di un’immagine nell’elenco può sembrare un compito facile. Ma in realtà, ci saranno alcuni problemi con la cache, il ridimensionamento, l’arrotondamento degli angoli, ecc. Questo è un buon esempio di quando l’uso di librerie di immagini popolari è più che giustificato.