![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
vakНас всех учили понемногу, чему-нибудь и как-нибудь. В моё время, в середине 80-х обучение программированию сводилось к изложению синтаксиса языка и написанию коротких изолированных задачек. На первом курсе нам давали Алгол и Бейсик, на втором Фортран и Паскаль, на третьем ассемблер (тогда он назывался автокод) и снова Фортран, на четвёртом почему-то опять Фортран, с самого начала.
Собственно программированию не учили совсем. Я имею в виду, как инженерному искусству. Стиль, методы организации программного проекта, автоматическую сборку, управление версиями и прочие премудрости приходилось осваивать самостоятельно. Ковырялся в исходниках Юникса и компилятора PCC, подсматривал у старших товарищей в курчатнике, рылся в ленточках Usenix. Толковых книг не было совсем, а преподаватели с реальным практическим опытом не встречались в природе.
С тех пор много воды утекло, и сейчас есть несколько книжек, учащих реальным приёмам программирования. Вот одна из них: "Modern C++ Programming with Test-Driven Development".
В книжке предлагается метод разработки, основанный на написании небольших тестов - сначала, до собственно функционального кода. Суть метода можно понять из статьи википедии "Разработка через тестирование". Русское название звучит несколько неоднозначно, и я предпочитаю называть метод оригинальным термином TDD.
Кроме TDD есть и другие подходы: BDD, TSD и прочие. Но все большие проекты из моего опыта используют методику "непрерывного" тестирования. Без этого разработка больших продуктов вообще невозможна, ведь внося любое изменение программист нарушает поведение системы. Без набора тестов с хорошим покрытием невозможно определить, насколько допустимо это нарушение.
Для поддержки разработки через тестирование существует несколько пакетов похожей функциональности: Googletest, CppUnit, Catch и другие. Некоторые из них описаны в вышеприведённой книжке. Я по работе использую Googletest, а для самоделок Catch.
В качестве заготовки я приготовил два репозитория (на Гитхабе и на Битбакете) с одним и тем же примером на Си++: вычислением чисел Фибоначчи.
Набор тестов к ней: test_demo.cpp
Запуск тестов выглядит так:
После каждого коммита заходим на вкладку Actions (на Гитхабе) или Pipelines (на Битбакете) и смотрим результаты автоматического тестирования.
Собственно программированию не учили совсем. Я имею в виду, как инженерному искусству. Стиль, методы организации программного проекта, автоматическую сборку, управление версиями и прочие премудрости приходилось осваивать самостоятельно. Ковырялся в исходниках Юникса и компилятора PCC, подсматривал у старших товарищей в курчатнике, рылся в ленточках Usenix. Толковых книг не было совсем, а преподаватели с реальным практическим опытом не встречались в природе.
С тех пор много воды утекло, и сейчас есть несколько книжек, учащих реальным приёмам программирования. Вот одна из них: "Modern C++ Programming with Test-Driven Development".
В книжке предлагается метод разработки, основанный на написании небольших тестов - сначала, до собственно функционального кода. Суть метода можно понять из статьи википедии "Разработка через тестирование". Русское название звучит несколько неоднозначно, и я предпочитаю называть метод оригинальным термином TDD.
Кроме TDD есть и другие подходы: BDD, TSD и прочие. Но все большие проекты из моего опыта используют методику "непрерывного" тестирования. Без этого разработка больших продуктов вообще невозможна, ведь внося любое изменение программист нарушает поведение системы. Без набора тестов с хорошим покрытием невозможно определить, насколько допустимо это нарушение.
Для поддержки разработки через тестирование существует несколько пакетов похожей функциональности: Googletest, CppUnit, Catch и другие. Некоторые из них описаны в вышеприведённой книжке. Я по работе использую Googletest, а для самоделок Catch.
В качестве заготовки я приготовил два репозитория (на Гитхабе и на Битбакете) с одним и тем же примером на Си++: вычислением чисел Фибоначчи.
- https://github.com/sergev/Catch-Actions-Demo
- https://bitbucket.org/serge-vakulenko/catch-pipelines-demo
Набор тестов к ней: test_demo.cpp
Запуск тестов выглядит так:
После каждого коммита заходим на вкладку Actions (на Гитхабе) или Pipelines (на Битбакете) и смотрим результаты автоматического тестирования.
no subject
Date: 2020-08-04 12:29 (UTC)TDD позволяет обнаружить внесённую ошибку сразу. Тогда её легче найти и проще исправить. Это полезно даже при работе в одиночку.
no subject
Date: 2020-08-04 14:13 (UTC)2. Ту задачку я видел. Мысленно мгновенно решил её, вспомнив, что вроде в С есть обязательные константы, означающие максимальные числа того или иного типа - но рассудил, что это, скорее всего, способ слишком топорный, текст получится длинным, и идея теста, возможно, в чём-то более остроумном. Но в любом случае - эта задача не является чем-то выдающимся в плане сложности.
То есть, мой вопрос остаётся с учётом п.1.
Грубо, Борланд С - помните такой? - уже достаточен для чего угодно, если человек работает один. Проблемы начинаются тогда, когда задача - написать что-то, на что производительности одного попросту не хватит, когда придётся либо использовать чужой код, либо писать вместе с кем-то.
no subject
Date: 2020-08-04 15:36 (UTC)Вместе с кем-то приходится писать потому что много писать, и потому что надо много знать разного. Тяжело одному человеку оставаться на переднем крае всего сразу, неизбежна специализация. Хотя сейчас модно это отрицать и даже слово специальное есть, dev ops.
На практике прототипы делаются из готовых кубиков, неоптимально и неэффективно. Если прототип взлетает, компания получает достаточно денег чтобы нанять узких спецов, которые разобьют его на части разумным образом, поделят между собой эти части и построят их заново по правилам. И вот там уже полезен TDD, чтоб отдельные части тестировать, потому что тестировать всё вместе гораздо сложнее и дольше, чем отдельные части.