Najbardziej godna pożałowania decyzja dotycząca projektowania lub programowania? [Zamknięte]

Chciałbym usłyszeć, jakie decyzje projektowe podjąłeś i jak się odegrały. Z powodu złej decyzji projektowej ostatecznie musiałem poprzeć tę złą decyzję na zawsze (ja też miałem w tym swój udział). Uświadomiłem sobie, że jeden błąd projektowy może prześladować cię na zawsze. Chcę dowiedzieć się od bardziej doświadczonych ludzi, jakiego rodzaju wpadek doświadczyli i czego się od nich nauczyli.

Jestem pewien, że będzie to bardzo pomocne dla innych programistów, pomagając im nie powtarzać tych decyzji.

Dziękujemy za podzielenie się swoimi doświadczeniami.

Ignorując YAGNI raz za razem ...

„Zrobię to później”
„Później” nigdy nie nadejdzie.

C ++, wielokrotne wirtualne dziedziczenie w kształcie rombu . Masz pomysł.

Konfigurowalność w aplikacji jest dobra. Zbyt duża konfigurowalność to koszmar w użyciu i utrzymaniu.

Z jednego z moich błędów nauczyłem się, że normalizacji DB nie należy ślepo przestrzegać. Możesz, aw niektórych sytuacjach MUSISZ spłaszczyć swoje stoły.

Skończyło się na zarządzaniu mnóstwem tabel (za pomocą modeli), a wydajność nie była tak dobra, jak mogłaby być z niewielkim spłaszczeniem tabel.

Używanie pojedynczego znaku w bazach danych dla statusów itp. Nie ma w tym sensu, narzut związany z używaniem dłuższego znaku () lub nvarchar2 () jest niewielki w porównaniu z siecią i analizą wywołaną przez każde wywołanie SQL, ale znaki zawsze się kończą raczej zaciemnione lub wyczerpujące (nie dla statusów, ale dla innych rzeczy). O wiele lepiej jest po prostu umieścić wersję czytelną dla człowieka i mieć w swoim modelu Java (w moim przypadku) wyliczenie z pasującymi wartościami.

Myślę, że jest to forma przedwczesnej niepotrzebnej i ślepej optymalizacji. Tak, jakby użycie jednego znaku uratowało świat w tych dniach. Oprócz boolanów Y / N w bazach danych, które nie obsługują boolanów / bitów.

Nie rozwijam odpowiedniej Warstwy Dostępu do Danych i mam sql wszędzie w moim kodzie, tylko po to, żeby dostać coś „szybkiego” i działającego. Później, gdy projekt zaczął się rozwijać, a wymagania ulegały zmianie, stał się koszmarem. Nie wiedziałem wtedy, czym jest DAL.

... cieszę się, że to już przeszłość, chociaż wciąż widzę, że robią to programiści z ponad 20-letnim doświadczeniem.

Myśląc, że mogę być Architektem, Deweloperem i PM w tym samym projekcie.

2 miesiące snu 3 godziny dziennie nauczyły mnie, że po prostu nie możesz tego zrobić.

Wybór Microsoft Foundation Classes (MFC) do pisania środowiska Java IDE.

To nie była moja decyzja (dołączyłem do firmy nieco później), ale gdzieś, gdzie pracowałem, zajęło mi to trochę za daleko, włączając w to tłumaczenie wszystkich komunikatów z dziennika.

Wyniki:

• Bardziej bolesne jest dodawanie nowego rejestrowania
• Więcej kosztów tłumaczenia
• Dzienniki są później trudniejsze do odczytania

Ups

Reinventing the Wheel

Robię za dużo projektowania . Tworzenie wielu diagramów UML, szczególnie diagramów sekwencji dla każdej pojedynczej operacji, z których wiele ostatecznie okazało się bezużyteczne. Na koniec okazało się, że można by zaoszczędzić znaczną ilość czasu, pomijając niepotrzebnie szczegółowy projekt / diagramy i bezpośrednio rozpoczynając kodowanie.

Wiara w klientów wie, czego chcą, a następnie zbyt wiele, zanim się z nimi skontaktuje.

