Проверять код на наличие ошибок — необходимость или излишество?

Алекс Admin 15.02.2010 15:50

не проверяйте код, и никогда не пишите тестов, коммитьте сразу и закрывайте задачи, оставляя все баги тестерам

5 баллов:)

А вообще-то альфа тестирование выполняют программисты

Відповісти

Підтримати

Valeriy Zamaraiev (junior lisper) 04.02.2010 13:40

Вывод: не проверяйте код, и никогда не пишите тестов, коммитьте сразу и закрывайте задачи, оставляя все баги тестерам, а лучше всего конечным пользователям. Я тогда больше заработаю.

Відповісти

Підтримати

anonymous 04.02.2010 13:17

Да, Design Driven Development это круто, это сейчас редко встретишь.

Зачем вообще Design если можно быстренько наколбасть, потом тестеры быстренько занесут все в багтрекинг, затем мы быстренько пофиксим, фиксы смержим и можно в продакшн. (ну или еще пару десятков итераций наколбасим-пофиксим-все перепишем)

Відповісти

Підтримати

anonymous 04.02.2010 11:26

А DDD? Как данные драйвят девелопментом (а не ходом выполнения программы)? Или может дизайн «драйвит»?)

Відповісти

Підтримати

Александр Маненко 04.02.2010 09:23

Тестирование важно, но ТДД — это вообще мошенническая аббревиатура, testing cannot drive development, имхо.

Ну как бы давно известно что в TDD слово Test неудачно. TDD это не тесты, а дизайн, тесты же побочное явление.

Відповісти

Підтримати

Nobody 04.02.2010 08:58

> И время, потраченное на качество, окупается.
А оно всегда оплачивается? В суровых реалиях беспощадного аутсорса...

В продуктовых компаниях это время тоже даалеко не всегда оплачивается. Но в подавляющем большинстве случаев окупается.

Впрочем, это уже тема совсем другого холивора:)

Відповісти

Підтримати

Grez 04.02.2010 07:16

2 Аноним
Если времени на это дело не выделяют, заставлять не заставляют, оплачивать не оплачивают, а вы и сами болт на все ложили. То не пешите просто, какие проблемы?

Толстенное трололо, ей богу.

Відповісти

Підтримати

anonymous 04.02.2010 06:56

to Aноним

А кто вам сказал что функциональные и интеграционные тесты не пишутся и не используются? Очень даже все пишится, но только это уже прерогатива тестеров которые являются следующим звеном в выпуске продукта. В принципе если вдаватсья в полемику то мы можем насчитать около дюжини различный видов тестов, вопрос ведь не в этом, а в том что юнит тесты в наше время уже почти как must have для девелоперов.

Відповісти

Підтримати

Valeriy Zamaraiev (junior lisper) 03.02.2010 21:14

Хм, если видишь заранее, что не успеваешь в поставленные сроки — так об этом надо говорить сразу! И не брать на себя ответственность, а потом колбасить до ночи. Если просто ошибся в оценке и/или возникли непредвиденные трудности — то на то и менеджмент, чтобы сглаживать последствия. А если довести до:

от именно в этот момент, но не раньше и надо начинать кипешевать. Ставить руководство перед фактом. Пускай чешется. Пускай дает больше людей, времени, пускай повышает зп. пускай отправляет на курсы конференции и тд.

то уже поздно...

И, да, я совсем не адепт ТДД, скорее наоборот, считаю, что лучше потратить это время на перечитывание/перепроверку того, что написал, эффект лучше, особенно если коллеге код показать. Полностью согласен с a2k насчет проверки в т.ч. на синтаксические ошибки. Особенно в условиях цейтнота. Тестирование важно, но ТДД — это вообще мошенническая аббревиатура, testing cannot drive development, имхо.

Відповісти

Підтримати

anonymous 03.02.2010 20:47

> А иначе это как снежный ком — со временем саппорт проблемы заваливают, и ты не можешь делать ничего нового.
Вот именно в этот момент, но не раньше и надо начинать кипешевать. Ставить руководство перед фактом. Пускай чешется. Пускай дает больше людей, времени, пускай повышает зп. пускай отправляет на курсы конференции и тд.

