Программирование пары с неровным числом членов команды? [закрытый]

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

(a) согласен с ними, когда вы посмотрите на это во второй раз,

(b) не согласен?

Если (a), то проблема в том, что вы сами не полностью разъясняете ваш код, когда вы его пишете. Поскольку парное программирование - единственное, что заставляет вас писать достойный код, я полагаю, я бы порекомендовал, чтобы «лишнее» работало над задачами, которые не связаны с написанием длинных участков плохого кода: поиск ошибок; возможно, написать тестовый код, так как это, как правило, немного менее дьявольски. Между тем, работайте над улучшением своих навыков написания лучшего кода - возможно, сделайте обзор своего собственного кода, написанного несколько месяцев назад, и сделайте заметки о том, что с ним было не так.

Если (b), то ваша проблема несовместима выражения ваших идей. Код может быть неплохим по вашим стандартам, но он взаимно непонятен, что в корпоративной среде означает, что это плохой код. Парное программирование означает, что то, что вы пишете, является компромиссом, который понимают двое из трех из вас, но на самом деле это не решение. Вам нужно прийти к взаимному соглашению о том, что вам кажется наиболее трудным в коде друг друга, и прекратить это делать. И вам всем срочно нужно начать думать о «качестве кода» в терминах «моим двум коллегам понравится этот код», а не «Мне нравится этот код».

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

Не то чтобы мой код был лучшим в мире, но я действительно думаю, что получил пользу от того, что моя первая работа была в компании с 30 с лишним программистами, поэтому я увидел широкий спектр способов мышления. Также несколько примеров того, «чего не следует делать», когда один программист сделал что-то, что никто не мог легко понять, и, следовательно, можно было окончательно назвать плохим. При наличии всего 3 человек непонятно, означает ли разница во мнениях 2: 1, что 1 - урод или разумное меньшинство. Когда я что-то делал, и 4 или 5 человек могли взглянуть на это и сразу сказать «эээ, не делай этого», тогда я начал действительно верить, что это была просто глупая идея.

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

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

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