Я продолжу раззадоривать любопытство тех, кто еще не читал Рона Патторна, приводя любопытные цитаты из его книжки.
One common misconception is that when a programmer create a program, he simply sits down and start writting code.
Самое распространенное заблуждение состоит в том, что, когда программист делает программу, он просто садится и начинает писать код.
А действительно, что еще надо то?) Сел и пиши код! А то, понимаешь, обсуждения ему подавай, ТЗ в нормальном виде пиши... Сел и пиши!
Однако, практика показывает, что такой подход превращается в разработку по стилю "code and fix". Это когда программист написал код, отдал тестировщику не глядя, тот нашел кучу ошибок "оно не запускается", программист поправил, тестировщик нашел ошибки "страница не открывается!!!", программист поправил, тестировщик наконец-то перешел к бизнес-логике и... ну вы поняли.
Чем плох такой подход? Тем, что очень много времени тратится на ошибки, которые стоило бы отловить на уровне компиляции проекта. Тем, что архитектура со временем превращается в "любая доработка = костыль!". Тем, что непродуманные решения приводят к такому исходу:
И именно поэтому! Существует так называемая "Sofware Design Documentation", которая включает в себя:
И вы знаете, в этом мы очень похожи! Да-да! Ведь перед тем, как протестировать фичу, тестировщик тоже должен в первую очередь СЕСТЬ И ПОДУМАТЬ! Иначе никак, иначе это monkey-кликание, а не тестирование :)
Без элементов тест-дизайна тестировщик сможет сказать лишь "Bug looks fixed", потому что он протестирует ровно то, что описано в баге и ни шагу дальше. Ну или сделает шаг влево, шаг вправо, а все равно все не продумает, что-то да забудет. И в итоге - пропущен дефект. Кто виноват? ;)
А всего то и надо было, посидеть вначале и подумать, как проверять, что могло сломаться, какие тут границы и тд и тп. Так что без "архитектуры" никуда, все равно надо продумать, что проверять.
И комментарии, кстати, комментарии! Даже в ручном тестировании они очень и очень полезны. Заливаете вы, например, файлик с данными для отчета. И все логично, все понятно. Файлик на всякий пожарный сохраняете. Потом проверяете другую ситуацию, делаете второй файлик...
А потом через месяц вам опять надо проверить этот отчет. Открываете вы папочку с файлами для заливки и... все. Какой файл для чего использовался? Где тут компании, где филиалы? Что же теперь, все открывать и изучать? А всего-то и надо было, добавить в папку description.txt, в котором сделать короткие комментарии - "*** - загрузка компаний, *** - загрузка филиалов" и тд. Самый тупой карандаш острее самой острой памяти!
Помните об этом! И будет вам счастье :)
One common misconception is that when a programmer create a program, he simply sits down and start writting code.
Самое распространенное заблуждение состоит в том, что, когда программист делает программу, он просто садится и начинает писать код.
А действительно, что еще надо то?) Сел и пиши код! А то, понимаешь, обсуждения ему подавай, ТЗ в нормальном виде пиши... Сел и пиши!
Однако, практика показывает, что такой подход превращается в разработку по стилю "code and fix". Это когда программист написал код, отдал тестировщику не глядя, тот нашел кучу ошибок "оно не запускается", программист поправил, тестировщик нашел ошибки "страница не открывается!!!", программист поправил, тестировщик наконец-то перешел к бизнес-логике и... ну вы поняли.
Чем плох такой подход? Тем, что очень много времени тратится на ошибки, которые стоило бы отловить на уровне компиляции проекта. Тем, что архитектура со временем превращается в "любая доработка = костыль!". Тем, что непродуманные решения приводят к такому исходу:
И именно поэтому! Существует так называемая "Sofware Design Documentation", которая включает в себя:
- Архетиктуру - документ, описывающий дизайн приложения в целом.
- Data Flow Diagram - диаграмма, показываюящая перемещение данных внутри программы.
- State Transition Diagram - диаграмма, показывающая переходы из одного состояния в другое.
- Flowchart - графическое изображение логики программы.
- Комментарии!!! Да да, самый простой и надежный способ вспомнить впоследствии, почему этот кусок кода в свое время был реализован именно так, а не иначе.
И вы знаете, в этом мы очень похожи! Да-да! Ведь перед тем, как протестировать фичу, тестировщик тоже должен в первую очередь СЕСТЬ И ПОДУМАТЬ! Иначе никак, иначе это monkey-кликание, а не тестирование :)
Без элементов тест-дизайна тестировщик сможет сказать лишь "Bug looks fixed", потому что он протестирует ровно то, что описано в баге и ни шагу дальше. Ну или сделает шаг влево, шаг вправо, а все равно все не продумает, что-то да забудет. И в итоге - пропущен дефект. Кто виноват? ;)
А всего то и надо было, посидеть вначале и подумать, как проверять, что могло сломаться, какие тут границы и тд и тп. Так что без "архитектуры" никуда, все равно надо продумать, что проверять.
И комментарии, кстати, комментарии! Даже в ручном тестировании они очень и очень полезны. Заливаете вы, например, файлик с данными для отчета. И все логично, все понятно. Файлик на всякий пожарный сохраняете. Потом проверяете другую ситуацию, делаете второй файлик...
А потом через месяц вам опять надо проверить этот отчет. Открываете вы папочку с файлами для заливки и... все. Какой файл для чего использовался? Где тут компании, где филиалы? Что же теперь, все открывать и изучать? А всего-то и надо было, добавить в папку description.txt, в котором сделать короткие комментарии - "*** - загрузка компаний, *** - загрузка филиалов" и тд. Самый тупой карандаш острее самой острой памяти!
Помните об этом! И будет вам счастье :)
