Про Programming Pro

Все чаще сталкиваюсь с ситуацией, когда на проект выделяется специальный человек с гордым названием "Аналитик", который является, по существу, всего-лишь записывателем слов, которые он услышал от заказчика. При этом задача часто даже не подвергается критическому анализу. Как услышал, так и перенес в таск-трекер. Более того, разработчики требуют, чтобы их оградили от заказчика, разжевали задачу и положили в рот, только тогда они радостно снимают с себя ответственность и делают "задачу по ТЗ". Когда на выходе получается самокат вместо вертолета, они говорят, что "так было в аналитике"...

Есть огромное количество статей на тему Continuous Integration, Continuous Delivery и прочих мастхэв практик современной разработки, и почти везде рекомендуют начинать с CI. С этим нет проблем, когда система только начинает разрабатываться, но что если система уже существующая? План действий обычно выглядит так: Надо бы начать -> ??? -> Профит (все, что там пишут про Netflix, Amazon и Google). То есть внедрение CI начинается без предварительной подготовки системы, при таком подходе накладные расходы только увеличиваются, а не снижаются как ожидалось...

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

Очень интересно наблюдать за командами, которые только перешли на разработку по гибким методологиям. Пока они перестраиваются и, по факту, живут маленькими waterfall’чиками, они задаются следующими вопросами: - А что, тестировщики (QA), первую половину спринта в гибернации находятся? - А как по завершению спринта на прод выкатывать, если тестировщики физически не успеют проверить то, что мы накодили в последний день спринта? - А что, у тестировщиков сдвинутый на неделю относительно разработки спринт?...

Все чаще слышу высказывания типа “монолиты не так уж плохи”. На этом основании можно предположить, что микросервисы благополучно миновали пик чрезмерных ожиданий и перешли в стадию избавления от иллюзий в хайп-цикле Gartner. Пока этот архитектурный подход находился на пике, многие команды успели прострелить себе ногу (а то и обе) применяя микросервисы. Видел даже примеры, когда из монолита делали прям какие-то наносервисы и разделяли их на слои API, бизнес-логика и слой доступа к данным (мне страшно представить как они справля(ются/лись?) со сложностью эксплуатации этого хозяйства)...

Часто сталкиваюсь с тем, что люди с опытом работы более 3-х лет backend разработчиками про индексы могут рассказать только то, что они ускоряют поиск. Для того, чтобы разобраться в этих вопросах предлагаю использовать аналогии из реального мира. Лично мне это прием очень сильно помогает разбираться в новых для меня областях. Для примера возьмем бумажный телефонный справочник. Предположим, что внесенные в него ФИО с телефонами идут в порядке добавления записей (сначала добавлен Петров, затем Васичкин, потом Иванов и еще млн других записей)...

Я вот все думаю, что определяет классного разработчика? Почему два выпускника одного и того же ВУЗа по уровню полезной отдачи - как небо и земля? Давайте отбросим фактор "природного таланта". Таланты редки, а за каждым реальным талантом стоит, простите, впахивание и работа над собой. Что создает качественного и талантливого разработчика? Это ведь профессия, ей учат. Учат системно и с важным лицом. Даже экзамены сдают все студенты поголовно, а умеют делать что-то толковое - единицы. Вывод: формальное образование - это не решающий фактор...