Я часто захожу на биржу фриланса для поиска заказов, чтобы поискать подходящие заказы, часто вижу там "сделать сайт на wordpress/opencart/tilda/etc". С одной стороны разработчик WordPress будет разрабатывать только на WordPress и делать на этом бабки на заказах. А с другой, если хочется реально разрабатывать ПО, то все-таки теорию лучше знать, так как это все опыт и ошибки предыдущих программистов
Как будто это проблема как раз в том, что он начинает использовать другой диапазон данных. Маленькие задачи описаны хорошо, а вот на больших задачах скорее всего данных слишком мало для качественного решения. Сам же ИИ не "думает", он просто подхватывает наиболее оптимальный вариант решения из имеющихся. А вот этот процесс "обдумывания" это просто алгоритм анализа, в какой набор данных попадет. Надо изучить подробнее, конечно, как работает Deepseek и ChatGPT для наиболее полного решения проблемы
Ну Powershell/Bash это вообще-то очень популярно, учитывая, что это базовые инструменты Windows/Linux. Про Rust не могу сказать ничего, так как не знаю
Как мне кажется ошибочно полагать мнение ИИ за основное. К нему можно присмотреться, проверить информацию и потом уже принимать решение о его целесообразности. Этот процесс не будет заменой действиям человека, а дополнит их и предложит альтернативу. Рановато доверять "ИИ", так как это всего лишь агрегатор информации из открытого доступа, но никак не ее генератор на основе умозаключений
Я когда пришел на свою первую работу, меня представили как опытного системного администратора, умеющего в 1С, php, Windows Server и различным ПО не связанным с повседневной жизнью (работал в хоккейном клубе, там были свои программы и железяки). На самом деле был просто студентом 2 курса с нулевыми знаниями в области 1С и php, серверное ПО тем более. Благо, все удавалось разрешать на банальном "как вы делали до этого" и гуглежом. За 3 года внутри компании вырос, работа была в кайф. Конечно, не так тяжело, как у вас. НО тут самое главное, что я за этот промежуток не научился полноценно "кодить" на php и 1С. Я (лично я считаю себя все-таки начинающим инженером) как инженер - находил решения проблемы. А программный код и прочее, и прочее - дело второе. Уметь программировать это скорее о том, чтобы писать код в соответствии с нормами и быстро. А уметь решать проблемы - быть инженером. На сегодняшний день работаю инженером-разработчиком баз данных. Меня тоже представили как БДшника, хотя я вообще до этого только на Java программировал (и знания по БД все же имелись) и нанимающие об этом знали. Но когда мне впервые дали оптимизацию запроса на несколько сот миллионов записей, чуть взгрустнул, так как индексы и иже с ними уже были, однако не работали. Избавился от view (они были перегружены) - сильно не помогло. Помог совет зайти с другой таблицы. На удивление в ней с 200x года было меньше записей чем в основной за последний год. В целом, не сильно такое достижение, но тоже увеличил объем знаний - подробнее изучил селективность индексов, как они работают, как лучше их формировать и т.д. Опыт скромен и мало соответствует профессионалам, просто захотелось поделиться, почему нет?. Надеюсь, что в будущем ждет еще множество интересных "вызовов" самому себе
И это огорчает. Общество довольно непривередливо, что, как мне кажется, довольно несправедливо. Касательно ТДД, ИМХО, тесты выступают в качестве спецификации. Но я работаю - ТЗ часто переписывают, добавляют и изменяют старый функционал, так как, "Уточнили - не так работает/не понравилось/подставить свое". В таком случае все переписывать, конечно, самоубийственно. В теории, практика оч крутая, на практике хз, может кому-то подойдет
Как работающий в госсекторе (а точнее там очень сложная цепь, когда госсектор повис на ОООшках) скажу, что это, если и правда, то не везде. На республиканском уровне точно нет. Хотя я работал и на Московский гос вуз из лидеров также через ОООшку - тоже нет) Там даже хуже было
Все так, команда была молодая (включая тех, кто нанимал), можно сказать, только начинающая, опыт работы с DDD у всех был первый (зачастую как и опыт работы). В связи с этим сам DDD был реализован скорее всего тоже не оптимально. Да, огромный бойлерплейт это тысячу преобразований, конвертаций в DTO и обратно, скорее всего валидацию тоже посчитали "бойлерплейтом". До самой книги не добрался ещё, надо будет прочитать
Хорошая статья, стало яснее, что подразумевается под "application layer" (ранее рассматривал его как аналог DAO). И понравилась рекомендация, "адаптироваться под масштаб проекта". Был опыт работы с DDD, точнее переписывал написанный по этой архитектуре проект (краткие вводные - работали на аутсорсе, "добро" от руководителя проекта на реализацию DDD было получено, однако после реализации проект был воспринят резко негативно из-за "огромного бойлерплейта"). Было решено разрабатывать "старым добрым, как у нас во всем монорепозитории". Помимо этого аргументом являлся тезис, что мы не можем изменить способ получения данных. Этот тезис я пытался опровергнуть, мотивируя, что мы спокойно можем поменять способ получения данных и вместо обращения к базе данных, можем полученать их по API с 1С. Однако, глава разработки не оценил, в связи с чем архитектура угасла. PS. DDD разрабатывал мой начальник, не я.
Я часто захожу на биржу фриланса для поиска заказов, чтобы поискать подходящие заказы, часто вижу там "сделать сайт на wordpress/opencart/tilda/etc". С одной стороны разработчик WordPress будет разрабатывать только на WordPress и делать на этом бабки на заказах. А с другой, если хочется реально разрабатывать ПО, то все-таки теорию лучше знать, так как это все опыт и ошибки предыдущих программистов
Как будто это проблема как раз в том, что он начинает использовать другой диапазон данных. Маленькие задачи описаны хорошо, а вот на больших задачах скорее всего данных слишком мало для качественного решения. Сам же ИИ не "думает", он просто подхватывает наиболее оптимальный вариант решения из имеющихся. А вот этот процесс "обдумывания" это просто алгоритм анализа, в какой набор данных попадет.
Надо изучить подробнее, конечно, как работает Deepseek и ChatGPT для наиболее полного решения проблемы
Разделяй и властвуй. Разбивая задачу на мелкие кусочки и используя ии, можно добиваться более эффективного результата. Однако все еще не панацея
Ну Powershell/Bash это вообще-то очень популярно, учитывая, что это базовые инструменты Windows/Linux. Про Rust не могу сказать ничего, так как не знаю
Как мне кажется ошибочно полагать мнение ИИ за основное. К нему можно присмотреться, проверить информацию и потом уже принимать решение о его целесообразности. Этот процесс не будет заменой действиям человека, а дополнит их и предложит альтернативу. Рановато доверять "ИИ", так как это всего лишь агрегатор информации из открытого доступа, но никак не ее генератор на основе умозаключений
Двухнедельные еще нет, а вот месячные уже да
Я когда пришел на свою первую работу, меня представили как опытного системного администратора, умеющего в 1С, php, Windows Server и различным ПО не связанным с повседневной жизнью (работал в хоккейном клубе, там были свои программы и железяки). На самом деле был просто студентом 2 курса с нулевыми знаниями в области 1С и php, серверное ПО тем более. Благо, все удавалось разрешать на банальном "как вы делали до этого" и гуглежом. За 3 года внутри компании вырос, работа была в кайф. Конечно, не так тяжело, как у вас. НО тут самое главное, что я за этот промежуток не научился полноценно "кодить" на php и 1С. Я (лично я считаю себя все-таки начинающим инженером) как инженер - находил решения проблемы. А программный код и прочее, и прочее - дело второе. Уметь программировать это скорее о том, чтобы писать код в соответствии с нормами и быстро. А уметь решать проблемы - быть инженером.
На сегодняшний день работаю инженером-разработчиком баз данных. Меня тоже представили как БДшника, хотя я вообще до этого только на Java программировал (и знания по БД все же имелись) и нанимающие об этом знали. Но когда мне впервые дали оптимизацию запроса на несколько сот миллионов записей, чуть взгрустнул, так как индексы и иже с ними уже были, однако не работали. Избавился от view (они были перегружены) - сильно не помогло. Помог совет зайти с другой таблицы. На удивление в ней с 200x года было меньше записей чем в основной за последний год. В целом, не сильно такое достижение, но тоже увеличил объем знаний - подробнее изучил селективность индексов, как они работают, как лучше их формировать и т.д.
Опыт скромен и мало соответствует профессионалам, просто захотелось поделиться, почему нет?. Надеюсь, что в будущем ждет еще множество интересных "вызовов" самому себе
Каждый раз прихожу к этому же выводу. При этом так работает везде
И это огорчает. Общество довольно непривередливо, что, как мне кажется, довольно несправедливо.
Касательно ТДД, ИМХО, тесты выступают в качестве спецификации. Но я работаю - ТЗ часто переписывают, добавляют и изменяют старый функционал, так как, "Уточнили - не так работает/не понравилось/подставить свое". В таком случае все переписывать, конечно, самоубийственно. В теории, практика оч крутая, на практике хз, может кому-то подойдет
Как работающий в госсекторе (а точнее там очень сложная цепь, когда госсектор повис на ОООшках) скажу, что это, если и правда, то не везде. На республиканском уровне точно нет. Хотя я работал и на Московский гос вуз из лидеров также через ОООшку - тоже нет) Там даже хуже было
Все так, команда была молодая (включая тех, кто нанимал), можно сказать, только начинающая, опыт работы с DDD у всех был первый (зачастую как и опыт работы). В связи с этим сам DDD был реализован скорее всего тоже не оптимально. Да, огромный бойлерплейт это тысячу преобразований, конвертаций в DTO и обратно, скорее всего валидацию тоже посчитали "бойлерплейтом". До самой книги не добрался ещё, надо будет прочитать
Хорошая статья, стало яснее, что подразумевается под "application layer" (ранее рассматривал его как аналог DAO). И понравилась рекомендация, "адаптироваться под масштаб проекта".
Был опыт работы с DDD, точнее переписывал написанный по этой архитектуре проект (краткие вводные - работали на аутсорсе, "добро" от руководителя проекта на реализацию DDD было получено, однако после реализации проект был воспринят резко негативно из-за "огромного бойлерплейта"). Было решено разрабатывать "старым добрым, как у нас во всем монорепозитории". Помимо этого аргументом являлся тезис, что мы не можем изменить способ получения данных. Этот тезис я пытался опровергнуть, мотивируя, что мы спокойно можем поменять способ получения данных и вместо обращения к базе данных, можем полученать их по API с 1С. Однако, глава разработки не оценил, в связи с чем архитектура угасла.
PS. DDD разрабатывал мой начальник, не я.