Как сохранить на протяжении многих лет большой и сложный программный продукт?

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

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

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

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

152 голоса | спросил 2 revs, 2 users 75%
chrmue
1 Jam1000000amThu, 01 Jan 1970 03:00:00 +030070 1970, 03:00:00

20 ответов


137

Единственное реальное решение, чтобы избежать гниения кода, - это хорошо кодировать код!

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

Обычная практика может помочь:

  1. Держите его простым.
  2. Держите его простым. Это особенно касается архитектуры, «большой картины». Если разработчикам нелегко получить общую картину, они будут собираться с кодом против нее. Поэтому сделайте архитектуру простой, чтобы все разработчики ее получили. Если архитектура должна быть менее простой, то разработчики должны быть обучены понимать эту архитектуру. Если они не интернализуют его, тогда они не должны кодировать его.
  3. Цель низкой связи и высокая сплоченность . Убедитесь, что все в команде понимают эту идею. В проекте, состоящем из слабосвязанных, сплоченных частей, если некоторые части становятся недостижимыми, вы можете просто отключить и переписать эту часть. Это труднее или почти невозможно, если соединение плотно.
  4. Будьте последовательны. Какие стандарты должны следовать мало, но, пожалуйста, следуйте некоторым стандартам. Разумеется, в команде все должны придерживаться тех же стандартов. С другой стороны, легко стать слишком привязанными к стандартам и забыть об остальном: пожалуйста, поймите, что, хотя стандарты полезны, они составляют лишь небольшую часть создания хорошего кода. Не делайте его большого количества.
  5. обзоры кода могут быть полезны, чтобы заставить команду работать последовательно.
  6. Убедитесь, что все инструменты - IDE, компиляторы, управление версиями, системы сборки, генераторы документации, библиотеки, компьютеры , стулья , общая среда и т. д. и т. д. - поддерживаются в хорошем состоянии, поэтому разработчикам не нужно тратить время на такие вторичные проблемы, как конфликты версий файлов проекта, обновления Windows, шум и любые банальные, но раздражающие вещи. Необходимость многократно тратить много времени на такой неинтересный материал снижает моральный дух, что, по крайней мере, не улучшит качество кода. В большой команде может быть один или несколько парней, основной задачей которых является поддержка инструментов разработчика.
  7. При принятии технологических решений подумайте, что потребуется для переключения технологии; какие решения необратимы, а какие нет. Выполните тщательную оценку необратимых решений. Например, если вы решили написать проект в Java , это довольно необратимое решение. Если вы решите использовать некоторый самоварный двоичный формат для файлов данных, это также довольно необратимое решение (после того, как код вышел из дикой природы, и вы должны поддерживать этот формат). Но цвета графического интерфейса можно легко отрегулировать, функции, которые изначально были исключены, могут быть добавлены позже, поэтому меньше внимания уделять таким проблемам.
ответил user3511585 6 FebruaryEurope/MoscowbTue, 06 Feb 2018 18:05:53 +0300000000pmTue, 06 Feb 2018 18:05:53 +030018 2018, 18:05:53
55

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

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

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

ответил user3511585 6 FebruaryEurope/MoscowbTue, 06 Feb 2018 18:05:53 +0300000000pmTue, 06 Feb 2018 18:05:53 +030018 2018, 18:05:53
40

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

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

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

ответил user3511585 6 FebruaryEurope/MoscowbTue, 06 Feb 2018 18:05:53 +0300000000pmTue, 06 Feb 2018 18:05:53 +030018 2018, 18:05:53
18

То, как я об этом говорю, это обрезать его в корне:

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

  1. Использовать стандарты для именования, кодирования, проверок, потока ошибок, потока процессов - в основном ничего.
  2. Не бойтесь прощаться с членами команды, которые не придерживаются стандартов. Некоторые разработчики просто не могут работать в рамках определенного набора стандартов и станут врагами 5-го столбца на поле битвы, чтобы сохранить чистую базу кода
  3. Не бойтесь выделять более опытных членов команды на тестирование в течение длительных периодов времени.
  4. Используйте каждый инструмент в своем арсенале, чтобы избежать проверки кода гниения: это включает в себя специальные инструменты, а также предварительно написанные блок-тесты , которые проверяют файлы сборки, файлы проекта, структуру каталогов и т. д.
  5. В команде из примерно 5-8 участников, ваш лучший парень рефакторинг почти постоянно - очистка от беспорядков, оставшихся остальными. Даже если вы найдете лучших специалистов в этой области, у вас все еще будет беспорядок - это неизбежно, но это может быть ограничено постоянным рефакторингом.
  6. Выполняйте модульные тесты и поддерживайте их - НЕ ИСПОЛЬЗУЙТЕСЬ с модульными тестами, чтобы проект был чистым, а нет.
  7. Обсудите все. Не бойтесь тратить часы, чтобы обсудить вещи в команде. Это будет распространять информацию и устранит одну из основных причин плохого кода: путаница в технологиях, целях, стандартах и ​​т. Д.
  8. Будьте very осторожны с консультантами, пишущими код: их код будет почти по определению быть настоящим дерьмовым материалом.
  9. Перед проведением проверки рекомендуется проводить проверку как шаг процесса. Не бойтесь совершать откаты.
  10. Никогда не используйте принцип открытия /закрытия , если только на последнем этапе до выпуска: это просто приводит к гниению кода оставляя запах.
  11. Всякий раз, когда возникает проблема, найдите время, чтобы понять это в полной мере, прежде чем внедрять решение. Большинство генов кода возникает из-за решения проблемы, которая не полностью понята.
  12. Используйте правильные технологии. Они часто бывают в наборах и свежие: лучше зависеть от бета-версии фреймворка, за который вам гарантирована поддержка в будущем, чем полагаться на чрезвычайно стабильные, но устаревшие фреймворки, которые не поддерживаются.
  13. Нанять лучших людей.
  14. Отложите все остальное - у вас нет кафе.
  15. Если менеджмент не лучший архитектор, и они вмешиваются в процесс принятия решений - найдите другую работу.
ответил user3511585 6 FebruaryEurope/MoscowbTue, 06 Feb 2018 18:05:53 +0300000000pmTue, 06 Feb 2018 18:05:53 +030018 2018, 18:05:53
17

Есть несколько вещей, которые мы можем сделать:

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

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

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

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

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

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

ответил user3511585 6 FebruaryEurope/MoscowbTue, 06 Feb 2018 18:05:53 +0300000000pmTue, 06 Feb 2018 18:05:53 +030018 2018, 18:05:53
12

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

  • Разработка новой функции
  • Исправить проблему

Значительно ускорьте свой первый цикл разработки:

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

Код рефакторинга для использования низкой связи (сильно внутренних когезионных единиц):

  • Более простые, (более) функции (подпрограммы)
  • Модули
  • Объекты (и классы или прототипы)
  • Чистые функции (без побочных эффектов)
  • Предпочтительное делегирование, над наследованием
  • Слои (с API)
  • Коллекции небольших, одноцелевых программ, которые могут работать вместе

Органический рост хорош; большой передний дизайн плохой.

Имейте лидера, который хорошо осведомлен о текущем проекте. Если нет, прочитайте код проекта, пока вы не будете осведомлены.

Прочитайте рефакторинг книг.

ответил user3511585 6 FebruaryEurope/MoscowbTue, 06 Feb 2018 18:05:53 +0300000000pmTue, 06 Feb 2018 18:05:53 +030018 2018, 18:05:53
10

Простой ответ: вы не можете .

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

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

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

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

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

ответил user3511585 6 FebruaryEurope/MoscowbTue, 06 Feb 2018 18:05:53 +0300000000pmTue, 06 Feb 2018 18:05:53 +030018 2018, 18:05:53
9

Я работаю над базой кода для продукта, который был в непрерывном развитии с 1999 года, так как вы можете себе представить, что он довольно сложный к настоящему времени. Самый большой источник хакерства в нашей кодовой базе - это то, что нам пришлось переносить его из ASP Classic to ASP.NET , от ADO до ADO.NET, от postbacks до Ajax , переключение библиотек пользовательского интерфейса, стандартов кодирования и т. д.

В целом мы сделали разумную работу по сохранению базы кода. Основные вещи, которые мы сделали, которые способствовали этому:

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

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

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

ответил user3511585 6 FebruaryEurope/MoscowbTue, 06 Feb 2018 18:05:53 +0300000000pmTue, 06 Feb 2018 18:05:53 +030018 2018, 18:05:53
8

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

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

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

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

  • Документация - особенно архитектура - почему были приняты решения и стандарты кодирования. Также держите ссылки /заметки /дорожные карты в документировании бизнес-домена - вы будете поражены тем, насколько сложно корпоративному бизнесу объяснить, что именно они делают с разработчиком без опыта работы в домене.

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

  • Убедитесь, что архитектура и особенно слои кода четко разделены и разделены - это потенциально позволит заменить слои кода по мере появления новых технологий, например, заменить интерфейс Web Forms на HTML5 jQuery UI и т. д., которые могут купить год или около того, чтобы добавить долговечность.

ответил user3511585 6 FebruaryEurope/MoscowbTue, 06 Feb 2018 18:05:53 +0300000000pmTue, 06 Feb 2018 18:05:53 +030018 2018, 18:05:53
7

Одним из свойств высокопотенциального кода является чистота функции .

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

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

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

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

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

ответил user3511585 6 FebruaryEurope/MoscowbTue, 06 Feb 2018 18:05:53 +0300000000pmTue, 06 Feb 2018 18:05:53 +030018 2018, 18:05:53
6

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

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

