Я хочу терминологически поддержать lair. Всё-таки MVC используется в презентационной части. И Controller обеспечивает логику поведения интерфейса, а не бизнес-логику приложения.
Если мы имеем выделенный сервер бизнес-логики со своим API, то для его реализации паттерн MVC не используется.
А уже к нему подвлючается Web-Frontend на базе MVC или клиент тоже на MVC или даже MVVM
О дивный новый мир! «простое устройство мониторинга энергопотребления» за 2Круб.
Амперметр — вот это простое устройство мониторинга потребления. При известном напряжении 220в, размечаем шкалу и получаем энергопотребление. Примерно с той же точностью измерений.
Я ничего не имею против статьи и областей применения, но название…
Почему на каждую-то? А Вас не удивляет, что там стоит медсестра просто для того, чтобы подавать инструменты хирургу? Казалось бы, возьми сам со столика, не выпендривайся. Нет же:
— Зажим!
— Тампон!
— Спирт!
— Огурец!
В современной промышленной разработке контроль качества — составная часть общего процесса ALM. Поздно контролировать качество, когда продукт уже разработан. Не путайте с контролем качества в серийном производстве, когда нужно проверить каждый выходящий экземпляр. Там это действительно отдельный процесс
оффтоп, конечно, но медсестра колет в мышцу в процедурном кабинете.
На операции она может уколоть в катетер, в операционном поле работает всё-таки врач.
А про DBA — да, все верно. Чудес не бывает. У вас будет либо крутой DBA, который досконально знает особенности сервера, либо куча кодеров, которые считают, что они могут написать написать всё сами. Опросите их, что они знают о статистике исполнения запросов, когда она собирается, когда сбрасывается и как влияет на исполнение одного и того же запроса. И вы поймете разницу между DBA и программистом, который знает как написать Select, хранимую процедуру или построить индекс.
Вы первый начали утрировать про милиционеров.
Есть понятие специализации. Укол могут сделать все. В ж ягодицу. Дома.
А на операции медсестра должна вскрывать шприц и набирать препарат, а врач — колоть.
Не путайте Software Engineer и Software Engineer in Test. Это разные люди, разные профессии, разные инструменты, разные цели. Это напрямую противоречит тому, что Вы пишете об отсутствии тестировщиков.
А вы согласились бы на операцию, где хирург, анастезиолог и медсестры по очереди бы резали, зашивали, кололи препараты и подавали инструмент?
Да и полы потом пусть помоют.
По поводу Screenshot-based:
Кто-то сначала должен проверить вручную правильность первого скриншота.
Есть куча проверок, не автоматизируемых в принципе.
Вы, конечно, можете считать, что это возможно, но рассудит вас — заказчик. Будет ли он рад результату, или получит продукт, который проходит автотесты, но которым не может нормально пользоваться живой человек.
Не помогает TDD. Если я, как разработчик неправильно понял задачу, то я сначала напишу неправильный тест, а потом — неправильный код.
Неправильное понимание требований — обычная ошибка. И работать надо над ней не отдельно, а в процессе разработки, как и с другими ошибками. С помощью тестирования.
Agile — не магическое заклинание. И вовлечение заказчика — тоже. Кто-то должен проверять правильность. И этот кто-то должен быть не тот, кто делает. Заказчика в процесс вовлекают не для тестирования.
Вникните глубже в то, что они говорят. У них нет тестировщиков, которые тыкают в кнопки по инструкции. У них есть инженеры QA.
Да, есть определённые сферы, где можно тестировать на пользователях. Например, Facebook рассказывал, что сначала выкатывает обновление только для 1% пользователей. Тут как раз эти пользователи работают обезьянками-тестерами.
Не уверен, что этот способ подойдет для систем, которые управляют деньгами, складскими запасами или технологическими процессами.
Заказчик или его уполномоченный… могут взять на себя приемку готовой работы в конце итерации или другого срока ее выполнения. Это звучит вполне логично — тот, кто заказывал работу, должен ее и принять. Причем, лучше это ни у кого не получится сделать. Тестировщик не может брать на себя такую ответственность.
Уважайте тех, кто вам платит. Проверяйте сначала сами. Иначе после пары итераций заказчик поймет, что сдача проекта — это не сдача, а его тестирование, и сильно огорчится.
Разработчик же не может найти ошибки сам, есть масса причин, по которым он даже подсознательно использует свое приложение так, как оно работает, а не так, как оно не работает.
Разработчики могут взять на себя обеспечение технологического процесса разработки, в котором минимальна вероятность ошибки. В этом им отлично помогут инженерные практики: Code Review, парное программирование, Continuous Integration, TDD и прочие. Ну и конечно же автоматизированное тестирование на всех уровнях (модульное, интеграционное, функциональное), что у разработчиков получается гораздо лучше.
Ошибки всегда были и будут. Никакой CodeReview, парное программирование, CI, TDD и прочее не спасут, например, от неверного понимания задачи.
Никакое автотестирование не покроет все варианты использования.
А про то, что у кого лучше получается — и говорить не стоит. Несколько веков назад произошло так называемое «разделение труда». С тех практика показывает, что разделение труда более эффективно. В разработке тоже. Хирург должен оперировать, а певец — петь.
Разработчики могут взять на себя обеспечение устойчивости к регрессии, автоматизировав процессы прогона приемочных тестов и сделав их регулярно повторяющимися на каждое изменение в коде продукта.
Невозможно всё автоматизировать. Автоматизируйте проверку, что поля не поехали, что картинки не исказились, что TabOrder у элементов на форме правильный и т.д.
Нет. Про Бирмана я не слышал раньше, я не дизайнер.
Возможно, он тоже делал что-то похожее, не знаю.
А вот активность студии Лебедева докатилась и задела даже меня. Я читал сводки с фронтов в журнале Людвига. Я разглядывал карту Метро 2010 (http://www.artlebedev.ru/everything/metro/map-2100/) и т.д.
Если мы имеем выделенный сервер бизнес-логики со своим API, то для его реализации паттерн MVC не используется.
А уже к нему подвлючается Web-Frontend на базе MVC или клиент тоже на MVC или даже MVVM
Амперметр — вот это простое устройство мониторинга потребления. При известном напряжении 220в, размечаем шкалу и получаем энергопотребление. Примерно с той же точностью измерений.
Я ничего не имею против статьи и областей применения, но название…
это параллельные процессы.
— Зажим!
— Тампон!
— Спирт!
— Огурец!
На операции она может уколоть в катетер, в операционном поле работает всё-таки врач.
А про DBA — да, все верно. Чудес не бывает. У вас будет либо крутой DBA, который досконально знает особенности сервера, либо куча кодеров, которые считают, что они могут написать написать всё сами. Опросите их, что они знают о статистике исполнения запросов, когда она собирается, когда сбрасывается и как влияет на исполнение одного и того же запроса. И вы поймете разницу между DBA и программистом, который знает как написать Select, хранимую процедуру или построить индекс.
Есть понятие специализации. Укол могут сделать все. В ж ягодицу. Дома.
А на операции медсестра должна вскрывать шприц и набирать препарат, а врач — колоть.
Да и полы потом пусть помоют.
Кто-то сначала должен проверить вручную правильность первого скриншота.
Есть куча проверок, не автоматизируемых в принципе.
Вы, конечно, можете считать, что это возможно, но рассудит вас — заказчик. Будет ли он рад результату, или получит продукт, который проходит автотесты, но которым не может нормально пользоваться живой человек.
Неправильное понимание требований — обычная ошибка. И работать надо над ней не отдельно, а в процессе разработки, как и с другими ошибками. С помощью тестирования.
Agile — не магическое заклинание. И вовлечение заказчика — тоже. Кто-то должен проверять правильность. И этот кто-то должен быть не тот, кто делает. Заказчика в процесс вовлекают не для тестирования.
Да, есть определённые сферы, где можно тестировать на пользователях. Например, Facebook рассказывал, что сначала выкатывает обновление только для 1% пользователей. Тут как раз эти пользователи работают обезьянками-тестерами.
Не уверен, что этот способ подойдет для систем, которые управляют деньгами, складскими запасами или технологическими процессами.
Уважайте тех, кто вам платит. Проверяйте сначала сами. Иначе после пары итераций заказчик поймет, что сдача проекта — это не сдача, а его тестирование, и сильно огорчится.
Разработчик же не может найти ошибки сам, есть масса причин, по которым он даже подсознательно использует свое приложение так, как оно работает, а не так, как оно не работает.
Ошибки всегда были и будут. Никакой CodeReview, парное программирование, CI, TDD и прочее не спасут, например, от неверного понимания задачи.
Никакое автотестирование не покроет все варианты использования.
А про то, что у кого лучше получается — и говорить не стоит. Несколько веков назад произошло так называемое «разделение труда». С тех практика показывает, что разделение труда более эффективно. В разработке тоже. Хирург должен оперировать, а певец — петь.
Невозможно всё автоматизировать. Автоматизируйте проверку, что поля не поехали, что картинки не исказились, что TabOrder у элементов на форме правильный и т.д.
Я волнуюсь за многих увлеченных людей, занимающихся самореализацией без должной зарплаты.
Возможно, он тоже делал что-то похожее, не знаю.
А вот активность студии Лебедева докатилась и задела даже меня. Я читал сводки с фронтов в журнале Людвига. Я разглядывал карту Метро 2010 (http://www.artlebedev.ru/everything/metro/map-2100/) и т.д.