Здравствуйте, jazzer, Вы писали:
J>Я предпочитаю работать снизу вверх. J>Т.е. смотрю на задачу и думаю, чем придется заниматься коду в процессе ее решения. J>И пишу простые маленькие компоненты, которые изолированно занимаются именно этими вещами. J>Естественно, с тестами.
J>А ТДД в этом смысле — это немного наоборот, сверху вниз
Почему ТДД наоборот? Кто мешает писать тесты маленьких компонент перед маленькими компонентами? А потом писать тесты подсистем непосредственно перед их сборкой из маленьких компонент?
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, gandjustas, Вы писали:
J>>>А идеология "сначала тесты, потом код", имхо — это уже экстремизм: слишком многое может поменяться в процессе написания этого самого кода. G>>Многое меняется в процессе написания потому что заранее неизвестно как оно должно работать. Я верю что есть зубры, которые проводят детальное проектирование в голове, а потом пишут с первого раза нужный код, но таких не встречал. G>>Именно поэтому тесты и пишутся перед кодом — чтобы понять как оно будет работать.
J>а как насчет того, что ты не учел 50 взаимосвязей, из-за который весь твой тестирующий код не имеет смысла, просто потому что, скажем, невозможно в заданном порядке сконструировать объекты, по каким угодно причинам?
В какой момент их можно не учесть в таком количестве? Если сначала пишутся тесты, а потом код, то откуда возьмутся эти 50 взаимосвязей?
J>Я несколько раз пробовал подступиться в ТДД, и каждый раз напарывался на это.
Я с тех пор как применяю TDD пользуюсь IoC-контейнерами, которые разраливают управление временем жизни объектов. Кроме того кучи взаимосвязей из воздуха не возникают.
J>Я предпочитаю работать снизу вверх. J>Т.е. смотрю на задачу и думаю, чем придется заниматься коду в процессе ее решения. J>И пишу простые маленькие компоненты, которые изолированно занимаются именно этими вещами. J>Естественно, с тестами.
Отлично, что на данном этапе мешает написать сначала тесты?
J>И когда ты доходишь до момента, когда минимальные сущности уже не выделяются, оказывается, что собрать требуемую подсистему из готовых компонентов сравнительно просто и быстро, так что ты можешь более-менее свободно экспериментировать, и главное, что эти компоненты потому будут использоваться в других местах проекта, уже будучи оттестированными.
J>А ТДД в этом смысле — это немного наоборот, сверху вниз, потому что ты пишешь тесты сразу для подсистемы, и то, какая будет архитектура этой подсистемы, что в ней универсального и переиспользуемого, остается за скобками — главное ведь, чтоб тесты сходились...
Это сильно догматичный TDD подход, который любят толкать агилисты. Есть более прагматичный подход, когда архитектура и высокоуровневы дизайн выполняются как обычно — определяются интерфесы, придумываются слои, итд. А детальный дизайн выполняется с помощью TDD.
Здравствуйте, Mystic, Вы писали:
M>Так и получается. Только UNIT-тестирование сводится к разработке внешнего приложения, которое читает последовательно файлы из парки, парсит их на предмет данных и результатов, данные загоняет в алгоритм и проверяет результат...
Это неправильный подход. При правильном подходе тест кормит алгоритму (через моки/стабы) некий заранее сформированный инпут, и затем сравнивает результат с тем, который должен быть. Причём тесты пишутся идеально просто в случае, если используется IoC, ибо тогда ничего не стоит вместо компонента, "который читает последовательно файлы из папки" (С), подсунуть мок, который вернёт то, что надо — да хоть захардкоженный прямо в тесте инпут. Алгоритмы — это именно то, что в 99.(9)% случаев отлично поддаётся юнит-тестированию.
Mystic пишет:
> Так и получается. Только UNIT-тестирование сводится к разработке > внешнего приложения, которое читает последовательно файлы из парки, > парсит их на предмет данных и результатов, данные загоняет в алгоритм и > проверяет результат...
Это уже не Unit-тестирование.
Это — просто тестирование. Unit-тест — это когда разбирают программу
по винтикам, и каждый винтик проверяют. Потом собирают. Это не значит,
что три собранных винтика проверить -- это не Unit-тест. Но ТОЛЬКО всё вместе
тестировать — это простое тестирование, регрессионное, функциональное и т.п.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, jazzer, Вы писали:
J>>Здравствуйте, gandjustas, Вы писали:
J>>>>А идеология "сначала тесты, потом код", имхо — это уже экстремизм: слишком многое может поменяться в процессе написания этого самого кода. G>>>Многое меняется в процессе написания потому что заранее неизвестно как оно должно работать. Я верю что есть зубры, которые проводят детальное проектирование в голове, а потом пишут с первого раза нужный код, но таких не встречал. G>>>Именно поэтому тесты и пишутся перед кодом — чтобы понять как оно будет работать.
J>>а как насчет того, что ты не учел 50 взаимосвязей, из-за который весь твой тестирующий код не имеет смысла, просто потому что, скажем, невозможно в заданном порядке сконструировать объекты, по каким угодно причинам? G>В какой момент их можно не учесть в таком количестве? Если сначала пишутся тесты, а потом код, то откуда возьмутся эти 50 взаимосвязей?
При написании собственно кода
Невозможно все учесть до того, как код написан.
Вдруг выяснится, что в конкретный метод надо передавать еще пару параметров, и что надо еще пару объектов создать для правильного окружения, и т.д. и т.п.
Хотя 50 — это я, наверное, загнул
J>>Я несколько раз пробовал подступиться в ТДД, и каждый раз напарывался на это. G>Я с тех пор как применяю TDD пользуюсь IoC-контейнерами, которые разраливают управление временем жизни объектов. Кроме того кучи взаимосвязей из воздуха не возникают.
Ну если эти контейнеры только для тестов — то да.
А так — выбор контейнера все-таки должен определяться задачей, а не нуждами тестов
В любом случае, это не принципиальный момент, просто неудобство, которое приводит к переписыванию теста, если он был написан слишком рано.
J>>Я предпочитаю работать снизу вверх. J>>Т.е. смотрю на задачу и думаю, чем придется заниматься коду в процессе ее решения. J>>И пишу простые маленькие компоненты, которые изолированно занимаются именно этими вещами. J>>Естественно, с тестами. G>Отлично, что на данном этапе мешает написать сначала тесты?
Да ничего не мешает. Можешь считать это моими личными предпочтениями.
Я предпочитаю сначала вчерне набросать рабочий код, который что-то делает в более-менее реальном окружении (в процессе этого может много чего поменяться по сравнению с первоначальной идеей, просто потому что какие-то новые идеи придут в процессе, например, поменяется интерфейс или твой модуль распадется еще на пару модулей), потом, когда архитектура и интерфейс устоялись, написать к нему тесты и уже с их помощью отполировать код для состояния, когда можно коммитить.
J>>И когда ты доходишь до момента, когда минимальные сущности уже не выделяются, оказывается, что собрать требуемую подсистему из готовых компонентов сравнительно просто и быстро, так что ты можешь более-менее свободно экспериментировать, и главное, что эти компоненты потому будут использоваться в других местах проекта, уже будучи оттестированными.
J>>А ТДД в этом смысле — это немного наоборот, сверху вниз, потому что ты пишешь тесты сразу для подсистемы, и то, какая будет архитектура этой подсистемы, что в ней универсального и переиспользуемого, остается за скобками — главное ведь, чтоб тесты сходились... G>Это сильно догматичный TDD подход, который любят толкать агилисты. Есть более прагматичный подход, когда архитектура и высокоуровневы дизайн выполняются как обычно — определяются интерфесы, придумываются слои, итд. А детальный дизайн выполняется с помощью TDD.
В такой формулировке, и с оговоркой выше — согласен.
Перефразируя Эйнштейна, тесты должны писаться настолько рано, насколько это возможно, но не раньше.
Здравствуйте, samius, Вы писали:
S>Здравствуйте, jazzer, Вы писали:
J>>Я предпочитаю работать снизу вверх. J>>Т.е. смотрю на задачу и думаю, чем придется заниматься коду в процессе ее решения. J>>И пишу простые маленькие компоненты, которые изолированно занимаются именно этими вещами. J>>Естественно, с тестами.
J>>А ТДД в этом смысле — это немного наоборот, сверху вниз S>Почему ТДД наоборот? Кто мешает писать тесты маленьких компонент перед маленькими компонентами? А потом писать тесты подсистем непосредственно перед их сборкой из маленьких компонент?
Потому что это будет не TDD. В TDD код пишется только тогда, когда его необходимость покажут тесты. Т.е. пока тесты для подсистем не покажут необходимость маленьких компонент — маленьких компонент не будет.
Здравствуйте, Константин Б., Вы писали:
КБ>Здравствуйте, samius, Вы писали:
S>>Почему ТДД наоборот? Кто мешает писать тесты маленьких компонент перед маленькими компонентами? А потом писать тесты подсистем непосредственно перед их сборкой из маленьких компонент?
КБ>Потому что это будет не TDD. В TDD код пишется только тогда, когда его необходимость покажут тесты. Т.е. пока тесты для подсистем не покажут необходимость маленьких компонент — маленьких компонент не будет.
А что заставляет начинать с тестов подсистем, а не с тестов компонент?
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, jazzer, Вы писали:
J>>>Здравствуйте, gandjustas, Вы писали:
J>>>>>А идеология "сначала тесты, потом код", имхо — это уже экстремизм: слишком многое может поменяться в процессе написания этого самого кода. G>>>>Многое меняется в процессе написания потому что заранее неизвестно как оно должно работать. Я верю что есть зубры, которые проводят детальное проектирование в голове, а потом пишут с первого раза нужный код, но таких не встречал. G>>>>Именно поэтому тесты и пишутся перед кодом — чтобы понять как оно будет работать.
J>>>а как насчет того, что ты не учел 50 взаимосвязей, из-за который весь твой тестирующий код не имеет смысла, просто потому что, скажем, невозможно в заданном порядке сконструировать объекты, по каким угодно причинам? G>>В какой момент их можно не учесть в таком количестве? Если сначала пишутся тесты, а потом код, то откуда возьмутся эти 50 взаимосвязей? J>При написании собственно кода J>Невозможно все учесть до того, как код написан. J>Вдруг выяснится, что в конкретный метод надо передавать еще пару параметров, и что надо еще пару объектов создать для правильного окружения, и т.д. и т.п.
Тесты как раз позволяют выявить такое до написания код.
J>>>Я несколько раз пробовал подступиться в ТДД, и каждый раз напарывался на это. G>>Я с тех пор как применяю TDD пользуюсь IoC-контейнерами, которые разраливают управление временем жизни объектов. Кроме того кучи взаимосвязей из воздуха не возникают. J>Ну если эти контейнеры только для тестов — то да.
Наоборот, контейнер в программе, в тестах он не нужен. Все зависимоти подсовываются через конструктор. Их редко бывает больше 5 штук.
J>В любом случае, это не принципиальный момент, просто неудобство, которое приводит к переписыванию теста, если он был написан слишком рано.
Тесты до кода позволяют уменьшить количество переписываний кода в процессе разработки функционала.
Здравствуйте, gandjustas, Вы писали:
G>Тесты как раз позволяют выявить такое до написания код. G>Тесты до кода позволяют уменьшить количество переписываний кода в процессе разработки функционала.
Ну, значит, мне не так везло. Для меня практика написания полного тест-сьюта для компонента до того, как у компонента появится что-то, кроме имени, частенько (но не всегда, конечно же) выливалось в "Гладко было на бумаге, да забыли про овраги, а по ним ходить".
G>>>Я с тех пор как применяю TDD пользуюсь IoC-контейнерами, которые разраливают управление временем жизни объектов. Кроме того кучи взаимосвязей из воздуха не возникают. J>>Ну если эти контейнеры только для тестов — то да. G>Наоборот, контейнер в программе, в тестах он не нужен. Все зависимоти подсовываются через конструктор. Их редко бывает больше 5 штук.
В таком случае это уже к вопросу об общей архитектуре приложения, которая сейчас немножко оффтопик.
Скажем так: если приложение сделано с применением IoC, то писать модульные тесты для его компонентов легче.
Не флейма ради, просто на полях:
Inversion of control is a common feature of frameworks, but it's something that comes at a price. It tends to be hard to understand and leads to problems when you are trying to debug. So on the whole I prefer to avoid it unless I need it. This isn't to say it's a bad thing, just that I think it needs to justify itself over the more straightforward alternative.
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, gandjustas, Вы писали:
G>>Тесты как раз позволяют выявить такое до написания код. G>>Тесты до кода позволяют уменьшить количество переписываний кода в процессе разработки функционала. J>Ну, значит, мне не так везло. Для меня практика написания полного тест-сьюта для компонента до того, как у компонента появится что-то, кроме имени, частенько (но не всегда, конечно же) выливалось в "Гладко было на бумаге, да забыли про овраги, а по ним ходить".
Так и есть. Полный тест-сьют и не требуется для начала работы над компонентом. Цикл красное-зеленое-рефакторим итерируется по одному, максимум двумя тестам, никогда итерация не равна полному тест-сьюту для компонента.
Здравствуйте, BokiyIS, Вы писали:
BIS>Хотел узнать, применяете ли вы в рабочих проектах модульное тестирование
Да, обязательно! Периодически вычисляется coverage (процент покрытия кода тестами),
и по его результатам для классов с низким покрытием пишутся дополнительные тесты.
Плюс при code review любой из инспекторов вправе потребовать написать юнит-тест для
кода, если есть подозрение, что там возможны проблемы.
Как показывает практика, даже для примитивнейшего кода из трёх строк юнит-тесты могут выявить скрытые грабли.
Вот, к примеру, из недавнего: http://www.rsdn.ru/forum/message/3299673.aspx
Здравствуйте, samius, Вы писали:
S>Здравствуйте, Константин Б., Вы писали:
КБ>>Здравствуйте, samius, Вы писали:
S>>>Почему ТДД наоборот? Кто мешает писать тесты маленьких компонент перед маленькими компонентами? А потом писать тесты подсистем непосредственно перед их сборкой из маленьких компонент?
КБ>>Потому что это будет не TDD. В TDD код пишется только тогда, когда его необходимость покажут тесты. Т.е. пока тесты для подсистем не покажут необходимость маленьких компонент — маленьких компонент не будет.
S>А что заставляет начинать с тестов подсистем, а не с тестов компонент?
Потому что в TDD заниматься проектированием запрещено, поэтому разбить подсистему на компоненты можно, только если этого потребуют тесты. А как вы будете писать тесты для компонент, если компоненты у вас еще не выделены.
Здравствуйте, Константин Б., Вы писали:
КБ>Здравствуйте, samius, Вы писали:
S>>А что заставляет начинать с тестов подсистем, а не с тестов компонент?
КБ>Потому что в TDD заниматься проектированием запрещено, поэтому разбить подсистему на компоненты можно, только если этого потребуют тесты. А как вы будете писать тесты для компонент, если компоненты у вас еще не выделены.
Мягко выражаясь, не верю. Можно ссылку?
Вообще, раз на то пошло, то разбивка на компоненты может происходить как минимум во время рефакторинга, который делается в конце очередной итерации. А рефакторинг в конце итерации делается сам по себе без всяких требований тестов.
Здравствуйте, Константин Б., Вы писали:
КБ>>>Потому что это будет не TDD. В TDD код пишется только тогда, когда его необходимость покажут тесты. Т.е. пока тесты для подсистем не покажут необходимость маленьких компонент — маленьких компонент не будет.
S>>А что заставляет начинать с тестов подсистем, а не с тестов компонент?
КБ>Потому что в TDD заниматься проектированием запрещено, поэтому разбить подсистему на компоненты можно, только если этого потребуют тесты. А как вы будете писать тесты для компонент, если компоненты у вас еще не выделены.
Вернитесь на землю — написанием тестов на систему в целом TDD не занимается. тесты на новые микрокомпоненты пишутся глядя на проект новых компонент. а он в свою очередь взялся из нового use case. Те проектрировать и вообще думать не запрещено
Здравствуйте, SleepyDrago, Вы писали:
SD>Здравствуйте, Константин Б., Вы писали:
КБ>>>>Потому что это будет не TDD. В TDD код пишется только тогда, когда его необходимость покажут тесты. Т.е. пока тесты для подсистем не покажут необходимость маленьких компонент — маленьких компонент не будет.
S>>>А что заставляет начинать с тестов подсистем, а не с тестов компонент?
КБ>>Потому что в TDD заниматься проектированием запрещено, поэтому разбить подсистему на компоненты можно, только если этого потребуют тесты. А как вы будете писать тесты для компонент, если компоненты у вас еще не выделены.
SD>Вернитесь на землю — написанием тестов на систему в целом TDD не занимается. тесты на новые микрокомпоненты пишутся глядя на проект новых компонент. а он в свою очередь взялся из нового use case. Те проектрировать и вообще думать не запрещено
Ну не совсем. Последовательность примерно такая. Use case на подсистему -> тест на подсистему -> use case на компонент -> тест на компонент.
Написать тест на компонент, до теста на подсистему в рамках TDD не получается.
Здравствуйте, samius, Вы писали:
КБ>>Здравствуйте, samius, Вы писали: S>>>А что заставляет начинать с тестов подсистем, а не с тестов компонент? КБ>>Потому что в TDD заниматься проектированием запрещено, поэтому разбить подсистему на компоненты можно, только если этого потребуют тесты. А как вы будете писать тесты для компонент, если компоненты у вас еще не выделены. S>Мягко выражаясь, не верю. Можно ссылку?
Не верите во что?
S>Вообще, раз на то пошло, то разбивка на компоненты может происходить как минимум во время рефакторинга, который делается в конце очередной итерации. А рефакторинг в конце итерации делается сам по себе без всяких требований тестов.
Ну это понятно. Непонятно в какой момент времени появятся тесты на компоненты.
Здравствуйте, BokiyIS, Вы писали:
BIS>Привет всем. BIS>Хотел узнать, применяете ли вы в рабочих проектах модульное тестирование (а возможно и вообще TDD) BIS>и какие мысли у вас есть на этот счет. Стоит ли игра свечь или нет?
ИМХО стоит. Но как и все в этом мире, юнит тесты нужно применять с головой. Статей, о том, какие юнит тесты и TDD клевые и прекрасные предостаточно, а повторятся не хочется. Так что я просто постараюсь разобрать типичные ошибки начинающих. Если что, я сам далеко не гуру в тестировании, и все нижесказанное лишь ИМХО.
Rage more
Неофиты, зачастую, считают, что чем больше тестов, тем лучше. Они радостно пишут тесты на каждый метод, включая приватные, а затем ноют, когда им приходится тесты менять. Между тем, далеко не все имеет смысл покрывать юнит тестами. Что именно стоит покрывать тестами подскажет опыт. Например, в одном банковском проекте (J2EE), в котором я участвовал, честными юнит тесами были покрыты лишь десяток классов для работы с валютой. Все остальное замечательно проверялось другими видами тестов, включая ручные. Текущий проект, high-load приложение на Java покрыто тестами процентов на 20. С другой стороны, в одном из моих проектов на Ruby on Rails модель покрыта тестами полностью, а контроллеры на 9/10. Другая моя библиотечка на Ruby тоже покрыта тестами полностью. Разница от того, что Ruby достаточно лаконичный язык, и принцип DRY соблюдается достаточно строго.
Что не имеет смысла покрывать юнит-тестами? Методы, ошибки в которых легко отлавливаются и еще легче исправляются. Это делегаты, перекладвания данных туда-сюда, тривиальная логика, которая и так будет высокоуровневыми тестами. Не всегда имеет смысл покрывать юнит тестами места, подверженные частыми изменениям. В типичном database editor такого кода чуть менее 100%.
Что имеет смысл покрывать юнит-тестами? Места на границах спецификаций, крайние и экстремальные случаи, ядро, сложные алгоритмы, утилитарные классы, хелперы общего назначения и т.п. Ошибки в таких местах имееют неприятное свойство вылезать уже на живой системе и интерферировать между собой приводя к непредсказуемым последствиям.
Think before
Когда мы начинаем писать код, нам чаще всего не известно о его клиентах. У нас есть в голове некоторое представление о них, но оно почти всегда неправильное. Юнит тесты хороши, как попытка поставить себя на место клиента и посмотреть насколько хорош наш интерфейс с его точки зрения. Вопрос, что писать сперва, тесты или код, лишен смысла. Сперва думать, а потом -- неважно. Если думать не получается, TTD может помочь направить мысли в правильную сторону. Если мысли и так текут правильно, нафига этот костыль?
Думать заранее полезно. При удачном предварительном проектировании, интерфейсы не менются годами. Например, год назад, я написал один небольшой модуль и полностью покрыл его тестами. С тех пор его интерфейс только расширялся, что не достовляло никаких хлопот с поддержкой тестов в актуальном состоянии. С другой стороны, при разработке интерфейс этого модуля неслабо колбасило. TDD сокращает процесс релаксации, но не устраняет его полностью.
Difficult case
Не всегда окружающий нас мир прост. Бывают сложные вещи, такие как эвристические алгоритмы, протокол Z39.50 или настройка почтового сервера под Linux. Сложные алгоритмы, это первые кандидаты на юнит тестирование. Их код плохо читается, а ошибки в них незаметны и болезненны. Я даже знаю историю, о том, как одна ошибка в алгоритме привела к банкротству компании.
Юнит-тесты побуждают к изоляции сложных алгоритмов, что положительно сказывает на связности системы. Если бы не они, никто бы не заморачивался изоляцией алгоритмов, которая почти всегда нетривиальна. Для любого, даже самого сложного, алгоритма всегда можно предположить, чего ожидать на выходе для заданного входа. Часто, я прямо в тесте запускаю алгоритм с разными входами и если они не соответствуют ожидаемым, разбираюсь почему. Возможно это ошибка, а может алгоритм не так хорош. В любом случае, после того как отладка закончена, поведение алгоритма фиксируется юнит тестом. Если алгоритм по своей природе нечеткий, не обязательно даже не сравнивать выход с фиксированными значениями. Можно сравнивать выходы между собой. Или искать инварианты. Возможностей масса.
Silver bullet
Юнит тесты не панацея. Небольшой ценой за написание и поддержку тестов они помогают избежать злокозненных багов. Если получается, нет причин их не писать. Если не выходит, нужно либо учиться проектировать устойчивый к тестированию код либо забить и не мучаться. Существуют и другие способы борьбы с ошибками.
Естествено это не касается методологий, в которых TTD неотъемлемая часть, например eXtreme Programming. Если вы используете XP, ничего не поделаешь, писать тесты придется, иначе XP перестанет работать.
Здравствуйте, Константин Б., Вы писали:
КБ>Здравствуйте, samius, Вы писали:
КБ>>>Здравствуйте, samius, Вы писали:
КБ>>>Потому что в TDD заниматься проектированием запрещено, поэтому разбить подсистему на компоненты можно, только если этого потребуют тесты. А как вы будете писать тесты для компонент, если компоненты у вас еще не выделены. S>>Мягко выражаясь, не верю. Можно ссылку?
КБ>Не верите во что?
в выделенное
КБ>Ну это понятно. Непонятно в какой момент времени появятся тесты на компоненты.
Тут я согласен с SleepyDrago
Здравствуйте, BokiyIS, Вы писали:
BIS>P.s. быстро прошелся поиском, вроде похожей темы небыло. В любом случае освежить не помешает
Давненько была то такая тема.. я там даже отметился — http://rsdn.ru/Forum/Message.aspx?mid=2116090&only=1
Приятно что теперь отклик на подобную тему в форуме получился гоораздо больше
BIS>Хотел узнать, применяете ли вы в рабочих проектах модульное тестирование (а возможно и вообще TDD) BIS>и какие мысли у вас есть на этот счет. Стоит ли игра свечь или нет?
Я считаю, что я гораздо продуктивнее когда пишу юнит тесты, чем без них. Даже на коротких задачах, в средних проектах.
BIS>Хочется послушать людей, которые удачно применяли TDD или просто использовали Unit testing, а также тех, кто является его противником.
Буквально месяц назад, я вынужден был взятся за функционал, размазаный по коду user space приложения и драйвера, на который перед этим
два разработчика потратили 4 дня, и в результате, родили нечто неполноценное и рандомайзно глючное. За 8 часов рабочего я изучил тестовый
фреймворк(CFix классная штука), наткнулся на все глюки возникновение которых растянуло элементарную задачу на 8 человекодней. И буквально
за полчаса после 18-00 заставил работать это все как часы.
Любишь ночевать на работе — не пиши тесты.
BIS>(а возможно и вообще TDD)
Скорее я делаю так:
Пишу небольшое ядро, изучаю предметную область, апи, особенности фреймворкаПишу тестыМодифицирую свою реализацию, делаю ее удобной для использованияНарашиваю функционал
-- Главное про деструктор копирования не забыть --
