Комментарии 23
Ммм, а если в этот код вставлять проверки на то, что API ведет себя как ожидается — то это ж сразу тесты получатся! Какая прекрасная новая идея!
Да, TDD изобретено. Только тестируем юзабилити API на разработчиках
(Если без иронии и серьезно.) Да, идея совершенно не новая. Да, близка по духу TDD. Но акцент в приёме на раннем тестирование нового API будущими пользователями API (разработчиками). Проведение тестов использования API, проведение code review попыток использовать макета API разработчиками.
Есть ирония… или какие возникают вопросы?
Есть ирония… или какие возникают вопросы?
В процессе данного предлагаемого тестирования макета API, как понимаете, определяется степень легкости использования API данными разработчиками данной команды, а не корректность реализации и корректность функционирование API (чтобы делал TDD). Определается какие места/возможности API вызывают трудности у разработчика. Где разработчик (конкретной команды, конкретного уровня) допускает ошибки, допускает больше всего ошибок.
Это тестирование дизайна API, а не реализации API.
Хотя да. Можно оформлять тестовые куски использования макета API в автоматизированные тесты и проверять насколько точно разработчик решил задачу по использованию макета API. Косвенно опередлять то, насколько разработчик понимает предлагаемое API.
Вы правы можно использовать автоматизированные тесты.
Правда, есть и такой инструмент, как интервью разработчика. В некоторых случаях интервью будет более дешевой альтернативой получения адекватной обратной связи по дизайну API, нежели автоматизированные тесты для которых первоначально нужно определить метрики.
Это тестирование дизайна API, а не реализации API.
Хотя да. Можно оформлять тестовые куски использования макета API в автоматизированные тесты и проверять насколько точно разработчик решил задачу по использованию макета API. Косвенно опередлять то, насколько разработчик понимает предлагаемое API.
Вы правы можно использовать автоматизированные тесты.
Правда, есть и такой инструмент, как интервью разработчика. В некоторых случаях интервью будет более дешевой альтернативой получения адекватной обратной связи по дизайну API, нежели автоматизированные тесты для которых первоначально нужно определить метрики.
а не корректность реализации и корректность функционирование API (чтобы делал TDD)
Я боюсь, у вас достаточно узкое понимание TDD. Одна из его задач как раз в том, чтобы помочь разработчику выработать удобный API через использование этого самого API.
Спасибо, поищу инфу по такому использованию TDD. Если можете подсказать ссылки, то буду рад. Так же это может помочь другим читателям. Спасибо
"When we write a test, we imagine the perfect interface for our operation. We are telling ourselves a story about how the operation will look from the outside. Our story won't always come true, but it's better to start from the best-possible application program interface (API) and work backward than to make things complicated, ugly, and “realistic” from the get-go."
Kent Beck, "Test Driven Development: By Example" (Addison-Wesley Professional, 2002), Chapter 1.
И ещё пояснение.
В приёме важен акцент на следующем процессе.
Разработчик API (используя TDD или иные методы) делает предположение об юзабилити внутренего API. Выдвигает гипотезу (разрабатывает макет API). А далее тестирует эту гипотезу. Используя макет API, просит реализовать разработчиков код, который использует гипотезу API. Далее разработчик API оценивает свою гипотезу. Вносит доработки в гипотезу и тестирует вновь.
Альтернативно, группа разработчиков могла бы формулировать свои собственные гипотезы по необходимому им API.
Вопрос в управлением разработки API. И ведение гипотез к формированию конечного внутреннего API.
В приёме важен акцент на следующем процессе.
Разработчик API (используя TDD или иные методы) делает предположение об юзабилити внутренего API. Выдвигает гипотезу (разрабатывает макет API). А далее тестирует эту гипотезу. Используя макет API, просит реализовать разработчиков код, который использует гипотезу API. Далее разработчик API оценивает свою гипотезу. Вносит доработки в гипотезу и тестирует вновь.
Альтернативно, группа разработчиков могла бы формулировать свои собственные гипотезы по необходимому им API.
Вопрос в управлением разработки API. И ведение гипотез к формированию конечного внутреннего API.
Это, повторюсь, типовой процесс разработки программного продукта, где продуктом выступает внутреннее API, а его аудиторией — разработчики, которые будут пользоваться этим API.
Отличный пример утверждения Шрёдингера. Который раскрывается вопросом: типовой процесс разработки внутренних библиотек для внутренних разработчиков каких фирм/компаний? (Этот вопрос является мотивацией написания поста.)
Не для "каких фирм/компаний", а для индустрии. В индустрии есть такой процесс.
для индустрии
Летают на самолетах, а не на авиаиндустрии.
Вы правомерно, указываете, что данные процессы существуют в индустрии, вы правомерно указываете, что данные процессы вытекают «из математических аксиом». Но смещаете фокус с выделенного в статье предложения для конкретной команды поити по пути фокусирования на потребностях конкретной команды.
вы правомерно указываете, что данные процессы вытекают «из математических аксиом».
Я? Вы точно меня ни с кем не путаете?
Но смещаете фокус с выделенного в статье предложения для конкретной команды поити по пути фокусирования на потребностях конкретной команды.
Я смещаю фокус с предложения "давайте использовать для АПИ вот такой подход" на предложение "давайте трактовать АПИ как продукт, и использовать для него тот же подход, что для продукта".
...start from the best-possible application program interface (API)...
Для кого лучший? Предложение/приём служит для того, чтобы работать с уточнением ответа на этот вопрос.
Для кого лучший?
Для пользователей API.
Да, создатель API создает API для пользователей API. Но в цитате это не прописано прямым текстом. Создатель API может полагать, что его видение API и есть лучшее видение API. Я обратил ваше внимание на то, что в цитате не определены заинтерсованные лица. И не определено разрешение конфликта «лучшее API». Возможно, вы к радости читателей сможете привес ти цитату, где опеределены криетрии «лучшего API».
В данном случае подразумевается, что внутренее API созадет не команда разработчиков, которое использует это API. В частности, из-за, например, недостаточной квалификации, а выделенная команда.
Поэтому в данном случае возникает конфликт интересов того, что понимать под понятием «лучшая реализация API».
Возможно, я давно не перечитавал классиков TDD и не могу сам найти цитату по разрешению именно данного конфликта — взгляд команды разработки внутреннего API на юзабилити API и взгляд команды разработчиков, которые используют внутреннее API.
В данном случае подразумевается, что внутренее API созадет не команда разработчиков, которое использует это API. В частности, из-за, например, недостаточной квалификации, а выделенная команда.
Поэтому в данном случае возникает конфликт интересов того, что понимать под понятием «лучшая реализация API».
Возможно, я давно не перечитавал классиков TDD и не могу сам найти цитату по разрешению именно данного конфликта — взгляд команды разработки внутреннего API на юзабилити API и взгляд команды разработчиков, которые используют внутреннее API.
Возможно, вы к радости читателей сможете привес ти цитату, где опеределены криетрии «лучшего API».
Этому вопросу посвящена другая литература — в частности, та, в которой обсуждается управление требованиями для ПО.
В данном случае подразумевается, что внутренее API созадет не команда разработчиков, которое использует это API. В частности, из-за, например, недостаточной квалификации, а выделенная команда.
В общем случае, чаще всего ПО создают не те люди, которые его используют. Разрешению этого конфликта посвящено множество литературы.
В данном случае подразумевается, что внутренее API созадет не команда разработчиков, которое использует это API. В частности, из-за, например, недостаточной квалификации, а выделенная команда.
Не дай бог так жить.
Разные команды с разной зоной ответсвенности это нормально. А вот эти лучше поэтому они делают это, а вы второго сорта поэтому делаете вот то нельзя.
В обоих командах и создающих АПИ и использующих его должны быть свои сеньеры. Которые знают, умеют и могут. Они договорятся между собой как лучше. И это на самом деле будет лучше.
Не дай бог так жить.
Вы предлагаете, что имеют право голоса только тимлиды/синьеры?
а вы второго сорта поэтому делаете вот то нельзя.
В предложение/приёме не оговорён круг лиц, которые исследуют юзабилити API. Возможно, это часть разработчиков из команды, которая будет использовать разрабатываемое API. По крайней мере, исследование не может учитывать разработчиков, которые придут на проект после внедрения разработанного API.
Поясню, когда возможен данный случай:
В частности, из-за, например, недостаточной квалификации, а выделенная команда.
Допустим, команда, которая будет использовать API не является высоко-компетентной в разработке низкоуровневой работы с устройствами. В то же время, команда, разрабатывающая API и выделяется, так как обладает компетенциями по работе с некоторым набором низкоуровневых API.
Команда разработки API предоставляет высокоуровневый механизм работы с обощенными устройствами.
Или же выделенная команда разрабатывает используя другие языки программирования.
В частности, из-за, например, недостаточной квалификации, а выделенная команда.
Для меньшей стигматизации можно переписать:
В частности, из-за, например, различий в специализации в разработке выделенной команды и основной команды.
Какие у вас возникают вопросы?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Приём для разработчиков API