Данный циклом статей я планирую рассказать о собственном опыте превращения наемного работника в стартаперы (на текущий момент уже успешно создан и опубликован в AppStore офлайн-браузер «Мегалента»). Некоторые статьи будут содержать технические подробности, а некоторые (как эта) будут скорее рассуждениями на тему как программирования, так и IT в целом.
Термин “девопс” мне на самом деле не нравится, хотя в современной терминологии это самое близкое (но далеко не исчерпывающее) описание круга работ, которые я выполнял более десяти лет на своем последнем месте работы. Какие-то области я изучал достаточно глубоко, какие-то поверхностно, но на протяжении всей своей 20-летней карьеры в IT я постоянно сталкивался с одной странной особенностью, которую решил назвать «культ ненужных знаний». Сразу предупрежу, что это моё сугубо лично мнение, которое я не собираюсь никому навязывать, но я вынужден начать свой цикл статей именно с этого, дабы впоследствии была понятна логика моих на первый взгляд «неправильных» (с технической или с любой другой точки зрения) решений.
Будучи в самом начале своего трудового пути я не мог не заметить, что в каждой области IT есть своя микрорелигия, в лучшем случае пропагандирующая определённый образ , а в худшем — требующая знания кучи специальных терминов и навязывающая некие правила, указывающие на то, что «правильно», а что нет. Причём многие термины либо придуманы специально для этой области, либо имеют в ней специфический смысл, радикально отличающийся от смысла этого термина как в человеческом языке, так и в других областях IT. Чтобы было понятней, о чём я говорю, вспомните количество значений терминов «domain» и «node» в разных областях IT. Соглашусь, что в некоторых случаях (например, в языках программирования или хорошо продуманных фрэймворках) это кажется логичным и выглядит органично. Однако во многих случаях (например, учетные системы, CMS типа «Битрикс» и т.д.) обилие незнакомых и порой нелогичных терминов и правил у человека со стороны вызывают взрыв и зачастую неоправданное чувство собственной неполноценности.
Впервые я заподозрил, что нечисто что-то в Датском королевстве, когда для каждого филиала независимо от его размера (сейчас и в дальнейшем в этой статье при упоминании предприятия я буду иметь в виду моё последнее место работы в качестве наёмного сотрудника) наш человек, который отвечал за IT-инфраструктуру в плане железа, OS и связи, устанавливал минимум по три Windows-сервера (и это без избыточности для надёжности). Я не могу описать технические подробности, т.к. не являюсь специалистом по Active Directory, но это как-то было связано с правилами организации леса и репликации в Active Directory. В том, что всё соответствовало правилам Майкрософт, у меня сомнений нет, т.к. он закончил курсы Microsoft для сисадминов. Да и я потом на каком-то семинаре у майкрософтовцев уточнял, правильно ли мы всё сделали. В итоге, для организации даже одного рабочего места требовалось наличие минимум трёх компьютеров с Windows Server. Возможно, что сейчас всё проще, но в 2003 году это было так.
Прозрение же относительно подобных «правил» в целом и Microsoft в частности у меня наступило несколько лет спустя, когда в ответ на просьбу опубликовать в сторе мой add-on для Экселя я получил письмо от сотрудника Microsoft с обратным адресом типа «loram@microsoft.com». Выходит, жили мы себе спокойно с корпоративными адресами типа IvanK@фирма.com, потом на курсах Майкрософт нам рассказала, что у нас всё неправильно, и мы всё переделали, как они научили. Сделали корневой домен «фирма.com», у него поддомены «город.фирма.com», а в них адреса формата «Имя.Фамилия@город.фирма.com». Сколько же у нас всё плевались и матерились на такие длинные адреса, но, типа, раз правильно так, значит надо так. Ну а Майкрософту, как оказалось, не обязательно свои же правила соблюдать. И, если раньше, когда я в угоду скорости, оптимизации или даже нежелания долго возиться тупо вбивал «костыль», нарушая какие-то догмы и парадигмы, меня не покидало чувство какой-то собственной неполноценности и даже, в некотором смысле, мучила совесть, то теперь подобный внутренний конфликт стал возникать гораздо реже. В дальнейшем моя вольность в интерпретации правил (как внутренних, так и общепринятых в каком-то языке или области) часто была причиной споров с коллегами, которые крайне негативно относились к подобным «костылям». Но бизнес есть бизнес, и если мои костыли ему помогали, то назвать меня полностью неправым было нельзя. Часто в результате этих споров хотелось ещё раз рассказать анекдот про верблюда в зоопарке:
Маленький верблюжонок спрашивает у верблюда-отца:
— Пап, а пап, а почему у нас такие широкие копыта?
— Ну-у, мы ведь живем в пустыне, ходим по пескам, так вот чтобы ноги в песок не проваливались на концах специально имеются широкие копыта…
— А-а, ну да… А зачем тогда такая толстая шерсть?
— Так ведь в пустыне бывает днем жарко, шерсть солнечные лучи к телу не пропускает, телу прохладно, ночью наоборот холодно, тогда она нас греет…
— А-а, понятно… А зачем у нас нижняя губа такая оттопыренная?
— Ну это специально, чтобы верблюжьи колючки есть. Поддеваешь её губой и в рот…
— Пап, ну а зачем у нас горбы на спине???
— Так мы ж ведь корабли пустыни, ходим долго по пустынным просторам без еды, без воды, а в горбах и еда, и вода…
— А-а, ну да-а… Вот только одно не понятно: зачем нам весь этот тюнинг в Самарском зоопарке нужен?!
Еще намного позже, когда в силу разных причин я перестал участвовать непосредственно в разработке нашего корпоративного продукта, я наткнулся на две замечательные статьи: Не дайте Астронавтам Архитектуры вас запугать и Костыльный программист. Они еще немного приблизили меня к формированию текущего отношения к догмам и парадигмам.
Дальше я начал замечать похожую ситуацию и в других, отличных от IT областях. В финансах, парфюмерии, косметике, учетных системах и даже на курсах по английскому для преподавателей – везде были свои микропсевдонауки разной степени проработки и зрелости, надувание щёк людьми, изучившими эти псевдонауки, а также платное обучение и сертификация. В некоторых случаях ситуация была ещё неочевидней и хитрее. Например, известный производитель парфюмерии под предлогом конкурса организовывает обучение и сертификацию в Париже лучшему продавцу месяца/квартала/года. Естественно, продавцы и консультанты забывают о существовании других брендов как за месяц до конкурса, так и ещё на пару месяцев после (хочется ведь пощеголять новыми знаниями). А иногда эта ситуация принимает ещё более уродливую форму: когда наличие сертификата обучения каким-нибудь банальностям становится либо обязательным, либо крайне желательным. Напомню, сейчас я говорю не только об IT. Например, есть какой-то международный сертификат для преподавателей английского, где один из тестовых вопросов звучит примерно так: «Вы просите ученика достать линейку из портфеля и произнести её название на английском. Как называется это действие?». То есть они придумали свой термин даже для этого! В общем, гипертрофированное проявление культа ненужных знаний в моём понимании выглядит так: один талантливый или даже просто здравомыслящий человек что-то делает хорошо, дальше в процессе развития его технологии/идеи какая-нибудь корпорация подхватывает тему и решает, что можно заработать на том, что остальные тоже хотят этому научиться. Создают псевдонауку с кучей терминов, чтобы даже дебил, вызубрив термины и заучив эту науку, смог повторить то же самое, а потом начинают продавать обучение и организуют сообщество «надувателей щёк». А вот потом происходит самое печальное: теряется причинно-следственная связь, и даже если ты обладаешь здравым смыслом и способен просто исходя из этого самого здравого смысла «на ходу» сгенерировать решение профильной задачи, это сообщество всё равно тебя либо отторгает, либо не воспринимает всерьёз из-за незнания этой псевдонауки и её терминов.
Тем не менее осознание вышеописанной ситуации никак меня не приблизило к окончательному пониманию в области «что такое хорошо и что такое плохо» в построении своего продукта. Также я не совсем понимал, как при его создании «правильно» организовывать работу с техзаданием для себя и других программистов, насколько в идеале оно должно быть подробным для максимального соотношения гибкость/эффективность, нужно ли прорабатывать детально архитектуру, рисовать UML и т.д. Ведь, создавая новый продукт, я выбираю технологии, в которых не являюсь спецом, и ни проработать архитектуру, ни качественно оценить сроки не могу априори. Еще ирония в том, что, когда я стану спецом в этой технологии, следующая задача будет или на другой технологии, или текущая эволюционирует так, что я опять буду чувствовать себя дилетантом.
Я понимал, что всему этому есть какое-то логичное объяснение, но формализовать это не мог. И тут на помощь пришла музыка и расставила всё на свои места. Есть классическая музыка, исполняемая симфоническим оркестром. Тут присутствуют архитектор (композитор), ПМ (дирижер), подробное техзадание (партитуры). А есть рок-руппа, которая создает и играет музыку совсем по-другому. Можете себе представить Браяна Мэя, требующего от Фредди Меркьюри ноты для исполнения «Богемной Рапсодии»? В рок-группе все понимают друг друга с полуслова и вносят в исполнение свой вклад за счёт мастерства и таланта. В итоге, я пришел к выводу, что есть три подхода с разными правилами — оркестр, рок-группа, и джазмен. Если я буду делать какой-нибудь фрэймворк или сложный продукт с сотней программистов, то я вынужден буду работать по правилам симфонического оркестра. Для стартапа с несколькими людьми достаточно быть сыгранной рок-группой, но с суперталантливыми музыкантами. Ну а одиночке-саксофонисту ничто не мешает уйти в полную импровизацию и делать всё так, как удобно лично ему и в угоду скорейшего выпуска готового продукта. Другой вопрос, что импровизировать без абсолютного музыкального слуха невозможно – будет полная лажа, но у меня вроде он (в виде многолетнего опыта и профессионального «чутья», где можно вбить костыль, а где лучше сделать системное решение) есть. На этом я успокоился, выбрал ради гибкости и скорости принятия решений вариант «джазмен» и начал работу над продуктом. Как я выбирал какой продукт и под какие платформы делать, какой инструментарий использовать, в какие тупики заходил, – читайте в следующих статьях, а пока что можно оценить результат — itunes.apple.com/ru/app/offlajn-brauzer-megalenta/id1013837150.
Автор:
