Czasami mój szef narzeka nam:
Dlaczego potrzebujemy tak długiego czasu na wdrożenie funkcji?
Właściwie ta funkcja została już wcześniej zaimplementowana w innej aplikacji, wystarczy skopiować i wkleić stamtąd kody. Koszt powinien być niski.
To naprawdę trudne pytanie, ponieważ z mojego punktu widzenia kopiowanie i wklejanie kodów nie jest takie proste.
Czy masz jakieś dobre powody, aby wyjaśnić to swojemu nietechnicznemu szefowi?
Odpowiedzi:
Jeśli znajdziesz błąd w swoim kodzie kopiuj-wklej, będziesz musiał go naprawić w każdym miejscu, które zrobiłeś i mieć nadzieję, że możesz je wszystkie zapamiętać (dotyczy to również zmienionych wymagań).
Jeśli zachowasz logikę w jednym miejscu, łatwiej jest ją zmienić w razie potrzeby (więc jeśli uznasz, że aplikacja wymaga aktualizacji, robisz to tylko w jednym miejscu).
Poproś szefa o przeczytanie o zasadzie DRY (Don't Repeat Yourself).
To, co opisujesz, brzmi jak idealne zastosowanie dla bibliotek , gdzie udostępniasz kod i przechowujesz go tylko w jednym miejscu.
Kopiowałbym i wklejałbym kod tylko wtedy, gdybym wkrótce potem zamierzał go refaktoryzować - upewniając się, że później wyodrębniłem wspólny kod, aby móc ponownie wykorzystać jak najwięcej logiki. Wkrótce potem mam na myśli minuty i godziny później, a nie dni i tygodnie.
ifs, a większość narzędzi nie obsługuje obecnie wykrywania klonów.
Byłoby znacznie lepiej, gdybyś udostępnił kod, budując bibliotekę, zamiast kopiować kod za pomocą kopiowania i wklejania.
Nadal uzyskasz przewagę szybkości nad ponownym pisaniem (patrz DRY), ale będziesz mieć tylko jedno miejsce do utrzymania kodu.
Oczywistym powodem jest to, że zaciągasz `` dług '' na przyszłość: każda zmiana, jaką kiedykolwiek będziesz musiał wprowadzić w kodzie (nie tylko poprawki błędów, każda zmiana) będzie teraz dwa razy droższa, ponieważ musisz zaktualizować dwa miejsca - i bardziej ryzykowne, ponieważ w końcu zapomnisz o jednym z nich. Innymi słowy, przyspieszenie teraz pracy sprawi, że w przyszłości Twoja praca będzie jeszcze wolniejsza, co może mieć dobry sens biznesowy, ale zwykle nie jest.
Ale ważniejszym powodem jest to, że założenie „to jest to samo co tamto” jest najczęściej w subtelny sposób błędne. Ilekroć twój kod zależy od niewypowiedzianych założeń, aby był poprawny, skopiowanie go w inne miejsce skutkuje błędami, chyba że te założenia obowiązują również w nowym miejscu. Dlatego wklejony kod jest często nieprawidłowy od samego początku, a nie zaraz po kolejnej zmianie.
Z punktu widzenia projektu, kod wklejony do kopii jest z pewnością katastrofą, która może spowodować wiele problemów w przyszłości. Ale pytasz dlaczego zajmuje Ci dużo pracy teraz , odpowiedź brzmi: dlatego, że nigdy nie jest po prostu skopiowanie i wklejenie.
Jeśli oryginalny kod został napisany w celu ponownego wykorzystania, jako dość niezależna biblioteka, z myślą o elastyczności i obsłudze klienta - to świetnie, ale to nie jest kopiowanie i wklejanie, to użycie biblioteki kodu. Kopiowanie i wklejanie prawdziwego kodu zazwyczaj wygląda tak:
Podsumowując, istniejący kod, którego nie można użyć bezpośrednio, może w najlepszym przypadku służyć jako dobre odniesienie do pisania podobnego kodu. Z pewnością nie da się go podnieść w całości i oczekiwać, że będzie działał w zupełnie innym systemie. Ogólnie rzecz biorąc, jest to bezpieczne założenie, że każdy kod, który został napisany i ukończony, powinien zostać wprowadzony jak najmniejszym bałaganem - nawet jeśli jest to kopia, a nie sam oryginał.
Jeśli chcesz oprzeć swój projekt na kopiowaniu i wklejaniu, musisz zacząć od kodu w sposób, który umożliwi łatwe ponowne użycie, bez kopiowania oryginalnego kodu i majstrowania przy nim. Warto to zrobić, a jeśli tego oczekuje twój szef, to oboje musicie się upewnić, że właśnie w ten sposób projektujesz i pracujesz.
kopiowanie i wklejanie to katastrofa, która czeka. Twój szef powinien wcześnie oszacować cenę wysyłki w odniesieniu do ceny za niedługo uszkodzony kod wysłany do użytkownika końcowego.
Jeśli masz już zaimplementowane funkcje i musisz je skopiować i wkleić, aby użyć ich ponownie, wygląda na to, że zrobiłeś coś złego. Nie możesz umieścić tych funkcji w bibliotece, aby móc ich ponownie używać bez kopiowania / wklejania?
Zasada DRY (Don't Repeat Yourself): DRY na Wikipedii .
„Każda część wiedzy musi mieć jedną, jednoznaczną, autorytatywną reprezentację w systemie”.
Wydaje mi się, że najgorszym błędnym przekonaniem, jakie ma twój nietechniczny szef, jest to, że twoja praca polega głównie na pisaniu na maszynie. Uważają, że możesz zaoszczędzić dużo czasu, eliminując pisanie.
Myślę, że najlepszą edukacją, jaką możesz dać tej osobie, jest wskazanie całej pracy, którą wykonujesz, a nie pisanie na maszynie. Nawet jeśli większość tej pracy zwykle dzieje się niewidocznie, w Twojej głowie, w tym samym czasie, co pisanie.
Jasne, wyeliminowanie wpisywania pozwoli zaoszczędzić trochę czasu. Ale wtedy znacznie większa część pracy, która nie polega na pisaniu na maszynie, staje się większa i pochłania każdą oszczędność czasu i nie tylko.
Czy na pewno Twój szef chce usłyszeć o zasadzie DRY, błędach i innych sprawach technicznych?
Tego rodzaju uwagi zwykle słyszysz, gdy Twój szef lub firma nie docenili czasu potrzebnego na ukończenie jakiegoś projektu. W oparciu o błędne oszacowanie podpisano umowę itp. W większości przypadków programiści nie brali udziału w szacowaniu.
Dlaczego tak się dzieje? Czasami sponsor projektu ma zbyt mały budżet. Może proces biznesowy, który automatyzujesz za pomocą oprogramowania, nie jest wart wysiłku Twojego zespołu. W takich przypadkach menedżerowie są zazwyczaj bardzo zamknięci na złe wieści. Na początku projektu jest myślenie życzeniowe. Następnie menedżerowie próbują winić programistów. W twoim przypadku pośrednio poprzez kopiowanie i wklejanie. W skrajnych przypadkach nazywa się to marszem śmierci .
Kopiowanie i wklejanie kodu zwykle prowadzi do programowania przez przypadek
Myślę, że kluczowa jest tutaj „ inna aplikacja ”, jeśli inna aplikacja jest już przetestowana i używana, nie należy jej zmieniać aby korzystała ze wspólnej biblioteki, dlatego nie można jej udostępniać kodu.
W ramach tej samej aplikacji „kopiuj i wklej” jest złe, ale pomiędzy bazami kodu opracowanymi przez różne zespoły lub z różnymi cyklami wydawania „kopiuj i wklej” może być najlepszą opcją.
Pracowałem w podobnej firmie. Będąc stażystą nie wiedziałem wtedy lepiej, więc kiedy zaczynałem nowy projekt, mój szef również zasugerował wklejenie kodu z innego miejsca. Cóż, jak może się wydawać, całe oprogramowanie było dość bałagan, do tego stopnia, że kiedy próbowałeś naprawić błąd, pojawiły się dwa nowe błędy.
Nawet jeśli inna aplikacja ma już potrzebną funkcję, kod tej funkcji może po prostu nie pasować do bieżącej aplikacji bez poważnego przepisania. To tak, jakby wziąć silnik forda i spróbować dopasować go do toyoty. Generalnie istnieje praktyczna zasada, że jeśli musisz zmodyfikować więcej niż 25% kopiowanego kodu, lepiej (taniej) jest przepisać go od nowa.
Wyodrębnienie danego kodu do biblioteki brzmi atrakcyjnie, ale może być trudniejsze niż się wydaje, w zależności od tego, jak ten inny system jest zbudowany. Na przykład kod tej funkcji może być trudny do wyodrębnienia, ponieważ łączy on wiele innych kodów w nieczysty sposób (np. Uzyskując dostęp do wielu zmiennych globalnych itp.)
Tak, największym problemem jest to, że nie jest to tylko kopiowanie i wklejanie - jego kopiowanie, wklejanie, a następnie nieznaczna modyfikacja.
Później, gdy jeden z wklejonych wariantów ma problem, zostaje zmieniony. Później zmieniono inny wariant.
Następnie okazuje się, że wszystkie warianty muszą ulec zmianie, ponieważ oryginalna kopia zawiera błędy. Teraz jesteś dobrze i naprawdę załatwiony, ponieważ wszystkie wklejone obszary nie są teraz takie same.
I czy nie wiedziałbyś o tym, tego rodzaju kiepskie kodowanie jest zwykle prawie całkowicie pozbawione komentarzy.
Dla mnie różnica polega na tym, że kiedy masz wiele kopii kodu wykonujących to samo, to co masz jest kawałkiem kodu. Kiedy masz tylko jeden kawałek kodu wykonujący każdą konkretną rzecz, masz system.
Zachowanie systemu można dość łatwo zmienić za pomocą pojedynczych modyfikacji - zmiana zachowania zestawu kodu wymaga sporej ilości kodu.
Lubię systemy, a nie zbiór kodu.
Istnieją kompromisy między szybkością rozwoju natychmiastowej funkcjonalności przed Tobą (zwłaszcza gdy aplikacja jest niewielka) a długoterminowymi kosztami utrzymania w miarę rozwoju aplikacji.
Kopiowanie i wklejanie jest szybsze w przypadku natychmiastowej funkcjonalności, ale będzie Cię drogo kosztować, gdy aplikacja będzie się rozrastać, jeśli chodzi o naprawianie błędów i wprowadzanie zmian w całym systemie oraz utrzymywanie przepływów pracy między różnymi komponentami aplikacji.
To jest argument, który właściciele firm powinni usłyszeć. Jest to podobne do akceptowanych kosztów utrzymania floty pojazdów, jednak w przypadku oprogramowania zepsute aspekty architektury oprogramowania są generalnie ukryte po stronie biznesowej i mogą być widoczne tylko przez programistów.
Ma rację, że jeśli zespół wdrożył wcześniej podobną funkcjonalność, powtórzenia tego będzie dużo łatwiejsze za drugim razem.
Jednak prawdopodobnie powinieneś wyjaśnić, że każda aplikacja jest inna. Tylko dlatego, że zainstalowałeś drzwi w jednym domu, nie oznacza, że możesz zainstalować kolejne drzwi w innym domu w krótkim czasie - będziesz szybszy dzięki doświadczeniu (liczba zainstalowanych drzwi), ale nadal zajmie trochę czasu, aby uzyskać sprzęt zamontuj drzwi, upewnij się, że są pionowe i przykręć je do ramy.
w mojej firmie zawsze pracujemy z klasami i metodami oraz wykonujemy dla nich dokumentację techniczną. Myślę, że to najlepsza praktyka, jeśli możesz użyć własnych aplikacji wyszukiwania svn z dobrymi kluczami, aby znaleźć klasę metody używaną wcześniej :)