В чём сложность поддержки большого проекта?

← →
Пит (2013-06-01 12:55) [0]

В чём сложность поддержки большого проекта?

Программист: ну представь, что ты писатель и поддерживаешь проект «Война и мир». У тебя ТЗ — написать главу как Наташа Ростова гуляла под дождём по парку. Ты пишешь «шёл дождь», сохраняешь, вылетает сообщение об ошибке «Наташа Ростова умерла, продолжение невозможно». Почему умерла? Начинаешь разбираться. Выясняется, что у Пьера Безухова скользкие туфли, он упал, его пистолет ударился о землю и выстрелил в столб, а пуля от столба срикошетила в Наташу. Что делать? Зарядить пистолет холостыми? Поменять туфли? Решили убрать столб. Получаем сообщение «Поручик Ржевский умер.» Выясняется, что он в следующей главе облокачивается о столб, которого уже нет…

(c) из интернета

← →
Pavia © (2013-06-01 12:58) [1]

:-)

← →
Юрий Зотов © (2013-06-01 13:34) [2]

Да, улыбнуло, спасибо.

Вероятно, программа использует COM, поскольку поручик Ржевский - это объект из другого приложения.
:o)

← →
Rouse_ © (2013-06-01 14:10) [3]

Забавно :)

← →
DVM © (2013-06-01 19:46) [4]

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

← →
Rouse_ © (2013-06-01 20:04) [5]

> DVM © (01.06.13 19:46) [4]
> Тестами надо проект покрывать и как можно гуще, тогда поддержка
> будет проще.

Тестами можно покрыть только бизнес-логику (в большинстве своем).
Как пример вот тебе мои основные задачи:
1. Криптографический движок - че его тестировать, он либо работает либо нет.
2. VM на базе машины тьюринга - как тестировать будем?
3. Пять подсистем защиты данных основанных на собственном менеджере памяти, две из которых драйверные, которые в юниттесты ну вообще никак не вынести.
4. Куча графических контролов самописок (а их-то как тестить?)
5. Система контроля целостности ПО (8 различных способов начиная с цифровой подписи) - это как тестить?

Jack128 тоже великий любитель юниттестирования. Меня периодически подбивает на это дело, но я ему выкатываю список задач и как-то все это быстро забывается.

← →
Pavia © (2013-06-01 20:13) [6]

Было бы желание а тесты сделать можно. Правда насколько я понимаю тесты нужны в основном для проверки качества работы программиста, а не его кода.

← →
Юрий Зотов © (2013-06-01 20:24) [7]

> Pavia © (01.06.13 20:13) [6]

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

:o)

← →
Rouse_ © (2013-06-01 20:28) [8]

> Pavia © (01.06.13 20:13) [6]

> - Коллега, и как вам реципиент?
> - Программист хороший, но код... Можно сказать что он экстремал.

← →
Пит (2013-06-01 20:36) [9]

> Jack128 тоже великий любитель юниттестирования

куда, кстати, Жэку дели? А то че он пропал...

← →
Rouse_ © (2013-06-01 20:40) [10]

> Пит (01.06.13 20:36) [9]
> куда, кстати, Жэку дели? А то че он пропал...

В Турцию выслали на 2 недели :)

← →
Макс Черных (2013-06-01 20:42) [11]

> В чём сложность поддержки большого проекта?

В том, что в этот процесс вмешиваются индивидумы ничего в нем не понимающие. Для примера, не знающие, что
1. Кремниевый пистолет времен Н.Ростовой под дождем не выстрелит.
2. От падения он не выстрелит и подавно, ибо если он со взведенным курком, то при падении порох с запальной площадки высыпется, а если с невзведенным - то и так понятно.
3. Пули тогда были свинцовые безоболочечные. Такие практически никогда не дают рикошета, при котором сохраняется достаточная убойная сила пули.
4. Столбы, за очень редким исключением тогда все были деревянные. Чтобы от деревяшки свинец срикошетил и убил - это из области фантастики.

:)

← →
Пит (2013-06-01 21:21) [12]

Удалено модератором

