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

4. SIMPLE CODE

5. I costi di sviluppo crescono esponenzialmente all’aumentare della complessità

6. La seniority ha un ruolo?

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)

10. assert(x > 42)

12. [
{
"id": 1,
"title": "Clean Code",
"authors": [ "Robert C. Martin" ],
"year": 2008
},
{
"id": 2,
"title": "Structure and Interpretation of Computer Programs",
"authors": [ "H. Abelson", “G. J. Sussman" ],
"year": 1984
}
]

16. PERCHÉ ACCADE

17. Fretta di consegnare

18. Troppo design up-front

19. Troppi cambi di requisiti

20. Inesperienza

21. Il software è un prodotto secondario di un processo di apprendimento
ziobrando

24. ESEMPI e SPUNTI

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);
}
}

26. Astrazioni errate
const Page1 = (props)
=
>
{
return (
<div class="container">
{
/
*
content
*
/
}
<div class="pop-up-dialog-error-one">
<h3>Inserire il nome del cliente
<
/
h3>
<div class="dialog-body">
<img src="trash"
/
>
<button value="Ok" onClick={onOnCustomer}
/
>
<
/
div>
<
/
div>
<div class="pop-up-dialog-error-two">
<h3>Errore durante il salvataggio
<
/
h3>
<div class="dialog-body">
<img src="error"
/
>
<button value="Ok" onClick={onSaveError}
/
>
<
/
div>
<
/
div>
<
/
div>
)
}

27. Astrazioni errate
const dialog = (props)
=
>
{
return (
<div class="pop-up-dialog">
<h3>{props.title}
<
/
h3>
<div class="dialog-body">
<img src={props.icon}
/
>
<button value="Ok" onClick={props.onOk}
/
>
<
/
div>
<
/
div>
)
}

28. const dialog = (props)
=
>
{
let buttons;
if (props.isYesNo) {
buttons = <div>
<button value="Yes" onClick={props.onYes}
/
>
<button value="No" onClick={props.onNo}
/
>
<
/
div>
} else {
buttons = <button value="Ok" onClick={props.onOk}
/
>
}
return (
<div class="pop-up-dialog">
<h3>{props.title}
<
/
h3>
<div class="dialog-body">
<img src={props.icon}
/
>
{buttons}
<
/
div>
<
/
div>
)
}

29. duplication is far cheaper than the wrong abstraction
prefer duplication over the wrong abstraction
Sandi Metz

30. Domain model monolitico

31. Bounded Context

32. CRUD con CQRS/ES

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

34. Microservizi!

36. Servizi “logici”

37. Process Manager

38. Siamo sicuri che la Single Page Application sia sempre la scelta giusta?

39. Useless layers

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

41. Il linguaggio ha un impatto sulla semplicità?

42. STRUMENTI UTILI

43. Misurare
● Cyclomatic complexity
● Afferent Coupling
● Efferent Coupling
● Depth of inheritance
● Instability
● Abstraction level
● …

44. Modularizzare

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

56. 4 rules of simple design
● Test Pass
● Express intent
● No duplication
● Small

57. As simple as possible, but no simpler. (Einstein)

60. EMANUELE DELBONO
Founder & Software developer @ CodicePlastico
emanuele@codiceplastico.com
@emadb

61. Grazie
emanuele@codiceplastico.com