Pull to refresh

Comments 20

На последней картинке мой мозг почему-то пытается найти слово «зае*ись». Видимо, я совсем испорчен.
Программировал около 10 лет на perl. Большие и нагруженные проекты, в т.ч. в крупных компаниях. Но нигде не было и намека на написание тестов.

С год назад перешел на Ruby on Rails и первое от чего сразу-же протащился — это система автоматического тестирования. Это гениальная технология, которая позволяет избежать тех 80% устранения различных скрытых багов. Если сначала у меня и были некие внутренние предпосылки типа «да зачем нужны эти тесты — только время на них тратить», то сейчас я убежден на 100% что тесты кардинальным образом снижают время на обнаружение и исправление багов в процессе изменения кода. Тестирование позволяет уделять 90% времени именно разработке и только 10% — устранению багов.
Вообще-то у перла есть огромный cpan где у каждого модуля есть модульные тесты, многим языкам ещё нужно поучиться у перла модульному тестированию, а если кто-то этого не умеет, то не перл виноват
Конечно. Я не и говорю что перл виноват. Просто так получилось что при работе с перлом они не использовались.
Хорошо и правдиво написано!
Хотели учиться чему-то новенькому? Первым делом научились писать надёжный код.
Прочитал и появилась надежда на лучшее.
Картинки подобраны отлично:) Вдохновило
красиво написано…
но как этого достичь? ума не приложу.
Вот участвую в проекте: писан разными людьми и в одной программе встречаются классы QString и тут же рядом std::string. В другом модуле классы boost и все это в куче и как-то взаимодействует… А еще местами чистый C…
И все это на встраиваемой платформе с заказным чипом в котором обнаружены ошибки которые не исправить… И местами нужны «подпорки».
А как делать модульные тесты для GUI? вообще не знаю…
А самое ужасное — поддержка совместимости со старыми версиями ПО…
Или вот еще — как отличить баг от фичи? Иной раз мнение разработчика и тестера на этот счет расходится.
Да, у вас сложный случай. Мне сложно что-то вот так посоветовать, не видя проект/код, но рискну предоставить пару общих рекомендаций.

Начните с чего-то попроще, например, с чистой функции или класс. Обычно есть какие-нибудь общие библиотеки функций на проекте, например QstringToString/StringToQString, всякие функции перекодирования из LowEndian в BigEndian и прочая полезная мелочь.

Я бы начал именно с этой мелочи. Рекомедую взять gtest и gmock — это отличные фрэйворки для тестрования C/C++ кода.

Набрав начальный необходимый вес (критическую массу/количество тестов), потом станет значительно легче. Старые тесты будут давать вам основу для написания новых :-), почувствуете почву под ногами :-)

У нас был похожий случай. Часть первых тестов, которые сделали, были очень сложными, и потом мы их просто выкинули и заменили уже «правильными простыми тестами».

Но эти плохие написанные нами тесты дали понимание, как нам правильно тестировать наш проект, которому уже 10 лет и в котором тоже намешана сборная солянка.

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

Вам ГРОМАДНУЮ помощь окажет книга М.Физерса «Эффективная работа с унаследованным кодом» (http://www.ozon.ru/context/detail/id/4311012/).
В ней очень хорошо разбирается старый код на C++.

Желаю вам решиться :-)
А как делать модульные тесты для GUI? вообще не знаю…

Никак. GUI должен тестироваться фреймворками для UI тестирования (Selenium и иже с ним). Задача разработчика состоит в том, чтобы вынести всю не относящуюся к интерфейсу логику в отдельные тестируемые классы (MVC/MVP/MVVM в помощь), и покрывать модульными тестами эти классы.

Или вот еще — как отличить баг от фичи? Иной раз мнение разработчика и тестера на этот счет расходится.

Нужно обратиться к спецификации/продакт оунеру/менеджеру/клиенту/собрать вече. Ошибкой по определению являются две вещи:
— нечто, что работает не так, как описано в спецификации
— нечто, что работает явно ненормально (например, понятно, что если программа стартует два часа — это ненормально)

