Я сподіваюся, що це не надто загальне питання; Я справді міг би скористатися деякими досвідченими порадами.

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

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

Спочатку я схильний навчати їх у деяких центральних концепціях Прагматичного програміста чи Фаулера Рефакторингу ("Код пахне" тощо). Я також сподіваюся запровадити ряд методів Agile. Але в кінцевому підсумку, щоб бути ефективним, я думаю, що мені знадобиться відточити 5-7 основних основ; інакше кажучи, які найважливіші принципи чи практики, які вони реально можуть почати впроваджувати, що дасть їм найбільше "удару за долар".

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

Передмова

Це справді непросте завдання, і є багато ґрунту. Тому я смиренно пропоную це як дещо вичерпне керівництво для вашої команди з покажчиками відповідних інструментів та навчального матеріалу.

Пам’ятайте: Це керівні принципи , і як такі вони мають бути прийняті, адаптовані або відхилені залежно від обставин.

Остерігайтеся: Скинути все це командою відразу, швидше за все, не вдасться. Спробуйте спробувати вишневі елементи, які б найкраще потіли, і вводити їх повільно, по одному.

Примітка: не все це стосується безпосередньо таких систем візуального програмування, як G2. Більш детальну інформацію про те, як вирішити, див. У Додатку в кінці.

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

• Визначте жорстку структуру проекту із:
  • шаблони проектів ,
  • умови кодування ,
  • знайомі системи побудови ,
  • і набори вказівок щодо використання вашої інфраструктури та інструментів.
• Встановіть хороший SCM і переконайтеся, що вони знають, як ним користуватися.
• Вкажіть їх на хороші ІДЕ за їх технологією та переконайтесь, що вони знають, як ними користуватися.
• Впровадити перевірку якості коду та автоматичну звітність у системі збірки.
• Приєднайте систему побудови до безперервної інтеграції та систем постійного огляду .
• За допомогою вищезазначеного визначте якість коду «гарячих точок» та рефактора .

Тепер для довгої версії ... Обережно, підтягніть себе!

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

Це суперечлива думка, оскільки жорсткість часто сприймається як сила, яка працює проти вас. Це правда для деяких етапів деяких проектів. Але як тільки ви бачите це як структурну підтримку, рамку, яка забирає здогадки, це значно скорочує витрачений витрачений час і зусилля. Зробіть так, щоб він працював на вас, а не на вас.

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

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

Жорсткість приходить в помірності!

Жорсткість структури проекту

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

Жорсткість систем побудови

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

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

Вам потрібно швидко READMEвказати специфіку проекту та витончено керувати користувачем / розробником / дослідником, якщо він є.

Це також значно полегшує інші частини інфраструктури побудови, а саме:

• безперервна інтеграція ,
• постійне обстеження .

Тож слідкуйте за своєю збіркою (як вашими проектами), але зробіть її суворішою та ефективнішою в повідомленні про порушення та погану практику.

Не вигадуйте колесо заново і не використовуйте повторно те, що вже зробили.

Рекомендоване читання:

• Постійна інтеграція: поліпшення якості програмного забезпечення та зменшення ризику (Duval, Matyas, Glover, 2007)
• Безперервна доставка: випуск програмного забезпечення за допомогою автоматизованого побудови, тестування та розгортання (Humble, Farley, 2010)

Жорсткість у виборі мов програмування

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

Зробіть свій стек простий, а технічне обслуговування та широта необхідних навичок до мінімуму: міцне серцевина.

Жорсткість конвенцій і вказівок кодування

Coding конвенції та керівні принципи , що дозволяє розвивати і ідентичність як команда, і загальний жаргон . Ви не хочете помилятися з terra incognita кожного разу, коли ви відкриваєте вихідний файл.

Безглузді правила, які ускладнюють життя або забороняють чіткість дій у тій мірі, в якій відмовляються від вчинення зобов'язань на основі простих простих порушень, є тягарем. Однак:

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

• а набір рекомендованих правил дає додаткові вказівки.

Особистий підхід: Я агресивний, коли справа доходить до умов кодування, деякі навіть кажуть нацистські , тому що я вірю в те, що мовна команда є мовою мовної мови . Коли кодовий код стає зареєстрованим, він виділяється як застуда на обличчі голлівудської зірки: він запускає огляд і дію автоматично. Насправді я інколи пішов далеко за те, щоб виступати за використання гачків, які попередньо здійснюють, для відхилення невідповідних зобов’язань. Як уже згадувалося, воно не повинно бути надмірно божевільним і перешкоджати продуктивності: воно повинно керувати цим. Введіть їх повільно, особливо на початку. Але краще, ніж витрачати стільки часу на виправлення несправного коду, що ви не можете працювати над реальними проблемами.

Деякі мови навіть застосовують це за допомогою дизайну:

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

