Mazaný a líný programátor

Školení, která pořádám

Vždycky jsem byl přesvědčen, že mazanost a lenost jsou dvě skvělé vlastnosti dobrého programátora. Vysvětlím to na kódu. Nejprve ukázka běžného přístupu:

<?php
final class Conventional {
    private $a;
    private $b;
    private $c;
    private $d;
    
    public function getA() {
        return $this->a;
    }
    
    public function setA(A $a) {
        $this->a = $a;
        return $this;
    }
    
    public function getB() {
        return $this->b;
    }
    
    public function setB(B $b) {
        $this->b = $b;
        return $this;
    }
    
    public function getC() {
        return $this->c;
    }
    
    public function setC(C $c) {
        $this->c = $c;
        return $this;
    }
    
    public function getD() {
        return $this->d;
    }
    
    public function setD(D $d) {
        $this->b = $d;
        return $this;
    }
}
?>

A teď řešení od mazaného a líného programátora. API není totožné, ale to je svým způsobem záměr:

<?php
final class SmartAndLazy {
    private $classes = array(
        'a' => 'A',
        'b' => 'B',
        'c' => 'C',
        'b' => 'D',
    );
    private $vars = array();
    
    public function __get($name) {
        return $this->vars[$name];
    }
    
    public function __set($name, $value) {
        if (method_exists($this, "set$name")) { // ošetření speciálních případů
            $this->{"set$name"}($value);
        } elseif (!array_key_exists($name, $this->classes)) {
            trigger_error("Property $name is not defined.");
        } elseif (!($value instanceof $this->classes[$name])) {
            trigger_error("Invalid class for property $name, must be " . $this->classes[$name] . ".", E_USER_ERROR);
        } else {
            $this->vars[$name] = $value;
        }
    }
}
?>

Druhé řešení považuji za v mnoha ohledech lepší. Jeho prvotní napsání bylo mentálně náročnější, při malém počtu vlastností asi i časově náročnější. Do budoucna nám ale přináší několik výhod:

Přidání nové vlastnosti je otázka jednoho řádku. U konvenčního řešení musíme přidat vlastnost a napsat dvě metody. Bude je někdo psát zgruntu? Těžko. Většina lidí si je zkopíruje a jen přepíše názvy vlastností.
V druhém řešení je těžší udělat překlep. U obou řešení jsem záměrně jeden udělal. Odhalíte ho? Co se stane, když zavolám $conventional->setD(new D)->getD() nebo $smartAndLazy->d = new D?
Druhé řešení můžeme vyčlenit do společného kódu (nejspíš přes trait) a použít ho ve více třídách.
Pokud se u druhého řešení pokusíme získat vlastnost, kterou jsme nejprve nenastavili, dostaneme E_NOTICE. Pokud bychom chtěli téhož dosáhnout u prvního řešení, museli bychom přepsat všechny gettery.
Pokud toto chování není v některých případech žádoucí, musíme to u prvního řešení vyřešit v každé metodě zvlášť, u druhého řešení to stačí na úrovni konfigurace (např. inicializací nepovinných položek v poli $vars).

Druhé řešení je podle mě krásná ukázka mazanosti (napíšeme kratší, i když složitější kód) a lenosti (přidání nové vlastnosti bude v budoucnu otázka jednoho řádku). Má i své nevýhody, i když čistě z technického pohledu mě napadá jediná:

Nedá se použít spolu s interface, ani pokud bychom zachovali původní API definicí metody __call.

Pokud bychom chtěli třídy doplnit o dokumentační komentáře, stálo by nás to u první varianty mnoho řádek balastního textu, u druhé varianty by to spláchnul jeden řádek @property pro každou vlastnost (ten je ale prakticky nezbytný, protože bez pohledu do třídy vůbec nemáme šanci zjistit, s čím pracovat lze a s čím ne).

Korporátní sféra

Ve Facebooku musí všechny změny schválit jiný vývojář. U prvního kódu je na první pohled jasné, co dělá, a bez problémů ho schválí prakticky kdokoliv. A to i přesto, že obsahuje snadno přehlédnutelnou a těžko odhalitelnou chybu.

Druhý kód naopak vyžaduje nemalé mentální úsilí nejen od toho, kdo kód schvaluje, ale i od všech dalších, kdo kód budou číst nebo s ním pracovat. Aby druhý kód vyhrál, musí mít opravdu zásadní přínosy a ušetřit do budoucna spoustu práce. Pár příkladů kódu od mazaného a líného vývojáře taky máme, ale ve většině případě je to spíš nudný kód podle prvního příkladu se všemi jeho nevýhodami.

Sám jsem se s tím také setkal: potřebovali jsme generovat dvě různé varianty celkem dlouhého HTML kódu, pro jehož vytvoření se používalo několik podmínek a cyklů. Vyřešil jsem to tak, že jsem vygeneroval kód jen jeden a pak ho v případě potřeby důmyslným způsobem převedl na druhou variantu. Na příkladu bych to mohl ukázat takhle:

