Obrona dla płyty kotłowej?

Dla mnie kod płyty głównej jest oczywiście zły. Jednak spotkałem programistę, który wykazuje opór przy każdej próbie zmniejszenia płyty kotłowej. Uświadomiłem sobie, że nie miałem łatwo sformułowanego, dobrze przemyślanego argumentu po odrazie, którą rozwinąłem z czasem.

Jakie są niektóre kontrargumenty, abym mógł sformułować przekonujący argument za faworyzowaniem mniejszej liczby płyt grzewczych? Innymi słowy, jakie są argumenty (jeśli w ogóle) na korzyść płyty kotłowej?

(Mam na myśli to, co myślę, że ogólnie rozumie się przez płytę kotłową, ale dobrym przykładem są pobierające i ustawiające w Javie).

Jedną ważną rzeczą do zapamiętania jest to, że kod jest zwykle zmniejszany przez usunięcie niepotrzebnego kontekstu. Jeśli kompilator może coś rozgryźć, argument jest oczywisty , nie ma potrzeby jawnego zapisywania tego.

Byłoby wspaniale, gdyby tylko kompilator miał zamiar go przeczytać. Pamiętaj jednak, że „programy powinny być pisane tak, aby ludzie je czytali, a tylko przypadkowo, aby maszyny mogły je uruchomić”. (Jak na ironię, ten cytat pochodzi z podręcznika poświęconego jednemu z najtrudniejszych ze wszystkich języków dla zwykłych ludzi do czytania, w dużej mierze ze względu na jego nadmierną zwięzłość).

To, co może ci się wydawać nudne, powtarzalne, jest dla ciebie cennym kontekstem dla kogoś, kto przyjdzie rok (lub pięć) później i będzie musiał zachować twój kod.

WRT konkretnie przykład Java, zgodzę się, że jest to dobry przykład złej płyty, ponieważ można ją zastąpić czymś, co jest zarówno krótsze i łatwiejsze do odczytania, jak i bardziej elastyczne: Właściwości. Ale to nie znaczy, że wszystkie elementy syntaktyczne z wszystkich języków są tak marnotrawne, jak programy pobierające i ustawiające z Javy i C ++.

Argumentem przemawiającym za kodem typu „kocioł” jest to, że zmiana go w jednym miejscu wpływa tylko na jeden przepływ kodu. Należy to zrównoważyć z faktem, że najczęściej chcesz, aby zmiana wpływała na każdy fragment kodu, który z niej korzysta. Ale widziałem rzadkie przykłady, które potwierdzają ten argument.

Powiedzmy, że masz fragment kodu, który mówi

public ForTheBar(Foo foo)
{
    Bar bar = foo.bar();
    return bar.BeFooed();
}

Jest to używane w około 2 miejscach w kodzie.

Pewnego dnia ktoś przychodzi i mówi: „Ok, tylko na tej ścieżce, chcemy, abyś wspiął się na pasek przed zrobieniem go”.

I myślisz „cóż, to jest proste”.

public ForTheBar(Foo foo, bool shouldIGrommit)
{
    Bar bar = foo.bar();

    if (shouldIGrommit)
    {
        bar.BeGrommitted();
    }

    return bar.BeFooed();
}

Następnie użytkownik dodaje nową funkcjonalność i uważasz, że dobrze pasuje do FooTheBar. I sumiennie pytasz ich, czy powinieneś przelecieć ten pasek przed nim, a oni powiedzą „nie, nie tym razem”.

Więc po prostu wywołujesz powyższą metodę.

Ale wtedy twój użytkownik mówi „ok, czekaj, w trzecim przypadku chcemy, abyś Doodle Bar, zanim zadzwonisz do BeFooed”.

Nie ma problemu, myślisz, że mogę to zrobić.

public ForTheBar(Foo foo, bool shouldIGrommit, bool shouldIDoodle)
{
    Bar bar = foo.bar();

    if (shouldIGrommit)
    {
        bar.BeGrommitted();
    }

    if (shouldIDoodle)
    {
        bar.BeDoodled();
    }

    return bar.BeFooed();
}

Nagle twój kod staje się coraz mniej wymagający. Być może powinieneś był zaakceptować powtórzone dwa wiersze kodu. Do tej pory będziesz miał trzy fragmenty kodu, każdy o długości 2-3 wierszy i nie wyglądający na powtarzający się.

To powiedziawszy, przeciwdziałbym temu stwierdzeniem „nie jest to częsty przypadek, a kiedy to się dzieje, można zrefaktoryzować”.

Innym argumentem, który ostatnio usłyszałem, jest to, że kod płytki wzorcowej może czasem pomóc w nawigacji kodu. Przykład, o którym rozmawialiśmy, polegał na tym, że usunęliśmy mnóstwo kodu mapowania płyty kotła i zastąpiliśmy go AutoMapper. Teraz argumentowano, ponieważ wszystko opiera się na konwencjach, nie można powiedzieć IDE „gdzie jest ta właściwość ustawiona” i oczekiwać, że się dowie.

Widziałem ludzi, którzy twierdzą podobne rzeczy na temat kontenerów IoC.

Nie mówię, że się z nimi zgadzam, ale mimo to jest to uczciwy argument.

Ewolucja wydajności

Zaczynasz od tego:

<p>
    <label for="field">My field</label>
    <input type="text" id="field">
</p>

pozbywacie się wszystkich tych irytujących bojlerów i włączacie funkcję:

1. createFieldHtml( id, label )

   to dobrze, oszczędzam sobie tyle linii!

2. createFieldHtml( id, label, defaultValue )

   tak, potrzebuję też wartości domyślnej, którą łatwo było dodać.

3. createFieldHtml( id, label, defaultValue, type )

   fajnie, mogę teraz używać go również do pól wyboru

4. createFieldHtml( id, label, defaultValue, type, labelFirst )

   Projektant UX powiedział, że etykieta musi znajdować się po polu wyboru.

5. createFieldHtml( id, label, defaultValue, type, labelFirst, isDate )

   w razie potrzeby wyświetla teraz selektor dat. Hm ... Params trochę wymyka się spod kontroli

6. createFieldHtml( id, label, defaultValue, type, labelFirst, isDate, containerCssClasses )

   był jeden przypadek, w którym muszę dodać klasy CSS

7. createFieldHtml( id, label, defaultValue, type, labelFirst, isDate, containerCssClasses, fieldCssClasses, disabled, clearAfter, helpText, uploadPath )

   aaaaaaaaaaaaaaaaaaaaa

W obronie płyty kotłowej

Trudno mi to wyrazić słowami, ponieważ tak naprawdę zauważyłem to niedawno, więc sporządzę listę:

1. Wydaje mi się, że istnieje pewien strach przed powieleniem nieco rozciągniętych linii. Jeśli to tylko kilka wierszy, może to nie stanowić żadnego problemu. niektóre rzeczy są z natury „prawie powtarzalne” (jak w powyższym przykładzie). Na dłuższą metę nie widzę szans na optymalizację.
2. Ludzie lubią gdzieś enkapsulować funkcjonalność; jeśli spojrzysz obiektywnie i wydaje się, że to po prostu „ukrywanie bałaganu” - bądź podejrzliwy! może to być czas na dobrą, starą płytę kotłową
3. Kiedy masz funkcję, która staje się coraz potężniejsza; który wymaga wielu różnych ścieżek wykonania w zależności od danych wejściowych i ostatecznie robi bardzo mało - może to być czas na płycie!
4. Kiedy dodasz warstwę abstrakcji na wierzchu innej warstwy abstrakcji, ale tylko po to, aby twój kod był krótszy (warstwa podstawowa nie powinna być zmieniana) - czas na płytkę!
5. Jeśli masz funkcję, która bierze tak wiele parametrów, że naprawdę musisz nazwać parametry - być może jest to czas płyty kotłowej.

Jedną z rzeczy, o których ostatnio zawsze zadaję sobie pytanie, jest to:
czy mogę skopiować i wkleić do innego projektu bez zmiany czegokolwiek? jeśli tak, można enkapsulować lub umieścić w bibliotece, jeśli nie: to czas bojlera.

Jest to bardzo sprzeczne z ogólną percepcją, że szablonem jest kod kopiuj i wklej. Dla mnie płyta główna polega na kopiowaniu i wklejaniu, ale zawsze muszę ją trochę poprawiać.

Aktualizacja : właśnie natknąłem się na artykuł podający mój przykład powyżej rzeczywistej nazwy: „zbyt SUCHY anty-wzór”.

Funkcja otrzymuje więcej parametrów i ma coraz bardziej złożoną wewnętrzną logikę do kontrolowania jej zachowania w różnych przypadkach. Zbyt suche funkcje są łatwe do wykrycia. Mają wiele skomplikowanych logik typu „jeśli-to”, które próbują sprostać szerokiej gamie zastosowań. [...] Powtarzanie kodu nie zawsze jest złą rzeczą, jeśli kod jest mały i wykonuje funkcję dyskretną.

To krótka i interesująca lektura, artykuł można znaleźć tutaj: Too Dry Anti-Pattern

I gardzić kod szablonowe, ale jest w stanie usunąć kod szablonowe nie zawsze oznacza, że jest to najlepszy sposób, aby przejść.

Struktura WPF ma właściwości zależności , które wiążą się z niesamowitą ilością kodu typu „kocioł”. W wolnym czasie szukałem rozwiązania, które znacznie zmniejsza ilość kodu, który należy napisać. Ponad rok później wciąż ulepszam to rozwiązanie i nadal muszę rozszerzyć jego funkcjonalność lub naprawić błędy.

Jaki jest problem? Jest to świetne narzędzie do nauki nowych rzeczy i odkrywania alternatywnych rozwiązań, ale prawdopodobnie nie jest to najlepsza decyzja komercyjna .

Struktura WPF jest dobrze udokumentowana. To właściwie dokumentuje, jak napisać kod szablonowe. Próba usunięcia tego kodu jest fajnym ćwiczeniem i jest czymś, co zdecydowanie warto zbadać, ale osiągnięcie tego samego poziomu „polerowania”, jaki oferuje msdn, zajmuje dużo czasu, czego nie zawsze mamy.

Problem z płytą grzewczą polega na tym, że narusza ona OSUSZANIE. Zasadniczo, pisząc szablon, powtarzasz ten sam kod (lub bardzo podobny kod) dla wielu klas. Kiedy ten kod wymaga zmiany, wcale nie jest pewne, że programista zapamięta wszystkie miejsca, w których kod został powtórzony. Prowadzi to do błędów, w których używane są stare interfejsy API lub stare metody.

Jeśli przebudujesz płytę główną na wspólną bibliotekę lub klasę nadrzędną, musisz zmienić kod tylko w jednym miejscu, gdy zmieni się interfejs API. Co ważniejsze, gdy nastąpią nieoczekiwane zmiany, kod pęka w jednym miejscu i pozwala dokładnie wiedzieć, co trzeba naprawić, aby wszystko znów działało. Jest to zdecydowanie lepsze niż scenariusz, w którym jedna zmiana powoduje awarie w dziesiątkach, a nawet setkach klas.

Zamierzam zastosować inny takt. Spójność w rozwoju jest jedną z najważniejszych cech projektowania oprogramowania, jest kluczowym narzędziem umożliwiającym rozszerzanie aplikacji i utrzymanie ich, ale może być trudna do osiągnięcia przy zarządzaniu zespołem w wielu witrynach, językach i strefach czasowych.

Jeśli zostanie osiągnięta, spójność sprawi, że kod będzie znacznie bardziej dostępny „kiedy już go zobaczysz, zobaczysz je wszystkie”, znacznie tańszy w utrzymaniu i refaktoryzacji, ale przede wszystkim znacznie łatwiejszy do rozszerzenia. Kiedy piszesz bibliotekę, która wymaga trochę podstaw, wraz z mocą swojej biblioteki dałeś także programistom:

• Punktem początkowym jest zrozumienie preambuły (płyty kotłowej) Twojej funkcjonalności, większość kluczowych klas i punktów dostępu zwykle będzie stanowić część płyty kotłowej. Daje to programistom punkt wyjścia do dokumentacji
• Oczekiwania na umieszczenie na programistach staną się oczywiste, na przykład jeśli skonfigurujesz obiekt śledzenia w ramach preambuły, programiści będą wiedzieć, gdzie rejestrować wyjątki i informacje
• Implikowane zrozumienie, gdy zmuszasz programistę do przejścia przez proces tworzenia instancji klas, może wywnioskować techniki, których będą potrzebować, aby uzyskać dostęp do reszty biblioteki i mieć możliwość wprowadzenia ich do wszelkich konwencji używanych w całej bibliotece
• Łatwa weryfikacja, gdy potrzebny jest Twój kod, może zazwyczaj bardzo łatwo zweryfikować się z wyjątkami i klauzulami ochronnymi, zapobiegając utknięciu konsumentów w dalszej linii, gdy już popełnisz wadliwy proces
• Konfiguracja biblioteki, która wymaga kodu typu „płyta podstawowa”, jest łatwa, ponieważ istnieje już oczywisty punkt implementacji umożliwiający dostosowanie funkcji do pojedynczej ścieżki wykonania. Jest to szczególnie przydatne, jeśli wymagany kod płyty rozszerzeń jest wzbogacony o wzorzec fabryczny lub poleceń

Gdy konsumenci Twojej biblioteki opanują tworzenie instancji, mogą łatwo tworzyć metody prywatne / rozszerzenia, klasy nadrzędne, a nawet szablony w celu zaimplementowania kodu szablonu.

Jedynym prawdziwym problemem z kodem typu „kociołek” jest to, że gdy znajdziesz w nim błąd, musisz naprawić wszędzie, gdzie go używałeś, a nie w jednym miejscu, którego używałeś ponownie .