Dawno temu dodaliśmy funkcję, w której nasi użytkownicy mogli „zaakceptować” obraz po dodaniu go do kolejki przepływu pracy. Okazuje się, że użyliśmy niewłaściwego terminu, a użytkownicy faktycznie „Zatwierdzili” obraz.
Zmiana Akceptuj, aby zatwierdzić w naszym interfejsie jest łatwa, wystarczy zastąpić jedno słowo. Ale zaprogramowaliśmy wszystkie warstwy słowem „akceptuj”, od nazwy klasy CSS po wartości bazy danych.
- Klasa CSS, która zmienia kolor przycisku na zielony: „.accepted”;
- Metoda modelowa, która weryfikuje i wiąże atrybut klasy w węźle DOM: „isAccepted”;
- Atrybut statusu JavaScript: Tablica z „nie sprawdzone”, „zaakceptowane” i „opublikowane”;
- Kolumna stanu MySQL: ENUM z „nie sprawdzone”, „zaakceptowane” i „opublikowane”;
- Nazwy testowe;
Zastępowanie większości przypadków akceptacji do zatwierdzenia jest trywialne (szczególnie gdy masz testy). Nieco trudniej jest migrować dane, zwłaszcza, że należy je zsynchronizować z wdrożeniem.
Ten konkretny przypadek jest prosty, ale w trakcie mojej kariery miałem do czynienia z podobnymi, ale bardziej złożonymi sprawami. Kiedy nazwa pliku również ulega zmianie i wdrażanie odbywa się na kilkudziesięciu serwerach, lub gdy w grę wchodzi buforowanie proxy, memcached i mysql.
Pozostawienie „zaakceptowanych” na każdej innej warstwie oprócz interfejsu jest złym pomysłem, ponieważ nowi programiści dołączający do zespołu mogą nie poznać historycznych powodów, dla których doprowadziła do tej decyzji, i chociaż akceptują -> zatwierdzają, są bliskimi słowami pod względem znaczenia, jeśli przemianowano go na „w kolejce na kolejne spotkanie menedżerskie”, to z pewnością nie miałoby sensu. I czuję, że jeśli pójdziemy na kompromis tu i tam, w kilku iteracjach koncepcje interfejsu użytkownika nie będą miały wpływu na elementy wewnętrzne systemu, a ja z pewnością nie chcę pracować w systemie, w którym połowa danych wyjściowych nie ma połączenia z jego wnętrznościami.
Czy zawsze zmieniasz nazwę wszystkiego w razie potrzeby? Jeśli tak się stało i zdecydowałeś, że kompromis nie był wart, to czy wrócił cię ugryźć? Czy komentarz kodu lub dokumentacja programisty wystarczą, aby uniknąć tego problemu?
Odpowiedzi:
Dla mnie zdecydowanie najlepiej jest zmienić wszystko, co dotyczy danego przedmiotu.
Jest to forma degradacji kodu i chociaż niezmieniony 1 element może nie być wielką sprawą, ustawia ton podstawy kodu.
Może to również prowadzić do zamieszania w przyszłości i utrudnić nowym deweloperom zrozumienie bazy kodu / domeny.
źródło
Na podstawie treści pytania i tagów stwierdzę, że używasz wszechobecnego języka.
Z mojego doświadczenia wynika, że UL jest świetny, ale, jak wspomniałeś, może prowadzić do dodatkowych zadań konserwacyjnych w miarę ewolucji języka. To samo w sobie nie jest złe. Jasne, jest niewygodne, ale można się też spodziewać.
To, co zwykle zrobiłem (i widziałem jako zrobione) to:
Myślę, że kluczową rzeczą jest to, że opisujesz dług techniczny i należy go jako taki uznać.
Miałem menedżerów, którzy twierdzili, że nie powinniśmy marnować czasu na tak trywialne zadania, które nie dodają żadnej widocznej funkcjonalności. Wtedy przydaje się analogia długu . Sprowadza się do tego:
Zespół postanowił zrobić DDD z Wszechobecnym językiem. Odejście od tego podejścia poprzez pozostawienie kodu w niespójnym stanie powoduje zamieszanie i usuwa wiele korzyści, które zapewniają DDD i UL. W kategoriach menedżerskich zwiększa koszty projektu. Kod staje się trudniejszy (drogi) w zarządzaniu i bardziej zagmatwany dla nowych programistów (drogi).
źródło
Możesz zajrzeć do opcji Lokalizacja (l10n). Chociaż może to nie wydawać się tak drastyczne, jak przejście z języka angielskiego na hiszpański, masz do czynienia z innym terminem dla tej samej koncepcji. Jeśli wydaje się, że zdarza się to często, to użycie l10n może pozwolić ci szybko zmienić to, co jest wyświetlane w interfejsie użytkownika, bez konieczności zmiany terminu używanego w kodzie.
Mając to na swoim miejscu, po prostu użyj najbardziej zrozumiałych terminów w kodzie. Wybierz nazwy z domeny, ponieważ programiści ją znają i mogą się spodziewać.
źródło
Jak odpowiednio to zobrazujesz, śledzenie zmian w nomenklaturze użytkownika końcowego w każdej części źródła jest sporą inwestycją. Jest to jednak zdecydowanie warte zachodu, szczególnie w przypadku produktu o długim okresie użytkowania opracowanego przez pełną infrastrukturę (z infolinią, testerami itp.)
Śledzenie nomenklatury użytkownika końcowego w źródle to inwestycja, ponieważ istnieje tak wiele typów komponentów, w których się pojawia, i nie ma magicznej różdżki działającej jednocześnie na wszystkie te komponenty. Być może opracowanie takiej magicznej różdżki, element po elemencie, jest interesującą inwestycją, którą można rozcieńczyć przez cały czas trwania projektu.
Pracowałem nad 30-letnią bazą kodu, w której odchylenie między nomenklaturą użytkownika końcowego a nomenklaturą wewnętrzną stało się szczególnie duże. Oto kilka wad tej sytuacji, które dodatkowo obciążają pracę wszystkich:
W przypadku braku odpowiedniej polityki nowe opracowania zwykle wykorzystują obecną nomenklaturę użytkownika końcowego. Zatem ta sama koncepcja może mieć dwie lub więcej nazw w różnych komponentach. Ponieważ komponenty współdziałają ze sobą, powstaje kilka synonimicznych nazw istniejących jednocześnie w niektórych lokalnych częściach kodu.
Po wywołaniu infolinii / pomocy technicznej zapisują historię użytkownika za pomocą nomenklatury użytkownika końcowego. Deweloper odpowiedzialny za naprawienie problemu musi przetłumaczyć nomenklaturę użytkownika końcowego, aby pasowała do nomenklatury źródłowej. Oczywiście nie jest archiwizowany i oczywiście jest to bałagan. (Patrz 1.)
Gdy programista debuguje kod, chce ustawić punkty przerwania w odpowiednich funkcjach. Trudno jest znaleźć odpowiednie funkcje, jeśli nomenklatura użytkownika końcowego i nomenklatura źródłowa nie są zgodne. Być może nawet trudno jest mieć pewność, że lista odpowiednich funkcji jest nawet kompletna. (Patrz 1.)
W przypadku braku odpowiedniej polityki utrzymanie źródła przy użyciu przestarzałej nomenklatury od czasu do czasu ponownie przedstawi tę przestarzałą nomenklaturę użytkownikom. Powoduje to złe wrażenie i powoduje narzut.
Wyśledziłem już dwa dni samego miejsca, w którym niektóre dane są odczytywane z bazy danych i wstrzykiwane do jakiegoś elementu tej bazy kodu. Ponieważ niezależnie od tego, czy ja ani ktokolwiek w firmie, w której pracowałem, udało mi się znaleźć nazwę prowadzącą do tego miejsca, w końcu odrzuciłem i postanowiłem znaleźć inne rozwiązanie tego problemu.
Choć kosztuje więcej niż [1] dwa dni utrzymania bez niczego (bez wiedzy, bez poprawek, niczego) jest prawdopodobnie tak zły, jak to tylko możliwe, rozbieżności między nomenklaturą użytkownika a nomenklaturą źródłową obciążają wiele rutynowych zadań związanych z utrzymaniem oprogramowanie.
Ważne jest, aby zauważyć, że koszty ogólne rosną wraz z firmą produkującą oprogramowanie, w dużej organizacji raport o problemie nie pojawi się na biurku, zanim nie zostanie rozpatrzony przez kilku współpracowników, a poprawka może zostać przetestowana.
[1] Z powodu zaangażowania więcej niż jednego programisty.
źródło
Nie zawsze zmieniam nazwę kodu i danych, ponieważ niektóre pakiety są wspólne dla klientów. Zasadniczo używają tego samego, ale nazywają to inaczej. Przykłady, w systemie CMS, jeden klient nazywa swojego klienta „Klientem”, a inny używa „Klienta”. Dlatego zastąpiliśmy Klienta klientem na powierzchni dla jednego klienta, ale CMS zawsze będzie systemem zarządzania klientami.
Innym przykładem jest zarządzanie użytkownikami za pomocą terminów takich jak uprawnienia vs lista kontroli dostępu, administrator vs menedżer itp. Może to być mylące dla nowych użytkowników, ale w przypadku podstawowych komponentów takich jak te zwykle programiści dbają o to, aby te składniki działały dla wszystkich klientów również łatwe do wdrożenia przez innych programistów (np. poprzez tworzenie konfigurowalnych etykiet).
Pomoże ci pomyśleć, że jeśli dokonasz tej zmiany, mam nadzieję, że nie będziesz musiał tego robić ponownie, jeśli ten sam kawałek zostanie użyty przez innego klienta, zasadniczo zmieniając go w produkt.
źródło