Там и все остальное такого же качества. Берется более менее разумная идея, если её применять в меру, и доводится до абсурда -- и подается как эталон к которому нужно стремиться. На кого это рассчитано? Опытный человек конечно поймет что автор не знает меры и опыта около нуля. А джуниор подумает что так и надо, и будет вместо того чтобы думать головой, где нужно комментарий писать, а где и так ясно, ИЛИ где нужен unit test, а где лишняя трата времени ИЛИ где стоит разбивать класс на более мелкие, а где это только усложнит понимание программы -- будет везде по великим заветам клин кода делать хрень.
Ну а у меня обратный опыт свежий. 1) Попал сначала на проект который писали сначала обычные люди. Потом судя по source control пришли фанаты паттернов, интерфейсов, крутых библиотек publish–subscribe и классов по 10 строк. Потом им надоело, и они наняли Ипам. И вот я беру таску из Jira. Если код первой команды -- фиксится за день. Если код второй команды -- я сначала лазию два дня по их бесконечным патернам, посыланиям мессаджей, составляю диаграмму из десятков классов и так далее. И делаю таску 5 дней. И не только я -- мои коллеги которые больше лет на этом проекте, так же плавают в понимании зачем и когда делала команда номер 2. Ладно, это может не про чистый код. Это скорее про резюме девелопмент. 2) Другая компания -- большое предприятие. Тим лид фанат клин кода, и все подобраны такие же. Я по описанию вакансии понял что будут спрашивать, прочел за день википедию что такое SOLID, DDD и прочая аббревиатурная хрень. И меня взяли, хотя искали девелопера до этого уже пол года. Беру в работу какие то таски по сайтику на 3 странички. А там везде... DDD. Пять уровней абстракции, куча паттернов, и чтобы добавить поле в БД, нужно поправить 10 файлов в 5 проектах. Пишу класс с 1 методом на 10 строк -- мне пишут SRP. Чё не так? А вот действие на 5 строк должно быть в одном классе а exception ловить (другие 5 строк) в другом классе. И опять не только я теряю время. Я смотрю на коллег. Они постоянно обсуждают такие 4 класса завести или другие 6. То есть обсуждают не алгоритм как решить задачу, а как в этих уровнях абстракций не ошибиться, и паттернов понаделать как тим лид любит. Девушка middle dev решила прочесть книжку по библиотеке базовых классов .NET на третьем году программирования на C#, но уже успела прочесть 4 книги по клин коду. Клин код головного мозга :))
Да нет там ничего здорового. Что "здорового" может посоветовать человек с опытом джуниора в программировании? Я видел пример рефакторинга от этого инфо-цыганина. Берется класс условно с 3 методами, вполне логичными, но слишком длинными по мнению этого чудика, и разбиваются на 10 методов. Для этого несколько локальных переменных переносятся на уровень полей класса. То есть он из обычного нормального кода, делает говно код и пишет что сделал классно :) Этот болтун даже не понимает разницу между локальными переменными метода и полями класса, их назначением, областью видимости, и думает что их можно тасовать туда сюда, лишь бы методы были по 5 строк. Ну он же полнейший профан в программировании, нафига его макулатуру читать?
Ну или если этот выбор применить к начинающим. То конечно лучше "каждый сам себе художник". Потому что результатом "фанатичного следование советам чистого кода" будет точно, 100%, раздутый и запутанный говно-код, без вариантов. В то время как если не быть фанатиком абсурдных правил, то многие программисты с увеличением опыта и задумываясь о том как сделать лучше, придут к разумной золотой середине о правилах написания кода.
Какая глупая надуманная дилемма :)) Я вообще то профессионал с многолетним стажем. Зачем я должен выбирать между подходом новичка который пишет Hello World и ничего не знает ИЛИ набором доведенных до абсурда советов? Не в курсе зачем это я буду возвращаться на уровень ниже чем Junior? ;)
Это не инструмент. "Чистый код" это набор маркетинговых материалов, составленных человеком, весь опыт которого как девелопера -- какая та приложуха с карточками в конце 80х годов. Он собрал какие то вполне полезные советы, но так он не имеет практического опыта в разработке, то довел их до абсурда, до "методов по 5 строк", до "не писать комментарии" и так далее. Я читал комментарии, что мол я не следую советам этого деда буквально, а мол творчески. Так в чем тогда ценность его помойных книжек и курсов, если там даются вредные советы, но вот если их переосмыслить.... может тогда просто стоит выкинуть этот мусор в ведро, и найти что то дельное для чтения? Ну и да, а многие буквально применяют все что написал этот клоун. И еще гордятся собой :))
Автор статьи ПРАВ на 100%. Вкатуны в айти, в попытке найти волшебную палочку, нашли маркетинговые сказки какого то таланливого болтуна из Америки, который никогда сам не программировал, и стали на сказки МОЛИТЬСЯ :)) В итоге получается код который в несколько раз сложнее чем нужно, но адепты этого не знают, так как профильного образования у них или нет, или после ВУЗа они сразу попали под руководства адепта секты. Жрут кактусы, плачут, смотрят на сотни не нужных классов и интерфейсов, обвешивают все юнит тестами, которые проверяют 2 + 2, разбивают методы на бессмысленные куски по 3-5 строчек, и упорно не пишут комментариев -- но думают что пишут что ни на есть прекрасный и правильный Чистый Код, а остальные просто еще не постигли дзен :))
Тогда можно в ответ сформулировать, что не бывает квалифицированных инженеров, которые закончили курсы в несколько месяцев. Так ведь, логично? На самом деле бывают, и именно в айти таких много -- но только такие которые энтузиасты. А вот если нет ни профильного полноценного образования, ни увлечения-хобби, то вот тогда чудес не бывает.
Да понятно что в айти хорошо. Но большие зарплаты потому что случайные люди с улицы не могут работать -- закон спроса и предложения. Если бы можно было после месячных курсов набрать хороших работников, уже бы давно набрали и зарплаты в айти были бы как в пятерочке и магните у продавцов. Но оказывается, чтобы работать в айти нужно много учиться, а не просто курсы оплатить. У меня несколько знакомых интересовались, что им нужно изучить чтобы стать программистами и тоже на удаленке смузи попивать. Я давал им книжки, советы и так далее -- все через пару месяцев бросили, устали.
Как же врачи например, в 17 поступил в мед, и до 60 лечит людей. Или юристы, или бухгалтера, инженеры и так далее -- люди десятками лет, обычно всю жизнь, работают по одной профессии. А программист по вашему более 10 лет не выдерживает, переключаются на другие какие то вещи? Спора нет, потом уже приедается, уже не интересное хобби, а просто способ заработать. Но в первые годы, когда происходит основное обучение, человек действительно увлечен этим -- об этом я написал. А насчет того что я далек от разработки -- сначала 20 лет в айти, программистом, PM, несколько сот тех собеседований поступающих на работу, десятка полтора людей которых персонально менторил, потом да, надоело, 8 лет просто жил в удовольствие, ходил в походы, ездил по миру, занимался ребенком, и вот снова 2 года в разработке. А у вас какой опыт?
А так ли всем подряд нужно в айти, особенно если душа к этому не лежит. Ну как бы, если программирование было интересно, то подросток мог начать им заниматься уже лет в 14-16, а к 20 вполне обладать каким то знаниями даже без всяких курсов. А если человек, что то там закончил, на компьютере до этого 10 лет только в игры играл и качал курсовые, и тут в 25 лет решил побыстрому войти в айти и посидеть на курсах каких то, то может это и не должно получаться у 90%, может это нормально? вон какая востребованность в рабочих специальностях, не всем дано каждый рабочий день решать сложные логические задачи, читать на английском, и постоянно дообучаться.
Ну в рекламных проспектах Аджайл рекомендуют стенд-ап митинги умещать в 15 минут. Ок, в реальной жизни это часто пол часа .. час. Если один-на-один PM будет обзванивать, то будет тот же час в день (для него), при этом с одними подчиненными можно будет спокойно обсудить их вопрос, не беспокоясь что остальные ждут своей очереди, а кого то можно легко пропустить. На самом деле каждый день каждого человека какой вообще смысл опрашивать? Таски есть в JIRA, там же люди отмечают прогресс, если это квалифицированный товарищ то можно и раз в 2-3 дня общаться голосом, а в промежутках просто в чате пингануть типа "вопросы есть?". А какой нибудь джуниор -- так с ним с одним можно минут 15 беседовать о том что он и как делает. Так что никакого целого дня тут нет. А коммуникации с командой это и есть работа PM. Плюс планирование и коммуникации с заказчиком. Если на каждую из этих трех активностей выделить по 2 часа в день, еще и 2 часа на смузи останется.
По моему наблюдению, де факто, эти созвоны в большинстве команд являются вредной и не эффективной активностью. А куда более эффективно определить примерное время в которое PM обзванивает коллег в команде и они один-на-один выясняют как дела, и при необходимости могут ситуацию обсудить подробнее, не отвлекая еще десяток человек в команде. Рассказы в маркетинговых материалах по Аджайл, что всей команде полезно слушать что там творится у коллег, по факту в большинстве команд не работают -- все тупо ждут чтобы оттарабанить о своем прогрессе, а остальное время просто в пустую тратят время, слушая в пол уха (или не слушая вовсе, если уже отчитались).
Правильно отметил автор в пункте 2 про DRY. Расширю мысль -- программирование как инженерная задача столь сложна, что она не сводится к набору примитивных аббревиатур и принципов. Пытаемся убрать дублирующий код, т к заметили сходства в двух алгоритмах, а потом нас просят что то изменить в первом, но не трогать второй, и сходства уже меньше, а проблем от объединения кода в один класс или метод все больше. Так же SPR из SOLID, на который некоторые молятся -- и доходят в этом до абсурда, превращая 50 рационально разработанных классов в 500 микро-классов. Да, каждый из этих 500 классов конечно стал проще, но в целом каша из 500 микро-классов стала сложнее чем 50 нормальных. А корень всей этой проблемы в одном -- программирование это сложно, опыт нужно набирать годами, и все равно каждый раз думать головой -- где нужно разбить на два класса, где нужно два объединить в один, а где оставить как есть. Многие же люди, особенно которые недавно "вкатились в айти", думать не хотят, хотят следовать простым принципам, находят их в разных книжках, и потом пытаются найденным молотком забить все, как будто кругом только гвозди.
Дело ни в курсах, и ни в ВУЗе (хотя с высшим профильным шансы в разы больше). Самое главное -- чтобы программирование было реальным увлечением человека, чуть ли не главным хобби. Тогда и просто на самообразовании можно обучиться, чтобы начать хотя бы джуниором. А если не интересно, только отсидеть и получить корочку, то мало что поможет, ну разве что вышка по специальности, там то все таки 5 лет штаны просиживал -- какую то информацию за такой срок впитал даже без особого энтузиазма.
Несколько человек возрастом 30+ спрашивали меня совет с чего начать и что изучать чтобы стать программистами. Я советов, давал списки литературы, книжки и так далее. Всех хватило на 1-3 месяца, а потом они забили. Очевидно, что люди которые не сталкивались с программированием питают иллюзии, что они месяцок что то поизучают и можно уже пробовать работать. Реальность же в том, что нужен год минимум плотного изучения, а без реального интереса к такой деятельности, только за длинным рублем, мало у кого хватает мотивации учиться.
Очень хорошо если человек готов помочь, подсказать и научить. Главное, это отсечь нахлебников, которые по любой мелочи, в которой они и сами могут разобраться, сразу хотят от кого то получить готовенькое. Если же вы тратите 10 минут, а кому то экономите пол дня, то вы очень ценный специалист и хороший человек. Это заметят и коллеги, и менеджеры (если в компании здоровая корпоративная культура).
Там и все остальное такого же качества. Берется более менее разумная идея, если её применять в меру, и доводится до абсурда -- и подается как эталон к которому нужно стремиться. На кого это рассчитано? Опытный человек конечно поймет что автор не знает меры и опыта около нуля. А джуниор подумает что так и надо, и будет вместо того чтобы думать головой, где нужно комментарий писать, а где и так ясно, ИЛИ где нужен unit test, а где лишняя трата времени ИЛИ где стоит разбивать класс на более мелкие, а где это только усложнит понимание программы -- будет везде по великим заветам клин кода делать хрень.
Ну а у меня обратный опыт свежий. 1) Попал сначала на проект который писали сначала обычные люди. Потом судя по source control пришли фанаты паттернов, интерфейсов, крутых библиотек publish–subscribe и классов по 10 строк. Потом им надоело, и они наняли Ипам. И вот я беру таску из Jira. Если код первой команды -- фиксится за день. Если код второй команды -- я сначала лазию два дня по их бесконечным патернам, посыланиям мессаджей, составляю диаграмму из десятков классов и так далее. И делаю таску 5 дней. И не только я -- мои коллеги которые больше лет на этом проекте, так же плавают в понимании зачем и когда делала команда номер 2. Ладно, это может не про чистый код. Это скорее про резюме девелопмент. 2) Другая компания -- большое предприятие. Тим лид фанат клин кода, и все подобраны такие же. Я по описанию вакансии понял что будут спрашивать, прочел за день википедию что такое SOLID, DDD и прочая аббревиатурная хрень. И меня взяли, хотя искали девелопера до этого уже пол года. Беру в работу какие то таски по сайтику на 3 странички. А там везде... DDD. Пять уровней абстракции, куча паттернов, и чтобы добавить поле в БД, нужно поправить 10 файлов в 5 проектах. Пишу класс с 1 методом на 10 строк -- мне пишут SRP. Чё не так? А вот действие на 5 строк должно быть в одном классе а exception ловить (другие 5 строк) в другом классе. И опять не только я теряю время. Я смотрю на коллег. Они постоянно обсуждают такие 4 класса завести или другие 6. То есть обсуждают не алгоритм как решить задачу, а как в этих уровнях абстракций не ошибиться, и паттернов понаделать как тим лид любит. Девушка middle dev решила прочесть книжку по библиотеке базовых классов .NET на третьем году программирования на C#, но уже успела прочесть 4 книги по клин коду. Клин код головного мозга :))
Да нет там ничего здорового. Что "здорового" может посоветовать человек с опытом джуниора в программировании? Я видел пример рефакторинга от этого инфо-цыганина. Берется класс условно с 3 методами, вполне логичными, но слишком длинными по мнению этого чудика, и разбиваются на 10 методов. Для этого несколько локальных переменных переносятся на уровень полей класса. То есть он из обычного нормального кода, делает говно код и пишет что сделал классно :) Этот болтун даже не понимает разницу между локальными переменными метода и полями класса, их назначением, областью видимости, и думает что их можно тасовать туда сюда, лишь бы методы были по 5 строк. Ну он же полнейший профан в программировании, нафига его макулатуру читать?
Ну или если этот выбор применить к начинающим. То конечно лучше "каждый сам себе художник". Потому что результатом "фанатичного следование советам чистого кода" будет точно, 100%, раздутый и запутанный говно-код, без вариантов. В то время как если не быть фанатиком абсурдных правил, то многие программисты с увеличением опыта и задумываясь о том как сделать лучше, придут к разумной золотой середине о правилах написания кода.
Какая глупая надуманная дилемма :)) Я вообще то профессионал с многолетним стажем. Зачем я должен выбирать между подходом новичка который пишет Hello World и ничего не знает ИЛИ набором доведенных до абсурда советов? Не в курсе зачем это я буду возвращаться на уровень ниже чем Junior? ;)
Это не инструмент. "Чистый код" это набор маркетинговых материалов, составленных человеком, весь опыт которого как девелопера -- какая та приложуха с карточками в конце 80х годов. Он собрал какие то вполне полезные советы, но так он не имеет практического опыта в разработке, то довел их до абсурда, до "методов по 5 строк", до "не писать комментарии" и так далее. Я читал комментарии, что мол я не следую советам этого деда буквально, а мол творчески. Так в чем тогда ценность его помойных книжек и курсов, если там даются вредные советы, но вот если их переосмыслить.... может тогда просто стоит выкинуть этот мусор в ведро, и найти что то дельное для чтения? Ну и да, а многие буквально применяют все что написал этот клоун. И еще гордятся собой :))
Не очень понятно зачем потрачено столько труда, когда УЖЕ есть отличные книги по C#, и если нужно бесплатно, то можно скачать с торрентов
Скальпелинг и алго трейдинг. Ну ну. Так какой доход у вас получился от торговли на бирже вашим энтерпрайз софтом? :))
из Киева, слушаю Шамана... как то нужно поскладнее сказки сочинять!
Автор статьи ПРАВ на 100%. Вкатуны в айти, в попытке найти волшебную палочку, нашли маркетинговые сказки какого то таланливого болтуна из Америки, который никогда сам не программировал, и стали на сказки МОЛИТЬСЯ :)) В итоге получается код который в несколько раз сложнее чем нужно, но адепты этого не знают, так как профильного образования у них или нет, или после ВУЗа они сразу попали под руководства адепта секты. Жрут кактусы, плачут, смотрят на сотни не нужных классов и интерфейсов, обвешивают все юнит тестами, которые проверяют 2 + 2, разбивают методы на бессмысленные куски по 3-5 строчек, и упорно не пишут комментариев -- но думают что пишут что ни на есть прекрасный и правильный Чистый Код, а остальные просто еще не постигли дзен :))
Тогда можно в ответ сформулировать, что не бывает квалифицированных инженеров, которые закончили курсы в несколько месяцев. Так ведь, логично? На самом деле бывают, и именно в айти таких много -- но только такие которые энтузиасты. А вот если нет ни профильного полноценного образования, ни увлечения-хобби, то вот тогда чудес не бывает.
Да понятно что в айти хорошо. Но большие зарплаты потому что случайные люди с улицы не могут работать -- закон спроса и предложения. Если бы можно было после месячных курсов набрать хороших работников, уже бы давно набрали и зарплаты в айти были бы как в пятерочке и магните у продавцов. Но оказывается, чтобы работать в айти нужно много учиться, а не просто курсы оплатить. У меня несколько знакомых интересовались, что им нужно изучить чтобы стать программистами и тоже на удаленке смузи попивать. Я давал им книжки, советы и так далее -- все через пару месяцев бросили, устали.
Как же врачи например, в 17 поступил в мед, и до 60 лечит людей. Или юристы, или бухгалтера, инженеры и так далее -- люди десятками лет, обычно всю жизнь, работают по одной профессии. А программист по вашему более 10 лет не выдерживает, переключаются на другие какие то вещи? Спора нет, потом уже приедается, уже не интересное хобби, а просто способ заработать. Но в первые годы, когда происходит основное обучение, человек действительно увлечен этим -- об этом я написал. А насчет того что я далек от разработки -- сначала 20 лет в айти, программистом, PM, несколько сот тех собеседований поступающих на работу, десятка полтора людей которых персонально менторил, потом да, надоело, 8 лет просто жил в удовольствие, ходил в походы, ездил по миру, занимался ребенком, и вот снова 2 года в разработке. А у вас какой опыт?
А так ли всем подряд нужно в айти, особенно если душа к этому не лежит. Ну как бы, если программирование было интересно, то подросток мог начать им заниматься уже лет в 14-16, а к 20 вполне обладать каким то знаниями даже без всяких курсов. А если человек, что то там закончил, на компьютере до этого 10 лет только в игры играл и качал курсовые, и тут в 25 лет решил побыстрому войти в айти и посидеть на курсах каких то, то может это и не должно получаться у 90%, может это нормально? вон какая востребованность в рабочих специальностях, не всем дано каждый рабочий день решать сложные логические задачи, читать на английском, и постоянно дообучаться.
Ну в рекламных проспектах Аджайл рекомендуют стенд-ап митинги умещать в 15 минут. Ок, в реальной жизни это часто пол часа .. час. Если один-на-один PM будет обзванивать, то будет тот же час в день (для него), при этом с одними подчиненными можно будет спокойно обсудить их вопрос, не беспокоясь что остальные ждут своей очереди, а кого то можно легко пропустить. На самом деле каждый день каждого человека какой вообще смысл опрашивать? Таски есть в JIRA, там же люди отмечают прогресс, если это квалифицированный товарищ то можно и раз в 2-3 дня общаться голосом, а в промежутках просто в чате пингануть типа "вопросы есть?". А какой нибудь джуниор -- так с ним с одним можно минут 15 беседовать о том что он и как делает. Так что никакого целого дня тут нет. А коммуникации с командой это и есть работа PM. Плюс планирование и коммуникации с заказчиком. Если на каждую из этих трех активностей выделить по 2 часа в день, еще и 2 часа на смузи останется.
По моему наблюдению, де факто, эти созвоны в большинстве команд являются вредной и не эффективной активностью. А куда более эффективно определить примерное время в которое PM обзванивает коллег в команде и они один-на-один выясняют как дела, и при необходимости могут ситуацию обсудить подробнее, не отвлекая еще десяток человек в команде. Рассказы в маркетинговых материалах по Аджайл, что всей команде полезно слушать что там творится у коллег, по факту в большинстве команд не работают -- все тупо ждут чтобы оттарабанить о своем прогрессе, а остальное время просто в пустую тратят время, слушая в пол уха (или не слушая вовсе, если уже отчитались).
Правильно отметил автор в пункте 2 про DRY. Расширю мысль -- программирование как инженерная задача столь сложна, что она не сводится к набору примитивных аббревиатур и принципов. Пытаемся убрать дублирующий код, т к заметили сходства в двух алгоритмах, а потом нас просят что то изменить в первом, но не трогать второй, и сходства уже меньше, а проблем от объединения кода в один класс или метод все больше. Так же SPR из SOLID, на который некоторые молятся -- и доходят в этом до абсурда, превращая 50 рационально разработанных классов в 500 микро-классов. Да, каждый из этих 500 классов конечно стал проще, но в целом каша из 500 микро-классов стала сложнее чем 50 нормальных. А корень всей этой проблемы в одном -- программирование это сложно, опыт нужно набирать годами, и все равно каждый раз думать головой -- где нужно разбить на два класса, где нужно два объединить в один, а где оставить как есть. Многие же люди, особенно которые недавно "вкатились в айти", думать не хотят, хотят следовать простым принципам, находят их в разных книжках, и потом пытаются найденным молотком забить все, как будто кругом только гвозди.
Дело ни в курсах, и ни в ВУЗе (хотя с высшим профильным шансы в разы больше). Самое главное -- чтобы программирование было реальным увлечением человека, чуть ли не главным хобби. Тогда и просто на самообразовании можно обучиться, чтобы начать хотя бы джуниором. А если не интересно, только отсидеть и получить корочку, то мало что поможет, ну разве что вышка по специальности, там то все таки 5 лет штаны просиживал -- какую то информацию за такой срок впитал даже без особого энтузиазма.
Несколько человек возрастом 30+ спрашивали меня совет с чего начать и что изучать чтобы стать программистами. Я советов, давал списки литературы, книжки и так далее. Всех хватило на 1-3 месяца, а потом они забили. Очевидно, что люди которые не сталкивались с программированием питают иллюзии, что они месяцок что то поизучают и можно уже пробовать работать. Реальность же в том, что нужен год минимум плотного изучения, а без реального интереса к такой деятельности, только за длинным рублем, мало у кого хватает мотивации учиться.
Очень хорошо если человек готов помочь, подсказать и научить. Главное, это отсечь нахлебников, которые по любой мелочи, в которой они и сами могут разобраться, сразу хотят от кого то получить готовенькое. Если же вы тратите 10 минут, а кому то экономите пол дня, то вы очень ценный специалист и хороший человек. Это заметят и коллеги, и менеджеры (если в компании здоровая корпоративная культура).