Má cenu mít vždycky pravdu? Co to znamená mít pravdu v softwarovém vývoji? Jak důležité je pro lídra mít pravdu? A kdy to všechno začne být arogance? Měli jste někdy co dočinění s někým, kdo musel mít vždy pravdu?
Prozkoumáme pohled developera, lídra a architekta.
V návaznosti na předchozí článek budu pokračovat komplexitou škálování, komplexitou podpůrných částí a náhodnou komplexitou – typy, které je možné managovat, redukovat a dokonce i odstranit.
Komplexita je úhlavní nepřítel softwarového designu a architektury. Primárním úkolem softwarového architekta je odstranit, redukovat a spravovat komplexitu – v tomto pořadí. Ale co když samotná podstata problému, který řešíte, je komplexní? Co potom? Co vlastně znamená řídit komplexitu a co je vůbec komplexita?
Existuje několik typů softwarové komplexity, a každý typ vyžaduje jiný přístup.
Vývojáři používají slovo "abstrakce" běžně, nicméně často s omezeným chápáním významu. Pro většinu byl koncept abstrakce zastíněn jejím použitím v některých jazycích pro označení metody nebo třídy, která musí být děděna a přetížena. Stejně tak "použij abstrakci" pro spoustu developerů znamená "napiš abstraktní třídu".
Abstrakce je jednou z nejdůležitějších technik pro docílení decouplingu a stabilizaci veřejného rozhraní na všech úrovních.
Existuje několik způsobů, jak vytvořit modulit, a jeden z nich si dnes ukážeme. Ty důležité části, na které se dnes zaměříme, jsou: aplikační vrstva, business vrstva, fasády a repositáře, event bus/broker, CQ router a utilities.
Pochopení rolí a rozdělení těchto částí je základem pro napsání kódu, který neskončí jako "big ball of mud".