Пока работает не трогай

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

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

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

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

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

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

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

Источник

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

Введение

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

Преамбула

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

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

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

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

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

Источник

О корректности «работает — не трогай» и понятии «так правильно»

Я для себя переформулировал его как «работает — не ломай» (улучшать можно, при условии, что . ), но это тоже несколько не то, отчасти из-за самоочевидности. И вот недавно в рассылке UAFUG пролетела такая цитата за авторством Michael Pigurnow:

Вот тут всё становится на свои места, особенно если вспомнить не менее известное «make it work, make it right, make it fast» (именно в такой последовательности, и каждое следующее не раньше имеющегося предыдущего). Остается только с виду незаметный, но очень важный вопрос — а что же такое правильно? Вроде всем понятное слово, но каждый под ним понимает что-то свое, обычно интуитивно понимаемое и расплывчатое. Более того, никакого абсолютного «правильно», общего для всех и всегда, нет и быть не может. Тогда что же это?

Я бы определил «правильно» как 3 компонента — цели, ценности и приоритеты. Они неразрывно связаны друг с другом.

• Правильно что-то делается или нет, зависит от цели, того, что требуется получить — что правильно в одной задаче, может быть неправильным в другой.
• При той же самой цели, делать что-то можно разными способами. Как выбирается способ? Между задачами соблюдаются какие-то более-менее постоянные ценности, принципы. Например, «деньги не пахнут» или «всё надо делать качественно». Ценности для человека — это то, что значимо, к чему он неравнодушен, на что ему не похуй. То, что можно описать словами «хорошо» и «плохо», в отличие от всех остальных вещей, к которым нет ничего, кроме равнодушия. Ну типа, «писать понятный читаемый код — это хорошо», «ломать мне посреди ночи работавший сервер, который я поеду чинить — плохо». (Замечу в скобках, что речь стоит вести не о декларируемых ценностях — если человеку плевать на утверждение «уступать старушкам место в автобусе — хорошо», реальной ценности для него это не представляет. Но эти темы уже совсем-совсем оффтопик.)
• Наконец, ценности как сами не равны между собой, так и могут вступать в конфликт с целями (точнее, обычно подзадачами, целями помельче, на которые бьется исходная). Или бывает, например, нехватка ресурсов или чего-то еще — так, что всё вместе удовлетворить нельзя. В этом случае приоритеты определяют, что из целей и ценностей сейчас важнее, а что, быть может, отбросить вовсе (скажем, в соответствующей ситуации «когда моим детям жрать нечего — плохо» перекроет собой «писать нечитаемый код — плохо»). Когда говорят «в той ситуации было правильно поступить именно так» (а обычно, мол, положено не так) — ноги растут именно отсюда.

Легко видеть, что, например, при наличии ценности «рабочий плохой код лучше перспективной идеи» получим следствие «если это не работает — это неправильно» (но при определенных обстоятельствах приоритеты могут изменить вывод на прямо противоположный, скажем, на отрезке в 10 лет).

Или что изо всех сил сидеть на FreeBSD 4.11 и бэкпортить патчи — неправильно, потому что трата времени админа на бэкпорты — не в целях и не в приоритетах.

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

Источник

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник