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

Я недавно работаю в качестве единственного «Инженера SW» в довольно небольшом магазине ученых, которые провели последние 10-20 лет, собирая обширную базу кода. (Он был написан практически на устаревшем языке: G2 - подумайте на Паскале с графикой). Сама программа представляет собой физическую модель комплекса химической обработки; Команда, которая написала это, обладает невероятно глубокими знаниями в области, но мало или совсем не имеет формального обучения основам программирования. Недавно они усвоили некоторые тяжелые уроки о последствиях несуществующего управления конфигурацией. Их усилиям по обслуживанию также сильно мешает огромное накопление недокументированного «шлама» в самом коде. Я избавлю вас от "политики" ситуации ( всегда есть политика!), но достаточно сказать, что нет единого мнения о том, что необходимо для дальнейшего пути.

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

Вначале я склонен обучать их некоторым из основных понятий Прагматического Программиста или Рефакторинга Фаулера («Запахи кода» и т. Д.). Я также надеюсь представить ряд гибких методологий. Но в конечном счете, чтобы быть эффективным, я думаю, что мне нужно оттачивать 5-7 основных принципов; Другими словами, каковы наиболее важные принципы или практики, которые они могут реально начать применять, которые дадут им наибольшую отдачу от обязательств.

Итак, вот мой вопрос: что бы вы включили в свой список наиболее эффективных стратегий, чтобы помочь распрямить спагетти (и предотвратить это в будущем)?

предисловие

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

Помните: это руководящие принципы , и как таковые они предназначены для принятия, адаптации или исключения в зависимости от обстоятельств.

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

Примечание: не все это относится непосредственно к системам визуального программирования, таким как G2. Для более подробной информации о том, как с этим справиться, смотрите раздел Дополнение в конце.

Резюме для нетерпеливых

• Определить жесткую структуру проекта с помощью:
  • шаблоны проектов ,
  • соглашения по кодированию ,
  • знакомые системы сборки ,
  • и наборы руководств по использованию вашей инфраструктуры и инструментов.
• Установите хороший SCM и убедитесь, что они знают, как его использовать.
• Укажите им хорошие IDE для своей технологии и убедитесь, что они знают, как их использовать.
• Внедрить средства проверки качества кода и автоматические отчеты в системе сборки.
• Соедините систему сборки с системами непрерывной интеграции и непрерывного контроля .
• С помощью вышеперечисленного определите качество кода «горячих точек» и рефакторинг .

Теперь для длинной версии ... Осторожно, приготовьтесь!

Жесткость (часто) хороша

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

Жесткость = Процесс / Процедура .

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

Жесткость приходит в умеренности, хотя!

Жесткость структуры проекта

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

Жесткость систем сборки

Если каждый проект выглядит по- разному, есть большая вероятность, что они также строятся по-разному . Сборка не должна требовать слишком много исследований или слишком много догадок. Вы хотите быть в состоянии сделать каноническую вещь и не нужно беспокоиться о специфике: configure; make install, ant, mvn install, и т.д. ...

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

Вам нужно быстро READMEуказать специфику проекта и изящно направить пользователя / разработчика / исследователя, если таковой имеется.

Это также значительно облегчает другие части вашей инфраструктуры сборки, а именно:

• постоянная интеграция ,
• постоянный осмотр .

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

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

Рекомендуемое чтение:

• Непрерывная интеграция: повышение качества программного обеспечения и снижение рисков (Дюваль, Матиас, Гловер, 2007)
• Непрерывная доставка: Выпуск Sotware Releases с помощью автоматизации сборки, тестирования и развертывания (Humble, Farley, 2010)

Жесткость в выборе языков программирования

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

Сохраняйте свой технический стек простым, а обслуживание и широту необходимых навыков - как минимум: сильное ядро.

Жесткость кодирования конвенций и руководящих принципов

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

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

• хорошо продуманный набор основных правил устраняет многие жалобы и размышления: никто не должен сломаться ни при каких обстоятельствах;

• и набор рекомендуемых правил обеспечивает дополнительное руководство.

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

Некоторые языки даже применяют это в дизайне:

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

• Блочная структура Python с отступом - еще одна идея в этом смысле.

• Go, с его gofmtинструментом, который полностью отнимает любые споры и усилия ( и эго! ), Присущие стилю: беги, gofmtпрежде чем совершить.

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

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

Жесткость документации

Документация идет рука об руку с кодом. Сам код является документацией. Но должны быть четкие инструкции о том, как создавать, использовать и поддерживать вещи.

Использование единой точки контроля для документации (например, WikiWiki или DMS) - это хорошо. Создайте места для проектов, места для более случайного подшучивания и экспериментов. Пусть во всех пробелах используются общие правила и соглашения. Попробуйте сделать это частью командного духа.

Большая часть рекомендаций, относящихся к коду и инструментам, также относится и к документации.

Жесткость в комментариях к коду

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

Жесткость в журналах коммитов

