Кросспост из личного ( http://www.eldar.com/node/200 ) по-прежнему… Да-да, я знаю.
Очень непривычно ругаться на код-ревью, особенно в мире, где они воспринимаются чуть ли не как одиннадцатая заповедь, за неуважение к которой легко можно оказаться на костре.
Так что терпите с небольшой ересью я все объясню! Итак.
Я не говорю, что доработка кода — это плохо.
Просто все в нашем грешном мире имеет свои преимущества и недостатки.
Или как говорили римляне, уставшие от мудрости греков – cons et pros. Итак, я хотел бы обратить ваше внимание на некоторые минусы доработки кода, о которых обычно не упоминают вслух.
Представьте, что вы работаете в небольшой команде и все ужасно заняты созданием нового продукта.
Обратите внимание: «ужасно занят».
И – удивительно, не правда ли? – как и в любом другом продукте, у вас есть ошибки.
Ошибка – это то, что необходимо исправить.
Нет дураки, я не шучу.
Теперь последний вопрос.
Как вы исправите ошибку? Насколько я знаю, есть только две философии того, как это сделать: патчи и рефакторинг.
Ну да-да, есть еще идиотское «просто исправь», но мы не будем опускаться так низко, правда? Идиоты, не понимающие, о чем я говорю, могут прогуляться и не вмешиваться в наши разговоры.
Но для нас – тех, кто остался – выбор все еще есть.
Итак, патчи или рефакторинг? Итак, как вы думаете, какой правильный способ исправить ошибки? Да-да, бывают случаи, когда патчи — правильное решение.
Например, Quick Fix Engineering — когда вам нужно доставить патч критичному пользователю с несколькими тысячами копий вашего ПО.
Другой пример — когда изделие изготавливается уже давно, и все, что хочется, — это как можно меньше к нему прикасаться.
Ну и, наконец, ситуации, когда каждое исправление — это очень большой риск.
Скажем, когда вы исправляете программное обеспечение для космического корабля на орбите Юпитера.
в реальном времени.
и любая ошибка оставит ваших клиентов с куском неработающего оборудования стоимостью многие, многие миллионы долларов.
на той же самой орбите Юпитера.
Однако в большинстве случаев я бы сказал, что с точки зрения «хорошего проектирования» рефакторинг обычно превосходит патчи.
Ну.
не только превосходит. но как бы это сказать.
«как бык над овцой»! Не правда.
Позвольте мне объяснить на примере.
Учитывая небольшой размер статьи, мне придется привести довольно примитивный пример, но все же очень понятный, как мне кажется.
Итак, представьте, что у вас есть метод LoadingFinished(), который вызывается, когда загрузка фрагмента мультимедиа завершена, что означает, что вы можете начать загрузку следующего фрагмента.
И тут вы заметили, что один из ваших коллег вставил в него какой-то совершенно идиотский код. Нет, будем честны, код был бы совсем не идиотским, если бы его вставляли не в LoadingFinished(), а в LoadingFinishedInРис().
Ну что поделаешь, плохой идентификатор.
Но в результате у вас есть выбор из двух вариантов: 1. Просто переместите код из LoadingFinished() в LoadingFinishedInfig().
Ошибка будет исправлена.
Исправление занимает несколько строк, перемещенных немного ниже в файле.
2. Выполните (1) и переименуйте LoadingCompleted() в AllowLoadingNextFile(), чем на самом деле и является эта функция, тем самым предотвращая подобные ошибки раз и навсегда.
Исправление затронет десяток-другой файлов.
Не забывайте, ваша команда очень занята.
Каковы ваши шансы получить код-ревью быстро, при выборе (1) или при выборе (2)? Ага.
Ну да.
Точно.
1. При попытке (2) ребята быстро посмотрят список измененных файлов и сразу запутаются.
И по уважительной причине.
И вам не очень нравится хранить код на своем компьютере столько времени, сколько вам хочется, и откладывать регистрацию, не так ли? Точно.
Какой результат? В результате ваш продукт получает исправление, а не рефакторинг.
А еще через неделю кто-то другой снова влезет в эту самую LoadingFinished(), и вы исправите очередной баг-двойник.
Ну, если будет то же самое, или еще хуже.
Я, честно говоря, не знаю, как это выглядит? Я действительно говорю о чем-то серьезном или мне это кажется? Теги: #разработка ПО #разработка ПО #Архитектура и дизайн #ИМХО #c++ #C++ #Чулан
-
Мошенничество Безосновательно
19 Oct, 24 -
Пиратство: Преступление Или Принуждение?
19 Oct, 24 -
Выбор Mq Для Высоконагруженного Проекта
19 Oct, 24
