January 10th, 2019

404

О разнице в именовании переменных

Во, ещё, в догонку. Существует большая разница в именовании переменных в математике и программировании. Почему математики счастливы с a,b,c,x,y,z,i,j с примесью букво-типизации (греческие - угол, abc - грани, xyz - координаты, ijk - индексы), а программисты от такого должны кривиться?

Потому что у математиков переменные выступают в роли данных. Ни один программист не даёт имена собственные для данных (мы будем называть первый байт файла "first_of_the_kind", второй байт - "second" и т.д.). Если называет - то это уже константы (которые именованные и у математиков, и у программистов). Он эти данные обрабатывает, используя именованные конструкции - типы, структуры, переменные, имена функций, etc.

Математик делает то же самое. Его функция - f, но он-то говорит не про 'f', а про, например, "формы", "линейные комбинации", "полином", "квазиполином" и т.д. То есть имена собственные во все поля. Иногда именование становится жутким "кососимметрическое тензорное поле на многообразии", но стремится к точной передаче сути явления. Математики дают имена собственные для сущностей, которые находятся в их фокусе внимания. А весь болейрплейт идёт в самой компактной возможной нотации c = aij. У программистов он тоже идёт, какой-нибудь for k, v in d.items(): yield "%s:%s" % (k, v) отличный пример такой нотации. Оно настолько вне фокуса внимания, что можно однобуквенные переменные.

Но большинство программистов решает не математические задачи. Я бы даже сказал не задачи, а 'make things which do things'. И там фокус внимания очень часто оказывается на том, что и с чем делается, а не решается. И в этом случае самые большие усилия по именованию приходятся именно на переменные и функции (классы), а так же их типы, потому что это как раз и есть описание "как, что и с чем делается". А математическая часть проблематики (алгебраические поля, алгоритмические вопросы структур данных и т.д.) - она как раз вне фокуса. Нужна, но не важна.
404

вызовы в зоне комфорта

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

Но при работе в зоне комфорта challenge другой: всё сделать правильно. То есть "получилось" не интересно, заведомо известно, что получится. А вот challenge, чтобы оно было безупречно. То самое, "всё сделал правильно", когда можно защитить каждый элемент, объяснить зачем оно так и почему так лучше, чем не так. Все известные антипаттерны исключены, читаемо, понятно, понятно до уровня "можно скользить глазами". Закончил писать - оно работает, и без багов (я про баги начального периода, когда оно даже success path пройти не может). code coverage за 90 (предпочтительнее 100), тесты покрывают все три случая (good, sad, bad), ошибки обрабатываются унифицированным образом. Нет незаконченных конструкций (тут мы будем наследоваться - и три уровня наследования а на выходе один реальный объект), нет гиперабстракций (настолько обще, насколько можно, но не так, чтобы потерять суть решаемой задачи), нет оверфиттинга (работает ТОЛЬКО в заданном сценарии и никакие другие сценарии неприемлимы). Удобно в работе, удобно в тестировании, удобно в использовании. Готово к разумному расширению и изменению функционала, но не собирается решать все задачи всего мира. Тесты разумно используют моки, но не так, чтобы "мока в моке видит мок".

То самое заветное "чтобы потом не было стыдно". Код, которым не нужно гордиться (там нет know how для неизвестной задачи), но который с лёгкостью можно показывать как образец того, как надо решать задачи такого класса.

... А там есть ещё и challenge второго порядка: сделать всё это с минимальным количеством рефакторинга, в TDD-стиле, и т.д.

(это по мотивам утилиты, которая грузит результаты бенчмарка и лог эвентов во время бенчмарка в инфлюкс).