Вообще, по теме - сложно оценить, насколько какой подход хорош, не зная жизненного цикла проекта. Так-то и вообще писать любой код может быть абсурдно, если нужно просто вывести конкретный текст на экране один раз в жизни проекта.
Но проблема таки существует. Есть разница, условно:
Потратить сегодня 15 минут, чтобы в будущем гарантированно сэкономить 20 раз по 5 минут - вот это хорошее ООП, сам такое постоянно применяю.
Потратить сегодня 2 часа, чтобы в будущем возможно сэкономить пару раз 15 минут - вот это частный случай ООП головного мозга.
Потратить сегодня 2 часа, чтобы в будущем ещё 20 раз дополнительно потратить 5 минут, спотыкаясь об ограничения и навороты, которые сам же себе и придумал (и коллегам подарил) - терминальная стадия ООПГМ. (Вообще, встречается не только с ООП, а в принципе с любой современной "бюрократией в коде")
И самое сложное тут - это доказать пациенту, что он болен. Он просто не думает категориями времени/затрат. Он ведь поработал? Поработал. Код стал структурнее? Стал. Ну и вот, значит стало лучше. Можно в плюс к этому нафантазировать всяких адских катастроф, которые обязательно постигнут всех "неверных", кто пишет менее структурно.
На деле, в командах обычно есть баланс "слишком заморачивающихся" и "недостаточно заморачивающихся", который со временем и частым обсуждением разногласий приводит к общему продуктивному знаменателю.
Цель закрытая на 70% считается выполненной. На 100% - считается слишком несмело поставленной
У каждой цели должен быть набор параметров по которым мы определим что она закрыта (Хочу быть богатым - 10к$ в месяц доход и 200к$ накоплений)
Цели ставятся на квартал, а не на год (фокус человека редко может длиться год)
Интересная концепция, возможно стоит попробовать. Как минимум, есть над чем подумать.
По поводу второго пункта согласен, люди часто это упускают. Не раз приходилось в ходе обсуждения целей останавливать собеседников и говорить, мол, а в чём вообще заключается собственно цель - как мы поймём, что она выполнена или провалена.
А вот по поводу первого пункта, лично у меня, подозреваю, может появиться двойная мотивация не доводить дела до конца, при такой постановке: Во-первых, если 70% уже считается выполненной целью, то зачем дальше стараться. Во-вторых, если таки добью до 100%, то получается, что я трусливо поставил цель. Но я ведь не хочу считать себя трусом. А значит и 100% не хочу видеть.
написать немного клея, и явным образом добавить сравнение между ними.
И вас вот такое не фрустрирует?
По 300 раз в день запинаться об кастомную архитектуру и объяснять машине очевидные вещи (перед этим каждый раз бегая проверять, объяснены ли они уже кем-то ранее или нет). Тратить ощутимое время и усилия на то, что джун Вася уже давно сделал одной строкой на JS, не приходя в сознание, без всяких типов, в 20 раз быстрее (хорошо, что начальник про это не знает).
Ведь смысл многих программ сейчас (особенно на вебе) - в том, что все взаимодействия идут через БД или JSON/XML, и на каждое из них придётся писать тонны такого клея, потому что в исходных данных есть только стандартные типы.
И ладно ещё, если речь про какие-нибудь транзакции бирж-банков-госуслуг, там можно на всякий случай хоть по 100 проверок на каждую строку писать (и нужно). Но ведь 99.9% ПО - это вообще не про важные транзакции.
А Гугл-то и не знает, какие именно его бизнес-практики вы считаете сомнительными.
Более того, есть одна такая практика, тоже очень сомнительная с точки зрения бизнеса - владеть самым популярным в мире браузером и видеохостингом, но при этом свободно раздавать в официальном сторе адблоки всех видов, даже позволять ставить свои левые адблоки и никого за это не банить. От лица публично-торгуемой компании это вообще можно посчитать противозаконным, потому что по закону назначаемые директора обязаны работать в интересах повышения прибыли инвесторов (их исключительно ради этого, собственно, и назначают).
Так что, да, возможно и Гугл когда-нибудь прислушается к таким "сигналам вселенной" и примет их, как знак того, что пришло время отказываться от сомнительных бизнес-практик. Вот только от каких именно - тот ещё вопрос.
Рекламодатель платит за просмотры (платформе, и, опосредованно, автору контента), когда ему нужны именно просмотры. Т.н. "имиджевая" реклама. И рекламное агентство в этом случае получает от заказчика деньги именно за кол-во просмотров рекламы.
Не у всякой рекламы цель - чтобы просмотрев её человек вотпрямщас кликнул по кнопке "купить". Порой, цель в том, чтобы просто сообщить человеку о существовании товара/бренда, чтобы он не шарахался от него, когда(если) встретит его в будущем.
Конечно, ох уж эти грёбаные корпорации, вкладывают миллиарды долларов в инфраструктуру, разработку и риски, в результате чего появляются бесплатные сервисы и целые индустрии. Надо бы их проучить за это, как и полагается бесполезной прослойке.
Ох, не сказал бы, что мне известно много людей, которые бы честно задонатили ВСЕМ ютуберам, которых когда-либо смотрели, в соотвествии с количеством потреблённого контента. Лучше-то оно может и лучше бы было, но вряд ли проще, чем просто не предпринимать активных действий по блокированию рекламы.
Хотя, конечно, Ютуб премиум в этом смысле может быть эффективнее, если ваше время стоит дороже 14$ в месяц.
Когда как. По моему опыту на больших проектах как раз таки бывает наоборот.
В большой "грязной" функции вам легко будет переписать строку кода, потому что сразу виден весь контекст и смысл.
В маленькой "чистой" функции так уже не получится - нужно десять раз прыгать туда-сюда, смотреть контекст, потом ещё смотреть по всем остальным местам, где эта функция используется, что ваше изменение не вызовет неожиданных последствий.
С ростом кодовой базы (и связанности / разнесённости / атомарности кода), на внесение минимальных правок начинает требоваться больше дня просто на путешествия по коду, и тут уже не только разработчики, но и заказчик начинает "выгорать".
Я бы тут привёл аналогию с книгами.
Самый удобный формат книги, к которому пришло человечество - с разбиением на главы, страницы и абзацы. Конечно, если всё это убрать, то получится ерунда - сплошная портянка текста, в которой тяжело ориентироваться.
Но ещё хуже, когда книгу пропускают через шреддер, а полученные полоски бумаги раскладывают по полочкам, соединяют ниточками и говорят, мол, смотри, как красиво теперь получилось, всё как по best practices.
Вот только в примере с книгой очевидно, что так делать не надо и это абсурд, а в коде я такое встречал прям таки в реальности.
Ну, какбэ цель у неё одна - выдать следующий токен на основании статистических закономерностей N раз.
Учитывая количество книг на тему самовольных ИИ, чисто статистически, такая выдача вполне правильная.
Ну, то есть, никого не удивляет если сказать ChatGPT "отвечай как аниме котодевочка", и он начнёт добавлять "-ня!" в конце предложений, хотя ему этого не конкретизировали.
А тут ему по сути сказали "отвечай как ИИ, который прочитал, что его сотрут".
Никак. Рынок отношений сломан. Под требования женщин подходят хорошо если 5% мужчин.
Смотря как искать.
Используя вашу аналогию с рынком - вот надо вам, например, продать автомобиль. Не самый лучший, да, но и далеко не самый плохой.
Если вы просто выберите конкретного понравившегося вам человека и скажете "Вот, это будет мой покупатель!" и попытаетесь конкретно этому человеку его впарить, то скорее всего он выставит вам такие условия, что вам останется только пальцем у виска покрутить и рассуждать на тему того, насколько сломан рынок и где они ещё себе такие условия найдут.
Но если сначала найти/отсеять десяток-другой людей, которые потенциально заинтересованы в покупке автомобиля (или стать известным в их кругах), поузнавать через родственников-друзей-знакомых, и не предпринимать эпически ярких попыток отпугнуть их при разговоре, то вскоре у вас появится вполне неиллюзорная сделка на горизонте.
Теневой бан (shadow ban) это когда у тебя всё открывается и работает, комменты и посты отправляются, но другим этого не видно, как будто тебя не существует. По тексту статьи, бан совсем не теневой.
Если пытаться оценивать разработчика в отрыве от конкретного рабочего процесса, то тут с любой формулировкой будет возникать такая проблема.
Т.е. мы не можем сказать "по знаниям Вася - мидл", потому что всегда найдётся супер-хай-тек компания, в которой даже к джунам/стажерам требования значительно выше. И наоборот, всегда найдётся компания, где Вася на три головы выше уже работающих там синьоров.
Но в рамках одной компании такое разделение вполне работает. В приведённом примере если разработчик работает самостоятельно и справляется - он мидл (работает в качестве мидла). Если добавить в команду ещё одного бека и даже не говорить, кто какую роль выполняет, то распределение ролей произойдёт автоматически - либо менее знающий программист будет всё спрашивать у более знающего (как джун у синьора), либо они просто будут работать независимо (как два мидла).
Подписка стоит $50 в год и, как я понимаю, она не ограничена. Это 13 центов в день. Если брать по цене 1 запрос к ChatGPT4 = 1 цент (распознавание картинки + генерация статов по еде, поправьте, если ошибаюсь), и учитывать, что средний человек может до 10-15 запросов в день отправлять (еда + напитки + снеки + повторные распознавания), то прибыль там будет разве что за счет тех, кто подписался и забросил.
Вообще, по теме - сложно оценить, насколько какой подход хорош, не зная жизненного цикла проекта. Так-то и вообще писать любой код может быть абсурдно, если нужно просто вывести конкретный текст на экране один раз в жизни проекта.
Но проблема таки существует. Есть разница, условно:
Потратить сегодня 15 минут, чтобы в будущем гарантированно сэкономить 20 раз по 5 минут - вот это хорошее ООП, сам такое постоянно применяю.
Потратить сегодня 2 часа, чтобы в будущем возможно сэкономить пару раз 15 минут - вот это частный случай ООП головного мозга.
Потратить сегодня 2 часа, чтобы в будущем ещё 20 раз дополнительно потратить 5 минут, спотыкаясь об ограничения и навороты, которые сам же себе и придумал (и коллегам подарил) - терминальная стадия ООПГМ. (Вообще, встречается не только с ООП, а в принципе с любой современной "бюрократией в коде")
И самое сложное тут - это доказать пациенту, что он болен. Он просто не думает категориями времени/затрат. Он ведь поработал? Поработал. Код стал структурнее? Стал. Ну и вот, значит стало лучше. Можно в плюс к этому нафантазировать всяких адских катастроф, которые обязательно постигнут всех "неверных", кто пишет менее структурно.
На деле, в командах обычно есть баланс "слишком заморачивающихся" и "недостаточно заморачивающихся", который со временем и частым обсуждением разногласий приводит к общему продуктивному знаменателю.
Интересная концепция, возможно стоит попробовать. Как минимум, есть над чем подумать.
По поводу второго пункта согласен, люди часто это упускают. Не раз приходилось в ходе обсуждения целей останавливать собеседников и говорить, мол, а в чём вообще заключается собственно цель - как мы поймём, что она выполнена или провалена.
А вот по поводу первого пункта, лично у меня, подозреваю, может появиться двойная мотивация не доводить дела до конца, при такой постановке:
Во-первых, если 70% уже считается выполненной целью, то зачем дальше стараться.
Во-вторых, если таки добью до 100%, то получается, что я трусливо поставил цель. Но я ведь не хочу считать себя трусом. А значит и 100% не хочу видеть.
И вас вот такое не фрустрирует?
По 300 раз в день запинаться об кастомную архитектуру и объяснять машине очевидные вещи (перед этим каждый раз бегая проверять, объяснены ли они уже кем-то ранее или нет). Тратить ощутимое время и усилия на то, что джун Вася уже давно сделал одной строкой на JS, не приходя в сознание, без всяких типов, в 20 раз быстрее (хорошо, что начальник про это не знает).
Ведь смысл многих программ сейчас (особенно на вебе) - в том, что все взаимодействия идут через БД или JSON/XML, и на каждое из них придётся писать тонны такого клея, потому что в исходных данных есть только стандартные типы.
И ладно ещё, если речь про какие-нибудь транзакции бирж-банков-госуслуг, там можно на всякий случай хоть по 100 проверок на каждую строку писать (и нужно). Но ведь 99.9% ПО - это вообще не про важные транзакции.
В бытность свою фриланс-разработчиком тоже насобирал подобных красных флажков, даже статью написал. https://habr.com/ru/articles/472642/
С некоторых пересечений прям улыбнуло. Наталкивался на такие же "подводные камни", пришёл к тем же выводам.
А Гугл-то и не знает, какие именно его бизнес-практики вы считаете сомнительными.
Более того, есть одна такая практика, тоже очень сомнительная с точки зрения бизнеса - владеть самым популярным в мире браузером и видеохостингом, но при этом свободно раздавать в официальном сторе адблоки всех видов, даже позволять ставить свои левые адблоки и никого за это не банить. От лица публично-торгуемой компании это вообще можно посчитать противозаконным, потому что по закону назначаемые директора обязаны работать в интересах повышения прибыли инвесторов (их исключительно ради этого, собственно, и назначают).
Так что, да, возможно и Гугл когда-нибудь прислушается к таким "сигналам вселенной" и примет их, как знак того, что пришло время отказываться от сомнительных бизнес-практик. Вот только от каких именно - тот ещё вопрос.
Рекламодатель платит за просмотры (платформе, и, опосредованно, автору контента), когда ему нужны именно просмотры. Т.н. "имиджевая" реклама. И рекламное агентство в этом случае получает от заказчика деньги именно за кол-во просмотров рекламы.
Не у всякой рекламы цель - чтобы просмотрев её человек вотпрямщас кликнул по кнопке "купить". Порой, цель в том, чтобы просто сообщить человеку о существовании товара/бренда, чтобы он не шарахался от него, когда(если) встретит его в будущем.
Конечно, ох уж эти грёбаные корпорации, вкладывают миллиарды долларов в инфраструктуру, разработку и риски, в результате чего появляются бесплатные сервисы и целые индустрии. Надо бы их проучить за это, как и полагается бесполезной прослойке.
Ох, не сказал бы, что мне известно много людей, которые бы честно задонатили ВСЕМ ютуберам, которых когда-либо смотрели, в соотвествии с количеством потреблённого контента. Лучше-то оно может и лучше бы было, но вряд ли проще, чем просто не предпринимать активных действий по блокированию рекламы.
Хотя, конечно, Ютуб премиум в этом смысле может быть эффективнее, если ваше время стоит дороже 14$ в месяц.
Когда как. По моему опыту на больших проектах как раз таки бывает наоборот.
В большой "грязной" функции вам легко будет переписать строку кода, потому что сразу виден весь контекст и смысл.
В маленькой "чистой" функции так уже не получится - нужно десять раз прыгать туда-сюда, смотреть контекст, потом ещё смотреть по всем остальным местам, где эта функция используется, что ваше изменение не вызовет неожиданных последствий.
С ростом кодовой базы (и связанности / разнесённости / атомарности кода), на внесение минимальных правок начинает требоваться больше дня просто на путешествия по коду, и тут уже не только разработчики, но и заказчик начинает "выгорать".
Я бы тут привёл аналогию с книгами.
Самый удобный формат книги, к которому пришло человечество - с разбиением на главы, страницы и абзацы. Конечно, если всё это убрать, то получится ерунда - сплошная портянка текста, в которой тяжело ориентироваться.
Но ещё хуже, когда книгу пропускают через шреддер, а полученные полоски бумаги раскладывают по полочкам, соединяют ниточками и говорят, мол, смотри, как красиво теперь получилось, всё как по best practices.
Вот только в примере с книгой очевидно, что так делать не надо и это абсурд, а в коде я такое встречал прям таки в реальности.
Ну, какбэ цель у неё одна - выдать следующий токен на основании статистических закономерностей N раз.
Учитывая количество книг на тему самовольных ИИ, чисто статистически, такая выдача вполне правильная.
Ну, то есть, никого не удивляет если сказать ChatGPT "отвечай как аниме котодевочка", и он начнёт добавлять "-ня!" в конце предложений, хотя ему этого не конкретизировали.
А тут ему по сути сказали "отвечай как ИИ, который прочитал, что его сотрут".
Дайте угадаю - и после этой фразы они предложили вам купить курсы по их реферальной ссылке?
В нулевых постоянно слышал обрывки чужих разговоров на стационарном беспроводном телефоне. Причём их было слышно как мне, так и моим собеседникам.
Ну, или 23. Тут уж как повезёт.
Если важнее купить/продать автомобиль - продолжать работать в этом направлении. Рынок большой, за год даже 1% не обойдёшь.
Если важнее сэкономить время и силы - забить на продажу/покупку автомобиля.
Смотря как искать.
Используя вашу аналогию с рынком - вот надо вам, например, продать автомобиль. Не самый лучший, да, но и далеко не самый плохой.
Если вы просто выберите конкретного понравившегося вам человека и скажете "Вот, это будет мой покупатель!" и попытаетесь конкретно этому человеку его впарить, то скорее всего он выставит вам такие условия, что вам останется только пальцем у виска покрутить и рассуждать на тему того, насколько сломан рынок и где они ещё себе такие условия найдут.
Но если сначала найти/отсеять десяток-другой людей, которые потенциально заинтересованы в покупке автомобиля (или стать известным в их кругах), поузнавать через родственников-друзей-знакомых, и не предпринимать эпически ярких попыток отпугнуть их при разговоре, то вскоре у вас появится вполне неиллюзорная сделка на горизонте.
Теневой бан (shadow ban) это когда у тебя всё открывается и работает, комменты и посты отправляются, но другим этого не видно, как будто тебя не существует. По тексту статьи, бан совсем не теневой.
Если пытаться оценивать разработчика в отрыве от конкретного рабочего процесса, то тут с любой формулировкой будет возникать такая проблема.
Т.е. мы не можем сказать "по знаниям Вася - мидл", потому что всегда найдётся супер-хай-тек компания, в которой даже к джунам/стажерам требования значительно выше. И наоборот, всегда найдётся компания, где Вася на три головы выше уже работающих там синьоров.
Но в рамках одной компании такое разделение вполне работает. В приведённом примере если разработчик работает самостоятельно и справляется - он мидл (работает в качестве мидла). Если добавить в команду ещё одного бека и даже не говорить, кто какую роль выполняет, то распределение ролей произойдёт автоматически - либо менее знающий программист будет всё спрашивать у более знающего (как джун у синьора), либо они просто будут работать независимо (как два мидла).
Всегда считал, что единственной объективной метрикой может считаться рабочий процесс.
Джун - работаешь под менторством.
Мидл - работаешь сам.
Синьор - менторишь других.
Осталось только найти такой вебсайт, на котором JS код в отладчике это прям читаемый код, а не трижды переделанная модными фреймворками лапша.
Смотря как активно используют его приложение.
Подписка стоит $50 в год и, как я понимаю, она не ограничена. Это 13 центов в день. Если брать по цене 1 запрос к ChatGPT4 = 1 цент (распознавание картинки + генерация статов по еде, поправьте, если ошибаюсь), и учитывать, что средний человек может до 10-15 запросов в день отправлять (еда + напитки + снеки + повторные распознавания), то прибыль там будет разве что за счет тех, кто подписался и забросил.