Журналы коммитов не являются раздражающим и бесполезным «шагом» жизненного цикла вашего SCM: вы НЕ пропускаете его, чтобы вернуться домой вовремя или приступить к следующему заданию, или догнать приятелей, которые ушли на обед. Они имеют значение, и, как (большинство) хорошее вино, чем больше времени проходит, тем ценнее они становятся. Так что делай их правильно. Я поражен, когда вижу, как коллеги пишут однострочники для гигантских коммитов или для неочевидных хаков.

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

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

Почему я обновил эту строку? -> Потому что интерфейс изменился.

Почему интерфейс изменился? -> Потому что библиотека L1, определяющая его, была обновлена.

Почему была обновлена ​​библиотека? -> Поскольку библиотека L2, которая нам нужна для функции F, зависит от библиотеки L1.

А что за черта Х? -> См. Задачу 3456 в трекере проблем.

Это не мой выбор SCM, и, возможно, не лучший для вашей лаборатории; но Gitпонимает это правильно и пытается заставить вас писать хорошие журналы больше, чем большинство других систем SCM, используя short logsи long logs. Свяжите идентификатор задачи (да, он вам нужен) и оставьте общее резюме для shortlog, и разверните в длинном журнале: напишите историю изменений .

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

Полезное правило. Если вы позднее что-то искали об этом изменении, вероятно, ваш журнал ответит на ваш вопрос?

Проекты, Документация и Кодекс ЖИВЫ

Держите их в синхронизации, иначе они больше не образуют эту симбиотическую сущность. Он творит чудеса, когда у вас есть:

• очистить журналы коммитов в вашем SCM, со ссылками на идентификаторы задач в вашем трекере,
• где сами билеты этого трекера ссылаются на наборы изменений в вашем SCM (и, возможно, на сборки в вашей системе CI),
• и система документации, которая ссылается на все это.

Код и документация должны быть связными .

Жесткость в тестировании

Эмпирические правила:

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

Конечно, это нужно:

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

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

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

Жесткость в использовании инструментов

Это нормально для случайного разработчика / ученого, желающего попробовать какую-нибудь новую статическую проверку источника, сгенерировать график или модель, используя другой, или внедрить новый модуль, используя DSL. Но лучше всего, если есть канонический набор инструментов, который все члены команды должны знать и использовать.

Кроме того, пусть члены используют то, что они хотят, если они ВСЕ:

• продуктивный ,
• НЕ требует регулярной помощи
• НЕ регулярно приспосабливаясь к вашей общей инфраструктуре ,
• НЕ разрушая вашу инфраструктуру (изменяя общие области, такие как код, система сборки, документация ...),
• НЕ влияет на работу других ,
• Умеет своевременно выполнять любую задачу по запросу .

Если это не так, то принудите их вернуться к значениям по умолчанию.

Жесткость против универсальности, адаптивности, прототипирования и чрезвычайных ситуаций

Гибкость может быть хорошей. Позволить кому - то иногда использовать хак, быстро-н-грязный подход, или любимый инструмент для домашних животных , чтобы получить работу в порядке. НИКОГДА не позволяйте этому стать привычкой, и НИКОГДА не позволяйте этому коду становиться фактической базой кода для поддержки.

Вопросы командного духа

Развивайте чувство гордости в своей кодовой базе

• Развивайте чувство гордости за код
  • Используйте настенные панели
    • таблица лидеров для непрерывной интеграции игры
    • настенные панели для управления проблемами и подсчета дефектов
  • Используйте систему отслеживания проблем / ошибок

Избегайте обвинительных игр

• НЕОБХОДИМО использовать игры «Непрерывная интеграция» и «Непрерывная инспекция»: это способствует хорошей и продуктивной конкуренции .
• Следите за дефектами: это просто хорошая уборка.
• ДЕЙСТВУЙТЕ выявление первопричин : это просто процессы будущего.
• НО НЕ возлагайте вину : это контрпродуктивно.

Речь идет о кодексе, а не о разработчиках

Заставьте разработчиков осознавать качество своего кода, НО заставьте их воспринимать код как отдельную сущность, а не как расширение себя, которое нельзя критиковать.

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

От ученого до программиста

Люди, которые не ценят и не гордятся кодом, не производят хороший код. Чтобы это свойство появилось, им нужно выяснить, насколько ценным и интересным оно может быть. Одного профессионализма и желания делать добро недостаточно: для этого нужна страсть. Поэтому вам нужно превратить своих ученых в программистов (в широком смысле).

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

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

Ведение кода является частью исследовательской работы

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

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

Почему все это??!

Почему мы беспокоимся обо всем вышеперечисленном? Для качества кода . Или это качественный код ...?

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

Как узнать, когда цель достижима?

Качество измеримо

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

Есть отличные инструменты для постоянного осмотра . Сонар является популярным в мире Java, но он может адаптироваться к любым технологиям; и есть много других. Держите свой код под микроскопом и ищите этих надоедливых жучков и микробов.

