Как улучшить свои навыки веб-дизайна в этом году

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

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

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

Зачем стремиться к качеству кода в Agile?

Спасите свою команду из ада

В [LoopStudio] (https://loopstudio.dev/) мы говорим очень важную вещь: скоро вы обнаружите, что столкнулись с ужасным кодом, не понимая, как вы туда попали. Оказавшись в такой ситуации, становится все труднее понять, что происходит, и, как следствие, работа над этим проектом становится болезненной и напряженной.

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

Плохой код, плохие результаты…

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

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

Сделай это для себя

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

Подождите… Что вообще такое качество кода?

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

Дело в том, что вы должны понять истинный смысл. Каждая команда разработчиков должна установить и реализовать то, к чему они стремятся. Тем не менее, я могу дать вам инструменты, чтобы определить, соответствует ли ваш код этой цели, и, следовательно, заставить его сиять. Справедливо?

Потрясающий! Итак, это изображение, которое вы ищете:

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

Холодный перевод заключается в том, что команда должна знать о каждой строке кода, которая попала в репозиторий, что может означать одно из двух: либо текущее состояние этого кода является желаемым, либо оно отслеживается как технический долг. Слишком резко? Вне досягаемости? Не паникуйте, вы на шаг ближе к успеху…

Раскрытие тактики: как это сделать

Вы не получите того, чего не ищете

В целом качество — это отношение. Говорим ли мы о красивом дизайне, производительном приложении или надежной архитектуре, вы добьетесь успеха, если команда сосредоточит свои усилия на этом. Однако первым, кто определяет природу всего этого, является PO (Product Owner). Если приложение, которое вы создаете, имеет очень плохой UX из-за спешки с запуском функций, работающих на самом элементарном уровне, в производство, дизайнеров и разработчиков нельзя винить в этом. Они сделали то, о чем просили, за короткое время, которое у них было.

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

Завоевать или умереть…

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

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

Подготовка к игре

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

Тем не менее, предполагая, что команда сможет войти в дверь в первый же день, вам понадобится следующее:

• стек, который должен эффективно соответствовать требованиям, а также быть знакомым или простым в освоении для всех разработчиков.

• Архитектура, определяющая, как будут связаны все части.

• Определенное руководство по стилю, которое гарантирует, что все кодируют одинаково * - чем оно более подробное и строгое, тем лучше, но, по крайней мере, иметь чистую документацию с примерами-*.

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

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

Освоение навыков написания кода

Ладно, пора печатать. Но ждать! Остается ответить только на один вопрос, и это тот, который вы должны задать себе: «Как я могу сделать это лучше?» Вот и все, честно. Если ни у кого нет идеального ответа, почему бы не попробовать?

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

Идеальное поле битвы: проверка кода

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

На этом этапе лучше быть раздражающим, чем молчать. Если вам нужно оставить 20 комментариев в одном запросе на слияние, оставьте их, и да, поле иногда может быть грязным, с сильными противоположными техническими мнениями, разным мышлением и разными приоритетами. Тем не менее, если все сделано профессионально, это вехи на пути к созданию общей концепции вашей работы. Помните: задавать себе вопросы — это то, что продвинет вас дальше, так что применяйте это и возьмите с собой свою команду.

У этого процесса есть внутренняя и внешняя цель. Внутренняя цель заключается в том, чтобы рецензируемый PR был чистым и соответствовал стандартам команды (функциональность и производительность даны для всей этой статьи). С другой стороны, внешняя цель — это общее видение того, как эта интеграция может повлиять на остальную часть кода, а также место для появления новых идей, переоценки того, что вы делаете, и самое главное, возможность учить и учиться у своих товарищей по команде. Не потому, что вам нужно переместить тикет или достичь цели спринта, а потому, что вы растете вместе.

Ослабьте стрелку: чего следует избегать

У меня есть три очень важных совета для этого финального этапа: Нок, ничья, лузово!

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

С учетом сказанного, давайте исправим это:

Существует огромная разница между принятием решения, ориентированного на доставку, и срезанием углов.

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

Не будь безжалостным

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

Никогда не думайте, что вы знаете лучше, даже если вы

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

Вывод

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

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

Также опубликовано здесь