Почитайте уже оригинальную статью Мартина и все комментарии, данные автором к ней за 20 лет.
Martin defines a responsibility as a reason to change, and concludes that a class or module should have one, and only one, reason to be changed (e.g. rewritten).
Отсюда следует, что если в вашей игре код движения персонажа используется, грубо говоря, еще и для движения облаков, то однажды вы налетите на всратые баги, когда какие-то фиксы для облаков затронут персонажей или наоборот.
При этом принцип не заставляет вас создавать CharacterMovement, CharacterCombat, CharacterInteraction и CharacterAnimation. Это обычно получается само собой из соображений сложности поддержки и восприятия или если, опять же, изменения в движении персонажа начинают засаживать баги в боевую систему. А так весь код персонажа вполне может быть в одном классе.
Также см. принцип "low coupling high cohesion", который идет рука об руку с SRP.
как кандидат видит свою работу, как часть бизнеса, а не просто закрывает ишуи.
Это я согласен. Я как раз топлю за то, чтобы в резюме было "мясо" по технике: улучшил, ускорил, упростил, внедрил, убрал ненужное. Но когда пишут типа "кодил кодил и привлек +30% новых клиентов" - это комично выглядит. Особенно если пишут люди из большого финтеха.
Наша команда последний год пашет как крабы на галерах. Но если я спрошу у начальства, как наши усилия повлияли на успешность бизнеса, то оно вряд ли ответит. Не из вредности, а потому что посчитать тяжело. И чем крупнее компания, тем сложнее считать.
Я бы снес все эти "программирование на", "умение работать с". Просто визуальный шум, который никакой информации не добавляет. "Программирование на Golang" - а что еще бывает на Golang? Приготовление пищи на Golang? Бурение скважин на Golang? Весь раздел можно сделать в 3 раза короче, если просто ключевые слова перечислить. Собственно по ним поиск и идет потом.
Администрирование UNIX-like систем.
С таким вообще поосторожнее надо. Программист и администратор - разные профессии. Вероятность, что человек за 2 года карьеры овладел обоими, стремиться к нулю.
Ваша правда. Просто я очень давно не слышал, чтобы стримы потоками называли. Но вопрос-то тот же остается. Стримы работают хуже, чем где? И что вообще означает "хуже" в данном контексте?
В него все же были введены ... потоки ... однако это работало хуже, чем в других языках
Потоки появились вместе с джавой в 1996 году. Они работали хуже, чем в каких именно языках?
не поддерживает множественное наследование
И спокойно живет с этим уже почти 30 лет. Что как бы говорит о "ценности" этой фичи.
Вообще забавно. Видно, что не Чятик писал. Но местами лучше бы уж Чятик. Учить подростков - дело благое. Но ученикам нисколько не лучше от того, что ради упрощения материала вы, мягко говоря, очень вольно обращаетесь с некоторыми фактами и концепциями.
Здорово, конечно, но это борьба с последствиями, а не с причиной. Стоило бы задать вопрос, почему вообще в бэклоге копятся задачи без перспектив к исполнению. И от этого начинать активность по работе с бизнесом и с разработкой. А так прибрались один раз - и цикл начался заново.
Например, мы пришли ко всеобщему соглашению, что столбец TODO в трекере состоит из Х багов, Х технических тасков и 2Х фич и общее число тасков не более N. Исключена ситуация, когда там одни фичи, а в бэклоге тонны рефакторинга и багов. Если число тасков меньше N, то нужно добавить таски именно недостающего типа.
Вообще речь шла про управление климатом в особняке на около-Рублевке. Вы себе представляете промышленный HMI в тех интерьерах? Зачем там вообще дубовое искро- и взрывозащитное устройство промышленного назначения?
Во-первых, как я уже говорил, резистивный экран. По экрану натурально надо бить кулаком, чтобы что-то нажать.
Во-вторых, тулкит в принципе не позволял изобразить вменяемый UI. 16 цветов, прямоугольники, символы - все. И еще для кириллицы шрифты только с засечками.
В панельках + железе как таковых ничего плохого нет. В итоге-то мы, инженеры, продавили тему прекратить впаривать клиентам всякую дичь. Стали использовать панельки Weintek.
Вот тоже ощущение, что все свободы, достигнутые в последние 50 лет уже дошатали. Пришел черед шатать достижения 100-летней давности. А там и Юрьев День недалеко.
То есть заказчикам норм. Исполнителям норм. Производителям норм
Воистину. Моя тогдашняя контора пилила АСУ для бытового климат-контроля. Начальник в 2015г на голубом глазу впаривал клиентам в качестве HMI промышленные резистивные панели 800х600. Им место в кочегарке, а не в модном лофте. Меня просто в ступор вводило, почему всем норм, почему у начальника хватает на это совести, а у заказчиков не хватает ума отказаться от этой дичи и потребовать реализацию HMI через iPAd.
И самое смешное, что я могу делать так, как вы описали. Но это скучно :) Успешно решить задачу обхода кавераджа технически - гораздо интереснее!
"господа, давайте не будем усердствовать с лимитом процента покрытия для прохождения деплоя, а то на Хабре есть статья как это дело прохачивать"
Пруфы, Билли, нам нужны пруфы. Без пруфов вы никакой не "тот чувак", а именно что маргинал, который хотел пошатать систему, а пошатал полторы строчки кода и родил из этого статью.
Огромное количество сред разработки PLC / HMI / SCADA («зоопарк»)
Работал я с ПЛК Honeywell Centraline. У этих клоунов для 4 контроллеров: Lion, Falcon, Hawk, Eagle - было 4 языка и соответственно 4 IDE. И самое смешное, что выходишь ты, знаток этого зоопарка, на рынок - и твой опыт там ни с чем не бьется и никому не нужен. А для компании отдельный квест найти тебе замену с опытом.
Отличный пример того, что когда не вырабатываются стандарты и кажды гребет под себя, то в итоге все в проигрыше.
ресурс снова станет профессиональным а не школьным
Вы себя тоже тут профессионалом не показываете.
Профессионально - это собрать своих коллег и ЛПРов и предметно доказать им, что ваша точка зрения ("тесты не нужны", "покрытие ну нужно") верна. Далее в вашей организации дружно отменили бы все "лишние" проверки, тесты и код-ревью заодно. Потом вы бы собрали метрики, которые показывают, что без тестов сложное ПО пишется быстрее и содержит меньше ошибок. Потом с этой фактурой вы пришли бы на Хабр и доказали бы уже всем, что ваша точка зрения верна.
А ничего этого не происходит, и вы просто выражаете маргинальную точку зрения без пруфов. А "школьный" при этом хабр, да.
Короче вместо того, чтобы бороться с бюрократом, который навязал вам каверадж, без которого не проходит CI, вы призываете бороться с самим кавераджем и заодно с вашими коллегами, которые будут читать и поддерживать код.
Ну студенты Плешки пусть сами за себя отвечают. А я закончил 12 лет назад, и год у нас стоил как раз около 100к.
Да и даже если по цифрам у вас все складно, то в текущих реалиях государству по факту все равно нет выгоды от людей просиживающих штаны. Тем самым оно просто откладывает нормальный старт карьеры налогоплательщика и опять же лишает себя нормальных налогов.
Зато есть массовый набег вьюношей на яндексы и гуглы. Потому что жизнь одна, и потратить лучшие годы на борьбу с ветряными мельницами в пыльных коридорах НИИ - дураков нет. После 30 лет какого-никакого рынка счет, как говорится, на табло. Всем понятно, где большинство этих НИИ и какой у них потенциал.
Я, конечно, оружейник не настоящий, но на картинке точно пистолет есть? Даже глок металлические части имеет, а на картинке вообще все прозрачное.
Почитайте уже оригинальную статью Мартина и все комментарии, данные автором к ней за 20 лет.
Отсюда следует, что если в вашей игре код движения персонажа используется, грубо говоря, еще и для движения облаков, то однажды вы налетите на всратые баги, когда какие-то фиксы для облаков затронут персонажей или наоборот.
При этом принцип не заставляет вас создавать CharacterMovement, CharacterCombat, CharacterInteraction и CharacterAnimation. Это обычно получается само собой из соображений сложности поддержки и восприятия или если, опять же, изменения в движении персонажа начинают засаживать баги в боевую систему. А так весь код персонажа вполне может быть в одном классе.
Также см. принцип "low coupling high cohesion", который идет рука об руку с SRP.
Это я согласен. Я как раз топлю за то, чтобы в резюме было "мясо" по технике: улучшил, ускорил, упростил, внедрил, убрал ненужное. Но когда пишут типа "кодил кодил и привлек +30% новых клиентов" - это комично выглядит. Особенно если пишут люди из большого финтеха.
Наша команда последний год пашет как крабы на галерах. Но если я спрошу у начальства, как наши усилия повлияли на успешность бизнеса, то оно вряд ли ответит. Не из вредности, а потому что посчитать тяжело. И чем крупнее компания, тем сложнее считать.
Я бы снес все эти "программирование на", "умение работать с". Просто визуальный шум, который никакой информации не добавляет. "Программирование на Golang" - а что еще бывает на Golang? Приготовление пищи на Golang? Бурение скважин на Golang? Весь раздел можно сделать в 3 раза короче, если просто ключевые слова перечислить. Собственно по ним поиск и идет потом.
С таким вообще поосторожнее надо. Программист и администратор - разные профессии. Вероятность, что человек за 2 года карьеры овладел обоими, стремиться к нулю.
Ваша правда. Просто я очень давно не слышал, чтобы стримы потоками называли. Но вопрос-то тот же остается. Стримы работают хуже, чем где? И что вообще означает "хуже" в данном контексте?
Потоки появились вместе с джавой в 1996 году. Они работали хуже, чем в каких именно языках?
И спокойно живет с этим уже почти 30 лет. Что как бы говорит о "ценности" этой фичи.
Вообще забавно. Видно, что не Чятик писал. Но местами лучше бы уж Чятик. Учить подростков - дело благое. Но ученикам нисколько не лучше от того, что ради упрощения материала вы, мягко говоря, очень вольно обращаетесь с некоторыми фактами и концепциями.
Здорово, конечно, но это борьба с последствиями, а не с причиной. Стоило бы задать вопрос, почему вообще в бэклоге копятся задачи без перспектив к исполнению. И от этого начинать активность по работе с бизнесом и с разработкой. А так прибрались один раз - и цикл начался заново.
Например, мы пришли ко всеобщему соглашению, что столбец TODO в трекере состоит из Х багов, Х технических тасков и 2Х фич и общее число тасков не более N. Исключена ситуация, когда там одни фичи, а в бэклоге тонны рефакторинга и багов. Если число тасков меньше N, то нужно добавить таски именно недостающего типа.
Вообще речь шла про управление климатом в особняке на около-Рублевке. Вы себе представляете промышленный HMI в тех интерьерах? Зачем там вообще дубовое искро- и взрывозащитное устройство промышленного назначения?
Во-первых, как я уже говорил, резистивный экран. По экрану натурально надо бить кулаком, чтобы что-то нажать.
Во-вторых, тулкит в принципе не позволял изобразить вменяемый UI. 16 цветов, прямоугольники, символы - все. И еще для кириллицы шрифты только с засечками.
В панельках + железе как таковых ничего плохого нет. В итоге-то мы, инженеры, продавили тему прекратить впаривать клиентам всякую дичь. Стали использовать панельки Weintek.
Вот тоже ощущение, что все свободы, достигнутые в последние 50 лет уже дошатали. Пришел черед шатать достижения 100-летней давности. А там и Юрьев День недалеко.
Как говорится, спустя 20 лет только дети и будут помнить, как батя упарывался на работе и дома не бывал.
Например, пусть исключения кидают только валидаторы на входе хэндлеров, но не сервисы и не репозитори
а) кто адресат этого сообщения? б) что адресат должен сделать при получении?
Вообще не понял, с чем вы спорите. Я ровно эту же мысль и выражаю.
Воистину. Моя тогдашняя контора пилила АСУ для бытового климат-контроля. Начальник в 2015г на голубом глазу впаривал клиентам в качестве HMI промышленные резистивные панели 800х600. Им место в кочегарке, а не в модном лофте. Меня просто в ступор вводило, почему всем норм, почему у начальника хватает на это совести, а у заказчиков не хватает ума отказаться от этой дичи и потребовать реализацию HMI через iPAd.
Пруфы, Билли, нам нужны пруфы. Без пруфов вы никакой не "тот чувак", а именно что маргинал, который хотел пошатать систему, а пошатал полторы строчки кода и родил из этого статью.
Работал я с ПЛК Honeywell Centraline. У этих клоунов для 4 контроллеров: Lion, Falcon, Hawk, Eagle - было 4 языка и соответственно 4 IDE. И самое смешное, что выходишь ты, знаток этого зоопарка, на рынок - и твой опыт там ни с чем не бьется и никому не нужен. А для компании отдельный квест найти тебе замену с опытом.
Отличный пример того, что когда не вырабатываются стандарты и кажды гребет под себя, то в итоге все в проигрыше.
Вы себя тоже тут профессионалом не показываете.
Профессионально - это собрать своих коллег и ЛПРов и предметно доказать им, что ваша точка зрения ("тесты не нужны", "покрытие ну нужно") верна. Далее в вашей организации дружно отменили бы все "лишние" проверки, тесты и код-ревью заодно. Потом вы бы собрали метрики, которые показывают, что без тестов сложное ПО пишется быстрее и содержит меньше ошибок. Потом с этой фактурой вы пришли бы на Хабр и доказали бы уже всем, что ваша точка зрения верна.
А ничего этого не происходит, и вы просто выражаете маргинальную точку зрения без пруфов. А "школьный" при этом хабр, да.
Короче вместо того, чтобы бороться с бюрократом, который навязал вам каверадж, без которого не проходит CI, вы призываете бороться с самим кавераджем и заодно с вашими коллегами, которые будут читать и поддерживать код.
Ну студенты Плешки пусть сами за себя отвечают. А я закончил 12 лет назад, и год у нас стоил как раз около 100к.
Да и даже если по цифрам у вас все складно, то в текущих реалиях государству по факту все равно нет выгоды от людей просиживающих штаны. Тем самым оно просто откладывает нормальный старт карьеры налогоплательщика и опять же лишает себя нормальных налогов.
Налоги. Посмотрел свои 2НДФЛ - я за первые 3 года после универа как раз выплатил налогов немногим меньше 500к.
Почему устроиться куда хочешь, работать на ЗП по рынку и платить налоги - плохо. А протирать штаны в НИИ Заборостроения за МРОТ - хорошо?
Зато есть массовый набег вьюношей на яндексы и гуглы. Потому что жизнь одна, и потратить лучшие годы на борьбу с ветряными мельницами в пыльных коридорах НИИ - дураков нет. После 30 лет какого-никакого рынка счет, как говорится, на табло. Всем понятно, где большинство этих НИИ и какой у них потенциал.