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

7 золотых правил одного программиста

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

Компьютер всегда прав

Самая раздражающая ситуация в программировании — когда код верный, но не работает. “Да тут три строчки, блин, просто негде ошибиться! Наверное баг! Пойду потрачу три дня на изучение баг-репортов компилятора/интерпретатора/фреймворка. ”. Возникает чувство, будто компьютер над вами издевается!

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

Успокойся и все получится

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

Самое сложное — начать

Бывает смотришь на задачу, и не знаешь как к ней подступиться. С какой стороны начать? И вообще, что-то лень сегодня. «Посижу 10 минут во Вконтактике, потом начну. Ну, после кофе. Ну вот, старый код надо порефакторить, и потом начну. А это что-за таск с низким приоритетом? Выполню его и точно начну…».
Просто начните. Начните с любого конца. Разбейте задачу на мелкие части и начните выполнять их. Перестаньте откладывать, отбросьте посторонние мысли, сконцентрируйтесь на задаче, и начните работу. Дальше пойдет как по маслу.

Читай книги

Читайте книги. Я еще раз напишу: Читайте книги!
Почему-то многие программисты совершенно игнорируют книги. “Я и на работе отлично просвещаюсь”, “У меня нет времени”, “Я читаю статьи в интернете”. Это все здорово, но лично я считаю, что лучший источник знаний — это все еще книги. Я стабильно покупаю по одной-две книги в месяц, плюс время от времени перечитываю что-то старое. Не буду врать, у меня на полке скопилась внушительная стопка того, что я купил, но пока не читал (как с играми в стиме), но я дойду, обязательно дойду.

Знай свои инструменты

Не поленитесь выделить время на подробное изучение инструментов и технологий с которыми вы работаете. Это многократно окупится. Досконально изучите все возможности языка на котором вы программируйте. Просто возьмите, и прочтите официальную документацию от корки до корки. Не используйте IDE только в качестве редактора кода, в любой современной среде есть куча инструментов для повышения качества кода и вашей продуктивности. Не используйте фреймворк только как скелет архитектуры. Изучите его и он сэкономит вам уйму времени. Разберитесь в тонкостях системы контроля версий. Чем лучше вы знаете свои инструменты, тем больше работы они делают за вас.

Не будь перфекционистом

Выше я писал, что самое трудное — это начать. Так вот, закончить — тоже не всегда легко. Отлаживать и рефакторить код можно бесконечно. “Что-за длинный метод?”, “Может это в отдельный класс?”, “Было бы удобнее если бы. ”, “А вдруг потом понадобится. ”, “А вдруг. ”. В программировании нельзя быть перфекционистом. Проблема в том, что достаточно почитать Роберта Мартина или Банду четырёх, как тут же возникает желание переписать нафиг весь свой код. Нужно понимать, что идеального кода нет. Я придерживаюсь правила: “Код должен работать без багов, быть тестируемым и читаемым”. Все. Пока код метода отвечает этому требованию, я его не трогаю. Даже если в нем два цикла, три условных оператора и четыре параметра.

Источник

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

Блог веселого программиста

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

Золотое правило админа

Если кто-то еще не знает, это правило звучит так:

Работает – не трожь!

Теперь собственно сама история. Когда-то у меня стояла OpenSUSE 10.3, в которой был Perl 5.8.8. С выходом OpenSUSE 11 я решил сделать апгрейд, который на первый взгляд прошел удачно. Все было хорошо, пока я не попробовал запустить несколько своих ботов.

Выяснилось, что в 11-й версии Perl проапгрейдился до версии 5.8.10, и основные модули по работе тоже подвергались апгрейду. Все товарищи, кто прямо или косвенно пользовался модулем HTTP::Message скорее всего в логах увидили нечто подобное:

HTTP::Message content not bytes

и после этого долго ломали голову над своим кодом. А на самом деле бага в коде была на стороне мантайнера HTTP::Message, версия libwww-perl-5.810 оказалась глючной до безобразия. И самое интересное, эта версия оказалась в дистрибутиве OpenSUSE 11, поэтому совсем безболезненно апгрейд не прошел.

Да, эта проблема решается апгрейдом libwww-perl до более свежей версии, что собственно я и сделал. Сейчас это libwww-perl-5.814, и пока багов в ней не заметил.

Вот и думай после этого, а нужен ли был апгрейд, если он принес столько геморроя?

Золотое правило админа : комментарий

Ох и точно, когда то тоже со мной такой казус случился. На фирме бухи работали в клиент банке (версию не помню) но там был какойто глюк с отчётностью (не конвертилась или ещё что то – не суть)… Работать можно было, но им не нравилось что пару строчек нужно было руками напечатать )) Ну я скачал новый релиз для теста поставил себе, так всё заработало нормально итд. Ставлю на клиентов, перезагружаюсь, и бац. Вообще всё пропало (базы старых версий не поддерживает-тока конвертером) ну я ессно ни про какой конв не знал. И у меня даже сердце приостановилось, сразу представил как стою перед начальником и тупые тётки меня отчитывают. Стало не по себе как то… Поехал в банк за старой версией, они мне там рассказали про конвертер, но я взял на всякий пожарный старую версию оболочки. Приехал поставил всё работает. А бухам я программку намаздырил которая строку добавляет в memo при нажатии на ктрл+д… Да уж и правду говорят – РАБОТАЕТ – НЕ ТРОЖЬ.

Источник

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

Введение

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

Преамбула

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

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

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

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

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

Источник