Записки программиста

Вы, наверняка, знаете, как это бывает. Ой, у нас тут такие тяжелые вычисления / так долго тянутся данные из базы. А давайте просто прикрутим кэшик. Что может пойти не так? Так вот, опыт показывает, что пойти не так может очень и очень многое.

Типичная ситуация. Программист читает книжку о новом, или не таком уж и новом, языке программирования, базе данных или иной технологии и сгорает от нетерпения поскорее ее попробовать. Возможно, он узнает о технологии или подходе не из книги, а из подкаста или доклада на конференции, не суть важно. Другая похожая ситуация — «в нашем проекте все очень плохо, потому что мы используем DynamoDB (пишем на Java), давайте все перенесем на PostgreSQL (перепишем на Erlang)». В этой заметке я собрал веские причины не поддаваться соблазну протащить новые игрушки в продакшн.

Когда вы начинаете использовать auto scaling groups, перед вами встает новая интересная проблема. На серверах, входящих в группу, нужно как-то смотреть логи, но размер и состав группы постоянно меняется. Ходить по SSH и делать tail -f больше не вариант. Есть много решений проблемы, как SaaS, так и не SaaS. Среди последних следует отметить Syslog, Graylog2 и Logstash. Однако в рамках это заметки речь пойдет об одном из SaaS решений, а именно Logentries.

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

В любой команде рано или поздно появляется человек, который совсем недавно прочитал книжку по Lisp или осилил Template Haskell и потому ему не терпится применить метапрограммирование на практике. Однако проблема заключается в том, что в большинстве случаев макросы или шаблоны создают больше проблем, чем решают. В этой заметке будет показано, почему так.

В данной заметке я намерен снова напомнить о том, что программирование — это, оказывается, не только выбор правильного языка и набивание кода. И речь идет не о наличии социальной/психологической составляющей процесса, вовсе нет. Речь все о той же, технической, стороне.

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

Мне нередко доводилось видеть печальную картину. Человек вроде как умеет работать с Git, знает там всякие git commit и git push, но плохо представляет, что именно с ними нужно делать. На практике это выливается в параллельную работу всей команды над пятью разными бранчами и мержами этих бранчей друг с другом, сорванными сроками потому что «ой, наш билд еще не стабилен», желание смотреть на «карты метро» при помощи IDE или gitk/gitg/tig, уговоры команды взять и дружно заставить себя использовать утилиту gitflow и в прочие ужасные вещи.

Снова и снова я сталкиваюсь с тем, что QA, тестировщики, или как их там у вас называют, не умеют нормально писать багрепорты. Что хуже, они и не хотят учиться делать это правильно. Что намного хуже, часто это касается не только QA и багрепортов, а команды и тикетов вообще в Jira, Trello, или чем вы там пользуетесь.

Пожалуйста, поймите меня правильно. Си я люблю и уважаю. В студенческие годы я провел много увлекательных вечеров за изучением WinAPI и POSIX, написанием своих архиваторов и даже драйверов для Windows XP. Однако так сложилось, что в своей профессиональной деятельности я пишу на более высокоуровневых языках. Вот о том, почему в программах, написанных на таких языках, следует избегать использования Си, мне и хотелось бы поведать.