Jak sprawić, by Kod był wielokrotnego użytku?

Jeśli zastosujesz podejście testowe, Twój kod będzie mógł być ponownie użyty jako refaktor tylko w oparciu o nadchodzące scenariusze.

Osobiście uważam, że ciągle refaktoryzacja generuje czystszy Kod, niż próba zastanowienia się, do jakich scenariuszy muszę kodować daną klasę.

Bardziej niż cokolwiek innego, konserwacja sprawia, że kod jest wielokrotnego użytku.

Reusability rzadko jest wartościowym celem samym w sobie. Jest to raczej produkt uboczny pisania kodu, który jest dobrze zorganizowany, łatwy do utrzymania i przydatny.

Jeśli postanowiłeś stworzyć kod wielokrotnego użytku, często starasz się wziąć pod uwagę wymagania dotyczące zachowania, które mogą być wymagane w przyszłych projektach. Bez względu na to, jak dobry staniesz się w tym, przekonasz się, że masz te przyszłościowe wymagania błędne.

Z drugiej strony, jeśli zaczniesz od gołych wymagań obecnego projektu, przekonasz się, że Twój kod może być czysty, szczelny i elegancki. Gdy pracujesz nad innym projektem, który wymaga podobnej funkcjonalności, w naturalny sposób dostosujesz swój oryginalny kod.

Proponuję przyjrzeć się najlepszym praktykom dla wybranego języka / paradygmatu programowania (np. Wzorce i solidne dla typów Java / C#), Literatura programowania Lean / Agile oraz (oczywiście) książka "Code Complete". Zrozumienie zalet i wad tych podejść poprawi twoją praktykę kodowania bez końca. Cały Twój kod będzie można odzyskać-ale "przez przypadek", a nie przez projekt.

Zobacz też: pisanie kodu

Dla większości definicji "ponownego użycia", ponowne użycie kodu jest mitem, przynajmniej z mojego doświadczenia. Możesz powiedzieć, że mam po tym jakieś blizny? :-)

Przez ponowne użycie, nie mam na myśli pobierania istniejących plików źródłowych i wysyłania ich do przesyłania, dopóki nowy komponent lub usługa nie wypadnie. Mam na myśli wzięcie konkretnego komponentu lub usługi i ponowne wykorzystanie go bez zmian.

Myślę, że pierwszym krokiem jest wprowadzenie nastawienia, że potrzeba co najmniej 3 iteracji, aby stworzyć wielokrotnego użytku komponent. Dlaczego 3? Ponieważ za pierwszym razem, gdy próbujesz ponownie użyć komponentu, zawsze odkrywasz coś, z czym nie może sobie poradzić. Więc musisz to zmienić. Zdarza się to kilka razy, aż w końcu masz komponent, który przynajmniej wydaje się być wielokrotnego użytku.

Innym podejściem jest wykonanie kosztownego, przyszłościowego projektu. Ale wtedy koszty są wszystkie z góry, a korzyści (mogą) pojawiają się jakiś czas w dół drogi. Jeśli twój szef nalega, aby obecny harmonogram projektu zawsze dominował, wtedy to podejście nie zadziała.

Object-orientation pozwala na refaktorowanie kodu do superklas. Jest to prawdopodobnie najłatwiejszy, najtańszy i najskuteczniejszy rodzaj ponownego użycia. Zwykłe dziedziczenie klas nie wymaga dużo myślenia o "innych sytuacjach"; nie trzeba budować "Wszechmocnego" kodu.

Poza prostym dziedziczeniem, ponowne użycie jest czymś, co znajdujesz więcej niż wymyślasz. Znajdujesz sytuacje ponownego użycia, gdy chcesz ponownie użyć jednego z własnych pakietów, aby rozwiązać nieco inny problem. Kiedy chcesz użyj ponownie pakietu, który nie pasuje dokładnie do nowej sytuacji, masz dwa wyjścia.

1. Skopiuj i napraw. Teraz trzeba prawie podobne Pakiety -- kosztowny błąd.

2. Spraw, aby oryginalny pakiet był wielokrotnego użytku w dwóch sytuacjach.

Po prostu zrób to dla ponownego użycia. Nic więcej. Zbyt wiele myślenia o" potencjalnym "ponownym użyciu i nieokreślonych" innych sytuacjach " może stać się stratą czasu.

Będziesz pisać różne moduły (części) podczas pisania stosunkowo dużego projektu. Kod wielokrotnego użytku w praktyce oznacza tworzenie bibliotek, z których mogą korzystać inne projekty wymagające tej samej funkcjonalności.

