Всегда есть самый компетентный, и если он не боится принимать решения — то ему не до́лжно бояться и признавать ошибки. Иначе грош ему цена.
Да можно хоть обпризнаваться, можно лоб разбить в монастыре от покаяния, но если в промышленной разработке на любом уровне бас фактор равен единице, то проблема не в самом распрекрасном суперстаре, как бы он ни был готов принимать на себя горы ответственности, а именно в процессе. Т.е. в менеджменте.
"А Basho взяли и разорились" - это не факап, а естественный риск, заложенный в саму природу принятия такого рода решений. Он сыграл, бывает.
Но, допустим, проблема бы была не конкретно в разорении вендора (называть его разорение собственным факапом это кокетство), а произошла бы действителньо ошибка ведущего специалиста, ошибка инженерного плана, выбрали неподходящее 3рд-пати решение, что это означает?
Судя по вашему "смог убедить" - решение принимал не один человек, а некий синклит (и это правильно). А значит, проблема была бы не в одном человеке, а в том, что его предложение неверно рассматривалось. Допустим, вместо полноценного ревью его предложений, с вниканием и собственным исследованием, просто послушали, махнули рукой и согласились. Ну так это опять-таки ошибка не разработчика, а организации процесса. Ч. и т.д.
Если ошибка разработчика становится проблемой для бизнеса - это не ошибка разработчика.
У такого разработчика зона ответственности не меньше, а часто — больше, ибо от его факапов может пострадать весь бизнес.
Не может.
Если от факапов разработчика может пострадать весь бизнес, значит, неправильно поставлены планирование и тестирование. И, возможно, найм.
Если от факапа разработчика внезапно пострадал весь бизнес, то это факап не разработчика, а его менеджмента (лида, инжиниринг-менеджера или кого бы то ни было)
Это так не работает. Недостаточно просто быть умным джуном.
Знания получаются разными путями, в том числе активным и пассивным. Когда вы читаете на новом языке, вы не учитесь на нём говорить, даже если вы читаете очень много - это просто разные навыки. Потому что когда вы читаете, вам не надо принимать решения (выбор правильных выражений), и при чтении навык этого принятия решения не вырабатывается, вырабатывается другой навык. Вот и получается - человек нормально читает, а сказать ни бэ ни мэ.
Если джун не будет принимать большое, очень большое количество правильных и неправильных решений на мелком уровне (из чего и складывается кодирование), ему будет трудно прогрессировать. Есть, конечно, всякие гении, но вайбкодинг попросту отнимает у среднестатистического джуна опыт, и далеко не всякий ум может скомпенсировать отсутствие опыта.
Это немножко неочевидно для технического ресурса, на котором пасутся инженеры (от которых ожидается, что они ориентированы на конструктивное и результативное общение), но знаете что.
Смысл реплик этого персонажа не в том, чтобы кого-то переубедить или даже просто высказать какую-то точку зрения. Смысл его реплик - произвести дискуссию и тем самым создать впечатление, что по теме есть разные точки зрения. Если беседа зайдёт не о том, хорошо ли или плохо этих самых детей лишать развивающих платформ, а, например, о том, хорош ли кушать этих детей с соусом на завтрак - он, поверьте, найдёт аргументы в пользу их поедания. Его цель - сделать длинную ветку комментариев.
Сделать с этим с помощью полемики ничего нельзя. Только с помощью явной или косвенной модерации. А если дискутировать, отвечать - они только рады (натурально они - в каждой репрессивной теме есть не-всё-так-однозначники с полутора десятками комментариев)
Очень познавательно. Хотя, разумеется, вполне себе существует более римская, чем надпись над воротами Колизея, нотация: это нотация, которой пользуется девяносто девять и девять процентов населения планеты и называет её "римской". Потому что значение слова, даже слова "римская", определяют не энциклопедии и не учебники, а словоупотребление. Но вопрос не в этом.
Скажите, а если не включать вот эту истерическую и отчасти оскорбительную клоунаду с "вы издеваетесь", "кащенко" и прочими элоквенционными экзерсисами, а просто сообщить любознательной публике, что нормализованная в современном мире римская система имела несколько другую форму в древности, то кто от этого пострадает? Почему бы не прийти к уважительному диалогу с публикой? Ну, возможно, будет чуть меньше плюсиков и минусиков, но, поверьте, оно того стоит.
Если водолаз в полном снаряжении по своей глупости залезет на подъёмный кран, упадёт с него и разобъётся, вы, возможно, скажете: "вот они, эти кислородные баллоны, совершенно не нужны". Приблизительно так выглядит ваша претензия.
Проблема вообще не в unwrap. Мало ли, может чуваку жена устроила скандал тем утром, и он забыл убрать, бывает.
Проблема в том, что существуют принципиальные ограничения на размер конфига, но теста на непрохождение этого ограничения, как оказалось, нет.
Т.е. это не вопрос языка и не вопрос ошибки программиста, это вопрос процесса разработки и технологической дисциплины. А вот тут уже вопросы не к одной строчке кода, а к инжиниринг-менеджерам клаудфлейра, ответственным за команду.
Представляется, что дело не в том, насколько трудно освоить профессию БА (срежем углы и примем гипотезу, что это действительно просто). Ассенизатором тоже, предположу, несложно стать. Проблема в соотношении спроса и квалифицированного предложения. Белые воротнички, имеющие достаточно софтов и абстрактного мышления - зачем они, собственно, пойдут на низкооплачиваемую должность? В мире есть миллион стезей для таких людей: мелкий бизнес, менеджмент, финансовый гешефт, значительная часть преподавания очевидных умений, в конце концов - мошенники той или иной степени легальности.
Ну и сколько остаётся достаточно способных людей на такую странную должность, как БА? Вот именно отношение их количества к количеству позиций и даёт в итоге и зарплаты для топовых специалистов, и средний уровень остальных. Из порога вхождения тут надо вычитать порог вхождения в другие отрасли деятельности.
А вот для программистов тут дело хуже - умение упаковывать килобайты, сочинять апи и проектировать микросервисы востребовано только здесь, его в театре, вузе или на площади не монетизируешь. Короче, прямое сравнение трудозатрат на обучение и востребованности тут не работает.
Ну если не продаётся, то это нельзя купить? Это ведь нормально? Откуда эта мысль, что всё можно купить или получить? Да, есть вещи, которые нельзя купить, это нормально. Это не значит, что их можно хватать самовольно. И убытки тут ни при чём. Отсутствие убытков ещё не признак того, что использование краденого не является использованием краденого.
Проезд зайцем тоже ничего не стоит метрополитену (с точностью да погрешности измерения), но является нарушением.
Для того, чтобы при тестировании связки не закладываться на функциональность каждого мелкого компонента, вроде бы тыщу лет назад и придумали интерфейсы и DI?
В результате функционал одного и того же компонента не покрывается многократно, потому что в тестах связки участвует не сам этот объект, а его мок.
Я не понимаю механику развала проекта, если пул-реквесты отвергаются без брани. Изменения не попали в код, пояснения даны, что произошло бы ужасного, если бы это просто сопровождалось словами "отвергаю по двум причинам: у этой функции такие-то пороки, а также нарушен срок подачи пр-ов"
Каким образом после этих слов развалится проект ядра линукса, не очень понятно
Нельзя прийти, к примеру, в гостиницу, и сказать: слушайте, у вас всё равно эти номера пустуют, я тут незаметно поживу бесплатно. Вы же ничего не потеряете!
Или подойти к гиду, который ведёт экскурсию, и сказать: ну мы тут рядом постоим послушаем, с вас не убудет, платить не будем, продолжайте, пожалуйста.
Да даже элементарный заяц в метро не может оправдаться тем, что он для поезда и инфраструктуры ничтожная нагрузка и фактически метро ничего не потеряет, провезя его бесплатно.
Разумеется, для нематериальных товаров физический переход от владельца к потребителю не происходит, и это очень легко эксплуатировать в свою пользу. Просто из этого не следует, что неоплаченное потребление нематериальных товаров чем-то отличается от неоплаченного потребления материальных товаров. А уж назвать это воровством или ровостмом, дело десятое.
Как только выяснится, что для вычисления рейтинга необходимо передать ещё один какой-нибудь параметр/зависимость, а выяснится это на этапе реализации алгоритма вычисления рейтинга, придётся бежать по всем тестам и править вызовы. А там уже и ещё какие-то новости в сигнатурах всплывут.
Чего принципиально не хватает в постановке задачи "написать программу, выигрывающую в шахматы"?
Принципиально то, что я не знаю хороших практик решения этой задачи, я никогда этим не занимался. Понятно, что надо как-то в глубину просчитывать ветви ходов и оценивать полученные позиции. Так ли это, может я что-то упускаю? Как отсекать? Как оценивать? Возможно, для оценки нужны ещё какие-то вспомогательные абстракции? Может быть, есть ещё какие-то стадии решения? Всего этого я не знаю. Нужна постановка задачи от эксперта.
И такая постановка позволит лучше декомпозировать решение. В том числе и в ООП-парадигме, почему нет.
А если предположить, что наш шахматный движок имеет какую-то степень абстракции и позволит дёшево реализовывать другие игры со схожим флоу, то ООП станет основной практикой. Реализовал, грубо говоря, интерфейс "правила игры" и "оценка позиции" для шашек - и ура, пользуйся, все эти доски и алгоритмы принятия решения будут автоматически переиспользованы.
Короче, ничего ужасного в уместном применении ООП нет. Если с ума не сходить.
Я ничего не знаю про программирование шахмат, так что дальше вольная фантазия. Очевидно, там существуют уже устоявшиеся методики, которые не сочинить в рамках сочинения случайного комментария на хабре
Но нет ничего невероятного, то в шахматах, написанных с использованием ООП, будут:
примитивный класс хранения состояния игры (доска), просто сохраняет инварианты, к примеру, не позволяет поставить две фигуры на одну клетку.
наверное, при реализации логики понадобится возможность итерироваться по дереву возможных вариантов ходов. Это удобно реализовать в виде класса, ведь это же просто контейнер, дерево положений доски со своими инвариантами. И, возможно, с какими-то дополнительными промежуточными данными, которые можно привязать к узлам.
Наверняка есть какие-то вспомогательные абстракции - например, оценка позиции. И наверняка их методики бывают разные, и у них есть состояние (например, кэш предыдущих рассуждений), поэтому они кандидаты на общий интерфейс и реализация в классах.
и, допустим, самый корневой класс, принимающий решение за игрока, строящий логику выбора следующего хода. Он через DI принимает предыдущие.
ну и так далее, нужна постановка задачи, это всё вольная фантазия, дело не в моих выдумках, а в том...
А в том, что вы сами выдумали себе какой-то свой ужасный ООП, в котором программисты моделируют не объекты предметной области, а объекты материального мира: класс для доски, потом класс для клетки, для белого и чёрного цвета, для пешек и ладей - и теперь с этим успешно боретесь.
Но так никто не делает, вы боретесь с демонами в своей голове. Классы для фигур не нужны. А для абстракций, участвующих в принятии решений - вполне могут оказаться полезны.
Как пример для статьи про ООП на хабре? Почему, собственно, нет? Речь не идёт про промышленную универсальную реализацию, вы даже не знаете, какие требования будут к такой очереди, но уже лезете в бутылку. Вполне можно навертеть ООП-абстракций для примера, начиная от иерархии самих типов сообщений и заканчивая какими-нибудь, я не знаю, подписчиками. Это иллюстративный материал для статьи, он не обязан летать на утюгах.
Ах да, я вспомнил, вы тот самый любитель общественного внимания, который обращается к собеседнику "тупой дегенерат", когда его самого макают в, назовём это так, чрезмерную широту обобщений на фоне ограниченнго кругозора. Тогда вопросов не имею.
Мы пишем класс (и прочими способами упрощаем поддержку кода), потому что писатель кода и читатель могут различаться, да (это может быть и один человек, но в разное время). Это действительно причина
Код, в котором никому никогда не надо будет разбираться и поддерживать, всё равно, в какой парадигме писать
Семантика владения и прочие детали важны при написании кода (и то в большинстве случаев компилятор не даст ошибиться).
Но код читается кратно больше, чем пишется. И когнитивная нагрузка - это про чтение, а не про написание. Здесь алиасы работают, как хорошее именование переменных и даже как конструирование типов - упрощает код.
Да можно хоть обпризнаваться, можно лоб разбить в монастыре от покаяния, но если в промышленной разработке на любом уровне бас фактор равен единице, то проблема не в самом распрекрасном суперстаре, как бы он ни был готов принимать на себя горы ответственности, а именно в процессе. Т.е. в менеджменте.
"А Basho взяли и разорились" - это не факап, а естественный риск, заложенный в саму природу принятия такого рода решений. Он сыграл, бывает.
Но, допустим, проблема бы была не конкретно в разорении вендора (называть его разорение собственным факапом это кокетство), а произошла бы действителньо ошибка ведущего специалиста, ошибка инженерного плана, выбрали неподходящее 3рд-пати решение, что это означает?
Судя по вашему "смог убедить" - решение принимал не один человек, а некий синклит (и это правильно). А значит, проблема была бы не в одном человеке, а в том, что его предложение неверно рассматривалось. Допустим, вместо полноценного ревью его предложений, с вниканием и собственным исследованием, просто послушали, махнули рукой и согласились. Ну так это опять-таки ошибка не разработчика, а организации процесса. Ч. и т.д.
Если ошибка разработчика становится проблемой для бизнеса - это не ошибка разработчика.
Не может.
Если от факапов разработчика может пострадать весь бизнес, значит, неправильно поставлены планирование и тестирование. И, возможно, найм.
Если от факапа разработчика внезапно пострадал весь бизнес, то это факап не разработчика, а его менеджмента (лида, инжиниринг-менеджера или кого бы то ни было)
Эмм... А что такого специфически русского в слове "тренер"? Чем он, собственно, лучше коуча? То же самое происхождение, только попривычнее.
Так о том и речь, что нужность слова определяет практика применения, а не этимология.
Это так не работает. Недостаточно просто быть умным джуном.
Знания получаются разными путями, в том числе активным и пассивным. Когда вы читаете на новом языке, вы не учитесь на нём говорить, даже если вы читаете очень много - это просто разные навыки. Потому что когда вы читаете, вам не надо принимать решения (выбор правильных выражений), и при чтении навык этого принятия решения не вырабатывается, вырабатывается другой навык. Вот и получается - человек нормально читает, а сказать ни бэ ни мэ.
Если джун не будет принимать большое, очень большое количество правильных и неправильных решений на мелком уровне (из чего и складывается кодирование), ему будет трудно прогрессировать. Есть, конечно, всякие гении, но вайбкодинг попросту отнимает у среднестатистического джуна опыт, и далеко не всякий ум может скомпенсировать отсутствие опыта.
Это немножко неочевидно для технического ресурса, на котором пасутся инженеры (от которых ожидается, что они ориентированы на конструктивное и результативное общение), но знаете что.
Смысл реплик этого персонажа не в том, чтобы кого-то переубедить или даже просто высказать какую-то точку зрения. Смысл его реплик - произвести дискуссию и тем самым создать впечатление, что по теме есть разные точки зрения. Если беседа зайдёт не о том, хорошо ли или плохо этих самых детей лишать развивающих платформ, а, например, о том, хорош ли кушать этих детей с соусом на завтрак - он, поверьте, найдёт аргументы в пользу их поедания. Его цель - сделать длинную ветку комментариев.
Сделать с этим с помощью полемики ничего нельзя. Только с помощью явной или косвенной модерации. А если дискутировать, отвечать - они только рады (натурально они - в каждой репрессивной теме есть не-всё-так-однозначники с полутора десятками комментариев)
Очень познавательно. Хотя, разумеется, вполне себе существует более римская, чем надпись над воротами Колизея, нотация: это нотация, которой пользуется девяносто девять и девять процентов населения планеты и называет её "римской". Потому что значение слова, даже слова "римская", определяют не энциклопедии и не учебники, а словоупотребление. Но вопрос не в этом.
Скажите, а если не включать вот эту истерическую и отчасти оскорбительную клоунаду с "вы издеваетесь", "кащенко" и прочими элоквенционными экзерсисами, а просто сообщить любознательной публике, что нормализованная в современном мире римская система имела несколько другую форму в древности, то кто от этого пострадает? Почему бы не прийти к уважительному диалогу с публикой? Ну, возможно, будет чуть меньше плюсиков и минусиков, но, поверьте, оно того стоит.
Если водолаз в полном снаряжении по своей глупости залезет на подъёмный кран, упадёт с него и разобъётся, вы, возможно, скажете: "вот они, эти кислородные баллоны, совершенно не нужны". Приблизительно так выглядит ваша претензия.
Проблема вообще не в unwrap. Мало ли, может чуваку жена устроила скандал тем утром, и он забыл убрать, бывает.
Проблема в том, что существуют принципиальные ограничения на размер конфига, но теста на непрохождение этого ограничения, как оказалось, нет.
Т.е. это не вопрос языка и не вопрос ошибки программиста, это вопрос процесса разработки и технологической дисциплины. А вот тут уже вопросы не к одной строчке кода, а к инжиниринг-менеджерам клаудфлейра, ответственным за команду.
Вы немножко мерилом работы считаете усталость.
Представляется, что дело не в том, насколько трудно освоить профессию БА (срежем углы и примем гипотезу, что это действительно просто). Ассенизатором тоже, предположу, несложно стать. Проблема в соотношении спроса и квалифицированного предложения. Белые воротнички, имеющие достаточно софтов и абстрактного мышления - зачем они, собственно, пойдут на низкооплачиваемую должность? В мире есть миллион стезей для таких людей: мелкий бизнес, менеджмент, финансовый гешефт, значительная часть преподавания очевидных умений, в конце концов - мошенники той или иной степени легальности.
Ну и сколько остаётся достаточно способных людей на такую странную должность, как БА? Вот именно отношение их количества к количеству позиций и даёт в итоге и зарплаты для топовых специалистов, и средний уровень остальных. Из порога вхождения тут надо вычитать порог вхождения в другие отрасли деятельности.
А вот для программистов тут дело хуже - умение упаковывать килобайты, сочинять апи и проектировать микросервисы востребовано только здесь, его в театре, вузе или на площади не монетизируешь. Короче, прямое сравнение трудозатрат на обучение и востребованности тут не работает.
Ну если не продаётся, то это нельзя купить? Это ведь нормально? Откуда эта мысль, что всё можно купить или получить? Да, есть вещи, которые нельзя купить, это нормально. Это не значит, что их можно хватать самовольно. И убытки тут ни при чём. Отсутствие убытков ещё не признак того, что использование краденого не является использованием краденого.
Проезд зайцем тоже ничего не стоит метрополитену (с точностью да погрешности измерения), но является нарушением.
Для того, чтобы при тестировании связки не закладываться на функциональность каждого мелкого компонента, вроде бы тыщу лет назад и придумали интерфейсы и DI?
В результате функционал одного и того же компонента не покрывается многократно, потому что в тестах связки участвует не сам этот объект, а его мок.
Я не понимаю механику развала проекта, если пул-реквесты отвергаются без брани. Изменения не попали в код, пояснения даны, что произошло бы ужасного, если бы это просто сопровождалось словами "отвергаю по двум причинам: у этой функции такие-то пороки, а также нарушен срок подачи пр-ов"
Каким образом после этих слов развалится проект ядра линукса, не очень понятно
Да хоть горшком назови.
Нельзя прийти, к примеру, в гостиницу, и сказать: слушайте, у вас всё равно эти номера пустуют, я тут незаметно поживу бесплатно. Вы же ничего не потеряете!
Или подойти к гиду, который ведёт экскурсию, и сказать: ну мы тут рядом постоим послушаем, с вас не убудет, платить не будем, продолжайте, пожалуйста.
Да даже элементарный заяц в метро не может оправдаться тем, что он для поезда и инфраструктуры ничтожная нагрузка и фактически метро ничего не потеряет, провезя его бесплатно.
Разумеется, для нематериальных товаров физический переход от владельца к потребителю не происходит, и это очень легко эксплуатировать в свою пользу. Просто из этого не следует, что неоплаченное потребление нематериальных товаров чем-то отличается от неоплаченного потребления материальных товаров. А уж назвать это воровством или ровостмом, дело десятое.
Как только выяснится, что для вычисления рейтинга необходимо передать ещё один какой-нибудь параметр/зависимость, а выяснится это на этапе реализации алгоритма вычисления рейтинга, придётся бежать по всем тестам и править вызовы. А там уже и ещё какие-то новости в сигнатурах всплывут.
Принципиально то, что я не знаю хороших практик решения этой задачи, я никогда этим не занимался. Понятно, что надо как-то в глубину просчитывать ветви ходов и оценивать полученные позиции. Так ли это, может я что-то упускаю? Как отсекать? Как оценивать? Возможно, для оценки нужны ещё какие-то вспомогательные абстракции? Может быть, есть ещё какие-то стадии решения? Всего этого я не знаю. Нужна постановка задачи от эксперта.
И такая постановка позволит лучше декомпозировать решение. В том числе и в ООП-парадигме, почему нет.
А если предположить, что наш шахматный движок имеет какую-то степень абстракции и позволит дёшево реализовывать другие игры со схожим флоу, то ООП станет основной практикой. Реализовал, грубо говоря, интерфейс "правила игры" и "оценка позиции" для шашек - и ура, пользуйся, все эти доски и алгоритмы принятия решения будут автоматически переиспользованы.
Короче, ничего ужасного в уместном применении ООП нет. Если с ума не сходить.
Я ничего не знаю про программирование шахмат, так что дальше вольная фантазия. Очевидно, там существуют уже устоявшиеся методики, которые не сочинить в рамках сочинения случайного комментария на хабре
Но нет ничего невероятного, то в шахматах, написанных с использованием ООП, будут:
примитивный класс хранения состояния игры (доска), просто сохраняет инварианты, к примеру, не позволяет поставить две фигуры на одну клетку.
наверное, при реализации логики понадобится возможность итерироваться по дереву возможных вариантов ходов. Это удобно реализовать в виде класса, ведь это же просто контейнер, дерево положений доски со своими инвариантами. И, возможно, с какими-то дополнительными промежуточными данными, которые можно привязать к узлам.
Наверняка есть какие-то вспомогательные абстракции - например, оценка позиции. И наверняка их методики бывают разные, и у них есть состояние (например, кэш предыдущих рассуждений), поэтому они кандидаты на общий интерфейс и реализация в классах.
и, допустим, самый корневой класс, принимающий решение за игрока, строящий логику выбора следующего хода. Он через DI принимает предыдущие.
ну и так далее, нужна постановка задачи, это всё вольная фантазия, дело не в моих выдумках, а в том...
А в том, что вы сами выдумали себе какой-то свой ужасный ООП, в котором программисты моделируют не объекты предметной области, а объекты материального мира: класс для доски, потом класс для клетки, для белого и чёрного цвета, для пешек и ладей - и теперь с этим успешно боретесь.
Но так никто не делает, вы боретесь с демонами в своей голове. Классы для фигур не нужны. А для абстракций, участвующих в принятии решений - вполне могут оказаться полезны.
Как пример для статьи про ООП на хабре? Почему, собственно, нет? Речь не идёт про промышленную универсальную реализацию, вы даже не знаете, какие требования будут к такой очереди, но уже лезете в бутылку. Вполне можно навертеть ООП-абстракций для примера, начиная от иерархии самих типов сообщений и заканчивая какими-нибудь, я не знаю, подписчиками. Это иллюстративный материал для статьи, он не обязан летать на утюгах.
Ах да, я вспомнил, вы тот самый любитель общественного внимания, который обращается к собеседнику "тупой дегенерат", когда его самого макают в, назовём это так, чрезмерную широту обобщений на фоне ограниченнго кругозора.
Тогда вопросов не имею.
Мы пишем класс (и прочими способами упрощаем поддержку кода), потому что писатель кода и читатель могут различаться, да (это может быть и один человек, но в разное время). Это действительно причина
Код, в котором никому никогда не надо будет разбираться и поддерживать, всё равно, в какой парадигме писать
Эвона чо
Семантика владения и прочие детали важны при написании кода (и то в большинстве случаев компилятор не даст ошибиться).
Но код читается кратно больше, чем пишется. И когнитивная нагрузка - это про чтение, а не про написание. Здесь алиасы работают, как хорошее именование переменных и даже как конструирование типов - упрощает код.