Одна из приятных мелочей в нашем банке - наличие внутреннего чата (на платформе bchat). В нем можно решать рабочие вопросы, а также просто поговорить с коллегами из разных концов света, где у нас есть офисы - Лондон, Нью Йорк, Гонконг и так далее. Недавно был свидетелем такого разговора:
- I wrote a program that appears to do nothing, but at least it does it very quickly.
- It's not finished yet, write a few unit tests and add code coverage and static analysis.
- Maybe if I knew what those meant I'd be a better programmer.
- no-one knows, that's the whole point ;-) /me runs and hides
- (after some googling) I do all of those, but I didn't know what they were called. When are you told what they're called?
- After about 10 years service, then the names all get changed again.
Showing posts with label Процесс разработки ПО. Show all posts
Showing posts with label Процесс разработки ПО. Show all posts
Friday, October 12, 2007
Wednesday, April 12, 2006
Тестирование как средство проектирования
На мой взгляд, принцип test first - отличная техника проектирования. По крайней мере, опыт использования такого подхода при разработке библиотеки классов для финансовых приложений - крайне положительный. Энтузиазм по поводу TDD, или Test-Driven-Development, при котором тест пишется до самого класса, основан, возможно, как раз на том, что такая техника восполняет недостаток / исправляет на раннем этапе недочеты дизайна. Дополнительное преимущество: когда класс написан, уже готовы тесты чтобы его протестировать. Если тесты писать после классов, то шансы велики, что тесты не будут написаны вообще.
Недостаток пропаганды TDD, на мой взгляд, - в утрировании принципа test first, его аксиоматизации и возведении на пъедестал, где он приобретает абсурдный вид. По крайней мере, так его часто подают в статьях. Такой подход совершенно естественно вызывает скептицизм практикующего программиста, поскольку написание теста сначала имеет свои неудобства - например, невозможность пользоваться IntelliSense при вызове методов класса. (Кстати, Resharper решает эту проблему.) Поэтому понять прелесть подхода часто можно только попробовав его на практике. Принцип "test first" нужно использовать не как догму, а как мощный инструмент, который качественно меняет подход к разработке ПО, но имеет свою область применения, если смотреть на него в контексте полного цикла разработки.
Отражение взгляда на тесты как на нечто очень важное я нашел в статье о тестировании в Microsoft. О значении, которое там придается тестам, говорят следующие факты:
Недостаток пропаганды TDD, на мой взгляд, - в утрировании принципа test first, его аксиоматизации и возведении на пъедестал, где он приобретает абсурдный вид. По крайней мере, так его часто подают в статьях. Такой подход совершенно естественно вызывает скептицизм практикующего программиста, поскольку написание теста сначала имеет свои неудобства - например, невозможность пользоваться IntelliSense при вызове методов класса. (Кстати, Resharper решает эту проблему.) Поэтому понять прелесть подхода часто можно только попробовав его на практике. Принцип "test first" нужно использовать не как догму, а как мощный инструмент, который качественно меняет подход к разработке ПО, но имеет свою область применения, если смотреть на него в контексте полного цикла разработки.
Отражение взгляда на тесты как на нечто очень важное я нашел в статье о тестировании в Microsoft. О значении, которое там придается тестам, говорят следующие факты:
- позиция тестировщика называется Software Design Engineer in Test
- число тестеров на 40% больше, чем число разработчиков
- планы тестирования внушительны (отрывок)
- тесты изначально автоматизированы
В общем, совершенно согласен с таким подходом, и рад, что мой взгляд на тесты как на что-то первостепенное, находит подтверждение в методике разработки софтверного гиганта.
Wednesday, January 25, 2006
Листая Software Development Magazine...
Две занимательные цитаты. Первая – проницательное наблюдение о метриках производительности, проиллюстрированное примером. Речь в статье идет о программе для управления проектом (точнее - bug-tracking):
Say they’d like to be able to keep track of which programmers create the most bugs, which fix the most, and which write the most code. These reports would be very easy to create from the data that we have, but as soon as you create a disincentive to put bugs in the system, people will stop putting them in the system. I’ve learned that any time you try to measure people in the workplace to make them better, they’ll begin to work toward the measurement, which is what you think you want, but they’ll do it in a way that isn’t what you want.
-- Joel Spolsky, SD Magazine February 2005
Вторая – интересный способ взглянуть на продукт глазами покупателя / пользователя:
Ask your customers to imagine that they’re selling your product at a trade show or an electronics store. Give them a few card-board boxes and ask them to design a product box that they’d buy. The boxes should display the key marketing slogans that they find interesting.
-- Luke Hohmann, из того же номера SD Magazine.
Думаю, можно не раздавать коробки, а просто представить; а вместо слоганов подумать о ключевых фичах; и вопрос этот задать не только клиентам, но и себе самому. :)
Say they’d like to be able to keep track of which programmers create the most bugs, which fix the most, and which write the most code. These reports would be very easy to create from the data that we have, but as soon as you create a disincentive to put bugs in the system, people will stop putting them in the system. I’ve learned that any time you try to measure people in the workplace to make them better, they’ll begin to work toward the measurement, which is what you think you want, but they’ll do it in a way that isn’t what you want.
-- Joel Spolsky, SD Magazine February 2005
Вторая – интересный способ взглянуть на продукт глазами покупателя / пользователя:
Ask your customers to imagine that they’re selling your product at a trade show or an electronics store. Give them a few card-board boxes and ask them to design a product box that they’d buy. The boxes should display the key marketing slogans that they find interesting.
-- Luke Hohmann, из того же номера SD Magazine.
Думаю, можно не раздавать коробки, а просто представить; а вместо слоганов подумать о ключевых фичах; и вопрос этот задать не только клиентам, но и себе самому. :)
Subscribe to:
Posts (Atom)