Другой подход - заставить всех читать comp.risks и The Daily WTF , чтобы они узнали о последствиях плохого дизайна и плохого программирования, и они будут бояться видеть их собственный код размещен на The Daily WTF .

ответил user3511585 6 FebruaryEurope/MoscowbTue, 06 Feb 2018 18:05:53 +0300000000pmTue, 06 Feb 2018 18:05:53 +030018 2018, 18:05:53
6

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

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

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

Однако, даже если у вас есть серьезный срок, я считаю, что еще одна хорошая вещь, которую следует иметь в виду:

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

И мой личный любимый совет - скорее цитата, хотя я не могу вспомнить источник:

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

ответил user3511585 6 FebruaryEurope/MoscowbTue, 06 Feb 2018 18:05:53 +0300000000pmTue, 06 Feb 2018 18:05:53 +030018 2018, 18:05:53
5

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

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

Только мои 2 цента.

ответил user3511585 6 FebruaryEurope/MoscowbTue, 06 Feb 2018 18:05:53 +0300000000pmTue, 06 Feb 2018 18:05:53 +030018 2018, 18:05:53
5
  • Будьте разведчиком . Всегда оставляйте код чище, чем вы его нашли.

  • Исправить разбитые окна . Все эти комментарии «меняются в версии 2.0», когда вы находитесь на версии 3.0.

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

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

  • Если вы объясните, как работает система (даже в одном случае), и вам придется извиняться за подсистему снова и снова, это проблема. Какое поведение могло бы сделать остальную часть системы более простой (независимо от того, насколько сложно ее реализовать по сравнению с тем, что есть). Классическая подсистема для перезаписи - это та, которая загрязняет каждую другую подсистему своей операционной семантикой и реализацией. «О, вы должны оценивать значения до того, как будете их кормить в подсистему froo, а затем вы снова отказываетесь от них, когда вы получаете выход из фто. Возможно, все значения должны быть оценены при чтении из пользовательского хранилища , а остальная система ошибочна? Это становится более захватывающим, когда есть два или более разных grozifications.

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

  • Преобразуйте весь код в стандарт кодирования.

  • Убедитесь, что система управления версиями привязана к вашему трекеру ошибок. Это означает, что будущие изменения хороши и подотчетны, и вы можете решить ПОЧЕМУ.

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

  • Перепечатайте проектные документы в вики. Это помогает институционализировать знания.

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

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

  • Если ваша команда не делает этого, это плохо для компании.

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

  • Попробуйте выполнить проверку некоторых старых битов, которые не тестируются на устройстве. Это помогает сократить страх перемен.

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

ответил user3511585 6 FebruaryEurope/MoscowbTue, 06 Feb 2018 18:05:53 +0300000000pmTue, 06 Feb 2018 18:05:53 +030018 2018, 18:05:53
4

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

ответил user3511585 6 FebruaryEurope/MoscowbTue, 06 Feb 2018 18:05:53 +0300000000pmTue, 06 Feb 2018 18:05:53 +030018 2018, 18:05:53
3

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

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

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

ответил user3511585 6 FebruaryEurope/MoscowbTue, 06 Feb 2018 18:05:53 +0300000000pmTue, 06 Feb 2018 18:05:53 +030018 2018, 18:05:53
2

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

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

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

ответил user3511585 6 FebruaryEurope/MoscowbTue, 06 Feb 2018 18:05:53 +0300000000pmTue, 06 Feb 2018 18:05:53 +030018 2018, 18:05:53
2

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

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

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

Или, если вы просто хотите приручить «проект Франкенштейна», это мои советы:

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

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

Вне реализации функций и исправлений ошибок не спешите очищать код.

ответил user3511585 6 FebruaryEurope/MoscowbTue, 06 Feb 2018 18:05:53 +0300000000pmTue, 06 Feb 2018 18:05:53 +030018 2018, 18:05:53
1

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

Используйте любые методы программирования в тех библиотеках, которые облегчают использование библиотеки. Следует отметить, что, например, любой не-объектно-ориентированный язык, поддерживающий указатели на функции, поддерживает фактически объектно-ориентированное программирование (ООП). Так, например, в C вы можете сделать ООП.

Вы даже можете рассмотреть возможность обмена этими небольшими независимыми библиотеками между многими проектами (git subodules - ваш друг).

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

Если вы используете C или C ++ и не любите идею наличия большого количества небольших файлов .so, вы можете связать все библиотеки вместе с большим .so-файлом или, как альтернатива, статическим связыванием. То же самое верно для Java, просто измените .so на .jar.

ответил user3511585 6 FebruaryEurope/MoscowbTue, 06 Feb 2018 18:05:53 +0300000000pmTue, 06 Feb 2018 18:05:53 +030018 2018, 18:05:53
0

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

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

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

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

ответил user3511585 6 FebruaryEurope/MoscowbTue, 06 Feb 2018 18:05:53 +0300000000pmTue, 06 Feb 2018 18:05:53 +030018 2018, 18:05:53

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

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

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