← →
Пит (2013-06-01 21:23) [13]

Удалено модератором

← →
Rouse_ © (2013-06-01 21:23) [14]

Удалено модератором

← →
Пит (2013-06-01 21:24) [15]

Удалено модератором

← →
Rouse_ © (2013-06-01 21:25) [16]

Удалено модератором

← →
Пит (2013-06-01 21:28) [17]

Удалено модератором

← →
Rouse_ © (2013-06-01 21:29) [18]

Удалено модератором

← →
Юрий Зотов © (2013-06-01 21:31) [19]

> и с их помощью вылавливает свои же баги.

А потом пишет тесты тестов, чтобы выловить баги и в тестах тоже.
:o)

PS
1. Нанести шампунь на волосы.
2. Вспенить.
3. Смыть.
4. Повторить.
:o)

← →
Kerk © (2013-06-01 21:32) [20]

> Rouse_ © (01.06.13 20:04) [5]

> 1. Криптографический движок - че его тестировать, он либо
> работает либо нет.
> 2. VM на базе машины тьюринга - как тестировать будем?
> 3. Пять подсистем защиты данных основанных на собственном
> менеджере памяти, две из которых драйверные, которые в юниттесты
> ну вообще никак не вынести.
> 4. Куча графических контролов самописок (а их-то как тестить?)
> 5. Система контроля целостности ПО (8 различных способов
> начиная с цифровой подписи) - это как тестить?
>
> Jack128 тоже великий любитель юниттестирования. Меня периодически
> подбивает на это дело, но я ему выкатываю список задач и
> как-то все это быстро забывается.

Попроси его как-нибудь на досуге тебе объяснить, что такое юнит-тестирование. Похоже, проблема именно с этим :)

← →
Rouse_ © (2013-06-01 21:38) [21]

> Юрий Зотов © (01.06.13 21:31) [19]

- «СЕПУЛЬКИ — важный элемент цивилизации ардритов с планеты Энтеропия. (см. СЕПУЛЬКАРИИ)». - «СЕПУЛЬКАРИИ — устройства для сепуления (см. СЕПУЛЕНИЕ)». - «СЕПУЛЕНИЕ — занятие ардритов с планеты Энтеропия (см.СЕПУЛЬКИ)».
© Станислав Лемм, «Звёздные дневники Ийона Тихого», путешествие четырнадцатое :)

← →
Rouse_ © (2013-06-01 21:39) [22]

> Попроси его как-нибудь на досуге тебе объяснить, что такое
> юнит-тестирование. Похоже, проблема именно с этим :)

Он мне девятый год это обьясняет :)

← →
Пит (2013-06-01 21:42) [23]

Да, мистер Джек любит эти тесты. Он даже в свое время, кажется, понял идеологию TDD: http://goo.gl/Y3NxH

Там еще был ролик такой забавный, где показывалось как в VS студии делать TDD...

На мой взгляд - *%%*№ какой-то. Или я тупой, а от последней мысли - грустно.

← →
Rouse_ © (2013-06-01 21:50) [24]

> На мой взгляд - *%%*№ какой-то. Или я тупой, а от последней
> мысли - грустно.

Не парься, не ты один.
Особенно радует хотелки делать юнит тесты, о которых забыли почему-то, в предрелизном состоянии. Сидишь и думаешь, щас программист, вместо правки тикетов, коих куча, варганит юнит-тест, потом часа три его будет отлаживать, потом будет править код класса ибо он не встраивается в систему юнитеста, потом к концу дня скажет что все вроде как норм и ура, а ведь завтра уже релиз и тикеты-то не закрыты. А для них нужно писать код, для которого нужно писать юнит тест, который нужно отлаживать...
Расстрелял-бы :)

← →
Kerk © (2013-06-01 21:55) [25]

> Rouse_ © (01.06.13 21:39) [22]
>
> > Попроси его как-нибудь на досуге тебе объяснить, что такое
> > юнит-тестирование. Похоже, проблема именно с этим :)
>
> Он мне девятый год это обьясняет :)

