The simplest thing that could possibly work
Emanuele DelBono - CodicePlastico

Cos’è il codice “semplice”?
/
/
OrderController
public IEnumerable<OrderRes> GetOrders(int orderId)
{
return _dbGateway.Execute<OrderRes>("SP_GET_ORDER", orderId);
}

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

SIMPLE CODE

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

La seniority ha un ruolo?

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)

Cos’è il codice “semplice”?
● Facile da leggere
● Facile da capire
● Facile da cambiare e mantenere (o da cancellare)

Cos’è il codice “semplice”?
Assert.That(x).Should().Be().Greater().Than(42)

assert(x > 42)

[
{
"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
}
]

PERCHÉ ACCADE

Fretta di consegnare

Troppo design up-front

Troppi cambi di requisiti

Inesperienza

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

ESEMPI e SPUNTI

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

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

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

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

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

Domain model monolitico

Bounded Context

CRUD con CQRS/ES

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

Microservizi!

Servizi “logici”

Process Manager

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

Useless layers

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

Il linguaggio ha un impatto sulla semplicità?

STRUMENTI UTILI

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

Modularizzare

Idee dall’FP: Funzioni pure e strutture dati immutabili
● Idee dalla programmazione funzionale
● Funzioni pure senza side effect
● Strutture dati immutabili
● High order function

I buoni vecchi principi
● DRY
● KISS
● OCP
● YAGNI
● SOLID or CUPID
● Composition over inheritance
● Be explicit

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

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.

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

test "Scan empty code should return 0" do
assert Checkout.scan("")
=
=
0
end
defmodule Checkout do
def scan(_code) do
0
end
end

Test Driven Development
○ Un test difficile da scrivere è indice di complessità del codice che
dovrà testare
○ Troppo setup
○ Troppe dipendenze
○ Test poco parlante

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

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

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

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

Grazie
emanuele@codiceplastico.com