• Блок-структура Python за допомогою відступу - це ще одна ідея в цьому сенсі.

• Піди, з gofmtінструментом, який повністю прибирає будь-які дискусії і зусилля ( і его !! ) властивий стиль: бігти , gofmtперш ніж зробити.

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

Плюс, як ви побачите нижче, код - це документація , і це ще одна область, де конвенції заохочують читати і чіткіша.

Жорсткість Документації

Документація йде рука об руку з кодом. Сам код - це документація. Але повинні бути чіткі інструкції щодо побудови, використання та обслуговування речей.

Використання єдиного пункту контролю для документації (наприклад, WikiWiki або DMS) - це добре. Створіть простори для проектів, пробіли для більш випадкових стен та експериментів. Нехай усі простори повторно використовують загальні правила та умови. Спробуйте зробити це частиною командного духу.

Більшість порад, що стосуються коду та інструментарію, стосуються також документації.

Жорсткість у кодовому коментарі

Як зазначалося вище, коментарі до коду - це також документація. Розробники люблять висловлювати свої почуття щодо свого коду (в основному гордість і розчарування, якщо ви запитаєте мене). Тож незвично для них висловлювати це у невизначених термінах у коментарях (або навіть кодексах), коли більш формальний фрагмент тексту міг би передати той самий сенс з менш виразними або драматичними. Добре дозволити кілька проскочити через забави та історичні причини: це також є частиною розвитку культури команди . Але дуже важливо, щоб усі знали, що є прийнятним, а що ні, і цей шум коментарів - це саме це: шум .

Жорсткість у журналах фіксації

Записи журналів - це не надокучливий і марний "крок" життєвого циклу вашої SCM: ви НЕ ПРИКЛАДАєте його, щоб вчасно дістатися додому або продовжити виконання наступного завдання, або наздогнати приятелів, які пішли на обід. Вони мають значення, і, як (більшість) хорошого вина, чим більше часу проходить, тим ціннішим вони стають. Тож робіть їх правильно. Мене спалахнуло, коли я бачу, як співробітники пишуть однокласинці для гігантських доручень або для неочевидних хакерів.

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

У кожному рядку коду є історія та історія . Різниці можуть розповісти свою історію, але ви повинні написати її історію.

Чому я оновив цей рядок? -> Тому що змінився інтерфейс.

Чому інтерфейс змінився? -> Оскільки бібліотека L1, що визначає її, була оновлена.

Чому бібліотеку оновили? -> Оскільки бібліотека L2, яка нам потрібна для функції F, залежала від бібліотеки L1.

А яка особливість X? -> Див. Завдання 3456 у трекері випуску.

Це не мій вибір SCM, і може бути не найкращим для вашої лабораторії; але Gitотримує це право і намагається змусити вас писати гарні журнали більше, ніж більшість інших систем SCM, використовуючи short logsі long logs. Зв’яжіть ідентифікатор завдання (так, він вам потрібен) та залиште загальний підсумок для shortlog, а також розгорніть у довгому журналі: напишіть історію зміни .

Це журнал: тут можна відстежувати та записувати оновлення.

Правило великого пальця: Якщо ви шукали щось про цю зміну пізніше, чи ваш журнал може відповісти на ваше запитання?

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

Тримайте їх синхронізовано, інакше вони вже не утворюють цього симбіотичного утворення. Це творить чудеса, коли у вас є:

• очищає журнали у вашому SCM, w / посилання на ідентифікатори завдань у вашому трекері випусків,
• де самі квитки на цей трекер посилаються на набори змін у вашій SCM (і, можливо, на версії вашої системи CI),
• і система документації, яка посилається на все це.

Код і документація повинні бути узгодженими .

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

Емпіричні правила:

• Будь-який новий код повинен мати (принаймні) одиничні тести.
• Будь-який реконструйований застарілий код має бути одиничним тестом.

Звичайно, для цього потрібно:

• насправді перевірити щось цінне (або вони є марною тратою часу та енергії),
• бути добре написаним та прокоментованим (як і будь-який інший код, який ви зареєстрували).

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

Звичайно, вам слід піти далі і пройти інтеграційні тести та регресійні тести для кожної відтвореної помилки.

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

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

Крім того, дозвольте членам використовувати те, що вони хочуть, якщо вони ВСІ:

• продуктивний ,
• НЕ регулярно вимагаючи допомоги
• НЕ регулярно підлаштовуючись під вашу загальну інфраструктуру ,
• НЕ порушуючи вашу інфраструктуру (шляхом зміни загальних областей, таких як код, система побудови, документація ...),
• НЕ впливаючи на роботу інших людей ,
• ВАЖЛИВО вчасно виконувати будь-яке запитуване завдання .

Якщо це не так, примушуйте їх повернутись до значень за замовчуванням.

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