Но что, если мой код уже дерьмо?

Все вышеперечисленное - это весело и мило, как поездка в Never Land, но это не так легко сделать, когда у вас уже есть (куча парных и вонючих) дерьмовых кодов, и команда не хочет меняться.

Вот секрет: вам нужно с чего-то начать .

Личный анекдот: В проекте мы работали с базой кода, изначально весившей 650 000+ Java LOC, 200 000+ строк JSP, 40 000+ JavaScript LOC и 400+ МБ двоичных зависимостей.

Примерно через 18 месяцев это 500 000 Java LOC (MOSTLY CLEAN) , 150 000 строк JSP и 38 000 JavaScript LOC, с зависимостями до 100 МБ (а их больше нет в нашей SCM!).

Как мы это сделали? Мы только что сделали все вышеперечисленное. Или старался.

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

Были некоторые большие «работы» ... Одним из них было переключение нашей системы сборки с гигантской сборки Ant из 8500+ XML LOC на многомодульную сборку Maven. Затем мы имели:

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

Другим было внедрение «поясов утилит», хотя мы пытались уменьшить зависимости: Google Guava и Apache Commons уменьшают ваш код и значительно уменьшают количество ошибок в вашем коде.

Мы также убедили наш ИТ-отдел, что, возможно, использование наших новых инструментов (JIRA, Fisheye, Crucible, Confluence, Jenkins) было лучше, чем имеющиеся на месте. Нам все еще нужно было иметь дело с некоторыми из тех, кого мы презирали (QC, Sharepoint и SupportWorks ...), но это был общий улучшенный опыт, оставив еще немного места.

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

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

Сверхсекретный инкрементный цикл рефакторинга кода спагетти для потрясающего качества

       +-----------------+      +-----------------+
       |  A N A L Y Z E  +----->| I D E N T I F Y |
       +-----------------+      +---------+-------+
                ^                           |
                |                           v
       +--------+--------+      +-----------------+
       |    C L E A N    +<-----|      F I X      |
       +-----------------+      +-----------------+

Если у вас есть несколько качественных инструментов в вашем наборе инструментов:

1. Проанализируйте свой код с помощью контроллеров качества кода.

   Линтеры, статические анализаторы или что там у вас.

2. Определите ваши критические горячие точки и низко висящие фрукты .

   Нарушения имеют уровни серьезности, и большие классы с большим количеством высокоуровневых классов имеют большой красный флаг: как таковые, они появляются в качестве «горячих точек» на видах радиатора / тепловой карты.

3. Исправьте горячие точки в первую очередь.

   Это максимизирует ваше влияние в короткие сроки, поскольку они имеют наибольшую ценность для бизнеса. В идеале критические нарушения следует устранять, как только они появляются, поскольку они являются потенциальными уязвимостями безопасности или причинами сбоев и представляют высокий риск возникновения ответственности (а в вашем случае - плохой работы лаборатории).

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

   Это улучшает отношение сигнал / шум, так что вы сможете увидеть значительные нарушения на радаре по мере их появления. Вначале часто возникает большая армия мелких нарушений, если о них никогда не позаботились, а ваша кодовая база осталась без внимания. Они не представляют реального «риска», но они ухудшают читабельность и удобство сопровождения кода. Исправляйте их, когда вы встречаете их во время работы над заданием, или с помощью больших квестов с автоматической очисткой кода, если это возможно. Будьте осторожны с большими автоматическими развертками, если у вас нет хорошего набора тестов и системы интеграции. Обязательно договоритесь с коллегами о правильном времени для их запуска, чтобы минимизировать раздражение.

5. Повторяйте, пока не будете удовлетворены.

   Что, в идеале, никогда не должно быть, если это все еще активный продукт: он будет продолжать развиваться.

Быстрые Подсказки для Хорошего Хозяйства

• В режиме исправления на основании запроса поддержки клиентов:

  • Обычно лучше НЕ пытаться решить другие проблемы, так как вы можете неохотно вводить новые.
  • Сделайте это в стиле SEAL: войдите, убейте ошибку, выйдите и отправьте свой патч. Это хирургический и тактический удар.

• Но во всех остальных случаях , если вы открываете файл, сделайте своим долгом:

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

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

Приложение: Управление средами визуального программирования

Стеновые сады на заказ систем программирования

Многочисленные системы программирования, такие как OP G2, - разные звери ...

• Нет исходного кода

  Часто они не дают вам доступа к текстовому представлению вашего исходного «кода»: он может храниться в проприетарном двоичном формате или, возможно, хранит вещи в текстовом формате, но скрывает их от вас. Созданные на заказ системы графического программирования на самом деле не редкость в исследовательских лабораториях, поскольку они упрощают автоматизацию повторяющихся рабочих процессов обработки данных.

• Нет инструментов

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

