Аналитика
Писать код — грех!

Писать код — грех!

Добрый день! Меня зовут Гоша, и я пишу код.

Программирование — не сама цель, программирование — средство. Равно как и построение архитектуры проекта. Но, увлекаясь, можно ой как нагрешить!

Добрый день! Меня зовут Гоша, и я пишу код.

*жидкие аплодисменты, понимающие кивки*

Я уже лет 10 пишу код и только сейчас стал осознавать, что это проблема. Всё началось в школе, я и не думал, что это перерастёт во что-то больше. Это были уроки информатики, основным мотиватором служила фраза «Нравится играть в игры? Так не лучше ли их делать?». «Естественно, лучше!» — думал я и продолжал постигать азы. Писать игры — это круто, весело… Но далеко не все идут в гейм-дев — об этом нам никто не говорил. Не говорили об этом и в университете, хотя некоторое понимание этого уже пришло.

К слову, я таки написал несколько игр:

  • «Жизнь» Конвея — на C (с Unix-, INET- сокетами), на Perl (с Tk), на TASM под DOS, JavaScript;
  • змейка — Java, TASM;
  • шашки — Perl;
  • морской бой — на TASM (с игрой по сети, где сеть — нуль-модемное соединение по COM);
  • прочие полезные мне, но бесполезные другим игры.

Не всё так плохо — делать программы, которые позволяют делать многие вещи проще, быстрее, делать полезное, за что получать и гешефт… А что есть «польза» и как она оценивается? К сожалению, немного не так, как я думал в детстве. А думал я примерно следующее: производство — полезно, продажи/проче сопутствующие — нет. Всё это оказалось, мягко говоря, не так.

Но чёрт с ним! Продадимся с потрохами менеджерам/продажникам/маркетологам, дабы быть адекватными миру!

Итак, моральный вопрос утрясли, теперь дело за утилитарностью. В последнее время я стараюсь не писать код для миграций, писать его меньше. На каждый крупный проект приходится не один десяток миграций различного типа: внутренние обновления, нормализация данных, «быстро поправить, а то раньше мы не знали, что…». Если на каждый чих писать код, более того: разрабатывать в рамках проекта, сил и времени не хватит. Куда проще написать хитрый запрос в базу/однострочник, а то и просто отбрехаться от ненужных телодвижений. И это отнюдь не бытовая лень. Этот код тоже придётся поддерживать, документировать — получаем увеличение проекта при том же наборе возможностей. Не пишите КОД, если можете написать запрос в бд или простенький скрипт.

К слову, если быть более-менее эрудированным в области IT, например, Unix-утилит, то можно большую часть работы просто сократить до перечитывания man’а. Часто то, что нам нужно сделать, уже сделано быстрее, качественнее, чем мы может себе позволить. Нужно написать web-паука? А wget не умеет? И многое другое — стоит только задуматься о проблеме, а не о том, как прекрасно мы сейчас это решим.

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

Итак, меньше кода, больше решений проблем.

И вообще, есть что-то в программировании сатанинское (да, теперь немного религии :)). Простой пример: пишется софт для жизненно-важной системы. После чего система выходит из строя… Вот и «не убий». Да и исполнение множества вещей за доли секунд — есть попытка приблизиться к Богу. А уж то, что многие уже давно сотворили из Интернета, компьютера кумиров — уму не постижимо! Многие уже в «красном углу» держат не каноничный телевизор, а ноубтук! А то, как греются мобильные (имеются в виду не только телефоны) девайсы, заправленные ужасными программами — это ли не адово пекло?

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

2014-05-28 09:05:36 annulen

YAGNI

Основное содержание статьи можно сформулировать в виде двух старинных принципов программирования: YAGNI и «не изобретай велосипед/колесо/…».

Первый говорит о том, что не надо делать гибкую архитектуру там, где задача не требует гибкости. В противном случае имеем удорожание разработки и feature creep из-за желания все-таки найти применение гибкости своей архитектуры. Такая архитектура легко устаревает, поскольку внезапно возникают требования, которые не удалось предугадать заранее, и приходится впиливать их костылями, так как сделать «красиво» из-за сложности системы будет слишком долго. В то же время, простая (на сколько возможно, но не проще(тм)) архитектура с годами не превратится в лапшу, если не забывать о рефакторинге.

Второй принцип очевиден и стирает разницу между, например, использованием готовых модулей CPAN в коде на Perl и использованием шелл-скриптов с пайплайнами из системных команд. И то, и другое является выражением переиспользования кода и использования наиболее высокоуровневых возможностей при программировании. SQL — это декларативный язык 4-го поколения (если правильно помню), его уровень намного выше ЯП, обычно используемых для написания бизнес-логики, так что неудивительно, что решение на нем получается наиболее удобным для человека (а возможно, и более эффективным по количеству процессорных циклов)

Однако, я не согласен с выводом в конце статьи — по сути это призыв к написанию throw-away кода. Ошибочно считать однострочники, шелл-скрипты и SQL-запросы чем-то, не являющимся кодом — это тоже код, только написанный на максимально высоком уровне, удовлетворяющий принципу YAGNI и, возможно, не учитывающий некоторые corner cases задачи (часть философии unix;) и best practices языка. Это тоже программирование, это тоже код, и по возможности его нужно сохранять и переиспользовать в виде скриптов или шелл-функций, чтобы в следующий раз не тратить время на уже решенную задачу (т.е., не заниматься сатанинским делом еще раз).

Также может быть вам интересно:

Высшее обрезание

Читать »

Маленькая книга о Redis

Небольшая книга о Redis, её особенностях, настройке.

Читать »
Фото Как настроить отправку почты из Django

Как настроить отправку почты из Django

Письма об ошибках, отчёты на почту, восстановление паролей - всё это полезно при работе с сайтом. Django предоставляет удобный способ это сделать с минимумом настроек!

Фото Добавляем поддержку медиа-файлов в Django проект

Добавляем поддержку медиа-файлов в Django проект

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

Фото Настройка журналирования (логирования) в Python с примерами

Настройка журналирования (логирования) в Python с примерами

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

Фото Так ли безопасен Linux? Несколько коммитов с уязвимосятми в stable

Так ли безопасен Linux? Несколько коммитов с уязвимосятми в stable

Исследователи сумели пройти code-review с реквестами в ядро Linux, заведомо содержащими добавление уязвимостей.

Фото Добавляем переменные в контекст Django шаблонов (свой контекст-процессор)

Добавляем переменные в контекст Django шаблонов (свой контекст-процессор)

В Django вы можете передавать данные в шаблоны посредством контекстов. Контекст передаётся из контроллера (view в терминах Django), однако, если одни и те же данные нужны в разных местах, лучше сделать свой контекст-процессор.

Фото Пример своей консольной команды в Django проекте

Пример своей консольной команды в Django проекте

Если вы работали с Django проектом, то, скорее всего, запускали команды из консоли (manage.py). В Django есть простой способ писать свои команды для управления проектом.

Фото Разграничение прав доступа на Django сайте

Разграничение прав доступа на Django сайте

Почти на любом веб-сайте необходимо разделять пользователей на группы и предоставлять им разные возможности. В Django есть довольно серьёзная система прав доступа для пользователей - давайте её рассмотрим!

Фото Пользователи и их создание в Django - своя регистрация на сайте

Пользователи и их создание в Django - своя регистрация на сайте

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