Программирование — не сама цель, программирование — средство. Равно как и построение архитектуры проекта. Но, увлекаясь, можно ой как нагрешить!
Добрый день! Меня зовут Гоша, и я пишу код.
*жидкие аплодисменты, понимающие кивки*
Я уже лет 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 языка. Это тоже программирование, это тоже код, и по возможности его нужно сохранять и переиспользовать в виде скриптов или шелл-функций, чтобы в следующий раз не тратить время на уже решенную задачу (т.е., не заниматься сатанинским делом еще раз).