Плохо наверно объясняет :)
Нет никакой связи между задачей и возможность/невозможностью разбития решения на небольшие независимые части для их тестирования. Другое дело, что если код написан без учета необходимости его тестировать, то покрыть его тестами будет очень сложно. Видимо, это Жеку и останавливает.

TTD надо воспринимать как подход к проектированию. И довольно неплохой подход, надо сказать.

← →
Алканавт расправил плечи (2013-06-01 22:02) [26]

> Rouse_ © (01.06.13 21:38) [21]
Азохэн вэй… Ну уж от тебя непонимание разницы цикла и рекурсии не ожидал %-)

← →
Пит (2013-06-01 22:10) [27]

> И довольно неплохой подход, надо сказать.

чем он хороший то? Только с точки зрения удобства тестирования)

Я вообще не понимаю автоматических тестов. Только если там мат. алгоритмы какие-то и типа того. Как можно автоматически протестировать современное приложение? Черт его знает, это фикция на мой взгляд, деньги попилить.

Пока что лучше тестировщиков в виде адекватных людей я не знаю.

← →
Kerk © (2013-06-01 22:45) [28]

> Пит (01.06.13 22:10) [27]
>
> > И довольно неплохой подход, надо сказать.
>
> чем он хороший то?

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

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

Но проектирование это ладно. Вернемся к тестам. Аргументы против юнит-тестов всегда те же самые, что и против статической типизации. Задумайтесь над этим. "Лишний код писать, да зачем он нужен, я и так все вижу, у меня все работает, если что, тестеры багу найдут".

Если вы понимаете, зачем нужна статическая типизация, то поймете и зачем нужны юнит-тесты.

Если вывернуть юнит-тесты наизнанку и взглянуть на них как на такую кустарную (в связи с убогими возможностями языка) форму контрактов (т.е. design-by-contract), то все выглядит еще интереснее. Некоторые теоретики computer science (могу вспомнить название книжки, если интересно) рассматривают контракты (точнее их математические корни - тройки Хоара) как более строгую систему статической типизации.

Так что, если о неудобности или неприменимости тестов в конкретном случае еще можно говорить, то об их ненужности в целом - несколько преждевременно.

> Пока что лучше тестировщиков в виде адекватных людей я не
> знаю.

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

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

← →
Пит (2013-06-02 01:04) [29]

> Есть такая штука - декомпозиция. Программирование в основном
> в этом и заключается

по-моему, ты фигню сказал. Прошу воспринять это мнение со всем уважением.

> Так вот TTD заставляет думать о грамотной декомпозиции,
> а не писать код абы как.

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

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

Иными словами, данная методика TDD не ведет напрямую к практике декомпозирования (надеюсь быть правильно понятым), просто её реализация проще в такой методологии. Но есть и еще куча моментов, которые будут упрощены, если использовать такой подход. То есть, если совсем по-другому сказать, то данная тактика проектирования к тестирования вообще отношения не имеет. Если ты не можешь объять необъятное - то разбей это на объятные кусочки и действуй. Логично - не спорю. Но причем тут тестирование? Просто в тестировании это правило - также действует, вот и всё. Имхо.

← →
Пит (2013-06-02 01:15) [30]

> Задумайтесь над этим. "Лишний код писать, да зачем он нужен,
> я и так все вижу, у меня все работает, если что, тестеры
> багу найдут".

я не сторонник именно такого подхода. Но когда ресурсы на написание проверочного кода сравниваются с написанием самого функционального кода (а насколько я видел примеры упомянутого TDD - так и происходит) - у меня вызывает недоумение.

> Так что, если о неудобности или неприменимости тестов в
> конкретном случае еще можно говорить, то об их ненужности
> в целом - несколько преждевременно.

ну тут можно спорить бесконечно. Имхо, это сильно привязывается к очень многим факторам, которые нужно учитывать.

Грубо говоря, если пользователей 100 человек - ты можешь забить на многие вещи. В крайней случаем они перезапустят программу раз в полгода, если им так нужно. И шанс натолкнулся на проблему - он один из тысячи.

