Если работает не трогай корова

«Работает — не трогай». Стоит ли нарушать правила?

Введение

Очень не хватало возможности ввести пользователей в контекст перед голосованием. Спасибо! И так

Преамбула

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

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

Такой код стараются фундаментально не менять, исправляются только локальные проблемы и ошибки. Правило «работает — не трогай» во всей своей красе. С другой стороны, если переписать или исправить этот код, то жить станет всем легче, но появляются проблемы:

• Никто не понимает, как изменения отразятся на всей системе в целом;
• Вероятность внести новые ошибки очень велика;
• Появляется период стабилизации кода (также как и с новым кодом).

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

Источник

«Работает — не трожь!» Насколько этот совет применим в работе программиста?

Перевод статьи «Advice to programmers: If it works, don’t fix it. Or?».

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

На как насчет кода? Как насчет программистов? Что они думают о своей программе?

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

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

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

Как насчет дебаггинга? На обнаружение и исправление багов также уходит слишком много времени.

Но если не принимать во внимание плохой дизайн и некрасивость кода, программа работает хорошо и пользователи довольны. И вы оказываетесь на раздорожье, где вам приходится выбирать один из возможных путей. С одной стороны, можно следовать старому инженерному правилу «Работает — не трожь!», а с другой стороны не помешало бы провести рефакторинг, чтобы сделать код более понятным и читаемым, и тем самым облегчить себе дальнейшую работу над этой кодовой базой. Какой путь выбрать?

Два типа мышления у программистов

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

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

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

Поэтому для таких программистов исправление плохо написанного кода это напрасная потеря времени. Код работает. Зачем же его трогать?! Кроме того, существует большой риск того, что в процессе исправления кода будут внесены новые баги.

Программисты с таким типом мышления просто не будут трогать старый код без острой необходимости.

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

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

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

Какое решение этой проблемы будет наилучшим?

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

Почему важно уделить внимание основным частям? Именно с ними вы работаете чаще всего. Именно их чаще всего приходится читать. Именно в них чаще всего приходится вносить изменения. И если потребуется добавить в программу новый функционал, он напрямую будет связан с ядром кодовой базы. Также именно в основных частях содержится наибольшее количество багов, которые придется находить и исправлять. Помните о принципе Парето: «20% кода содержат 80% ошибок. Найдите их и исправьте!»

Как насчет остальных частей кодовой базы?

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

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

Если вы хотите, чтобы ваша программа служила пользователям верой и правдой долгие годы, ваш продукт должен оставаться поддерживаемым. А поддерживаемость предполагает, что внесение изменений не должно быть трудным делом. Отладка и исправление багов не должны занимать слишком много времени. Добавлять новый функционал должно быть просто. При таком положении дел будут довольны как программисты, так и пользователи программы.

Мартин Фаулер в своей книге «Рефакторинг. Улучшение проекта существующего кода» говорит: «Когда вы представляете себе программистов, вы думаете, что они проводят большую часть своего времени за написанием кода. Но на самом деле то лишь малая часть их работы. Большую часть своего времени программисты проводят за чтением и отладкой кода. Каждый программист может рассказать свою историю о баге, который пришлось искать целый день. Исправление бага обычно происходит довольно быстро, но поиски это настоящий кошмар».

Чем лучше написан ваш код, тем проще в нем разобраться. А чем проще в нем разобраться, тем легче ваша работа.

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

Источник

Брось, а то уронишь! Или не трогай, пока работает.

Всем привет! В общем, я тут в очередной раз подтвердила известное выражение — не трогай, пока всё работает! А получилось вот как. Собралась я комп продавать. Ну как собралась, разбирала хлам, поняла, что ноут переставляем с места на место уже пару лет. Дай, думаю, гляну — стоит он чего вообще? Ну за 1-1.5к продать можно. Бесплатно я ничего не выставляю, причина — перекупы и яжемамки у который по 10 детей и ооочень нужен бесплатный ноут, чтоб мультики смотреть, а потому «привезите его нам в алтуфьево, сегодня же к 6 вечера». Ноут рабочий, полностью, интернет работал, даже игры какие-то шли. Пока я не решила, что надо бы винду снести. XP уже давно померла. Думаю, хотя бы висту поставить, она поддерживается, да и хард почистить. Почему в жизни нет Ctrl+Z.

