Problemy (takie jak utrzymanie) w rozwoju z niepopularnym językiem

W moim zespole pracuję nad aplikacją z clojure (lisp). Zaczyna się jako mała aplikacja. Nie ma problemu. Ale ponieważ ma funkcje i rozszerza obszar, staje się ważnym programem.

Martwiłem się o konserwację czy coś takiego. Nikt w moim zespole nie zna clojure ani seplenienia, ani nie interesuje się takimi językami jak oni.

Czy więc nie jest źle robić programowanie w niepopularnych językach? (dla własnej zabawy?) Czy powinienem używać bardziej popularnych języków? (przynajmniej taki jak python)

Jestem pewien, że jeśli odejdę z zespołu, - nie mówię, że odchodzę. :) - nikt by tego nie utrzymał. Ten program zostanie zniszczony, a niektóre będą rozwijać się w innym języku.

Bardzo się cieszę rozwijaniem z clojure, ale zorientowałem się, że to może nie być mój zespół.

Co o tym myślisz? Myślę, że wielu programistów kochających niepopularne języki zajmowało się podobną kwestią.

Czuję twój ból, chciałbym więcej kodować w programowaniu funkcjonalnym (Haskell wygląda tak zabawnie!). Wydaje mi się, że dopiero co podrapałem powierzchnię, ponieważ nie używam jej jeszcze w kontekście biznesowym.

Zdecydowanie jednak odradzam to robić . Jeśli programujesz tylko w języku, który znasz, tylko Ty będziesz mógł go obsługiwać. Chyba że chcesz poradzić sobie z każdym problemem związanym ze wsparciem (nawet jeśli masz inne terminy / priorytety), koduj w języku, który Twój zespół zna i może wspierać. Co się stanie, gdy coś się zepsuje podczas wakacji? Co się stanie, jeśli chcesz dostać awans?

Polecam zabrać ze sobą co najmniej jednego członka zespołu. Pokaż im kilka fajnych funkcji językowych. Z dwiema osobami na pokładzie jest to wykonalne i nie będziesz obciążony całym wsparciem.

Jestem pewien, że jeśli odejdę z zespołu, - nie mówię, że odchodzę. :) - nikt by tego nie utrzymał.

Prawdopodobnie Fałsz.

Jeśli program ma wartość, a zarząd dostrzega wartość, zleci komuś nauczenie się Clojure i utrzymanie go.

Dzieje się cały czas.

Ten program zostanie zniszczony, a niektóre będą rozwijać się w innym języku.

Zawsze prawda. Więc po co się tym martwić?

Wszystkie programy muszą ostatecznie zostać wymienione.

Jestem dokładnie w miejscu, w którym wyobrażasz sobie następcę. Zadanie polegało mi na dodaniu funkcji do starszego programu, który korzystał z Clojure i Erlanga do wyszukiwania asynchronicznego i przekształcenia go w program, który dokonuje wyszukiwania asynchronicznego. Kiedy podjąłem tę pracę, wszystko, co wiedziałem, to Python i Java.

Moja rada dla Ciebie: użyj najlepszego narzędzia do pracy . Jeśli tym narzędziem jest Clojure, niech tak będzie. Języki programowania nie są trudne do nauczenia się. Dobrze napisany kod w języku odpowiednim do danego zadania jest zawsze łatwiejszy do odczytania niż kod, który próbuje zrobić coś, do czego język nie został zaprojektowany. Następcy łatwiej będzie czytać czyste Clojure niż zniekształconą Javę.

Przyjęcie nowego języka lub języka „ samodzielnego ” przez pewne zadanie stanowi duże ryzyko w projekcie.

Jeśli ta część systemu ma problem lub należy ją zamknąć, musisz znaleźć programistę, który musi nauczyć się umiejętności obsługi tego języka. W obu przypadkach straciłeś dużo czasu.

W niektórych przypadkach problem ten można wykorzystać do poprawy i dywersyfikacji umiejętności zespołu według przyszłych zadań.

Clojure może mieć obecnie małą zainstalowaną bazę (pojawiła się w 2007 roku), ale nie jest mało popularna - w rzeczywistości jest to prawdopodobnie „najgorętszy” nowy język. Byłbym zaskoczony, gdybyś nie mógł znaleźć innych osób zainteresowanych nauką.