Если пользователей у тебя миллион - то критерии качества у тебя совершенно другие. В такой ситуации, если в разработке хоть раз возникла ошибка - то на миллионе пользователей она точно проявится. Но опять же - волнует ли проблема тебя зависит от статуса программы, договоренностей с пользователями и бла бла бла.

Имхо, сначала стоило бы договориться о том, что такое "большой" проект.

Юнит-тесты полезны. От того, что их не понимают, они менее полезными не становятся.

> Пит (02.06.13 01:04) [29]

> по-моему, ты фигню сказал. Прошу воспринять это мнение со
> всем уважением.

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

> Иными словами, данная методика TDD не ведет напрямую к практике
> декомпозирования

Ведет. Не только она, естественно. Но она ведет к этому крайне жестко, я бы даже сказал, что местами жестоко.

Собственно, я даже не поленился цитату найти от авторитетного в этом деле человека:

"Ирония TDD состоит в том, что это вовсе не методика тестирования. Это методика анализа, методика проектирования, фактически методика структурирования всей деятельности, связанной с разработкой программного кода" (с) Кент Бек. Разработка через тестирование.

Идея в том, что с помощью тестов разработчик как бы описывает требования к коду, на соответствие которым он в дальнейшем может свой код проверять. То есть сначала это описание требований, затем разработка и уже потом тестирование - и все это TDD.

> Но когда ресурсы на написание проверочного кода сравниваются
> с написанием самого функционального кода (а насколько я
> видел примеры упомянутого TDD - так и происходит) - у меня
> вызывает недоумение.

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

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

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

Собственно, две темы непроизвольно смешались. Юнит-тесты - это конечно не всегда TTD. По-хорошему, разговоры о TTD как подходе к проектированию и о пользе юнит-тестов стоит на две отдельных ветки разделить :)

А ну и про то, что при TDD можно сделать кривую архитектуру и писать суперсложные большие тесты. Можно. У нас такая профессия, что вообще все можно. Но если подходить адекватно, то сложность теста - это уже звоночек проблем в коде. Тесты принято делать простыми, чтобы их корректность можно было проверить глазами, а не писать потом тесты для тестов. :) Это же здорово - вообще иметь такой звоночек. Даже целый будильник :)

поручик Ржевский - это объект из другого приложения

Судя по анекдотам - из того же.

← →
Алканавт расправил плечи (2013-06-02 08:29) [37]

из того же пространства имён

> Игорь Шевченко © (02.06.13 01:28) [32]
> Юнит-тесты полезны.

Бесспорно. Но, как ты и сам часто говоришь об овощах, и как сказал Керк в [33]: "Как и всякий инструмент, юнит-тесты хороши на своем месте и в свое время". Что, надо полагать, тоже бесспорно.

> Пит (01.06.13 22:10) [27]
>
> > И довольно неплохой подход, надо сказать.
>
> чем он хороший то? Только с точки зрения удобства тестирования)
>
> Я вообще не понимаю автоматических тестов. Только если там
> мат. алгоритмы какие-то и типа того. Как можно автоматически
> протестировать современное приложение?

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

> Rouse_ © (01.06.13 20:04) [5]
>

> Тестами можно покрыть только бизнес-логику (в большинстве
> своем).
> Как пример вот тебе мои основные задачи:
> 1. Криптографический движок - че его тестировать, он либо
> работает либо нет.

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

> 2. VM на базе машины тьюринга - как тестировать будем?
> 3. Пять подсистем защиты данных основанных на собственном
> менеджере памяти, две из которых драйверные, которые в юниттесты
> ну вообще никак не вынести.
> 4. Куча графических контролов самописок (а их-то как тестить?
> )
> 5. Система контроля целостности ПО (8 различных способов
> начиная с цифровой подписи) - это как тестить?

Тестить можно отдельные части и все в целом. Задача любого теста - сравнить эталон и реальную работу.
Про тестирование интерфейса грфического ничего сказать не могу - не занимался, есть какая то автоматизация, но я не в курсе, человек имхо быстрее проверит.

В чём сложность поддержки большого проекта? Найти похожие ветки