• Недостаток документации

  Довольно часто это нишевые системы программирования, которые используются в довольно закрытых средах. Люди, которые их используют, часто подписывают NDA и никогда не говорят о том, что они делают. Сообщества программистов для них редки. Так что ресурсов мало. Вы застряли с вашей официальной ссылкой, и это все.

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

Персональный анекдот 2:На самом деле, я работал над одним из них сам. Я не связывал запрос с ОП, но мой проект представлял собой набор взаимосвязанных больших программ для обработки и хранения данных (в основном для исследований в области биоинформатики, здравоохранения и косметики, а также для бизнеса). интеллект или любая область, подразумевающая отслеживание больших объемов исследовательских данных любого рода и подготовку рабочих процессов обработки данных и ETL). Одним из этих приложений была, довольно просто, визуальная среда IDE, в которой использовались обычные функции: интерфейсы перетаскивания, рабочие версии проектов (использование текстовых и XML-файлов для хранения метаданных), множество подключаемых драйверов к разнородным источникам данных и визуальные элементы. Canvas для проектирования конвейеров для обработки данных из N источников данных и, в конце концов, для создания M преобразованных выходных данных, и возможные блестящие визуализации и сложные (и интерактивные) онлайн-отчеты. Ваша типичная система визуального программирования на заказ, страдающая от небольшого синдрома NIH под предлогом разработки системы, адаптированной к потребностям пользователей.

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

Отлично, мы обречены! - Что мы делаем с этим?

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

О версии и хранении

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

Но, тем не менее, если они предоставляют такую ​​функциональность, возможно, ваше решение состоит в том, чтобы следовать нашим любимым отраслевым стандартам, приведенным выше, и перенести их в эту систему программирования !!

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

О тестировании

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

Конечно, это хакерская работа и определенно не соответствует стандарту того, что является обычным для «нормального» программирования, но идея состоит в том, чтобы адаптироваться к системе, пытаясь сохранить видимость профессионального процесса разработки программного обеспечения.

Дорога длинная и крутая ...

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

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

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

К сожалению, это подразумевает, что вам, возможно, придется погрузиться и проделать огромную работу. Так...

Известные последние слова и смиренные просьбы:

• Документируйте все, что вы делаете.
• Поделитесь своим опытом.
• Open Source любой инструмент, который вы пишете.

Делая все это, вы будете:

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

Кто знает, может быть в самом начале нового энергичного сообщества Obscure языка X . Если их нет, начните!

• Задавайте вопросы о переполнении стека ,
• Может быть, даже написать предложение для нового сайта StackExchange в области 51 .

Может быть, внутри красиво , но пока никто не догадывается , так что помогите снять эту уродливую стену и пусть другие заглянут!

Самым первым шагом будет внедрение системы контроля версий (SVN, Git, Mercurial, TFS и т. Д.). Это должно иметь место для проекта, который будет иметь рефакторинг.

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

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

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

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

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

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

Я считаю, что они очень умные люди, но для того, чтобы стать хорошим разработчиком, требуется много времени. Готовы ли они проводить так много времени в деятельности, которая не является их основным бизнесом? ИМХО, это не способ добиться лучших результатов.

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

• Прежде всего: расставьте приоритеты . Чего вы хотите достичь в первую очередь? Что является наиболее важным для текущего состояния проекта? Что вы получите больше всего от того, сколько времени потребуется, чтобы добраться туда.
• Убедитесь, что у вас есть система контроля версий. Git или Mercurial, например.
• Получите какую-то систему непрерывной интеграции (например, Jenkins ) и работайте.
• Получите систему отслеживания ошибок и работает. Mantis довольно хорош, на мой взгляд.
• Посмотрите на статический анализ кода (если что-то доступно для языка, с которым вы сейчас работаете).
• Постарайтесь достичь как можно большей согласованности во всем, начиная от именования переменных и заканчивая общими соглашениями и рекомендациями по коду в базе кода.
• Получите тестируемую систему . На мой взгляд, это чрезвычайно важно для такой большой устаревшей системы. Используйте тестовые случаи для документирования существующего поведения , независимо от того, кажется ли поведение странным или нет (обычно есть причина, почему код выглядит так: почему, может быть, хорошо или плохо, или оба; P). Michael Feathers эффективно работает с Legacy Code - отличный ресурс для этого.

Они говорят, что первым шагом в решении проблемы является признание того, что она у вас есть. Имея это в виду, вы можете начать с создания графика зависимостей, который иллюстрирует обширную путаницу, которая является вашей текущей кодовой базой. Хороший инструмент для создания диаграммы зависимостей? ему несколько лет, но он содержит некоторые ссылки на инструменты, которые могут помочь в создании таких графиков. Я бы пошел с одним огромным, ужасным графиком, который показывает как можно больше, чтобы понять суть дела. Поговорим о проблемах, возникающих из-за слишком большого числа взаимозависимостей, и, возможно, добавим строку от Бакару Банзая :

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

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

Некоторые вещи, чтобы сосредоточиться на:

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

• Ищите случаи, когда одна и та же функциональность была повторена. Работать в направлении объединения.

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

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