W każdym razie, czy przyjąć nowy język, zawsze powinna być decyzja oparta na wartości dla firmy . Możesz omówić ze swoim menedżerem w następujący sposób:

Zalety przyjęcia Clojure:

• Bardziej produktywny niż inne używane języki - o czym świadczy ilość użytecznych funkcji dostarczonych w krótkim czasie i przy mniejszej liczbie wierszy kodu
• Mamy już jedną ważną aplikację (twoją) napisaną w Clojure, więc warto budować umiejętności Clojure, aby ją utrzymać (zamiast kosztownego przepisywania)
• Korzystanie z Clojure będzie postrzegane jako innowacyjne i może być dobrym sposobem na zmotywowanie utalentowanych programistów do dołączenia / pozostania w firmie.

Wady przyjęcia Clojure

• Jeden dodatkowy język do wsparcia
• Programiści mogą potrzebować więcej szkolenia i czasu, aby przyśpieszyć

Gdybym był menedżerem oceniającym tę decyzję, prawdopodobnie spodobałby mi się pomysł wyższej produktywności od Clojure, aby pozwolić na pewne ograniczone eksperymenty i odroczyć decyzję, dopóki nie będzie jasne, jak dobrze sobie radzi zespół. W takim przypadku prawdopodobnie musiałbyś być adwokatem, zachowywać się jak dobry nauczyciel i pomagać innym.

Nie martw się, bądź szczęśliwy.

Najwyraźniej program ma wartość, inaczej nie rozszerzyłbyś jej. Gratulujemy udanego projektu. Prawdopodobnie wybrałeś Clojure, ponieważ dzięki temu zaoszczędziłeś czas, a tym samym zaoszczędziłeś pieniądze pracodawcy. Jeśli napisałeś go w Javie, program byłby jeszcze trudniejszy w utrzymaniu. Nawet gdyby Twoi koledzy mogli łatwiej zrozumieć program linia po linii, czy byliby w stanie go utrzymać i rozszerzyć?

Powiedziałbym ci więcej mocy! Lisp jest dziadkiem języków komputerowych i jest nadal aktualny; fakt, że nie jest tak popularny, jak sądzę, wynika z faktu, że nie ma ciepłych puszystych IDE C # i Java, a główna implementacja kompilatora w Windows działa tylko pod Cygwinem (fuj!). Wydaje się, że prace rozwojowe odbywają się w Emacsie i myślę, że lepiej to działa na Linuksie lub Macu.

Ten konkurs kodowania wygrał program Lisp w 2010 roku: http://planetwars.aichallenge.org/

Dawno temu, kiedy mogli debugować go na żywo z około 100 milionów mil: http://www.flownet.com/gat/jpl-lisp.html

Zdecydowanie rezygnujesz z konserwacji, ale pomyśl o tym jako o możliwości uczenia się dla kogoś innego. Jeśli używasz jakiegoś koszmarnego języka (jak MUMPS) lub jakiegoś żmudnego języka (jak TCL), myślę, że należy zadać pytania. Ale myślę, że powinieneś być uważany za faceta, który stara się zachować najlepsze stare tradycje :)

Jest wiele dobrych odpowiedzi, ale chciałbym dodać punkt.

Byłem w podobnej sytuacji, ale z innym językiem. Musiałem nauczyć się wszystkiego na własnej skórze, tj. Metodą prób i błędów z powodu braku wskazówek. To, czego się nauczyłem ”z mojego doświadczenia, jak wskazałeś, konserwacja / rozszerzalność, stałoby się problemem, ponieważ ktoś może nie znać skutecznych metod z powodu braku wskazówek.

Sugeruję, aby porozmawiać ze swoim przełożonym o odpowiednią pomoc, aby uniknąć problemów w przyszłości.

Powodzenia!

W niektórych przypadkach język taki jak Lisp może przyspieszyć lub ułatwić wdrożenie funkcjonalności, która byłaby bardzo trudna w innym języku. Wpływa także na sposób patrzenia na problemy, dając perspektywę, której inni członkowie zespołu mogą nie mieć. Posiadanie szerszego wachlarza możliwości i szerszego widoku tego, co jest możliwe, może być bardzo cenne dla firmy, która jest w stanie je zrozumieć i wykorzystać. Ceną za te możliwości jest jednak brak standaryzacji.