Гнучкість може бути хорошою. Дозволити комусь час від часу використовувати хаку, швидкий п-брудний підхід або улюблений інструмент для домашніх тварин, щоб виконати роботу, це добре. НІКОЛИ не дозволяйте це стати звичкою, і НІКОЛИ не дозволяйте цьому коду стати фактичною базою коду для підтримки.

Матеріальні стосунки команди

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

• Розвивати почуття гордості в кодексі
  • Використовуйте настінні дошки
    • лідерна дошка для безперервної інтеграційної гри
    • стінові дошки для управління випуском та підрахунку дефектів
  • Скористайтеся трекером проблем / трекером помилок

Уникайте звинувачувальних ігор

• НЕ використовуйте ігри безперервної інтеграції / безперервної інспекції: це сприяє доброму та продуктивній конкуренції .
• НЕ слідкуйте за дефектами: це просто гарне господарство.
• НЕ визначте першопричини : це лише процеси, що підтверджують майбутнє.
• АЛЕ НЕ покладайте провини : це зустрічно продуктивно.

Йдеться про код, а не про розробників

Зробити розробників усвідомленими якістю свого коду, АЛЕ змусити їх бачити код як відокремлене ціле, а не розширення себе, яке не можна критикувати.

Парадокс: потрібно заохочувати програмування без его до здорового робочого місця, але покладатися на его в мотиваційних цілях.

Від вченого до програміста

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

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

З досвіду, більшість дослідників розцінюють кодування як необхідність, або в кращому випадку - як веселе відволікання. Вони просто хочуть, щоб це спрацювало. Тих, хто вже досить добре розбирається в цьому і хто має інтерес до програмування, набагато простіше переконати перейняти кращі практики та переключити технології. Потрібно дістати їх на півдорозі.

Технічне обслуговування коду є частиною науково-дослідної роботи

Ніхто не читає шалених наукових робіт. Ось чому вони перевіряються, перевіряються, уточнюються, переписуються та затверджуються знову і знову, поки не буде визнано, що вони готові до публікації. Те саме стосується дисертації та бази коду!

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

Чому все це ??!

Чому ми турбуємося з усім вищезазначеним? Для якості коду . Або це код якості ...?

Ці вказівки мають на меті привернути вашу команду до цієї мети. Деякі аспекти роблять це, просто показуючи їм шлях і дозволяючи їм це робити (що набагато краще), а інші беруть їх за руку (але саме так ви навчаєте людей і розвиваєте звички).

Звідки ви знаєте, коли мета досягається?

Якість вимірюється

Не завжди кількісно, ​​але це вимірюється . Як уже згадувалося, потрібно розвивати почуття гордості за свою команду, а показ успіху та хороших результатів є ключовим. Регулярно вимірюйте якість коду та показуйте прогрес між інтервалами та як це важливо. Зробіть ретроспективи, щоб замислитись про те, що зроблено, і як це покращило або погіршило ситуацію.

Є чудові інструменти для постійного огляду . Sonar є популярним у світі Java, але він може адаптуватися до будь-яких технологій; і є багато інших. Тримайте свій код під мікроскопом і шукайте цих прикрих дратівливих помилок і мікробів.

Але що робити, якщо Мій код уже лайно?

Все вищесказане весело і мило, як поїздка у Never Land, але це не так просто, коли у вас вже є (купка парних і смердючих) лай-кодів, і команда неохоче змінюється.

Ось секрет: починати потрібно десь .

Особистий анекдот: В рамках проекту ми працювали з кодовою базою, яка спочатку важила 650 000+ Java LOC, 200 000+ ліній JSP, 40,000+ LOC JavaScript і 400+ МБ бінарних залежностей.

Приблизно через 18 місяців це 500 000 Java LOC (НАЙБІЛЬШЕ ОЧИЩЕННЯ) , 150 000 ліній JSP і 38 000 JavaScript LOC, залежності ледь не перевищують 100 МБ (і таких вже немає в нашій SCM!).

Як ми це зробили? Ми просто зробили все вищесказане. Або дуже старався.

Це зусилля в команді, але ми повільно вкладаємо в наші правила процесу та інструменти для моніторингу частоти серцевих скорочень нашого продукту, при цьому поспішно збиваючи "жир": лайно код, непотрібні залежності ... Ми не зупиняли всі розробки, щоб зробіть це: у нас є періодичні періоди відносного спокою та тиші, коли ми можемо зійти з розуму на кодову базу і розірвати її, але більшу частину часу ми робимо це все, дефолтуючи до режиму "перегляду та рефактора", кожен шанс, який ми отримаємо : під час складання, під час обіду, під час виправлення помилок у спринтах, у п’ятницю вдень ...

Було кілька великих "робіт" ... Перехід нашої системи побудови з гігантської збірки мурашок 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: увійдіть , вбийте помилку, вийдіть і відправте патч. Це хірургічний тактичний удар.

