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

  • В Москве

    Первые дни в Москве вызвали довольно странное впечатление. Как-то так получилось, что в России опять теория разошлась с реальностью, где-то слегка,…

  • Временной аспект

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

  • Из прочитанного^Wнедочитанного. Выпуск 58

    Решил протись по новой и не очень русской литературе 1) Третий роман писателя Абрикосова, Денис Драгунский 4 / 5 Если бы я открыл книгу…

  • 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