Як кодувати, не ображаючи?

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

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

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

ОНОВЛЕННЯ

Не існує жодного посібника зі стилів, про який можна говорити - просто люди не звикли ділитися кодовою базою даних. У кожного свій маленький кодовий світ.

Це магазин Perl, але я впевнений, що вони стосуються будь-якої мови

ОНОВЛЕННЯ 2

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

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

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

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

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

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

Що стосується перевірки коду "занадто часто", чому б не створити власну гілку для періодичних комісій, а потім об'єднати назад до магістралі, коли ваш код буде готовий? Нікому іншому не шкода робити це, і коли ваші колеги побачать, що ви отримуєте переваги від SVN, які їм хотілося б, вони можуть слідувати вашій увазі.

Щодо пробілів: просто зробіть це, однак код вже це робить. Плисти за течією.

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

Загалом: Почніть створювати стандартний документ кодування. Не намагайтеся заповнити його 100 правилами. Просто додайте правила, коли вони з’являються.

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

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

Що стосується перевірки коду у SVN, я б спробував євангелізувати те, що, на мою думку, є правильним способом робити справи, а не дозволяти собі пропаритись. Я не перевіряю свій код, якщо він не створює і не проходить тести, і якщо я вношу кілька непов'язаних змін, я розбиваю роботу на кілька комітетів. Якщо щось порушиться на деякий час, я створюю філію і роблю там свою роботу. Коміти отримують описові коментарі. На мій досвід це працює краще, ніж метод "перевірка в купі змін у п'ятницю о 5:00", і, здається, це перевага "найкращої практики" відповідно до більшості того, що я читав тут і в інших місцях.

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

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

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

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

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

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

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

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

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