Ну и плюсую к призыву прочитать Физерса в комментарии выше.
Как-то тут всё у вас по-детски, штаны на лямках.
О подобных вещах написано уже очень и очень много. В частности, считаю неплохой книгу:
Мартин Р. Чистый код. Создание, анализ и рефакторинг == Clean Code: A Handbook of Agile Software Craftsmanship
Можно начать с изучения вот этих листочков: www.planetgeek.ch/wp-content/uploads/2013/06/Clean-Code-V2.pdf
А вы не мешайте высказываться человеку. Он напишет, у него еще раз в голове что-то по полочкам разложится. Кто-то прочитает и вдохновится. И это хорошо.
Почти год пытался приучить коллег работать с тестами. Проводил публичные лекции, объяснял лично, показывал, использовал сам (написал более сотни тестов на разные компоненты, примеров — тьма). Но мои попытки так и не увенчались успехом. В итоге через неделю я перехожу в компанию Y.
До ката неплохо бы вынести притчу (очень понравилась) и коротенько предисторию про компанию погрязшей в г^W коде, убрать про Яндекс и можно каждое утро читать :)
Вот программист, программист, а протом придет манагер и скажет — время=деньги, лабай новую фичу, то работает и ладно, какой рефакторинг еще, подавай мне естимейт на вот это.
Если менеджер не знает про технический долг, он проф.непригоден в it, что стоит донести до него и его руководства.
Предлагаю предложить ему такой гипотетический вариант.

Какой системе вы могли бы передать ответственность за свой палец(согласен, палец жалко — машину :-)), например?

Той, которая пишется с тестами и инспекциями кода или той, которая без тестов и без инспекций?
Да, самое главное — ПЕРЕГОВОРЫ!

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

Можно попробовать пролистать вот эти книжки:
Just Listen: Discover the Secret to Getting Through to Absolutely Anyone(http://www.amazon.com/Just-Listen-Discover-Getting-Absolutely/dp/0814414036)

Becoming a Technical Leader: An Organic Problem-Solving Approach (http://www.amazon.com/Becoming-Technical-Leader-Problem-Solving-Approach/dp/0932633021/ref=sr_1_1?s=books&ie=UTF8&qid=1376559982&sr=1-1&keywords=becoming+a+technical+leader)

Честно говоря — я редко встречал «тупых» людей, непонятых — постоянно.

Имхо, конечно всё.
Немного странно, в начале стать и описываете свой проект как апогей протухшести. Как правило к этому приходят в «неочень качественных» коммандах, какгда расхлябоность сотрудников не позволяет собстно начать: не быдлокодить, думать перед написанием кода, проверять, обсуждать с коллегами…

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

С чего бы это? Как долго они сидели на этом проекте и «ничего не делали» и как быстро они перешли на «грамотную разработку»?
Нас было 5 разработчиков на проекте. Все перешли на разработку с тестами и инспекциями достаточно быстро.

На введение в процесс разработки инспекции кода нам понадобилась 2 недели.

1) а через месяц у нас появился документ codingstyle;
2) весь код стал проходить инспектирование, было как-то стрёмно закомитить непроинспектированный код — это же всегда заметно(если кто-то считает что незаметно — скорей всего, обманывает сам себя);
3) мы стали больше общаться вживую, появились обсуждения разных подходов разработки;
4) стали лучше понимать друг друга, уважение выросло на порядок.

С тестами подольше. В конце концов все переключились на разработку с тестами от одного месяца до полугода. На новый код писали тесты. Делали швы по рекомендациям книги М.Физерса «Эффективная работа с унаследованным кодом» (http://www.ozon.ru/context/detail/id/4311012/).

На те места, где приходилось рефакторить — в обязательном порядке писали тесты. Да, были ошибки, да было непросто, но все мои бывшие коллеги согласны в одном — написание тестов в унаследованном проекте того стоило. Это мнение как самих разработчиков, так и менеджеров проекта, отдела сопровождения, отдела внедрения.

Это же супер: приезжаешь на объект, настраиваешь и уезжаешь (забываешь про него :-)

Не так давно понял одно высказывание по новому.

«Компьютер должен быть продуктивным, а человеку лучше быть эффективным.»

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

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

Имхо, конечно всё.
Sign up to leave a comment.