или это:

по сравнению с этим, любезно предоставлено 99 бутылок пива :

beer-bottles()

i:integer =99;
j:integer;
constant:integer =-1;

begin
for i=99 down to 1
    do
    j = (i+constant);
        if (i=1) then begin
            post"[i] bottle of beer on the wall";
            post" [i] bottle of beer";
            post" Take one down and pass it around ";
            post" No bottle of beer on the wall"; 
        end 
        else begin
            post"[i] bottles of beer on the wall";
            post" [i] bottles of beer";
            post" Take one down and pass it around ";
            if (i=2) then 
                post" [j] bottle of beer on the wall"
           else
                post" [j] bottles of beer on the wall"; 
           end
    end
end

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

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

Хотя очевидно, что вашим первым приоритетом будет получение какого-то контроля версий в Интернете, как отметил ЭльЮсубов , и похоже, что контроль версий поддерживается начиная с версии 8.3 . Поскольку G2 представляет собой комбинацию из пары разных языковых методологий, вы, вероятно, сочтете наиболее эффективным использовать прилагаемый к нему элемент управления версиями, а не пытаться найти что-то еще и заставить его работать.

Далее, хотя некоторые, скорее всего, выступят за то, чтобы начать рефакторинг, я решительно рекомендую убедиться, что вы полностью понимаете систему, с которой работаете, прежде чем приступать к прикосновению к какому-либо коду, особенно при работе с кодом и визуальными диаграммами, разработанными разработчики без формального обучения (или фона) в методологии разработки программного обеспечения. Это объясняется несколькими причинами, но наиболее очевидная причина заключается в том, что вы работаете с приложением, в которое потенциально может быть вложено более 100 человеко-лет работы, и вам действительно необходимо убедиться, что вы знаете, что оно делает и сколько в нем есть документация Поскольку вы не сказали, в какой отрасли развернута система, Исходя из того, что я читал о G2, можно с уверенностью предположить, что это, скорее всего, критически важное приложение, которое может даже иметь потенциальные последствия для безопасности жизнедеятельности. Таким образом, понимание того, что он делает, будет очень важным. Если есть код, который не документирован, он работает с другими членами команды, чтобы обеспечить создание документации, чтобы люди могли определить, что делает код.

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

Как только у вас есть модульные тесты для достаточного количества кода, вы можете начать приближаться к рефакторингу таким образом, как это предложено haylem ; однако помните, что вы имеете дело с чем-то, что предназначено для разработки экспертных систем, и рефакторинг может оказаться непростым делом. Это на самом деле среда, в которой есть что сказать, чтобы не писать очень общий код время от времени.

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

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

Трудно понять код? Проверьте. Массивная кодовая база? Проверьте.

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

Вот что я хотел бы решить по порядку:

1. Резервные копии, как серверной, так и локальной версии
2. Настройте трекер ошибок
3. Настройка системы управления версиями
4. Настройка FAQ / Wiki
5. Первый разбор всех ученых / программистов
   • Напомните им о правиле 80/20. 20% ошибок ответственны за 80% проблем.
   • Сосредоточьтесь на самых больших проблемах и держите запросы на улучшение и прочее.
   • Цель здесь не в том, чтобы напугать людей большим списком, а в списке небольших достижимых побед. В конце концов, вы также должны доказать свою ценность.
6. Настройте систему сборки
   • Начните работать над получением надежных сборок (это может занять некоторое время)
   • определить и назвать каждый проект
   • выявить циклические зависимости
   • если есть бинарные файлы из некоторых проектов с открытым исходным кодом, попробуйте получить источники
