Czy generowanie kodu podnosi jakość kodu?

Argumentując za generowaniem kodu, szukam kilku przykładów sposobów, w jaki podnosi on jakość kodu. Aby wyjaśnić, co mam na myśli przez generowanie kodu, mogę mówić tylko o moim projekcie:

Używamy plików XML do opisywania relacji encji w naszym schemacie bazy danych, dzięki czemu pomagają nam generować naszą strukturę ORM i formularze HTML, których można używać do dodawania, usuwania i modyfikowania encji.

Moim zdaniem poprawia to jakość kodu, ponieważ zmniejsza się błąd ludzki. Jeśli coś zostanie zaimplementowane niepoprawnie, zostanie zepsute w modelu, co jest dobre, ponieważ błąd może pojawić się wcześniej, ponieważ zepsuty jest również więcej wygenerowany kod.

Ponieważ zapytano mnie o definicję jakości kodu , wyjaśnię to, co miałem na myśli, to jakość oprogramowania .

Jakość oprogramowania : nie jest to jeden atrybut, ale wiele, które wpływają na siebie, np. Wydajność, modyfikowalność, czytelność, poprawność, niezawodność, zrozumiałość, użyteczność, przenośność itp.

Generatory kodu nie mogą wygenerować lepszego kodu niż osoba, która napisała generator.

Moje doświadczenie z generatorami kodów polega na tym, że są w porządku, o ile nigdy nie będziesz musiał edytować wygenerowanego kodu . Jeśli możesz trzymać się tej zasady, możesz iść. Oznacza to, że możesz wiarygodnie i szybko ponownie generować tę część systemu, automatycznie dodając w razie potrzeby więcej funkcji. Myślę, że to może liczyć na jakość.

Kiedyś usłyszałem argument za generatorami kodu, że jeden programista może wytwarzać tak wiele wierszy kodu dziennie, a dzięki generatorom kodów mogą wytwarzać tysiące wierszy! Oczywiście nie dlatego używamy generatorów.

Byłbym przeciwny - zakładając, że piszesz ciekawe aplikacje, generowanie kodu obniża jakość kodu. Natura generowania kodu nagradza bardzo obcinające pliki cookie, przepełnione, zbyt szczegółowe ramy, z którymi bardzo trudno sobie poradzić bez ciągłego polegania na narzędziu do generowania kodu w celu ciągłego generowania większych, bardziej złożonych, brzydszych wiązek kodu. Chociaż może być dobrym narzędziem, tak naprawdę nie powinno być podstawowym narzędziem w pudełku.

Myślę, że automatyczne generowanie kodu i jakość kodu są nieco ortogonalne i niekoniecznie korelują.

Generowanie kodu jest jedynie sposobem na rozwiązanie określonego zadania technicznego. To, czy spowoduje to wzrost jakości kodu, zależy w dużej mierze od tego, co robisz.

Twoja sytuacja jest dobrym przykładem generowania kodu, którego wynikiem jest poprawa jakości kodu poprzez wczesne wykrywanie potencjalnych błędów.

Mogę podać kolejny przykład, gdy automatyczne generowanie kodu obniża jakość kodu. To jest wszechmocny WebForms ASP.NET. Automatycznie generuje kod, tłumacząc hierarchię elementów sterujących interfejsu użytkownika na znaczniki HTML, które są stabilne, przewidywalne i łatwe do zarządzania.

Aby wyciągnąć wniosek, automatyczne generowanie kodu może pomóc w poprawie jakości kodu, gdy jest właściwie stosowany.

Generowanie kodu nie wpływa samo na jakość kodu , podobnie jak na spójność kodu .

Wygenerowany kod będzie spójny między instancjami generowania. Jeśli generator jest zaprojektowany do emitowania kodu dobrej jakości, wówczas generowany kod będzie niezmiennie dobrej jakości. Jeśli jednak generator kodu emituje kod o złej jakości, konsekwentnie otrzymujesz zły kod.

Generowanie kodu można również wykorzystać do szybszego budowania kodu . Szybsze jednak nie oznacza lepszego ... Może to oznaczać, że otrzymujesz kod złej jakości o wiele szybciej.

