Ваши курсы по яве (если они качественные) могут пригодиться выпускнику вуза или переобучающемуся программисту. Ни тому ни другому они скорее всего нужны не будут так как есть достаточное количество обучающей литературы и видео. Из текста непонятно даёте вы базу или нет, хотя в тексте статьи об это сказано. Без институтской базы такие курсы профанация. Я бы рекомендовал сделать курсы по технологии программирования на месяцев 6-7 которые являлись бы экстрактом лекций из престижного вуза(пусть будет МГУ Столяров 1-4 том.). Второй курс уже по языку. И только в такой последовательности после сдачи экзаменов. Намерение выпускать мидлов - вызывает только грустную улыбку. Для начала выпустите одного крепкого джуна которого после этих курсов сразу связи на работу в нормальную компанию.
П.С.
Сразу не глянул , что автор скилфектори. Больше вопросов и предложений нет, хорошие курсы. Сакутин прошелся по Unity кованными сапогами :)
При всём уважении Павел вы переизобрели уровневую архитектуру игрового приложения где на нижнем слое менеджеры общего назначения-> выше жанровое ядро-> логика представления -> арт. Ну и назвали это детернимированным движком. Забыли ещё про жанровый плагинный редактор упомянуть тогда повестрование было закончено.
Очень спорный момент с обработкой состояний на каждом "тике", разве событийная модель не лучше? Это же не приложение требующее реального времени выполнения.
"Детерминированность"(нормальная архитектура) не имеет никакого отношения к воспроизводимости реплея. Вам достаточно добавить в архитектуру паттерн "команда" для управляющих сообщений и перед вами откроются бездны сериализации и прокрутки вперёд и назад с логированием перед эксепшеном или крашем.
Господи Карл гравитация в М3? рукалицо. В М3 для перемещения плиток со времён угля и пара используют динамическую анимацию(кокос) или твины(юнити, годо).
"Активация" эффектов - логика инитится из конфигурационного файла. а не реализуется в коде.
Для анимации "жука" не нужны потоки(таски) или кастомные автоматы состояний, это делается с помощью динамической анимации/твинов по завершению которого генерится событие в котором проигрывается эффект или анимация "взрыва".
Ну и завершая, весь смысл того что вы называете "детерминированностью", а другие уровневой архитектурой - это разрыв связности между уровнями и выставление между ними только универсализированных интерфейсов. Судя по последнему абзацу вы так и не поняли зачем это нужно, даю подсказку - уровни представления и конфигурируемой логики легко меняются как и арт и это решение максимально полезно именно для гиперказуалок. Вы можете клепать их десятками не тестируя, комбинировать и переиспользовать.
Движения не корректируются по обстановке, подвисает как анимация при недостатке памяти. Возможно вариантом будут инерциальные датчики положения на лапках и на основе их данных корректируемое положение манипуляторов.
Спорный выбор типа сенсора для определения контакта с поверхностью. Поверхность может быть вогнутой под лапкой, нестатичной или локально возвышенной(ветка). лапка должна иметь ход не только до уровня условного нуля поверхности но и ниже если там вогнутость ланшафта. Нужно уметь остановить лапку если она погружается ниже нуля. Я бы выбрал оптический или аккустический сенсор расстояния на каждую лапку. Это также дало бы возможность правильно формировать модель окружающего мира и отмечать тип подлежащей поверхности и нависающие препятствия(ощупать лапкой).
А обычно заказчик озвучивает максимально общую формулировку.
В начале статьи описано попадание этого общего ТЗ на вход сервиса. Декомпозиция начинается не с общей задачи, а составления экономического обоснования. Задача->ЭЭ->ТТ->ТЗ->… конвеер декомпозиции.
требования меняются на ходу
Тоже про это есть. Для этого задача закидыватся с уровня ТЗ на архитектора который может компетентно оценить внедряемость, совместимость и т.д. В итоге у вас нет ситуации адской мешанины из костылей и легаси.
формализация и декомпозиция могут отнять больше ресурсов чем реализация без таковых
Это нормально. Формализации и декомпозиция в данном случае предназначены для атомизации задач и снижения их связности с базой знаний и другими модулями проекта. Вхождение в такую задачу будет низким, время выполнения минимальным, издержки на рефакторинг и тех долг снизятся, по сути это инвестиции в будущее проекта.
И что случится, если опишет таки при декомпозиции, её выполнят, но конечный результат заказчика не устроит — «декомпозитор» неправильно понял основную задачу?
Над «декомпозитором»(так же как и над любой другой ролью) находится тот кто поставил задачу и который апрувит решение. Решение ревьювят исполнители с той же ролью плюс на одну выше и ниже. Некачественное решение не пройдёт утверждение у постановщика задачи и не пройдёт ревью.
Каждая задача и декомпозиционное дерево задач сопровождается созданием набора документов обосновывающих выбор решения и кратко описывающих его. Каждая задача не являющаяся веткой уже существующей, то есть расширение функционала — должна начинаться с утверждения у менеджера и далее проходить утверждения по ролям вплоть до конечного исполнителя.
То есть — изменились требования, формализуем их отправляем на самый верх дерева для утверждения менеджером (нужно ли, на что влияет и т.д.), далее функционал анализирует архитектор на предмет возможности внедрения, проблем при интеграции, совместимость с легаси и утверждает, далее задача падает вниз на декомпозицию. Всё достаточно просто и логично, защищено от бездумного и опасного внесения функционала и рефакторинга.
Разделение труда эффективнее кустарного производства, конвеер эффективнее мануфактуры. Выше специализация меньше времени на производство одной единицы продукта, меньше издержки, дешевле продукт. Кому-то понравиться, кому-то нет, кто-то зажрался, а кто-то нет. Индусы, пакистанцы и китайцы демпингуют только впуть.
А вы слышали про такую штуку, как Agile? Знаете, зачем вообще появился и стал настолько популярен вот такой навороченный комплекс этих методик?
Agile и его манифест крайне спорная вещь и по моему мнению приносит больше проблем чем их решает. Как-то до него всё работало, но тут профсоюз программистов победил и продавил.
Статус задачи — программист говорит, что уже почти готово. Или говорит что готово, а оно не работает. Или работает, но не так как надо. А когда об этом начинаем говорить, то оказывается, что это изменение требований.
У поставленной задачи есть критерии оценки выполнения — это время, соответствие код конвеншену, пройденные Unit тесты, пройденное ревью, опционально(потребляемые кодом ресурсы или время выполнения). Если решение соответствует критериям — значит оно выполнено верно и должно быть оплачено. Исполнитель имеет право вернуть задачу постановщику с указанием ошибок или неточностей, неоднозначных трактовок. Постановщик правит задачу или заводит спор с арбитражем. Постановщик не может задним числом исправить задачу если она не была передана ему на ревью от исполнителя, поэтому никаких дополнительных требований в задаче быть не должно.
Качество — программисты не знают зачем и как будет использоваться система и в итоге делают глупые ошибки с точки зрения UX и логики.
Это решается с помощью чёткой постановки задачи с необходимым уровнем декомпозиции. Декомпозицию делают специалисты компетенция которых(отсутствие возвратов на доработку) позволяет оформлять задачу правильно. Конечная задача представляет из себя описание данных на входе и выходе, интерфейсы, используемые библиотеки и технологии, параметры быстродействия и т.д. Если на задачу должным образом оформлена документация с схемами движения данных, есть описание архитектуры модуля и обоснование, то ошибок логики быть не должно, а уровень входа исполнителя в задачу будет низким.
Тестеры, которые тоже в предметной области непонимают не могут такие ошибки отловить.
У QA должны быть документы от разработчиков для составления чек-листа или в некоторых случаях сами разработчики составляют такие списки, это тоже можно предусмотреть в задаче.
Идея для концепции возникла давно под давлением описанных обстоятельств. Возникла как попытка разобраться какая схема работы будет наиболее удобной для заказчика, бизнеса и исполнителей. Перед написанием статьи я исследовал существующие концепции и практические наработки в этой области. Полностью описанная концепция не реализована ещё нигде, есть частичные реализации бизнес-исполнители, есть CRM с похожей моделью отчётности и документации. Есть Егор Бугаенко, я нашёл про него обзорную статью где он описывал свой проект существующий в коде, но как внутренний проект без внешней части и заказчика, без арбитража, ролей, балов и многого другого.
территории где это организовать
Вся идея была в такой форме организации рабочего процесса при котором исполнители смогут решать задачи доступного им уровня, в которых они наиболее специализированы. По мере выполнения задач исполнители выстроятся в дерево с которым можно решать задачи широкого спектра. Даже если все исполнители всплывут вверх, а внизу никого — они смогут брать задачи уровня ниже но выполнять их на порядок быстрее и качественнее чем новички.
Но в общем случае, и я в этом уверен, что даже если удастся запустить данную модель, то уже через полгода (плюс/минус в зависимости от внешних факторов) ее разорвет в клочья!
Чтобы такого не произошло внедрять необходимо этапами, на готовом проекте и штатных исполнителях и уже после обкатки выводить вовне.
Если я правильно понял статью — это называется краудсорсинг.
Отличие аутсорса и краудсорса в оплате труда. Краудсорсеры — это волонтёры им не платят денег соответственно для логика работы и мотивация другая.
В России из-за менталитета не взлетит.
Можно подробнее что в России не так с менталитетом? И где так? В Европе? Европа большая, Россия тоже европа. Что скажете насчёт испанского и итальянского менталитета и отношения к работе?
Во-первых, ревью также никак не гарантирует качества, тем более если ревью проводится таким же анонимным исполнителем, пусть и более высокого ранга.
Одним может и нет, двумя и более вполне возможно. Если трое скажут что всё хорошо, такому ревью вероятно стоит доверять. Да и такие вопросы возможно балансировать.
Во-вторых, ревью — это оплачиваемая работа, как много клиентов готовы за это платить?
Конечно оплачиваемая, за ревью можно получить балы, если спери исполнителей нет желающих всегда можно назначить цену и это тоже предмет баланса и настроек. Клиент не готов платить за качество кода? Сомнительно!
Во внутренних проектах ревью вообще скорее исключение, чем правило.
И что? Это проблемы этих внутренних сервисов, есть мировая практика доказавшая свою эффективность и её результатами стоит воспользоваться.
В третьих, вот не прошёл какой-то код ревью — а работа-то не выполнена. Заказчику ведь надо было получить решённую задачу, а не ждать, пока там шестеренки между собой порешают, годный код или не годный.
Заказчик не работает на уровне задач, он работает на уровне сроков и смет, поэтому можно смело это исключить. Зависшая задача — это проблема, но не данной концепции так у всех случается постоянно. Концепция не серебряная пуля которая сделает ваш проект суперменом, она позволяет быстро и эффективно решать проблемы. В рамках описанной концепции проблема ревью задачи решается повышением её привлекательности, тоесть повышением балов или установка стоимости на неё. Как вариант можно иметь команду из разных компетенций и уровней которые в пожарном режиме, за отдельную плату, согласны решать директивные задачи.
Любая. Но время и бюджеты всегда ограничены, а возможности раздувать бюрократию, наворачивая друг на друга цепочки контроля, метрики там всякие, безграничны.
Бюрократия — это система делегирования. На одном её конце полная остановка любых решений на другом полный хаос. Нужно стараться придерживаться середины. Без небольшой бюрократии у вас будет ручной режим управления и микроменеджмент. Если вам такое подходит — работайте так.
Как связан интернет с проблемой определения статуса задачи? Или с проблемой контроля качества? Вы же эти проблемы обещаете решить, а не проблему «послать сообщение, поставить задачу через интернет».
Не уверен что правильно понял вопрос, но концепция призвана решить не глобальные проблемы столетия, а несколько конкретных проблем. По «статусу задачи» пожалуйста напишите вопрос более развёрнуто, что конкретно вас заинтересовало. Контроль качества осуществляется так же как и раньше для тех же задач, но уже систематизировано по ясным критериям большим количеством людей коллегиально.
Нужны пруфы! Этого начальника нужно знать в лицо, иначе это вариация анекдота про менеджера по продажам https://matveychev-oleg.livejournal.com/154637.html
Ваши курсы по яве (если они качественные) могут пригодиться выпускнику вуза или переобучающемуся программисту. Ни тому ни другому они скорее всего нужны не будут так как есть достаточное количество обучающей литературы и видео. Из текста непонятно даёте вы базу или нет, хотя в тексте статьи об это сказано. Без институтской базы такие курсы профанация. Я бы рекомендовал сделать курсы по технологии программирования на месяцев 6-7 которые являлись бы экстрактом лекций из престижного вуза(пусть будет МГУ Столяров 1-4 том.). Второй курс уже по языку. И только в такой последовательности после сдачи экзаменов. Намерение выпускать мидлов - вызывает только грустную улыбку. Для начала выпустите одного крепкого джуна которого после этих курсов сразу связи на работу в нормальную компанию.
П.С.
Сразу не глянул , что автор скилфектори. Больше вопросов и предложений нет, хорошие курсы. Сакутин прошелся по Unity кованными сапогами :)
Для камрадов скрасить вечер комедией https://www.youtube.com/watch?v=k1RQ9hAAvsk&t=452s
Не разрушайте детские мечты о том как без них все повсираются.
А как построить цифровой концлагерь если нет цифры, ни софта ни железа? У вас первое предложение по смыслу противоречит четвёртому.
При всём уважении Павел вы переизобрели уровневую архитектуру игрового приложения где на нижнем слое менеджеры общего назначения-> выше жанровое ядро-> логика представления -> арт. Ну и назвали это детернимированным движком. Забыли ещё про жанровый плагинный редактор упомянуть тогда повестрование было закончено.
Очень спорный момент с обработкой состояний на каждом "тике", разве событийная модель не лучше? Это же не приложение требующее реального времени выполнения.
"Детерминированность"(нормальная архитектура) не имеет никакого отношения к воспроизводимости реплея. Вам достаточно добавить в архитектуру паттерн "команда" для управляющих сообщений и перед вами откроются бездны сериализации и прокрутки вперёд и назад с логированием перед эксепшеном или крашем.
Господи Карл гравитация в М3? рукалицо. В М3 для перемещения плиток со времён угля и пара используют динамическую анимацию(кокос) или твины(юнити, годо).
"Активация" эффектов - логика инитится из конфигурационного файла. а не реализуется в коде.
Для анимации "жука" не нужны потоки(таски) или кастомные автоматы состояний, это делается с помощью динамической анимации/твинов по завершению которого генерится событие в котором проигрывается эффект или анимация "взрыва".
Ну и завершая, весь смысл того что вы называете "детерминированностью", а другие уровневой архитектурой - это разрыв связности между уровнями и выставление между ними только универсализированных интерфейсов. Судя по последнему абзацу вы так и не поняли зачем это нужно, даю подсказку - уровни представления и конфигурируемой логики легко меняются как и арт и это решение максимально полезно именно для гиперказуалок. Вы можете клепать их десятками не тестируя, комбинировать и переиспользовать.
В начале статьи описано попадание этого общего ТЗ на вход сервиса. Декомпозиция начинается не с общей задачи, а составления экономического обоснования. Задача->ЭЭ->ТТ->ТЗ->… конвеер декомпозиции.
Тоже про это есть. Для этого задача закидыватся с уровня ТЗ на архитектора который может компетентно оценить внедряемость, совместимость и т.д. В итоге у вас нет ситуации адской мешанины из костылей и легаси.
Это нормально. Формализации и декомпозиция в данном случае предназначены для атомизации задач и снижения их связности с базой знаний и другими модулями проекта. Вхождение в такую задачу будет низким, время выполнения минимальным, издержки на рефакторинг и тех долг снизятся, по сути это инвестиции в будущее проекта.
Над «декомпозитором»(так же как и над любой другой ролью) находится тот кто поставил задачу и который апрувит решение. Решение ревьювят исполнители с той же ролью плюс на одну выше и ниже. Некачественное решение не пройдёт утверждение у постановщика задачи и не пройдёт ревью.
Нет. В статье чёрным по белому написано
То есть — изменились требования, формализуем их отправляем на самый верх дерева для утверждения менеджером (нужно ли, на что влияет и т.д.), далее функционал анализирует архитектор на предмет возможности внедрения, проблем при интеграции, совместимость с легаси и утверждает, далее задача падает вниз на декомпозицию. Всё достаточно просто и логично, защищено от бездумного и опасного внесения функционала и рефакторинга.
Agile и его манифест крайне спорная вещь и по моему мнению приносит больше проблем чем их решает. Как-то до него всё работало, но тут профсоюз программистов победил и продавил.
У поставленной задачи есть критерии оценки выполнения — это время, соответствие код конвеншену, пройденные Unit тесты, пройденное ревью, опционально(потребляемые кодом ресурсы или время выполнения). Если решение соответствует критериям — значит оно выполнено верно и должно быть оплачено. Исполнитель имеет право вернуть задачу постановщику с указанием ошибок или неточностей, неоднозначных трактовок. Постановщик правит задачу или заводит спор с арбитражем. Постановщик не может задним числом исправить задачу если она не была передана ему на ревью от исполнителя, поэтому никаких дополнительных требований в задаче быть не должно.
Это решается с помощью чёткой постановки задачи с необходимым уровнем декомпозиции. Декомпозицию делают специалисты компетенция которых(отсутствие возвратов на доработку) позволяет оформлять задачу правильно. Конечная задача представляет из себя описание данных на входе и выходе, интерфейсы, используемые библиотеки и технологии, параметры быстродействия и т.д. Если на задачу должным образом оформлена документация с схемами движения данных, есть описание архитектуры модуля и обоснование, то ошибок логики быть не должно, а уровень входа исполнителя в задачу будет низким.
У QA должны быть документы от разработчиков для составления чек-листа или в некоторых случаях сами разработчики составляют такие списки, это тоже можно предусмотреть в задаче.
Вся идея была в такой форме организации рабочего процесса при котором исполнители смогут решать задачи доступного им уровня, в которых они наиболее специализированы. По мере выполнения задач исполнители выстроятся в дерево с которым можно решать задачи широкого спектра. Даже если все исполнители всплывут вверх, а внизу никого — они смогут брать задачи уровня ниже но выполнять их на порядок быстрее и качественнее чем новички.
Чтобы такого не произошло внедрять необходимо этапами, на готовом проекте и штатных исполнителях и уже после обкатки выводить вовне.
Отличие аутсорса и краудсорса в оплате труда. Краудсорсеры — это волонтёры им не платят денег соответственно для логика работы и мотивация другая.
Можно подробнее что в России не так с менталитетом? И где так? В Европе? Европа большая, Россия тоже европа. Что скажете насчёт испанского и итальянского менталитета и отношения к работе?
Одним может и нет, двумя и более вполне возможно. Если трое скажут что всё хорошо, такому ревью вероятно стоит доверять. Да и такие вопросы возможно балансировать.
Конечно оплачиваемая, за ревью можно получить балы, если спери исполнителей нет желающих всегда можно назначить цену и это тоже предмет баланса и настроек. Клиент не готов платить за качество кода? Сомнительно!
И что? Это проблемы этих внутренних сервисов, есть мировая практика доказавшая свою эффективность и её результатами стоит воспользоваться.
Заказчик не работает на уровне задач, он работает на уровне сроков и смет, поэтому можно смело это исключить. Зависшая задача — это проблема, но не данной концепции так у всех случается постоянно. Концепция не серебряная пуля которая сделает ваш проект суперменом, она позволяет быстро и эффективно решать проблемы. В рамках описанной концепции проблема ревью задачи решается повышением её привлекательности, тоесть повышением балов или установка стоимости на неё. Как вариант можно иметь команду из разных компетенций и уровней которые в пожарном режиме, за отдельную плату, согласны решать директивные задачи.
Бюрократия — это система делегирования. На одном её конце полная остановка любых решений на другом полный хаос. Нужно стараться придерживаться середины. Без небольшой бюрократии у вас будет ручной режим управления и микроменеджмент. Если вам такое подходит — работайте так.
Не уверен что правильно понял вопрос, но концепция призвана решить не глобальные проблемы столетия, а несколько конкретных проблем. По «статусу задачи» пожалуйста напишите вопрос более развёрнуто, что конкретно вас заинтересовало. Контроль качества осуществляется так же как и раньше для тех же задач, но уже систематизировано по ясным критериям большим количеством людей коллегиально.