Как Вы работаете с программистом с радикально другим стилем кодирования? [закрытый]

общаться с другим разработчиком. Согласны в стиле кодирования, который сочетает в себе лучших в оба мира?

Когда вы говорите «стиль кодирования», вы имеете в виду форматирование или разницу в том, как вы структурируете свой код?

Что касается стиля кодирования, команда, вероятно, должна иметь форму стиля и обеспечить соблюдение какого-либо формата до коммита. Таким образом, слияние не будет водить слияние сумасшедшего.

Для структурной разницы в коде я боюсь, нет простого решения. Если кто-то является труднодоступным кодером спагетти, по сравнению с фанатичным объектом, вам придется сесть на стол и обсудить оба подхода, и как они применяются в вашем конкретном проекте. Убедитесь, что нет абсолютного ответа, все зависит от контекста. Также попробуйте прибегать к тому, что вы оба вы уважаете, чтобы возобновить лучшие практики, просмотрите код для проверки кода и помогите определить общий подход (Технический лидер или Tech PM).

Ваш стиль кодирования не является нормой. Его стиль кодирования не является нормой. Норма - это стиль кодирования, выбранный проектом или, иногда всей организацией (и который должен быть где-то документирован), и оба вы должны соблюдать его. Инструменты, такие как CheckStyle (с Java), могут быть использованы для обеспечения соответствия. Если вы используете такой инструмент, распространяйте его файл конфигурации. Также распределите файлы для форматирования IDES.

Многие проекты с открытым исходным кодом (или корпоративными) используют эти принципы (см. Например, Xwiki's стиль кода Java , Стиль кода Maven Code и конвенции кода или разработчики Apache 'C Руководство по языку ). Это работает для разработчиков, распространяемых по всему миру, не говорите мне, что не может работать для разработчиков в одной комнате.

Если у вашего проекта нет никаких стандартов кода, то это может быть время для определения некоторых, и я просто надеюсь, что вы сможете сделать это как двух взрослых (на самом деле, это должно быть решением команды). При необходимости напомните, почему стиль Unified Code важен (для лучшей читаемости, для дифференциров). Если, к сожалению, это не работает, то у вас босс решается для вас.

Я собираюсь ответить на «мягкие навыки», необходимые для того, чтобы ладить с кем-то, кто имеет в значительной степени другой стиль кодирования, который мне. Как правило, я пытаюсь сосредоточиться на трех простых принципах; Профессионализм, доверие и эго.

С точки зрения профессионализма простым недопустимым для просто повторного записи или удаления чьего-либо кода, потому что их стиль отличается от вашего. Профессиональный подход будет сначала понять, почему я считаю, что мои идеи / стиль / предпочтения будут лучше. Тогда я ожидал сесть с другим человеком и обсудить свои очки, и вот важная часть, держите открытый разум. Только потому, что мне нравится моя идея, не означает, что это правильно или правильно. Настоящий профессионал сможет и желает принять, что другие идеи так же ценны и приходят с другой точки зрения.

Лично мне нужно доверять своим собратьям. Старая поговорка заключается в том, что доверие должно быть заработано, а это верно для разработки программного обеспечения. Доверие может быть построено из разнообразных источников, таких как обмен информацией, идеями и кодом. Продуктивная команда обычно имеет неявный уровень доверия между его разработчиками.

Одной из основных причин, по которым люди не ладят, - это эго. Наши эго позволяют нам чувствовать угрозу, превосходные, смущенные и разнообразные другие человеческие эмоции. Оставляя наши EGOS в сторону и говорить о наших проблемах с другим лицом, всегда хорошее начало.

Я работаю для Chillisoft.co.za в Южной Африке

Управляемое развитие : Мы использовали практику развития, ориентированные на тестовые приводы, поскольку первая книга Кент Бек его применяется во всем. Мы используем NUNIT и R # в качестве тестового бегуна.

Вы тестируете? : В дополнение к TDD мы выполняем ручное тестирование (Visual), и это автоматически при необходимости. Технологии, используемые для автоматизации, зависит от технологий UI.

Установка тестирования : см. TDD.

Тестирование интеграции : Да, но мы еще не использовали повсеместливо.

Приемное тестирование : Мы выполняем разработку пользовательских программ для внешних клиентов, которые вам не платят, пока они не примут, следовательно, да.

Код отзывы : запланировано в два раза для каждого проекта. Даже те, которые были программированы в паре / свертке.

Пара Progamming : Мы делаем большую часть нашего кодирования парами, но, безусловно, есть некоторые задачи и некоторые этапы проекта, где это менее эффективно. То, что мы делаем, это во время запуска проекта (первые несколько недель каждой фазы), которую мы пару программа. На этапах отделки мы не делаем. У нас также есть конкретные времена (8 часов в неделю на разработчик), когда мы работаем над проектами с открытым исходным кодом, все это программирована. Все наши машины установлены с несколькими клавиатурами и мыши, чтобы облегчить плавное взаимодействие между Devs.

Инновационные технологии : Мы проделали большое количество работы на Habanero и используем эту основу наряду с дистанционным единством и черномоками.

