Ведущим просто необходимо заниматься тех. поддержкой. Это позволит «почувствовать» всю боль пользователя. На практике очень часто сталкивался с тем, что команда пишет софт без детального понимания того, как продуктом пользуются люди. В результате образуется пропасть между представлением в головах и реальным использованием.
Люди которые создают программный продукт должны не то, что ументь программировать, они должны понимать как этот продукт вообще создается, надо понимать сам процесс. Первоклассным разработчиком быть не нужно, но опыт считаю должен быть.
Статья ни о чем. Много воды смысла нуль. Автоматизированное тестирование и TDD тоже надо применять с умом. Почему вы не раскрываете деталей и условий когда это хорошо и когда плохо?
Разрабатывать по TDD? Иди поучи свою жену щи варить. Что нам говорит TDD, сначала пишем тест. Он не проходит. Имплементируем функционал — проходит. Такой подход иррационален. Зрелый продукт внутри представляет собой иерархическую структуру с компонентами и слоями, которые в свою очередь тоже покрыты тестами. TDD двойное покрытие. Учитывая что бизнес логика меняется, то со временем придется еще поддерживать и тесты.
Как на мой взгляд должно производиться тестирование. Чем важнее и «базовее» компонент, тем лучше он должен быть покрыт тестами. TDD хорошо подходит для некоторых фич фреймворков.
Интеграционное тестирование хорошо подходит для критических вещей всего продукта.
Автоматизацию надо начинать с рутинных или приемочных тестов, без которых продукт выпускать смысла нет. В идеале можно использовать DSL подход, и прямо в требовании писать сценарий на DSL для тестирования.
Например проводник винды: select menu «File», submenu «New». Keyboard «My Folder». Check: Explorer.FolderExists("%PATH%\My Folder").
Например у нас в приложении есть большое количество независимых окон, автоматизировали сценарий открытия окна, пока кодом, следующий шаг выделить DSL и дать возможность тестерам писать DSL.
В целом полезная статья.
>User Story жестко отсеивает кнопочные идеи. Проверено на практике. Но здесь появляется оборотная сторона проблемы.
Немножко лукавите, отсеивает тот, кто их читает.
А у меня такой вопрос, почему нельзя всем этим теплом греть, какую либо воду? пусть тепло переносится как переноится, только охлаждение испарителя будет осуществляться водой?
А вам не кажется что дело не в программистах, а в консерватории? Никто не говорит о реализации хоп хоп и в продакшен.
>И после этого вы мне сможете повторить, что вот второй человек затягивает тривиальную задачу в условиях неопределенных требований и ему не стоит идти решать бизнес задачи? Серьезно?
Серьезно.
Есть тривиальная задача: реализовать копирование файла, никто не знает, в том числе заказчик, как оно точно должно работать. Тривиальна она потому, что у нее нет контекста. В рамках своего мировоззрения разработчик может предусмотреть валидные кейсы, несколько дополнив этот контекст.
Любая на первый взгляд тривиальная задача в легаси системе может вызывать боль и ужас.
В вашем случае смеяться можно сколько угодно, но надо сменить продукт оунера и поменять архитекторов/тех лидов.
Код в таких системах должен быть идеально написан в рамках ООП. Качественная программная бизнес модель позволяет делать соразмерные изменения, изменениям происходящим в бизнес процессах. На практике бывает так, надо срочно сделать вот так, программная модель не может, ее надо дорабатывать. Лепят костыль, потом еще костыль — в результате получают какое-то УГ за неимоверные деньги.
Мне не нравится ни кандидат ни интервьювер. Интервьювер убивает свое время, потому как перед ним человек, который затягивает тривиальную задачу в условиях неопределенных требований. Надо скопировать файл, предусматриваешь более менее очевидные кейсы и делаешь.
Польза от такого человека в разработке продукта будет стремиться к нулю, т.к. он не способен работать в степени неопределенности.
Интревьювер видя упорство кандидата и его нежелание двигаться дальше все равно продолжает. Интервью это первое знакомство и не одной из сторон не надо показывать свои понты, человек может просто не подходить к команде, к задачам и т.д.
А такому кандидату надо стремиться быть экспертом в тех. области, т.к. знаний у него предостаточно. Решать бизнес задачи получается, видимо, плохо.
>Таким образом, цель спринта — это командообразующий элемент скрама и хорошо подобранная цель
В корне неверное суждение. Командообразующий элемент это подбор праивльных людей в команду и организациея иерархии и ролей в команде.
>2.ПОЧЕМУ нужно отправлять письмо с объявлением старта спринта всем заинтересованным лицам и членам команды?
Какой-то бюррократический оверхед. Заинтересованные лица как правило знают место, где можно посмотреть текущее состояние, плюс спросить у лида или еше кого либо. Пункт для имитации бурной дятельности.
Вообще метрика только в одних SP попытка объять обним показателем эффективность работы, сомнительная затея. Можно на это потратить кучу времени, но не получить результата.
>Если у кого-нибудь из команды возникает проблема, угрожающая срывом сроков спринта, то она сразу вскрывается и решается совместными усилиями.
Это работает и без скрама при адекватном руководстве, при неадекватном проблему можно вскрывать каждый раз.
Мне вообще скрам напоминает: «Организация рабочего процесса для чайников» в желте-черной обложке. В реальности все сложнее и учитывать приходится многие факторы. Тот же DM Daily Meeting обыкновенная оперативка перед работой, быстро поговорили у кого что и как и поехали работать.
Я бы разделил звание старший/рядовой/младший разработчик на несколько составляющих: экспертная, кругозор, интеллект.
• Экспертная составляющая отражает глубину знаний конкретных технологий. На сколько человек точно и досканально представлет внутренее устройство и принцип работы технологии или инструмента.
• Кругозор говорит о том, какие смежные технологии/области изучал человек при решении проблемы.
• Интеллект говорит о способе и эфективности мышления: человек в состоянии выявить проблему, изучить инструменты для её решения и выбрать наиболее подходящие.
В российской практике очень часто на позицию старшего разработчика отбирают только по экспертным знаниям. На собсеседовании спрашивают лютейшие тонкости, кандидат все отвечает, но когда сталкивается с задачей в которой нет опыта, то возникают проблемы, потому как не хватает кругозора и умственных способностей для её решения.
Ошибка заключается в том, что его не спрашивали, а как бы он решал новую задачу, по которой читал только теорию и давно. И вот тут срабатывает кругозор и интеллект, благодаря которым и формируются экспертные знания.
Понятным становится недовольство способными младшими разработчиками: «Мол я не знаю, но вот изучил и применил бы так и так», и его решение имеет верное направление. Т.к. интеллект на уровне, а тонкости и кругозор он получает в процессе.
При устройстве на работу выбирайте те компании, которые ищут умных людей, готовых развиваться и умеющих двигаться в верном направлении. На моей практике таких компаний было две, где на собеседовании выявляли уровень по трем составлящим.
А способному младшему всегда найдется работа, при условии, что в старшем и рядовых составляющие сбалансированы.
У нас есть стандарт. Он фиксирует спорные моменты по которым были разногласия, периодически дополняется. К проекту есть еще архитектурные заметки, из серии если вы в коде столкнулись с указанными областями, то с ними следует поступать вот так.
Описывать всё и вся не вижу смысла — всегда проще договориться и найти пример в существующем коде. Чем большее количество человек работают над одной базой кода, тем строже должен быть стандарт.
Вот я тоже не понимаю этого шума ах взломали то, ах взломали это. При необходимости власть всегда сможет надавить на бизнес и вынудить компанию выполнить необходимые требования. Пустая болтовня большинства граждан власть не интересует, а если уж органы и власть заинтересовались, они всегда могут доставить человека в удобное им место для разговора.
Если же вы ведете какую-то противозаконную деятельность, то безопасность какого-то вацапа это вообще второстепенный ворос.Вся эта шумиха о безопасности и приватности не более, чем страх своих комплексов.
Посыл автора вроде как понятен, но дизайн выглядит избыточным. Чем это принципиально хуже, чем. Model.ChangeName(Customer, FirstName, LastName), атомарность есть, проблема решена. Непонятно какую проблему решает гибкость, привнося дополнительнуб сложность.
Правила валидации могут быть разными. Например «Икс Зетов» валидно с точки зрения данных, но не валидно с точки зрения бизнеса, такой пользователь уже есть. Валидация формата данных может быть сделана в представлении, ограничение по символам, длине и т.п. А вот проверку валидности с точки зрения бизнеса необходимо делать в бизнес логике, при навалидной сущность модель бросает исключение. В интерфейсе модель может содержать метод для проверки валидности пользователя по конкретномому сценарию
В этом случае представление должно позаботиться о том, чтобы сделать все необходимые проверки и проинформировать пользователя. Если модель получает невалидного пользователя, она просто кидает исключение, т.к. не знает что с этим пользователем делать. Замечу, что для корректности представление должно иметь безопасный (не выбрасывающий исключение) метод проверки валидности.
>«При таком подходе моя валидация строится вокруг команд и действий, а не сущностей.»
Ни слова не говорится об области видимости: данные могут быть объявлены в интерфейсе, а каждый слой может иметь свою реализацию и оперировать «своим» типом. Но как всегда «все сильно зависит».
Не знаю как большинство, но я в ресторан хожу кушать и пить, в фастфудах бываю редко. Какой там стол сугубо наплевать, если качественная еда и хорошее обслуживание, то все эти новомодные фишки, да еще и за 6,7 килобаксов вообще никуда не уперлись, 20 столов — 134 килобакса. Такие деньги лучше пустить на персонал, и получить больше прибыли, чем на какие-то новомодные столы. Китай планшет за 100 баксов, решит задачу по заказу на раз два.
Мне кажется программист, как инженер, прежде всего должен понимать для чего создавался инструмент и в каких случаях им целесообразно пользоваться. Для этого он должен уметь разобраться и понять сущность этого инструмента. Алгоритмы еще один обширный инструмент, который немного бы надо знать, для кругозора. Весь говнокод который я видел был поражден плохим руководством, отсутствием взаимодействия в команде и недостаточным уровне IQ для рационального использования той или иной технологии. Даже зная алгоритмы, плохой программист и все равно КРИВО применит, я незнающий прямой, изучит и применит прямо. Неправильные пчелы делают неправильный мед.
У меня сейчас знания по лагоритмам посредственные, я бы сказал просто имею представление, при необходимости буду читать учить и разбираться, ровно как и с другими технологиями. На изучение какой-то технологии уходит больше времени, на какой-то другой меньше, но голова с прямыми руками вероятнее всего со временем будет приближаться к верному результату.
Разрабатывать по TDD? Иди поучи свою жену щи варить. Что нам говорит TDD, сначала пишем тест. Он не проходит. Имплементируем функционал — проходит. Такой подход иррационален. Зрелый продукт внутри представляет собой иерархическую структуру с компонентами и слоями, которые в свою очередь тоже покрыты тестами. TDD двойное покрытие. Учитывая что бизнес логика меняется, то со временем придется еще поддерживать и тесты.
Как на мой взгляд должно производиться тестирование. Чем важнее и «базовее» компонент, тем лучше он должен быть покрыт тестами. TDD хорошо подходит для некоторых фич фреймворков.
Интеграционное тестирование хорошо подходит для критических вещей всего продукта.
Автоматизацию надо начинать с рутинных или приемочных тестов, без которых продукт выпускать смысла нет. В идеале можно использовать DSL подход, и прямо в требовании писать сценарий на DSL для тестирования.
Например проводник винды: select menu «File», submenu «New». Keyboard «My Folder». Check: Explorer.FolderExists("%PATH%\My Folder").
Например у нас в приложении есть большое количество независимых окон, автоматизировали сценарий открытия окна, пока кодом, следующий шаг выделить DSL и дать возможность тестерам писать DSL.
>User Story жестко отсеивает кнопочные идеи. Проверено на практике. Но здесь появляется оборотная сторона проблемы.
Немножко лукавите, отсеивает тот, кто их читает.
>И после этого вы мне сможете повторить, что вот второй человек затягивает тривиальную задачу в условиях неопределенных требований и ему не стоит идти решать бизнес задачи? Серьезно?
Серьезно.
Есть тривиальная задача: реализовать копирование файла, никто не знает, в том числе заказчик, как оно точно должно работать. Тривиальна она потому, что у нее нет контекста. В рамках своего мировоззрения разработчик может предусмотреть валидные кейсы, несколько дополнив этот контекст.
Любая на первый взгляд тривиальная задача в легаси системе может вызывать боль и ужас.
В вашем случае смеяться можно сколько угодно, но надо сменить продукт оунера и поменять архитекторов/тех лидов.
Код в таких системах должен быть идеально написан в рамках ООП. Качественная программная бизнес модель позволяет делать соразмерные изменения, изменениям происходящим в бизнес процессах. На практике бывает так, надо срочно сделать вот так, программная модель не может, ее надо дорабатывать. Лепят костыль, потом еще костыль — в результате получают какое-то УГ за неимоверные деньги.
Польза от такого человека в разработке продукта будет стремиться к нулю, т.к. он не способен работать в степени неопределенности.
Интревьювер видя упорство кандидата и его нежелание двигаться дальше все равно продолжает. Интервью это первое знакомство и не одной из сторон не надо показывать свои понты, человек может просто не подходить к команде, к задачам и т.д.
А такому кандидату надо стремиться быть экспертом в тех. области, т.к. знаний у него предостаточно. Решать бизнес задачи получается, видимо, плохо.
В корне неверное суждение. Командообразующий элемент это подбор праивльных людей в команду и организациея иерархии и ролей в команде.
>2.ПОЧЕМУ нужно отправлять письмо с объявлением старта спринта всем заинтересованным лицам и членам команды?
Какой-то бюррократический оверхед. Заинтересованные лица как правило знают место, где можно посмотреть текущее состояние, плюс спросить у лида или еше кого либо. Пункт для имитации бурной дятельности.
Вообще метрика только в одних SP попытка объять обним показателем эффективность работы, сомнительная затея. Можно на это потратить кучу времени, но не получить результата.
>Если у кого-нибудь из команды возникает проблема, угрожающая срывом сроков спринта, то она сразу вскрывается и решается совместными усилиями.
Это работает и без скрама при адекватном руководстве, при неадекватном проблему можно вскрывать каждый раз.
Мне вообще скрам напоминает: «Организация рабочего процесса для чайников» в желте-черной обложке. В реальности все сложнее и учитывать приходится многие факторы. Тот же DM Daily Meeting обыкновенная оперативка перед работой, быстро поговорили у кого что и как и поехали работать.
Статья попахивает «скрам головного мозга».
• Экспертная составляющая отражает глубину знаний конкретных технологий. На сколько человек точно и досканально представлет внутренее устройство и принцип работы технологии или инструмента.
• Кругозор говорит о том, какие смежные технологии/области изучал человек при решении проблемы.
• Интеллект говорит о способе и эфективности мышления: человек в состоянии выявить проблему, изучить инструменты для её решения и выбрать наиболее подходящие.
В российской практике очень часто на позицию старшего разработчика отбирают только по экспертным знаниям. На собсеседовании спрашивают лютейшие тонкости, кандидат все отвечает, но когда сталкивается с задачей в которой нет опыта, то возникают проблемы, потому как не хватает кругозора и умственных способностей для её решения.
Ошибка заключается в том, что его не спрашивали, а как бы он решал новую задачу, по которой читал только теорию и давно. И вот тут срабатывает кругозор и интеллект, благодаря которым и формируются экспертные знания.
Понятным становится недовольство способными младшими разработчиками: «Мол я не знаю, но вот изучил и применил бы так и так», и его решение имеет верное направление. Т.к. интеллект на уровне, а тонкости и кругозор он получает в процессе.
При устройстве на работу выбирайте те компании, которые ищут умных людей, готовых развиваться и умеющих двигаться в верном направлении. На моей практике таких компаний было две, где на собеседовании выявляли уровень по трем составлящим.
А способному младшему всегда найдется работа, при условии, что в старшем и рядовых составляющие сбалансированы.
Описывать всё и вся не вижу смысла — всегда проще договориться и найти пример в существующем коде. Чем большее количество человек работают над одной базой кода, тем строже должен быть стандарт.
Если же вы ведете какую-то противозаконную деятельность, то безопасность какого-то вацапа это вообще второстепенный ворос.Вся эта шумиха о безопасности и приватности не более, чем страх своих комплексов.
Правила валидации могут быть разными. Например «Икс Зетов» валидно с точки зрения данных, но не валидно с точки зрения бизнеса, такой пользователь уже есть. Валидация формата данных может быть сделана в представлении, ограничение по символам, длине и т.п. А вот проверку валидности с точки зрения бизнеса необходимо делать в бизнес логике, при навалидной сущность модель бросает исключение. В интерфейсе модель может содержать метод для проверки валидности пользователя по конкретномому сценарию
В этом случае представление должно позаботиться о том, чтобы сделать все необходимые проверки и проинформировать пользователя. Если модель получает невалидного пользователя, она просто кидает исключение, т.к. не знает что с этим пользователем делать. Замечу, что для корректности представление должно иметь безопасный (не выбрасывающий исключение) метод проверки валидности.
>«При таком подходе моя валидация строится вокруг команд и действий, а не сущностей.»
Ни слова не говорится об области видимости: данные могут быть объявлены в интерфейсе, а каждый слой может иметь свою реализацию и оперировать «своим» типом. Но как всегда «все сильно зависит».
У меня сейчас знания по лагоритмам посредственные, я бы сказал просто имею представление, при необходимости буду читать учить и разбираться, ровно как и с другими технологиями. На изучение какой-то технологии уходит больше времени, на какой-то другой меньше, но голова с прямыми руками вероятнее всего со временем будет приближаться к верному результату.