Generowanie kodu jest dobre, jeśli:

• wygenerowany kod nie powinien być edytowany
• generator kodu zapewnia wystarczającą elastyczność, aby robić to, co musisz zrobić
• język wprowadzania do generatora kodu jest lepszy (tj. OSUSZANIE) niż to, co w innym przypadku musiałbyś napisać
• generator kodu tworzy dobry, niezawodny kod, o który nie musisz się martwić, nawet jeśli jest trudny

W takim przypadku kodem, którego jakość należy wziąć pod uwagę, jest kod wprowadzany do generatora.

Prostą miarą jakości jest, w przypadku typowych zmian wymagań, ile ręcznej edycji musisz zrobić. Im mniej, tym lepiej.

Zwiększona jakość kodu z powodu OSUSZANIA (nie powtarzaj się).

Reguły generowania kodu są zapisywane raz; nie są one zakodowane na stałe dla każdego wygenerowanego kodu, a tym samym zmniejszają potencjał błędu ludzkiego podczas kopiowania / wklejania treści z niewielkimi modyfikacjami.

Zakładam, że masz na myśli generatory kodu własnościowego przeznaczone do konkretnego użytku wewnętrznego, ponieważ w przeciwnym razie kod maszynowy jest generatorem kodu. Ale proszę bardzo:

Myślę, że bardzo dyskusyjne jest to, że graf węzłów w Blueprints jest łatwiejszy w utrzymaniu i znacznie mniej podatny na błędy niż generowany przez niego kod GLSL / HLSL (i w innym przypadku musiałby być pisany odręcznie).

O wiele bardziej produktywne jest wymyślanie nowych shaderów, ponieważ otrzymujesz wizualną informację zwrotną w czasie rzeczywistym o tym, jak wygląda efekt końcowy po zmianie wykresu. Zdecydowanie wolałbym utrzymywać w ten sposób tysiące shaderów reprezentowanych za pomocą grafów węzłowych zamiast kodu GLSL / HLSL, i tak naprawdę lepiej znam pisanie GLSL / HLSL niż używanie Blueprints. Wydaje mi się, że jest to praktycznie niemożliwe, aby spowodować poważny błąd oprócz być może drobnej usterki wizualnej, którą prawdopodobnie złapałbyś od razu, ponieważ „język wizualny” nakłada rozsądne ograniczenia z często czystym funkcjonalnym stylem, który nie pozwala, powiedzmy, załamać moduł cieniujący, przynajmniej AFAIK (co prawda nie jestem ekspertem od Blueprints).

Nie ma nawet „kodu” do utrzymania. Po prostu umieszczasz węzły wewnątrz wykresu i rysujesz między nimi połączenia, i voila, generuje dla ciebie kod modułu cieniującego. Kto utrzymuje te rzeczy i mówi: „ Wiesz, moje życie byłoby o wiele łatwiejsze i miałbym o wiele więcej wolnego czasu, gdyby zostało to zapisane w kodzie GLSL zamiast korzystania z Blueprints ” . Prawdopodobnie nigdy.

To powiedziawszy, natknąłem się na część własnych generatorów kodów, które utrudniły życie, co spowodowało, że nauczyłem się tego głupiego meta-języka, który ma bardzo ograniczone korzyści, jeśli w ogóle, nad pisaniem kodu w języku wygenerowanego kodu. Dla mnie charakterystycznym znakiem generowania kodu, który jest gówniany, jest to, co robi niewiele więcej niż redukuje niewielką ilość płyty kotłowej i w rzeczywistości nie zmniejsza, powiedzmy, możliwości błędów. Wiesz, że to szczególnie gówniane, jeśli faktycznie wprowadza nowe sposoby powodowania błędów, których nie miał oryginalny język. Istnieją jednak przypadki generowania kodu, takie jak powyższe, w których wzrost wydajności jest tak ogromny, że drobiazgowe rzeczy, które kosztują olbrzymi czas, kosztują teraz grosze, że nikt nigdy nie użyłby ich i nie obejrzałby się za siebie.