Брать на себя все, писать тесты, бежать впереди паровоза я не собираюсь ибо это всегда себе дороже. Инициатива наказуема, слыхали?

Відповісти

Підтримати

anonymous 03.02.2010 20:44

> Окупается тем, что в последствии на старые задачи не нужно тратить время, и они не отвлекают от новых задач.

Я работать после 18.00 из-за таких вот сверх предусмотрительных товарисчей никогда не собирался и не буду. Если времени на проект выделено стоко, что никакого микроскопа не хватает. А тим лид такой буквоед, что этого ну никак слушать не хочет, то пускай он все эти тесты и пишет. И пускай еще за весь КУа отдел пашет. Может там тоже кто-то «неправ».

Відповісти

Підтримати

Valeriy Zamaraiev (junior lisper) 03.02.2010 20:36

2 Аноним. Окупается тем, что в последствии на старые задачи не нужно тратить время, и они не отвлекают от новых задач. Для меня это очень важно. А иначе это как снежный ком — со временем саппорт проблемы заваливают, и ты не можешь делать ничего нового. В результате спасает только перезагрузка — поменять работу. А насчет суровых реалий аутсорса — если менеджмент систематически недооценивает задачи, то надо с этим что-то делать, обычно все не безнадежно и Йордон хорошо написал по этому поводу.

Відповісти

Підтримати

anonymous 03.02.2010 20:12

> И время, потраченное на качество, окупается.

А оно всегда оплачивается? В суровых реалиях беспощадного аутсорса часто на тесты да и вообще на какуюто архитектуру просто нету времени. Писать или выдумывать что-то поверх того на что тебе выделено время это себе проблем на одно место искать. Да в идеале должны быть тесты, код должен быть подвергнут хорошему рефакторингу, архитектор должен был выдать продуманную и железобетонную архитектуру. Но в реалиях все могли на все это забить. Свалив все на простого кодера и посавив ему 80 человекочасов на выполнение того что по нормальному три месяца как пилить и пилить надо.

Відповісти

Підтримати

anonymous 03.02.2010 20:06

А вот вам пища для ума, опытные или неопытные товарисчи. Вот вы все говорите о юнит тестах. Всякие покусанные тестами на право и налево бездумно по заученному орут, что без юнит тестов никуда. Хорошо. А как насчет функциональных и интеграционных тестов? Без них тоже ведь никуда не дется. Выходит, что если ты не пишешь функциональных и интеграционных тестов, то ты идешь против партии. Всем срочно начать дописывать функциональные и интеграционные тесты.

Відповісти

Підтримати

a2k 03.02.2010 19:56

Я считаю, что это необходимость, причем проверять нужно не только на логические, но и на синтаксически ошибки. Конечно, последние тривиально находятся компилятором или интерпретатором, но стремление писать код так, чтобы он компилировался с первого раза, позволяет не терять концентрацию и повышает шансы того, что во время просмотра вы обнаружите не только забытую точку с запятой, но и более серьезные проблемы.

Відповісти

Підтримати

Valeriy Zamaraiev (junior lisper) 03.02.2010 19:06

ИМХО программисту для начала надо понять, осознать, что выдавать код с как можно меньшим количеством проблем выгодно лично для него. И время, потраченное на качество, окупается. Это для начала. Замечать ошибки в спеках и заданиях, и эскалировать вопрос наверх тоже выгодно, чтобы не делать дурную работу. Все остальное сам поймет, если моск есть. Качества можно разными способами добиваться. Если не доходит, надо на саппорте поработать чуток. Отдельным уникумам, которые меняют работу каждые полгода-год, оставляя предыдущей конторе головняк, на это, конечно, понадобятся долгие годы.

Відповісти

Підтримати

flyman 03.02.2010 12:07

Ти суслика видиш? -Ні.

От бач, але він є.

В идеале тестеры должны доказывать что в программе нет ошибок, а не говорить «программисту» где он забыл подумать.

