Questa frase racchiude uno dei capisaldi delle metodologie agili: la semplicità, eppure ancora oggi come sviluppatori siamo sempre affascinati dalla complessità come se fosse una misura della nostra bravura. WardCunningham insieme a Kent Beck hanno coniato questo principio nel 2004. Nella sessione ripasseremo i principi di extreme programming e (senza vergogna) vi racconterò di alcuni degli approcci e dei pattern che oggi utilizzo per progettare e scrivere le applicazioni.
1. The simplest thing that could possibly work
Emanuele DelBono - CodicePlastico
2. Cos’è il codice “semplice”?
/
/
OrderController
public IEnumerable<OrderRes> GetOrders(int orderId)
{
return _dbGateway.Execute<OrderRes>("SP_GET_ORDER", orderId);
}
3. Disclaimer
● Tutto quello che dico può essere giusto e condiviso ma anche sbagliato e
discorde dalle vostre opinioni, tutto dipende dal contesto, dai gusti e dalla
vostra esperienza. ☮💙
● L’obbiettivo di un team agile è consegnare software funzionante
7. E’ facile scrivere codice semplice?
Simplicity and elegance are unpopular because they require hard work and
discipline to achieve and education to be appreciated
(Edsger W. Dijkstra)
8. Cos’è il codice “semplice”?
● Facile da leggere
● Facile da capire
● Facile da cambiare e mantenere (o da cancellare)
9. Cos’è il codice “semplice”?
Assert.That(x).Should().Be().Greater().Than(42)
25. The hello world
public static class Program
{
public static void SayHello(ISettingReader sr, IMessageComposer mc)
{
var message = sr.Get("MESSAGE");
var formattedMessage = mc.CreateMessage(new Capitalizer());
var printer =
PrinterFactory.createPrinter(sr.Get("CONFIGURED_PRINTER"));
printer.print(formattedMessage);
}
}
33. Alternative?
● Se è davvero solo CRUD: Rails/Django/Phoenix
● Oppure (CQS)
○ Separare lettura e scrittura (stesso db)
○ Salvare sempre tutti gli eventi
○ Salvare lo stato sul db
40. Framework
● Non sempre semplificano
● Rendono il codice meno flessibile
● La magia (metaprogrammazione, macro, AOP, mixin, classi base) rende il
codice complesso da capire
● Disaccoppiare con ACL
● Preferire librerie a framework
45. Idee dall’FP: Funzioni pure e strutture dati immutabili
● Idee dalla programmazione funzionale
● Funzioni pure senza side effect
● Strutture dati immutabili
● High order function
46. I buoni vecchi principi
● DRY
● KISS
● OCP
● YAGNI
● SOLID or CUPID
● Composition over inheritance
● Be explicit
47. Approccio Prototipo/MVP
● Scrivere codice come se non ci fosse un domani
● Soluzioni quick&dirty per arrivare al risultato
● Validare il risultato
● Buttare e ricominciare
48. Test Driven Development Write
a failing
test
Make
the test
pasS
Refactor
Il TDD è Lo strumento
per scrivere codice semplice.
Obbliga a pensare cosa devi fare.
Focus su uno scope ridotto.
49. Le regole
● Non si può scrivere codice nuovo applicativo a meno che lo si faccia per
far diventare verde un test
● Non si può scrivere più di uno unit test che fallisce (gli errori di
compilazione sono fallimenti)
● Non è consentito scrivere codice di produzione non necessario a superare
l'unico test rosso
50. test "Scan empty code should return 0" do
assert Checkout.scan("")
=
=
0
end
defmodule Checkout do
def scan(_code) do
0
end
end
51. Test Driven Development
○ Un test difficile da scrivere è indice di complessità del codice che
dovrà testare
○ Troppo setup
○ Troppe dipendenze
○ Test poco parlante
52. Test Driven Development
○ Ragioni da utente in modo dichiarativo
○ Favorisce l’ortogonalità delle dipendenze
○ Non scriviamo mai codice inutile
○ Il design emerge un po’ alla volta
○ Accorcia feedback loop
○ I test fanno da documentazione
53.
54.
55.
56. 4 rules of simple design
● Test Pass
● Express intent
● No duplication
● Small
57. As simple as possible, but no simpler. (Einstein)