Moja najgorsza decyzja projektowa? W latach 80. pracowałem nad projektem, w którym wpadliśmy na pomysł stworzenia pewnego rodzaju szablonu dla naszych ekranów wprowadzania danych, który byłby interpretowany w czasie wykonywania. Niezła decyzja: ułatwiło projektowanie ekranów wejściowych. Zasadniczo po prostu stwórz plik, który przypominałby ekran wprowadzania danych, z kilkoma specjalnymi kodami, aby zidentyfikować, co było etykietą w porównaniu z tym, co było polem wejściowym, i aby ustalić, czy pola wejściowe były alfanumeryczne czy numeryczne. Następnie postanowiłem dodać do tych plików kilka specjalnych kodów, aby określić, jakie weryfikacje należy wykonać. Następnie dodałem więcej kodów, aby umożliwić warunkowe budowanie ekranu, pole X było uwzględniane tylko wtedy, gdy jakiś warunek był spełniony itp. Następnie dodałem więcej kodów, aby wykonać proste przetwarzanie danych wejściowych. Itd itd. Ostatecznie zmieniliśmy szablon ekranu w nowy język programowania, zawierający wyrażenia, struktury kontrolne i bibliotekę we / wy. A po co? Zrobiliśmy mnóstwo pracy, aby ponownie wynaleźć FORTRAN. Mieliśmy półkę pełną kompilatorów dla języków, które były lepiej zaprojektowane i lepiej przetestowane. Jeśli poświęcilibyśmy tyle wysiłku na tworzenie produktów, w których rzeczywiście dysponowaliśmy wiedzą specjalistyczną, firma ta mogłaby nadal działać.

Nadgorliwe stosowanie YAGNI (zwanego Projektowaniem przez wyliczenie w pułapkach rozwoju obiektowego ) w środowisku, w którym każda rozsądna osoba może stwierdzić, że wymagania na pewno się zmienią. I zmieniaj się wielokrotnie.

Jeśli (twardo) zakodowałeś wszystko dokładnie do aktualnych wymagań - jednocześnie pokonując każdego, kto mówi „czy to nie może być bardziej ogólne?” z młotkiem YAGNI - a następnie wymagania zmieniają się drastycznie (ale w sposób, który można było rozsądnie przewidzieć), wtedy może to być różnica między poświęceniem 2 tygodni na dostosowanie, a zajęciem 20 minut.

AKTUALIZACJA: Aby wyjaśnić, oto fikcyjny przykład, który nie jest zbyt daleko od tego, co się stało. Przepełnienie stosu zostało zaprojektowane tak, aby obsługiwać odznaki, ale załóżmy, że na początku mogły myśleć tylko o czterech odznakach. Tylko cztery, tak mała liczba, więc zakodowali na stałe wsparcie dokładnie czterech odznak w całej logice na stronie. W bazie danych, w informacjach o użytkowniku, we wszystkich kodach wyświetlanych. Ponieważ „Nie będziesz potrzebować” żadnych odznak, o których nie możesz pomyśleć, prawda? Załóżmy, że witryna jest aktywna, a ludzie zaczynają sugerować nowe plakietki. Każda odznakadodanie zajmuje nawet dwa tygodnie, ponieważ w całym tym miejscu jest tak wiele poprawek. Ale nadal: „Nie będziesz potrzebował” więcej odznak niż dzisiejsza lista, więc nigdy nie będzie żadnego refaktoryzacji w celu obsługi ogólnej kolekcji odznak. Czy taka ogólna kolekcja zajęłaby więcej czasu z góry? Niewiele, jeśli w ogóle.

YAGNI jest cenną zasadą, ale nie należy jej (ab) usprawiedliwiać złego projektu i niewłaściwego kodowania. Jest równowaga i z doświadczeniem, myślę, że do niej podchodzę.

Niekompetentne zasoby ludzkie

Próbuję zrobić coś dobrego i dobrego z niewłaściwymi ludźmi!
Nawet jeśli pełnią one rolę zbędnego premiera ego (co jest dość powszechne, szczególnie w dużych firmach, w których ich niekompetencja może trwać dłużej).

Za każdym razem, gdy tworzę dług techniczny, piszę kod proceduralny, pomijam pisanie testów itp., Ponieważ śpieszę się. Prawie nieuchronnie uważam, że powoduje to ból na drodze.

Korzystanie z usług SQL Server Intergration Services (SSIS).

Nie życzę tego mojemu najgorszemu wrogowi.

