В книгах в основном пишут про простые приемы, профилактические, например явное преобразование типов, создание ловушек в коде, просто грамотное проектирование и ещё про кучу всяких простеньких приемов. Но с ростом проектов, этого всего уже не хватает, по крайней мере мне. Ошибок много и их причины очень сложно и долго ищутся. Связность кода растет и никак с этим бороться не получается.
Вот, очень хочется узнать, кто какие приемы или т.п. применяет в борьбе с ошибками или вообще в отладке, или на этапе проектирования...
27.03.07 16:17: Перенесено модератором из '.NET' — TK
Здравствуйте, _Mihail, Вы писали:
_M>В книгах в основном пишут про простые приемы, профилактические, например явное преобразование типов, создание ловушек в коде, просто грамотное проектирование и ещё про кучу всяких простеньких приемов. Но с ростом проектов, этого всего уже не хватает, по крайней мере мне. Ошибок много и их причины очень сложно и долго ищутся. Связность кода растет и никак с этим бороться не получается. _M>Вот, очень хочется узнать, кто какие приемы или т.п. применяет в борьбе с ошибками или вообще в отладке, или на этапе проектирования...
Здравствуйте, _Mihail, Вы писали:
_M>В книгах в основном пишут про простые приемы, профилактические, например явное преобразование типов, создание ловушек в коде, просто грамотное проектирование и ещё про кучу всяких простеньких приемов. Но с ростом проектов, этого всего уже не хватает, по крайней мере мне. Ошибок много и их причины очень сложно и долго ищутся. Связность кода растет и никак с этим бороться не получается. _M>Вот, очень хочется узнать, кто какие приемы или т.п. применяет в борьбе с ошибками или вообще в отладке, или на этапе проектирования...
Главное правило: чем раньше ошибка обнаруживается, тем легче ее исправить. Соответственно, плясать надо от этого правила. Именно из этого правила вытекают и ранняя интеграция, и юнит тесты и статическая типизация и прочие полезные в ловле ошибок приемы.
Здравствуйте, _Mihail, Вы писали:
_M>Вот, очень хочется узнать, кто какие приемы или т.п. применяет в борьбе с ошибками или вообще в отладке, или на этапе проектирования...
Языки программирования со статической типизацией и сборкой мусора (например, C#, Nemerle).
Инструменты для поиска ошибок и предупреждений в процессе создания кода (наподобие ReSharper'а).
Комментирование кода.
Code review, в том числе и основанный на автоматическом анализе кода (например, с помощью FxCop).
Рефакторинг. Замена длинных методов короткими, сложных — простыми, запутанных — понятными.
Валидация входных параметров методов и выбрасывание исключений наподобие ArgumentException.
Частое использование конструкций наподобие Debug.Assert для проверки инвариантов и согласованности логики кода.
Отсутствие преждевременной оптимизации, упор на надежность и понятность.
Уменьшение количества нисходящих приведений типов (особенно так называемых "безопасных" — как с оператором as в C#). Их замена на параметрический полиморфизм и pattern matching.
Написание исчерпывающих unit-test'ов (ни одно исправление или улучшение кода не должно происходить без добавления соответствующего теста). Их регулярный автоматический запуск и автоматический контроль покрытости кода.
Здравствуйте, ZevS, Вы писали:
ZS>Здравствуйте, _Mihail, Вы писали:
_M>>В книгах в основном пишут про простые приемы, профилактические, например явное преобразование типов, создание ловушек в коде, просто грамотное проектирование и ещё про кучу всяких простеньких приемов. Но с ростом проектов, этого всего уже не хватает, по крайней мере мне. Ошибок много и их причины очень сложно и долго ищутся. Связность кода растет и никак с этим бороться не получается. _M>>Вот, очень хочется узнать, кто какие приемы или т.п. применяет в борьбе с ошибками или вообще в отладке, или на этапе проектирования...
ZS>Юнит тесты.
Как минимум, регрессионное тестирование (без юнит-тестов и тестов функциональности теоретически можно обойтись) ZS>Постоянный рефакторинг.
Здравствуйте, _Mihail, Вы писали:
_M>В книгах в основном пишут про простые приемы, профилактические, например явное преобразование типов, создание ловушек в коде, просто грамотное проектирование и ещё про кучу всяких простеньких приемов. Но с ростом проектов, этого всего уже не хватает, по крайней мере мне. Ошибок много и их причины очень сложно и долго ищутся. Связность кода растет и никак с этим бороться не получается.
Значит неправильно пишешь с самого начала, просто архитектура неправильная. Иначе бы связность кода не росла. Впрочем, может у тебя что супер сложное, конечно.
Если можешь по написанной программе понять, что она делает без заглядываний в другие файлы, это хорошо.
У меня вот та же проблема, конкретно на C# когда пишу, вот ну немогу написать большое приложение. Постоянно оказывается что что-то забыл, что-то неуклюже написано и просто не укладывается в голове. Дошло до того, что когда мне, после нескольких месяцев C#, пришлось писать на не любимом мной C++ я просто почувствовал себя как в раю
Вообще, когда используешь C# и .NET постоянно используешь сразу несколько компонентов. Обязательно надо что-то куда-то создать, записать, передать интерфейс и т.п. Куча служебных действий, иногда создаётся впечатление, что вернулся в assembler. Всё время думаешь о коде, а не о программе.
Здравствуйте, Gajdalager, Вы писали:
G>Как минимум, регрессионное тестирование (без юнит-тестов и тестов функциональности теоретически можно обойтись) ZS>>Постоянный рефакторинг.
А на основе чего тогда осуществлять регрессионное тестирование? И как проверять, не допущена ли ошибка при рефакторинге?
Нет уж, одно с другим завязано.
V>Главное правило: чем раньше ошибка обнаруживается, тем легче ее исправить. Соответственно, плясать надо от этого правила. Именно из этого правила вытекают и ранняя интеграция, и юнит тесты и статическая типизация и прочие полезные в ловле ошибок приемы.
Почитал про юнит тесты — очень мощная вещь. Только возникают небольшой вопрос. Вот при описании создания юнит тестов всё время используют простенькие примеры, типа функций округления чисел, смены расширения файла и т.п. А вот как поступают в случае тестирования сложных методов, которые помимо входных параметров внутри пользуются какими-нибудь общедоступными объектами (и меняют их), и эти объекты так вот просто для каждого отдельного юнит теста не создашь, а если и создашь, то по времени это будет очень долго. Я так понимаю в этом случае помимо подстановки тестовых параметров в метод, нужно специально конструировать и всю остальную среду приложения в тестовом режиме, одну для всех юнит тестов, а потом тестирование методов проводить не по алфавиту, а писать какой-то "сценарий", учитывающий, что "среда" по мере прохождения тестов будет меняться... так поступают в подобных случаях?
Верно подмечено , но тут и кроется ответ . Если система так сильно связанна , то это ошибки проектирования. Необходимо стремиться к минимальной связанности , а как минимум проектировать модули уже готовые к тестированию
Лично меня пока что спасает "проверки времени выполнения" и Sanity Tests , тесты на основную функциональность.
вот тут пишут про юнит-тесты, но они хороши для бизнес-логики и прикладных программ.
если вы системный программист, и разрабатываете _систему_, покрыть ее простыми тестами невозможно.
Здравствуйте, _Mihail, Вы писали:
_M>Связность кода растет и никак с этим бороться не получается.
Значить, кто-то когда-то и неизвестно зачем лазит куда ему не надо.
Лекарство — плотные code review на потенциальних виновниках. С последующей профилактической (или пенициарной?) беседой. А вообще, "cvs annotate" выдумал не идиот...
Или же, ваш дизайн прогнивает. Пора рефакторить.
Если есть на это время — вы счастливчик.
Если нет — мне вас жалко.
__________
16.There is no cause so right that one cannot find a fool following it.
Здравствуйте, _Mihail, Вы писали:
V>>Главное правило: чем раньше ошибка обнаруживается, тем легче ее исправить. Соответственно, плясать надо от этого правила. Именно из этого правила вытекают и ранняя интеграция, и юнит тесты и статическая типизация и прочие полезные в ловле ошибок приемы.
_M>Почитал про юнит тесты — очень мощная вещь. Только возникают небольшой вопрос. Вот при описании создания юнит тестов всё время используют простенькие примеры, типа функций округления чисел, смены расширения файла и т.п. А вот как поступают в случае тестирования сложных методов, которые помимо входных параметров внутри пользуются какими-нибудь общедоступными объектами (и меняют их), и эти объекты так вот просто для каждого отдельного юнит теста не создашь, а если и создашь, то по времени это будет очень долго. Я так понимаю в этом случае помимо подстановки тестовых параметров в метод, нужно специально конструировать и всю остальную среду приложения в тестовом режиме, одну для всех юнит тестов, а потом тестирование методов проводить не по алфавиту, а писать какой-то "сценарий", учитывающий, что "среда" по мере прохождения тестов будет меняться... так поступают в подобных случаях?
Здравствуйте, degor, Вы писали:
D>вот тут пишут про юнит-тесты, но они хороши для бизнес-логики и прикладных программ. D>если вы системный программист, и разрабатываете _систему_, покрыть ее простыми тестами невозможно.
Это почему? В чем проблема тестировать куски системы (например алгоритмы, состояния ошибки)и проводить integration тесты уже системы в целом (например с использованием реального железа или устройства, если это допустим дрова)? Ибо без тестов нельзя быть уверенным ни в чем, правда с тестами тоже
Здравствуйте, 0xDEADBEEF, Вы писали:
DEA>Лекарство — плотные code review на потенциальних виновниках. С последующей профилактической (или пенициарной?) беседой.
code review — это очень полезно, но с упором найти и устранить проблемы,
а не поучить "виновников". Вменяемые люди, которых все же большинство,
сами видят что к чему и делают выводы, когда видят результаты review.
Если есть какие-то косяки, которые повторяются постоянно,
то надо разбираться с причинами. Причины могут и не зависить от конкретного кодера.
В общем, устраивать детский сад с профилактическими беседами после
review — это не конструктивно, а часто и вообще вредно.
Здравствуйте, degor, Вы писали:
D>вот тут пишут про юнит-тесты, но они хороши для бизнес-логики и прикладных программ. D>если вы системный программист, и разрабатываете _систему_, покрыть ее простыми тестами невозможно.
Здравствуйте, nikov, Вы писали:
N>Языки программирования со статической типизацией и сборкой мусора (например, C#, Nemerle). N>Инструменты для поиска ошибок и предупреждений в процессе создания кода (наподобие ReSharper'а). N>Комментирование кода. N>Code review, в том числе и основанный на автоматическом анализе кода (например, с помощью FxCop). N>Рефакторинг. Замена длинных методов короткими, сложных — простыми, запутанных — понятными.
Я бы еще уточнил, что важно просто причесывать код. Не сикрет, что когда пишешь конерктный участок, то порой важно просто продавить решение, чтобы онозаработало.
Важно после этого взять и "причесать" код так чтобы он был не только работающим, но и понятным, простым... короче как ты сказал.
N>Валидация входных параметров методов и выбрасывание исключений наподобие ArgumentException. N>Частое использование конструкций наподобие Debug.Assert для проверки инвариантов и согласованности логики кода. N>Отсутствие преждевременной оптимизации, упор на надежность и понятность. N>Уменьшение количества нисходящих приведений типов (особенно так называемых "безопасных" — как с оператором as в C#). Их замена на параметрический полиморфизм и pattern matching. N>Написание исчерпывающих unit-test'ов (ни одно исправление или улучшение кода не должно происходить без добавления соответствующего теста). Их регулярный автоматический запуск и автоматический контроль покрытости кода.
+ Я бы добавил бы это список:
1. Конечно же отладчик и другие средства интерактивной отладки (Imediate, редаткриование кода без остановки программы и т.п.).
2. Продумывание реализуемых подзадач. Потому как многие привыкая на простых задачках лепить все по наитию поступают так же и с более сложными вещами.
3. Применение библиотек и другие способы абстрагирования. В прочем уменьшение исходников это примерно о том же но другими словами.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, prVovik, Вы писали:
V>Главное правило: чем раньше ошибка обнаруживается, тем легче ее исправить. Соответственно, плясать надо от этого правила. Именно из этого правила вытекают и ранняя интеграция, и юнит тесты и статическая типизация и прочие полезные в ловле ошибок приемы.
Еще лучше просто их не допускать. Отсюда вытекают: планирование, проектирование, применение билилотек, самосовершенствование, примерение паттернов проектирования...
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, aka50, Вы писали:
A>Здравствуйте, degor, Вы писали:
D>>вот тут пишут про юнит-тесты, но они хороши для бизнес-логики и прикладных программ. D>>если вы системный программист, и разрабатываете _систему_, покрыть ее простыми тестами невозможно.
A>Это почему? В чем проблема тестировать куски системы (например алгоритмы, состояния ошибки)и проводить integration тесты уже системы в целом (например с использованием реального железа или устройства, если это допустим дрова)? Ибо без тестов нельзя быть уверенным ни в чем, правда с тестами тоже
не надо путать тесты и юнит-тесты. последние — одна из практик xp, которая, на мой взгляд, имеет очень ограниченное применение. о чем я и сказал
проблема тестирования системы в том, что мясо приходится на взаимодействие объектов, а не на сами объекты, простые и корректно выполняющие свои контракты.
Здравствуйте, bkat, Вы писали:
B>Здравствуйте, degor, Вы писали:
D>>вот тут пишут про юнит-тесты, но они хороши для бизнес-логики и прикладных программ. D>>если вы системный программист, и разрабатываете _систему_, покрыть ее простыми тестами невозможно.
B>Покрывай из сложными тестами. B>В чем проблема?
свежая мысль в сабже. мой поинт в том, что есть системы, использование для которых юнит-тестов неэффективно, так как основная сложность заключается в процессах использующих эти объекты и во взаимодействии.добавьте сюда асинхронность и многопоточность.
Здравствуйте, _Mihail, Вы писали:
_M>Почитал про юнит тесты — очень мощная вещь. Только возникают небольшой вопрос. Вот при описании создания юнит тестов всё время используют простенькие примеры, типа функций округления чисел, смены расширения файла и т.п. А вот как поступают в случае тестирования сложных методов, которые помимо входных параметров внутри пользуются какими-нибудь общедоступными объектами (и меняют их), и эти объекты так вот просто для каждого отдельного юнит теста не создашь, а если и создашь, то по времени это будет очень долго.
Вопрос очень правильный. Действительно, прогон полного набора тестов на сложной системе может занимать несколько часов. В идеале, тесты должны полностью воссоздавать все окружение, в котором работает система. Например, если используется база данных, то хорошие тесты должны уметь создать ее "с нуля", прогнав необходимые скрипты, заполнить данными и "погонять" в разных режимах (можно подумать, что это излишние требования, но зато, если завтра Вам понадобится поднять новый продакшн-сервер, Вы можете быть уверены, что для этого достаточно просто запустить скрипт).
При активной разработке желательно, чтобы билд собирался и тестировался в автоматическом режиме каждый час (это приблизительная оценка, которая на самом деле очень зависит от типа проекта). К сожалению, прогон "тяжелых" тестов может ограничить количество билдов до двух раз в сутки. И о проблеме, внесенной утром, разработчики могут узнать только в конце рабочего дня, когда уже может не хватать времени на адекватное ее исправление. Чтобы этого избежать, можно запускать настроить запуск полного набор тестов лишь один раз в сутки (например, ночью), а в течение рабочего дня запускать его облегченный вариант, который может отработать меньше чем за час, и оперативно отловить основные проблемы.
Ну и конечно, желательно иметь достаточно шустрый билд-сервер.
