Я спробую дати вам деякі підказки, підкріплені моїм особистим досвідом.
Один з моїх товаришів по команді, хоча і досвідчений, не дуже розуміє SVN. Природно, порожні області на його ментальній карті із зображенням океанів СВН змушують його прийняти досить дивні схеми використання.
Наприклад, він оголосив політику "1 SVN комісія на день на розробника", оскільки в іншому випадку "серверу незабаром не вистачить місця на диску". Коли я пояснив йому, що події SVN - це дельти, а не повні копії, він відповів сумнівом, і навіть сьогодні я не зовсім впевнений, чи розуміє він, що це означає.
Навіть якщо простір на диску був проблемою, ви завжди можете зробити багато файлів одночасно, тому я думаю, що він пропонує неправильне рішення. Крім того, можна витратити багато місця, перевіривши великі бінарні файли, оскільки SVN не зберігає дельта для бінарних файлів. Одне заїзд на день також поганий, оскільки змушує вас вносити зміни, які не належать разом, наприклад, якщо ви виправите більше однієї помилки на день.
Рішення, яке ми прийняли в нашій компанії, полягає в тому, що існує фільтр, який відхиляє будь-яку комісію, що містить бінарні файли. Ми можемо змусити зобов’язання використовувати спеціальне ключове слово в коментарі до реєстрації (ми повинні показати SVN, що ми знаємо, що робимо). Раз на рік-два менеджер проекту архівує старі відділення та вилучає їх із сховища. З цією стратегією у нас немає проблем з космосом, про які я знаю (наш репозитарій підтримує декілька різних проектів і налічує понад 100000 змін).
Підводячи підсумок, ви можете сказати йому, що ви згодні з ним, що місце на диску є важливим питанням, але, з іншого боку, вказуйте
- важливість реєстрації, пов’язаної з функціями, замість однієї монолітної щоденної реєстрації;
- той факт, що перевіряючи один великий двійковий файл на день, можна було все-таки заповнити диск.
Тоді ви можете запропонувати зустріч (можливо, з іншими розробниками чи системними адміністраторами), щоб обговорити стратегії, щоб тримати під контролем використання дискового простору (наприклад, фільтри бінарних файлів, регулярне резервне копіювання та очищення старих невикористаних гілок).
У нас також був бурхливий аргумент щодо того, чи потрібно включати конфігурацію проекту Eclipse .prov у SVN. Мій товариш по команді наполягав на необхідності, хоча це спричинило численні безглузді конфлікти. Я був проти збереження окремих файлів конфігурації розробника у SVN. Нарешті, виявилось, що мій товариш по команді мав практику повторної перевірки всього вихідного дерева після кожного зобов’язання, щоб просто переконатися, що "код, виконаний у сховищах". Це було причиною того, що він настільки прихильний до збереження конфігурації проекту у SVN - тому його буде легко повторно імпортувати. Коли я пояснив, що виконувати синхронізацію робочої копії з віддаленим байтом за байтом, що робить повторну перевірку непотрібною, мій товариш по команді знову відповів сумнівом і, врешті-решт, відкинув всю проблему як незначну.
На мою думку, наша команда витрачає час, вирішуючи конфлікти SVN у файлах конфігурації проекту, які містять лише специфічні для розробника налаштування, які взагалі не повинні надаватись SCM. Все це безлад, тому що хтось адаптував процес навколо неправильних припущень.
Ви використовуєте сервер збирання? У нас є сервер збирання, який перевіряє повний проект і збирає його щовечора. Наступного ранку у тестерів є готовий до тестування інсталятор продукту (якщо майстер-збірка запустився правильно), і ми (розробники) склали звіт про збірку з усіма попередженнями (і помилками, якщо такі є). Звичайно, вам потрібно встановити стандартні файли конфігурації для сервера збирання та перевірити їх. Кожен розробник може перевірити їх разом із рештою проекту, але їм заборонено перевіряти будь-які локальні зміни.
У цьому сценарії ви звертаєтесь до його необхідності мати можливість перевірити весь проект та створити його в будь-який час. Ви також уникаєте витрачати час на злиття змін, які не слід було б перевіряти в першу чергу, оскільки вони не є частиною продукту: продукт - це основне складання, і його потрібно підтримувати в чистоті. Якщо хтось порушує головну збірку (наприклад, перевірка власного файлу .project), ви можете скасувати зміни або змусити розробника вирішити проблему.
Можливо, якщо він знову поставить проблему, ви можете знову запропонувати зустрітися (можливо, з іншими розробниками) і разом знайти спільну стратегію.
Як я можу переконати товариша по команді, який вважає себе старшим, краще зрозуміти основи SVN?
Я думаю, що найкращою стратегією було б уникнути доведення конфлікту до особистого рівня та скоріше обговорити проблеми та можливі шляхи їх вирішення. Якщо у вас складається враження, що він шукає особистого протистояння, ось кілька пропозицій (знову ж таки, з особистого досвіду):
- Яка динаміка вашої команди? Чи мають інші колеги подібний досвід роботи з цим товаришем по команді? Є багато невеликих, не надто явних натяків, які команда може дати одному зі своїх членів, щоб відмовитися від певної поведінки (невеликі анекдоти чи спостереження) та заохотити конструктивне протистояння (запропонувати зустріч або неофіційно підняти тему під час перерви на каву ). Іноді хороша команда може швидко ізолювати тривожний елемент і повернути речі в норму.
- Наскільки добре ваше управління персоналом? У нас був один конфліктний випадок у нашій компанії, і для усунення ситуації повинен був втрутитися керівник персоналу. Це було не приємно, але іноді робоча атмосфера погіршується настільки, що не покращиться сама по собі. Я сподіваюсь, що це не ваш випадок (у мене ще немає враження, що це дійшло до цього часу), але завжди добре знати, чи є у вас хороша адміністрація персоналу чи вам доведеться вирішувати конфлікти самостійно.
Чому я це пишу? Ви кажете, що хочете "переконати товариша по команді, який бачить себе старшим, щоб краще зрозуміти основи SVN". Для мене це здається, що конфлікт може бути занадто особистим. Деякі психологи стверджують, що 70% нашого спілкування перебуває на емоційному рівні, якщо цей рівень не працює, то люди перестають говорити про факти, тому що вони занадто зайняті справою з емоціями.
Отже, окрім пояснення ваших пунктів, ви також можете спробувати зробити щось для покращення спілкування. Запрошення на каву або перерву на обід разом, коротка розмова на тему, яка не пов’язана з роботою тощо, може покращити спілкування та повернути увагу колеги до важливих фактів, які ви хочете, щоб він зрозумів. Якщо він приймає такий вид спілкування, то, можливо, конфлікти, які ви мали до цього часу, були пов'язані з тим, що ви не знаєте один одного добре і були невеликі непорозуміння, але він, ймовірно, відкритий для створення конструктивної співпраці. Якщо він відмовиться, то на його боці може виникнути більш глибока ворожнеча.
У цьому випадку, я думаю, вам слід почекати, поки ваші ролі не стануть зрозумілішими. Якщо ваш товариш по команді офіційно не має вищого рангу, ніж ваш, він не має сенсу дратуватися вашими спробами покращити справи. З часом йому доведеться це прийняти або зробити дурня з себе, якщо він намагатиметься показати, що знає краще. Якщо він має вищий ранг, вам слід знайти спосіб зрозуміти, що це не обговорюється: ваші спостереження спрямовані на підвищення продуктивності, а не на підрив його позиції, це повинно бути на 100% зрозуміло. Коли ролі були уточнені, якщо він все ще не може прийняти конструктивні пропозиції чи критику, то він справді повинен мати певні проблеми з самооцінкою чи чимось подібним.
Тож якщо всі стратегії, описані вище, зазнають невдачі, і ви відчуваєте (дуже) розчарування, я боюся, що єдине розумне, що потрібно зробити, - це запакувати свої речі та шукати краще місце. Я зробив цей досвід три роки тому і знайшов набагато кращу компанію, в якій зараз дуже задоволений. Можливо, це не ваш випадок (сподіваюся, звичайно), але спробуйте зрозуміти і цей момент.
Всього мої 2 копійки.