Golang is a trend now but there is a lot of projects where you have to avoid of using it.
Let’s start from what kind of benefits brings Golang for your team/project:
– Easy to learn and get started with. This helps to grow your team quickly and involve new people even without any experience with Golang.
– Built-in concurrency and a robust standard library. Which allows to utilise your CPU in the most effective way and easily create multithreading applications (channels, mutex, atomic etc.).
– Strict types helps to avoid some basic coding issues. So these options shows us that Golang is a good tool for high performance projects and big growing teams.
But otherwise when your team is small and you don’t need to solve high performance tasks. That means that you will have some troubles like a very big codebase.
– Lack of generics in Golang will make you to write / support more code.
– Writing of multithreading programms even in Golang requires to have senior engineers. So that means you will have to spend more money on your team without any incomes from using Golang.
– It will take more time to release because you will need to write/support a bigger codebase.
When you don’t need to use Golang in your team/project?
– Your project is not simple (it is not quite small like some CLI utilities or small service) and it should be build as a monolithic application with a small team
– Your budget is not big and you don’t have too much time for release
– Your project is new and you have to release it ASAP to make money
– You don’t have any high performance problems which can not be solved on your current technical stack
Разработка через тестирование (англ. test-driven development, TDD) — техника разработки программного обеспечения, которая основывается на повторении очень коротких циклов разработки: сначала пишется тест, покрывающий желаемое изменение, затем пишется код, который позволит пройти тест, и под конец проводится рефакторинг нового кода к соответствующим стандартам. Кент Бек, считающийся изобретателем этой техники, утверждал в 2003 году, что разработка через тестирование поощряет простой дизайн и внушает уверенность (англ. inspires confidence).
Кстати, рекомендую прочитать книгу о TDD самого Кента Бега(http://www.ozon.ru/context/detail/id/1501671/). О том для чего и когда использовать TDD я в этой заметке писать не буду, т.к. я думаю, что это достаточно очевидный момент и как правило вопрос возникает как к этому подходу разработки перейти и как его успешно внедрять.
Workflow
Ниже на рисунке представлен процесс разработки программы в стиле TDD.
процесс разработки программы в стиле TDD
Начинается весь процесс всегда с написания тестов и далее двигаемся по стрелочке:
1. Написание теста, без написания логики программы, которую мы проверяем в тесте.
2. Запуск теста и проверка того, что тест красный, т.к. у нас нет реализации тестируемой части(если тесты зеленые – значит тесты ничего не проверяют и их нужно переписать)
3. Пишем код, который делает тесты зелеными(минимальный код, а точнее любой корректно работающий код, который сделает тесты зелеными)
4. Запускаем тесты и проверяем, что они зеленые
5. Рефакторинг, мы переписываем наш "говнокод" для озеленения тестов, так, чтобы он был работающим и хорошо пахнущим не только для тестов, но и для нас.
Проблема первого теста
Исходя из собственной практики на первых этапах самое сложное это начать писать первый тест, до реализации тестируемого кода и здесь я вижу два приема:
1. Написать сначала интерфейс, затем переходить к тесту. Это позволит начать переход к TDD и при этом не слишком "тупить" над тем, что и как тестировать, т.к. часть кода вы уже будете писать до теста и в голове уже будет небольшое понимание того, что тестировать. Ну а как привыкните – начнете писать тесты сразу.
2. Это писать сначала самый короткий, т.е. минимальный и общий тест. Собственно это и есть праведный путь TDD. Таким образом дизайн программы будет строиться по циклу через тесты, с каждой итерацией вы будете добавлять тесты и код.
Проблема плохого дизайна
Часто такое бывает, что есть желание перевести проект на TDD и жить хорошо, но оказывается так, что текущая ситуация с дизайном не позволяет перевести весь проект на TDD, на практике иногда ине всегда возможно в разумные сроки перенести весь проект на TDD. В связи сэтим разумно этого не делать, но естьвсе таки несколько вариантов для того, чтобы начать использовать TDD и в таком проекте:
1. Писать проект заново, особенно если в пользу этого уже есть какие-нибудь и другие предпосылки.
2. Выделять из проекта отдельные компоненты и тестировать их. Этот вариант подходит для проектов с не слишком НЕудачным дизайном.
3. Использовать TDD только для новых изменений кода и со временем весь проект сможет перейти на TDD. Этот вариант на мой взгляд самый универсальный.
Заключение
В общем и в целом считаю, что TDD это хороший способ улучшить стабильность и надежность своего кода и даже при написании небольших приложений это позволяет снизить количество ошибок в приложении многократно. Как минимум это стоит попробовать.