7. Определите, как код G2 может быть модульным, например, API, сервисы
8. Определите, как код G2 может быть протестирован, задокументирован.
9. Настроить систему проверки кода
10. Второй отчет
    • Как выглядит идеальный модуль?
    • Как оцепить старый код
    • Как обернуть новый модуль вокруг старого кода (см. Шаблон Strangler http://agilefromthegroundup.blogspot.com.au/2011/03/strangulation-pattern-of-choice-for.html )
11. Определите отличную команду лучших программистов и поработайте с ними, чтобы обернуть их модули.
12. На этом этапе проводятся проверки кода для улучшения связи и документирования. Сохраняйте это легко на этом этапе. Разберитесь с любыми проблемами процесса.
13. Разверните систему другим программистам. Пусть члены кряковой команды станут равными наставниками для остальных. Помните, что проблема масштабирования здесь. Вы эффективно в роли управления.

Подобные вопросы и являются причиной того, что проект Software Carpentry существует.

Последние 14 лет мы учим ученых и инженеров основным навыкам разработки программного обеспечения: контролю версий, тестированию, модуляции кода и т. Д. Все наши материалы свободно доступны по лицензии Creative Commons, и мы проводим пару десятков бесплатных двухдневных семинаров каждый год, чтобы помочь людям начать работу.

Исходя из этого, я думаю, что лучшей отправной точкой, вероятно, является превосходная (короткая) книга Роберта Глаза « Факты и ошибки разработки программного обеспечения» : его основанный на фактических данных подход является хорошим способом убедить ученых в том, что то, что мы говорим им о хороших практиках программирования, больше, чем просто мнение.
Что касается конкретных практик, то два, которые люди больше всего хотят принять, это контроль версий и модульное тестирование; как только они будут созданы, они могут заняться систематическим рефакторингом, который Майкл Фезерс описывает в « Эффективной работе с устаревшим кодом» .
Я больше не рекомендую Прагматичного Программиста (много наставлений, трудно для новичков на практике), и я думаю, что код McConnell завершен это слишком много, чтобы начать с него (хотя было бы здорово дать им шесть месяцев или год после того, как они освоили основы).

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

Я думаю, что в первую очередь вы должны прояснить ситуацию. Что они хотят от вас?

• Маловероятно, что они хотят, чтобы вы выучили древний язык, потому что теперь это кажется тупиком: существует все меньше шансов найти кого-то, кто знает или хочет изучать G2, поэтому знания будут похоронены в куче кода, когда текущие ученые уходят, или все исправленный код выходит из строя все чаще и чаще.
• Готовы ли ученые (или некоторые из них) выучить новый язык и множество парадигм программирования? Или они хотят разделить программирование и научную деятельность в долгосрочной перспективе, и, возможно, при необходимости иметь еще несколько программистов? Это кажется рациональным и более эффективным разделением опыта.

Я думаю, что основное требование здесь - «сохранить знания в системе», так что вам нужно идти и раскопать их!

Первая задача - написать документацию.

Проанализируйте структуру и требования, как если бы это была новая задача, но с помощью существующей системы. Они будут рады, потому что вы спрашиваете, а не УЧИТЕ в первую очередь - и вы быстро получите достаточно, но более организованные базовые знания с точки зрения программиста: «что здесь происходит?» Документы (статическая структура системы, рабочий процесс, компоненты, проблемы) будут сразу же полезны для них и, возможно, будут отображать для них более релевантную информацию, чем для вас (у некоторых из них может быть «AHA!» И сразу же начать исправлять некоторые коды). ) ...

Затем вы должны начать спрашивать, куда они хотят пойти?

Если они готовы отойти от G2какую систему они хотят видеть (платформу, язык, интерфейс, общую структуру)? Вы могли бы начать писать внешнюю оболочку вокруг системы, если это вообще возможно, имея целевую структуру, но сохраняя оригинальные компоненты, таким образом, медленно запуская своего рода структуру, которая позволяет внедрять новые компоненты в этой целевой среде. Вы должны найти основные сервисы (постоянные подключения к данным и «наборы инструментов»: базовые вычисления, рисование, ... библиотеки), и поэтому вы предоставляете им знакомую среду на новой платформе и языке, которые позволяют переход либо вам, либо их: возьмите старые коды один за другим, переопределите (и ОЧИСТИТЕ!) их в новой среде. Когда это будет готово, они знают новый язык; и сервисный уровень (в основном сделанный вами, извините) готов к размещению новых компонентов.

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

При анализе и написании документов читайте, используйте и рекламируйте шаблоны GoF Design! :-)

... мои 2 цента

Я только что закончил делать серию презентаций о принципах SOLID Роберта Мартина для моих коллег. Я не знаю, насколько хорошо эти принципы переводятся на G2, но так как вы ищете 5-7 основных принципов, они кажутся хорошо устоявшимися. Если вы хотите округлить его до 7, вы можете начать с DRY и добавить Fail-Fast.

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

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

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

Наиболее важные принципы работы в такой ситуации:

1. Потерпи. Яма, на которую ушло 20 лет, не будет заполнена через несколько недель.

2. Быть положительным. Не поддавайтесь искушению жаловаться и ворчать.

3. Будьте прагматичны. Посмотрите на позитивные изменения, которые вы можете достичь за один день, и сделайте это сегодня. У вас еще есть система контроля версий? Реализуйте это и обучайте людей. Затем посмотрите, сможете ли вы автоматизировать тестирование (модульное тестирование или что-то подобное). Полоскание. Повторение.

4. Будь моделью. Покажите (не просто рассказывайте) людям, как гибко работает, будучи гибким. Первые три пункта выше являются ключами к тому, чтобы быть хорошим парнем, который предшествует тому, чтобы быть эффективным проворным парнем. На мой взгляд, люди, которые являются замечательными разработчиками, не только умны, но и хороши, моделируют сотрудников и коллег.