В общем поставила висту из под винды, и тут понеслось. Дрова есть, но их не скачать, в интернете поиск не работает, даже опера не устанавливается. Ну всё, приплыли. Зачем трогала? Полезла в биос, а он на пароле. Вспоминала — нифига. Обзвонила всех родственников, которые могут знать пароль от биоса, ну кто-то же его туда поставил. Результата — 0. Поискала в интернете, несколько часов результата не дали (не там искала как оказалось). Решила попробовать физически сбросить пароль, релогнув биос. Оказалось все не так просто и я вспомнила за что ненавижу дешёвые ноутбуки, да и ноутбуки в целом (кроме Dell Precision M6800, вот там два болта открутил и всё как на ладони).

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

Сейчас снова половину утра убила на возню с этим динозавром. Как я его настраивала до этого — помню, но вроде тогда ещё была поддержка XP. В принципе, драйвера нашла, загрузила, всё ок, но. Интернет =) В принципе, жить можно, но корректно опера, мозила и хром не хотели. Полезла искать альтернативу, нашла K-Meleon. Если не будет и он нормально работать, то сдам на запчасти xD.

Мораль — не лезь, олень, куда не просят! Ну и инициатива наказуема.

А у вас были ситуации, когда хотели как лучше, а в итоге всё пошло не туда?

Источник

Изучаем программирование. День 44. О принципе «Работает — не трожь!» и ещё об одном подобном принципе.

Вчера у нас с вами была рубрика «Занимательный факт», где я рассказывал о бесплатных курсах по Python для начинающих от Google и Microsoft.

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

«Работает — не трожь!»

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

1. Бизнес

Самая, наверное, частая причина этого явления — «интересы бизнеса». Почему я написал это в кавычках? Ну потому что в 99% случаев к бизнесу такие «улучшения» никакого отношения не имеют. Пример: работает компания, хорошо работает, приносит прибыль, но неизменно появляется такой человек, которому нужно в налаженном процессе обязательно что-то поменять, чаще всего это какой-то новый человек, либо старый, занимающий высокую должность. И вот он приходит и говорит: делайте теперь вот так, прежний метод не подходит, если вы ему справедливо приводите аргументы и говорите, что предложенный способ не заработает и не будет лучше старого, «главный» человек в отделе/компании говорит: «ты ничего не понимаешь в бизнесе».

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

2. Незнание продукта.

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

3. Новые фукнции.

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

И мы плавно приходим к очень частой ошибке it-компаний, которая вытекает из вышеописанного — «Чинить не там, где сломано».

Очень показателен недавний пример в одной фирме. Имён я называть не буду, чтобы ненароком кого-нибудь не обидеть. Было приложение, работало не без проблем, но работало. Одно время в нём старались что-то исправлять, но потом как-то всё затихло и многие старые раздражающие ошибки так и остались на месте. Но тут приходит новость, приложение решило «улучшиться» — оно сменило имя. Как только я услышал эту новость я сразу сказал жене:»Ну вот и конец пришёл приложению N». Не далее, как сегодя, захожу в Play Market и совсем неудивлённый читаю огромную кучу возмущенных отзывов, которые появились ровно на следующий день после «улучшения». Мало того, что ничего не «улучшилось», так ещё и сломалось там, где до этого работало.

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

К чему я всё это?

Вы вступаете в мир, где вы будете создавать продукты для конечного пользователя, чаще всего это будут бизнес-продукты. Бизнес-продукты приносят прибыль только тогда(если это конечно не какие-нибудь мошеннические продукты), когда они направлены на удобство пользователя, а не когда какой-нибудь самодур, простите, захотел поменять что-то и по его мнению «улучшить». Все вот эти «улучшатели» остались от времён, когда выбора у человека(конечного пользователя продукта) не было и он был вынужден пользоваться одним продуктом. Сейчас выбор у человека есть, но «улучшатели» об этом, видимо, не догадываются. Так вот, прежде, чем принимать решение о будущих изменениях в продукте, проведите опрос, среди сотрудников, среди клиентов, а удобно ли было бы им введение такого улучшения? Принесёт ли оно пользу? В эту ловушку попадаются не только маленькие кампании, но и мастодонты из мира IT, вспомните, например, Windows Vista и Windows 8.

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

То же можно сказать и про ваш код, если он хорошо работает и отлажен, не нужно его чинить. Чините там, где у вас сломано, а не там, где хорошо работает.

Как всегда, приятного вам обучения!

Если понравилась статья, поставьте, пожалуйста, лайк! А если вы ещё не с нами, то обязательно подписывайтесь, тут полезно и интересно.

Источник