Как стать автором
Обновить

Кодекс разработчика-джентльмена

Время на прочтение 3 мин
Количество просмотров 2.6K

Кодекс разработчика-джентльмена


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

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

Разработчик-джентльмена всегда вежлив


Ваше плохое настроение или мания величия — это еще не повод портить настроение другим людям. Думаю никому не понравиться если ему нагрубят. Поэтому старайтесь и Сами не грубить.

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

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

Разработчик-джентльмен всегда уважает свое время, а значит и уважает время других


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

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

Разработчик-джентльмен уважает код и технические решения своих коллег


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

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

Зазработчик-джентльмен не правит код другого разработчика без его ведома


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

Во-вторых, Вы сами, скорей всего, не знаете всех особенностей функционала, который собираетесь переписывать. В итоге ни автор, ни Вы полноценно не знаете код, который был обновлен.

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

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

Разработчик-джентльмен не критикует чужой код без аргументов и без альтернатив


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

Бессмысленная критика приводить только к раздору в команде, что не очень сказывается на результате.

Разработчик-джентльмен также умеет принимать критику достойно


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

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

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

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

Разработчик-джентльмен пишет код в общем стиле


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

То же самое касается проектов. Старайтесь всегда придерживаться общепринятых правил и стандартов, даже если они Вам не нравятся, но команды им следует.
Теги:
Хабы:
-10
Комментарии 11
Комментарии Комментарии 11

Публикации

Истории

Работа

Ближайшие события

Московский туристический хакатон
Дата 23 марта – 7 апреля
Место
Москва Онлайн
Геймтон «DatsEdenSpace» от DatsTeam
Дата 5 – 6 апреля
Время 17:00 – 20:00
Место
Онлайн