Жизнь несколько сложнее, на самом деле. В моём случае объяснять генеральному, что он не прав, это было не что-то страшное и ужасное. Человек компетентный, по утрам он ещё не терял адекватность под нагрузкой, и с ним можно было конструктивно подискутировать. Спокойно признавал свою неправоту, когда для него открывались новые обстоятельства. Собственно, как и я. У нас были с ним очень разные наборы данных, синхронизация их помогала найти решения для иных вопросов.
Но генеральный директор — это не сверхчеловек, он точно так же, как и все остальные, действует в системе своих ограничений. Там наверху свои проблемы, и я ещё не видел человека, который с ними справлялся бы идеально. Но видел немало людей, которые знали, как идеально, и их наверху размазывало под нагрузкой.
К слову, мне как-то несколько раз в грубой форме высказывать своё негативное мнение об совладельцах-миноритариях компании, причём им лично. Что мне за это было? Меня не уволили, меня не оштрафовали, меня просто посчитали грубым и неуравновешенным человеком. Поэтому с тезисом о «быстро уволят» я не могу согласиться.
P. S.
Описанная вами проблема с самолётами уже решалась. У части самолётов выход производится через шасси. У Су-34 так, если я правильно помню. В поворотных механизмах для сегментов корпуса нужды нет. Сейчас даже поворотные механизмы для крыльев самолёта теряют свою актуальность.
Если брать SQL, то это было общее требование по компании. На самом деле, мы ещё согласовывали новые таблицы, поля и индексы. Когда у тебя облако, а в нем многие тысячи схем клиентов, факт того, что, например, под индексы и таблицы тот же PostgreSQL создаёт отдельные файлы, начинает очень больно кусаться. Как и неоптимальные запросы, которые исполняются миллионы раз.
У компании был собственный ЦОД, достаточно мощный. Постоянно расширять его мощности и тратить на это миллиарды рублей, было нецелесообразно. Поэтому началась системная работа над оптимизацией запросов.
Говоря честно, основная сложность моего модуля была именно в интеграциях и контроле за потоками данных. У меня были хорошие компетенции в PostgreSQL, но у пары команд внутри моего филиала компетенции в PostgreSQL были значимо выше. Кроме того, в компании был техлид по PostgreSQL, я вряд ли чем его мог бы удивить (в базах данных, конечно).
Представление о том, что золотые шестерёнки будут избегать конфликтов — ложное. Чаще всего, им на них все равно, если надо, то будут конфликтовать, если не надо, то не будут. В отдельный юнит вы их упаковать не сможете. Не забывайте, что они не только хорошие программисты, но ещё знают как руководить людьми, могут решать архитектурные проблемы и играть в политику.
Даже если вы найдёте нужное количество золотых шестерёнок, даже если среди них будет человек, которого они будут уважать и слушать, то вы их все равно в отдельном юните не удержите. Вы, скорее, дворцовый переворот получите, когда эта команда пойдёт просить отдать им рычаги управления.
У нас здесь явно не проблема в «защите мундира», а в вашем избирательном чтении. А так же в тех надуманных аргументах, что вы приводите.
Например. Откуда вы взяли, что в таблице было всего 5 столбцов? И почему вы упустили, что речь шла о компонентах, которые в себя ещё включали много html-элементов?
Почему вы пытаетесь игнорировать тот факт, что русский язык относится к категории синтетических и имеет очень развитые механизмы словообразования? Для такого языка ссылка на то, что вы не смогли найти слово в орфографическом словаре, выглядит даже как-то нелепо…
Претензии типа: «...Но вы почему-то выделили лишь свою скромную роль в одном единственном случае...», показывают, что вы просто теряете контекст повествования. Так нельзя.
Потерю контекста подтверждает и это ваше заявление: «...Вы писали, что у вас питон падал, а не си...». Я же указывал, что код платформы на бэкенде написан на C++ и проблемы с неоптимальной работой с памятью были именно в коде платформы. Зачем вы что-то решили додумать?
Каким образом у вас из того, что я оценил квалификацию некоторых разработчиков по тому фактору, что они не смогли подхватить функционал (который в моей группе передавался без проблем), получилось вывести, что я оценивал их квалификацию при приёме на работу? Расскажите мне пожалуйста ход своих мыслей. Но проверьте их на логические ошибки, перед тем, как кому-то рассказывать.
Кстати. Часть этих людей «которые не смогли», работали не только в других центрах разработки, но ещё и были наняты до меня. Но, как я понимаю, по вашей логике я всё равно виноват? Потому, что виноват и точка?
У вас очень интересное заявление: «...Если у меня не пилит пила, то я её точу. Вы же решили, что точить должны другие. Результат - они не смогли...». Например, попытка другой команды что-то закоммитить в мои модули жёстко пресекались. Вплоть до удаления без предупреждения. Закоммитить что-то в код платформы, без предупреждения, без согласования — это диверсия.
Причём даже не та диверсия, после которой следует неминуемое наказание. После этого вообще адекватность и психическое здоровье человека нужно проверять.
Вот здесь: «...В оригинале вы писали, что именно вам приходилось отбирать кандидатов. А задним числом мы все красавцы...», вы опять теряете контекст повествования. Как у вас найм сотрудников в одном филиале смешался с наймом сотрудников для всей компании-то? Каким образом?
Вот здесь: «...Я бы не стал сравнивать с худшими примерами. Но да, для защиты именно такое сравнение выглядит "подходящим"...» вы как-то странно додумали. А кто сказал, что «другие компании» это худшие примеры? На самом деле, я даже не обозначал эти «другие компании». Но вы сразу додумали, что они худшие. Прекрасно же?
Иногда вы просто занимаетесь какими-то голословными обвинениями. Например, здесь: «...Вы писали о проблемах в вашей области. Не о проблемах налаженного начальником бизнеса… Он работал совсем в другом направлении. ...». Чтобы о таком говорить, нужно хотя бы иметь понятия, а в чём бизнес-то заключался, и какое место там занимала непосредственно разработка. И почему генеральный директор был вынужден участвовать в разборе архитектурных проблем. Да и почему он вообще МОГ принимать такое участие тоже.
Затем уже идут фантазии чистой воды: «... А вам ничто не мешало зайти к нему в "переговорную комнату"...». А это вы с чего взяли? Либо в мире волшебных эльфов в кабинет основателя и генерального директора компании с миллиардными оборотами можно входить с ноги? Либо он сидит да только ждёт, когда же вы ему встречу назначите?
Теперь смотрите. Вы постоянно теряете контекст повествования. Это очень плохой симптом. Вы постоянно пробуете что-то додумать. Это некорректный приём демагогии. Иногда у вас в рассуждениях появляются логические ошибки. Специально либо не специально вы их допускаете — неизвестно.
Если мы говорим про «конструктив», то вам следует оперировать полным контекстом, не додумывать того, чего вы не знаете, даже если очень хочется, не допускать грубых ошибок в логике рассуждений. Тогда вы перестанете приходить с очевидно неверным выводам.
Возможно, я просто не смог верно передать "масштабы бедствия". Система была очень и очень большая. То, что я описывал, по своей сути происходило на несколько архитектурных слоёв выше, чем тот уровень, где может существовать ООП.
Нет, конечно, ООП мы активно использовали, куда без него. Просто над ним было еще множество иных слоёв абстракции. Например, "Модуль" - это фактически отдельный продукт, который можно было подключить по лицензии в облаке. И объектов в этом модуле было достаточно много. В других модулях - тоже.
Во-первых, по вашему комментарию видно, что вы не прочитали первую часть статьи. То есть начали делать выводы не владея полным контекстом.
Во-вторых, почему браузер может упасть от того, что его попросили отрисовать табличку в десятки тысяч записей. Нет проблем вернуть с бэкенда на фронтенд сколько-то десятков тысяч записей. Это даже не так долго будет. Проблемы испытает сам браузер. Потому, что у него внутри используется DOM-дерево, то есть все html-элементы на странице входят в специальную иерархичную структуру, по которой ходят события и вычисляется видимость элементов, а потом ещё и рендеринг происходит. Если используется какой-то компонент таблицы, значит в одной строке будет находиться множество html-элементов, плюс связанные с этим события и код их обработки. В какой-то момент это все может стать непосильной ношей для браузера.
При этом мы помним, что мы не знаем мощность компьютера, на котором работает наш пользователь.
Конечно, есть подходы с виртуальным DOM, но в платформе, которую предложили это использовать ничего подобного не было.
Кроме того, виртуальный DOM тоже не всегда спасает. Бывают специфичные требования, которые не позволяют его применять. У нас как-то встала такая проблема, мы использовали Canvas. Если я правильно помню, ровно так же делает Гугл и Яндекс в своих таблицах. Именно из-за проблем с DOM.
В-третьих. Если мы бурем слово «подцветка», от слова «цвет», то дело не в орфографии. Подсветка происходит от слова «свет». В моем же случае, речь шла не о том, чтобы подсветить, а именно о том, чтобы подцветить. Немного разные вещи.
В-четвёртых. В компании была целая программа по повышению оптимальности запросов. В процессе её работы были разработаны специальные инструменты и программы обучения, результатом её стала работа раз в 100-1000 быстрее, со аналогичным снижением потребления оперативной и дисковой памяти. А это уже — многомиллионная экономия на мощностях ЦОД.
Для того сложного случая, реализовать сборщик SQL-запросов с оптимальными планами выполнения, это признак очень хорошего программиста. А вот использование ORM на таком классе задач — признаком плохого.
В-пятых. Немного не понял критику в адрес 32-битного Python, при условии того, что проблемы были в коде, который реализовали на С++. Наоборот, хорошо что оно падало, то есть проблема стала понятной. Лучше поток упадёт, чем нода ЦОДа.
Либо вы хотели сказать, что С++ это плохой язык? Я снова с вами не соглашусь. И на хорошем языке можно писать плохой код.
В-шестых. Вроде бы я писал, что мой код был быстрым, но эффективным. Но вот для того, чтобы владеть им, нужна была высокая квалификация.
В-седьмых. Не начальником отдела, а руководителем центра разработки, с количеством сотрудников, которое не каждого департамента информационных технологий бывает.
В-восьмых. Платформу разрабатывал не я и не мои ребята. Просто так лезть к ним и менять код, естественно было нельзя. И слава богу. Они и так не очень работали, а такая вакханалия вообще бы общую работу остановила бы.
В-девятых. Я же был руководителем одного из центров разработки. А их таких был где-то 10. Набирать сотрудников, естественно, я мог только в свой центр. Не справились ребята не из моего центра разработки.
С учётом вышесказанного, можно поставить под сомнение ваш тезис: «Главная беда всегда одна - те, кто сверху. А те, кто снизу - продукт жизнедеятельности тех, кто сверху». Было много людей снизу. Было ещё больше людей сбоку. Было какое-то количество людей сверху.
Конечно, можно сказать, что во всем виноват основатели и генеральный директор (это один и тот же человек). Вот только, если заглянуть внутрь других крупных компаний, там было как-то не лучше.
Поэтому, пока я не смогу такое лучше чем он, от оценок я буду воздерживаться. Просто рассказывать это одно, а показать работающее — совсем другое.
На самом деле, золотая шестерёнка часто может выполнять функции архитектора. Если мы говорим о сложных системах, то делать качественно и правильно это ещё делать недорого и быстро. Снижаются затраты на ошибки, переделки и аварии.
Действительно, иногда приходится делать неправильно, так как рынок не стоит на месте. Но это технический долг, который потом придётся отдавать. Вопрос только в том, сколько процентов по нему накопится. Во второй части статьи привёл немного своего опыта. Там дело было не в архитектуре, а именно в организационных проблемах.
Мы иногда ведём проекты в крупных компаниях. Иногда в них архитекторы не только присутствуют номинально, а действительно работают. Люди исключительно полезные, они заранее для тебя снимают многие препятствия на пути. Грех таким не пользоваться.
Ну и особую остроту добавляют ситуации, когда кто-то что-то сделал по быстрому. Показал, сдал но не может внедрить, потому что ИБ сказал ему нет. Архитектора, который заранее обсуждает такие вопросы с информационной безопасностью, там, конечно, не было.
Оверхед всё-таки есть, и в какой-то момент начинаешь его чувствовать, есть неопределённость в реализации в некоторых местах STL, иногда может выстрелить. Кроме того, есть ещё STL::valarray, если уж использовать, то его.
На само деле, пример, конечно, экстремальный. Если бы это был коммерческий код над которым работает команда разработчиков, то пришлось бы смириться с некоторой неоптимальностью, откинуть все эти изыски и писать «нормально». И здесь я с вами был бы полностью согласен.
Можно. Но мне нравится оптимизирующий компилятор С++, который позволяет мне не думать об архитектуре конкретного процессора, а работать в рамках лишь семейства, например x86. ))
Мне иногда приходится писать код на С++, не коммерческий. Выполнение кода требует активной работы с оперативной памятью (численные методы, научные расчеты). Поэтому я предпочитаю никогда не использовать не то чтобы банальные smart pointers, но даже STL::vector, так как важно чувствовать эту самую оперативную память, операции выделения и освобождения памяти. Кроме того, оператор ветвления в ряде случаев я могу заменять арифметическими выражениями, чтобы избавить процессор от необходимости лишний раз ветвления предсказывать.
Это может показаться извращением, но зато мой код никогда по памяти не течёт (ведь я за этим слежу вручную), и работает быстро, что для меня важно. Справится ли с таким современный рядовой разработчик на С++, я не знаю. Скорее всего, нет. Другой вопрос, а оно ему вообще надо? ))
Я чуть попозже напишу и опубликую взгляд с другой стороны. Есть вещи, которые выглядят, как JSDD, но ими совсем не являются.
По поводу "стать незаменимым". Тут имеет смысл посмотреть на долгосрочную перспективу, вы так можете сильно ограничить свой профессиональный рост, плюс оказаться в "болоте". Конечно, помним о том, что все ситуации разные и универсальных решений не бывает.
Если мы находимся в контексте проведения собеседования в компании, которая сосредоточилась на применении Agile-методологий, то, возможно, вы правы. Если мы находимся в контексте целевой аудитории статьи, то вы скорее не правы.
Почему так? Очень часто, когда спрашиваешь людей, по какой методологии вы работаете, то можно услышать в ответ Agile. Просто Agile. Иногда кто-то говорит о Kanban. Но надо понимать, что именно называется «Kanban». Это просто что-то с Kanban-доской.
Именно поэтому приходится напоминать о том, что нет такой методологии разработки, как Agile либо Kanban. Первое — это просто манифест, соответствие которому может заявлять та либо иная методология, либо может не заявлять. Второе это инструмент визуализации.
Например, есть такая методология, как Agile Unified Process. Что это такое? Говорят, что адаптация IBM Rational Unified Process под принципы из Agile Manifesto. Можно было бы отнестись с юмором, но ведь есть OpenUP. Это тоже и Agile и Unified Process одновременно.
Идём дальше. Если мы используем Kanban-доску, как ритуал в Scrum, это не превращает Scrum в Kanban. Если мы используем каскадную модель и используем в для визуализации процесса работы Kanban-доску, то у нас водопад не станет Kanban. Даже больше. Если мы используем ITIL и просто осуществляем IT-услугу по внедрению/доработке/исправлению и используем для этого Kanban-доску, то ITIL всё равно не станет Kanban.
Конечно, можно вспомнить Lean software development, который “бережливая разработка программного обеспечения”. Я даже соглашусь, что Kanban изначально пришел к нам из бережливого производства, прямо с завода. Но там никто и никогда не пытался подменить понятие “pull production” понятием “Kanban”.
На мой взгляд, если мы говорим о Lean software development, то термины “Agile” и “Kanban” в нем носят скорее маркетинговый характер, вместо того, чтобы нести полезную смысловую нагрузку.
На последок скажу. Мне еще не один человек, который “работает по Kanban” не ответил на простой вопрос: “Что такое муда?”. От Muda – так японцы потерю на производственной цепочке называют. А вот заявленная целевая аудитория может быть вполне знакома с таким термином. Всё-таки, бережливое производство, шесть сигм, кайдзен на худой конец, российскому бизнес-сообществу хорошо знакомы.
Жизнь несколько сложнее, на самом деле. В моём случае объяснять генеральному, что он не прав, это было не что-то страшное и ужасное. Человек компетентный, по утрам он ещё не терял адекватность под нагрузкой, и с ним можно было конструктивно подискутировать. Спокойно признавал свою неправоту, когда для него открывались новые обстоятельства. Собственно, как и я. У нас были с ним очень разные наборы данных, синхронизация их помогала найти решения для иных вопросов.
Но генеральный директор — это не сверхчеловек, он точно так же, как и все остальные, действует в системе своих ограничений. Там наверху свои проблемы, и я ещё не видел человека, который с ними справлялся бы идеально. Но видел немало людей, которые знали, как идеально, и их наверху размазывало под нагрузкой.
К слову, мне как-то несколько раз в грубой форме высказывать своё негативное мнение об совладельцах-миноритариях компании, причём им лично. Что мне за это было? Меня не уволили, меня не оштрафовали, меня просто посчитали грубым и неуравновешенным человеком. Поэтому с тезисом о «быстро уволят» я не могу согласиться.
P. S.
Описанная вами проблема с самолётами уже решалась. У части самолётов выход производится через шасси. У Су-34 так, если я правильно помню. В поворотных механизмах для сегментов корпуса нужды нет. Сейчас даже поворотные механизмы для крыльев самолёта теряют свою актуальность.
Если брать SQL, то это было общее требование по компании. На самом деле, мы ещё согласовывали новые таблицы, поля и индексы. Когда у тебя облако, а в нем многие тысячи схем клиентов, факт того, что, например, под индексы и таблицы тот же PostgreSQL создаёт отдельные файлы, начинает очень больно кусаться. Как и неоптимальные запросы, которые исполняются миллионы раз.
У компании был собственный ЦОД, достаточно мощный. Постоянно расширять его мощности и тратить на это миллиарды рублей, было нецелесообразно. Поэтому началась системная работа над оптимизацией запросов.
Говоря честно, основная сложность моего модуля была именно в интеграциях и контроле за потоками данных. У меня были хорошие компетенции в PostgreSQL, но у пары команд внутри моего филиала компетенции в PostgreSQL были значимо выше. Кроме того, в компании был техлид по PostgreSQL, я вряд ли чем его мог бы удивить (в базах данных, конечно).
Представление о том, что золотые шестерёнки будут избегать конфликтов — ложное. Чаще всего, им на них все равно, если надо, то будут конфликтовать, если не надо, то не будут. В отдельный юнит вы их упаковать не сможете. Не забывайте, что они не только хорошие программисты, но ещё знают как руководить людьми, могут решать архитектурные проблемы и играть в политику.
Даже если вы найдёте нужное количество золотых шестерёнок, даже если среди них будет человек, которого они будут уважать и слушать, то вы их все равно в отдельном юните не удержите. Вы, скорее, дворцовый переворот получите, когда эта команда пойдёт просить отдать им рычаги управления.
У нас здесь явно не проблема в «защите мундира», а в вашем избирательном чтении. А так же в тех надуманных аргументах, что вы приводите.
Например. Откуда вы взяли, что в таблице было всего 5 столбцов? И почему вы упустили, что речь шла о компонентах, которые в себя ещё включали много html-элементов?
Почему вы пытаетесь игнорировать тот факт, что русский язык относится к категории синтетических и имеет очень развитые механизмы словообразования? Для такого языка ссылка на то, что вы не смогли найти слово в орфографическом словаре, выглядит даже как-то нелепо…
Претензии типа: «...Но вы почему-то выделили лишь свою скромную роль в одном единственном случае...», показывают, что вы просто теряете контекст повествования. Так нельзя.
Потерю контекста подтверждает и это ваше заявление: «...Вы писали, что у вас питон падал, а не си...». Я же указывал, что код платформы на бэкенде написан на C++ и проблемы с неоптимальной работой с памятью были именно в коде платформы. Зачем вы что-то решили додумать?
Каким образом у вас из того, что я оценил квалификацию некоторых разработчиков по тому фактору, что они не смогли подхватить функционал (который в моей группе передавался без проблем), получилось вывести, что я оценивал их квалификацию при приёме на работу? Расскажите мне пожалуйста ход своих мыслей. Но проверьте их на логические ошибки, перед тем, как кому-то рассказывать.
Кстати. Часть этих людей «которые не смогли», работали не только в других центрах разработки, но ещё и были наняты до меня. Но, как я понимаю, по вашей логике я всё равно виноват? Потому, что виноват и точка?
У вас очень интересное заявление: «...Если у меня не пилит пила, то я её точу. Вы же решили, что точить должны другие. Результат - они не смогли...». Например, попытка другой команды что-то закоммитить в мои модули жёстко пресекались. Вплоть до удаления без предупреждения. Закоммитить что-то в код платформы, без предупреждения, без согласования — это диверсия.
Причём даже не та диверсия, после которой следует неминуемое наказание. После этого вообще адекватность и психическое здоровье человека нужно проверять.
Вот здесь: «...В оригинале вы писали, что именно вам приходилось отбирать кандидатов. А задним числом мы все красавцы...», вы опять теряете контекст повествования. Как у вас найм сотрудников в одном филиале смешался с наймом сотрудников для всей компании-то? Каким образом?
Вот здесь: «...Я бы не стал сравнивать с худшими примерами. Но да, для защиты именно такое сравнение выглядит "подходящим"...» вы как-то странно додумали. А кто сказал, что «другие компании» это худшие примеры? На самом деле, я даже не обозначал эти «другие компании». Но вы сразу додумали, что они худшие. Прекрасно же?
Иногда вы просто занимаетесь какими-то голословными обвинениями. Например, здесь: «...Вы писали о проблемах в вашей области. Не о проблемах налаженного начальником бизнеса… Он работал совсем в другом направлении. ...». Чтобы о таком говорить, нужно хотя бы иметь понятия, а в чём бизнес-то заключался, и какое место там занимала непосредственно разработка. И почему генеральный директор был вынужден участвовать в разборе архитектурных проблем. Да и почему он вообще МОГ принимать такое участие тоже.
Затем уже идут фантазии чистой воды: «... А вам ничто не мешало зайти к нему в "переговорную комнату"...». А это вы с чего взяли? Либо в мире волшебных эльфов в кабинет основателя и генерального директора компании с миллиардными оборотами можно входить с ноги? Либо он сидит да только ждёт, когда же вы ему встречу назначите?
Теперь смотрите. Вы постоянно теряете контекст повествования. Это очень плохой симптом. Вы постоянно пробуете что-то додумать. Это некорректный приём демагогии. Иногда у вас в рассуждениях появляются логические ошибки. Специально либо не специально вы их допускаете — неизвестно.
Если мы говорим про «конструктив», то вам следует оперировать полным контекстом, не додумывать того, чего вы не знаете, даже если очень хочется, не допускать грубых ошибок в логике рассуждений. Тогда вы перестанете приходить с очевидно неверным выводам.
Возможно, я просто не смог верно передать "масштабы бедствия". Система была очень и очень большая. То, что я описывал, по своей сути происходило на несколько архитектурных слоёв выше, чем тот уровень, где может существовать ООП.
Нет, конечно, ООП мы активно использовали, куда без него. Просто над ним было еще множество иных слоёв абстракции. Например, "Модуль" - это фактически отдельный продукт, который можно было подключить по лицензии в облаке. И объектов в этом модуле было достаточно много. В других модулях - тоже.
Вы очень спешите с выводами, это вас подводит.
Во-первых, по вашему комментарию видно, что вы не прочитали первую часть статьи. То есть начали делать выводы не владея полным контекстом.
Во-вторых, почему браузер может упасть от того, что его попросили отрисовать табличку в десятки тысяч записей. Нет проблем вернуть с бэкенда на фронтенд сколько-то десятков тысяч записей. Это даже не так долго будет. Проблемы испытает сам браузер. Потому, что у него внутри используется DOM-дерево, то есть все html-элементы на странице входят в специальную иерархичную структуру, по которой ходят события и вычисляется видимость элементов, а потом ещё и рендеринг происходит. Если используется какой-то компонент таблицы, значит в одной строке будет находиться множество html-элементов, плюс связанные с этим события и код их обработки. В какой-то момент это все может стать непосильной ношей для браузера.
При этом мы помним, что мы не знаем мощность компьютера, на котором работает наш пользователь.
Конечно, есть подходы с виртуальным DOM, но в платформе, которую предложили это использовать ничего подобного не было.
Кроме того, виртуальный DOM тоже не всегда спасает. Бывают специфичные требования, которые не позволяют его применять. У нас как-то встала такая проблема, мы использовали Canvas. Если я правильно помню, ровно так же делает Гугл и Яндекс в своих таблицах. Именно из-за проблем с DOM.
В-третьих. Если мы бурем слово «подцветка», от слова «цвет», то дело не в орфографии. Подсветка происходит от слова «свет». В моем же случае, речь шла не о том, чтобы подсветить, а именно о том, чтобы подцветить. Немного разные вещи.
В-четвёртых. В компании была целая программа по повышению оптимальности запросов. В процессе её работы были разработаны специальные инструменты и программы обучения, результатом её стала работа раз в 100-1000 быстрее, со аналогичным снижением потребления оперативной и дисковой памяти. А это уже — многомиллионная экономия на мощностях ЦОД.
Для того сложного случая, реализовать сборщик SQL-запросов с оптимальными планами выполнения, это признак очень хорошего программиста. А вот использование ORM на таком классе задач — признаком плохого.
В-пятых. Немного не понял критику в адрес 32-битного Python, при условии того, что проблемы были в коде, который реализовали на С++. Наоборот, хорошо что оно падало, то есть проблема стала понятной. Лучше поток упадёт, чем нода ЦОДа.
Либо вы хотели сказать, что С++ это плохой язык? Я снова с вами не соглашусь. И на хорошем языке можно писать плохой код.
В-шестых. Вроде бы я писал, что мой код был быстрым, но эффективным. Но вот для того, чтобы владеть им, нужна была высокая квалификация.
В-седьмых. Не начальником отдела, а руководителем центра разработки, с количеством сотрудников, которое не каждого департамента информационных технологий бывает.
В-восьмых. Платформу разрабатывал не я и не мои ребята. Просто так лезть к ним и менять код, естественно было нельзя. И слава богу. Они и так не очень работали, а такая вакханалия вообще бы общую работу остановила бы.
В-девятых. Я же был руководителем одного из центров разработки. А их таких был где-то 10. Набирать сотрудников, естественно, я мог только в свой центр. Не справились ребята не из моего центра разработки.
С учётом вышесказанного, можно поставить под сомнение ваш тезис: «Главная беда всегда одна - те, кто сверху. А те, кто снизу - продукт жизнедеятельности тех, кто сверху». Было много людей снизу. Было ещё больше людей сбоку. Было какое-то количество людей сверху.
Конечно, можно сказать, что во всем виноват основатели и генеральный директор (это один и тот же человек). Вот только, если заглянуть внутрь других крупных компаний, там было как-то не лучше.
Поэтому, пока я не смогу такое лучше чем он, от оценок я буду воздерживаться. Просто рассказывать это одно, а показать работающее — совсем другое.
На самом деле, золотая шестерёнка часто может выполнять функции архитектора. Если мы говорим о сложных системах, то делать качественно и правильно это ещё делать недорого и быстро. Снижаются затраты на ошибки, переделки и аварии.
Действительно, иногда приходится делать неправильно, так как рынок не стоит на месте. Но это технический долг, который потом придётся отдавать. Вопрос только в том, сколько процентов по нему накопится. Во второй части статьи привёл немного своего опыта. Там дело было не в архитектуре, а именно в организационных проблемах.
Мы иногда ведём проекты в крупных компаниях. Иногда в них архитекторы не только присутствуют номинально, а действительно работают. Люди исключительно полезные, они заранее для тебя снимают многие препятствия на пути. Грех таким не пользоваться.
Ну и особую остроту добавляют ситуации, когда кто-то что-то сделал по быстрому. Показал, сдал но не может внедрить, потому что ИБ сказал ему нет. Архитектора, который заранее обсуждает такие вопросы с информационной безопасностью, там, конечно, не было.
Оверхед всё-таки есть, и в какой-то момент начинаешь его чувствовать, есть неопределённость в реализации в некоторых местах STL, иногда может выстрелить. Кроме того, есть ещё STL::valarray, если уж использовать, то его.
На само деле, пример, конечно, экстремальный. Если бы это был коммерческий код над которым работает команда разработчиков, то пришлось бы смириться с некоторой неоптимальностью, откинуть все эти изыски и писать «нормально». И здесь я с вами был бы полностью согласен.
�
Можно. Но мне нравится оптимизирующий компилятор С++, который позволяет мне не думать об архитектуре конкретного процессора, а работать в рамках лишь семейства, например x86. ))
Мне иногда приходится писать код на С++, не коммерческий. Выполнение кода требует активной работы с оперативной памятью (численные методы, научные расчеты). Поэтому я предпочитаю никогда не использовать не то чтобы банальные smart pointers, но даже STL::vector, так как важно чувствовать эту самую оперативную память, операции выделения и освобождения памяти. Кроме того, оператор ветвления в ряде случаев я могу заменять арифметическими выражениями, чтобы избавить процессор от необходимости лишний раз ветвления предсказывать.
Это может показаться извращением, но зато мой код никогда по памяти не течёт (ведь я за этим слежу вручную), и работает быстро, что для меня важно. Справится ли с таким современный рядовой разработчик на С++, я не знаю. Скорее всего, нет. Другой вопрос, а оно ему вообще надо? ))
Да, но главное этим не злоупотреблять.
Немного не так. Я эту тему во второй части раскрою. )
Спасибо, Владимир Николаевич.
Прочитал ваши статьи "Пятьдесят лет на стезе программирования", и вам спасибо за них. Без понимания прошлого, будущее сложно построить.
Чуть попозже напишу о чем-то похожем. Универсального способа нет.
Но можно попробовать заболеть либо надолго уйти в отпуск. ))
У нас был опыт с такими сотрудниками, которые практиковали JSDD.
Но, наверное, будет статья и про случай, когда это выглядит, как JSDD, но JSDD не является.
Спасибо. Попробую по возможности его использовать.
Я чуть попозже напишу и опубликую взгляд с другой стороны. Есть вещи, которые выглядят, как JSDD, но ими совсем не являются.
По поводу "стать незаменимым". Тут имеет смысл посмотреть на долгосрочную перспективу, вы так можете сильно ограничить свой профессиональный рост, плюс оказаться в "болоте". Конечно, помним о том, что все ситуации разные и универсальных решений не бывает.
Если мы находимся в контексте проведения собеседования в компании, которая сосредоточилась на применении Agile-методологий, то, возможно, вы правы. Если мы находимся в контексте целевой аудитории статьи, то вы скорее не правы.
Почему так? Очень часто, когда спрашиваешь людей, по какой методологии вы работаете, то можно услышать в ответ Agile. Просто Agile. Иногда кто-то говорит о Kanban. Но надо понимать, что именно называется «Kanban». Это просто что-то с Kanban-доской.
Именно поэтому приходится напоминать о том, что нет такой методологии разработки, как Agile либо Kanban. Первое — это просто манифест, соответствие которому может заявлять та либо иная методология, либо может не заявлять. Второе это инструмент визуализации.
Например, есть такая методология, как Agile Unified Process. Что это такое? Говорят, что адаптация IBM Rational Unified Process под принципы из Agile Manifesto. Можно было бы отнестись с юмором, но ведь есть OpenUP. Это тоже и Agile и Unified Process одновременно.
Идём дальше. Если мы используем Kanban-доску, как ритуал в Scrum, это не превращает Scrum в Kanban. Если мы используем каскадную модель и используем в для визуализации процесса работы Kanban-доску, то у нас водопад не станет Kanban. Даже больше. Если мы используем ITIL и просто осуществляем IT-услугу по внедрению/доработке/исправлению и используем для этого Kanban-доску, то ITIL всё равно не станет Kanban.
Конечно, можно вспомнить Lean software development, который “бережливая разработка программного обеспечения”. Я даже соглашусь, что Kanban изначально пришел к нам из бережливого производства, прямо с завода. Но там никто и никогда не пытался подменить понятие “pull production” понятием “Kanban”.
На мой взгляд, если мы говорим о Lean software development, то термины “Agile” и “Kanban” в нем носят скорее маркетинговый характер, вместо того, чтобы нести полезную смысловую нагрузку.
На последок скажу. Мне еще не один человек, который “работает по Kanban” не ответил на простой вопрос: “Что такое муда?”. От Muda – так японцы потерю на производственной цепочке называют. А вот заявленная целевая аудитория может быть вполне знакома с таким термином. Всё-таки, бережливое производство, шесть сигм, кайдзен на худой конец, российскому бизнес-сообществу хорошо знакомы.