2009-03-15 10 views
5

Nie jestem do końca pewien, jak to sformułować, ale spróbuję.Twarde kodowanie a ogólne kodowanie: gdzie narysować linię?

Załóżmy, że masz pewne ustawienia w niektórych elementach programu, w których 80% na pewno nie będziesz musiał modyfikować ponownie. Skąd wiesz, gdzie narysować linię na zmiennym kodzie? Wiesz, że przeniesienie ustawień do pliku XML zdefiniowanego przez użytkownika jest przesadą. Jednak wiesz również, że istnieje niewielkie 20% prawdopodobieństwo, że ustawienia te mogą wymagać późniejszej zmiany, więc kodowanie ich w miejscu, w którym guma spotyka się z drogą, nie jest optymalne.

Domyślam się, że staram się zapytać, w jakim stopniu drzewo abstrakcji powinno pozwolić na łatwą zmianę programu?

Jednym z wielu przykładów jest ręczne napisanie kodu HTML strony internetowej, a program automatycznie ją wygeneruje. Bezpośrednie pisanie kodu HTML nie zajmuje zbyt wiele czasu. Napisanie programu do automatycznego generowania kodu HTML trwa znacznie dłużej.

Odpowiedz

5

To jest dobre pytanie, ale nie ma absolutnej odpowiedź na to:

Jak zauważył Einsteina:

zrobić rzeczy jak najprostsze, ale nie prostsze.

Prostota jest względna. Podjęcie najlepszej decyzji co do ilości warstw abstrakcji w projekcie jest tym, co czyni świetnego architekta świetnym. Dobry architekt powinien zawsze ocenić konkretną sytuację i dokonać najlepszego kompromisu. Nie ma żadnych srebrnych kul.

0

80%? Nie jest wystarczająco dobra, aby zakodować kod, umieść go w pliku konfiguracyjnym.

100%? Może to zrobić stała.

1

dwa punkty:

  • Wszystkie stałe powinny mieć charakter ogólny, czyli nie zawsze ciężko kod magiczne numery bez narażania go na opisowej stała.
  • Wdrożyć minimum, którego faktycznie potrzebujesz - zakodować go na sztywno, aż do momentu, gdy będziesz chciał powtórzyć kod zakodowany więcej niż jeden raz - w takim przypadku powinieneś zacząć generować kod. (Test Driven Development jest niesamowity).
1

Twoje pytanie było ukierunkowane na rzeczywisty projekt kodu niż na to, czy umieścić zmienne w pliku konfiguracyjnym czy w stałych. Zgadzam się z innymi odpowiedziami dotyczącymi tych aspektów.

Ale o tym, czy napisać kod uogólniony ...

Z mojego doświadczenia, jeśli piszesz kod specjalnie do czynienia z zadaniem pod ręką, można tylko znaleźć się pisząc podobny kod w pewnym momencie w przyszłości. Ok, jeśli naprawdę wykonasz zadanie tylko raz, to jest w porządku. Ale okazuje się, że w większości przypadków tak nie jest.

Jeśli powtarzasz zadanie na wszystkich, powinieneś zrobić krok do tyłu i zastanowić się, co trzeba zrobić, aby zautomatyzować to w sposób ogólny.

Sprawdź również, czy ktoś jeszcze tego nie zrobił.Jeśli nie, należy rozważyć opublikowanie swojego kodu, bez względu na to, jak mały może być. Ktoś może poprawić to za Ciebie, za darmo.

2

W ciągu ostatnich czterech lat ten stary pies nauczył się nowej sztuczki TDD. Nawet gdy nie mam czasu na "prawdziwego" TDD, udaje, że to robię.

Tak więc zawsze Napisz zduplikowany kod. Co jest ok, ponieważ I zawsze refactor to później. Jest to część procesu pisania kodu, a nie coś, do czego można później przejść. Ponieważ podążałem za TDD i napisałem tylko minimalny niezbędny kod, a ponieważ mam zautomatyzowane testy potwierdzające, że kod działa, jeśli znajdę duplikację, mogę je odłożyć komfortowo, wiedząc, że znów uruchomię moje testy podczas i po refaktoryzacji. To po raz kolejny udowodni, że niczego nie złamałem.

W ten sposób nie spekuluję na temat, czy kod zostanie ponownie użyty - nigdy nie refactor, dopóki nie zostanie ponownie użyty . Ponieważ jest tworzony w każdym przypadku zgodnie z potrzebami instancji, wiem, że wywołujący kod nie został wypaczony przez chęć uczynienia kodu generycznym. Osoby dzwoniące, w tym testy jednostkowe, zostały napisane, aby spełnić ich najbliższe potrzeby. Oddzielna przepustka refaktoryzacyjna obsługuje szerszą potrzebę nie duplikowania kodu.

+0

Jeśli piszesz zduplikowany kod, ale nie zaznaczasz go do czasu ponownego przetworzenia, czy zduplikowałeś kod? (Filozoficzne) – Arafangion

3

dam ten strzał, moja filozofia jest następująca:

1 - Zachowaj plik konfiguracyjny & klasy parser/funkcji, które są niezwykle dumbed dół i proste, jak to możliwe, aby dać Ci spokój, że gdy tylko potrzebujesz czegoś z niego, możesz to zrobić bez konieczności tworzenia przypadkowo przetartego parsera plików konfiguracyjnych XML. Mój plik config wygląda następująco:

DBHostname -> XX.XX.XXX.XX 
DBUsername -> foomonger 
DBName -> fooDb 
DBPassword -> xxxxx 
ImageUploadsDir -> /uploads/images/ 
... 

wyodrębnić co muszę z niego przy użyciu statycznej metody pomocnika (małe aplikacje) lub singleton instancji (duże MVC napędzane apps) wygenerowany przez mojego idioty znajomego ConfigHelper, który jest tak głupi, on nie wie, jak generować nad głową.

Mam ten dylemat kilka razy w moim średnim dniu pracy: powinienem umieścić to w config.txt lub powinienem zrobić to stała klasy? Moja odpowiedź brzmi: po prostu nie wiem - aż do dużo później. Jeśli okaże się, że trzeba go umieścić w pliku konfiguracyjnym, nic nie przebije przyzwoitego IDE ze stabilną implementacją "Znajdź w projekcie &" w celu zmiany odniesień.

3 - Pliki konfiguracyjne są koszmarne po wdrożeniu aplikacji, gdy programowanie obejmuje serwer testowy, a następnie wdrożenie do produkcji - nie ma praktycznej alternatywy. Różne instancje baz danych na różnych komputerach mają różne adresy IP w świecie, który rozumiem.

Jednym z wielu przykładów jest pisanie kodu HTML strony internetowej ręcznie vs posiadające program automatycznie generuje to

To jest tak prawdziwe. Podczas gdy my, jako programiści, lubimy budować maszyny, mamy tendencję do marnowania czasu na budowanie maszyn do budowy maszyny, którą początkowo zamierzaliśmy zbudować. Chociaż może to być bardzo satysfakcjonujące, z doświadczenia mogę zaryzykować stwierdzenie, że w sytuacji o największej liczbie komputerów, im więcej systemów będzie trzeba obsługiwać, tym więcej punktów awarii, tym więcej dudnień dostanie od właścicieli firm. - i to nie jest zabawne. Ponadto będziesz miał tendencję do uruchamiania sytuacji, w których pośredni generator HTML nie może uzyskać pożądanego wyniku. Więc co robisz, marnujesz czas na naprawianie błędu w generatorze, marnujesz czas na rozwiązanie problemu voodoo lub zwyczajnie piszesz kod HTML?To naprawdę zależy od konkretnych okoliczności, ale ja wolę to drugie.

Trochę się rantem, ale mam nadzieję, że pomogło to odpowiedzieć na twoje pytanie, przynajmniej trochę.

+0

Jedną z wielu zalet .NET jest spójne i czyste podejście do konfiguracji. Jeden definiuje silnie typowane klasy konfiguracji o silnie typowanych właściwościach. Są one mapowane bezpośrednio do pliku konfiguracyjnego XML, więc nie ma potrzeby analizowania i sprawdzanie poprawności jest nieodłączne. –

+0

Twój ostatni akapit jest tak bardzo, boleśnie prawdziwy. Z zawodu nie jestem programistą, raczej hobby. Jednak napisałem BARDZO dynamiczną stronę/aplikację HTML do mojego miejsca pracy, która buduje ogromne ilości treści DOM na podstawie wyborów użytkowników w czasie rzeczywistym. To ogromny koszmar, który trzeba utrzymywać, pogarszany przez fakt, że ograniczam się do IE6. Cześć debugowanie, kiedy łamam zestaw narzędzi. I ile razy próbowałem zmusić zestaw narzędzi do uzyskania pożądanej wydajności, gdy ktoś wymyślił coś, o czym nie myślałem na początku. Boże pomóż mi. – Kivin