• Але для всіх інших випадків , якщо ви відкриєте файл, покладіть на нього обов'язок:

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

Просто не заважайте витрачати тиждень від файлу до файлу і закінчуватись масовим набором тисяч виправлень, що охоплюють кілька функцій та модулів - це ускладнює майбутнє відстеження. Один випуск у коді = один квиток у вашому трекері. Іноді набір змін може впливати на кілька квитків; але якщо це трапляється занадто часто, то, напевно, ти робиш щось не так.

Додаток: Керування середовищами візуального програмування

Огороджені сади замовних систем програмування

Кілька систем програмування, як G2 ОП, є різними звірами ...

• Немає джерела "Код"

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

• Немає інструментальних засобів

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

• Відсутність документації

  Досить часто це нішеві програми програмування, які використовуються в досить закритих середовищах. Люди, які ними користуються, часто підписують НДА і ніколи не говорять про те, що вони роблять. Програми спільнот для них рідкісні. Тож ресурсів мало. Ви застрягли зі своєю офіційною довідкою, і все.

Іронічний (і часто розчаровуючий) біт полягає в тому, що все, що ці системи роблять, очевидно, можна досягти, використовуючи основні та загальномовні мови програмування, і, мабуть, більш ефективно. Але це вимагає більш глибоких знань програмування, тоді як ви не можете сподіватися, що ваш біолог, хімік або фізик (щоб назвати декілька) знають достатньо про програмування, а ще менше мати час (і бажання) на реалізацію (і підтримку) складні системи, які можуть бути або не бути довговічними. З тієї ж причини, що ми використовуємо DSL, ми маємо ці замовлені системи програмування.

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

І, як ви могли очікувати, це приємна система, досить гнучка для своїх потреб, хоча іноді трохи перевершена, так що вам цікаво "чому б не використовувати інструменти командного рядка замість цього?", І, на жаль, завжди провідні в середніх розмірах команди, які працюють над великими проектами для багатьох різних людей, використовуючи його з різними "найкращими" методами.

Чудово, ми приречені! - Що ми з цим робимо?

Ну і врешті-решт все вищезазначене все-таки має місце. Якщо ви не можете витягти більшість програм з цієї системи для використання більш основних інструментів та мов, вам "просто" потрібно адаптувати її до обмежень вашої системи.

Про версію та зберігання

Зрештою, ви можете майже завжди змінювати речі, навіть із самим обмеженим та огородженим середовищем. Найчастіше ці системи все ще оснащені власною версією (яка, на жаль, часто є досить базовою, і просто пропонує повернутися до попередніх версій без особливої ​​видимості, просто зберігаючи попередні знімки). Це не точно використання диференціальних наборів змін, таких як ваш SCM вибору, можливо, і, ймовірно, не підходить для декількох користувачів, які одночасно подають зміни.

Але все-таки, якщо вони надають таку функціональність, можливо, ваше рішення полягає в тому, щоб дотримуватися наших улюблених стандартних галузевих рекомендацій і перенести їх у цю програмування !!

Якщо система зберігання даних є базою даних, вона, ймовірно, експортує функції експорту або може бути резервна копія на рівні файлової системи. Якщо використовується спеціальний двійковий формат, можливо, ви можете просто спробувати його версію за допомогою VCS, який має хорошу підтримку бінарних даних. Ви не будете мати дрібнозернистий контроль, але, принаймні, ви будете захищені від катастроф і матимуте певну ступінь дотримання аварійних ситуацій.

Про тестування

Реалізуйте свої тести на самій платформі та використовуйте зовнішні інструменти та фонові завдання для створення регулярних резервних копій. Цілком ймовірно, ви запускаєте ці тести так само, як ви б запускали програми, розроблені за допомогою цієї програми програмування.

Звичайно, це зламана робота і, безумовно, не відповідає стандарту, що є загальним для "звичайного" програмування, але ідея полягає в адаптації до системи, намагаючись зберегти вигляд професійного процесу розробки програмного забезпечення.

Дорога довга і крута ...

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

Рекомендація: Намагайтеся максимально реалізовувати вищезазначені вказівки поза вашою замовленою програмуванням. Це гарантує, що ви можете розраховувати на "загальні" інструменти, які мають належну підтримку та стимул громади.

Вирішення завдань: Коли це не варіант, спробуйте вдосконалити цю глобальну рамку у свій "ящик". Ідея полягає в накладенні цього креслення найкращих галузевих практик над вашою системою програмування, і зробити це найкращим. Порада все ще діє: визначайте структуру та кращі практики, заохочуйте їх дотримання.

На жаль, це означає, що вам може знадобитися зануритися і зробити величезну кількість роботи на ногах. Тому...

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

• Документуйте все, що ви робите.
• Поділіться своїм досвідом.
• Відкрийте джерело будь-якого інструменту вашого запису.

Роблячи все це, ви:

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

Хто знає, може бути на самому початку нового енергійного спільноти Obscure мови X . Якщо таких немає, починайте одну!

• Задавайте питання щодо переповнення стека ,
• Можливо, навіть написати пропозицію для нового сайту StackExchange в районі 51 .

Можливо, всередині це красиво , але поки ніхто не має жодної підказки , тому допоможіть зняти цю потворну стіну і нехай заглядають інші!

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

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

Існує аналогічна публікація про те, як поводитися зі застарілим кодом. Це може бути корисним дотриманням - Поради щодо роботи зі застарілим кодом

Коли мені доводиться працювати з кодом спагетті, перше, над чим я працюю, - це модуляризація . Знайдіть місця, де можна намалювати лінії та витягнути (більш-менш) незалежні фрагменти кодової бази. Вони, ймовірно, не будуть дуже маленькими через високу ступінь взаємозв'язку та з’єднання, але деякі лінії модулів з’являться, якщо їх шукати.

Після того, як у вас є модулі, ви вже не зіткнетеся з грізною задачею очищення всієї безладної програми. Тепер замість цього у вас є кілька менших незалежних безладних модулів для очищення. Тепер виберіть модуль і повторіть у меншому масштабі. Знайдіть місця, де ви можете витягнути великі функції в менші функції або навіть класи (якщо G2 їх підтримує).

Це все набагато простіше, якщо мова має достатньо сильну систему типу, тому що ви можете змусити компілятора зробити багато важких підйомів для вас. Десь ви внесете зміни, які (навмисно) порушать сумісність, а потім спробуйте компілювати. Помилки компіляції приведуть вас безпосередньо до місць, які потрібно змінити, і коли ви припините їх отримувати, ви знайшли все. Потім запустіть програму і протестуйте все! Постійне тестування має вирішальне значення при рефакторингу.

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

Я вважаю, що вони дуже розумні люди, але щоб стати хорошим розробником вимагає багато часу. Чи готові вони провести стільки часу в діяльності, яка не є їх основною справою? ІМХО, це не спосіб досягти найкращих результатів.

Ого. Здається, перед вами справді великий виклик! Я б щось зробив у наступних напрямках:

• Перш за все: розставити пріоритети . Чого ти хочеш досягти першим? Що є найважливішим для поточного стану проекту? Що ви отримаєте найбільше від того, скільки часу знадобиться, щоб потрапити туди.
• Переконайтеся, що у вас є система контролю версій . Наприклад, Git або Mercurial .
• Налаштуйте якусь систему безперервної інтеграції (наприклад, Дженкінс ).
• Отримати відстеження помилки системи і працює. Mantis на мій погляд досить приємний.
• Перегляньте статичний аналіз коду (якщо щось доступне для мови, з якою ви зараз працюєте).
• Постарайтеся досягти такої ж послідовності в чому-небудь, від іменування змінних до загальних конвенцій коду та вказівок у кодовій базі.
• Пройдіть тестування системи . На мою думку, це надзвичайно важливо для такої великої спадкової системи. Використовуйте тестові випадки для документування існуючої поведінки , незалежно від того, чи виглядає це дивно чи ні (зазвичай є причина, чому код виглядає певним чином, може бути хорошим чи поганим, або і те й інше; P). Майкл Перо, Ефективна робота зі Спадковим кодексом - чудовий ресурс для цього.

Вони кажуть, що першим кроком у вирішенні проблеми є визнання того, що у вас є. Зважаючи на це, ви можете почати з генерування графіка залежності, який ілюструє величезний клубок, який є вашою поточною базою коду. Хороший інструмент для створення діаграми залежності? кілька років, але містить деякі вказівки на інструменти, які допоможуть створити такі графіки. Я б поїхав з одним великим потворним графіком, який показує якнайбільше, щоб загнати точку додому. Поговоріть про проблеми, які виникають із-за занадто великої взаємозалежності та, можливо, киньте рядок від Buckaroo Banzai :

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

Звідти введіть план, щоб почати випрямляти безлад. Розбийте код на максимально самостійні модулі. Будьте відкриті до пропозицій, як це зробити - люди, з якими ви говорите, краще знаєте історію та функціональність коду, ніж ви. Мета, однак, полягає в тому, щоб прийняти одну велику проблему і перетворити її на деяку кількість менших проблем, які потім можна розставити пріоритети та почати прибирати.

Деякі речі, на яких слід зосередити увагу:

• Створіть чисті інтерфейси між модулями та почніть їх використовувати. Старий код може, за необхідності, ще не використовувати ті приємні нові інтерфейси деякий час - ось проблема, яку ви починаєте вирішувати. Але змусьте всіх погодитися використовувати лише нові інтерфейси, що рухаються вперед. Якщо є щось, що їм потрібно, це не в інтерфейсах, виправляйте інтерфейси, не обходьте їх.

