У ООП есть свои проблемы это правда, но какая альтернатива? Функциональный подход, который всегда скатывается в файлы с 1000 строк кода несвязанных по логике функций. Лично я не хочу, чтобы программирование скатывалось в условный реакт, потому что код в проектах на нём очень сложно читаем из-за мешанины. По итогу, те же компоненты становятся подобием классов, если грамотно разделять логику.
В общем, ООП сам по себе не плох, просто нужно его "уметь готовить" и не упарываться слишком сильно в реализации.
Например, не использовать паттерны, где надо и не надо. Есть же паттерналистское мышление, когда человек пытается подогнать задачу под паттерн, а не паттерн, под задачу. Вечно искать, какие-то "красивые" решения, которые, по итогу не расширяемые, имеют сильные связи, плюс сам человек, что это написал, не разберётся а своём же коде спустя время.
Если использовать ООП не переусложняя его, то он, не станет головной болью.
А с чего вообще бизнес должен быть справедливым, если сама система координат в которой он находится не справедлива.
Мы живём во время, когда условный блогер, что харизматично несёт бред на камеру, получает больше электрика, работающего с высокопоточкой. Хотя, без его работы, стримерство исчезнет, как профессия.
Так и в бизнесе, даже не беря в расчет иерархию, когда руководство всегда молодцы, а работники всегда крайние и плевать, что без работников не будет и руководства. Даже на одной ступене иерархии может существовать несправедливость. Банальный пример, один работник, пашет 24/7 и тянет команду на себе, когда его коллеги, что пинают болты, получают столько же. Таких примеров можно привести много.
Думаете, сейчас прогоню телегу про равенство, законы, горизонтальную иерархию, коммунизм, где все равны, но кто-то ровнее и прочий сказочный бред?
Нет, просто смиритесь с этим и ищите всеми способами пригретое местечко. Бороться имеет смысл, только за то, чтобы своя жопа в тепле была, а бороться с системой, нормальные люди перестают лет в 16, потому что она тебя перемолет и выплюнет.
Это уже старое веение, сейчас обучают как не только пройти собес при помощи gpt, но и вайбкодить на новом месте без минимальных знаний программирования. 😂
Да, и именно всякие лохобоксы убили it школы и курсы, как таковые. А не прикроют их, потому что они технически свои обязательства выполняют. Блиновская продаёт воздух и ложные обещания, а вот ШП, продают курсы. Да, понятно, что качество курсов оставляет желать лучшего и никакие 300к/наносек после них, ученика не ожидают и близко (если на бесплатную стажировку возьмут уже победа в текущих реалиях). Там много схем, в которых по итогу, оказываешься виновным по закон сам.
Добавим к этому, что большинство ШП владеют не последние люди в правительстве/бизнесе с серьезными связями и поймём, что ШП ещё долго не закроют. Они трансформируются в Алабуги, АИ обучение и прочий бред, но смысл не поменяется.
Сейчас будет новый тренд в геймдеве на основе дегенеративных ии. Например, будут при помощи них генерироваться квесты/персонажи/предметы и т.д. Или вообще нейронки будут создавать целые сцены с геймплеем в соответствии с созданным ими же квестом например.
Это и раньше было, а сейчас подвезли MCP, что это в теории может облегчить создание таких фичей. Ну и не забываем про вайб кодеров, что уже думаю заполоняют ичи и нексусы своими модами.
Я пару раз его спрашивал, касаемо каких-то проблем. Например, один раз получил хим. ожог глаза и он в целом неплохо описал пп до похода к окулисту и даже верно сказал, какие лекарства пропишет доктор.
Гуглить нет желания в таких случаях, т.к. там, что не чих, то сразу пишут про спидорак ну и тексты невозможно читать из-за сео заспамленнгсти. Пока до ответа на вопрос дойдёшь, утонешь в воде и рекламе.
Здесь скорее не ловушка конкретно SRP, а ловушка излишнего перфекционизма.
Он проявляется много где, не только при декомпозиции. Например при использовании паттернов. Многие программисты (даже опытные), порой любят "пихать" паттерны туда, где это вообще не нужно, что только усложняет код без какого-либо решения конкретной проблемы.
Мне кажется, понимание рамок перфекционизма приходит только с опытом. Потому что, нужно искать индивидуальный подход под разные размеры, типы проектов, учитывая например скорость их развития/масштабируемости и т.д.
Мне понравилась мысль, что "декомпозированный код не всегда является качественным кодом". На самом деле, тоже самое можно сказать про любое проявление перфекционизма в разработке. Имхо, но мысли в статье описаны правильные, просто на одном из примеров.
Я помню нашёл в 2016 свою первую работу вообще через биржу. Да, платили немного, но тогда это был неплохой вариант. В то время, в гос. конторы будучи джуном можно было довольно просто. Не во все конечно, но в многие.
Иронично, что эту статью написала нейронка (конечно автор сделал правки из-за чего хорошо видно их на контрасте)
Однако, то что халява кончилась сейчас, тезис странный. Она кончилась ещё в 2021 году, если не раньше.
Порог входа понятное дело растёт (если бы типичный сеньор из 2015, переместился бы в наше время, то скорее-всего не смог бы пройти собес на современного джуна), а зарплаты уменьшаются. Очередной it пузырь не успел лопнуть, как уже растёт другой в плане нейросетей, который так же рано или поздно лопнет.
Так что настали не самые лучшие времена для сферы. Думаю очень многие её покинут, т.к. зп будут небольшие, а требований будет и переработок будет огромное количество. Очень мало сфер, где на собесах устраивают порой экзамены на несколько часов, сами собесы могут идти в течении нескольких месяцев и где работа 24/7 считается нормой. Плюс сахар с удалёнкой понемногу заканчивается. В США и Европе уже загоняют работников обратно в офис и этот тренд так же до вас дойдёт через годик.
Касаемо ценных навыков, то компьютер сайнс уже давно стал базовым требованием даже для формошлёпов/крудошлёпов. Его спрашивают во всех конторах, размером начиная от средних.
С поиском багов, CI/CD, деплоем и т.д. GPT так же справляется процентов на 80. Про компиляцию приложения на С++ вообще рассмешило. В 2022 первые версии жпт генерили рабочий код для C++ и C# например, если грамотно промпт написать.
В одном соглашусь. Сейчас будет самым ценным навыком, это решать проблемы/баги более эффективнее, чем нейронка и принимать архитектурные решения так же более эффективнее, чем нейронка, чтобы дополнять её, а не быть промпт макакаой, что бездумно копипастит всё, что та генерит.
Тут ещё можно добавить момент: Почему все в обсуждениях нейронок забыли о банальном код ревью.) Даже если допустить, что программист пишет код при помощи нейросети, во-первых, он сам проверяет код на адекватность, во-вторых, этот код проверяет ревьювер, а то и несколько. Уже молчу про разного рода тесты, которыми покрыт код.
Если честно, я не представляю, как в таких условиях в релиз или прод может попасть плохой код от нейронки.) Если такое произошло в команде, то вопрос уже не только к программисту, почему тот не в состоянии уследить косяки нейронки, которые всегда явные и простые в распознавании.)
Ой, рано или поздно, кто-то вспомнит о такой вещи, как Dreamweaver, сделает копию с AI функционалом и сборкой полноценного бэкенд + фронтенд билда. Плюс добавят огромное количество готовых компонентов с кастомизацией и вот уже снова веб программисты не нужны. Никогда такого не было и вот опять. 🙃
проговаривается наполовину или меньше, а вторую половину кандидат должен клещами вытягивать из интервьюера
Без чёткого ТЗ, результат хз. Честно, это какой-то бред. Максимально абстрактная задача, которая так же решается максимально абстрактно исходя из фантазий интервьюера.
Причём, помню на одном проекте хотели использовать один из их продуктов. При ознакомительном звонке (у них есть такая бесплатная услуга), на объяснения заказчика из разряда (а вы решите нашу проблему, если купим?), что-то не применили архитектурные навыки, абстрактного проектирования (как у автора), а затребовали у тех. специалистов (т.е. у нас) подробную информацию с технической стороны проекта.
Да, я про то и говорю, что 2 разные бд это больше проблема, чем решение. Как раз в том случае с приложением и сайтом, нам пришлось писать апи для приложения, чтобы всё работало с единой бд.
может быть какие-то нишевые, бедные предприятия
На данный момент даже у них обычно всё сделано по уму, т.к. их программисты используют готовые решения, чтобы не тратить много времени.
Такое встречал пару раз, но это не было, чем-то рядовым. Как раз наоборот , было большой проблемой.
1 случай.
Веб сайт и windows приложение имели 2 разные удаленные бд на одном сервере. Приложение работало с mssql напрямую, через пользователя с сильно ограниченными правами. Чем это плохо (всем) думаю, объяснять не нужно. Ну а сайт был на php cms (не помню на какой) и работал через mysql стандартно. Видимо, разработчики приложения не поняли, как сделать, хотя бы обращение из приложения к mysql и решили сделать 2 базы данных, что синхронизировались, через крон скрипты на пайтоне (видимо в то время, информацию по готовым библиотекам на нём, найти было проще). Одним словом большой костыль, который и пришлось решать, путём создания нормального апи для приложения.
2 случай
2 сайта одной компании, которые развивались параллельно и в один момент, нужно было сделать единый вход для пользователей. Решить эту проблему оказалось относительно просто, через социальную авторизацию. Один сайт стал "главным", а на второй можно было зайти только через авторизацию первого. Хотя это больше не про использование двух разных баз, а скорее речь только про данные пользователей.
Конечно, можно ещё привести в пример проекты, где используются nosql + sql бд или например несколько бд для архивации или миграций (между серверами), но это не совсем, то что имел автор.)
Так же, никто не отменял возможность сдавать жильё и арендовать более плохое, чтобы существовать на разницу, если внезапно окажешься без работы. Своя недвижка даёт очень много возможностей.
Кстати понял это, как открыть свой стартап-бизнес, но имхо в текущих мировых реалиях я бы купил квартиру в любом случае, т.к. открывать сейчас свой бизнес дело гиблое.
Лично я, вообще отказался от copilot, потому что он больше мешает, чем помогает. Он совершенно не понимает контекста и такое ощущение, что просто берёт код из чужих репозиториев, вообще никак его не меняя... Включаю его только для документации, переводов и прочей рутинной мишуры.
GPT чат использую с функционалом проектов. Прошу в основном либо найти баги (он это делает нормально, если настроить проект), сгенерировать боллерплейты, шаблоны, заготовки и т.д. Чаще всего он генерирует рабочий код, но требующий доработки. Так же, прошу его генерировать, не больше одного класса/модуля/компонента. Чем меньше код, тем лучше он его пишет. Прошу GPT не переписывать код при каждой правке, а описать кратко только варианты изменения. Так быстрее и понятнее. Под каждую задачу делаю новый чат в проекте. С таким подходом вполне удаётся быть более эффективным, при этом не теряя навык и не делегируя всё нейронке.
Далеко не всегда нейронка генерит, то что нужно. Более-того, она обожает уходить в цикл. Например, у вас ошибка в программе. GPT посоветует, допустим, откатить версию, какого-нибудь модуля. Ошибка не пропала? Обновите модуль обратно. Ещё есть ошибка? Удалите модуль и поставьте обратно. Ошибка сохранилась? Попробуйте эту версию модуля (ссылка на несуществующую страницу). И так по кругу, хотя ошибка оказывается вообще в другом месте и по другой причине, а модуль не причём.
Никто не отменял необходимость думать и тестить всё самому. Почти всегда пробежаться дебагером или посмотреть логи, поможет быстрее решить проблему, чем мучить GPT.
Имхо, но GPT, как тот самый мифический идеальный джун. Идеально знает теорию, но плохо кодит и решает проблемы.
У ООП есть свои проблемы это правда, но какая альтернатива? Функциональный подход, который всегда скатывается в файлы с 1000 строк кода несвязанных по логике функций. Лично я не хочу, чтобы программирование скатывалось в условный реакт, потому что код в проектах на нём очень сложно читаем из-за мешанины. По итогу, те же компоненты становятся подобием классов, если грамотно разделять логику.
В общем, ООП сам по себе не плох, просто нужно его "уметь готовить" и не упарываться слишком сильно в реализации.
Например, не использовать паттерны, где надо и не надо. Есть же паттерналистское мышление, когда человек пытается подогнать задачу под паттерн, а не паттерн, под задачу. Вечно искать, какие-то "красивые" решения, которые, по итогу не расширяемые, имеют сильные связи, плюс сам человек, что это написал, не разберётся а своём же коде спустя время.
Если использовать ООП не переусложняя его, то он, не станет головной болью.
А с чего вообще бизнес должен быть справедливым, если сама система координат в которой он находится не справедлива.
Мы живём во время, когда условный блогер, что харизматично несёт бред на камеру, получает больше электрика, работающего с высокопоточкой. Хотя, без его работы, стримерство исчезнет, как профессия.
Так и в бизнесе, даже не беря в расчет иерархию, когда руководство всегда молодцы, а работники всегда крайние и плевать, что без работников не будет и руководства. Даже на одной ступене иерархии может существовать несправедливость. Банальный пример, один работник, пашет 24/7 и тянет команду на себе, когда его коллеги, что пинают болты, получают столько же. Таких примеров можно привести много.
Думаете, сейчас прогоню телегу про равенство, законы, горизонтальную иерархию, коммунизм, где все равны, но кто-то ровнее и прочий сказочный бред?
Нет, просто смиритесь с этим и ищите всеми способами пригретое местечко. Бороться имеет смысл, только за то, чтобы своя жопа в тепле была, а бороться с системой, нормальные люди перестают лет в 16, потому что она тебя перемолет и выплюнет.
Это уже старое веение, сейчас обучают как не только пройти собес при помощи gpt, но и вайбкодить на новом месте без минимальных знаний программирования. 😂
Да, и именно всякие лохобоксы убили it школы и курсы, как таковые. А не прикроют их, потому что они технически свои обязательства выполняют. Блиновская продаёт воздух и ложные обещания, а вот ШП, продают курсы. Да, понятно, что качество курсов оставляет желать лучшего и никакие 300к/наносек после них, ученика не ожидают и близко (если на бесплатную стажировку возьмут уже победа в текущих реалиях). Там много схем, в которых по итогу, оказываешься виновным по закон сам.
Добавим к этому, что большинство ШП владеют не последние люди в правительстве/бизнесе с серьезными связями и поймём, что ШП ещё долго не закроют. Они трансформируются в Алабуги, АИ обучение и прочий бред, но смысл не поменяется.
Да не то, чтобы новый тренд.
Сейчас будет новый тренд в геймдеве на основе дегенеративных ии. Например, будут при помощи них генерироваться квесты/персонажи/предметы и т.д. Или вообще нейронки будут создавать целые сцены с геймплеем в соответствии с созданным ими же квестом например.
Это и раньше было, а сейчас подвезли MCP, что это в теории может облегчить создание таких фичей. Ну и не забываем про вайб кодеров, что уже думаю заполоняют ичи и нексусы своими модами.
Я пару раз его спрашивал, касаемо каких-то проблем. Например, один раз получил хим. ожог глаза и он в целом неплохо описал пп до похода к окулисту и даже верно сказал, какие лекарства пропишет доктор.
Гуглить нет желания в таких случаях, т.к. там, что не чих, то сразу пишут про спидорак ну и тексты невозможно читать из-за сео заспамленнгсти. Пока до ответа на вопрос дойдёшь, утонешь в воде и рекламе.
Здесь скорее не ловушка конкретно SRP, а ловушка излишнего перфекционизма.
Он проявляется много где, не только при декомпозиции. Например при использовании паттернов. Многие программисты (даже опытные), порой любят "пихать" паттерны туда, где это вообще не нужно, что только усложняет код без какого-либо решения конкретной проблемы.
Мне кажется, понимание рамок перфекционизма приходит только с опытом. Потому что, нужно искать индивидуальный подход под разные размеры, типы проектов, учитывая например скорость их развития/масштабируемости и т.д.
Мне понравилась мысль, что "декомпозированный код не всегда является качественным кодом". На самом деле, тоже самое можно сказать про любое проявление перфекционизма в разработке. Имхо, но мысли в статье описаны правильные, просто на одном из примеров.
Я помню нашёл в 2016 свою первую работу вообще через биржу. Да, платили немного, но тогда это был неплохой вариант. В то время, в гос. конторы будучи джуном можно было довольно просто. Не во все конечно, но в многие.
Иронично, что эту статью написала нейронка (конечно автор сделал правки из-за чего хорошо видно их на контрасте)
Однако, то что халява кончилась сейчас, тезис странный. Она кончилась ещё в 2021 году, если не раньше.
Порог входа понятное дело растёт (если бы типичный сеньор из 2015, переместился бы в наше время, то скорее-всего не смог бы пройти собес на современного джуна), а зарплаты уменьшаются. Очередной it пузырь не успел лопнуть, как уже растёт другой в плане нейросетей, который так же рано или поздно лопнет.
Так что настали не самые лучшие времена для сферы. Думаю очень многие её покинут, т.к. зп будут небольшие, а требований будет и переработок будет огромное количество. Очень мало сфер, где на собесах устраивают порой экзамены на несколько часов, сами собесы могут идти в течении нескольких месяцев и где работа 24/7 считается нормой. Плюс сахар с удалёнкой понемногу заканчивается. В США и Европе уже загоняют работников обратно в офис и этот тренд так же до вас дойдёт через годик.
Касаемо ценных навыков, то компьютер сайнс уже давно стал базовым требованием даже для формошлёпов/крудошлёпов. Его спрашивают во всех конторах, размером начиная от средних.
С поиском багов, CI/CD, деплоем и т.д. GPT так же справляется процентов на 80. Про компиляцию приложения на С++ вообще рассмешило. В 2022 первые версии жпт генерили рабочий код для C++ и C# например, если грамотно промпт написать.
В одном соглашусь. Сейчас будет самым ценным навыком, это решать проблемы/баги более эффективнее, чем нейронка и принимать архитектурные решения так же более эффективнее, чем нейронка, чтобы дополнять её, а не быть промпт макакаой, что бездумно копипастит всё, что та генерит.
В 2015 можно было просто прийти в контору со словами "хочу учиться, знаю основу яп" и с 90% вероятностью получить офер джуна.)
Тут ещё можно добавить момент: Почему все в обсуждениях нейронок забыли о банальном код ревью.) Даже если допустить, что программист пишет код при помощи нейросети, во-первых, он сам проверяет код на адекватность, во-вторых, этот код проверяет ревьювер, а то и несколько. Уже молчу про разного рода тесты, которыми покрыт код.
Если честно, я не представляю, как в таких условиях в релиз или прод может попасть плохой код от нейронки.) Если такое произошло в команде, то вопрос уже не только к программисту, почему тот не в состоянии уследить косяки нейронки, которые всегда явные и простые в распознавании.)
Ой, рано или поздно, кто-то вспомнит о такой вещи, как Dreamweaver, сделает копию с AI функционалом и сборкой полноценного бэкенд + фронтенд билда. Плюс добавят огромное количество готовых компонентов с кастомизацией и вот уже снова веб программисты не нужны. Никогда такого не было и вот опять. 🙃
Без чёткого ТЗ, результат хз. Честно, это какой-то бред. Максимально абстрактная задача, которая так же решается максимально абстрактно исходя из фантазий интервьюера.
Причём, помню на одном проекте хотели использовать один из их продуктов. При ознакомительном звонке (у них есть такая бесплатная услуга), на объяснения заказчика из разряда (а вы решите нашу проблему, если купим?), что-то не применили архитектурные навыки, абстрактного проектирования (как у автора), а затребовали у тех. специалистов (т.е. у нас) подробную информацию с технической стороны проекта.
По идее это не зависит от дельфи, это больше про возможности IDE
Да, я про то и говорю, что 2 разные бд это больше проблема, чем решение. Как раз в том случае с приложением и сайтом, нам пришлось писать апи для приложения, чтобы всё работало с единой бд.
На данный момент даже у них обычно всё сделано по уму, т.к. их программисты используют готовые решения, чтобы не тратить много времени.
Такое встречал пару раз, но это не было, чем-то рядовым. Как раз наоборот , было большой проблемой.
1 случай.
Веб сайт и windows приложение имели 2 разные удаленные бд на одном сервере. Приложение работало с mssql напрямую, через пользователя с сильно ограниченными правами. Чем это плохо (всем) думаю, объяснять не нужно. Ну а сайт был на php cms (не помню на какой) и работал через mysql стандартно. Видимо, разработчики приложения не поняли, как сделать, хотя бы обращение из приложения к mysql и решили сделать 2 базы данных, что синхронизировались, через крон скрипты на пайтоне (видимо в то время, информацию по готовым библиотекам на нём, найти было проще). Одним словом большой костыль, который и пришлось решать, путём создания нормального апи для приложения.
2 случай
2 сайта одной компании, которые развивались параллельно и в один момент, нужно было сделать единый вход для пользователей. Решить эту проблему оказалось относительно просто, через социальную авторизацию. Один сайт стал "главным", а на второй можно было зайти только через авторизацию первого. Хотя это больше не про использование двух разных баз, а скорее речь только про данные пользователей.
Конечно, можно ещё привести в пример проекты, где используются nosql + sql бд или например несколько бд для архивации или миграций (между серверами), но это не совсем, то что имел автор.)
Всё так и есть. То, что свой бизнес никогда не обещал успеха, стабильных доходов и всегда был намного более трудозатратным.
Касаемо условий, то не согласен. Во времена кризисов всё-равно открывать свой бизнес сложнее и шанс прогореть намного выше, чем в обычное время.
Так же, никто не отменял возможность сдавать жильё и арендовать более плохое, чтобы существовать на разницу, если внезапно окажешься без работы. Своя недвижка даёт очень много возможностей.
Кстати понял это, как открыть свой стартап-бизнес, но имхо в текущих мировых реалиях я бы купил квартиру в любом случае, т.к. открывать сейчас свой бизнес дело гиблое.
Лично я, вообще отказался от copilot, потому что он больше мешает, чем помогает. Он совершенно не понимает контекста и такое ощущение, что просто берёт код из чужих репозиториев, вообще никак его не меняя... Включаю его только для документации, переводов и прочей рутинной мишуры.
GPT чат использую с функционалом проектов. Прошу в основном либо найти баги (он это делает нормально, если настроить проект), сгенерировать боллерплейты, шаблоны, заготовки и т.д. Чаще всего он генерирует рабочий код, но требующий доработки. Так же, прошу его генерировать, не больше одного класса/модуля/компонента. Чем меньше код, тем лучше он его пишет. Прошу GPT не переписывать код при каждой правке, а описать кратко только варианты изменения. Так быстрее и понятнее. Под каждую задачу делаю новый чат в проекте. С таким подходом вполне удаётся быть более эффективным, при этом не теряя навык и не делегируя всё нейронке.
Далеко не всегда нейронка генерит, то что нужно. Более-того, она обожает уходить в цикл. Например, у вас ошибка в программе. GPT посоветует, допустим, откатить версию, какого-нибудь модуля. Ошибка не пропала? Обновите модуль обратно. Ещё есть ошибка? Удалите модуль и поставьте обратно. Ошибка сохранилась? Попробуйте эту версию модуля (ссылка на несуществующую страницу). И так по кругу, хотя ошибка оказывается вообще в другом месте и по другой причине, а модуль не причём.
Никто не отменял необходимость думать и тестить всё самому. Почти всегда пробежаться дебагером или посмотреть логи, поможет быстрее решить проблему, чем мучить GPT.
Имхо, но GPT, как тот самый мифический идеальный джун. Идеально знает теорию, но плохо кодит и решает проблемы.