Приводит отвратный react код, где не используется кэширование а есть загрузка из useEffect (говнокод), потом вместо мемоизации вычислений с помощью мемоизирующих селекторов или хотя бы синхронного useMemo вычисляет данные в другом useEffect (нереальный говнокод), а потом рассказывает какой реакт плохой.
Ради интереса спросил GPT что делать в подобных ситуациях, тупо копировал текст проблемы из статьи, дав контекст чтобы он представил себя крутым софтовым менеджером - и он предлагал ровно то же самое, и даже больше, но что самое удивительное - читать было интереснее, ничего лишнего. Не выглядело как бахвальство.
И я не про то, что статья плохая или написана GPT. Вряд ли. Но это забавно, ведь у него нет ни эмоционального интеллекта, ни других перечисленных в статье качеств.
При этом код до сих пор писать может нормально только типовой. Забавно.
PS. По личному опыту, менеджер без очень серьезных технических навыков - это печальное зрелище. Не знаю насчет автора статьи, но фразы типа рок стар, дрим тим и тп у таких часто вообще ничего общего с реальностью не имеют.
Способность решать конфликты и спорные ситуации очень сильно зависит от способности разбираться в технических нюансах, с этим даже у бывших разработчиков с большим опытом часто проблемы бывают, а человек без тех скилов вообще как ежик в тумане. И привет несправедливость и отрицательный отбор. Признавать заслуги - реальные, а не кажущиеся, раздутые - тоже исключительно технический вопрос.
Абсолютно точно выберу супер скилового руководителя против кого угодно, по своему опыту. Это показатель в том числе и интеллекта, и следовательно адекватности. А поговорить если что то не устраивает я и сам могу.
Вот хороший пример того, как стоит использовать StyleSheet.create
Это как раз плохой пример использования StyleSheet.create, так как стили будут создаваться либо на каждый рендер, либо с useMemo на каждое монтирование каждого элемента. То есть если в списке 500 ячеек, то 500 раз.
В своей статье я писал, как правильно работать со стилями для лучшей производительности.
То есть у вас в каждом классе только один метод? Так это и есть ФП, поздравляю. Нужно посто выкинуть лишнюю сущность классов и оставить просто функцию.
А если серьезно, то даже по меркам ООП ваш код плох. Почему то класс называется робопес, в нем лежит мозг обезьяны, а что тогда у обезьяны? Копипаста? Почему то есть класс колес, а что тогда у телеги? Почему то FlyingSystem тоже в робопсе лежит, а как тогда самолет летает? Про полиморфизм кряканья я вообще молчу - его тупо нет.
Дальше - лучше:
Стажер ООП <- вы находитесь здесь, но любите поспорить.
Про влияние - я так понимаю проигнорирован возможно один из самых важных моментов про выгорание и текучку кадров, причем в основном самых квалифицированных кадров.
И даже в пункте про Developer efficiency про это ни слова, хотя далее в статье на графике на третьем месте "снижение мотивации".
Целью внедрения ООП в ядро Linux было бы улучшение модульности, инкапсуляции и повторного использования кода, что упростило бы сопровождение и разработку.
Автор статьи не понимает ни того, что имел ввиду Линус, ни самой концепции ООП на классах.
Чтобы понять, почему модульность и повторное использование с классами становятся только хуже, советую почитать статью https://habr.com/ru/articles/885980/.
Кто знает, что будет дальше: Go, C# или даже Java
Запрет С++ но разрешить Java и C#, это по мнению автора логичное предположение.. мне кажется это уже диагноз.
Трекинг, если без программ слежения за курсором и привязки к зп, в целом вещь хорошая для работодателя, но так как так делают далеко не все, то нужно платить выше рынка за доп. стресс. И учитывать, что текучка увеличится.
С программами слежения - сильно выше рынка, чтобы предотвратить сильную текучку, и сотрудники будут выгорать от сильного стресса. Мало кто из крутых специалистов согласится даже за большую зп.
Учитывая это, имеет смысл 10 раз подумать, перед тем как что то подобное вводить - может дейли с компетентным менеджером вполне хватит.
Всерьез о правильности реализации enum в TypeScript
Я ни разу не утверждал то, что в TS именно реализация идеальная - речь про синтаксис и встроенные возможности, без необходимости костылей. Переводите тему - чувствуете слабую позицию.
В качестве эксперимента попробуйте создать в TypeScript enum такой же как Message
В TypeScript и это сделано куда лучше - через Union Type. И будет выглядеть так:
Во-первых, эту новость писал не сотрудник амазон в их блоге, и она может быть выдумана от и до.
Во-вторых, там нет речи про то, что сотрудник без опыта, опыт то у него есть.
Решил одну проблему, заменив С на С++.
Теперь у тебя 1000 проблем.
Статья от крайне некомпетентного разработчика.
Приводит отвратный react код, где не используется кэширование а есть загрузка из useEffect (говнокод), потом вместо мемоизации вычислений с помощью мемоизирующих селекторов или хотя бы синхронного useMemo вычисляет данные в другом useEffect (нереальный говнокод), а потом рассказывает какой реакт плохой.
Джавист, одним словом.
Ради интереса спросил GPT что делать в подобных ситуациях, тупо копировал текст проблемы из статьи, дав контекст чтобы он представил себя крутым софтовым менеджером - и он предлагал ровно то же самое, и даже больше, но что самое удивительное - читать было интереснее, ничего лишнего. Не выглядело как бахвальство.
И я не про то, что статья плохая или написана GPT. Вряд ли. Но это забавно, ведь у него нет ни эмоционального интеллекта, ни других перечисленных в статье качеств.
При этом код до сих пор писать может нормально только типовой. Забавно.
PS. По личному опыту, менеджер без очень серьезных технических навыков - это печальное зрелище. Не знаю насчет автора статьи, но фразы типа рок стар, дрим тим и тп у таких часто вообще ничего общего с реальностью не имеют.
Способность решать конфликты и спорные ситуации очень сильно зависит от способности разбираться в технических нюансах, с этим даже у бывших разработчиков с большим опытом часто проблемы бывают, а человек без тех скилов вообще как ежик в тумане. И привет несправедливость и отрицательный отбор. Признавать заслуги - реальные, а не кажущиеся, раздутые - тоже исключительно технический вопрос.
Абсолютно точно выберу супер скилового руководителя против кого угодно, по своему опыту. Это показатель в том числе и интеллекта, и следовательно адекватности. А поговорить если что то не устраивает я и сам могу.
Использование потокобезопасных коллекций - антипаттерн.
Объяснил кратко в конце статьи https://habr.com/ru/articles/803273/
Это как раз плохой пример использования
StyleSheet.create, так как стили будут создаваться либо на каждый рендер, либо сuseMemoна каждое монтирование каждого элемента. То есть если в списке 500 ячеек, то 500 раз.В своей статье я писал, как правильно работать со стилями для лучшей производительности.
Осталось параллельность JS завезти в RN эффективную, и была бы вообще сказка.
Очередной типичный спор с ООП-шником.
То есть у вас в каждом классе только один метод? Так это и есть ФП, поздравляю. Нужно посто выкинуть лишнюю сущность классов и оставить просто функцию.
А если серьезно, то даже по меркам ООП ваш код плох. Почему то класс называется робопес, в нем лежит мозг обезьяны, а что тогда у обезьяны? Копипаста? Почему то есть класс колес, а что тогда у телеги? Почему то FlyingSystem тоже в робопсе лежит, а как тогда самолет летает? Про полиморфизм кряканья я вообще молчу - его тупо нет.
Дальше - лучше:
Стажер ООП <- вы находитесь здесь, но любите поспорить.
Джун ООП
Мидл ООП
Сеньор ООП
Хороший программист
Отличный программист
Ответил всем кроме самого упоротого, пока что примеров где лучше ООП - нуль.
{…data} это поверхностное копирование, и structured clone разумеется медленнее.
190 уже неотличимо.
Так я же говорю, я на деньги готов поспорить, 30к рублей запросто.
Я сам скачаю и сконвертирую выбранный лосслес трек в мп3, поставлю софт для слепого сравнения (foobar), вы должны будете отличить треки.
Только вот что то никто дальше слов не готов идти (оно и понятно).
Анекдот: решил как то старый армянин самый лучший процессор сделать, но денег не было. Видит - русские идут..
Материал - любой реальный трек в lossless формате из музыкальных онлайн платформ. Любое железо. Спб. Можно и звать )
Не 95% а 100%. Готов поспорить на деньги с кем угодно.
Автор, судя по всему, не работал на долгих проектах. И уж тем более не работал на хорошо написанных долгих проектах.
А что такое простой код в принципе не понимает.
Но голосовалка явно показывает контингент хабра.
Про влияние - я так понимаю проигнорирован возможно один из самых важных моментов про выгорание и текучку кадров, причем в основном самых квалифицированных кадров.
И даже в пункте про Developer efficiency про это ни слова, хотя далее в статье на графике на третьем месте "снижение мотивации".
Автор статьи не понимает ни того, что имел ввиду Линус, ни самой концепции ООП на классах.
Чтобы понять, почему модульность и повторное использование с классами становятся только хуже, советую почитать статью https://habr.com/ru/articles/885980/.
Запрет С++ но разрешить Java и C#, это по мнению автора логичное предположение.. мне кажется это уже диагноз.
Трекинг, если без программ слежения за курсором и привязки к зп, в целом вещь хорошая для работодателя, но так как так делают далеко не все, то нужно платить выше рынка за доп. стресс. И учитывать, что текучка увеличится.
С программами слежения - сильно выше рынка, чтобы предотвратить сильную текучку, и сотрудники будут выгорать от сильного стресса. Мало кто из крутых специалистов согласится даже за большую зп.
Учитывая это, имеет смысл 10 раз подумать, перед тем как что то подобное вводить - может дейли с компетентным менеджером вполне хватит.
Я ни разу не утверждал то, что в TS именно реализация идеальная - речь про синтаксис и встроенные возможности, без необходимости костылей. Переводите тему - чувствуете слабую позицию.
В TypeScript и это сделано куда лучше - через Union Type. И будет выглядеть так:
И можно спокойно объединять уже имеющиеся типы без создания дурацких енумов.
Опять, уходите от темы про непродуманность, предлагая спор про совсем другое.
Я пожалуй удаляюсь. Позицию высказал довольно четко в прошлых сообщениях.