Стандарти роботи розробників на власних робочих станціях

Ми щойно стикаємося з однією з тих ситуацій, яка час від часу виникає, коли розробник на протязі декількох днів перебуває в захваті протягом середини проекту.

Було кілька запитань щодо того, чи вчинив він останню версію свого коду, чи є щось новітнє на його локальній машині, на яку ми повинні дивитися, і у нас надійшла доставка до клієнта, тому ми не могли чекати його повернути.

Один з інших розробників увійшов до нього, щоб побачити і виявив безлад робочих просторів, багато, здавалося б, тих самих проектів, із тимчасовими позначками, які зробили незрозумілим, який з них "поточний" (він прототипував деякі біти на версіях проекту, крім його "серцевина").

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

Я не говорю про стандарти для зареєстрованого коду чи навіть про загальні стандарти розробки, я кажу про те, як розробник працює локально, домен, як правило, вважається (на моєму досвіді) майже повністю під контролем розробників.

То як ви вирішуєте подібні ситуації? Чи є однією з тих речей, що тільки трапляються, і з якими вам доводиться мати справу, ціна, яку ви платите за розробників, дозволяється працювати так, як їм найбільше підходить?

Або ви просите розробників дотримуватися стандартів у цій галузі - використання конкретних каталогів, іменування стандартів, нотатки на вікі чи що завгодно? І якщо так, що охоплюють ваші стандарти, наскільки вони суворі, як ви їх поліцейські тощо?

Або є інше рішення, яке мені не вистачає?

[Припустимо заради аргументу, що з розробником не можна зв’язуватися, щоб поговорити про те, що він тут робив, - навіть якщо він міг знати і описувати, яка робоча область, яка з пам’яті, не буде простою і бездоганною, а іноді люди справді можуть Звертаються до мене, і мені хотілося б рішення, яке охоплює всі можливі випадки.]

Редагувати: Я розумію, що проходити через чиюсь робочу станцію - це погана форма (хоча це цікаве - і, швидше за все, поза темою - питання, чому саме це є), і я, звичайно, не дивлюся на необмежений доступ. Подумайте більше за типом стандарту, де їх каталоги з кодом налаштовані із загальним доступом для читання - нічого не можна змінити, нічого іншого не можна побачити тощо.

" Якщо це не в контролі джерела, його не існує. "

Це одна з небагатьох речей у нашій професії, про яку я прикордонний догматик. З наступних причин:

1. Незважаючи на те, що робоча станція є власністю компанії, давайте поглянемо на це - є трохи неписане правило, що власне робоче місце програміста - це його замок. Мені просто неприємно з культурою на робочому місці, де кожен може звичайно зайти на неї та пройти її.
2. У кожного свій потік (як ви вже сказали). Намагаючись змусити всіх розробників організовувати власні місцеві робочі простори певним чином, це може суперечити їх особливостям роботи та порушити їх потік і зробити їх менш ефективними.
3. Те, що не знаходиться у контролі джерела, - напівфабрикат. Якщо це повністю запечений код, готовий до випуску, він повинен знаходитись у контролі джерела. Що повертається знову до основного пункту….
4. "Якщо це не в контролі джерела, його не існує."

Одним із можливих способів пом’якшити питання прагнення до коду на робочих станціях людей є сприяння культурі регулярних перевірок. Я колись працював у компанії, де - хоча офіційного мандату на це не було - це було якоюсь гордістю завжди мати все, що потрібно перевірити на вихідні. Під час технічного обслуговування та випуску кандидатських етапів елементи CR були навмисно дуже дрібними, щоб забезпечити невеликі, чітко видимі зміни та регулярні перевірки, щоб відстежувати їх.

Крім того , маючи все перевіряється , перш ніж йти у відпустку було обов'язковим .

Версія TL; DR : Пробиватися по робочих станціях людей - це погана форма. Замість того, щоб намагатись виховувати культуру, щоб полегшити проїзд через робочі станції людей, щоб знайти те, що ми хочемо, краще застосовувати культуру розумного використання джерел управління джерелами та регулярні перевірки. Можливо, навіть гіперрегулярні чеки та тонкодисперсні завдання, коли знаходяться у критичних фазах проектів.

Замість того, щоб застосовувати стандарт того, як ваші розробники організовують свої робочі станції, застосуйте стандарт, де всі роботи перевіряються в кінці кожного дня . Реєстрація може бути відділенням, якщо вони ще неповні.

Таким чином нікому ніколи не потрібно мати доступ до робочої станції іншого розробника.

Я б міг уявити, що ця політика зустрінеться з якоюсь опозицією, але нічого в порівнянні з тим, що я б очікував, якби ви застосували правила щодо організації робочих станцій.

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

Востаннє я виїхав на вихідні, хлопці переналаштували сервери з базою даних та керуванням джерелами, і чомусь вважали за потрібне увійти на свою машину та перенастроїти систему для нового налаштування.

Шкода, що вони не мали уявлення, чим вони займаються, і вони стерли прототип, над яким я працював останні два місяці.

Це не сталося б, якби було належне спілкування. Це те, що вам потрібно. Перейдіть до цього розробника і дізнайтеся про стан речей. Ще краще попросіть людей скласти звіт перед тим, як відправитись у відпустку, щоб ви прийняли обгрунтоване рішення, чи потрібно вам щось із них чи ні.

Але не возиться з робочими станціями людей.

PS У нас є умова щодо структури каталогів, але головна причина існування - це поєднання історії / конфігурації - помістіть її деінде і вона не буде компілюватися.

Кілька місяців тому я працював над досить великим проектом, і мені довелося різко залишити роботу, коли я з'ясував, що я потрапив до лікарні. Я не встиг перевірити свій останній код проекту.

На щастя, тут є умовою (хоча це не "необхідно") зберігати код, /var/www/ourdomain.comщоб імітувати виробництво. Завдяки такому логічному та легко дотримуватися конвенції, колезі було легко увійти до моєї машини та отримати мої останні зміни.

Я думаю, що деякі умовності хороші. Хоча я згоден з Боббі, коли він каже

"Якщо це не в контролі джерела, його не існує."

Крім того, корисним доповненням до будь-якої робочої області програмістів може бути привід SATA на гарячому заміну, на якому можна зберігати всі джерела та проекти розробки. Таким чином, якщо така проблема виникає, працівник може легко отримати нові зміни джерела в проекті без необхідності входу на робочу станцію розробників.

У першій частині вашого питання чітко визначте проблеми спілкування у вашій команді. Ви пробували щоденні складання ?

Я погоджуюся з вами, коли ви говорите, що стандарти, ймовірно, призведуть до неефективності, якщо вони занадто суворі. Стандарти повинні бути визначені командою , в якій беруть участь усі.

У вашому випадку я б зачекав кілька днів після повернення зацікавленого розробника на роботу. Потім організуйте зустріч, щоб поговорити про ці стандарти.

Щоб уникнути будь-яких психологічних блоків та опору, не називайте людей чи конкретні речі, які ви бачили. Майте це загалом, мета тут - отримати вклад від усіх, включаючи розробника, який, на вашу думку, має покращити його спосіб роботи. Хлопець також може вважати вашу організацію безладом.

Під час зустрічі презентуйте проблему та чітко запитайте, як команда могла б покращити ситуацію.

(Вся) команда вирішує , що робити.

Цей користувач, ймовірно, страждав від нестачі належних інструментів. Зокрема, використання розподіленої системи управління версіями усувало б для нього необхідність мати різні каталоги коду в різних станах. Він міг утримати це у гілках і був набагато щасливішим.

До головного, однак, ні, я не хочу, щоб на мене застосовувались стандарти щодо організації власної робочої станції. Я зараз наполягаю на тому, щоб мій відділ був стандартизований на IDE (мій начальник дійсно хоче, щоб ми всі були в Eclipse, тому що це він використовує і добре знає, хоча ІМО це не найкращий інструмент для моєї роботи).

Нехай розробники роблять все, що робить їх зручніше. Зручний розробник продуктивніший, ніж незручний. І якщо хтось НЕ є продуктивним, і ви підозрюєте, що вони обмінюються локально з інструментами, це можливість для тренувань, а не час для створення нових правил.

На моєму старому місці роботи у нас була система, згідно з якою кожне завдання в нашій помилковій програмі мала власну гілку управління джерелами. Зрозуміло, що більшу частину часу один розробник видаляє помилку / завдання, тому зламаний код дозволив перевірити джерело управління.

Як тільки код був у стані, що він стабільний у галузі розробки, було зроблено перезавантаження, перетягуючи код з гілки, з якою ви збиралися інтегруватися. Після того, як ви протестували це злиття, це був би просто випадок введення коду до гілки інтеграції - це не вимагатиме злиття, як ви вже зробили злиття у вашій гілці.

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

У цій конкретній ситуації зателефонуйте людині вдома, дайте зрозуміти, що ви не сумніваєтесь, що він хворий, але вам потрібно, щоб хтось інший продовжував свою роботу, і запитував, де останні матеріали та в якому стані.

Тоді вам потрібно подумати, що звідси робити. Якщо проблема полягає в тому, що люди перевіряються занадто рідко, подумайте про використання розподіленої системи управління джерелами, яка дозволяє людям працювати у відділеннях, не заважаючи один одному.

Якщо проблема полягає в тому, що вам не подобається, що розробники мають на своєму комп'ютері кілька робочих просторів, тоді перейдіть це. Стиль роботи індивідуальний, і ви, в основному, повинні триматися подалі від їхніх систем, доки вони добре працюють з правилами джерела сховища. Особисто я перевіряю нову копію дуже часто для різних проектів і прибираю лише раз у раз.

Якщо проблема полягає в тому, що ви не знаєте, що робить ваш розробник, проблема політична, а не технічна, і вам потрібно змінити стиль управління. Пам'ятайте, що розробники - це висококваліфікований персонал, якому рідко подобається мікроуправління, і вам доведеться делегувати. Інакше ви відштовхнете найбільш кваліфікованих людей.

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

То як ви вирішуєте подібні ситуації?

Вирішити цю проблему можна за допомогою системи управління джерелами, яка підтримує особисті нестабільні гілки та підтримуючи часті комунікації. Прийняття зобов’язань не повинно прийти, коли вирішується вся проблема. Він повинен надходити, коли ви користуєтесь контролем над джерелами. Кінець дня - один із багатьох моментів, коли має відбутися вчинення, щоб ви могли бачити, де були внесені ваші зміни, створити резервні копії та пояснити їх своєму майбутньому самому чи іншим.

Або ви просите розробників дотримуватися стандартів у цій галузі - використання конкретних каталогів, іменування стандартів, нотатки на вікі чи що завгодно?

У нас є величезний документ із конфігурацією середовища, який позначає конвенції, але не стандарт. Стандарти призначені для виробничого коду та середовища. Однак багато наших інструментів розробки налаштовані на підтримку конвенцій, і більшість розробників не витрачають зусиль, щоб зменшити тенденцію.