5. Карта вашей территории. У меня есть техника для отображения гигантских устаревших кодовых баз. Я клонирую репо, делаю рабочую копию, а затем пытаюсь что-то изменить, и вижу, что еще ломается. Изучая связь (из-за глобального состояния или из-за неработающих API, или из-за отсутствия согласованного API, или из-за каких-либо абстракций или интерфейсов для программирования) и читая код, который ломается, когда я что-то изменяю, я обнаруживаю бессмысленность и задаю вопросы, которые приводят к идеи от остальной части команды (О, мы добавили, что, поскольку Босс X 5 лет назад потребовал, это никогда не работало!). Со временем вы получите ментальную карту территории. Как только вы узнаете, насколько он велик, вы узнаете достаточно, чтобы составить карту и добраться до дома. Поощряйте других наносить на карту территорию вашей гигантской кодовой базы и приобретать технические знания команды. Некоторые люди возражают против «документации» потому что это не ловко. Без разницы. Я тоже работаю в научной среде, и для меня важна документация, проклятые проворные манифесты.

6. Создавайте маленькие приложения. Работая с унаследованной кодовой базой, я обнаружил, что у меня все получается. Я возвращаю дух, создавая маленькие вспомогательные приложения. Возможно, эти приложения помогут вам прочитать, понять и изменить эту гигантскую кодовую базу G2. Может быть, вы можете сделать мини IDE или инструмент парсера, который поможет вам работать в вашей среде. Во многих случаях метапрограммирование и создание инструментов не только помогут вам вырваться из гигантских тупиков, которые навязывают вам унаследованные кодовые базы, но и дадут вашему мозгу возможность неограниченно летать на языке G2. Напишите свои инструменты и помощники на любом языке, на котором вы сможете сделать их быстрее и эффективнее. Для меня эти языки включают Python и Delphi. Если вы Perl или действительно любите программировать на C ++ или C #, напишите свои вспомогательные инструменты на этом языке.

1. Управление ревизиями : показать экспертам по доменам выгоду от возможности вернуться, посмотреть, кто что изменил и т. Д. (Это сложнее с бинарными файлами, но если содержимое действительно является кодом, то, безусловно, существует какой-то тип G2-to- текстовый конвертер, который может включать различия.)

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

3. Преобразуйте общий код в повторно используемые подпрограммы и компоненты. Люди, не занимающиеся программным обеспечением и не имеющие контроля версий, вероятно, копируют и вставляют сотни строк за раз, чтобы создавать процедуры. Найдите их и проведите рефакторинг, показывая, что все тесты пройдены и код стал короче. Это также поможет вам узнать его архитектуру. Если вам повезет, когда вы начнете принимать сложные архитектурные решения, возможно, вам не хватает 100KLOC.

С политической точки зрения , если вы встретите сопротивление старожилов в этом процессе, пригласите консультанта, который придет и расскажет о хорошей методологии программного обеспечения. Убедитесь, что вы нашли подходящего человека, с мнением которого вы согласны, и попросите руководство окупить необходимость консультанта, даже если эксперты по предметной области этого не делают. (Они должны согласиться - в конце концов, они вас наняли, так что, очевидно, они понимают, что им нужен опыт разработки программного обеспечения.) Конечно, это тратя деньги, но причина в том, что если вы - начинающий программист - говорите им нужно что-то сделать, они могут игнорировать это. Но если руководство заплатит консультанту 5000 долларов, чтобы он пришел и сказал им, что им нужно делать, они поверит в это. Бонусные очки: попросите консультанта посоветовать в два раза больше изменений, чем вы действительно хотите, тогда вы можете быть «хорошим парнем» и поддержать экспертов по предметной области, компрометируя лишь половину изменений, предложенных консультантом.

«Сама программа представляет собой физическую модель комплекса химической обработки ...»

«Поскольку G2 подобен не-коду, а скорее автоматизированному коду, написанному неким гадким графическим интерфейсом ...» - Эрик Реппен

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

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

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

В вашей отрасли широко используются три коммерческих пакета: gPROMS, Aspen Custom Modeller, и (если в ваших моделях нет явлений, распределенных по пространственным областям) существуют пакеты программного обеспечения на основе Modelica, такие как Dymola.

Все эти пакеты так или иначе поддерживают «расширения», так что если у вас есть части ваших моделей, требующие пользовательского программирования, они могут быть инкапсулированы в объект (например, .DLL), на который могут ссылаться уравнения в модель. Между тем основная часть вашей модели остается краткой, описанной в форме, легко читаемой учеными. Это гораздо лучший способ получить знания и информацию о вашей компании.

Большинство из этих программ также должны позволять вам «начинать с малого» и переносить небольшие части (подмодели) вашего монолитного кода в их формат, вызывая их извне. Это может быть хорошим способом поддержания работающей системы и проверки ее по одной части за раз.

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

Таким образом, я могу с некоторым опытом сказать, что некоторые ключевые решения, которые были сделаны на ранних этапах разработки программного обеспечения (например, язык или библиотека ключей), имеют тенденцию оставаться на месте и причинять боль в течение длительного времени ... Они уже «сформировали» Программное обеспечение вокруг них. Для меня это звучит так, как будто вы можете столкнуться со многими годами чистой очистки кода здесь. (Я не решаюсь использовать числа, но я думаю, что 10+ человеко-лет, может быть, гораздо больше, если вы не можете перенести код, перенесенный из G2, на что-то, что поддерживает хорошие инструменты автоматического рефакторинга, такие как Eclipse / Java quick-smart.)

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

