Проблемы (например, обслуживание) в разработке с непопулярным языком

Я разрабатываю какое-то приложение с clojure (lisp) в моей команде. Он начинается как небольшое приложение. Нет проблем. Но поскольку у него есть функции и расширение области, это становится важной программой.

Я беспокоился об обслуживании или что-то в этом роде. Никто в моей команде не знает clojure или lisp и не интересуется такими языками, как они.

Итак, разве это неправильно делать программирование на непопулярных языках? (для собственного удовольствия?) Должен ли я использовать более популярные языки? (по крайней мере, такой как python)

Я уверен, что покину команду, - не говорю, что я ухожу. :) - никто не поддержал бы это. Эта программа будет уничтожена, а некоторые будут развиваться на другом языке.

Мне очень нравится развиваться с clojure, хотя я столкнулся с тем, что это может быть не для моей команды.

Что вы думаете об этом? Я думаю, что многие программисты, любящие непопулярные языки, касались аналогичной проблемы.

31 голос | спросил Hybrid 7 FebruaryEurope/MoscowbTue, 07 Feb 2012 12:34:12 +0400000000pmTue, 07 Feb 2012 12:34:12 +040012 2012, 12:34:12

13 ответов


22

Я чувствую вашу боль, я хотел бы сделать больше кодирования в функциональном программировании (Haskell выглядит так весело!). Я чувствую, что только что поцарапал поверхность, потому что я еще не использовал ее в бизнес-контексте.

Я бы настоятельно рекомендовал сделать это, хотя . Если вы программируете только на одном языке, вы знаете, что только вы сможете его поддержать. Если вы не хотите иметь дело с каждой проблемой поддержки (даже когда у вас есть другие крайние сроки /приоритеты), то код на языке, который ваша команда знает и может поддерживать. Что происходит, когда что-то ломается, когда вы в отпуске? Что произойдет, если вы хотите получить повышение?

Я бы порекомендовал, чтобы на вашем борту появился хотя бы один член команды. Покажите им некоторые интересные функции языка. С двумя людьми на борту он становится работоспособным, и вы не будете загружены со всей поддержкой.

ответил Tom Squires 7 FebruaryEurope/MoscowbTue, 07 Feb 2012 15:26:16 +0400000000pmTue, 07 Feb 2012 15:26:16 +040012 2012, 15:26:16
17
  

Я уверен, что покину команду, - не говорю, что я ухожу. :) - никто не поддержал бы это.

Возможно, False.

Если программа имеет значение, а управление видит значение, они будут задавать кому-то обучение Clojure и поддерживать его.

Случается постоянно.

  

Эта программа будет уничтожена, а некоторые будут развиваться с другим языком.

Всегда верно. Так зачем беспокоиться об этом?

В конечном итоге все программы должны быть заменены.

ответил S.Lott 7 FebruaryEurope/MoscowbTue, 07 Feb 2012 14:57:04 +0400000000pmTue, 07 Feb 2012 14:57:04 +040012 2012, 14:57:04
10

Я точно в том месте, где вы предполагаете, что ваш преемник находится. Мне было поручено добавить функции в унаследованную программу, которая использовала Clojure и Erlang для выполнения асинхронного поиска и превращения его в программу, которая распределяет асинхронный поиск. Когда я вошел в эту работу, все, что я знал, это Python и Java.

Мой совет вам: использовать лучший инструмент для работы . Если этот инструмент - Clojure, то пусть будет так. Языки программирования не так уж трудно узнать. Хорошо написанный код на языке, который подходит для этой задачи, всегда легче читать, чем код, который пытается сделать то, что не был разработан для этого языка. Ваш преемник будет проще читать чистый Clojure, чем искаженная Java.

ответил quanticle 7 FebruaryEurope/MoscowbTue, 07 Feb 2012 23:00:10 +0400000000pmTue, 07 Feb 2012 23:00:10 +040012 2012, 23:00:10
5

Принятие новых языков или " самостоятельный " язык по какой-либо задаче представляет собой высокий риск в проекте.

Если эта часть системы имеет проблему или эта часть должна быть уволена, вы должны найти программиста, который должен изучить навыки этого языка. В обоих случаях вы потеряли много времени.

В некоторых случаях эта проблема может быть использована для улучшения и разнообразия навыков команды в будущем.

ответил Spirit 7 FebruaryEurope/MoscowbTue, 07 Feb 2012 15:09:33 +0400000000pmTue, 07 Feb 2012 15:09:33 +040012 2012, 15:09:33
4

