who wanna be software developer?

Гаразд, вступу про користь і потрібність використання систем керування версіями не буде — це банально і тупо.

Проблема у тому, що їх використовують переважно для годиться, або ж тому що цього вимагає корпоративна/проектна політика. До того ж, далеко не найефектнішим чином, сприймаючи їх просто, як “місце, де зберігається уся ця фігня”. Гаразд, про це також не будемо, бо і це тема, про яку дуже багато написано.

Існує інша серйозна, і чомусь мало висвітлена (а може я просто надто мало читаю?) тема — фіксація зроблених змін. Під час, скажімо, періоду баґ фіксингу, усе зрозуміло: зафіксив баґ, [залив на review board,] закомітив. У такому випадку, і тобі просто організовувати політику комітів, й історія на сервері виглядає гламурною. Що ж робити під час активного девелопменту? Зі своїх спостережень, можу сказати, що більшість комітить власний код або у кінці робочого дня, за 30 секунд до вимкнення комп’ютера, або ж коли той комусь потрібні (колезі, тім ліду, рев’юверу, менеджеру, клієнту…).

Гадаю, кожен зтикався із ситуацією, коли після активного кількохгодинного кодингу, щось внєзапно (а ви думали, це ви винні?) перестає працювати, і лиш дідько знає, після внесення якої змін це сталось. І, що в таких випадках роблять справжні програмісти? Правильно, вони починають або через жопу по пам’яті відкатувати зміни, або довго і нудно дебажити.

Більш розумні, досвідчені, й водночас, менш ліниві дядькі знають, що (усе, що тіко мона) і коли (часто — після внесення кожної більш-менш значної зміни) тре комітити. Це потрібно для того, щоб ви у будь який момент могли “повернутись у часі” до практично будь якого стану коду, коли “та фігня працювала” з мінімальними втратами часу. І повірте, це не просто якась тавтологія з теоретичних посібників з інструкціями для ідеальних корпоративних програмістів, це реальна хакерська практика, опанувати і зрозуміти усю глибину якої можуть лише обрані.

Інколи цьому перешкоджає одна проблемка — корпоративна/проектна політика не дозволяє “засирати” історію комітів на VCS, або ж відсутність доступу до сервера. У такому випадку справжні музики встановлюють, і налаштовують локальний сервер, в який і комітять зроблені зміни, а потім просто мержать його з центральним. Але ті, кому менше 25 років, знають про ще трушніший метод — використання розподілених VCS, деякі з яких (наприклад, git) дозволяють не заморочуватись налаштуванням репозиторію, і звести усе до елементарного `git init`, після чого одразу ж приступити до роботи.

Так багато розумних дядьків працюючи, скажімо, над якимось функціоналом локальний репозиторій Git, і комітить туди усе, що хоче, і на стільки часто, як того хоче, а в центраьний — лише великі, праюючі і добре відлагоджені шматки коду. Спробуйте!

This entry was posted on вівторок, Листопад 17th, 2009 at 12:38 and is filed under Розробка софту.