Скажем так если вы используете return несколько раз и использование четко регламентировано, это нормально.
Если у вас есть функция в который никто не может предсказать, где появиться return или вызов Exception, то это не правильно.
Я собственно это и имел виду когда писал, про несколько return-ов.
Программирование это уже не как раньше. Десяток языков и кругом задач в 20-30 направлениях. Программирование это уже целая отрасль с огромных количеством языков и направлений.
Было бы странно видеть проектировщика электросетей который спорит с архитектором, как именно ставить размеры на чертежах.
Так и в программирование, под каждое направление определяется свой набор правил. Главное чтобы эти правила было обдуманными и логичными.
Насколько я понял функция получает номер столбца, получает значения причем непонятного какого-типа и сравнивает их?
Думаю тут скорее не return 0 или 1 нужен, а скорее генерировать исключительные ситуации, когда не получен одно из значений.
Согласен бред. Но исключительная ситуация на то и исключительная, что можно и не следовать этому правилу. Кроме того в моем комментарии про исключение ни слова :) я говорил только про return. Хотя exception тоже своего рода выход из функции.
Читал его статью в свое время. Для меня это один из принципов хорошего программирования. И если перечислять ряд приемов разрушающих красоту, то это один из них.
Парное программирование + Review Кода, могут в некотором роде спасти от появления антипаттернов.
Review может заменить парное программирование, когда оно не возможно, но не всегда.
Я не из мира java, возможностей javadoc не знаю :). Сам использую ndoc и ghostdoc.
Но хотелось бы иметь примерно следующее.
Имеется написанный код, методы и классы названы в соответствии с Agile принципами(тесты тоже :)).
После очередного «коммита», все это собирается, само документируется(ghostdoc или аналог) и выкладывается, например в wikki. В результате получаем готовое описание кода без лишних хлопот.
Хотелось бы услышать о системе документирования кода. Конечно, код должен документировать сам себя. Но все же желательно иметь какой-нибудь инструмент, который будет обеспечивать автоматической формирование документации, на основе хорошо написанного кода :)
Ни кто не мешает :) Чаще всего так делается. Создаем свой интерфейс, реализуем обертку вокруг какого нить Database и вперед :) Но я же не сказал, что это не возможно :)
Тесты покроют всю основную функциональность, их будет ровно столько сколько ситуаций обрабатывает твой код. Естественно если ты меняешь поведения кода, надо будет менять тесты. Вернее ты в начале подправишь тесты, а потом код. И еще при правильном написании тестов, если не меняется поведение метода, то не меняются и сами тесты.
Из практики.
Был большой метод который добавлял route, но в процессе добавления надо было проверить его уникальность, и это тоже было в методе(был большой, плохой метод :), там вообще было много не нужного).
Был написан тест(их там было несколько) который проверял наличия исключения при не уникальности маршрута(именно это и должен был делать наш метод).
Тестов которые бы проверяли работу по проверки уникальности не было(так как метод этого не должен делать)
В результате в момент рефакторинга все ненужные куски кода из метода, растащили по другим классам и методам, сама объявленная логика метода не поменялась, тесты так же не пришлось трогать.
А все потому что они были написаны правильно
Тесты должны быть простыми. Есть такое правильно. Если тест непонятен и требует слишком много, значит сам метод надо делать. он делает не свою работу. Тут тесты выступают в качестве инструмента, для построения архитектуры. На agiledev.ru есть очень много хороших статьей. Но опять повторюсь, надо пробовать и пробовать.
У вас есть задача разобрать CSV файл и поместить данные в БД. По сути любая задача разбивается на много маленьких.
Например в контексте этой задачи есть такая:
«Прочитать строку из файла, распарсить по правилам и разместить в массиве нужные значение из строки.»
Я пишу тест на входе метода строка на выходе массив и проверяю массив(actual и expected).
Далее с помощью тестов я описываю те ситуации которые должен обрабатывать мой метод. Например, если пропущено значение в строке или формат строки не соответствует ожиданиям. И так далее и тому подобное.
По сути тесты это проверка ситуаций, из которых состоит например модуль, который берет данные из файла и помещает из в БД.
Плохая новость в том, что большинство решения для работы с БД, слабо поддаются мокингу, :) поскольку сами созданы без использование этих принципов. Некоторые современные технологии для работы с БД(ORM), приближают нас к этому. Но пока все еще в стадии развития, хотя самому TDD уже предостаточно времени.
Скажем так. TDD выходит из стадии испытания и начинает использоваться в индустрии(asp net mvc полностью построен на нем)
TDD — для команд, для постоянной разработки, когда задача решается не в течении недели двух и благополучно забывается.
Уммм, представил себе идеальный мир, где все используют TDD и Agile.
К тебе обращаются как к разработчику-фрилансеру и просят решить задачу в рамках проекта.
Ты подключаешься к svn(или любой другой системе контроля версии), получаешь последнею версию, просмотрел набор тестов(По названию тестов, быстро понял где что проверяется :)).
Написал тесты для своей задачи, реализовал их, немного по-рефакторил, запустил всю сборку на тестирование.
Сделал commit, где то там у заказчика сработала CI, все успешно собралось и протестировалось.
Пошел забрал свои деньги в банке :)
Что именно проверять в тесте, что мокать, что не мокать, как поступать с приватными методами, как быть при работе с БД. Нет смысла(просто не получится) раскрывать все эти вопросы в одной статье, которая тем более привязана к какой-то технологии(языку программирования). Надо рассматривать их отдельно и пробовать, пробовать, пробовать. И Бек и Файлер пишут, и не только они, что любая команды которая начинает использовать TDD(и unit тестирование в рамках TDD), в среднем тратят по пол года, чтобы хоть что-то понять и наработать свои практики.
Темы TDD, BDD и все, что за ними тянется(unit test, CI, refactoring и так далее) настолько обширны, что пытаться их изложить в какой-то одной статье неблагодарное дело. Когда пытаешься все это прицепить к какой-либо технологии, то получается вообще каша, а сама статья вызовет еще кучу вопросов и нареканий(сам с этим столкнулся).
Поэтому я бы писал статью только про саму технологию и как именно она позволяет использовать те или иные приемы TDD(Предполагая, что аудитория знакома с техникой tdd). При это стараясь не вдаваться в теорию.
Или же написать цикл статьей посвященных исключительно TDD и BDD, максимум давай небольшие примеры.
Если у вас есть функция в который никто не может предсказать, где появиться return или вызов Exception, то это не правильно.
Я собственно это и имел виду когда писал, про несколько return-ов.
Было бы странно видеть проектировщика электросетей который спорит с архитектором, как именно ставить размеры на чертежах.
Так и в программирование, под каждое направление определяется свой набор правил. Главное чтобы эти правила было обдуманными и логичными.
Думаю тут скорее не return 0 или 1 нужен, а скорее генерировать исключительные ситуации, когда не получен одно из значений.
function Fa(a, b)
{
if (a < b){
return 1;
}else
{
return 2;
}
}
Красивее так
function Fa(a, b)
{
if (a < b){
result = 1;
}else
{
result = 2;
}
return result;
}
Review может заменить парное программирование, когда оно не возможно, но не всегда.
Но хотелось бы иметь примерно следующее.
Имеется написанный код, методы и классы названы в соответствии с Agile принципами(тесты тоже :)).
После очередного «коммита», все это собирается, само документируется(ghostdoc или аналог) и выкладывается, например в wikki. В результате получаем готовое описание кода без лишних хлопот.
Из практики.
Был большой метод который добавлял route, но в процессе добавления надо было проверить его уникальность, и это тоже было в методе(был большой, плохой метод :), там вообще было много не нужного).
Был написан тест(их там было несколько) который проверял наличия исключения при не уникальности маршрута(именно это и должен был делать наш метод).
Тестов которые бы проверяли работу по проверки уникальности не было(так как метод этого не должен делать)
В результате в момент рефакторинга все ненужные куски кода из метода, растащили по другим классам и методам, сама объявленная логика метода не поменялась, тесты так же не пришлось трогать.
А все потому что они были написаны правильно
Тесты должны быть простыми. Есть такое правильно. Если тест непонятен и требует слишком много, значит сам метод надо делать. он делает не свою работу. Тут тесты выступают в качестве инструмента, для построения архитектуры. На agiledev.ru есть очень много хороших статьей. Но опять повторюсь, надо пробовать и пробовать.
Например в контексте этой задачи есть такая:
«Прочитать строку из файла, распарсить по правилам и разместить в массиве нужные значение из строки.»
Я пишу тест на входе метода строка на выходе массив и проверяю массив(actual и expected).
Далее с помощью тестов я описываю те ситуации которые должен обрабатывать мой метод. Например, если пропущено значение в строке или формат строки не соответствует ожиданиям. И так далее и тому подобное.
По сути тесты это проверка ситуаций, из которых состоит например модуль, который берет данные из файла и помещает из в БД.
Скажем так. TDD выходит из стадии испытания и начинает использоваться в индустрии(asp net mvc полностью построен на нем)
Уммм, представил себе идеальный мир, где все используют TDD и Agile.
К тебе обращаются как к разработчику-фрилансеру и просят решить задачу в рамках проекта.
Ты подключаешься к svn(или любой другой системе контроля версии), получаешь последнею версию, просмотрел набор тестов(По названию тестов, быстро понял где что проверяется :)).
Написал тесты для своей задачи, реализовал их, немного по-рефакторил, запустил всю сборку на тестирование.
Сделал commit, где то там у заказчика сработала CI, все успешно собралось и протестировалось.
Пошел забрал свои деньги в банке :)
Еще бы почитать про то как эти уровни взаимодействуют друг с другом.
Поэтому я бы писал статью только про саму технологию и как именно она позволяет использовать те или иные приемы TDD(Предполагая, что аудитория знакома с техникой tdd). При это стараясь не вдаваться в теорию.
Или же написать цикл статьей посвященных исключительно TDD и BDD, максимум давай небольшие примеры.