В настоящее время у Clojure может быть небольшая установленная база (она появилась в 2007 году), но вряд ли она непопулярна - на самом деле это, возможно, самый «горячий» новый язык. Я был бы удивлен, если бы вы не смогли найти других людей, заинтересованных в изучении этого.

В любом случае, нужно ли принимать новый язык, но всегда должно быть решением, основанным на значении для бизнеса . Вы можете обсудить с вашим менеджером следующие строки:

Преимущества принятия Clojure:

  • Более продуктивен, чем другие используемые языки - о чем свидетельствует количество полезных функций, которые вы поставили за небольшой промежуток времени и с меньшим количеством строк кода
  • У нас уже есть одно важное приложение (ваше), написанное на Clojure, поэтому стоит использовать навыки Clojure для его поддержания (вместо того, чтобы делать дорогостоящий переписывание).
  • Использование Clojure будет рассматриваться как инновационное и может быть хорошим способом побудить талантливых разработчиков присоединиться /остаться в компании.

Недостатки принятия Clojure

  • Один дополнительный язык для поддержки
  • Разработчики могут нуждаться в дополнительной подготовке и времени, чтобы ускориться.

Если бы я был менеджером, оценивающим это решение, мне бы, вероятно, хотелось бы, чтобы идея о высокой производительности от Clojure была достаточной, чтобы позволить некоторые ограниченные эксперименты, и отложить решение до тех пор, пока не станет ясно, насколько хорошо команда взялась за это. В этом случае вы, вероятно, должны быть адвокатом, действовать как хороший учитель и помогать другим на борту.

ответил mikera 8 FebruaryEurope/MoscowbWed, 08 Feb 2012 05:34:44 +0400000000amWed, 08 Feb 2012 05:34:44 +040012 2012, 05:34:44
3

Не волнуйтесь, будьте счастливы.

Очевидно, что программа имеет значение, или вы не будете расширять ее. Поздравляем с успешным проектом. Предположительно, вы выбрали Clojure, потому что сделали это сэкономили время и, следовательно, сохранили деньги вашего работодателя. Если бы вы написали его на Java, программа была бы еще сложнее поддерживать. Даже если ваши коллеги могли бы легче понять программу по очереди, смогут ли они поддерживать ее и расширять?

ответил kevin cline 7 FebruaryEurope/MoscowbTue, 07 Feb 2012 20:45:23 +0400000000pmTue, 07 Feb 2012 20:45:23 +040012 2012, 20:45:23
2

Я бы сказал вам больше силы! Лисп - дедушка компьютерных языков и по-прежнему актуальна сегодня; тот факт, что он не так популярен, я думаю, это связано с тем, что у него нет теплых пушистых IDE C # и Java, а основная реализация компилятора в Windows работает только под Cygwin (yuk!). Развитие, похоже, происходит в Emacs, и я думаю, что он лучше работает с Linux или Mac.

Этот конкурс по кодированию был выигран программой Lisp в 2010 году: http://planetwars.aichallenge.org/

Вернемся в тот день, когда они могут отлаживать его вживую примерно с 100 миллионов миль: http: //www.flownet.com/gat/jpl-lisp.html

Вы определенно отказываетесь от красного флага обслуживания, но думайте об этом как о возможности обучения для кого-то другого. Если вы использовали какой-то кошмарный язык (например, MUMPS) или какой-то утомительный язык (например, TCL), я думаю, что вопросы следует задавать. Но я думаю, вы должны считаться парнем, который пытается сохранить лучшие из старых традиций:)

ответил 7 FebruaryEurope/MoscowbTue, 07 Feb 2012 15:21:03 +0400000000pmTue, 07 Feb 2012 15:21:03 +040012 2012, 15:21:03
2

Есть много хороших ответов, но я хотел бы добавить пункт.

Я был в похожей ситуации, но с другим языком. Я должен был изучить все, что было трудно, т. е. методом проб и ошибок из-за отсутствия руководства. То, что я узнал из моего опыта, поскольку вы указали на обслуживание /расширяемость, станет проблемой, поскольку, возможно, зная эффективные подходы из-за отсутствия руководства.

Я предлагаю вам поговорить с вашим менеджером для получения адекватной помощи, чтобы вы могли избежать любых проблем в будущем.

Удачи!

ответил Karthik Sreenivasan 7 FebruaryEurope/MoscowbTue, 07 Feb 2012 18:58:33 +0400000000pmTue, 07 Feb 2012 18:58:33 +040012 2012, 18:58:33
2

В некоторых случаях язык, такой как Lisp, может ускорить или упростить реализацию функций, которые будут очень сложными на другом языке. Это также влияет на то, как вы смотрите на проблемы, давая вам точку зрения, которую другие из вашей команды могут не иметь. Наличие более широкого спектра возможностей и более широкое представление о том, что возможно, могут быть очень ценными для компании, которая может их понять и использовать. Однако ценой для этих возможностей является отсутствие стандартизации.

