Jaki jest właściwy sposób zarządzania skryptami programistów?

Programiści tworzą skrypty, które pomagają w ich pracy. Na przykład, aby uruchomić Maven z określonymi parametrami, zabić niepotrzebne zadania w tle, które pojawiają się w fazie rozwoju lub połączyć się z określonym serwerem. Skrypty nie są skryptami kompilacji rdzenia ani nie są używane na naszym serwerze Continuous Integration.

Jaki jest najlepszy sposób na zarządzanie nimi? Umieścić je w katalogu (być może /scripts) i sprawdzić w Git? Aby zachować je osobno na niektórych serwerach plików?

Argument za traktowaniem ich jako kodu źródłowego polega na tym, że są one źródłowe i mogą ulec zmianie. Argumentem za tym, aby tego nie robić, jest to, że są to tylko narzędzia pomocnicze i że nie wszyscy programiści potrzebują danego skryptu (np. Skrypty specyficzne dla systemu Linux, w których niektórzy programiści pracują w systemie Windows).

Skrypty deweloperów przechodzą także do kontroli wersji, ponieważ zwykle skrypty te zależą również od elementów kontroli wersji, np. Ścieżek plików.

Jeśli te skrypty są wersjonowane, powinny również działać dla wszystkich programistów, aby uniknąć sytuacji, w której każdy programista pisze swój własny zestaw skryptów, co staje się piekłem konserwacyjnym.

Ponadto poprawki lub ulepszenia tych skryptów są automatycznie wdrażane dla każdego programisty poprzez kontrolę wersji.

Oprócz odpowiedzi @ simon.

Nie wszystko w inżynierii oprogramowania dotyczy programowania, projektowania lub modelowania. Istnieje niezliczona ilość zadań, które wykonujemy nieprzerwanie w ciągu dnia roboczego. Wspomniałeś już o jednym - budowaniu projektu poza IDE - ale jest wiele innych.

Doświadczeni / proaktywni programiści zwykle automatyzują te zadania. Niektóre nawet budują narzędzia, gdy zadania te stają się częścią SDLC i są nużące - i podatne na błędy - wykonywane ręcznie. Programy są dobre w wykonywaniu powtarzalnych prac, bez względu na to, jak są nużące. My - ludzie - nie jesteśmy tacy dobrzy.

Te narzędzia / skrypty mają inne pozytywne skutki uboczne

1. Wydajność
2. Transfer wiedzy
3. Autonomia (dla nowych użytkowników)

Tak, tak, skrypty powinny znajdować się w SCM i powinny być jeszcze jednym narzędziem w przyborniku programisty.

Jeśli chodzi o folder /scripts, powiedziałbym, że to nie ma znaczenia. Dla uproszczenia zostawiam je w katalogu głównym projektu, aby wszystkie trasy zadeklarowane w skryptach były względne względem folderu projektu. Jeśli potrzebuję dostępu do zewnętrznych folderów lub plików, tworzę miękkie linki .

Rzeczy do rozważenia przed sprawdzeniem skryptów w SCM.

• Dla bezpieczeństwa upewnij się, że skrypty nie mają zakodowanych na stałe danych uwierzytelniających - najlepiej skrypty powinny być dobrze sparametryzowane -

• Upewnij się, że skrypty nie robią dziwnych rzeczy w systemie, na przykład do wykonywania poleceń, których nie można cofnąć (najbardziej typowe rm -rf).

• Ponieważ stały się one częścią źródła projektu, dokumentacja jest bardzo ceniona.

• Skrypty nie są nauką rakietową. Spraw, by skrypty były zwięzłe. Zamiast jednego rządzić nimi wszystkimi ... iw ciemności związać ich , uczynić więcej, mniejszymi i zwięzłymi. Jak gdybyś stosował SRP.

Mam zamiar zaoferować nieco bardziej negatywną opinię. Z jednej strony skrypty programistów, które są ogólne, skuteczne i przydatne, powinny oczywiście być udostępniane innym programistom, a najlepszym sposobem na to jest umieszczenie ich z kodem w tym samym repozytorium.

Ustawiłbym jednak wysoki próg wejścia do zatwierdzania skryptów. Skrypty są kodem, podobnie jak samo oprogramowanie. Oznacza to, że muszą być traktowane podobnie jak inne fragmenty kodu:

• Przegląd kodu
• Testowane i zautomatyzowane, jeśli to możliwe
• Rozważane przy wprowadzaniu zmian w bazie kodu (szczególnie, jeśli wielu programistów używa skryptu, wprowadzenie zmiany, która psuje skrypt spowoduje wiele konfliktów)
• Utrzymane (ze wszystkim, co się z tym wiąże - ustalanie priorytetów, czas, dokumentacja itp.).

Istnieje wiele innych kwestii, które dotyczą bardziej skryptów niż samego oprogramowania:

• Przede wszystkim znacznie trudniej jest przekonać organizację i interesariuszy do inwestowania w utrzymywanie skryptów ułatwiających programistom życie. Oznacza to, że trudniej jest znaleźć czas na spełnienie powyższych kryteriów - łatwo jest napisać skrypt, który będzie dla ciebie działał w twoim środowisku, ale sparametryzowanie go, uczynienie go stabilnym, dokumentowanie zajmie znacznie więcej czasu. Oznacza to, że skrypty mogą stać się martwym kodem, chyba że programista uzasadni utrzymanie aktualności skryptu.
• O wiele mniej prawdopodobne jest, że wielu programistów zna wystarczająco skomplikowany skrypt, aby go utrzymać, lub że wielu programistów odczuwa własność kodu. Gdy oryginalny programista odejdzie, znalezienie kogoś, od kogo można przejąć własność, może być trudne (a znalezienie i uzasadnienie czasu, w którym uczą się, jak działa skrypt, może być jeszcze trudniejsze).
• O wiele bardziej prawdopodobne jest, że skrypt będzie w jakiś sposób wchodził w interakcje z maszyną programistów i budował środowisko. Jest również bardzo prawdopodobne, że będziesz mieć wielu programistów w wielu różnych środowiskach. Jeśli skrypt psuje środowisko, ponieważ nie było właściwie utrzymywane lub nie uwzględniono przypadku narożnego, nie tylko łamiesz nocną wersję oprogramowania, ale potencjalnie kosztujesz programistę dzień lub więcej pracy, aby uzyskać jego środowisko wróciło do normy. Może to spowodować baad krew i utratę zaufania.
• Ponieważ skrypty są często zewnętrzne w stosunku do samego oprogramowania, utrzymanie ich może być wyzwaniem. Jeśli skrypty nie są uruchamiane przez automatyzację, łatwo im się zestarzeć lub zostać zapomnianym, w którym to momencie stały się martwym kodem i są tylko technologicznym długiem, który ktoś będzie musiał poświęcić na oczyszczenie.

Podsumowując, skrypty mogą być bardzo pomocne dla poszczególnych programistów, ale udostępnianie ich jako część samej bazy kodu może być znacznie trudniejszym zadaniem i może potencjalnie powodować więcej problemów niż rozwiązanych.