can3p (can3p) wrote,
can3p
can3p

Category:

Про программирование, выпуск 1

Неохота писать абстрактное, поэтому решил написать о том, про что душа болит. Хочется описать то, что по моим наблюдениям почти наверняка работает одним способом (всегда плохо или всегда хорошо). Начнем с такого.

Один код для разных целей

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

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

Другой классический пример - одна константа на два случая. Определили вы, скажем, что ALPHA = 500, а потом эту константу используете как для количества товаров на странице, так и для количества товаров в имейл-рассылке. Все чудно и здорово во время разработки, но я прямо вижу, как к вам подходит пм и говорит, что 500 для рассылки много, дава 10, а у вас эта константа уже по всему коду распихана, и никто уже не вспомнит, что именно и для чего.

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

Самодокументируемый код

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

Например, мы футер будем добавлять только для бананов.

hasFooter := productKind == 'bananas'

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

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

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

Читаете вы код, а там вдруг без объявления войны:

bla.ToString()

Что это значит? В сообщении к коммиту об этом написано не будет. Вы же не помните уже наверняка, что когда-то дебажили библиотеку Х версии 1.2.3, и в ней есть внутренный кеш, который можно так заполнить. И как переменную не называй, ничего не поможет, только правильно составленный комментарий спасет. Причем не только в стиле // fill the cache for library x, а развернутый - dima: we're using library x to send emails. To make it faster we need to warm up library to generate all emails faster. Имя поможет тем, кто будет медитировать над этим кодом через 22 ребейза и три хард пуша.

Tags: coding
Subscribe

  • Из прочитанного. Выпуск 60

    Добавлю новый тег, т.к. какое-то количество книг я добавил себе в список на прочтение после прослушивания подкастов Юзефоыич на медузе. 1) Midnight…

  • Ссылки и указатели

    Наткнулся на один осмысленный пример применения ссылок вместо указателей. TLDR: указатели могут быть пустыми, а ссылки - нет. Так что ссылка в…

  • Субботник

    Ну или не совсем. Каждый год раздражаюсь, но в этом просто решил принять как факт. Каждый сентябрь в Амстердаме - это месяц раскопок. В промышленном…

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 1 comment