Многие компании пытаются стандартизировать на одном или двух языках, потому что это дает им большую организационную гибкость: они могут перемещать разработчиков из одного проекта в другой, не переучивая их, у них есть встроенный запас знаний о языках, на которых они использовать, а менеджеры не должны учитывать сильные и слабые стороны использования одного языка или другого для данного проекта. Когда у вас есть молот, все выглядит как гвоздь.

Как я уже сказал, оба подхода имеют определенные преимущества и недостатки. Как это часто бывает, нет правильного или неправильного подхода. Вы просто торгуете одним набором преимуществ и недостатков для другого. Компании не обязательно идти в одном направлении или в другую сторону. Совершенно разумно делать большую часть работы на C ++ или Java, но время от времени проваливайте нос в Lisp или Python, чтобы попробовать их и посмотреть, что работает. Похоже, это может быть то, что делает ваша компания.

Итак, продолжайте (но не Forth), учитесь как можно больше и становитесь экспертом Clojure, которым ваш менеджер может рассчитывать на то, что ваши коллеги могут не иметь. И не чувствуйте себя плохо в этом ... беспокоиться об организационном материале - это ваша работа менеджеров.

ответил Caleb 8 FebruaryEurope/MoscowbWed, 08 Feb 2012 00:18:24 +0400000000amWed, 08 Feb 2012 00:18:24 +040012 2012, 00:18:24
1

Я бы рекомендовал начать переписывать вашу программу на другом (более удобном) языке, когда вы начинаете ощущать, что техническое обслуживание имеет высокие шансы стать доминирующей проблемой.

Если вам удалось написать его в закрытии (который вы не знали, когда приступали к созданию своего приложения, как я понял), тогда нет проблем переписывать его с использованием более привычного /удобного языка. Закрытие использует совершенно разные концепции, и поэтому реализация может быть трудно перевести на другой язык. Но дело в том, что если вам было интересно писать новое приложение в закрытии, то вам может показаться интересным передать концепции и идеи, которые вы использовали на другом удобном языке. Возможно, было бы интересно сравнить разные языки и их возможности. Я думаю, что ваш случай идеально подходит для таких экспериментов.

ответил altern 7 FebruaryEurope/MoscowbTue, 07 Feb 2012 22:02:37 +0400000000pmTue, 07 Feb 2012 22:02:37 +040012 2012, 22:02:37
1

Конечно, неправильно программировать на «непопулярных» языках. Почему вы на самом деле заботитесь, популярны они или нет? Я полностью согласен с @quanticle в этом. Если Clojure или другой не основной язык - лучший инструмент для решения проблемы, вы должны выбрать его.

Я не понимаю, почему обслуживание будет проблемой. Если вы примените Unit, Integration и т. Д. Тестирование и документирование вашего кода, любой программист с интересом к функциональному программированию сможет поддерживать вашу программу. ИМХО, факт, что ваши коллеги не заботятся о Clojure, не является хорошим аргументом в пользу его не использования, за исключением того, что это политика компании, которую вы должны уважать.

ответил sakisk 7 FebruaryEurope/MoscowbTue, 07 Feb 2012 23:42:06 +0400000000pmTue, 07 Feb 2012 23:42:06 +040012 2012, 23:42:06
0

Будет ли программа продолжена после того, как ваш отъезд не будет касаться вас, на мой взгляд. Вы можете использовать язык программирования, чтобы сделать то, что нравится вашему боссу, звучит неплохо для меня. Беспокойство о продолжении - это то, что должен делать ваш босс.

ответил Paul Hiemstra 7 FebruaryEurope/MoscowbTue, 07 Feb 2012 15:10:41 +0400000000pmTue, 07 Feb 2012 15:10:41 +040012 2012, 15:10:41
0

Организуйте учебное пособие или учебную сессию. Если ваши члены команды не хотят действовать как профессионалы и увеличивают свои знания, особенно если программа становится более важной, чем из ваших рук. В худшем случае вы можете поговорить с руководством, и они могут, возможно, поручить такую ​​тренировку. Вы можете выглядеть как рывок, но по крайней мере вы не будете единственным, кто должен поддерживать программу. Другой вариант - предположить, что 2-й программист, который знает clojure, будет добавлен в команду.

ответил Rudolf Olah 17 FebruaryEurope/MoscowbFri, 17 Feb 2012 09:08:53 +0400000000amFri, 17 Feb 2012 09:08:53 +040012 2012, 09:08:53

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132