Будучи оказанным давление к GOTO темная сторона

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

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

Также имейте в виду, что некоторые "современные" функции языка, такие как оператор "throw" в java или "ON ERROR" в SQL, на самом деле являются замаскированными "GO TO".

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

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

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

ЕСЛИ вы не можете размотать свои GOTO, я определенно рекомендую вам больше не использовать их.

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

То, что у вас есть, - это лишь один пример. То, как вы это сделаете, будет определять, как вы будете заниматься разработкой в ​​будущем. Я думаю, у вас есть 4 варианта:

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

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

3. Откажитесь от дел и будьте готовы бороться, чтобы исправить беспорядок.

4. Уйти в отставку.

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

Обратно к принципам:

• Читается ли он?
• Работает ли он?
• Поддерживается ли он?

Это классический конфликт «менеджмент» и «технари».

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

Для этого есть ряд причин:

1. Вполне возможно иметь хорошо написанные, легко читаемые, правильно структурированные программы с помощью gotos! Спросите любого программиста на ассемблере; условная ветвь и примитивный цикл do - все, с чем им нужно работать. Просто потому, что «стиль» не актуален и не означает, что он плохо написан.

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

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

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

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

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

Если не сломалось, не чини!

PS: Даже Джоэл думает, что это плохая идея: вещи, которые вы никогда не должны делать

Обновить! -

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

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

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

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

Может быть, вы можете использовать шаблон boyscout: оставьте место немного более чистым, чем вы его нашли. Поэтому для каждой функции запрос: не вводите новые gotos, а удалите один.

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

Утверждайте, что рефакторинг в 2 часа сэкономит в 20 раз 15 минут в будущем, и позволит быстрее и глубже улучшить.

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

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

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

Во многих случаях намного лучше альтернативы, такие как:

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

К сожалению, на языке, на котором это написано, нет готовых инструментов рефакторинга

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