Я унаследовал 200K строк кода спагетти - что теперь?

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

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

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

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

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

470 голосов | спросил 5 revs, 4 users 61%
kmote
1 Jam1000000amThu, 01 Jan 1970 03:00:00 +030070 1970, 03:00:00

19 ответов


466

Предисловие

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

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

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

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


Резюме для пациента

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  

Личный подход: Я агрессивный, когда дело доходит до кодирования   некоторые говорят даже nazi , потому что я действительно верю в    lingua franca , узнаваемый стиль для моей команды. Когда дерьмовый код   получает зарегистрированный, он выделяется как холодная болячка на лице   Голливудская звезда: она автоматически запускает обзор и действие.   Фактически, я иногда зашел так далеко, чтобы отстаивать   pre-commit hooks, чтобы отклонить несоответствующие коммиты. Как уже упоминалось, это   не должно быть слишком сумасшедшим и мешать производительности: это   должен вести его. Вводите это медленно, особенно на   начало. Но это предпочтительнее, чем тратить столько времени на фиксацию   ошибочный код, который вы не можете решить по реальным проблемам.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  

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

     

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

     

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

     

А что такое функция X? - > См. Задачу 3456 в журнале отслеживания проблем.

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

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

  

Правило большого пальца: Если вы искали что-то об этом   позже, ваш журнал может ответить на ваш вопрос?

Проекты, документация и код ALIVE

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

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

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

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

  

Правила большого пальца:

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

Конечно, это необходимо:

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

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

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

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

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

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

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

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


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

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


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

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

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

Избегать игр с ошибками

  • DO использовать игры Continuous Integration /Continuous Inspection: it способствует хорошему и продуктивной конкуренции .
  • СЛЕДУЙТЕ отслеживать дефекты: это просто хорошая уборка.
  • DO идентификация корневых причин : это просто процессы проверки будущего.
  • НО НЕ назначьте вину : это противодействовать продуктивному.

Это о коде, а не о разработчиках

Заставьте разработчиков осознавать качество своего кода, НО сделать их см. код как отдельный объект, а не расширение сами, что не может бытькритика.

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


От Ученого к Программисту

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

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

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


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

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

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


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

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

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

Откуда вы знаете, когда цель находится в пределах досягаемости?

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

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

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


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

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

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

  

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

     

Примерно через 18 месяцев это 500 000 Java LOC (МОСТЛИ ЧИСТЫЙ) ,   150 000 строк JSP и 38 000 JavaScript LOC с зависимостями   до почти 100 МБ (и это больше не в нашем SCM!).

     

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

     

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

     

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

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

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

     

Мы также убедили наш ИТ-отдел, возможно, используя наши новые инструменты   (JIRA, Fisheye, Crucible, Confluence, Jenkins) был лучше, чем   на месте. Нам все еще нужно иметь дело с некоторыми презираемыми (КК,   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-style: войдите, убейте ошибку, выйдите и отправьте свой патч. Это хирургический и тактический удар.
  • Но для всех остальных случаев , если вы открываете файл, сделайте свой долг:

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

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


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

Уолл-Гарденс в системах программирования на заказ

Несколько систем программирования, таких как G2 OP, являются разными животными ...

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

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

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

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

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

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

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

  

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

     

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Знаменитые последние слова и скромные запросы:

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

Выполняя все это, вы:

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

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

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
101

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

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

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
43

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

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

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
22

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

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
20

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

  • Прежде всего: Приоритет . Что вы хотите достичь первым? Что является самым важным для текущего состояния проекта? Что вы получите от vs, сколько времени потребуется, чтобы добраться туда.
  • Убедитесь, что у вас есть система управления версиями . Git или Mercurial , например.
  • Запустите систему непрерывной интеграции (например, Дженкинс ).
  • Загрузите систему отслеживания ошибок . Mantis , на мой взгляд, довольно приятный.
  • Посмотрите анализ статического кода (если что-то доступно для языка, на котором вы находитесь в настоящее время работает).
  • Постарайтесь достичь как можно большего количества во всем: от присвоения имен переменных до общих условных обозначений кода и рекомендаций в базе кода.
  • Получить тестируемую систему . Это очень важно для большой старой системы, как это, на мой взгляд. Использовать тестовые примеры для документирования существующего поведения , независимо от того, является ли поведение странным или нет (обычно есть причина, почему код выглядит определенным образом, может быть хорошим или плохим, или и то, и другое) , Майкл Перо, работающий эффективно с устаревшим кодом , является отличным ресурсом для этого.
ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
10

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

  

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

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

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

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

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

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
9

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

введите описание изображения здесь>> </p>

<p> или это: </p>

<p> <img src = 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

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

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

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

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

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
9

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

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

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

Вот что я хотел бы сделать, чтобы:

  1. Резервные копии, как серверная, так и локальная версия
  2. Настройка отслеживания ошибок
  3. Настройка системы управления версиями
  4. Настройка FAQ /Wiki
  5. Первый опрос всех ученых /программистов
    • Напомните им правило 80/20. 20% ошибок отвечают за 80% проблем.
    • Сосредоточьтесь на самых больших проблемах и продолжайте запросы на повышение и т. д.
    • Цель здесь - не пугать людей с большим списком, а список небольших достижимых побед. В конце концов, вы также должны доказать свою ценность.
  6. Настройка системы сборки
    • Начните работать над получением надежных сборок (это может занять некоторое время)
    • определить и назвать каждый проект
    • идентифицировать циклические зависимости
    • Если есть двоичные файлы из некоторых проектов с открытым исходным кодом, попробуйте получить источники
  7. Определите, как код G2 может быть модульным, например. API, услуги
  8. Определите, как код G2 может быть протестирован, документирован.
  9. Настройка системы проверки кода
  10. Второй опрос
  11. Определите команду трещины лучших программистов и поработайте с ними, чтобы обернуть свои модули.
  12. На этом этапе просматриваются обзоры кода для улучшения связи и документации. На этом этапе это упростит. Отсортируйте любые проблемы процесса.
  13. Разверните систему другим программистам. Пусть члены команды трещины станут наставниками-сверстниками для остальных. Помните, что масштабирование является проблемой здесь. Вы эффективно управляете ролью.
ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
9

Вопросы, подобные этим, - это вся причина существования проекта Software Carpentry .

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

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

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
7

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

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

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

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

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

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

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

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

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

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
4

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
3

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

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

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
3

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

  1. Будьте терпеливы. Отверстие, которое потребовалось 20 лет, чтобы выкопать, не будет заполнено через несколько недель.

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

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

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

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

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
3
  1. Контроль версий . Покажите экспертам домена, что вы можете вернуться, посмотреть, кто изменил что и т. д. (Это более жестко со всеми двоичными файлами, но если содержимое действительно код, конечно, есть какой-то конвертер G2-to-text, который может включать diff.)

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

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

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
3
  

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

     

«Так как G2 - это не код, а скорее автоматический код, написанный каким-то gadawful GUI ...» - Erik Reppen

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

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

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

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

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

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

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

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

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

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

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


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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
2

Я бы выбрал следующее:

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

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

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

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

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

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
2

Сначала выполните анализ.

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

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

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

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

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

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

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

Некоторые методы имеют приоритет.

Правильное использование системы контроля версий (ИМО) превосходит все остальное. Близко позади - уроки по модуляции, сцеплению /сцеплению и отслеживанию битов объектов /ошибок.

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

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

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

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
0

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

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

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

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

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

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49
0

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

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

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

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

Удачи!

ответил Alexander Torstling 30 Jpm1000000pmThu, 30 Jan 2014 21:48:49 +040014 2014, 21:48:49

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

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

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