Czy istnieją określone "długi techniczne", które nie są warte ponoszenia?

Question

Istnieją (przynajmniej) dwa sposoby, w jakie długi techniczne trafiają do projektów. Pierwszą jest świadoma decyzja. Niektórych problemów po prostu nie warto podejmować z góry, więc świadomie pozwala się im kumulować jako dług techniczny. Drugi to ignorancja. Ludzie pracujący nad projektem nie wiedzą lub nie zdają sobie sprawy, że zaciągają techniczny dług. To pytanie dotyczy drugiego. Czy masz długi techniczne, które wpuściłeś do swojego projektu, które byłyby błahe, by trzymać się z daleka ("Gdybym tylko wiedział ..."), ale kiedy zostały osadzone w projekcie, stały się znacznie droższe?

Answer 1

Nie uruchamianie projektu WWW za pomocą struktury javascript i ręczne wdrażanie rzeczy, które były już dostępne. Utrzymanie ręcznie napisanego javascripta okazało się wystarczającym bólem, który w końcu wyrzuciłem i przerobiłem go za pomocą frameworka.

Answer 2

Jednym z przykładów jest uruchomienie bazy danych w trybie, który nie obsługuje Unicode. Działa aż do momentu, w którym jesteś zmuszony do obsługi ciągów Unicode w bazie danych. Ścieżka migracji jest nietrywialna, w zależności od bazy danych.

Na przykład SQL Server ma ustaloną maksymalną długość wiersza w bajtach, więc po konwersji kolumn na ciągi znaków Unicode (NCHAR, NVARCHAR itd.) Może brakować miejsca w tabeli na przechowywanie danych już mam. Teraz twój kod migracyjny musi podjąć decyzję o skróceniu lub musisz całkowicie zmienić układ tabeli. Tak czy inaczej, to znacznie więcej pracy niż rozpoczęcie od wszystkich ciągów Unicode.

Answer 3

Brak spójnej konstrukcji z przodu prowadzi do tego. Możesz go pokonać do pewnego stopnia, jeśli poświęcisz czas na częste refaktory, ale większość ludzi nie przestaje walić w ogólny projekt, który nie odpowiada ich zmieniającym się wymaganiom. Może to być bardziej ogólna odpowiedź na pytanie, czego szukasz, ale zazwyczaj jest jedną z bardziej popularnych przyczyn długu technicznego.

Answer 4

W poprzedniej firmie używali i wymuszali COM na rzeczy, do których nie byli potrzebni.

Inna firma z podstawą C++ nie zezwala na STL. (WTF ?!)

Kolejny projekt, na którym byłem, wykorzystał MFC tylko do kolekcji - nie było w tym przypadku żadnego interfejsu użytkownika. To było złe.

Oczywiście konsekwencje tych decyzji były niewielkie. W dwóch przypadkach mieliśmy zależności od żałosnych technologii MS bez powodu, a inni zmuszali ludzi do korzystania z gorszych implementacji generycznych i kolekcji.

Klasyfikuję je jako "dług", ponieważ musieliśmy podejmować decyzje i kompromisy w późniejszym okresie w projektach z powodu idiotycznych decyzji z góry. W większości przypadków musieliśmy obejść te niedociągnięcia.

Answer 5

Chociaż nie wszyscy mogą się zgodzić, myślę, że największy udział w długu technicznym zaczyna się od interfejsu dowolnego typu aplikacji i pracy w stosie. Nauczyłem się, że istnieje mniejsza szansa na odchylenie od celów projektu poprzez wdrożenie kombinacji TDD i DDD, ponieważ nadal można rozwijać i testować podstawowe funkcje, a interfejs staje się lukrem.

To nie jest sam techniczny dług, ale odkryłem, że odgórne opracowywanie to bardziej otwarte drzwi, które zachęcają do decyzji, które nie są dobrze przemyślane - wszystko po to, by coś zrobić. "wygląda fajnie". Rozumiem też, że nie wszyscy się z tym zgadzają lub czują w ten sposób, więc Twój przebieg może się różnić w zależności od tego. Dynamika zespołu i umiejętności są również częścią tego równania.

Answer 6

Całkowite ignorowanie problemów z zabezpieczeniami.

Skrypt cross-site jest jednym z takich przykładów. Uważa się, że jest nieszkodliwy, dopóki nie pojawi się alert('hello there!') pojawienie się w interfejsie administratora (jeśli masz szczęście - skrypt może również cicho skopiować wszystkich administratorów danych mają dostęp lub złośliwego oprogramowania do klientów).

A następnie potrzebujesz 500 szablonów naprawionych wczoraj. Pośpieszne poprawki spowodują podwójne ucieczki danych i nie będą usuwać wszystkich luk w zabezpieczeniach.

Answer 7

naprawdę walczyć z tym jednym, próbując zrównoważyć YAGNI kontra „byłem spalony na ten jeden raz zbyt często”

Moja lista rzeczy przeglądu dotyczącego każdego zastosowania:

1. Localization:
   2. Czy strefa czasowa kiedykolwiek będzie ważna? Jeśli tak, przechowuj datę/czas w UTC.
   3. Czy wiadomości/tekst zostaną zlokalizowane? Jeśli tak, przekazuj wiadomości na zewnątrz.
2. Niezależność od platformy? Wybierz łatwą do przeniesienia implementację.

Inne obszary, w których dług techniczny mogą być poniesione obejmują:

• Black Hole Zbieranie danych: Wszystko idzie w nic nigdy nie gaśnie. (Brak długoterminowego planu archiwizowania/usuwania starych danych)
• Nieprawidłowe rozdzielenie MVC lub warstw przez czas życia aplikacji - na przykład, pozwalając zbyt dużej logice na wkradnięcie się do widoku, dodając interfejs dla urządzeń mobilnych lub usługi internetowe są znacznie droższe.

jestem pewien, że będą inni ...

Answer 8

Zapisywanie daty bazy danych w lokalnej strefy czasowej. W pewnym momencie Twoja aplikacja zostanie przeniesiona do innej strefy czasowej, a będziesz mieć kłopoty. Jeśli kiedykolwiek będziesz mieć mieszane daty, nigdy nie będziesz w stanie ich rozszyfrować. Po prostu przechowuj je w UTC.

Answer 9

Skalowalność - w szczególności aplikacje biznesowe sterowane danymi. Widziałem więcej niż jeden raz, gdy wszystko wydaje się działać dobrze, ale kiedy środowisko UAT wreszcie staje w obliczu rozmiarów tabel bazy danych, które zbliżają się do produkcji, to wszystko zaczyna spadać w prawo iw lewo. Łatwo jest uruchamiać ekran internetowy lub program wsadowy, gdy db w zasadzie trzyma wszystkie wiersze w pamięci.

Answer 10

Testowanie jednostek - Myślę, że nieudane próby pisania przynoszą OGROMNY dług, który trudno nadrobić. Chociaż jestem fanem TDD, nie obchodzi mnie, czy napiszesz testy przed lub po zaimplementowaniu kodu ... tak długo, jak utrzymujesz testy zsynchronizowane z kodem.

Answer 11

stereotyp, że przedwczesna optymalizacja jest źródłem wszelkiego zła, a to na pewno jest prawdziwe dla mikro -optimization. Jednak całkowite ignorowanie wydajności na poziomie projektu w obszarze, w którym wyraźnie będzie miało znaczenie, może być złym pomysłem.