Прочитал первую и вторую из вышеозначенных книг. На мой субъективный взгляд книги совершенно бесполезные, по меньшей мере в плане практическом, в софтверных проектах. Как с точки зрения управляющего разработкой, так и с точки зрения человека, который пишет код. Мой список правильных книг про гибкую разработку:
Кент Бек "Экстремальное программирование"
Кент Бек "Экстремальное программирование. Разработка через тестирование"
Роберт Мартин "Чистый Agile. Основы гибкости"
Роберт Мартин "Идеальный программист"
Роберт Мартин "Чистый код"
Роберт Мартин "Чистая архитектура"
Роберт Мартин "Гибкая разработка программ на Java и C++. Принципы, паттерны и методики"
Роберт Мартин "Принципы, паттерны и методики гибкой разработки на языке C#"
… Мы живем в Обществе Развитого Капитализма. Здесь перевод-на-дерьмо — высшая добродетель. Политики называют это 'оптимизацией потребления'. Я называю это 'переводом на дерьмо'…
Харуки Мураками "Дэнс, дэнс, дэнс"
Автору просто надо было в начале этого текста написать, что это перевод доклада.
Если щелкнуть по видео на youtube, которое там в начале этой статьи, и включить субтитры, то все становится вполне нормально. Можно смотреть и не ломать голову что это такое.
Менеджеры могут просить вас поторопиться. Ни в коем случае не поддавайтесь. Ваша работа — грамотно распоряжаться своими ресурсами, чтобы выстоять до конца.
… выстоять до конца или уйти… менеджеры в большинстве случаев уверены что они лучше умеют распоряжаться чьими угодно ресурсами… разве нет?
О! Практикуете парное программирование!? Через TDD? Это замечательная техника! Я как раз считаю что применять это надо постоянно.
Если говорить про кандидатов, то 95% процентов из них показывают себя на собеседованиях вполне перспективно, а затем проваливаются в повседневной производственной коммуникации. Люди не устройства с совместимыми интерфейсами.
Более-менее адекватная оценка для кандидата появляется после пары месяцев совместной работы в обычной обстановке. И ежедневное парное программирование наиболее этому способствует.
Scrum — это в смысле стендапы и ретро? Нееее… я не про это. Я про TDD и парное программирование с шаблонами, приемочными тестами и автоматизациями CI/CD.
Возможно, программист захочет протестировать эти 50 API endpoints, а менеджеру важны лишь 20 из них, а остальные — это доп. функциональность, которая не влияет на покупательную способность
Странное на мой взгляд допущение. То есть мы предполагаем что программист программирует то, что ему хочется, в отрыве от требований? Ну взял просто реализовал вместо 30 нужных бизнес-функций, которые описаны в требованиях, еще 20 дополнительных, которые ему показались прикольными? А менеджер взял ему за это заплатил еще?
Тут не совсем понятно, бизнес не рассчитывает на окупаемость вложений? Ресурсы вкладываются просто так?
Поторопился и неправильно сформулировал.
Последние 7 лет программирую в восновном финансовые приложения и автоматизацию для бизнеса. Несколько новых проектов подряд в виде стартапов. Управленческий подход такой — "быстро, за полгода пишем сложную бизнес систему без всяких тестов, успешно выводим ее на рынок, потом, когда cash flow наладится, будем приводить все в порядок". Вот это я обозначил термином "быстрый перепихон".
Это означает, что программист пишет код, а тестировщик тестирует код.
Давайте по другому посмотрим на вопрос. 50 автоматизированных тестовых последовательностей вызовов конечных точек web API отрабатывает за 27 секунд. В каждой последовательности в среднем 3 обращения к web API. То есть суммарно это около 150 HTTP запросов. Сколько времени понадобится ручному тестировщику, чтобы выполнить вручную эти 50 тестовых сценариев и оценить их результаты визуально?
Для больших кусков с огромным числом исходов и вариаций поведения весьма сложно написать unit-тест
Ну так бейте большие куски на маленькие, тестируемые unit-ы, а уж потом собирайте из них большие куски, для которых тоже сначала пишите тесты. Single Responsibility Principle очень удобная штука.
Распределите огромное число исходов по обработчикам, из которых соберете потом цепочку ответственности. Хотя я предпочитаю плоский набор методов, который складывает результаты вызовов в контейнер состояния. Цепочки таки геморройней собирать и тестировать.
Эволюционно именно команды использующие TDD или просто автоматические тесты выигрывают на длинной дистанции.
Коллега! Это неоспоримый факт! На длинной дистанции мы молодцы! Но где они? Эти команды? Лично я не знаю ни одной такой команды.
Вообще не видел бизнес-процесса ориентированного на сколько-нибудь длительный срок. Все известные мне предприниматели практикуют в рыночной среде стратегию "быстрого перепихона".
Так Agile в исходном виде даже не методология… набор принципов… не более.
Прочитал первую и вторую из вышеозначенных книг. На мой субъективный взгляд книги совершенно бесполезные, по меньшей мере в плане практическом, в софтверных проектах. Как с точки зрения управляющего разработкой, так и с точки зрения человека, который пишет код. Мой список правильных книг про гибкую разработку:
… Мы живем в Обществе Развитого Капитализма. Здесь перевод-на-дерьмо — высшая добродетель. Политики называют это 'оптимизацией потребления'. Я называю это 'переводом на дерьмо'…
Харуки Мураками "Дэнс, дэнс, дэнс"
Автору просто надо было в начале этого текста написать, что это перевод доклада.
Если щелкнуть по видео на youtube, которое там в начале этой статьи, и включить субтитры, то все становится вполне нормально. Можно смотреть и не ломать голову что это такое.
Купил вчера. Прочитал пару глав. На мой взгляд с переводом все хорошо.
… выстоять до конца или уйти… менеджеры в большинстве случаев уверены что они лучше умеют распоряжаться чьими угодно ресурсами… разве нет?
Javascript мой любимый язык программирования… когда нет работы и проектов я только на нем и пишу…
О! Практикуете парное программирование!? Через TDD? Это замечательная техника! Я как раз считаю что применять это надо постоянно.
Если говорить про кандидатов, то 95% процентов из них показывают себя на собеседованиях вполне перспективно, а затем проваливаются в повседневной производственной коммуникации. Люди не устройства с совместимыми интерфейсами.
Более-менее адекватная оценка для кандидата появляется после пары месяцев совместной работы в обычной обстановке. И ежедневное парное программирование наиболее этому способствует.
Ни разу еще мне не удавалось с помощью собеседований и тестовых заданий определить станет ли кандидат хорошим коллегой впоследствии…
Понял лишь что если сразу что-то явно не нравится, то надо извиняться и вежливо расставаться.
Scrum — это в смысле стендапы и ретро? Нееее… я не про это. Я про TDD и парное программирование с шаблонами, приемочными тестами и автоматизациями CI/CD.
AG10 вы и ваша команда следуете принципам гибкой разработки?
Мдауш...
Что правда кто-то пишет такой код в реальности? В проектах, которые в проде обслуживают реальных потребителей?
Кот клевый...
Странное на мой взгляд допущение. То есть мы предполагаем что программист программирует то, что ему хочется, в отрыве от требований? Ну взял просто реализовал вместо 30 нужных бизнес-функций, которые описаны в требованиях, еще 20 дополнительных, которые ему показались прикольными? А менеджер взял ему за это заплатил еще?
Поторопился и неправильно сформулировал.
Последние 7 лет программирую в восновном финансовые приложения и автоматизацию для бизнеса. Несколько новых проектов подряд в виде стартапов. Управленческий подход такой — "быстро, за полгода пишем сложную бизнес систему без всяких тестов, успешно выводим ее на рынок, потом, когда cash flow наладится, будем приводить все в порядок". Вот это я обозначил термином "быстрый перепихон".
Давайте по другому посмотрим на вопрос. 50 автоматизированных тестовых последовательностей вызовов конечных точек web API отрабатывает за 27 секунд. В каждой последовательности в среднем 3 обращения к web API. То есть суммарно это около 150 HTTP запросов. Сколько времени понадобится ручному тестировщику, чтобы выполнить вручную эти 50 тестовых сценариев и оценить их результаты визуально?
Субъективный. А если к примеру отчитаться о 10 часах дебага? Это будет упущенная выгода? Или менеджер должен быть счастлив?
Если сначала всегда писать тест, то архитектура сама собой начинает получаться более продуманной и тестируемой.
Ну так бейте большие куски на маленькие, тестируемые unit-ы, а уж потом собирайте из них большие куски, для которых тоже сначала пишите тесты. Single Responsibility Principle очень удобная штука.
Распределите огромное число исходов по обработчикам, из которых соберете потом цепочку ответственности. Хотя я предпочитаю плоский набор методов, который складывает результаты вызовов в контейнер состояния. Цепочки таки геморройней собирать и тестировать.
Коллега! Это неоспоримый факт! На длинной дистанции мы молодцы! Но где они? Эти команды? Лично я не знаю ни одной такой команды.
Вообще не видел бизнес-процесса ориентированного на сколько-нибудь длительный срок. Все известные мне предприниматели практикуют в рыночной среде стратегию "быстрого перепихона".