Под давлением перейти на темную сторону

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

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

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

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

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

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

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

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

4. Подать в отставку.

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

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

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

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

Вернемся к принципам:

• Это читается?
• Это работает?
• Это ремонтопригодно?

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

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

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

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

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

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

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

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

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

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

PS: Даже Джоэл считает это плохой идеей: то, что вам никогда не следует делать

Обновлять!-

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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