<?php
$return = "";
foreach ($data as $key => $val) {
    if (is_valid($key)) {
        $return .= "<tr><th>" . htmlspecialchars($key) . "</th><td>" . htmlspecialchars($val) . "</td></tr>\n";
    }
}

if ($other_variant) {
    $return = preg_replace('~<tr><th>([^<]*)</th><td>([^<]*)</td></tr>~', '<span title="\1">\2</span>', $return);
}
?>

Změna mi sice byla schválena, ale ostatní vývojáři se jí báli, začali na ni svádět chyby, které vůbec nezpůsobovala, a nakonec ji smazali a nahradili jednoduchým kódem, který nejprve zjistil, která varianta se má generovat, a pak všechny cykly a podmínky provedl v obou větvích. Nějak takhle:

<?php
$return = "";
if ($other_variant) {
    foreach ($data as $key => $val) {
        if (is_valid($key)) {
            $return .= '<span title="' . htmlspecialchars($key) . '">' . htmlspecialchars($val) . "</span>\n";
        }
    }
} else {
    foreach ($data as $key => $val) {
        if (is_valid($key)) {
            $return .= "<tr><th>" . htmlspecialchars($key) . "</th><td>" . htmlspecialchars($val) . "</td></tr>\n";
        }
    }
}
?>

Jak tenhle kód vznikl? Copy/paste, samozřejmě. Co když budeme v budoucnu chtít udělat nějaké změny? Budeme je muset udělat na dvou místech, pochopitelně. Přesto se s tímto kódem většině lidí líp pracuje.

Co se náchylnosti k chybám týče, je to sporné. První kód je bez pochyby složitější, takže v něm lze snadněji něco pokazit. U druhého kódu je zase mnohem snadnější obě varianty rozhodit.

Co se dalšího rozvoje týče, je to taky sporné. Pokud budeme chtít obě varianty od sebe v budoucnu víc oddalovat, bude to jednodušší s druhou ukázkou. Pokud naopak budeme dělat stejné změny, tak u druhé ukázky uděláme spoustu zbytečné práce navíc.

Závěr

Často si proto při vývoji Facebooku říkám: „Nesnaž se být mazaný a nebuď líný.“ U svých projektů v mazaných řešení, které mi do budoucna ušetří práci, budu pokračovat, protože mi to činí potěšení. Ale ve firmě, kde se stejným kódem pracuje spousta lidí, jsou obvykle lepší jednoduchá řešení, která do budoucna práci neušetří, mají své problémy, ale každý je na první pohled pochopí. A taky je pravda, že chyby, které opravuji, mnohem častěji vznikly tak, že se někdo snažil být příliš mazaný, než že by zapomněl stejnou změnu na všech potřebných místech.

Jakub Vrána, Dobře míněné rady, 30.3.2012, diskuse: 75 (nové: 0)

Diskuse

Michal Raška:

Jakube, mazaná řešení jsou fajn, ale nový programátor, který na nich bude chtít pokračovat, tě nejspíš bude chtít zabít obzvláště nehezkým způsobem. Protože, co ty jsi ušetřil, tak on ztratí dvojnásobně, než pochopí co to doopravdy dělá.

Mazaný a líný programátor

Školení, která pořádám

Korporátní sféra

Závěr

Diskuse

Michal Raška:

Jakub Vrána :

Michal Raška:

radix:

Já:

Jakub Vrána :

Michal Raška:

Jakub Vrána :

Michal Raška:

Jakub Vrána :

Michal Raška:

Honza:

MIchal:

Filip Procházka (@HosipLan):

MIchal:

Michal Špaček:

kevujin:

Jakub Vrána :

David Grudl:

Richard Šerý:

Substance242:

MIchal:

Richard:

v6ak:

Jakub Vrána :

ptica:

lopata:

Martin Soušek:

Jakub Vrána :

Martin Soušek:

radix:

Pavel:

Pavel:

David Grudl:

Olda:

Knyttl:

Jakub Vrána :

Knyttl:

Sniper:

Knyttl:

radix:

Knyttl:

radix:

Knyttl:

Jakub Vrána :

Franta:

Jakub Vrána :

Franta:

Jakub Vrána :

Jakub Tesárek:

David Grudl :

Jakub Vrána :

Jakub Tesárek:

David Grudl :

ToM:

David Grudl :

Jakub Vrána :

dynínská výzva:

David Grudl:

Ondřej Mirtes:

mj41:

Jakub Vrána :

Jakub Vrána :

Jakub Vrána :

mj41:

lopata:

David Grudl :

Jakub Vrána :

David Grudl :

David KONEČNÝ:

David Majda :

David Majda :

lopata:

Patrik Šíma:

František Musil: