Как вы код без обид?

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

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

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

ОБНОВИТЬ

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

Это магазин Perl, но я уверен, что они применимы к любому языку

ОБНОВЛЕНИЕ 2

Технический директор, который впоследствии стал генеральным директором, был полным манией величия и был основным источником этих жалоб. Если вы не делали то, что ему нравилось, будь то Mac или Emacs, или 4 табуляции вместо 2, или одевались определенным образом, вы были хуже. Это была ужасная ситуация, которую я пытался исправить, но единственный правильный ответ для меня - уходить.

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

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

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

Кроме того, не бойся быть собой . Вы можете быть новым парнем, но вы являетесь членом команды, и ваши мнения верны. Если вы можете придумать лучшие способы что-то сделать, предложите это. Уважайте других членов команды и общепринятый способ ведения дел, но не позволяйте им подталкивать вас. Компания не приняла бы вас на работу, если бы не оценила ваш вклад.

Это очень поможет, если вы найдете кого-то в команде, кто кажется дружелюбным и особенно готов ответить на вопросы. (Если это хорошая команда, это должен быть каждый, но команды не всегда такие.) Ваш начальник, возможно, назначил кого-то, чтобы помочь вам начать. Используйте этого человека в качестве ресурса. Запишите вопросы по мере их возникновения, а затем попросите этого полезного человека время от времени отвечать на них.

Что касается проверки в коде «слишком часто», почему бы не создать собственную ветку для ваших периодических коммитов, а затем объединиться с транком, когда ваш код будет готов? В этом нет никого другого вреда, и когда ваши коллеги увидят, что вы получаете преимущества от SVN, которые им нравятся, они могут последовать вашему примеру.

Что касается пробелов: просто сделайте это, однако код уже делает это. Плыть по течению

Относительно проверок SVN: документируйте их очень четко. Это помогает людям понять, что происходит в коде. (Продолжение: каковы их возражения против частых проверок?)

В общем: начните создавать стандартный документ по кодированию. Не пытайтесь заполнить его 100 правилами. Просто добавьте правила по мере их появления.

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

Что касается стиля форматирования кода (пробелы, табуляции, куда уходят фигурные скобки и т. Д.), Вы должны следовать преобладающему стандарту в коде. Если его нет, я не думаю, что им есть на что жаловаться. Когда дело доходит до того, ставите ли вы фигурные скобки в собственную строку или нет, ставите пробелы вокруг списков параметров метода и т. Д., Это личное предпочтение, и вы должны уступить преобладающему стилю, потому что в долгосрочной перспективе это действительно не так. неважно . Важно то, чтобы быть последовательным.

Когда дело доходит до проверки кода в SVN, я бы старался проповедовать то, что, по моему мнению, является правильным способом сделать что-то, а не позволять себе кататься. Я не проверяю свой код, если он не создает и не проходит тесты, и если я делаю несколько несвязанных изменений, я делю свою работу на несколько коммитов. Если на какое-то время что-то сломается, я создаю ветку и делаю там свою работу. Коммиты получают описательные комментарии. По моему опыту, это работает лучше, чем метод «отметьте кучу изменений в пятницу в 5:00», и, похоже, это преобладающая «лучшая практика», согласно большинству того, что я читал здесь и в других местах.

Сначала прочитайте их документ по соглашениям о кодировании (если у них его нет, попросите их написать так, чтобы вы могли следовать ему)

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

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

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

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

Лучшее, что вы можете сделать, это следовать советам, которые они вам дают. Нет возможности заранее сказать, чего они хотят. Если вы не экстрасенс.

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

Я бы посоветовал вам не приписывать рекомендации в документе отдельным лицам (поэтому «блоки кода должны иметь три пробела», а не «Билл сказал мне, что блоки кода должны иметь три пробела»). Однако, если вы можете записывать эту информацию ненавязчивым способом (например, в комментарии к коммиту, напишите «добавлено правило об отступах на основе совета Билла»), то это может помочь в разрешении противоречий, потому что вы можете сразу получить две точки зрения. на что-то. На самом деле я думаю о том, что если вам дают противоречивые советы, вам нужно избегать того, чтобы стать футбольным игроком, которого избивают двое коллег, которые с чем-то не согласны. Это что-то вроде подхода «прикрывай свою задницу», но это может быть разумным.

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