• Шукайте випадки, коли однакова функціональність була повторена. Робота над об'єднанням.

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

Якщо трохи поглянути на 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

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

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

Хоча, очевидно, вашим першим пріоритетом стане отримання якогось контролю версій в Інтернеті, як вказував Ельюсубов , і, здається, контроль версій підтримується з версії 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. Другий підсумок
    • Як виглядає ідеальний модуль?
    • Як відключити старий код
    • Як обернути новий модуль навколо старого коду (Див. Шаблон удушника http://agilefromthegroundup.blogspot.com.au/2011/03/strangulation-pattern-of-choice-for.html )
11. Визначте кракінг команд кращих програмістів і працюйте з ними, щоб обернути їх модулі.
12. На цьому етапі є огляди коду для покращення спілкування та документації. Нехай це легко на цьому етапі. Упорядкуйте будь-які проблеми процесу.
13. Розкачуйте систему іншим програмістам. Нехай члени команди тріщин стають наставниками однолітків для решти. Пам’ятайте, що тут полягає проблема. Ви фактично перебуваєте в управлінській ролі.

Такі питання - це причина, що існує проект « Програма столярної роботи ».

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

Виходячи з цього, я думаю, що найкращою відправною точкою є, мабуть, відмінна (коротка) книга Роберта Гласса Факти та помилки інженерії програмного забезпечення : її підхід на основі доказів є хорошим способом переконати вчених, що те, що ми їм розповімо про добрі практики програмування, - це більше, ніж просто думка.
Що стосується конкретних практик, два, які люди найбільше бажають застосувати, - це контроль версій та тестування одиниць; Після того, як вони знайдуться, вони можуть вирішити той вид систематичного рефакторингу, який описує Майкл Перо в роботі "Ефективна робота зі спадковим кодексом" .
Я більше не рекомендую Прагматичного програміста (багато закликань, новачкам важко втілитись у життя), і я вважаю, що Кодекс МакКоннелла завершений це занадто багато для початку (хоча це чудова річ, щоб дати їм півроку чи рік, як тільки вони освоїли основи).

Я також настійно рекомендую чудовий документ Пола Дюбуа "Підтримання правильності в наукових програмах" ( Computing in Science & Engineering , травень-червень 2005 р.), В якому описаний підхід "глибокої оборони", який поєднує десяток різних практик у логічний, узгоджений характер шлях.

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

• Дуже малоймовірно, що вони хочуть, щоб ви вивчили давню мову, тому що це зараз здається глухим кутом: є зменшення шансів знайти когось, хто знає чи хоче вивчити G2, тому знання будуть поховані в руйнуючій купі коду, коли нинішні вчені залишають або всезагадливий код виходить з ладу все частіше і частіше.
• Чи готові вчені (або деякі з них) вивчити нову мову та багато парадигм програмування? Або вони хочуть розділити програмування та наукову діяльність у довгостроковій перспективі і, можливо, матимуть ще декількох програмістів, якщо потрібно? Це здається раціональним та ефективнішим розділенням експертних знань.

Я думаю, що головна вимога тут полягає в тому, щоб "зберегти знання в системі", тому вам доведеться піти і розкопати їх!

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

Проаналізуйте структуру та вимоги так, ніби це буде новим завданням, але за допомогою існуючої системи. Вони будуть задоволені, тому що ви ЗАПИТАТИ замість НАВЧАННЯ спочатку - і ви швидко отримаєте достатньо, але більш організованих фонових знань з точки зору програміста: "що тут відбувається?" Документи (статична структура системи, робочий процес, компоненти, проблеми) будуть для них негайно цінними і, можливо, з’являться для них більш релевантною інформацією, ніж для вас (деякі з хлопців можуть мати "AHA!" І негайно почніть виправляти деякі коди ) ...

Тоді ви повинні почати запитувати, куди вони хочуть поїхати?

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

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

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

... мої 2 копійки

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

Єдина проблема виробництва звучить як проблема управління змінами. Якщо це так, і програмне забезпечення в іншому випадку виконує його мету, перша порада, яку я дав би, - протистояти позиву робити занадто багато занадто швидко.

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

Прагнення подрібнити через безлад буде часом великим, але, поки ви не будете інженерно розроблений enoughof це, ви знаєте, що ви можете перевірити свою замінну версію адекватно, вам потрібно бути дуже обережним.

Найважливіші принципи роботи в такій ситуації:

1. Будьте терплячі. Яму, яку копали 20 років, не буде заповнено за кілька тижнів.

2. Бути позитивним. Встояти перед спокусою скаржитися і бурчати.

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

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

5. Картуйте свою територію. У мене є техніка для відображення гігантських застарілих баз кодів. Я клоную репо, роблю робочу копію, а потім намагаюся щось змінити і побачити, що ще ламається. Досліджуючи з'єднання (через глобальний стан, або зламані API, або відсутність послідовного API або будь-яких абстракцій чи інтерфейсів для програмування проти) та читаючи код, який порушується, коли я змінюю речі, я виявляю суть, я задаю питання, що призводять до розуміння решти команди (О, ми додали, що тому, що Boss X 5 років тому вимагав цього, він ніколи не працював!). З часом ви отримаєте ментальну карту території. Як тільки ви дізнаєтесь, яка вона велика, ви будете знати достатньо, щоб скласти свою карту і повернутися додому. Заохочуйте інших до картування території вашої гігантської кодової бази та до побудови технічних знань команди. Деякі люди балакають на "документацію" тому що він не спритний. Що б там не було. Я теж працюю в наукових умовах, і документація для мене є королем, прокляті маніфести будуть прокляті.

6. Створюйте мало додатків. Під час роботи зі застарілою кодовою базою я виявляю, що я перетворююся на пульпу. Я повертаю дух, будуючи маленькі допоміжні програми. Можливо, ці програми допоможуть вам прочитати та зрозуміти та змінити цю гігантську базу даних G2. Можливо, ви можете зробити міні-інструмент IDE або аналізатор, який допоможе вам працювати у вашому оточенні. Є багато випадків, коли метапрограмування та створення інструментів не тільки допоможуть вам вийти з гігантських тупиків, які вам накладають застарілі кодові бази, вони також надають вашому мозку можливість літати без обмежень вашою мовою G2. Пишіть свої інструменти та помічники будь-якою мовою, з якою ви зможете зробити їх найшвидше і найкраще. Для мене ці мови включають Python та Delphi. Якщо ви хлопець Perl, або ви дійсно любите програмування на C ++ або C #, тоді напишіть свої допоміжні інструменти на цій мові.

1. Контроль редагування : покажіть експертам домену користь від можливості повернення, побачити, хто що змінив і т. Д. (Це жорсткіше з усіма бінарними файлами, але якщо вміст справді кодовий, напевно, існує якийсь тип G2 - текстовий конвертер, який може включати різні)

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

3. Загальний код Refactor на багаторазові підпрограми та компоненти. Люди, що не мають програмного забезпечення, без контролю за редакцією, ймовірно, одночасно копіюють та вставляють 100 рядків рядків для створення процедур. Знайдіть їх і відновлюйте їх, показуючи, що всі тести проходять і код стає коротшим. Це також допоможе вам вивчити її архітектуру. Якщо вам пощастить, коли вам доведеться приймати важкі архітектурні рішення, можливо, ви знизитесь до 100 KLOC.

У політичному плані, якщо ви знайдете опір старих таймерів у цьому процесі, наймайте консультанта, щоб прийти і поговорити про хорошу методологію програмного забезпечення. Переконайтеся, що ви знайдете хорошого, з поглядами якого ви згодні, і попросіть менеджмент викупити необхідність консультанта, навіть якщо доменні експерти цього не роблять. (Вони повинні погодитися - зрештою, вони найняли вас, тому, очевидно, вони розуміють, що їм потрібна експертиза програмного забезпечення.) Звичайно, це витівка, яка витрачає гроші, але причина полягає в тому, що якщо ви - новий програміст молодих хлопців, - скажіть їм потрібно щось робити, вони можуть ігнорувати це. Але якщо керівництво заплатить консультанту 5000 доларів, щоб зайти і сказати їм, що їм потрібно зробити, вони будуть більше вірити в це. Бонусні бали: попросіть консультанта порадити вдвічі більше змін, ніж ви насправді хочете, тоді ви можете бути "хорошим хлопцем" і сторонитись з експертами в галузі домену, намагаючись змінити лише половину стільки, скільки запропонував консультант.

"Сама програма - це фізична модель складного заводу хімічної переробки ..."

"Оскільки G2 - це як не-код, а досить автоматизований код, написаний деяким поважним графічним інтерфейсом ..." - Ерік Реппен

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

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

Мова моделювання полягає в тому, щоб відокремити опис проблеми від алгоритмів, що використовуються для вирішення проблеми. Ці алгоритми, як правило, застосовні до більшості моделювання / оптимізацій даного класу (наприклад, хімічних процесів), і в цьому випадку вони насправді не повинні бути винайдені та підтримуватися у власних умовах.

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

Усі ці пакети так чи інакше підтримують "розширення", так що якщо у вас є частини ваших моделей, які потребують спеціального програмування, вони можуть бути інкапсульовані в об'єкт (наприклад, .DLL), на який можна посилатися рівняннями в модель. Тим часом основна частина вашої моделі залишається лаконічною, описаною у формі, легко зрозумілою вченим безпосередньо. Це набагато кращий спосіб зафіксувати знання та IP компанії.

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

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

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

Хоча мій статус за замовчуванням - "рефактор і підтримка робочої системи", я також думаю, що коли проблема стає "занадто великою", то більш радикальна зміна / перезапис стає швидшою загалом. (І, можливо, приносить додаткові переваги, як, наприклад, перехід до більш сучасних технологій.) Я кажу, що з деяким досвідом перенесення на нову програмну платформу, але з того, що я збираю, це ще більш драматично з портом до пакету математичного моделювання.

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

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

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

Я б кинув наступне:

1. Тут є один програміст. Шнекова політика. Вони знають свою торгівлю. Ви знаєте своє. Позначте цю територію, навіть якщо вам доведеться піти на неї. Вони вчені. Вони можуть поважати таку річ чи слід, оскільки вони майже постійно роблять те саме. За допомогою будь-яких засобів ви можете позначити межі зараз. Це я виправлю. Це те, за що я не можу відповідати.

2. Вчені пишуть / перевіряють алгоритми. Вчені, які хочуть писати власні алгоритми 1-3 мовами, кожен може погодитись на те, щоб перетворити на основний код. Це ставить на них тестування своїх речей. Крім того, їм доведеться допомогти вам виділити важливий науковий матеріал, порівняно з добрим богом-знанням - що вони зробили для архітектури. Кодова база шлангується. Існує багато косого і горілого, що потрібно буде зробити. Надайте їм варіанти передавати вам робочі версії речей, в яких використовується те, що вони найкраще знають, щоб ви могли робити те, що вам найкраще. Запишіть свої знання у вікно, за яке вони відповідають, але з яким ви можете працювати.

3. Використовуйте зручну для подій мову з функціями першого класу, якщо можете. Коли все інше виходить з ладу, викликати подію або перекинути зворотний виклик на якийсь об'єкт із інтерфейсом та механізмом стану, який насправді має сенс, може бути величезною економією часу, коли ви перебуваєте по колу в коді, що не має кривавого сенсу і, можливо, ніколи буде. Вченим, здається, подобається Пітон. З цим не важко склеїти матеріали з низьким рівнем математики на C. Просто говорю'

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

5. Шаблони дизайну. Перехідники. Використовуйте їх. Використовуйте їх багато в таких ситуаціях.

6. Дізнайтеся, що ви можете від науки. Чим більше ви знаєте, тим краще ви можете визначити наміри в коді.

Зробіть аналіз спочатку.

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

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

Я обмежую практику до ~ 3 залежно від рівня зміни до там стилю програмування SDLC; доки їм не почне комфортно (я б наполягав на запровадженні 1 нової зміни кожні ~ 1-2 тижні, коли вони ставатимуть більш комфортно з ідеєю вивчення нових підходів). Також непогано визначити, які критерії успіху. Те, що практика повинна досягти (навіть якщо це така м'яка мета, як моральна команда). Таким чином ви зможете показати, ефективна вона чи ні.

• Навіщо обмежувати кількість змін?

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

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

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

Деякі практики мають перевагу.

Належне використання системи управління версіями (ІМО) підкреслює все інше. Позаду - уроки з модуляризації, з’єднання / згуртованості та відстеження функцій / помилок.

Видаліть практики, які не працюють.

Не бійтеся позбутися практики, яка не працює. Якщо висока вартість і мало користі, скасуйте практику.

Удосконалення - це процес.

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

Схоже, перший крок - продати команді необхідність вкладати кошти в нову програмну методологію. Згідно з вашим твердженням, в команді немає консенсусу, і вам знадобиться це, щоб мати можливість випереджуватись за допомогою повільного "оновлення" коду.

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

Наприклад, два розробники мали різні копії і в кінцевому підсумку розгорнули гібридний неперевірений реліз -> Ввести контроль версій, розгалуження та тестування.

Хтось видалив декілька рядків коду, які вони не зрозуміли і спричинили перебої -> ввести DDD.

Якщо важкі уроки не діляться з вами досить детально, то просто покажіть власні приклади того, як все пішло не так, коли цієї дисципліни не дотримувались.

Контроль вихідного коду - це крок №1, як уже було зазначено багато разів. Хоча люди, з якими ви працюєте, можуть не бути професійними розробниками, і вони не відповідатимуть великій кількості підприємств або спритних мамбо-джамбо. Вони також не мавпи з низьким рівнем коду, і намагаються поводитись з ними так, змушуючи їх робити речі "по-своєму", не пролетить.

Ви повинні оглянути, що там. Якщо вони не використовували контроль вихідного коду, тоді просто визначити правильні версії коду (якщо це можливо) та які всі можливі результати буде тривати довго. Тоді ви будете мати завдання навчити своїх колег користуватися керуванням вихідного коду та переконати їх у тому, що вони варті свого часу. Почніть з переваг!

Поки ви робите це, знайдіть інші низько висячі фрукти та виправте ці проблеми.

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

Удачі!