Уроки учебного курса по программированию. SI: первый блог.
Темы, о которых говорится в этой серии сообщений в блоге, полностью отражают мое мнение о вещах, которые я узнал во время буткемпа по программированию. Это ни в коем случае не правда, а моя история :)!
Инженеры-программисты — одни из самых территориальных существ, с которыми мне доводилось работать. Доверие в этом Королевстве часто очень низкое, и каждое существо готово сделать все возможное, чтобы добраться до вершины Королевства. Чтобы преуспеть в этом Королевстве, помимо языков программирования и компьютерных наук, вам нужно знать еще кое-что. Так что, если вы думаете о присоединении к этой колонии, читайте дальше.
Колония инженеров-программистов, программистов, разработчиков — как бы вы их ни называли, — интересная группа. По большей части все они очень хороши в создании, разработке и внедрении, но эта колония интеллектуалов быстро приходит в замешательство, когда сталкивается с сотрудничеством и компромиссом. Среди множества проблем, с которыми сталкивается эта колония интеллектуалов, одна проблема заключается в том, что создание структурированного здания может происходить разными способами. Есть много разных методов, которые эта группа может использовать для достижения одной и той же цели, и это часто может привести к проблемам в Королевстве. «Почему вы не вложили свои стили?», «Почему вы использовали LESS, Sass намного лучше!», «Что это за странные имена переменных?». Я уверен, что вы, разработчики, можете понять.
Большинство буткемпов дадут вам возможность участвовать в групповых проектах, если вы создаете приложение от начала до конца, вам обычно требуется, чтобы кто-то разрабатывал UI/UX, тогда у вас может быть один или два разработчика интерфейса и команда бэкенда. Разработчики. Хорошая команда понимает важность дизайна. Дизайн очень важен, но большинство программистов слишком зацикливаются на функциональности. «О, давайте просто заставим это работать, мы можем беспокоиться о том, чтобы приукрасить это позже». Важно иметь возможность визуализировать то, что вы планируете создать, и если в дизайне UI/UX нет четкого перехода от страницы к странице, его интерпретация останется на усмотрение того, кто пишет код для внешнего интерфейса. Это не лучший способ начать проект, и без прочной основы вы можете очень быстро получить очень запутанный пользовательский интерфейс.
Это подводит меня к следующему вопросу о выпуске минимально жизнеспособного продукта (MVP) в течение определенного периода времени. Вторым ключевым фактором, но не менее, если не более важным, является время. В зависимости от брифа вам, возможно, придется реализовать довольно много, в других случаях вам может не понадобиться, но крайне важно разбить каждую задачу на минимум и дать себе достаточно места для маневра, чтобы вносить изменения и запускать тесты. Например, в течение моей первой недели сборки мы потратили слишком много времени на дизайн, и это повлияло на рабочий процесс фронтенд-инженеров, потому что у них не было шаблона для начала, поэтому они создали приложение с минимальным стилем. Как вы понимаете, невыполненные задачи могут потенциально стать проблемой, если вам дали одну неделю на создание MVP проекта, а на оформление уходит 2–3 дня.
Последний фактор — как эффективно общаться с вашей командой. Итак, у вас есть временные рамки, дизайн также завершен. Теперь пришло время воплотить его в жизнь. Если вы не единственный человек, разрабатывающий весь проект, вы должны иметь возможность сообщать о каждой разработке, которую вы делаете, своей команде, чтобы все были в курсе. Но дело в том, что вы столкнетесь с другими, которые не всегда будут такими же четкими, как вы, и это нормально — до некоторой степени — вам просто нужно активизироваться и проявлять инициативу в отношении ситуации. Задавайте вопросы, обновляйте контрольный список своей команды, делитесь своим прогрессом. Вы можете спросить себя, почему я должен брать на себя эту дополнительную ответственность? и правда в том, что вам это не нужно, но это окупится в долгосрочной перспективе и сэкономит драгоценное время при написании кода, потому что вы сможете избежать таких проблем, как переписывание кода, создание дубликатов файлов и необходимость рефакторинга работы.
Это первая из серии сообщений в блоге, в которых рассказывается о моем опыте участия в буткемпе по программированию. Для тех, кто подумывает об учебном лагере по кодированию, или участвует в учебном лагере по кодированию, или просто интересуется разработкой программного обеспечения, я расскажу обо всем, что мне показалось интересным в моем путешествии.
