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

Прилагательное без эго в названии было использовано с определенной целью. Сам термин Egoless говорит о многих проблемах, которые мы несем как разработчик, и поэтому заповеди были изложены почти 50 лет назад Джеральдом М. Вайнбергом в этой книге под названием Психология компьютерного программирования. Интересно выглядит само название этой книги (С каких это пор люди начали изучать психологию компьютерного программирования?). Сам я не читал, но планирую когда-нибудь попробовать. Однако мне понравились 10 заповедей, о которых он говорит.

Давайте поговорим о том, что мистер Джеральд назвал 10 заповедями программиста без эгоизма?

Поймите и примите то, что вы будете делать ошибки

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

Ты не твой код

Это была боль, которую я испытывал с собой. Раньше я был так привязан к своему коду и очень внимательно относился к людям, вызывающим в них проблемы. Однако суть в том, чтобы не так сильно привязываться к вашему коду. Цель кода - служить большим целям, чем вы, я или кто-либо другой. Будьте открыты для ОТЗЫВОВ. Будьте открыты для здоровой критики.

Неважно, сколько «карате» вы знаете, кто-то другой всегда будет знать больше

Примите тот факт, что есть люди, которые знают больше, чем вы. Обращайтесь за помощью, запрашивайте информацию, чтобы улучшить ваш модуль или код, даже если вы чувствуете, что в этом нет необходимости. Я помню случай, когда я написал Junit для класса валидатора фреймворка проверки JSR-бина, и мне было предложено не основывать свой Junit на фреймворке Spring. Меня это просто поразило. Я работал над этой частью и удалил зависимость от пружины. Мне было приятно, что я спросил, и еще более приятно, что мой код стал более надежным.

Не переписывайте код без консультации

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

Относитесь к людям, которые знают меньше вас, с уважением и терпением

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

Единственная константа в мире - это изменение

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

Единственный истинный авторитет проистекает из знания, а не из положения

Ваши знания должны владеть вашим авторитетом, а не вашим титулом. Развивайте свои знания, чтобы люди начали прислушиваться к вам, ценить ваши отзывы, искать совета, который вызовет к вам большее уважение. МСП даже с меньшим опытом пользуются уважением, потому что они являются экспертами в своей области, независимо от их звания или должности.

Боритесь за то, во что верите, но изящно примите поражение

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

Не будь «парнем в комнате»

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

Критикуйте код вместо людей - будьте добры к кодеру, а не к коду

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

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

Спасибо за чтение!! Пожалуйста, хлопните мне в ладоши, если эта статья добавила вам ценность вашего времени.