Такое все чаще слышу — что программирование не суть кодирование. Мол, можно программировать не зная ЯП, а можно не уметь программировать, в совершенстве владея ЯП.
Мол, если есть четкое Т.З. и вы его переводите просто на ЯП — это манки-кодинг.
Далее, эту же идею все более поднимают в свете успехов злополучного ChatGPT. Мол, суть программирования будущего — это умение разобраться в процессе и затем в деталях описать задачу на естественном языке. Знать при этом ЯП уже не требуется.
Здравствуйте, Shmj, Вы писали:
S>Согласны или нет?
Нет.
Не потому что невозможно писать программы не зная или плохо зная язык.
А потому что навык создания программ обычно развивается вместе со знанием языков программирования.
Обратное не верно. Я видел людей, которые хорошо знают язык, но совершенно неспособны самостоятельно решить реальную задачу.
Здравствуйте, vsb, Вы писали:
vsb>Но вот простой вопрос: почему сейчас никто так не делает? Сесть над душой у программиста и говорить ему, что ему писать. vsb>Наверное потому, что это фигня.
Потому что мало кто на это согласится даже за большие деньги. Вас просто пошлют а то и дадут в лицо.
Вообще это выдержать не возможно длительное время. Ну можно час-два выдержать, когда над душой сидят — но чтобы каждый день...
А вот ChatGPT никуда не денется.
Я не говорю что текущая версия. Нет, текущая версия — говно. Но представьте что будет через 5-7 лет!
Здравствуйте, Shmj, Вы писали:
S> vsb>Но вот простой вопрос: почему сейчас никто так не делает? Сесть над душой у программиста и говорить ему, что ему писать.
В каком-то смысле это типичный эпизод из практики Pair Programming.
S> vsb>Наверное потому, что это фигня. S> Потому что мало кто на это согласится даже за большие деньги. Вас просто пошлют а то и дадут в лицо.
Не поэтому. А потому что результат так себе. Если бы результат такого был лучше, эта практика бы прижилась.
S> Вообще это выдержать не возможно длительное время. Ну можно час-два выдержать, когда над душой сидят — но чтобы каждый день...
А если код получается супер-пупер и деньги за него рекой текут?
Здравствуйте, Shmj, Вы писали:
S>Далее, эту же идею все более поднимают в свете успехов злополучного ChatGPT. Мол, суть программирования будущего — это умение разобраться в процессе и затем в деталях описать задачу на естественном языке. Знать при этом ЯП уже не требуется.
Естественный язык имеет много неоднозначностей. Если попытаться описывать задачу максимально формально, то придем к идее ... языка программирования.
Язык программирования может быть декларативным (таких уже много) и походить на естественный (такие тоже бывают).
S>Такое все чаще слышу — что программирование не суть кодирование. Мол, можно программировать не зная ЯП, а можно не уметь программировать, в совершенстве владея ЯП.
Особенность заключается в том, что есть еще одна сущность — разработка ПО. Просто лишь программирование или кодинг не даст тебе на выходе продукт.
Я представляю себе эту иерархию так:
— есть кодинг (когда ТЗ — написать функцию, которая делает N, и на входе принимает параметры XYZ, а выдает Q, реализовать класс, что-то базовое). Это уровень джуна
— есть программирование (реализовать модуль, что-то немного улучшить, описать задачу другому человеку на кодинг). Это уровень мидла
— есть архитектура (выбрать технологию, сделать разбиение на модули, выбрать ключевой фреймворк и технологии, предъявить требования к железу, оптимизировать решение). Это уровень сеньора
— и есть разработка ПО (собрать команду, перевести с языка бизнеса на язык программистов, определиться с высокоуровневой архитектурой и базовыми вещами, выявить требования ко всей системе, организовать процесс, в том числе процесс тестирования, ну и т.д.). Это уровень тимлида, главы разработки или CTO
ИМХО первый уровень как раз доступен уже сейчас для делегирования ИИ. И он будет все активнее использоваться в ближайшее время. Даже уровень программирования недоступен пока ИИ.
S>Я не говорю что текущая версия. Нет, текущая версия — говно. Но представьте что будет через 5-7 лет!
В 60-е верили, что к концу века человек выйдет за пределы солнечной системы.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, BSOD, Вы писали:
S>>Далее, эту же идею все более поднимают в свете успехов злополучного ChatGPT. Мол, суть программирования будущего — это умение разобраться в процессе и затем в деталях описать задачу на естественном языке. Знать при этом ЯП уже не требуется.
BSO>Естественный язык имеет много неоднозначностей. Если попытаться описывать задачу максимально формально, то придем к идее ... языка программирования. BSO>Язык программирования может быть декларативным (таких уже много) и походить на естественный (такие тоже бывают).
Естественный язык, конечно, имеет много неоднозначностей, с этим спорить глупо. Но в то же время люди как-то налаживают коммуникации, в последние годы даже удалённо, несмотря на все эти неоднозначности. Кто-то пишет постановку задачи, кто-то её читает.
Здравствуйте, Shmj, Вы писали:
S>Далее, эту же идею все более поднимают в свете успехов злополучного ChatGPT. Мол, суть программирования будущего — это умение разобраться в процессе и затем в деталях описать задачу на естественном языке. Знать при этом ЯП уже не требуется.
S>Согласны или нет?
Простой вопрос: можно ли эффективно мыслить, не владея никаким человеческим языком?
Здравствуйте, Shmj, Вы писали:
S>Такое все чаще слышу — что программирование не суть кодирование. Мол, можно программировать не зная ЯП, а можно не уметь программировать, в совершенстве владея ЯП. S>Согласны или нет?
Настоящий программист на любом языке напишет программу на Фортране. (с)
Здравствуйте, Shmj, Вы писали:
S>Такое все чаще слышу — что программирование не суть кодирование. Мол, можно программировать не зная ЯП, а можно не уметь программировать, в совершенстве владея ЯП.
S>Мол, если есть четкое Т.З. и вы его переводите просто на ЯП — это манки-кодинг.
S>Далее, эту же идею все более поднимают в свете успехов злополучного ChatGPT. Мол, суть программирования будущего — это умение разобраться в процессе и затем в деталях описать задачу на естественном языке. Знать при этом ЯП уже не требуется.
S>Согласны или нет?
Про Visual Basic говорили почти то же самое. Там знание ЯП как такового сведено к минимуму. Почти английский. Что не отменяет необходимости понимать, как писать программы, чтобы хоть что-то написать. Много ты видел продуктов на нём? Это показывает, какую (никакую) проблему реально составляет знание ЯП.
Сильный AI мог бы невразумительное мычание переводить в код (мы этим зачастую и занимаемся), но где сильный AI и где ChatGPT.
Здравствуйте, Shmj, Вы писали:
S>Далее, эту же идею все более поднимают в свете успехов злополучного ChatGPT. Мол, суть программирования будущего — это умение разобраться в процессе и затем в деталях описать задачу на естественном языке. Знать при этом ЯП уже не требуется.
Похоже на предыдущую идею — что для программирования на Java не нужно знать С, ОС и железо. С одной стороны это правда, с другой — есть нюанс. Уверен, с ChatGPT будет ровно то же самое — массовые дешевые постановщики задач AI и дорогие программисты, использующие AI как инструмент для написания сложных программ.
Здравствуйте, Shmj, Вы писали: S>Мол, суть программирования будущего — это умение разобраться в процессе и затем в деталях описать задачу на естественном языке. Знать при этом ЯП уже не требуется.
Видео на ютубе можно поделить на два типа.
1. Бесполезное балабольство
Как раз данный ролик относится к нему. Вроде говорит всё правильно, но практического смысла в этом нет. Обычно под такими видео копятся комментарии. Часто они положительные, типа автор какой ты клёвый, всё правильно сказал.
А потом у людей, которые действительно этим интересуются возникает куча вопросов. Ответы на них нужно искать в книгах, если есть время их читать. В качестве введения в эти книги могут подойти видеокурсы.
2. Полезные курсы
По видео на серьёзном уровне учиться довольно сложно, зато в них можно первоначально войти в тему. То о чём говорит автор данного тобою ролика называется программной инженерией.
И по данной ссылке и в принципе в связи с этой темой часто упоминают.
1. ✔ Заказчик (customer).
2. ✔ Планировщик ресурсов (planner).
3. ✔ Менеджер проекта (project manager).
4. ✔ Архитектор (architect).
5. ✘ Руководитель команды (team leader).
6. ✔ Разработчик (developer).
7. ✔ Тестер (tester, QA).
8. ✔ Разработчик документации (technical writer).
9. ✔ Пользователь (user).
10. ✔ Инженер группы поддержки (support engineer).
Дополнительные
1. ✔ Эксперт предметной области.
2. ✔ Специалист по пользовательскому интерфейсу и эргономике.
3. ✔ Ответственный за выпуск релизов.
4. ✔ Библиотекарь.
"Вы неправильно программируете"
Теперь давай вернёмся к видео, которое у тебя в качестве примера.
Я ещё на халяву без редактирования возьму субтитры и помечу некоторые слова относящиеся к ролям, которые он говорил.
Всем привет дорогие друзья. Сейчас на Ютюбе прекрасный тренд где программисты разных мастей рассказывают о видос. Я изучал 10 лет программирования чтобы вот рассказать вам об этом то есть вот поделиться быстренько опытом. И к сожалению ребята просто берут и переводят зарубежный видосы это полная хрень
И допустим мы возьмём вот видос инфоцыганёнка винтерна. Да он инфо цыганёнок у него весь канал построен на тупом копировании зарубежных видео с пересадствованием одной и той же примитивнейшей информации и самый близкий язык программирования по моему хамблему мнению тут это спасибо честно говоря потраченного времени жаль.
Да пятикратно переваренный кал. Да и я решил записать похожее видео, но как всегда со своим мнением нас никому не нужным и со своим нестандартным со своими стандартной позицией. Во-первых да это видео будет не про то что, а я изучал 10 лет программирования чтобы рассказать вам о Big Go notation, про анализ и синтетической сложности. И не про то что я прочитал в книге пасе для самой базовой.
Нет потому что это хрень изучаете в первый год это не за 10 лет на самом деле, что я понял за 10 лет программирования что программирование вообще не проход. Вот тут вот на самом деле, чем больше программируйте меньше я не то что взаимодействует с кодом. А вообще моя мысль там не находится программирование это анализ предметной области.
Во-первых программистов нет. В общем это не ремесло. Вы программист всегда предметный у вас должна быть специализация, если вы программист у вас своя, если разработчик игр, у вас своя. И вся фишка в том что как ты будешь при построении программы взаимодействовать со своей командой и заказчиком условным.
Даже если вы сами решили что сделать у вас в команде появляется заказчик продукта. Некий продукт умер и что я изучил за 10 лет программирования что самое ценное, что я имею в данный момент это понимать свою сферу. Это умеет работать с требованиями, осознавать какие-то есть проблемы и во многом глаза на это открывает допустим такая прекрасная книга как трипл и дома Эрика эванса, который рассказывает как раз таки как писать код предметно.
И такое магическое слово фруктовый программист за 10 лет вы перестаете быть ремесленником, который задрачивает алгоритмы которые пытаются какой-то плагин интересный для Visual Studio найти. Из этого вот ремесла вы становитесь продуктовым разработчиком, который разрабатывает. Не кодразрабатывает, не программуразрабатывает. Продукт мне за эту разработку такую премию дадут. И это самое ценное.
И рекомендую вам идти именно туда не пытаться заучить все алгоритмы сортировки. Это бред, это вам не понадобится не пытаться как-то углубляться в какую-то математику. Потому что даже дата сайнс даже Machine Learning там прекрасный алгоритмы. Но это все тесно связано с бизнесом и продуктом. И вот такой крутой Инсайт, что хороший программист это еще и бизнес-аналитик.
Как определить хорошего программиста как его отличить от плохого. Вот что, если ко мне придёт человек и скажет меди если нет опыта. Как мне понять врет он или нет. Очень просто я вас прошу если у вас не будет чёткого ТЗ. Как вы на это среагируете он даст ответ определенный или даже можно такой вопрос задать.
А вам придет детальное ТЗ по продукту. Как вы, как, как вы его начнете читать. На что вы обратите внимание и неопытный разработчик скажет, что ну вот начнут с самого начала, потом пройдусь по оглавлению и так далее. Ну будет рассказывать как действительно будет это читать. И только опытный вам скажут не хочется картинки лучше. Какие буквы читать на кой это надо, а ТЗ она вообще тут надо.
Вы чем занимаетесь вы типа из тех из галер которые пришло ТЗ как сделали сдали подписали акты о закрытии работ забыли о проекте потому что любой опытный разработчиком продуктовый ты за это рудимент его не существует это это Миф. Это как вот женщин придумали маркетологи реально такого пола не существует, это все биороботы которые. И Земля, каждый раз когда рассказываю новичкам о том что ТЗ не существует они такие существуют.
Земля плоская, бред женщина придумали маркетолог. Это бред а высадку на луну записывал Кубрик на студиях камнем вниз крыши дома Вот это бред или не бред все-таки высадка на луну была или нет. Если я сам уже запутался и то же самое и для них звучит нет ТЗ это тоже такой бред конспирологической теории на самом деле это правда никогда ТЗ не будет.
Любой опытный программист он в Agile это рациях через mailstone и копается с заказчиком продукта работает с клиентами пытается понять, что мы делаем и реализует соответственно и пишет под это код. Потому что самое важное это самое ценное создавать продукт и программист погружен создание продукта. Потому что его делает финальные решения остаются за программистом.
Чтобы не было написано в ТЗ. Чего бы не хотел заказчик. Чего бы не хотели клиенты финальное решение за программиста. Как он напишет так и будет. Если программист не понимает, что надо делать он будет тактически принимать неверные решения и в общем система будет иной не такой какой она должна быть и да это Инсайт.
Что за 10 лет вы приучитесь работать без ТЗ. И вот первый вопрос который бы я задал в чем подвох неопытный разработчик говорит без чёткого ТЗ результат хз. Ну это бред потому что вас никогда не будет чёткого ТЗ. Что такое четкое ТЗ это работающая программа. Возьмите код продукта и у вас будет техническое задание прописанное по пунктам со всеми деталями деталей уже некуда. Вот это чёткое ТЗ
Если вы хотите чтобы за вас заказчик написал программу и вы просто перевели из ТЗ языка на язык года это не программирование это в манки кодинг это самое примитивное тупое, что можно делать в жизни. Быстро наскучивает настоящий разработчик настоящий программист пишет ТЗ в своей программе программирование создание спецификации это создание как раз таки правил по которым это все работает.
И да вы пишете ТЗ вы получается становитесь бизнес-аналитиком вы общаетесь с заказчиком. Что вам надо. Что вы хотите и попутно сразу же переводите это в язык программирования. А чтобы потом не путаться и у вас как в херовом ТЗ не было что в двух разных точках. У вас одно и то же описывается по-разному разные функционал. Вы должны соблюдать правила проектирования чтобы этого не возникало. Вот он Инсайт.
Вот вы пишете ТЗ при общении заказчиками на языке программирования. Чтобы ты не выглядел тупо не было ни четким, не было противоречивым внутри себя вы должны хорошо писать код чтобы этих противоречий не возникало. Очень удобно встать вот эту дешёвую позицию о том что пришлите мне ТЗ как реализую. Ну вы просто переведете криво ТЗ со всеми противоречиями.
Вот не надо так жить, никто так жить не хочет и этим отличается опытный программисты неопытного. Неопытные широкой специализации хочет делать все и сразу. Хочет чтобы он прислали чёткое описание. Он кое-как это перевел без понимания как это будет поддерживаться развиваться и так далее. Он не живет продуктом, он не живет в рынке, он не хочет этим заниматься, у него Корона на голове, он хочет реализовывать алгоритмики.
Хочешь чтобы мы говорили, что делать он хочет жить в этом мире. А опытные разработчик наоборот ему не нужны. Вот эти четкие правила ему не нужны есть сферы где нужны нужна проектная документация, нужно согласование. Но все-таки в большинстве разработки нет этого и не будет, это не надо и за 10 через 10 лет вы это поймете.
Что вы хотите жить своим продуктом вы хотите разрабатывать его в тесной связи с заказчиком с клиентами. Вы хотите анализировать это все. Вы хотите систему ни один раз написать, а развивать, поддерживать, изменять её, удалять функционал, добавлять функционал, изменять функцию чтобы продукт был живой.
И вот этот вот главное мне кажется бред про алгоритмы про бегу на тейшен. Про и прочую на уши вам сайт, что типа я изучал 10 лет программирования чтобы сказать вам что си это важно. Не важно это хрень это бесполезно. Если вы это не используете не надо выкинуть у психики есть хороший защитный механизм от всяких придурков.
Если я чего-то не практикую и о чем-то не разговариваю постоянно, я об этом забываю. Это нормально если вы сейчас сядете изучите вы пойдете в свой предметный рынок свой предметную область. Начнёте делать сайты, вы через год про этот си забудете. На хрен вам не нужен и если вы будете заниматься бестолковой деятельностью изучать бесполезные истории, потому что это якобы квази круто.
В это забудете ваша психика. Вас этого защитит вы просто потратите кучу времени. Не тратьте выберите сферу в которой вам интересно. Если нравится делать сайты погружаетесь в Digital маркетинг погружаетесь в аналитику как это все считается. Какие блоки классно работают. Какие не классные. Как делать а/б тесты. Какие для этого фреймворки.
Какие есть подходы к дизайну типографии. Как мне лучше разместить текста при программировании. Как мне вот запрограммировать шрифты вот эти программируем шрифтов такая специфичная история говорю про растеризацию векторной графики. Есть специальные программисты решают сложность задачи для визуализации допустим шрифтов.
Вот программирует мама, только мама может думать что. Потому что когда я в детстве под себя срался я просите если под себя срался как и все здесь как и все здесь. Вот вы должны вот выбрать чем вы будете заниматься и туда погружаться и развитие ваш прогресс будет, когда вы будете понимать требования рынка, что он хочет.
И конечно наращивать технические навыки все-таки вы программист а не только бизнес-аналитик но технические навыки должны быть подкреплены внешними требованиями. Они просто придуманы вами изнутри и рынку диктуете, что вот так правильно.
И так надо так делать не надо если вы хотите больше узнавать про реально профессиональное крутое программирование от опытных людей подписывайтесь на мой телеграм-канал. В нем я часто пишу разные статьи на тему как живет индустрия, реально живет и обязательно подписывайтесь на Youtube канал.
Мой там я на нем не несу хрень. Я не перевожу бездумно зарубежное видео выдавая что я нихера подобного херни на моем канале не увидите на этом все. Всем спасибо До скорой встречи
Описание ролей
Давай вернёмся к слайдам из видеокурса.
Заказчик
1. Инициирует разработку.
2. Участвует в сборе требований.
3. Участвует в разработке спецификации требований.
4. Принимает результаты разработки.
Планировщик ресурсов
1. Член руководства организации.
2. Выдвигает и координирует требования к проектам в организации.
3. Развивает и направляет план выполнения проекта с точки зрения организации.
4. Обеспечивает финансирование проекта.
Менеджер проекта
1. Выполняет внешние функции.
1.1. Взаимодействие с инициаторам проекта.
1.1.1. Заказчиком.
1.1.2. Планировщиком ресурсов.
2. Выполняет внутренние функции:
2.1. Распределяет задачи среди членов команды.
2.2. Организует выполнение проекта.
Архитектор
1. Проектирует архитектуру системы.
2. Разрабатывает основные проектные решения.
3. Определяет общий план развития проекта.
4. Формирует инфраструктуру разработки.
Руководитель команды
1. Является «главным разработчиком».
2. Осуществляет техническое руководство командой.
3. Разрешает технические вопросы.
Разработчик
1. Реализует проектируемые компоненты.
2. Создает классы и методы.
3. Осуществляет кодирование.
4. Разрабатывает модульные тесты.
5. Выполняет автономное тестирование.
6. Внутри команды может иметь специализацию.
Тестировщик
Тестировщик, Quality Assurance (QA).
1. Проверяет качество программного обеспечения (функциональность, надежность, эффективность и т.п.).
Составляет тесты для каждой фазы проектирования продукта.
2. Исполняет созданные тесты.
3. Выполняет функциональное тестирование.
4. Выполняет интеграционное, системное тестирование.
Разработчик документации
Технический писатель, technical writer.
1. Разработка программной документации.
2. Разработка эксплуатационной документации.
3. Ведение информационной поддержки процесса разработки.
Пользователь
1. Не является заказчиком проекта.
2. Может являться, а может и не являться сотрудником проекта.
3. Является главным потребителем проекта.
4. Обычно существуют группы пользователей проекта.
Эксперт предметной области
1. Обеспечивает информационную поддержку в предметной области проекта.
2. Если проект большой – таких экспертов может быть несколько.
Дизайнер интерфейсов
Специалист по пользовательскому интерфейсу и эргономике. UI/UX.
1. Проектирует пользовательские интерфейсы.
2. Взаимодействует с заказчиком.
3. Анализирует и оценивает комплексные характеристики интерфейса.
3.1. Удобство
3.2. Эргономичность
3.3. Лаконичность
3.4. Дружественность
3.5. Локализуемость
3.6. …
Релиз менеджер
Ответственный за выпуск релиза.
1. Определяет и реализует политику выпуска релизов.
2. Формулирует и проверяет требования к конкретному релизу.
2.1. Необходимая функциональность.
2.2. Состав релиза.
3. Определяет дату выхода релиза.
4. Контролирует процесс выхода релиза.
В программировании может быть.
1. Один программист на один проект.
2. Несколько программистов на один проект.
Можно поизвращаться и сказать, что может быть.
3. Один программист на несколько проектов.
4. Несколько программистов на несколько проектов.
Уровни конвейера
И можно условно построить конвейер по нисходящей.
1. Несколько проектов.
2. Несколько ролей в проекте.
3. Разные операции одной роли в проекте.
Отличие ролей в проекте
И есть закономерный вопрос, а зачем нам было делить людей на роли. При этом заметь я уже выше написал, что все роли будет совмещать один человек, если на проекте один человек.
Один человек будет совмещать роли.
1. Неявно.
2. Явно.
Почему я первым пунктом написал "неявно". Потому что так будет делать новичок. Можно сколько угодно говорить о том, что чем-то можно пренебречь, но в реальности это будет или задокументировано, или храниться в голове. И то, что какие-то знания хранятся лишь в голове не значит, что они не используются при создании проекта и этой роли как бы нет.
Роли и изделия
Так вот главное отличие ролей в том, что когда люди перестают играться в игру под названием "а я всё помню", "а у меня всё в голове", они начинают записывать каждый свой артефакт, то есть по-русски искусственно созданный объект.
Я размышлял над тем же разработчиком и лидером команды разработки, или над тестировщиком и лидером команды тестировщиков, и разницы между создаваемыми артефактами не увидел. Хотя конвейер "3. Разные операции одной роли в проекте." по прежнему будет работать.
Другое дело размышления про то, что должен создавать один и тот же человек, но в разных ролях. Я ещё не додумал эту мысль до конца, она у меня находится в личной базе знаний на рассмотрении.
Изделие (роль)
Требования
1. Заказы (заказчик). (идеи, требования)
Планирование
2. Запасы (планировщик). ресурсов. (люди, деньги, время)
3. Задачи (управленец). (менеджер)
Предметная область
4. Знания (знаток). (эксперт, доп.)
5. Общение (переводчик). (дизайнер ui/ux, интерфейсы, взаимодействия, доп.)
Проектирование
6. Состав (книжник). (библиотеки алгоритмов, доп.)
7. Строение (строитель). (архитектор, конструкции)
Кодирование
8. Действия (разработчик). (алгоритмы, кодировщик)
9. Испытания (испытатель). (тестировщик)
Выпуск
10. Сборки (сборщик). (релиз менеджер, доп.)
Использование
11. Проблема (пользователь). (бета-тестер, вопрос)
12. Решение (помощник). (поддержка, ответ)
Документирование
13. Записи (писатель). (документовед)
1. Заказы (заказчик). (идеи, требования)
У тебя в приведённом видео автор говорит о том, что техническое задание это чуть ли не законченная программа, что там якобы должно быть всё прописано досконально. Я лично читал технические задания, их обычно присылали в формате Microsoft Word и эти заказчики довольно хорошо представляли, что им нужно.
А как-то я смотрел лекцию, сейчас уже точно не помню кто это был. Там была такая теория, что описать техническое задание можно несколькими способами.
1. Один из них описываешь что-то сам.
2. А другой, просто показываешь на уже существующее и говоришь, хочу как здесь.
Там ещё что-то было, но я не помню.
И это техническое задание можно держать в голове, а можно куда-то записать. Другие люди используют документы, а я обзавёлся личной базой знаний, хочу попробовать провернуть такую вот штуку.
Проект
Изделия (роли)
1. Заказы (заказчик)
2. Запасы (планировщик)
3. Задачи (управленец)
4. Знания (знаток)
5. Общение (переводчик)
6. Состав (книжник)
7. Строение (строитель)
8. Действия (разработчик)
9. Испытания (испытатель)
10. Сборки (сборщик)
11. Проблема (пользователь)
12. Решение (помощник)
13. Записи (писатель)
Исходный код
main.cpp
...
Исходный код у меня уже прекрасно лежит в личной базе знаний в каждом своём и чужом проекте, в библиотеках алгоритмах, в примерах. Я не определился ещё с именами, но мне подумалось, что разные артефакты, они же изделия, можно хранить на разных страницах или в подстраницах этих разных страниц. Причём каждое изделие артефакт выглядит по своему.
Да, алгоритмический смысл здесь никакой, но как архитектор я могу записать словесное описание и кодовую конструкцию аля сниппет (фрагмент, отрывок) в раздел архитектуры, то есть строения программы.
Создание изделий (ролей)
И таким образом каждая роль генерирует свои изделия артефакты. У разработчика это код, но он его может сделать на основе архитектуры и прочих вышестоящих или даже нижестоящих изделий произведённых другими ролями. А можно намешать всё в кучу, или что-то держать в голове, то есть пренебречь конвейером в программировании.
Ведь чем полезный ролик отличается от бесполезного. В полезном ролике у нас есть видимый результат труда, его наглядный образец. А в бесполезном есть общие размышления.
Кстати, я тут посмотрел, что я написал, а ведь исходный код относится к роли "8. Действия (разработчик)", или всё же нет. Если подумать, то исходный код это финальная часть, которая потом пойдёт на сборку в объектный код. А это ведь даже разработчику кода позволяют отделять свою работу от той же архитектуры и прочему ещё менее связанному.
Здравствуйте, Shmj, Вы писали:
S>Далее, эту же идею все более поднимают в свете успехов злополучного ChatGPT. Мол, суть программирования будущего — это умение разобраться в процессе и затем в деталях описать задачу на естественном языке. Знать при этом ЯП уже не требуется.
Такое уже предлагали создатели языков COBOL и SQL, когда обещали, что запросы на них может писать бухгалтер, не сильно понимающий в компьютерах.
Думаю, развитие ИИ вроде ChatGPT приведет к появлению специальных языков для них, на которых можно будет описывать задачу и получать четкий, правильный и недвусмысленный ответ.
И задачей программиста будет формулировка ТЗ и перевод требований заказчика на язык, понятный машине — то есть то же, что и сейчас, но на более высоком уровне.
Пока не появится сильный ИИ, разбирающийся в психологии человека (а такого пока не предвидится), программисты будут нужны.
Как запру я тебя за железный замок, за дубовую дверь окованную,
Чтоб свету божьего ты не видела, мое имя честное не порочила…
М. Лермонтов. Песня про царя Ивана Васильевича, молодого опричника и удалого купца Калашникова
Здравствуйте, Worminator X, Вы писали:
WX>Такое уже предлагали создатели языков COBOL и SQL, когда обещали, что запросы на них может писать бухгалтер, не сильно понимающий в компьютерах. WX>Думаю, развитие ИИ вроде ChatGPT приведет к появлению специальных языков для них, на которых можно будет описывать задачу и получать четкий, правильный и недвусмысленный ответ. WX>И задачей программиста будет формулировка ТЗ и перевод требований заказчика на язык, понятный машине — то есть то же, что и сейчас, но на более высоком уровне. WX>Пока не появится сильный ИИ, разбирающийся в психологии человека (а такого пока не предвидится), программисты будут нужны.
Вы мыслите прошлым. Не нужны будут спец. языки никакие — любой язык разумного существа годится.
Программирование — это больше не алгоритмы и не языки. А архитектура. Говорю это как человек отвечающий ща продукт от начального открытия IDE до релизного билда. Ты можешь охрененно знать все тонкости языка и уметь писать гипер-сложные алгоритмы, но если архитерктура говно, то продукт не спасет ничего
Здравствуйте, Shmj, Вы писали:
S>Далее, эту же идею все более поднимают в свете успехов злополучного ChatGPT. Мол, суть программирования будущего — это умение разобраться в процессе и затем в деталях описать задачу на естественном языке. Знать при этом ЯП уже не требуется.
Вроде как если тут заменить слово ChatGPT на какое-нибудь другое, то описана работа ИТ-ного менеджера. Я не уверен в том, что можно руководить каким-то процессом, если сам в нём не разбираешься. Хотя есть мнение, что можно.
S>Согласны или нет?
На мой век нормальной работы хватит.
P.S. Если около товоего дома построят атомную станцию, а софт в ней ИИ напишет, тебе это будет как?
Здравствуйте, Shmj, Вы писали:
S>Вы мыслите прошлым. Не нужны будут спец. языки никакие — любой язык разумного существа годится.
Раньше (например, во времена Евклида или Ломоносова) математические рассуждения описывались обычным человеческим языком. Потом придумали алгебраическую нотацию потому, что обычный язык для этого не очень удобен. Заметим, что очень большой кусок достижений математики был сделан до изобретения алгебраической нотации.
Вот так вот и тут. Путь от формального языка к человеческому — это регресс и одичание, а не прогресс.
Здравствуйте, Pzz, Вы писали:
Pzz>Раньше (например, во времена Евклида или Ломоносова) математические рассуждения описывались обычным человеческим языком. Потом придумали алгебраическую нотацию потому, что обычный язык для этого не очень удобен. Заметим, что очень большой кусок достижений математики был сделан до изобретения алгебраической нотации.
Pzz>Вот так вот и тут. Путь от формального языка к человеческому — это регресс и одичание, а не прогресс.
Как запру я тебя за железный замок, за дубовую дверь окованную,
Чтоб свету божьего ты не видела, мое имя честное не порочила…
М. Лермонтов. Песня про царя Ивана Васильевича, молодого опричника и удалого купца Калашникова