Po zbudowaniu kilku pakietów SSIS w ciągu ostatnich dwóch miesięcy, okazało się, że pakiety, które opracowałem, nie są dystrybuowalne i nieodwracalne. W szczególności w środowisku innym niż www, nie licencjonowanym SQL Server.

Jest to bardzo zła sytuacja, gdy masz mniej niż 48 godzin, aby ponownie napisać swoje pakiety SSIS w czystym kodzie .NET POCO lub nie dotrzymać wyznaczonego terminu.

Dziwi mnie, że udało mi się przepisać trzy pakiety SSIS (testowanie i rozwój zajęło mi dwa miesiące) w ciągu 12 godzin w czystym kodzie .NET za pomocą adapterów OLEDB i adapterów SQL.

SSIS nie jest rozpowszechniany i nie będzie wykonywać pakietów z komputera klienta, jeśli nie ma na nim zainstalowanej licencji SQL Server (w szczególności DTSPipeline.dll). Byłoby wspaniale wiedzieć z góry. Widzę teraz wyłączenie odpowiedzialności (drobnym drukiem) w witrynie MSDN. Nie ma to nic dobrego, jeśli masz przykładowy kod w całym Internecie, używając tylko kodu maszynowego SQL-LICENSED. Zasadniczo musisz utworzyć usługę internetową, która będzie komunikować się z serwerem SQL, aby programowo uruchamiać pakiety SSIS. Nie można ich wykonać z czystego kodu .NET, chyba że na komputerze wykonującym zainstalowana jest licencja SQL. Jak to jest nierealne? Czy Microsoft naprawdę oczekuje, że SSIS będzie używany na komputerach, które wymagają instalacji serwera SQL? Co za kompletna strata dwóch miesięcy.

Moja firma nigdy więcej nie użyje SSIS z powodu tego małego wydruku „gotcha”.

Nie zdefiniowanie mechanizmu / modelu wdrażania tak wcześnie, jak to możliwe.

Wrzucam trochę „śmiesznych” pisanek do jakiegoś kodu, który napisałem przed wyjazdem na wakacje na 2 tygodnie. Myślałem, że będę jedyną osobą, która przeczytałaby go, gdy wrócę, zachichotałbym i byłbym gotowy go ponownie zakodować.

Nie trzeba dodawać, że mój szef nie był pod wrażeniem, gdy przejrzał go podczas mojej nieobecności, a jeszcze bardziej był pod wrażeniem, gdy jedno z „wielkanocnych jaj” obejmowało jego zabawnie rysowaną twarz w ASCII.

Mmmmmm ...

Używanie motywów ASP.Net, gdy zwykły stary folder CSS byłby w porządku.

Szybka droga do uruchomienia kodu, a nie właściwa droga (nieco ogólna, ale nazwiemy to abstrakcją, a zatem „właściwą” odpowiedzią).

Moja firma ma model rozwoju podobny do wodospadu, w którym nasi użytkownicy biznesowi i analitycy biznesowi określą wymagania dotyczące projektów. W przypadku jednego z naszych „dużych” projektów otrzymaliśmy stos wymagań i zauważyłem, że wiele wymagań zawierało szczegóły implementacji , w szczególności informacje związane ze schematem naszej bazy danych używanym przez nasz system księgowy.

Skomentowałem użytkownikom biznesowym, że implementacja jest moją domeną, nie powinna być zawarta w wymaganiach. Nie chcieli zmieniać swoich wymagań, ponieważ w końcu są BIZNESEM, a księgowi mają sens jedynie projektować oprogramowanie księgowe. Jako mało zaawansowany programista, który jest zbyt daleko w ankiecie totemowej, płacę za to zamiast myśleć . O ile walczyłem, nie udało mi się przekonać ich do ponownego napisania wymagań - jest zbyt wiele papierkowej roboty i biurokracji wokół zmian, co jest zbyt wielkim problemem.

Dałem im więc to, o co prosili. Przynajmniej trochę działa , ale baza danych jest dziwnie zaprojektowana:

• Dużo niepotrzebnej normalizacji. Pojedynczy rekord zawierający 5 lub 10 pól jest podzielony na 3 lub 4 tabele. Mogę sobie z tym poradzić, ale osobiście chciałbym, aby wszystkie pola 1: 1 zostały zebrane w jednym stole.

