usta

Keep It Simple Stupid

Wprowadzaliśmy ostatnio w projekcie integrację z zewnętrznym serwisem na potrzeby nowej funkcjonalności. Zebraliśmy się żeby omówić jak ma wyglądać nowe rozwiązanie. Wymyślaliśmy połączenia między nowymi komponentami. Omawialiśmy sposób pozyskiwania danych z API. Projektowaliśmy schemat bazy danych.

Przez pewien czas rozmawialiśmy aż doszliśmy do wniosku, że za bardzo wszystko komplikujemy. Nie trzymamy się reguły KISS czy po Polsku BUZI. Niepotrzebnie próbujemy przewidzieć scenariusze, które na tę chwilę, zgodnie z dokumentacją, nie występują i może występować nie będą.

Nie ma potrzeby implementowania wszystkich dostępnych w API metod po naszej stronie. Jeżeli wykorzystujemy dwie to zaimplementujmy tylko te dwie. A co jeśli ktoś w przyszłości nie będzie miał dokumentacji i nie będzie wiedział, że istnieją inne metody, które akurat będą mu potrzebne? Jeśli jest taka potrzeba to można zapisać je w taki sposób:

<?php
class Api
{
    methodToBeUsedInTheFuture()
    {
        throw new NotImplementedYetException();
    }
}

 

W ten sposób nie tracimy czasu na pisanie kodu, który może nigdy nie będzie wykorzystany i zostawiamy sobie ściągę na przyszłość. To samo tyczy się też samych obiektów w ramach naszej funkcjonalności. Prześledziliśmy przypadki użycia i doszliśmy do wniosku, że niektóre z nich nigdy nie będą edytowane. Wystarczy obsłużyć dla nich jednorazowy zapis i pobieranie z bazy danych. Dzięki temu zaoszczędziliśmy dużo czasu bo operujemy na skomplikowanych strukturach.

Warto czasem zastanowić się czy to co napisaliśmy trzyma się KISS. Czasami warto też zapytać się kogoś o radę. Jeśli samemu próbuje się rozwiązać problem od dłuższego czasu to można wpaść na przedziwne pomysły. Powiew świeżości wniesiony przez opinię innej osoby może być bardzo pomocny.

Podczas przyrostowego realizowania projektu też warto pamiętać o tym żeby wszystko maksymalnie upraszczać. Jeśli wiemy, że aktualnie potrzebujemy w projekcie obsługę dla klasy samochód  a w przyszłości również dla pociąg to nie powinniśmy zaczynać od abstrakcyjnej klasy środek transportu. Jeśli na dany moment potrzebujesz tylko klasy samochód to napisz tylko tę klasę. Nie jesteś w stanie przewidzieć wszystkiego. Kiedy będziesz potrzebował pociągu to dopiero wtedy wynieś potrzebne metody do klasy nadrzędnej. Keep It Simple.

Kiedy sprawdzamy kod kolegi należy również zwrócić uwagę na to czy nie jest on niepotrzebnie zbyt skomplikowany. Osoba sprawdzająca powinna zrozumieć istotę problemu i sposób w jaki został on rozwiązany. Może będzie w stanie zasugerować twórcy prostsze rozwiązanie. Należy tu pamiętać o tym, że chodzi tu o szukanie prostszego, lepszego rozwiązania a nie wymóg napisania kodu tak jak sami byśmy go napisali.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *