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).
Odpowiedzi:
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 ++.
źródło
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
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”.
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ć.
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.
źródło
Ewolucja wydajności
Zaczynasz od tego:
pozbywacie się wszystkich tych irytujących bojlerów i włączacie funkcję:
createFieldHtml( id, label )
to dobrze, oszczędzam sobie tyle linii!
createFieldHtml( id, label, defaultValue )
tak, potrzebuję też wartości domyślnej, którą łatwo było dodać.
createFieldHtml( id, label, defaultValue, type )
fajnie, mogę teraz używać go również do pól wyboru
createFieldHtml( id, label, defaultValue, type, labelFirst )
Projektant UX powiedział, że etykieta musi znajdować się po polu wyboru.
createFieldHtml( id, label, defaultValue, type, labelFirst, isDate )
w razie potrzeby wyświetla teraz selektor dat. Hm ... Params trochę wymyka się spod kontroli
createFieldHtml( id, label, defaultValue, type, labelFirst, isDate, containerCssClasses )
był jeden przypadek, w którym muszę dodać klasy CSS
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ę:
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”.
To krótka i interesująca lektura, artykuł można znaleźć tutaj: Too Dry Anti-Pattern
źródło
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.
źródło
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.
źródło
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:
Gdy konsumenci Twojej biblioteki opanują tworzenie instancji, mogą łatwo tworzyć metody prywatne / rozszerzenia, klasy nadrzędne, a nawet szablony w celu zaimplementowania kodu szablonu.
źródło
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 .
źródło