Как работать с программистом, у которого радикально другой стиль программирования?[закрыто]
-
23-09-2019 - |
Вопрос
Кто-нибудь работал с программистом с радикально другим стилем кодирования?Как вам удается играть вместе, не желая удалять и переписывать код друг друга?
Решение
Выберите один и идите с ним.
Если вам трудно прийти к согласию, найдите время, чтобы перечислить плюсы и минусы, включая:
- поддержка инструментов для автоматического форматирования (навскидку я знаю, что Eclipse и Visual Studio могут сделать это с помощью файла настроек)
- соответствие общему отраслевому стандарту (Sun опубликовала стандартные соглашения для Java, возможно, есть эквивалент на вашем языке?)
- соответствие или стоимость модификации уже существующего источника (если у вас миллион строк в одном стиле, насколько сложно будет обновить этот код до нового стиля?)
- ...любой другой фактор, который любой из вас считает важным (сюда может входить стоимость ознакомления с новым стилем)
Если вы обнаружите, что работаете с кем-то, слишком упрямым, чтобы меняться и адаптироваться, у вас есть более серьезная проблема, чем конфликт стилей кода, и решение этой проблемы выходит за рамки этого вопроса.
Если вы тот человек, который может адаптировать свой стиль, избегайте утверждений: «Ну, если бы мы выбрали мой способ...".Если вы договорились о едином стиле, полностью придерживайтесь его.
Однако прежде чем перейти к этому моменту, вам, вероятно, следует спросить себя:каковы преимущества наличия согласованного кода?Вы можете обнаружить, что стоимость единообразного кода (раздражающего другого разработчика) не стоит выгоды.
Другие советы
Мы согласовываем стандартный стиль кодирования и применяем его в виде файлов настроек Visual Studio.
Это проблема человеческого общения.Просто поговорите друг с другом.Не через код, лично.
Свяжитесь с другим разработчиком.Согласитесь на стиль кодирования, который сочетает в себе лучшее из обоих миров?
Когда вы говорите «стиль кодирования», вы имеете в виду форматирование или разницу в том, как вы структурируете свой код?
Что касается стиля кодирования, команде, вероятно, следует иметь форматировщик стилей и применять какой-то формат перед фиксацией.таким образом, слияния не доведут слияние до безумия.
Боюсь, что для структурных различий в коде нет простого решения.Если вы заядлый программист-спагетти, а не фанатичный объектный программист, вам придется сесть за стол и обсудить оба подхода и то, как они применяются в вашем конкретном проекте.Помните, что однозначного ответа не существует, все зависит от контекста.Также попробуйте обратиться к кому-нибудь, кого вы оба уважаете, чтобы он порекомендовал лучшие практики, провел проверку кода для проверки кода и помог определить общий подход (технический руководитель или технический руководитель).
Используя IDE в сочетании с плагинами проверки стиля (в случае Java — Checkstyle, PMD), руководитель группы или даже руководитель проекта (если он технический специалист) может навязать рекомендации по стилю кода всей команде.
просто игнорируйте его стиль - я работал над проектами Java, где некоторые разработчики помещали фигурные скобки в новую строку и имели тенденцию забывать пробелы там, где они обычно необходимы - и после первой недели у меня не было с этим никаких проблем.
обсудите стили кода и компромиссы, а затем примените возможности IDE, упомянутые в первом пункте.
Я собираюсь ответить на вопрос о «мягких навыках», необходимых для того, чтобы ладить с кем-то, чей стиль программирования совершенно отличается от моего.Обычно я стараюсь сосредоточиться на трех простых принципах;профессионализм, доверие и эго.
С точки зрения профессионализма просто неприемлемо просто переписать или удалить чей-то код, потому что его стиль отличается от вашего.Профессиональный подход заключается в том, чтобы сначала понять, почему я считаю свои идеи/стиль/предпочтения лучшими.Затем я ожидаю, что сяду с другим человеком и обсужу свои точки зрения, и, что самое важное, сохраняю непредвзятость.То, что мне нравится моя идея, не означает, что она правильная или верная.Настоящий профессионал сможет и захочет признать, что идеи других столь же ценны и исходят из другой точки зрения.
Лично мне нужно доверять своим коллегам-разработчикам.Старая поговорка гласит: доверие нужно заслужить, а не принести, и это справедливо для разработки программного обеспечения.Доверие можно построить на основе различных источников, таких как обмен информацией, идеями и кодом.Продуктивная команда обычно имеет неявный уровень доверия между разработчиками.
Одна из главных причин, по которой люди не ладят, — это эго.Наше эго позволяет нам чувствовать угрозу, превосходство, смущение и множество других человеческих эмоций.Оставить свое эго в стороне и поговорить о наших проблемах с другим человеком — это всегда хорошее начало.
Твой стиль кодирования не является нормой. Его стиль кодирования не является нормой. А Норма — это стиль кодирования, выбранный проектом или, иногда, всей организацией (и это должно быть где-то задокументировано), и вы оба должны ему соответствовать.Для обеспечения соответствия можно использовать такие инструменты, как Checkstyle (с Java).Если вы используете такой инструмент, распространите его файл конфигурации.Также распространяйте файлы конфигурации форматирования IDE.
Многие проекты с открытым исходным кодом (или корпоративные) используют эти принципы (см., например, XWiki). Стиль кода Java, Стиль кода Maven и соглашения о коде или Руководство по стилю языка C для разработчиков Apache).Это работает для разработчиков, разбросанных по всему миру, не говорите мне, что это не может работать для разработчиков, находящихся в одной комнате.
Если в вашем проекте нет каких-либо стандартов кода, возможно, пришло время их определить, и я просто надеюсь, что вы сможете сделать это как двое взрослых (на самом деле, это должно быть командное решение).При необходимости напомните, почему важен единый стиль кода (для лучшей читаемости, для различий).Если, к сожалению, это не сработает, пусть начальник решит за вас.
Мне приходится каждый день работать с разработчиками, стили кодирования которых сильно отличаются от моего, и как разработчик вы учитесь с этим справляться.
У вас есть 4 варианта, - вы либо конвертируете их - вы конвертируете - вы предлагаете стандарт компании.- ты живешь с этим.
Если это что-то вроде добавления типа к переменной, докажите, что переменная должна быть достаточно описательной, чтобы можно было определить ее тип.
personName vs sPersonName vs strPersonName <- какой из них вы бы выбрали?
если вы имеете в виду форматирование, ctrl-a, k f <-- красиво форматирует ваш код в VS :)
Я редко встречаюсь с одним разработчиком, с которым мне приходится согласовывать стили кодирования, и что разные группы или проекты имеют разные стили.Вам придется научиться адаптироваться к различным стилям кодирования.
Если вас только двое, то только двое из вас должны договориться об общем стиле кодирования, который вы собираетесь использовать.
Если вы не можете договориться о стиле кодирования, то вам просто придется с этим смириться.Постарайтесь работать продуктивно, а это значит, что не нужно переписывать чужой код только для того, чтобы он соответствовал вашему стилю.
Могут быть некоторые стилистические аспекты, которые вызывают затруднения, и лучше сосредоточиться на них.Стиль может легко превратиться в религиозную дискуссию, поэтому зачастую более эффективно сосредоточиться на количественных или эмпирических аргументах в пользу изменений.Элегантность и физическая красота вашего кода могут не победить в споре, но демонстрация случаев, когда стилистическое изменение предотвратило бы ненужную отладку, может быть эффективным.
Это зависит.
Если другой разработчик не особенно спокоен, то я склонен просто следовать его стилю программирования, даже если я с ним не согласен, вместо того, чтобы форсировать проблему - в этом случае это действительно вопрос что более неудобно, их стиль программирования или горе, которое я получу, подняв шум?
Если другой разработчик более непредубежден, я мог бы обсудить такие вещи, как стандарты кодирования/именования (я надеюсь, что такие вещи, как общая архитектура, все равно будут обсуждаться).
Вам придется придумать какой-то стиль, подходящий вам обоим, и придерживаться его.А если общение является проблемой, просто придерживайтесь идеи:«Когда я пишу свой, я не трогаю чужой код»