• Пройти The Clean Code Game
• Прочитать "Чистый код" Роберта Мартина или её краткий конспект
• Пройти онлайн практикум по языку запросов LINQ

От простых и поверхностных способов к более сложным и глубоким:

1. Пройти супер-краткий гайд
2. Скачать на рабочий стол Git Cheat Sheet
3. Пройти интерактивный учебный курс от github и schoolacademy по основам git.
4. Решить практическую задачу на работу с ветками.
5. Пройти игру-квест https://github.com/hgarc014/git-game
6. Пройти интерактивную игру про работу с ветками http://pcottle.github.io/learnGitBranching/
7. Прочитать официальную книгу по git: http://git-scm.com/book/ru/v2 (первые три главы обязательны)

Напишите процессор простого markdown-подобного языка разметки.

Описание языка, он же пример файла с разметкой.

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

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

Разбейте ваш процессор на составные части. Каждая часть должна быть легко читаема и покрыта тестами.

• Сначала проведите начальное проектирование. Определите какие будут классы и какие в них будут методы. Не пишите внутренности методов на этом этапе.
• Пишите код метода, параллельно создавая модульный тест на этот метод.
• Придумывайте тесты по одному. Старайтесь каждый раз придумывать как можно более простой тест, который позволит максимально просто продвинуться в реализации задачи.

• Пишите тесты так, чтобы их имена читались как спецификация на язык разметки. У вас должна получиться более точная и полная спецификация, чем в файле sample.txt.
• Уделите внимание правильному порядку тестов, чтобы их было удобно читать как спецификацию.
• Каждый тест должен быть в формате Arrange—Act—Assert.

Сделайте fork этого репозитория и ведите всю работу в нем.

Разбейте работу на отдельные (но не очень мелкие) подзадачи и делайте по отдельному коммиту на каждую подзадачу.

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