Кодекс iOS джентльмена
Большинство проектов разрабатываются командой разработчиков. Как правило качество результата командной работы зависит от атмосферы царящей в команде. Для поддержания гармонии каждый разработчик должен всегда оставаться джентльменом. Поэтому я хочу представить основные, по моему скромному мнению, правила кодекса iOS джентльмена.
iOS потому, что я сам iOS разработчик и являюсь частью команды. Правила довольно общие, поэтому подойдут для любого направления в разработке программного обеспечения и не только.
iOS джентльмен всегда вежлив
Ваше плохое настроение или мания величия — это еще не повод портить настроение другим людям. Думаю никому не понравиться если ему нагрубят. Поэтому старайтесь и Сами не грубить.
Бескультурье и хамство портит отношения между участниками команды, а в командной работе очень важно работать сообща. Обиды друг на друга или личная неприязнь могут не только замедлить прогресс, но и внести дополнительные проблемы.
Всегда и при любых обстоятельствах нужно держать себя в руках и стараться быть вежливым.
iOS джентльмен всегда уважает свое время, а значит и уважает время других
Если у Вас есть срочная проблема, в которой может помочь коллега, это еще не означает, что нужно отвлекать коллегу от его работы. Возможно сейчас идет очень важный мыслительный процесс и если его прервать, то Ваш коллега может потерять много времени на восстановления всей картины проблемы, которую он решал.
Стоит вежливо уточнить, может ли нужный вам человек уделить время и помочь Вам. Если он сильно занят, то скорей всего он сможет помочь чуть позже.
iOS джентльмен уважает код и технические решения своих коллег
Всегда нужно помнить, что каждый блок кода — это наилучшее решение, которое смог придумать автор на тот момент времени и при тех обстоятельствах, когда этот код писался. Поэтому не стоит лишний раз устраивать выяснения почему код написан так плохо. Это касается моментов, когда вообще нет необходимости что-либо менять.
Думаю, каждый может вспомнить момент, когда он пытался переписать код, который выглядел ужасно. При этом натыкался на ранее неочевидные проблемы, которые решал этот код. И в попытках решить эти проблемы более элегантным способом, писал еще более ужасный код.
Следует это помнить, перед тем как портить кому-то настроение неуместной критикой и воздержаться от подобных действий.
iOS джентльмен не правит код другого разработчика без его ведома
Даже если Вы знаете как сделать лучше, не стоит молча переписывать плохой код. Во-первых, автор кода, который по мнению окружающих несет ответственность за этот участок кода, может потерять нить понимания в обновлениях. И при попытках что-то поменять он попадет в затруднительную ситуацию.
Во-вторых, Вы сами, скорей всего, не знаете всех особенностей функционала, который собираетесь переписывать. В итоге ни автор, ни Вы полноценно не знаете код, который был обновлен.
В -третьих, если автор кода не узнает, о том, что он сделал что-то плохо, то он будет продолжать делать так как делал. А как мы знаем в команде результат работы каждого участника влияет на всю команду.
В таких случаях следует сначала обратиться к автору, уточнить его мнение. Возможно, Вы ошибаетесь и Ваше решение, которое Вам казалось более подходящим, не является таковым. А в случае, если Вы оказались правы, то вы поможете своему коллеге и соответственно поможете общему делу.
iOS джентльмен не критикует чужой код без аргументов и без альтернатив
Когда все же дело доходит до критики, а в командной работе это неизбежно, то это стоит делать правильно. Во-первых, критиковать код можно, когда от качества этого кода зависит решение Вашей задачи. Во-вторых, критиковать можно только в случае, если Вы точно знаете как сделать лучше.
Бессмысленная критика приводить только к раздору в команде, что не очень сказывается на результате.
iOS джентльмен также умеет принимать критику достойно
Никто не идеален и никто не пишет идеальный код. Мы все время обучаемся и усовершенствуем наши навыки, в том числе и в разработке ПО. Критика является одним из самых эффективных механизмов обучения. И нужно не только уметь подавать критику но и достойно ее принимать.
Не стоит реагировать агрессивно на чужую критику. Это только оттолкнет окружающих. И в дальнейшем Ваши ошибки в коде могут быть своевременно не выявленные только потому, что коллега не стал Вам ее сообщать, не желая провоцировать скандал.
Если критика действительно полезна, то стоит поблагодарить человека, который указал на Ваши погрешности.
Если же критика не обоснована и Вы абсолютно уверены, что ваше решение в коде является достаточно хорошим если даже не лучшим, то стоит спокойно аргументировать свою правоту. Привести доводы в опровержение критики.
iOS джентльмен пишет код в общем стиле
Думаю всем будет понятна аллегория, что если в лодке несколько гребцов и один из них будет грести в противоположную сторону, то на скорость движения лодки это повлияет только негативно.
То же самое касается проектов. Старайтесь всегда придерживаться общепринятых правил и стандартов, даже если они Вам не нравятся, но команды им следует.
rinat_crone
Я так понимаю, это Вы своему тим–лиду писали? По одному пункту точно с другой стороны могу подсветить: если лид правит ваш код «втихую», то скорее всего задача была рассчитана на день и должна была быть сдана ещё неделю назад. Бизнес не должен нести убытки из-за ранимости отдельных членов команды. Конечно, это не отменяет факта, что либо до, либо, скорее, после внесённых изменений необходимо о них сообщить «владельцу» кода, и, желательно, с пояснениями. Но, ИМХО, относиться к таким вещам необходимо проще. Набирайтесь опыта.
ruslanshevtsov Автор
Вы ошиблись, адресовано скорей джуниор и миддл разработчикам, которые, просматривая код, вдруг решают что-то порефакторить. И проблема тут не в ранимости, а в том что в результате изменений в коде ни автор не может быстро сориентироваться ни тот, кто рефакторил до конца не понимает, для чего этот код был написан. Как раз таки появляются проблемы для бизнесса, увеличиваются затраты времени на внесения изменений или багфикса.
ruslanshevtsov Автор
Отдельно хочу прокоментировать ситуацию: задача на один день, а ее неделю не сдают. Это уже вопросы к тимлиду. Зачем отдал задачу тому, кто не может ее сделать? Разве нет понимая уровня способностей своих подчиненных? Почему не поинтересовался прогрессом на следующий день, когда предполагалось завершение работы над задачай? Почему ждал неделю и потом сам все исправил? Это, ИМХО, сведетельствует о некомпитентности тимлида, который неправильно распределяет задачи и не следит за прогрессом.