Тестування це не є один із способів індуктивного пізнання програми із витікаючими звідси недоліками.
Максимум, можуть показати будь-які тести, це те що «прояви помилок не виявлені».
Але це не означає, що помилок нема.
Як на мене, як писати код виріується не прогером і що робити з помилками.
Як писати код — має буути дока з правилами написання коду: погодження назв, відступи і т.п, ворнінги, нотіси, і т.п...

Я для цього QM, тобто він дає діагнноз, креш, не відповідність специфікації, фіча-реквест...

Я придерживаюсь другого мнения, и считаю, что если программист не пишет тест-юниты к своему коду, и знает, что пока еще допускает много ошибок, он должен сам тестировать то, что пишет, и наличие кучи ошибок говорит не о неправильном подходе к тестированию, а о кривых руках программиста...

~~О вкусах не спорят~~Про методології не сперечаються.
Якщо на проекті прийнято тест-драйвен підхід, роблять відповідно до нього.
Є різні напрями ПЗ і вартість виявлення помилок на етапі розробки і прояву помилок при експлуатаціїї різна.

Джуну не вирішувати як кодити і що робити (копать от забора до обеда), хоча ніхто йому не заважає вивчати «природу багів» і розвиватися читаючи літерату і переймаючи досвід.

Відповісти

Підтримати

anonymous 03.02.2010 10:57

To Nagheenanajar:
Приношу свои извинения, не правильно понял сути Вашего высказывания.:)

Мы и сами себе сочувствуем.:)

Відповісти

Підтримати

Grez 03.02.2010 09:17

Тестирование разное бывает.
Тестирование бизнес-логики как правило «дешевле» и «эффективнее» проводить силами тестеров.

Со стороны программистов эффестивно использовать юнит-тесты (или дебаг) для того чтобы определить работает ли написанный код.

Відповісти

Підтримати

anonymous 03.02.2010 09:16

Мурзик, суть моего высказывания было не про отношение тестеров к работе, а суть их работы.

Если у вас тестеры заняты bulk импортом ошибок в багтреккинг — я вам сочуствую.

Відповісти

Підтримати

anonymous 03.02.2010 08:55

Тестеры наоборот должны доказывать, что в программе есть ошибки. Первая аксиома для тестера: «в любой программе есть хотя бы одна ошибка».

Відповісти

Підтримати

anonymous 03.02.2010 08:37

Я вот работаю с людьми которые считают, что ошибки должны находить пользователи.
Любая модель может работать, но чем позже ошибка найдена тем дороже ее фикс.

В идеале тестеры должны доказывать что в программе нет ошибок, а не говорить «программисту» где он забыл подумать.

Відповісти

Підтримати

Злата 03.02.2010 08:27

спасибо всем, Макконелла читаю, считаю что это must have.

Відповісти

Підтримати

anonymous 03.02.2010 07:57

опытные товарищи скажут тебе следующее.

Писать качественный код или не качественный, с юнит тестами или без них, с код кавередж или без него это дело сугубо личное каждого программиста. Просто в большинстве ситуаций там где этот программист будет работать, задача считается выполненой если все этапы ее так сказать создания были выполнены. И одним из этапов это есть test что подразумевает выполнение всех юнит тестов для написанного когда, в противном случае задачу (не написаный код) рассматривают как незваершенной, а значит в продакшен она просто не идет и программист просто не может сказать что он выполнил свою работу. Все просто.

Відповісти

Підтримати

anonymous 03.02.2010 07:11

точно

Відповісти

Підтримати

anonymous 03.02.2010 06:43

Начните свою карьеру с прочтения книги «Совершенный код» Стива Макконнелла. Там есть ответы и на этот, и на сотни других вопросов, которые у Вас скоро возникнут.

P.S. Ваш коллега напоминает чукчу из анекдота, который «чукча не читатель, чукча — писатель».:)

Відповісти

Підтримати

Проверять код на наличие ошибок — необходимость или излишество?

26 коментарів

Підписатись на коментарі