Ведущие разработчики, они же Senior developers. Это те самые люди, которые на своем веку перевыполняли уже все возможные задачи. Это люди, которые входят в переговорку, открывая дверь с ноги. Они — решение всех проблем компании и гарантия светлого будущего. Они не изучают технологии, а изобретают. Они знают бизнес-требования до того, как те были сформулированы. И самое главное: они четко и отчетливо представляют себя через пять, а иногда и через десять лет.Серьезно, мне кажется, что от сеньоров сейчас слишком много ожиданий. Судя по вакансиям, это такой аналог советских космонавтов. Если внезапно в вашем офисе перестанет работать stackoverflow, вся документация, да и вообще интернет, версия компилятора/интерпретатора доунгрейднится на 5 лет назад, а вам срочно нужно будет написать аналог Редиса, не используя сторонних фреймворков и библиотек — вы обязаны это сделать. Причем за пару часов и излучая стрессоустойчивость.
В этой статье я бы хотел немного поговорить о том, кем не должен быть ведущий разработчик. Развенчать несколько мифов.
10+ лет опыта
У меня вот есть эти 10+ лет опыта, но вспоминая, чем и как я занимался 10 лет назад, я надеюсь, что мне никогда не придется применять эти знания. Технологии бегут, просто летят и меняются с огромной скоростью. То, что было актуально вчера — сегодня уже bad practice, завтра — deprecated, послезавтра — история. В нашей профессии мы не накапливаем знания, мы их просто одалживаем на время, заменяя на более современные и полезные.
Ценится не багаж знаний, а умение быстро накапливать нужные навыки. Умение держать руку на пульсе. Быть в теме. Не допускать устаревания знаний. И ни в коем случае не уставать от этого. Выживает тот, кто научился получать удовольствие от постоянного ресерча. Если у меня будет выбор между уставшим от технологий ветераном или выпускником, с горящими глазами рассуждающим об особенностях новой технологии — я бы предпочел последнего.
Самостоятельный
Самостоятельность — это здорово! Дал разработчику задачу — он ее сделал. Без вопросов, без уточнений, без проблем. Интерфейс, который принимает в качестве аргумента задание, а на выходе отдает работающий код. На практике это часто вредно. Некоторые разработчики вместо того, чтобы уточнить бизнес-требования, пытаются быть самостоятельными, не отвлекать продукт-овнера и додумывают все сами. Додумывают неправильно.
Действительно, самостоятельность — это отличительное качество сеньора. Но принимать решения он должен только в вопросах архитектуры и кода. Если есть вопросы по бизнес-требованиям — нужно уточнять у специального человека.
Обучает начинающих
Путь от джуниора до мидла тернист и запутан. Много поворотов в никуда, много дорог, ведущих в очень плохие районы. Часто подразумевается, что сеньор должен быть гидом, который поставленным голосом вещает интересные факты о каждом здании. Объясняет нюансы каждой технологии, убирает из под ног все грабли и помогает превратить костыли в изящные архитектурные решения.
Обучать людей — это талант. И не у каждого хорошего программиста он есть. На самом деле, сеньор должен быть скорее Яндекс Картами, чем гидом. Он должен указывать направление, следить, чтобы джуниор не свернул в опасный район и шел правильной дорогой. При должном желании джуниора этого с лихвой хватит, чтобы вырастить из него приличного мидла.
Незаменим
Этот миф касается скорее не требований в резюме, а уже работающих в компании сеньоров. Часто случается, что сеньоры становятся незаменимыми, обладают большим количеством знаний, которыми не обладает больше никто в компании. И это считается нормальным, на то ведь они и сеньоры, чтобы знать больше других.
На самом деле — это неправильно. Никто не должен аккумулировать у себя важные знания. Все должно быть описано в документации. Некоторые считают, что незаменимость является гарантом вашего места в компании. Кто вас уволит, если без вас некому отвечать на вопросы? Но ведь ваша незаменимость также мешает вам спокойно уйти в отпуск или уволиться. Да и вообще, если вы боитесь, что вас уволят — значит в какой-то момент своей карьеры вы свернули не туда.
Коммуникабельный
Если сеньор коммуникабелен, обладает обаянием, харизмой, умеет и любит общаться — это отлично. Но, к сожалению, чаще всего это не так. И неспроста, ведь общение — это не тот скилл, который всю жизнь прокачивают программисты. Если мне на собеседовании долго рассказывают, какой дружный в компании коллектив, как они все ездят на шашлыки раз в месяц и возят друг друга на работу — я скорее откажусь от этой вакансии, понимая, что от меня требуется не только делать свою работу, но и быть ярко выраженным экстравертом. А я в этом не специализируюсь.
Однако это не значит, что нужно приходить в офис, садиться за комп, надевать наушники и закрываться от всего мира. Наша работа — командная, и она подразумевает общение с коллегами. Вы можете быть интровертом в свое свободное время, но во время работы вы — командный игрок.
Итого
По сравнению с вакансиями пятилетней давности, компании сделали большой шаг вперед. Уже не перечисляют все термины, которые можно услышать в каком-либо уголке офиса. Вакансии составлены настоящими профессионалами и действительно выглядят привлекательными. Тем не менее, раз за разом, я вижу в вакансиях мифы, оформленные в виде требований. И каждый раз, когда от меня требуют быть дружелюбным или учить джуниоров — мне становится немного грустно.
Комментарии (103)
bisor
25.01.2018 10:01С чем-то можно согласиться, а с чем-то нет.
Но с чем я точно соглашусь, так это с дебильными вакансиями, в которых перечисляют все что нашли в гугле.leshakk
25.01.2018 17:36Напомнило древний, но по-прежнему актуальный баян.
Если бы водителей принимали на работу как программистов...Вакансия: водитель.
Требования:
Профессиональные навыки в управлении легковыми и грузовыми автомобилями, троллейбусами, трамваями, поездами метрополитена и фуникулёра, экскаваторами и бульдозерами, спецмашинами на гусеничном ходу, боевыми машинами пехоты и современными легкими/средними танками, находящимися на вооружении стран СНГ и НАТО.
Навыки раллийного и экстремального вождения обязательны.
Опыт управления болидами “Формулы 1” – приветствуется. Знания и опыт ремонта поршневых и роторных двигателей, автоматических и ручных трансмиссий, систем зажигания, бортовых компьютеров, антиблокировочных систем, навигационных систем и автомобильных аудиосистем ведущих производителей.
Опыт проведения кузовных и окрасочных работ – приветствуется.
Претенденты должны иметь сертификаты Mercedes, BMW, General Motors, а также справки об участии в крупных международных соревнованиях не более, чем двухлетней давности.
Зарплата: определяется по результатам собеседования.
Varim
25.01.2018 10:34Действительно, самостоятельность — это отличительное качество сеньора. Но принимать решения он должен только в вопросах архитектуры и кода.
Так ли это? Вот допустим есть у меня несколько вариантов решений, я могу выбрать любое, но почему бы не посоветоваться? Вдруг найдется то решение о котором я не подумал.
Вообще, как в команде можно думать об вопросах архитектуры в одиночку…
Скорее и архитектору неплохо бы обсуждать архитектуру с другими разработчиками, что-бы договорится что это решение сделать достаточно просто и всем понятно как, зачем и почему именно так.VolCh
25.01.2018 11:38Тут сильно зависит от отношений в команде. Есть команды, где все более-менее значимые решения принимаются коллегиально или в стиле "мы посовещались и я решил", а есть те, куда квалифицированных специалистов берут как раз для того, чтобы они других не отвлекали по каждому чиху.
Varim
25.01.2018 12:07Есть 10 full-stack разработчиков которые пилят один проект, если они не будут согласовать (обсуждать и советоваться) что да как делать, это же будет каша в проекте?
Разработчик взял и сделал молча как захотел, добавив костыли и новые сторонние библиотеки и завязав проект на парочку типов приложений вроде RabbitMQ и Redis, ведь другие разработчики и архитекторы не для того что бы я их дергал или они меня дергали.
Или наоборот, приходит задача разработчику, разработчик думает об архитектуре, а потом такой «СТОП! У нас же есть архитектор, вот ему таска пусть подумает, а потом скажет мне какая будет архитектура». Не странно ли?
Может я чего то не понимаю. Масса рабочего времени уходит на обсуждение / согласование, как требований так и способов решений, часто бОльшая часть времени.VolCh
25.01.2018 12:52Какие-то моменты в обсуждениях и согласовании нуждаются по-любому, да. Но уровень необходимых согласований сильно зависит от команды и компании. Скажем, где-то создание нового класса надо согласовывать, а где-то можно в рамках задачи новый "стэндэлон" сервис запилить на одном из десятка языков ни с кем не советуясь.
labone
25.01.2018 13:02Я из геймдев команды, где мы согласовывали основные направления развития кода и способы реализации фич (не подробно, но общий подход и инструменты решения) попал в команду где каждый молча пилит свою фичу, ни с кем не советуясь.
Снижение эффективности во втором подходе буквально вгоняет меня в депрессию.
Не рекомендую такой подход в геймдеве. Моя старая команда в 6 человек на порядок (именно в десять раз, судя по джире) эффективнее текущей команды в 14 человек по количеству фич в месяц, более того, многие фичи вообще не достижимы в новой команде в разумный срок. Дальше становится только хуже, и я не могу исправить ситуацию.
Более того, чужие решения начинают ломать твои фичи, что превращает линейную разработку в поддержку старых систем.
Вот так страшно жить.
alexeykuzmin0
25.01.2018 13:34Вот допустим есть у меня несколько вариантов решений, я могу выбрать любое, но почему бы не посоветоваться?
Более того, обычно в компаниях вообще запрещено коммитить что-либо, не посоветовавшись с остальными разработчиками в виде code review.Evgen52
27.01.2018 07:26+2Это ведь разные вещи, нисколько друг друга не отменяющие. Советоваться в таких вопросах нужно ещё до написания кода, code review — слишком поздно, так как ресурсы уже потрачены на разработку и тестирование) На этапе дизайна исправить ошибки, очевидно, на порядок дешевле.
africaunite
25.01.2018 11:25+1По моему опыту, senior разработчик — это просто категория для отдела кадров и бухгалтерии. Никогда не встречал специалиста, называющего себя таким титулом при знакомстве, например.
Ценится не багаж знаний, а умение быстро накапливать нужные навыки.
Знания, как раз, позволяют не только быстро приобретать нужные навыки, но, что важнее — осознанно выбирать, которые из них стоят приобретения.
В нашей профессии мы не накапливаем знания, мы их просто одалживаем на время, заменяя на более современные и полезные.
Я бы уточнил — знания накапливаем (это чтобы одно на другом строить, или, наоборот — держаться подальше), а некоторые навыки (локальные) приобретаем на время.
VolCh
25.01.2018 11:54Ведущий разработчик для меня это уже lead. Team lead, tech lead, может lead developer (редкая официальная позиция в целом). От старшего (senior) разработчика отличается прежде всего развитыми, как говорится, soft skills, прежде всего упомянутые как ненужные коммуникабельность, самостоятельность, способность обучать (ну, или, хотя бы способность грамотно и понятно донести свою техническую мысль до менее технически квалифицированных разработчиков, а не просто направлять джунов по принципу "делай так, а то
руки оторвутвой код моё ревью не пройдёт").
ilya-ivanov
25.01.2018 12:15+1Мне кажется, вы переоцениваете значимость текстов о вакансиях) Это не священные скрижали, а просто сборник хотелок в поисках идеала. Тексты составляют обычные люди, разные, зачастую случайные и далекие от принятия решений.
Представьте пишет кто-то вакансию. Допустим, HR. Или даже кто-то реально компетентный. Но проходит мимо большой босс и говорит: «Добавь-ка там Гарвард и Нобелевскую премию. Я такие деньги плачу! Да за них можно пятерых гениев нанять, блин!». Окей. Подбегает маркетолог. Говорит: «Глубокие знания бизнес-процессов обязательны! Нам нужны умные понимающие люди!». Ну окей. Пробегает девочка-бухгалтер: «Ой, а давайте напишем, чтобы был спортивного телосложения...». Уборщица кивает и поддакивает: «Во-во! И чтобы бачок в унитазе починил!». Ну и так далее.
Много хотеть и искать идеал — это нормально. И вопреки стереотипам, тексты вакансий не всегда годятся для оценки рынка. Мы же не журналисты, чтобы по трем цифрам зарплат с доски объявлений Урюпинска «исследовать» медианные заработки в IT «во всем цивилизованнном мире» :)
Поясню на еще одном примере. Если спросить у какой-нибудь подруги, какие качества обязательно должны быть у ее мужчины, почти любая на гора выдаст вам список из нескольких десятков пунктов. Порой взаимоисключающих. Если эти хотелки воспринимать всерьёз, человечество просто перестанет размножаться и вымрет :) А на практике для успешного прохождения чек-листа из ста сложных пунктов порой достаточно легкой самоуверенности и задрипанной ромашки, честно стыренной с ближайшей клумбы. Это позиционные игры, не более.
Работодатель имеет право хотеть чего угодно. Но вы, в свою очередь, не обязаны оправдывать все эти хотелки и быть идеальным. Реальное положение дел определяется только конкуренцией между соискателями. И если на вакансию супермена в течение долгого времени откликнутся только косой, хромой и горбатый, то одному из них вскоре выдадут синюю плюшевую майку и красный плащ. И тот полетит. А если не полетит, то пойдет или похромает. И все смирятся с этим и будут работать с тем, что есть, пока не найдется альтернатива.
Вывод? Не грустите :)
RomanPokrovskij
25.01.2018 12:25Какие вакансии? Если ты ведущий, самостоятельный, коммуникабильный — значит ты фрилансер.
tangro
25.01.2018 12:41Самостоятельность — это здорово! Дал разработчику задачу — он ее сделал.
Ха, если бы это было так! Для специалистов уровня сеньйоров и выше под «самостоятельностью» подразумевается не только выполнение задачи, а и её формулирование, аргументация её практической пользы для проекта и чуть ли не план повышения продаж продукта и роста прибыли после реализации фичи.Varim
25.01.2018 12:49Самостоятельность — это здорово! Дал разработчику задачу — он ее сделал.
Это когда на проекте только один разработчик и бизнес аналитик всё классно разжевал в документации. В остальных случаях не представляю как это возможно.
Smiz001
25.01.2018 13:53или выпускником, с горящими глазами
Честно, такое читать в реалиях смешно. От всех только и слышишь, что опыта мало.sand14
25.01.2018 14:10Ага, теперь ждите следующей остановки — когда будет опыт и знания текущих актуальных технологий, и при этом останутся горящие глаза и желание изучать новые технологии,
то вдруг оказывается, что вот это вот все не особо то и нужно.
В основном все работают с легаси.
Суть в том, что когда нанимают человека, в конечном итоге решает психологическая совместимость, или вообще какие-то отвлеченные факторы.
Если в конкретном случае что-то в фазе Марса не совпало, то тогда и начинается "мало опыта"/"много опыта, но легаси", "не хочешь изучать новое"/"слишком хочешь изучать новое, а нам надо баги пилить".
sand14
25.01.2018 13:53+1Ведущие разработчики, они же Senior developers
И сходу самая распространенная ошибка в обсуждениях Titles разработчиков.
Ведущий != Senior, очень даже не равно.
Senior это просто старший опытный разработчик, который все знает, как лучше всего сделать, к чему это приведет, если сделать так-то и так то, как обойти то-то, когда нужен микроскоп, а когда молоток, которые знает не только конкретные технологии, но и общие принципы, etc — за счет знаний и/или опыта.
Который может сам сделать задачу, и его не нужно особой контролировать.
Ведущий (Lead) — на то и ведущий, что он ведет других за собой.
Это может быть или Team Lead — ведущий за собой команду в разрезе процесса разработки, либо Tech Lead — ведущий команду в плане выбора и соблюдения технологий.
Причем, Senior вполне может быть Team Lead'ом (здесь больше нужны организационные навыки), а вот до Teach Lead'а сеньору нужно дорасти одну ступеньки строго по вертикали.
BalinTomsk
25.01.2018 19:00То что вы в статье описали это Principal Developer. В чем разница — хорошо описали в этой статье.
www.quora.com/What-is-the-difference-between-a-principal-developer-and-a-senior-developer
У нас в компании все Principal Developer.
Знание конкретного языка не имеет значения.
Все работают одновременно с C/C++/Java/TSQL/C# в 2-3 фреймворках.
Кто -то в чем-то лучше кто-то меньше.
У каждого свой фронт работ и полная отвественность за результат.
С написанием юнит тестов, функциональных и нагрузочных.
Документациим спецификаций и прочая.
Если что отряд не заметитпотериуход бойца.
2creker
25.01.2018 19:48+1«Back to the black». ИМХО. Прихожу к выводу, что лучше инвестировать свое время в основы: в изучение алгоритмов, архитектур популярных БД (реляционных и нет), изучение устройства сетей и протоколов, парадигм программирования (функ., императив. итд) и др.
Изучение конкретных технологий и узких приемов в конкретном языке инструменте — не выгодно.
eldog
25.01.2018 19:48В сказанном много правды, но есть ещё кое-что. Технологии в конечном счёте вторичны по сравнению с алгоритмами и архитектурой. Выучить новый способ забивания гвоздя — не проблема.
Приходится работать с джуниорами, ошибки в технологиях тоже есть, но главная проблема не в этом. Вроде бы всем объясняли про архитектуру, но юноша с горящими глазами забивает бизнес-логику в presentation layer, прогоняет один раз, вроде работает, ура, коммитит. И если это не заметили на ревью (юнош много), то к тому моменту, когда всё развалится, переделывать придётся очень много.
Или, работают с коллекциями, LINQ в .NET, прекрасная вещь, написал строчку и всё готово. Что там под капотом никого не волнует, а там полноценная итерация. Итерация, поверх итерации и ещё условие — O(N^3) как с куста. И всё в порядке с технологиями.
А у сениора когда он такое видит сразу глаза кровью наливаются :-)
SeregaSA73
25.01.2018 19:48"Если у меня будет выбор между уставшим от технологий ветераном или выпускником, с горящими глазами рассуждающим об особенностях новой технологии — я бы предпочел последнего." — должны быть оба, ветеран контролирует новичка, ибо новичок наломает дров и получится как последний запуск с Восточного.
Antervis
25.01.2018 20:58И каждый раз, когда от меня требуют быть дружелюбным или учить джуниоров — мне становится немного грустно.
Быть дружелюбным — это требование применимо к любому сотрутнику, а не только к сеньору. Смысл нанимать того, кто будет третьим в команде из лебедя, рака и щуки?
Уж лучше обучать, чем перепроверять
Mugik
25.01.2018 21:34Обычно недружелюбные и эталонные интроверты, работающие в своём мирке обладают огромным чувством собственной важности, умности и прочего. И в 96% случаях их способности и таланты на уровне очень низком. Зато считают, что это не так.
Может у меня только была такая выборка. Не знаю. Но чаще всего дружелюбные, экстраверты, общительные ребята отлично знают своё дело и очень хорошо шарят в теме и делают реально крутые вещи.
Zanak
25.01.2018 22:22Исходя из своего опыта, я готов несогласится с автором.
10+ лет опыта
Нужно посмотреть, в чем этот самый опыт заключается. Не исключено, что опыта решения именно специфичных для вашей конторы задач у чела может и не оказаться.
Самостоятельный
Бывал в ситуации, когда разработчик решал не ту задачу, которую перед ним ставили. Например: требовалось написать примитивный скрипт на php, который автоматизирует мелкий процесс в жизни заказчика, и этот скрипт следующие лет 5 точно не поменяется, а вместо этого получил полуготовую CMS с ворохом ненужного кода.
Незаменим
Отделимость проекта от его создателя — это прежде всего в интересах работодателя. Как минимум должны быть критерии достаточности документирования: коментарии в коде, переписка в задаче, wiki, что — то еще, и хотя бы формальный надзор за их исполнением.
Коммуникабельный
Коммуникабельность, как способность внятно излагать свои мысли и готовность учитывать, что твой собеседник не всегда программист, это да.
Способность не быть угрюмым молчуном и поддерживать нормальную беседу с коллегами, тоже да.
Корпоративный дух и общие мероприятия, официальные, вроде нового года и других праздников, и неофициальные, вроде выхода на природу или похода в сауну, это, скорее нет, чем да. Общение через нехочу — это точно не мое.
saintbyte
26.01.2018 11:39ИМХО Сеньор это тот кто не сошел еще с ума после 10 лет разработки, знает что все плохо и смирился с этим. Это не космонавт — это святой.
VolCh
26.01.2018 11:50А если не смерился и пытается хотя бы локально улучшить "все плохо"?
saintbyte
26.01.2018 16:04Значит не Сеньор. Сеньор должен знать что человек несовершенен и еще более несовершенен его код. И цитата из «святого писания»: Высочайший уровень интеллекта — далеко не главное условие для человека, желающего стать хорошим
программистом.
Совершенный код, Макконнелл 33.2
Fesor
26.01.2018 18:15Не путайте принятие и смирение. Я могу принять что мир несовершенен, что все плохо, но это ни коем образом не обязывает меня с этим мириться. Я просто могу это учитывать, но продолжать экспериментировать с целью хоть что-то улучшить.
p.s. цитату вы привели тоже не к месту. Про уровень интеллекта никто вообще не говорил. А так выходит что синьер это застой и тупость (я утрирую конечно).
saintbyte
27.01.2018 03:06Само подобное суждение говорит о вашей гордыни, а гордыня это несовершенство.
Отриньте гордыню и поймите уже вы не совершены, ваши мысли не совершены, а ваш код… Апеллируйте уже не философским понятиями, а математическим.VolCh
27.01.2018 14:22+1Но ничто не мешает стараться стать самому более совершенным, писать более совершенный код и, даже, делать код написанный другими более совершенным.
Varim
27.01.2018 15:13Более совершенный код не самоцель для работодателя, поэтому написал более менее понятный код, что бы через пол года самому было понятно и норм., всегда так делаю. (а может нет, но стараюсь, по крайней мере иногда, когда есть время (никогда))
Fesor
27.01.2018 15:18+1более совершенный = более эффективный, понятный, гибкий, менее подверженный рискам или с более предсказуемыми рисками. Эдакий компромис между всеми составляющими которые в конечном итога можно пересчитать как профит для бизнеса (он должен быть, иначе нет смысла).
И да, речь не только о коде, а скорее о том как в целом вы за задачи беретесь, как происходит сбор и анализ требований, весь пайплайн от "хочу" до продакшена можно улучшать. Все же разработка это в меньшей степени код. А если мы только на коде будем зацикливаться — тогда будет как у всех — нет времени что-то улучшать.
VolCh
27.01.2018 15:19+1Мелкие совершенствования кода типа минимального использования невнятных сокращений или выделений кусков кода в отдельные методы/функции с говорящими именами, даже если повторного использования нет и не предвидится, практически не влияют на затраченное на начальную разработку время, с одной стороны, а, с другой, должны сокращать время на доработки/исправления/развитие. То есть в целом, стремление писать более соврешенный код не противоречит интересам работодателя, если не ставить себе самоцелью писать совершенный код.
muhaa
28.01.2018 01:32Мне больше 40. По себе могу сказать, что утомляет не изучение новых технологий, а изучение старых.
Если бы мне предложили срочно делать проект на Хаскеле или на React (которых я не знаю), глаза у меня горели бы не меньше, чем в 25. Проблема в том, что кроме того, постоянно приходится изучать вроде-бы новые технологии, в которых 90% по сути старое, но другое.
У меня в голове полно места для новых идей, но совсем нет места для простых навыков, которые у меня уже есть и которые нужно заместить новыми. Лет до 40 это не было для меня проблемой.
SirEdvin
Тут есть два замечания:
alexs0ff
Скорее всего речь автор ведет о web разработке
TyVik
Да и в веб-разработке тоже не очень. Концепции и синтаксис Java, PHP, Python поменялись не сильно, разве что новые языки добавились. Скорее всего вы имели ввиду js — вот тут действительно за всеми новыми фреймворками и фичами не уследишь.
php_freelancer
SPA — не так давно внедряются в мир. Я вот не могу уже рендерить HTML странички в PHP, твигом и т.п. и прокидывать туда переменную с массивом постов из бд, тошнить начинает.
Microservices, SOA — из той же серии, правда, не такие уж незаменимые, но модные.
Docker — туда же.
Так что в разработке очень-очень часто все обновляется!
Fesor
до этого народ писал десктопный софт, где были те же компоненты в UI (виджеты), те же mvvm и т.д. Ну и как же не вспомнить ужасный extjs, mootols и прочие фреймворки. А еще помните flash/flex?
модные нынче flux это просто ребрендинг smalltalk mvc и т.д. подслащенный отсутствием ограничений по оперативке присущие концу 70-ых.
Микросервисы — это soa good parts. А сколько лет SOA, это ух прям. А до были actor model. И до этого тоже были интересные похожие идеи. Ничего нового. Просто хорошо забытое старое.
LXC появился 9 лет назад. Докер просто сделал это удобным. Ну и до докера тоже как-то инфраструктуру надо было налаживать.
На самом деле не очень. Качество инструментов растет — это да. А вот "координально нового", того что прям ставит под сомнение 10 лет опыта, такого я лично не знаю. У людей проблемы с простыми концепциями которые придумали лет 40 назад и которые никуда не исчезли, все еще best practice и т.д. Большинство просто даже не знают о их существовании (всякие там structured design и подобные раритетные штуки).
Ну и еще очень важный момент — 10 лет опыта должны быть 10-ю годами опыта а не 1 год повторенный 10 раз.
i8enn
Чертовски верное уточнение…
Viacheslav01
Верный путь к производству спагетти в промышленных масштабах.
evgenWebm
Чтобы понять, что вы не правы, вы просто должны открыть чейндж лог любого популярного браузера. И это будет только начала пути осознания, что вы не правы.
Да синтаксис языка может и не меняется. Но вот технологии меняются. И меняются очень часто. Не так недавно я радовался флексбоксу, а сейчас уже новые гриды подплывают. Или CSS, там нет изменений? Синтаксис тотже. Но теперь анимацию делают на голом CSS.
Да о чем говорить, если парадигма ООП меняется. Верней понятие этой парадигмы.
Fesor
принципы не меняются.
мы сейчас говорим о штуках которые изучаются за вечерок. Более того, чем больше опыта — тем проще изучается так как все базируется на более общих идеях.
Это что-то что надо как-то переосмыслять или чем-то принципиально отличается от анимаций на JS с точки зрения понимания того как работают все эти переходы и как их описать?
А вот тут мне даже интересно, что именно вы имеете ввиду. Начнем с того что есть 2 разных трактовки ООП (а то и больше), одна — просто надстройка над структурным программированием, а вторая — которую никто не понимает (под вдохновением от которой родилась концепция actor model).
Ну и в любом случае, если мы возьмем все популярные "парадигмы" и концепции, идеи там старые. Очень старые. Просто многие из этих идей хоть и были озвучены еще в 60-х, 70-х, в силу ограничений по железу небыли реализуемы.
Andrey-072
Концепции трактовки парадигмы меняются, как только подплывают новые гриды. А идеи принципов меняют технологии.
Fesor
как это коррелируется с опытом?
HellMaster_HaiL
Увидел такое своими глазами с моим коллегой: человек вполне себе разбирается в WinForms, но WPF обошёл его стороной, совсем. И в 2016м году он был искренне удивлен о том, как работают байндинги, что такое конверторы, стили, темплейты и в целом зачем MVVM.
SirEdvin
Справедливости ради, хотел бы заменить, что технология WPF появилась в 2006 году. Ну и тот же поход MVVM, который он использует начал упоминаться Microsoft в 2005.
HellMaster_HaiL
Простите, но не понял к чему Ваш комментарий?
lexore
Технологии, которым удивился коллега, были новыми только для него.
Чуть выше, в другой ветке написали про это:
sand14
А может и к лучшему?
К 2k16 этот ваш мертворожденный WPF стал уже таким жутчайшим легаси…
А если говорить о неплохих идеях, заложенных в нем (но либо плохо воплощенных, либо так и не воплощенных), так все равно к 2k16 в современном фронте значительно все поменялось — от идей до их реализации.
В том смысле — что если ваш коллега все это проскочил, то и ок, а то бы может там и застрял посильнее, чем в винформах.
P.S. С WPF довелось познакомиться и плотно поработать (с теми самыми "байндинги, что такое конверторы, стили, темплейты и в целом зачем MVVM").
aquamakc
А что сейчас лучше по вашему для Desktop GUI применять?
sand14
Хороший вопрос.
Что делать, если разработку дестопных UI-технологий забросили в угоду вебу?
Видимо, разрабатывать на том, что есть — на том же WPF или винформах.
Есть еще вариант разрабатывать десктопые приложение с вебовским UI — кажется, клиент Slack так разработан?
Когда то в пору Windows 8 Microsoft вроде так и планировали — чтобы писать декстопные формы на HTML5.
TheKnight
Qt. Их пока еще не забросили.
aquamakc
Как-то мы незаметно перешли с .Net на C++. Там ещё где-то GTK бродит.
TheKnight
Не нашел в треде привязки к до-диезу, однако нашел обсуждение текущих реалий разработки GUI. В таком контексте Qt вполне смотрится.
MacIn
Как же бессмертный WinAPI?
aquamakc
WinForms же
MacIn
Это NETовская обертка над WinAPI? Я просто не в курсе, работаю напрямую.
aquamakc
Именно.
justcooldude
Бессмертным он будет до виндекапец, его понимание, на самом деле, также важно, как понимание ассемблера. На мой взгляд, единственное, где тут стоит влезать в такую низкоуровневость — это крайняя необходимость в быстродействии и получении специфических фишек Винды. Гуи на нем писать сомнительно.
Chamie
UI в Qt можно и на JS писать, можно даже без С++ вообще.
aquamakc
Изначально шёл разговор про GUI на .Net (WPF). Автор камента написал, что WPF — жуткое легаси и устарело. Я спросил — если не WPF, то что применять? QT здесь вообще не в тему, поскольку языки .Net в фреймворке QT не поддерживаются от слова совсем. Есть, конечно QtSharp, но это просто обёртка над Qt, позволяющая пользовать его функционал в C# .Net и Mono. Причём, на мой скромный взгляд это может пригодится только для Mono (ну может, ещё .Net Core). Классический .Net на винде вполне может обходиьтся WPF`ом.
Antervis
а зачем вообще .net?
aquamakc
Что значит зачем? Код на нём пишут.
Antervis
из вашей логики не понятно зачем отказываться от Qt когда можно отказаться от .net
aquamakc
Действительно. Зачем ездить на метро, если есть фуникулёр? Логика странная. Разговор изначально шёл про .Net. Исключительно про .Net. Если позволите ещё одна аналогия. Стоят два человека, обсуждают чем лучше смазывать лыжи. Подходит третий и говорит — надо прорезиненные гусеницы ставить.
Fesor
а зачем вам C++?
VolCh
Какая разница над чем обёртка и вообще обёртка или полноценный продукт, если API для использовани из .Net/Mono имеется?
"может обходиться" != "единственный доступный вариант"
HellMaster_HaiL
Десктопные решения, представьте себе, еще дорабатываются и разрабатываются новые. На сколько я понимаю, Xamarin.Forms в принципе опирается на WPF. Разработка под Windows Store, так называемые UWP — тоже.
nbytes
Зачем? Мобильная платформа умерла, как давно вы пользовались Store на десктопе?(Это я про UWP и Store)
HellMaster_HaiL
Что зачем?
Для Вас может и да. Я лично до сих пор пользую WP. Да и Xamarin, на мой взгляд, имеет право на жизнь и востребована.
Сегодня.
shurutov
Да. Особенно, если вам придётся работать с 10-й версией.
SirEdvin
Ну, разве с 7.2 (вышла в 2002) сильно поменялась логика работы индексов? То есть, добавились новые, но старые вроде так же работали.
shurutov
Использовать только старые при современных требованиях? Вы это серьёзно?
SirEdvin
Нет конечно, изучать новые технологии нужно, но вы же используете старые индексы, например, Btree?
shurutov
Вот пройдитесь по описанию команды CREATE INDEX хотя бы. Настоятельно рекомендую.
И ещё неплохо было бы понимать, что Btree (balanced tree) — это логика. А вот физическая реализация может существенно различаться от версии к версии, что приводит к различиям в планах выполнения запросов и, соответственно, различном времени выполнения этих запросов на разных версиях ПГ. На соответствующих ресурсах неоднократно такие вопросы задаются.
Varim
И что, это вещи которые невозможно узнать «на лету», по ходу дела? Это мелочи которые вы же сами несколько раз на день гуглите по работе.
shurutov
Желание решать проблемы в проде — оно сейчас более востребовано, да. Только вот я предпочитаю не создавать этих проблем бездумным внедрением обновлений, когда обновление может существенно повлиять на работу существующего приложения, и/или разведением зоопарка из дикого количества различных ключ-значение решений, когда нужная функуциональность появляется в используемой СУБД.
А для этого надо не гуглить по несколько раз за день, а внимательно изучать, что появилось/изменилось в новой версии. Вот как-то так. Гуглить — это когда возникла конкретная проблема. Для уточнения конкретной возможности используемого ПО надо пользоваться официальной документацией. Тем более, что у постгреса поиск по документации весьма годный.
Varim
Когда появится необходимость — тогда и изучай, за счет времени оплачиваемого работодателем. (Если нет личного чистого интереса.)
Вот я с PG в проде работал мало. Но в случае надобности работодатель наймет меня и заплатит за мое обучение. (за то что я в рабочее время подтягиваю то что нужно работодателю)
По крайней мере если другие мои скилы подойдут работодателю.
Перед выбором БД и во время эксплуатации.
Любые знания которые не применяются забываются. Так что заранее учить подряд все нюансы нет никакого смысла, разве что ради интереса. Старые знания легко подтянуть до 10й версии. И то, далеко не всё понадобится в проде.
Предмет спора что основные идеи не поменялись с прошлых версий.
Всё это мелочи которые легко и достаточно быстро учатся, особенно если есть опыт с другими БД или есть понимание о чем идет речь.
GerrAlt
есть мнение что нужно всё-таки знать немного заранее — иначе трудно проектировать
вот не знаешь, допустим, что в pg10 есть xmltable, а он бы может как раз очень подошел вместо второй СУБД умеющей xml
Fesor
вы когда вдруг решаете хранить xml в базе данных, даже если вы никогда не использовали постгрес до этого, можете хотя бы поинтересоваться умеет ли он это. Вроде ж не сложно, и ничего не надо сильно заранее штудировать и изучать.
Я вот постгрес использую последние года 4, ждал релиз 10-ки но про xmltable вот не знаю. И не особо переживаю по этому поводу. Как никак, плюшка довольно редко используемая.
С другой стороны незнание о таких вещах может подтолкнуть к более сложным решениям в духе конвертации xml в другую модель данных, хотя по факту хватило бы просто xpath.
Varim
Что же там такого появилось в 10й версии?
shurutov
Рекомендую изучить (на русском, если что):
https://postgrespro.ru/docs/postgresql/10/release.html
https://postgrespro.ru/docs/postgresql/10/release-10-1.html
Я лучше всё равно не скажу.
potan
Я бы не сказал, что что-то поменалось так, что рядовому энтерпрайсному программисту придется переучиваться.
shurutov
В случае ПГ более корректным термином является "доучиваться". Ибо от версии к версии возможности по работе со всякими JSON-ами всё улучшаются и улучшаются. Это для разработчиков приложений. Для эксплуататоров и АБД — перелопачиваются хранилища, что влияет на планы запросов и, соответственно, на производительность.
Fesor
лучше ответте на простой вопрос. Допустим 10 лет назад человек знал postgresql. Никаких jsonb небыло, другие СУБД по возможностям были примерно там же… Предположим что волею судьбы мы на 10 лет отстранились от psql. А теперь вопрос — мы вообще на 10 лет ушли от баз данных и SQL? Версткой начали заниматься? Ну так тут тогда нет 10-ти лет опыта.
А если мы все же занимались разработкой и так или иначе юзали ораклы, ms sql, мускули и т.д. читали статьи и новости то если через 10 лет мы вдруг решили "а сделаю я проект с postgres 10" — я не думаю что у челвоека уйдет больше недели на то что бы восстановить знания и ознакомиться с новыми плюшками.
Varim
shurutov
Ключевое в любом описании новшеств любого ПО, не только постгреса — список несовместимых с предыдущими версиями изменений. А у 10-ки этот список весьма приличный.
Fesor
а вам нужны всякие брин индексы? Вряд ли зная постгрес 10 лет назад и сейчас вы не сможете почитать вики или в целом были в информационном вакууме и вообще ничего не знали про psql.
romuto
По поводу актуальности Psql хорошо сказано в подкасте радиота, выпуск 574, начиная с 1:28:00
radio-t.com/p/2017/12/02/podcast-574
Нет, переучивать не нужно, нужно учить Монгу, если вы этого еще не сделали!
SirEdvin
Не могу послушать, у этих ребят кривой сайт и не мотается подкаст.
Там кластер уже не разваливается с пол-пинка? В любом случае, каждому делу свой инструмент.
Fesor
мне казалось мода на монгу уже давно канула в лету. jsonb в постгресе покрывает 90% юзкейсов для которых люди брали монгу. Возможность быстро на монге делать шарды и реплики перекрывается отсутствием реальной необходимости у тех же 90% в этом. Да и есть более интересные решения вроде тех же orientdb или arangodb.
То что сегодня надо уметь не только в реляционную модель но и понимать зачем нужны document/column/key value модели, это факт. Но это не обязательно должна быть монга и это никак не говорит что пора выкидывать любимый постгрес.
Я бы не стал инвестировать свое время в монгу (в 13-ом году пол годика побаловались и хватит), да и с точки зрения управления данными есть куча прикольных концептов вроде aws dynamodb в купе с хайповыми нынче serverless решениями.