Чтобы дать некоторую перспективу, вы можете быть очень удивлены уменьшением размера. Например, 200 000 LoC могут быть представлены в виде примерно 5000 строк уравнений (хорошо, я думаю, здесь, но я мог бы попытаться получить реальный отзыв от друзей в бизнесе); плюс несколько относительно небольших функциональных модулей, написанных на что-то вроде C (например, вычисления физических свойств - хотя опять-таки готовые пакеты могут существовать в зависимости от вашего химического процесса). Это потому, что вы буквально просто отбрасываете код алгоритмического решения и позволяете «стеку» математических решателей общего назначения выполнять тяжелую работу. После запуска симуляций вы можете делать с ними гораздо больше, например, оптимизировать процесс - без изменения строки кода.

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

Наконец, поскольку мой ответ может быть неуместным, я просто хотел бы добавить еще одну книгу в список хороших книг, которые уже упоминались здесь: «Чистый код» Роберта Мартина. Полный простых (и оправданных) советов, которые легко выучить и применить, но которые могут иметь огромное значение для людей, разрабатывающих новый код в вашей компании.

Я бы бросил следующее:

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

2. Ученые пишут / тестируют алгоритмы. Ученые, которые хотят, могут написать свои собственные алгоритмы на 1-3 языках, с которыми все могут договориться, чтобы вы перешли на основной код. Это ставит тестирование их вещей на них. Кроме того, им придется помочь вам изолировать важные научные достижения от того, что бог знает, что они сделали для архитектуры. Кодовая база хранится. Есть много слэша и ожога, которые нужно будет сделать. Дайте им варианты передать вам рабочие версии материала, в котором используется то, что они знают лучше всего, чтобы вы могли делать то, что вы делаете лучше всего. Положите свои знания в коробку, за которую они несут ответственность, но с которой вы можете работать.

3. Если возможно, используйте язык, ориентированный на события, с функциями первого класса. Когда все остальное терпит неудачу, запуск события или сброс обратного вызова к некоторому объекту с интерфейсом и механизмом состояний, который действительно имеет смысл, может значительно сэкономить время, когда вы по колено в коде, который не имеет никакого кровавого смысла и, возможно, никогда будем. Ученым, кажется, нравится Питон. С этим не сложно склеить математику С с более низким уровнем математики. Просто говорю'

4. Ищите кого-то, кто решил эту или подобную проблему. Потратьте некоторое серьезное время на исследование. Эти парни слышали о G2 от кого-то.

5. Шаблоны проектирования. Адаптеры. Используйте их. Используйте их много в таких ситуациях.

6. Узнайте, что вы можете из науки. Чем больше вы знаете, тем лучше вы можете определить намерение в коде.

Сделайте анализ в первую очередь.

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

Вносить только несколько изменений за раз (в подобной ситуации я делал 2-3 практики каждые 2 недели) .

Я бы ограничил практики до ~ 3 в зависимости от уровня изменения там стиля программирования SDLC; до тех пор, пока им не станет комфортно с ними (я буду настаивать на том, чтобы вводить 1 новое изменение каждые ~ 1-2 недели, поскольку им становится удобнее изучать новые подходы). Это также хорошая идея, чтобы определить критерии успеха. Чего должна достичь практика (даже если это мягкая цель, такая как командный дух). Таким образом, вы можете показать, эффективно это или нет.

• Зачем ограничивать количество изменений?

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

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

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

Определенные практики имеют приоритет.

Правильное использование системы контроля версий (IMO) превосходит все остальное. Рядом находятся уроки модульности, связи / сплоченности и отслеживания функций / ошибок.

Удалить практики, которые не работают.

Не бойтесь избавиться от практики, которая не работает. Если есть высокая стоимость и мало пользы, откажитесь от практики.

Улучшение - это процесс.

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

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

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

Например, два разработчика имели разные копии и в итоге развернули гибридный непроверенный выпуск -> Введение в управление версиями, ветвление и тестирование.

Кто-то удалил несколько строк кода, которые они не понимали, и вызвал сбой -> ввести DDD.

Если тяжелые уроки не передаются вам достаточно подробно, просто покажите свои собственные примеры того, как что-то пошло не так, когда эта дисциплина не была соблюдена.

Контроль исходного кода - это шаг № 1, как уже говорилось много раз. Хотя люди, с которыми вы работаете, могут не быть профессиональными разработчиками, и они не будут реагировать на большую корпоративную или гибкую игру. Они также не низкоуровневые обезьяны, и попытка обращаться с ними так, заставляя их делать то, что «по-вашему», не сработает.

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

Пока вы это делаете, найдите другие низко висящие фрукты и исправьте эти проблемы.

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

Удачи!