Любой из пунктов прокачивается в рамках обычной работы, особенно если проект активно растет. Но конечно, если сидишь на поддержке седого легаси, то и литкод - соловей.
Сразу скажу, что титулы "синьор реакта", "синьор AWSа" и подобные - это какая-то хрень... Синьор - это про фундаментальные знания и успешный опыт множества серьёзных разработок с применением этих знаний
Сразу скажу, что чемпион мира по легкой атлетике или чемпион MotoGP и подобные - это какая-то хрень. Чемпион - это фундаментальные навыки в спорте и успешный опыт множества соревнований.
Вот так вот легко сбросить мишуру с вашего основного тезиса.
Стандарта нет. Вот например на протокол TCP есть стандарт, а на квалификацию кодера нет. Поэтому нельзя сказать "реальный TCP - это когда розовые пони летят по проводам". Потому что есть стандарт. А про "реального сеньора" можно словоблудить хоть каждый день - что мы и наблюдаем.
Короче, у вас в трудовой написано "старший" и вы получаете по рынку как "старший" - все, achievement unlocked, вы сеньор. И никаким словоблудием вы этого не достигнете, если данный конкретный работодатель вас оценит ниже.
Дискутируя с заголовком, а не с содержанием, замечу, что и девопс и гибкие методологии разработки работают - но только если к ним прийти эволюционным путем. Нельзя просто взять за шиворот команду, работающую по лекалам прошлого века, и закинуть ее в светлое будущее. Так же как нельзя цивилизацию из феодализма зашвырнуть в коммунизм, где все в кайф.
Имел честь работать в стартапе, сформированный людьми, бежавшими от сберджайл-трансформации. Все практики у нас прекрасно работали.
Мне почему-то кажется, что вы уже говорите "гоп", но еще не перепрыгнули.
На моем прошлом проекте на момент моего прихода тоже была ситуация, когда абстрактные абстракции были написаны "шоб было" и "потому что это джава". По моим наблюдениям, люди, начавшие карьеру джависта еще в нулевых, по какой-то причине эти приседания просто обожали.
И первым этапом рефакторинга как раз было массовое упрощение по принциам чистого кода и с внедрением единого нейминга по глоссарию проекта. Тоже выкинули два камаза хлама. Но кажущаяся когнитивная простота кода вовсе не привела с собой скорость разработки и поддержки. Не вдаваясь в подробности проекта могу сказать, что на добалвение нового "плагина" как тратилось 2-3 недели - так и продолжало тратиться.
И тогда начался второй этап рефакторинга. Когда на уже наработанной кодовой базе с хорошей структурой кода и сквозным неймнгом стало видно, где реально просятся обобщения и паттерны. В основном провели рефакторинг по SOLID, где-то внедрили CQRS и event-driven architecture. И вот тогда я поставил свой личный рекорд, когда написал новый "плагин" за 2 рабочих дня.
Главный вопрос: что важнее для тебя как для соискателя, чтобы рекрутер понимал как развернуть кластер на виртуалке или "шарил за рынок"
Знаете, работник автозаправки не обязан знать про крекинг и циклоалканы, но бензин от дизеля отличать-то должен. А вы (коллективное КА) зачастую даже таких базовых когнитивных способностей не демонстрируете. Про JS и Java уже вспоминали. А сколько еще приколов, например, с Project Reactor и ReactJS.
В целом, в том-то и беда, что за рынок вы (коллективное КА) шарите так же, как и кластеры разворачиваете.
Ваша "разъясняющая" статья перестает быть сколь-нибудь полезной в тот момент, когда валит в одну кучу все возможные виды тестирования. Их много и ими должны заниматься несколько разные специалисты.
Ну а если кто считает, что все же разработчик должен заниматься всем тестированием на свете, то такой человек просто отрицает принцип разделения труда.
Если у вас сквозная функциональность нужна посреди метода бизнес-логики, то стоит задуматься либо о том, реально ли это сквозная функциональность, либо грамотно ли декомпозирован код. Еще стоит задуматься, стоит ли выносить синхронизацию в сквозную функциональность. Сомнительно, что коллеги будут вам благодарны.
Спору нет, код бывает всякий, - но спринговый механизм успешно закрывает 99% кейсов. Труднее найти код, где аспектов нет. Я в курсе, что есть пуристы и сектанты, которым любой спринговый сахар как ножом по сердцу. Но в среднестатистическом приложении менеджмент транзакций - аспект, логирование запросов - аспект, обработка исключений в контроллерах - аспект.
Так и в чем же принцип не работает? Вы же таки декомпозировали код, а не решили оставить как есть.
Ну и кроме того, сам SRP изначально как раз и формулируется в терминах связности и причин к изменениям: "There should never be more than one reason for a class to change". А вовсе не в терминах "делать что-то одно и хорошо". Это лишь следствие, которое лучше укрепилось в массовом сознании.
Кстати да, скорее всего резюме слабо написано. АСУ ТП - это тоже программирование. Где-то это языки FBD и программирование мышкой, где-то прям код си-подобных проприетарных языков. Плюс опыт пусконаладки и общения с заказчиком.
Это все далеко не бесполезные навыки. Их нужно уметь правильно подать.
Если автор любит смотреть глазами эффективных менеджеров, то пусть сам себе и ответит, сильно ли он нужен в ИТ. Потому что то, что завершающий статью пассаж есть ни что иное, как взывание к альтруизму и человечности. Но где менеджеры и где альтруизм и человечность?
Сравнение на 5 из 5 просто. В конторах с серьезной инженерией точно так же есть аналитики, архитектор и далее по тексту. И математик есть, и технолог даже. Никто не пилит серьезный (и коммерчески успешный) rocket science в одиночку в гараже.
Опыт вникания нужно экстраполировать на отношения между любыми коллегами. Каждый должен понимать, чем живут другие. Иначе получается не команда, а пачка премудрых пескарей по норам. Имел несчастье оказаться в такой. Ну и продукт будет так себе.
Но изменились ли стандарты за это время? Идею декомпозиции кода формализовала Банда Четырех аж в 1994 году. Потом в 2000 году Мартин формализовал свой SOLID. То есть 10 лет назад уже были вменяемые гайды на написание чистого кода - но в энтерпрайзе их предпочитали не замечать.И до сих пор предпочитают, но сейчас уже бОльшему числу людей понятно что так жить нельзя.
Ой как жизненно. Работал я в одной конторе и своими глазами видел адовый говнокод десятилетней выдержки за авторством людей, который на момент моего присутствия были уже начальниками отделов и департаментов.
Кроме шуток - это сильно меня впечатлило. После такоого я, честное слово, стараюсь писать код так, чтобы меня спустя 10 лет никто плохим словом не поминал.
Ну то есть, резюмируя, вы уходите от именно беседы. И двигаетесь по направлению к Яндексу и его фрейдовской фиксации на литкоде и собесам в 5 этапов. Колесо изобретено.
Прямой путь к постоянному регрессу. И с QA быстро отношения испортятся. Они взяли на проверку кейс А, а вы попутно нарефакторили еще и кейсы В и С, на которые ресурсы никто не выделял.
Я связываю вал статей про выгорание с общей инфляцией корпуса специалистов в IT. Как известно, стать сеньором-помидором теперь можно всего за 3 месяца курсов. Как следствие - квалифицированный разработчик вместо разработки занимается подтиранием слюней за курсантами-разрабами, курсантами-QAшниками, курсантами-аналитиками и даже курсантами-ПМами. И тут реально вопрос, как не взвыть волком.
Любой из пунктов прокачивается в рамках обычной работы, особенно если проект активно растет. Но конечно, если сидишь на поддержке седого легаси, то и литкод - соловей.
Сразу скажу, что чемпион мира по легкой атлетике или чемпион MotoGP и подобные - это какая-то хрень. Чемпион - это фундаментальные навыки в спорте и успешный опыт множества соревнований.
Вот так вот легко сбросить мишуру с вашего основного тезиса.
Стандарта нет. Вот например на протокол TCP есть стандарт, а на квалификацию кодера нет. Поэтому нельзя сказать "реальный TCP - это когда розовые пони летят по проводам". Потому что есть стандарт. А про "реального сеньора" можно словоблудить хоть каждый день - что мы и наблюдаем.
Короче, у вас в трудовой написано "старший" и вы получаете по рынку как "старший" - все, achievement unlocked, вы сеньор. И никаким словоблудием вы этого не достигнете, если данный конкретный работодатель вас оценит ниже.
Дискутируя с заголовком, а не с содержанием, замечу, что и девопс и гибкие методологии разработки работают - но только если к ним прийти эволюционным путем. Нельзя просто взять за шиворот команду, работающую по лекалам прошлого века, и закинуть ее в светлое будущее. Так же как нельзя цивилизацию из феодализма зашвырнуть в коммунизм, где все в кайф.
Имел честь работать в стартапе, сформированный людьми, бежавшими от сберджайл-трансформации. Все практики у нас прекрасно работали.
Мне почему-то кажется, что вы уже говорите "гоп", но еще не перепрыгнули.
На моем прошлом проекте на момент моего прихода тоже была ситуация, когда абстрактные абстракции были написаны "шоб было" и "потому что это джава". По моим наблюдениям, люди, начавшие карьеру джависта еще в нулевых, по какой-то причине эти приседания просто обожали.
И первым этапом рефакторинга как раз было массовое упрощение по принциам чистого кода и с внедрением единого нейминга по глоссарию проекта. Тоже выкинули два камаза хлама. Но кажущаяся когнитивная простота кода вовсе не привела с собой скорость разработки и поддержки. Не вдаваясь в подробности проекта могу сказать, что на добалвение нового "плагина" как тратилось 2-3 недели - так и продолжало тратиться.
И тогда начался второй этап рефакторинга. Когда на уже наработанной кодовой базе с хорошей структурой кода и сквозным неймнгом стало видно, где реально просятся обобщения и паттерны. В основном провели рефакторинг по SOLID, где-то внедрили CQRS и event-driven architecture. И вот тогда я поставил свой личный рекорд, когда написал новый "плагин" за 2 рабочих дня.
Думаю, ваша история еще не окончена.
Знаете, работник автозаправки не обязан знать про крекинг и циклоалканы, но бензин от дизеля отличать-то должен. А вы (коллективное КА) зачастую даже таких базовых когнитивных способностей не демонстрируете. Про JS и Java уже вспоминали. А сколько еще приколов, например, с Project Reactor и ReactJS.
В целом, в том-то и беда, что за рынок вы (коллективное КА) шарите так же, как и кластеры разворачиваете.
Ваша "разъясняющая" статья перестает быть сколь-нибудь полезной в тот момент, когда валит в одну кучу все возможные виды тестирования. Их много и ими должны заниматься несколько разные специалисты.
Ну а если кто считает, что все же разработчик должен заниматься всем тестированием на свете, то такой человек просто отрицает принцип разделения труда.
Если у вас сквозная функциональность нужна посреди метода бизнес-логики, то стоит задуматься либо о том, реально ли это сквозная функциональность, либо грамотно ли декомпозирован код. Еще стоит задуматься, стоит ли выносить синхронизацию в сквозную функциональность. Сомнительно, что коллеги будут вам благодарны.
Спору нет, код бывает всякий, - но спринговый механизм успешно закрывает 99% кейсов. Труднее найти код, где аспектов нет. Я в курсе, что есть пуристы и сектанты, которым любой спринговый сахар как ножом по сердцу. Но в среднестатистическом приложении менеджмент транзакций - аспект, логирование запросов - аспект, обработка исключений в контроллерах - аспект.
Так и в чем же принцип не работает? Вы же таки декомпозировали код, а не решили оставить как есть.
Ну и кроме того, сам SRP изначально как раз и формулируется в терминах связности и причин к изменениям: "There should never be more than one reason for a class to change". А вовсе не в терминах "делать что-то одно и хорошо". Это лишь следствие, которое лучше укрепилось в массовом сознании.
Кстати да, скорее всего резюме слабо написано. АСУ ТП - это тоже программирование. Где-то это языки FBD и программирование мышкой, где-то прям код си-подобных проприетарных языков. Плюс опыт пусконаладки и общения с заказчиком.
Это все далеко не бесполезные навыки. Их нужно уметь правильно подать.
Если автор любит смотреть глазами эффективных менеджеров, то пусть сам себе и ответит, сильно ли он нужен в ИТ. Потому что то, что завершающий статью пассаж есть ни что иное, как взывание к альтруизму и человечности. Но где менеджеры и где альтруизм и человечность?
Описанное вами умозаключение есть "ошибка выжившего". Универсальным советом это быть никак не может. Особенно с учетом всех рисков.
Меня вот поражают эти советы стажерам идти во фриланс.
Во-первых, там за дешманский фриланс конкуренция ничуть не меньше, чем за джуновские позиции.
Во-вторых, кто является заказчиком дешманского фриланса, если не кроила? Тут скорее соберешь портфолио историй "как меня кинули".
В-третьих, это в целом равносильно совету новичку-охотнику пойти на медедя в одиночку с ножом. Ага, зато портфолио соберешь.
Сравнение на 5 из 5 просто. В конторах с серьезной инженерией точно так же есть аналитики, архитектор и далее по тексту. И математик есть, и технолог даже. Никто не пилит серьезный (и коммерчески успешный) rocket science в одиночку в гараже.
Опыт вникания нужно экстраполировать на отношения между любыми коллегами. Каждый должен понимать, чем живут другие. Иначе получается не команда, а пачка премудрых пескарей по норам. Имел несчастье оказаться в такой. Ну и продукт будет так себе.
Но изменились ли стандарты за это время? Идею декомпозиции кода формализовала Банда Четырех аж в 1994 году. Потом в 2000 году Мартин формализовал свой SOLID. То есть 10 лет назад уже были вменяемые гайды на написание чистого кода - но в энтерпрайзе их предпочитали не замечать.И до сих пор предпочитают, но сейчас уже бОльшему числу людей понятно что так жить нельзя.
Ой как жизненно. Работал я в одной конторе и своими глазами видел адовый говнокод десятилетней выдержки за авторством людей, который на момент моего присутствия были уже начальниками отделов и департаментов.
Кроме шуток - это сильно меня впечатлило. После такоого я, честное слово, стараюсь писать код так, чтобы меня спустя 10 лет никто плохим словом не поминал.
А мне кейс очень даже понятен. Задан открытый вопрос - но внезапно ожидается конкретный ответ. Ну тогда это уровень "угадай, какое число я загадал".
А девушка или не девушка - в тот момент это был человек на зарплате, исполняющий свои профессиональные обязанности.
Ну то есть, резюмируя, вы уходите от именно беседы. И двигаетесь по направлению к Яндексу и его фрейдовской фиксации на литкоде и собесам в 5 этапов. Колесо изобретено.
Прямой путь к постоянному регрессу. И с QA быстро отношения испортятся. Они взяли на проверку кейс А, а вы попутно нарефакторили еще и кейсы В и С, на которые ресурсы никто не выделял.
Я связываю вал статей про выгорание с общей инфляцией корпуса специалистов в IT. Как известно, стать сеньором-помидором теперь можно всего за 3 месяца курсов. Как следствие - квалифицированный разработчик вместо разработки занимается подтиранием слюней за курсантами-разрабами, курсантами-QAшниками, курсантами-аналитиками и даже курсантами-ПМами. И тут реально вопрос, как не взвыть волком.