Agile : Мы использовали гибкие философии в течение 8 лет и продолжаем экспериментировать с инструментами и философиями, поскольку мы продолжаем по этому пути.

Спецификация требований (как?) : Мы захватываем истории пользователей (используйте случаи) для следующих итераций в Msword. Затем мы захватываем краткое изложение этих в JEERA с оценками усилий и т. Д., Что управляет рисовать графики и т. Д.

Продолговная интеграция : В настоящее время мы используем HUDSON, который работает на вершине SVN.

Инструменты покрытия кода : мы запускаем покрытие кода для каждого проекта как часть нашей ночной сборки. Мы заинтересованы в результате доклада в отчеты HUDSON, чтобы мы могли отслеживать их ежедневно для каждого проекта.

Общение (Wiki, Mail, IM, MailingLists, другие документы) : Очевидно, мы коммуникативны во многих разных манерах, у нас есть внутренний Wiki и т. Д.

Размер команды : У нас есть 15 разработчиков программного обеспечения.

Встречи : У нас есть «Scrum» каждое утро, продолжив около 10 минут.

Отслеживание ошибок : Мы используем разные системы для отслеживания внутренних ошибок (I.E. Во время разработки и внутреннего тестирования) и для отслеживания внешних ошибок I.E. Ошибки от клиентов. Внутреннее отслеживание (то есть во время внутреннего тестирования и разработки) мы используем Redmine. Внешнее отслеживание (то есть для наших клиентов) Мы используем Mantis.

• Использование IDE в сочетании со стилью плагинов (в корпусе Java - CheckStyle, PMD) руководителя команды или даже менеджер проекта (если техническое лицо) может принудительно привести к руководящим принципам кода. на всю команду.

• Просто игнорируйте свой стиль - я работал над проектами Java, где некоторые разработчики выдвинули вьющиеся скобки на новую линию и имели тенденцию забыть пробелы, где они вообще нужны - и у меня не было никаких проблем с этим после кулачная неделя.

• Обсудить кодовые стили и компромисс, затем примените возможности IDE, упомянутые в первую точку.

Мне приходится работать с разработчиками каждый день, что значительно разные стили кодирования, чтобы моим и как разработчик, вы научитесь иметь дело с этим.

У вас есть 4 варианта, - Вы либо преобразуете их - Вы преобразуете - Вы предлагаете стандарт компании. - Вы живете с этим.

Если это что-то вроде приготовления переменных с типом, утверждают точку, что переменная должна быть достаточно описательной, так что его тип можно сделать.

Персонал против Spersonname VS Strpersonname <- Какой из них вы бы выбрали?

Если вы имеете в виду форматирование, Ctrl-A, K F <- Форматы Ваш код красиво в против:)

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

Если есть только два из вас, то есть только двое из вас, кто должен согласиться с общим стилем кодирования, который вы собираетесь использовать.

Если вы не можете договориться о стиле кодирования, то вам просто нужно с этим иметь дело. Попробуйте работать таким образом, который является продуктивным - и это означает, что не переписывает код другого человека, чтобы получить его, чтобы соответствовать вашему стилю.

Там могут быть некоторые стилистические аспекты, которые являются неприятными, и лучше всего сосредоточиться на тех. Стиль может легко превратиться в религиозную дискуссию, поэтому часто более эффективно сосредоточиться на количественных или эмпирических аргументах для изменений. Элегантность и физическая красота вашего кода могут не выиграть аргумент - но показывая случаи, когда стилистические изменения направились бы от ненужной отладки, могут быть эффективными.

Это проблема общения между людьми. Просто поговорите друг с другом. Не через код, лично.

Вам придется изобрести свой стиль подходящего для вас обоих и придерживаться этого. И если общение - это проблема, просто придерживайтесь идеи: «Когда я пишу свой собственный, я не прикасаюсь к другому коду»

[neilb@GONERIL NeilB]$ gcc -Wall -pedantic sw.c
sw.c: In function 'main':
sw.c:11: warning: ISO C forbids casts to union type
sw.c:12: warning: ISO C forbids casts to union type

От http://twidroid.com/plugins/

ACTION_SEND намерения Твидроида

Intent sendIntent = new Intent(Intent.ACTION_SEND); 
sendIntent.putExtra(Intent.EXTRA_TEXT, "This is a sample message via Public Intent"); 
sendIntent.setType("application/twitter");   
startActivity(Intent.createChooser(sendIntent, null)); 

Это зависит.

Если другому разработчику не очень легко идти, то я склонен просто идти с их стиль программирования, даже если я не согласен с ним, а не форсировать проблему - В этом случае это действительно вопрос что более неудобно, их стиль кодирования или горе я получу, подсуетившись?

Если другой разработчик более открытый, то я мог бы обсудить такие вещи, как кодирование/стандарты именования (Я надеюсь, что такие вещи, как общая архитектура, будут обсуждаться в любом случае)

Мы согласны с стандартным стилем кодирования и обеспечить его в форме файлов настроек Visual Studio.