Więc musisz zidentyfikować moduły, które mogą być ponownie użyte, do tego

1. Określenie podstawowych kompetencji każdego modułu. Na przykład, jeśli twój projekt ma kompresować pliki, będziesz miał moduł, który zajmie się kompresją plików. Do nie make it do more than JEDNA RZECZ . Tylko jedno.

2. Napisz bibliotekę (lub klasę), która zajmie się kompresją plików, bez potrzeby niczego więcej niż plik do skompresowania, wyjście i format kompresji. Spowoduje to oddzielenie modułu od reszty projektu, umożliwiając jego (ponowne)użycie w innym ustawieniu.

3. Nie musisz go doskonalić za pierwszym razem, gdy faktycznie wykorzystasz bibliotekę, prawdopodobnie dowiesz się wad w projekcie (dla przykład, nie uczyniłeś go na tyle modularnym, aby móc łatwo dodawać nowe formaty kompresji) i możesz naprawić je po raz drugi i poprawić wielokrotne użycie modułu. Im bardziej go używasz (i naprawiasz wady), tym łatwiej będzie go ponownie użyć.

Najważniejszą rzeczą do rozważenia jest odsprzęgnięcie, jeśli napiszesz ściśle sprzężony kod reusability jest pierwszą ofiarą.

Pozostaw cały potrzebny stan lub kontekst poza biblioteką. Dodaj metody do określenia Państwo do biblioteki.

Inni wspominali o tej taktyce, ale tutaj są formalnie. Te trzy zabiorą cię bardzo daleko:

/ Align = "left" / Zasada - zapewnia, że twoja klasa "robi tylko jedną rzecz", co oznacza, że jest bardziej prawdopodobne, że będzie wielokrotnego użytku dla innej aplikacji, która zawiera tę samą rzecz.
• Liskov Zasada substytucji - zapewnia, że Twój kod "robi to, co powinien bez niespodzianek" , co oznacza, że jest bardziej prawdopodobny będzie wielokrotnego użytku dla innej aplikacji, która wymaga tego samego.
• przestrzegaj Zasady Open/Closed - zapewnia, że Twój kod może zachowywać się inaczej bez modyfikowania jego źródła, co oznacza, że jest bardziej prawdopodobny do wielokrotnego użytku bez bezpośredniej modyfikacji.

Aby dodać do wyżej wymienionych elementów, powiedziałbym:

• Stwórz funkcje ogólne, które musisz ponownie wykorzystać
• Użyj plików konfiguracyjnych i spraw, aby Kod używał właściwości zdefiniowanych w plikach / db
• wyraźnie włączaj swój kod do takich funkcji/klas, które zapewniają niezależną funkcjonalność i mogą być używane w różnych scenariuszach i Definiuj te scenariusze za pomocą plików konfiguracyjnych

Dodałbym pojęcie "skład klasy nad dziedziczeniem klasy" (które pochodzi z innych odpowiedzi tutaj). W ten sposób "złożony" obiekt nie dba o wewnętrzną strukturę obiektu, od którego zależy - tylko o jego zachowanie, co prowadzi do lepszej hermetyzacji i łatwiejszej konserwacji (testowanie, mniej szczegółów do dbania). W językach takich jak C# i Java jest to często kluczowe, ponieważ nie ma wielokrotnego dziedziczenia, więc pomaga uniknąć grafu dziedziczenia.

Jak wspomniano, kod modułowy jest bardziej wielokrotnego użytku niż kod niemodułowy.

Jednym ze sposobów na pomoc w kodowaniu modułowym jest użycie enkapsulacji, patrz teoria enkapsulacji tutaj: http://www.edmundkirwan.com/

Ed.

Unikaj wymyślania koła na nowo. To wszystko. I to samo w sobie ma wiele korzyści wymienionych powyżej. Jeśli musisz coś zmienić, po prostu tworzysz kolejny fragment kodu, inną klasę, inną stałą, bibliotekę itp... pomaga tobie i reszcie programistów pracujących w tej samej aplikacji.

Skomentuj, szczegółowo wszystko, co wydaje się być mylące, gdy wrócisz do kodu następnym razem. Nadmiernie gadatliwe komentarze mogą być nieco irytujące, ale są o wiele lepsze niż rzadkie komentarze i mogą zaoszczędzić wiele godzin prób zrozumienia WTF, które robiłeś ostatnio.