Dla mnie jest bardziej uzasadniony argument za zastrzeżonym opracowaniem Blueprints wśród zespołu Epic, niż wiele zbędnych języków programowania dostępnych dla ogółu społeczeństwa, które ledwo wnoszą coś nowego do stołu.

Powiedziałbym, że w twoim przypadku może to nieco podnieść jakość, ale znacznie skraca czas programowania. Czasami wygenerowany kod jest niestabilny, niezręczny lub po prostu zły. W takich przypadkach wygenerowany kod może obniżyć jakość i wydłużyć czas testowania / naprawy / regresji do projektu. Niektóre zadania są po prostu zbyt skomplikowane, aby można je było łatwo wygenerować - generator staje się odrębnym systemem (być może większym i bardziej złożonym niż główny projekt).

Generatory kodów są w porządku, ale bądź z nimi ostrożny!

Pracowałem w sklepie, który w dużej mierze polegał na generowaniu kodu. Moim zdaniem kod ten był bardzo jednolity. I pod tym względem jakość była OK.

Jeśli jednak nie możesz już pisać niestandardowego kodu, ponieważ wszystko musi przejść przez generator, myślę, że tracisz trochę przewagi w byciu programistą.

Myślę więc, że to z pewnością temat miecza o podwójnej krawędzi. Tak, generatory są świetne, ponieważ redukują błędy i podnoszą standardy kodu, jednak powodują, że „niektórzy” programiści są głupi, ponieważ są zależni od generatorów zamiast brudzić sobie ręce.

Tylko moje 2 centy.

Oprócz odpowiedzi Martina dodam, że generowanie kodu SQL jest bardzo dobre, gdy pracujesz w trybie rekord po rekordzie (wybierz * z tab1 gdzie tab1.pkcolumn =: parametr, aktualizuj tab1 ustaw [dowolną liczbę kolumn] gdzie tab1.pkcolumn =: parametr itp.). Twoja ORM będzie świecić w tym scenariuszu, ponieważ SQL, który należy wygenerować, jest w rzeczywistości powtarzalny.

Moje główne zmartwienia to metaqueries - zapytania o właściwości obiektu, które ORM tłumaczy na SQL przy użyciu dowolnego algorytmu. Bardzo podobne metaqueries mogą generować SQL, który jest zupełnie inny - i nie mają gwarancji, że ten wygenerowany SQL jest wydajny.

Język metaquery, który tłumaczy na inny język (SQL), który przekłada się na plan zapytań w celu skutecznego wykonania gromadzenia danych. Wygenerowany wynik musi być obiektami, więc ORM musi utworzyć instancję dotkniętych obiektów - aby mógł wywołać kolejny deszcz zapytań, wypełniając atrybuty obiektów nie wniesionych przez samą metaquery ...

Całkowicie zgadzam się z tymi, którzy twierdzą, że generowanie kodu jest w porządku, o ile nigdy nie musisz edytować (najlepiej nigdy nie patrzeć) wygenerowanego kodu.

Jeśli możemy zaakceptować, że wygenerowany kod ma w przybliżeniu taką samą liczbę wierszy, jak ręcznie napisany, i jeśli możemy powiedzieć, że jest on wolny od błędów, wówczas liczba linii, które potencjalnie mogą zawierać błędy, zmniejszyła się. Ergo, jakość kodu powinna wzrosnąć.

Dodatek: oczywiście inne czynniki, takie jak czas wykonania, mogą odgrywać rolę.

Osobiście napisałem sporo generatorów kodu, ale nigdy jako wstępne podejście.

Zawsze tak było, kiedy zauważyłem powtarzający się wzorzec w istniejącym kodzie, więc mój generator pobiera trochę istniejącego kodu podczas dodawania nowego, ale podobnego kodu i sparametryzował niektóre jego zmienne części.

W tym zakresie mój wygenerowany kod jest prawie identyczny z istniejącym odręcznym kodem (z wyjątkiem tego, że ma on lepszą strukturę wizualną i jest bardziej jednolity, co uważam za pomocne w czytelności, jeśli kiedykolwiek trzeba go obejrzeć).

Przy okazji, zalecam wstawianie komentarzy otwierających / zamykających, które wskazują, że kod został wygenerowany, w tym szczegółów narzędzia i jego opiekuna.