Как повысить качество кода

Git branches

В детстве мой дом находился рядом с НИИ статистики. На территории мы находили много картонных прямоугольников с ровными рядами цифр. В некоторых цифрах были пробиты отверстия. Уже подростком я узнал, что это перфокарты — первые программы для ЭВМ. Точнее, еще раньше перфокарты применялись для кодирования рискунка на ткацких станках.

В школе я впервые увидел 386й компьютер и пятидюймовые дискеты. А в институте и трехдюймовые. Мои первые программы и курсовые целиком помещались на одной дискете. Однажды, я вытащил дискету из компьютера пока еще горел сигнальный светодиод. И потерял весь свой код. Так я быстро научился делать бэкапы.

Уже на работае я познакомился c CVS. Тогда ее использовали только для резервного копирования кода. В то время большинство проектов создавались одним разработчиком и возможности совместной работы не использовались.

На второй работе я познакомился с разделением окружения на prod, dev и test. Вернее, окружение было всего два: prod и dev. Test считался излишним, т.к. все тесты выполнялись разработчиками на dev. Тогда же я познакомился с идей разделения прав и ответственности: разработчики имели доступ только к dev. Копированием файлов с dev на prod занимался руководитель проекта. Разработчики, закончив новую функциональность, создавали файл с описанием и прикладывали файлы c кодом, которые надо было скопировать на prod. Руководитель проекта проверял описание и копировал файлы с кодом. Если в работе prod возникали ошибки, то он откатывал файлы с кодом на предыдущую версию.

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

Git поддерживает разделение кода на prod и dev, которые называются ветками: master и develop. Права на запись в мастер ветку имеет только руководитель проекта. Разработчики могут обновлять ветку develop, но большинство создают свои копии ветки develop, например: feature или bugfix. А после завершения работы со своей веткой, копируют ее содержимое в develop. В Git реализован механизм обьединения веток даже при конфликтах в коде, когда два разработчика изменили одну и ту же строку.

Git можно установить самостоятельно, на свой сервер, но чаще всего пользуются сайтами GitHub.com и Bitbucket.com. Они позволяют сравнивать две версии кода: до и после изменений, оставлять комментарии, организуя социальную сеть разработчиков для обмена кодом, тестирования и code review.

В нашей команде GitHub.com и Bitbucket.com — основные инструменты для хранения и проверки кода. Клиенты имеют доступ к проеткам 24/7, могут сами тестировать код и оставлять свои комментарии.


Добавить комментарий

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