• Dużo niewłaściwej denormalizacji. Mamy tabelę, która przechowuje dane faktury, która przechowuje więcej niż dane faktury. W tabeli InvoiceData przechowujemy wiele różnych flag, nawet jeśli flaga nie jest logicznie powiązana z tabelą InvoiceData, tak że każda flaga ma magiczną, zakodowaną wartość Klucza podstawowego, a wszystkie inne pola wyzerowane w tabeli InvoiceData. Ponieważ flaga jest reprezentowana jako rekord w tabeli, zasugerowałem wciągnięcie flagi do własnej tabeli.

• O wiele bardziej niewłaściwa denormalizacja. Niektóre flagi dla całej aplikacji są przechowywane jako kolumny w nieodpowiednich tabelach, tak że zmiana flagi aplikacji wymaga aktualizacji każdego rekordu w tabeli.

• Klucze podstawowe zawierają metadane, tak że jeśli klucz podstawowy varchar kończy się na „D”, faktury obliczamy na podstawie jednego zestawu wartości, w przeciwnym razie obliczamy go na innym zestawie. Bardziej sensowne byłoby przeciągnięcie tych metadanych do osobnej kolumny lub pobranie zestawu wartości do obliczenia do innej tabeli.

• Klucze obce często trafiają do więcej niż jednej tabeli, tak że klucz obcy kończący się na „M” może łączyć się z naszą tabelą kont hipotecznych, podczas gdy klucz obcy kończący się na „A” może łączyć się z naszą tabelą automatycznych kont. Łatwiej byłoby podzielić dane na dwie tabele, MortageData i AutoInsuranceData.

Wszystkie moje sugestie zostały zestrzelone z wieloma lamentami i zgrzytaniem zębami. Aplikacja działa zgodnie z projektem i choć jest to wielka kula błota, wszystkie nieprzyjemne hacki, specjalne przypadki i dziwne reguły biznesowe są sarkastycznie i humorystycznie udokumentowane w kodzie źródłowym.

Trzymanie się starszej technologii, ponieważ wydaje się, że zbyt duży problem sprawia, że ​​Twoi klienci mogą aktualizować się do nowej wersji .NET Framework, ale w rzeczywistości tworzenie oprogramowania zajmie więcej czasu, ponieważ nie możesz użyć niektórych (oszczędzających czas) komponentów nowsza wersja frameworka.

Po powrocie na uniwersytet pracowałem nad moim starszym projektem. Razem z innym facetem pisaliśmy internetowy system śledzenia błędów. (Nic przełomowego, ale oboje chcieliśmy uzyskać trochę doświadczenia w Internecie.) Zrobiliśmy to z serwletami Java i działało to całkiem dobrze, ale z jakiegoś głupiego powodu, zamiast zdecydować się na użycie wyjątków jako naszego mechanizmu obsługi błędów, wybraliśmy używać kodów błędów.

Kiedy przedstawiliśmy nasz projekt do oceny, a jeden z wykładowców zapytał nieuniknione: „Gdybyś musiał to zrobić ponownie, co zrobiłbyś inaczej?” Natychmiast znałem odpowiedź: „Użyłbym wyjątków, po to są.”

Nie mój wybór metody, ale utworzyłem XSLT do konwersji pliku XML opartego na wierszach na raport HTML oparty na kolumnie.

Działa tylko w IE, było całkowicie niemożliwe do odkodowania, jak to działało. Za każdym razem, gdy potrzebowaliśmy go rozbudowywać, było to niemożliwie trudne i trwało wieki.

Na koniec zastąpiłem małym skryptem C #, który zrobił to samo.

próbując wykorzystać wszystkie nowe technologie (aby nauczyć się nowych technologii), nawet jeśli nie wymagają nawet ..

Nie poświęciłem wystarczająco dużo czasu na ocenę modelu biznesowego. Zrobiłem to, o co prosił klient, ale 6-12 miesięcy później doszliśmy do wniosku, że powinno być inaczej.

Projektowanie bez specyfikacji.

Zaimplementowałem podsekcję aplikacji zgodnie z wymaganiami.

Okazuje się, że wymagania były rozdęte i pozłacane, a mój kod został przeprojektowany. Powinienem był zaprojektować moją podsekcję, aby działała tylko z tym, co dodawałem w tym czasie, ale planuję dodać wszystkie inne rzeczy bez uwzględnienia ogólnej obsługi tego od samego początku.