Wiele firm próbuje ustandaryzować jeden lub dwa języki, ponieważ daje im to większą elastyczność organizacyjną: mogą przenosić programistów z jednego projektu do drugiego bez konieczności ich przekwalifikowania, mają wbudowaną rezerwę wiedzy o językach, których używają, a menedżerowie nie muszą brać pod uwagę mocnych i słabych stron używania jednego lub drugiego języka dla danego projektu. Kiedy wszystko, co masz, to młotek, wszystko wygląda jak gwóźdź.

Jak wskazałem, oba podejścia mają pewne zalety i wady. Jak to często bywa, nie ma dobrego lub złego podejścia. Po prostu wymieniasz jeden zestaw zalet i wad na inny. Firma też nie musi iść całkowicie w jednym lub drugim kierunku. Większość pracy w C ++ lub Javie jest całkowicie rozsądna, ale od czasu do czasu zanurz palce w Lisp lub Python, aby je wypróbować i zobaczyć, co działa. Wygląda na to, że to właśnie robi Twoja firma.

Więc idź dalej (ale nie dalej), dowiedz się jak najwięcej i zostań ekspertem Clojure, na którym twój menedżer może polegać na wglądu, którego Twoi koledzy mogą nie mieć. I nie przejmuj się tym ... martwienie się o sprawy organizacyjne to praca twoich menedżerów.

Polecam rozpocząć przepisywanie programu w innym (wygodniejszym) języku, gdy zaczniesz czuć, że utrzymanie ma duże szanse na dominację.

Jeśli udało Ci się napisać go w zamknięciu (czego nie wiedziałem, kiedy zacząłeś tworzyć swoją aplikację, jak zrozumiałem), to bez problemu przepisanie jej przy użyciu bardziej znanego / wygodnego języka. Zamknięcie używa zupełnie innych pojęć, dlatego wdrożenie może być trudne do przeniesienia na inny język. Chodzi o to, że jeśli dobrze się bawiłeś pisząc nową aplikację w zamknięciu, może być interesujące przeniesienie użytych koncepcji i pomysłów na inny wygodny język. Porównanie różnych języków i ich możliwości może być zabawne. Myślę, że twój przypadek jest idealny do takich eksperymentów.

Z pewnością programowanie w „niepopularnych” językach nie jest niczym złym. Dlaczego tak naprawdę obchodzi Cię, czy są popularne, czy nie? W pełni zgadzam się z @ quanticle w tej sprawie. Jeśli Clojure lub inny język nie będący głównym nurtem jest najlepszym narzędziem do rozwiązania problemu, powinieneś go wybrać.

Nie rozumiem, dlaczego utrzymanie będzie problemem. Jeśli zastosujesz jednostkę, integrację itp. Testowanie i udokumentowanie kodu, każdy programista zainteresowany programowaniem funkcjonalnym będzie w stanie utrzymać Twój program. IMHO fakt, że twoi koledzy nie dbają o Clojure, nie jest dobrym argumentem za nieużywaniem go, z wyjątkiem sytuacji, gdy jest to polityka firmy, której musisz przestrzegać.

Moim zdaniem to, czy program będzie kontynuowany po twoim odejściu, nie dotyczy ciebie. Możesz użyć języka programowania, aby stworzyć coś, co lubi twój szef, dla mnie brzmi całkiem nieźle. Martwienie się o kontynuację to coś, co powinien zrobić szef.

Zorganizuj samouczek lub sesję szkoleniową. Jeśli członkowie Twojego zespołu nie chcą zachowywać się jak profesjonaliści i poszerzać swoją wiedzę, zwłaszcza jeśli program staje się ważniejszy, niż wymyka się on z rąk. W najgorszym przypadku możesz porozmawiać z zarządem, który może zlecić tego rodzaju szkolenie. Możesz wyglądać jak palant, ale przynajmniej nie będziesz jedynym, który będzie musiał utrzymywać program. Inną opcją jest zasugerowanie, aby do zespołu został dodany drugi programista, który zna clojure.