Первое правило программиста работает не трогай

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

Введение

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

Преамбула

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

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

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

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

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

Источник

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

Если работает – ничего не трогай! Как мы неосознанно помогаем себе сами

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

Среди моих знакомых тьма программистов. Наверное, это оттого, что в мире их вообще сейчас тьма-тьмущая. Общаясь с ними, я немножко вникла в их особый юмор, фольклор и магию. Да-да, именно магию. Потому что любой программист расскажет вам массу историй о том, как ОНО работало – непонятно КАК и непонятно ПОЧЕМУ. А любой желающий разобраться в причинах бывал сурово наказан отказавшим раз и навсегда кодом (ранее прекрасно работавшим).

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

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

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

Что-то было нарушено в ее «протоколе любовного этикета»

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

В те времена я легко раздавала телефоны интересным молодым людям и потом отслеживала степень их вовлеченности: пригласит ли на свидание? Позвонит? Напишет СМС? Или просто хочет дружить? У нее все было наоборот: сначала секс, а потом интрига: возьмет ли телефон? Спросит ли, как зовут. Удивительное создание. Причем за нее почему-то совсем не было страшно.

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

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

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

Активное сексуальное поведение, готовность броситься в объятия к первому встречному – продолжение грустной истории детства и яркий пример того, как бессознательное человека стремится «починить» травму, не сообщая никаких сигналов «наружу». Недостаток любви в детском возрасте восполнялся активной сексуальностью в юности.

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

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

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

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

Психолог работает с этими паттернами (схемами) только в том случае, если есть запрос. Но это происходит нечасто. Чаще такие люди попадают в терапию, когда плотину «прорвало», когда адаптивный механизм дал сбой. И работать в ситуации такого кризиса, безусловно, сложнее.

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

Источник

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

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

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

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

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

1. Бизнес

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник