Рубрика «Совершенный код» - 51

О книге Боба Мартина «Чистый код»
(Картинка без намека, просто уж очень хотелось котика в статью добавить! Ведь это основной залог популярности в интернетах, правда? :))

У меня очень неоднозначное отношение к книгам Роберта Мартина… В них довольно много здравых и интересных мыслей, но иногда они выражаются столь категорично, что неокрепшим программерским мозгом они могут восприниматься неправильно. Если же мозг читателя достаточно окреп, чтобы воспринимать советы прагматично, то есть все шансы, что ничего нового из этих советов он (мозг или программист) не вынесет.
Читать полностью »

Стихи в коде

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

Читать полностью »

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

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

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

Но при этом «быстро и просто» не значат «плохо».

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

И вот тут я хочу напомнить почему-то забываемый всеми момент.

Авралы, расходы и головную боль мы поимеем только тогда, когда система закрыта. Если она открыта, все эти радости достанутся кому-нибудь другому.
Читать полностью »

Совершенный код и реальные проектыУ меня есть проблема — я перфекционист. Я люблю совершенный код. Ведь это не только правильный подход к написанию программ, но и настоящее искусство. От чтения хорошего листинга я получаю не меньше удовольствия, чем от чтения хорошей книги. Проектировать архитектуру большого проекта ничуть не легче, чем проектировать архитектуру большого здания, а в случае хорошей работы — результат не менее прекрасен. Порой меня завораживает то, как изящно переплелись паттерны проектирования в создании совершенной программной системы. Меня восхищает внимание к деталям, когда абсолютно каждый метод настолько прост и понятен, что претендует на место классического примера совершенного кода.

Но, увы, всё это великолепие разбивается о суровую действительность и реальные проекты. Если мы говорим о продакшн-проекте, то пользователей не волнует, насколько красив ваш код и насколько хороша архитектура, их волнует, чтобы проект хорошо работал. Но я всё равно считаю, что в любом случае нужно стремиться писать правильно, просто при этом фанатизма быть не должно. После чтения различных холиваров на тему правильных подходов к написанию кода мне в глаза бросилась одна тенденция: каждый пытается применить означенные подходы не в целом к программированию, а только к своему опыту разработки, к своим проектам. Многие не осознают, что хорошие практики — это не абсолютные правила, которые должны строго соблюдаться в 100% сценариев, это лишь советы о том, как следовало бы поступать в большинстве ситуаций. На каждую хорошую практику всегда можно придумать несколько дюжин примеров, в которых она работать не будет. Но это вовсе не означает, что хорошая практика не такая уж и хорошая, просто её применили не к месту.

Читать полностью »

Комментировать или не комментировать?По-настоящему хороший комментарий — тот,
без которого вам удалось обойтись.
© Дядюшка Боб

В последнее время меня стали очень утомлять оживлённые дебаты о том, нужно ли комментировать код. Как правило, по одну сторону баррикад — самоуверенные джуниоры, имеющие непререкаемую позицию вида «А как же его не комментировать, ведь без комментариев непонятно будет!». По другую — умудрённые опытом сеньоры. Они понимают, что если возможно обойтись без комментариев, то «Лучше бы, чёрт возьми, так и сделать!». Наверное, у многих жажда комментировать идёт со студенческой скамьи, когда товарищи преподаватели заставляли комментировать каждую строчку, «чтобы студент лучше разобрался». В реальном проекте не должно быть кучи комментариев, которые только и делают, что засоряют код. Впрочем, я не агитирую вообще не писать комментарии, но если вам удалось написать такой код, который не требует пояснений, то расценивайте это, как свою маленькую победу. Сразу хотелось бы сослаться на нескольких очень умных книжек, на основе которых формировалось моя позиция. Я люблю и уважаю авторов этих работ, полностью разделяя их мнение.

Читать полностью »

Советы Google по кодированию на языке Python. Часть вторая: советы по форматированию исходного кода
Доброго времени суток. Вот и пришло время для публикации второй части так понравившегося многимам перевода стайл гайда для языка Python от компании Google, (первая часть бережно хранится хабром). Теперь мы коснемся напрямую форматирования исходного кода на языке программирования Python. Как известно, чистота — залог здоровья, а чистота программного кода — залог уважения коллег и (в идеале) поощрения от кого-нибудь свыше. Вообще, Python сам по себе является хорошо читаемым языком, и даже синтаксис данного языка призывает к порядку в коде (и, как следствие — в голове). Но каждый из нас сам себе документатор и сам себе творец оформления. А как уже говорилось однажды — ко мнению авторитетных товарищей нельзя не прислушиваться. Итак, вторая часть Google Python Style Guide — Python Style Rules ждет Вас под катом.
Читать полностью »

Советы Google по кодированию на языке Python. Часть первая: советы по программированию
Хай Хабр!
Сегодня я хочу представить, дорогому хабрасообществу свой первый хабраперевод. Программировать на языке Python — подобно песне. Но еще лучше, когда Ваш код читаем и понятен, а значит чуть более поэтичен, чем обычно бывает производстве. У каждого свои правила и свои стереотипы относительно написания и оформления исходного кода на каком бы языке он ни был написан. Множество копий сломано о щиты на форумах, но как ни крути нельзя не считаться с мнением авторитетных товарищей. Так что сейчас будет представлен перевод первой части стайл-гайда для языка Python от Google. А коснется он именно постулатов написания кода (вторая часть тоже скоро появится, а посвящена она будет форматированию исходного кода). Сразу предупреждаю: тут много (если не большинство) прописных истин, которые все знают уже давно. Но я искренне надеюсь, что Вы сможете найти тут что-то новое, или хотя бы вспомнить старое. Приступим под катом.
Читать полностью »

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

Как же они этого добиваются?

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

Читать полностью »

    Мое становление как  программиста началось в 2005 году  и продолжается по
сей  день. Несомненно,  многие  читатели смогут  похвастаться более  обширным
опытом,  но речь  пойдет о  другом.  Мой профессиональный  рост наложился  на
интересный период  - повышение культуры  программирования в рунете,  если это
можно  так  назвать.  Профессионалы  были  всегда,  но сегодня  подкованность
среднего  программиста(во всяком  случае  в сфере  best pracices)  несравнимо
выше, чем тогда.

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

Читать полностью »

Начало Код с душком
Техника: Составление методов

В продолжении, техника рефакторинга по книге Рефакторинг. Улучшение существующего кода Мартин Фаулер.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js