Какой была бы ваша стратегия?
Вам знакомо это чувство, когда у ваших менеджеров есть проблема, которую нужно решить, и они просят вас придумать решение?
Программист, разработчик, кодировщик или ботаник внутри вас думают: «Да, я собираюсь раскачать это! Я собираюсь поразить всех своим супер-умным решением ".
Если вам знакомо это чувство, продолжайте читать, потому что это может вызвать несколько опасных ситуаций для бизнеса.
В этой истории я хочу погрузиться в опасность чрезмерной инженерии. Я хочу показать вам, что существует очень тонкая грань между созданием достаточно хорошего решения и чрезмерно сложными решениями.
Я не собираюсь говорить вам, какое лучшее решение. Я хочу, чтобы вы хорошенько обдумали это, потому что эти ситуации и решения могут иметь большое влияние на график фазы разработки.
Создайте надежную архитектуру
Большинство разработчиков счастливы погрузиться в проблему и найти лучшее решение. Мы очень стараемся вложить в это решение все, что в наших силах и возможностях.
Вы, вероятно, узнаете великолепную архитектуру, которую придумали вы и ваша команда, и вы все были в восторге от нее.
Может быть, вы были в огне и уверены, что собираетесь это раскачать. Несомненно, что-то между этим и есть.
А потом приходит ваш менеджер, и у вас есть шесть месяцев.
Ой, вот и план!
Но вы и ваша команда находите способ сделать архитектуру немного менее классной - но все же достаточно крутой.
Вы и ваша команда начинаете строить изо дня в день.
Многоразовый или нет
Проходят недели, а вы создаете множество компонентов.
Он получает данные из API и показывает все данные.
Вы создаете сервис для преобразования всех моделей данных в формы. Это супер круто!
Таким образом, вы создаете сервис, который можно использовать везде.
Но что происходит при изменении модели данных? Это все еще будет работать или у вас и вашей команды будут большие проблемы, потому что все подключено к этой услуге?
Этот крайний срок все ближе и ближе!
Итак, что лучше: заставить все компоненты использовать эту службу или создать ее специально?
Худой или нет
Может быть, будет лучше, если вы и ваша команда упростите задачу. Просто построение того, что было задано или определено очень бережливым способом - не более того.
Иногда лучше начать именно с этого! Просто построение того, что является абсолютным минимумом решения. Пусть сначала его протестируют тестировщики, менеджеры или пользователи.
После этого у вас есть данные для его улучшения.
Может поток хороший, а вот производительности не хватает. Тогда вы сможете это улучшить!
Вы удаляете ненужный код и, возможно, делаете некоторые части повторно используемыми.
Это лучшее решение или лучше проработать полную архитектуру?
Гибкость, читаемость и масштабируемость
Всем известно, что эти качества очень важны. Вы хотите, чтобы ваш код оставался читабельным, чтобы другие могли внести в него свой вклад.
С другой стороны, он должен быть гибким, чтобы вы могли использовать его в течение длительного времени.
Кроме того, вы хотите сделать приложение масштабируемым несколькими способами. Но как это сделать, если вы хотите сохранить читаемость?
Если вы сделаете все возможное, чтобы добиться гибкости и масштабируемости, это может вызвать большую сложность, снижающую удобочитаемость. Вы хотите, чтобы?
Если вы сделаете все возможное для удобочитаемости, это может вызвать проблемы с производительностью, которые снизят гибкость и масштабируемость приложения. Вы хотите, чтобы?
Вы видите между ними очень тонкую грань. Выбор определяет успех приложения или мешает ему.
Конкретный или общий
Как я сказал ранее о бережливом методе, вы можете начать очень конкретно и построить только минимальное решение.
Но на это может уйти больше времени. Таким образом, вам может потребоваться больше итераций для улучшения приложения.
Вы также можете начать с отличного плана надежной архитектуры, которая будет очень универсальной и гибкой.
Это может помочь создать приложение, которое повысит гибкость и масштабируемость. Но какой ценой?
Создание универсальных классов, функций или компонентов снизит удобочитаемость - особенно для людей, которые только в это погружаются.
Это может даже стать проблемой, если этот код потребуется изменить из-за нового понимания пользовательского опыта.
В тот момент что было лучше написать более конкретно или обобщенно?
Я собрал парочку начинающих разработчиков со всего мира на сервере Discord, не стесняйтесь присоединяться.
Заключение
Очень много открытых вопросов!
При создании приложения существует очень тонкая грань между удобочитаемостью, гибкостью и масштабируемостью.
Если вы переходите к бережливому производству и начинаете очень конкретно, когда вы начнете улучшать и делать код более динамичным? Когда можно сделать код менее читабельным?
Может быть, лучше, чтобы некоторые части были конкретными, а некоторые - общими.
Но что важнее всего - независимо от того, что решите вы и ваша команда, - это то, что вы говорите друг с другом об этом. Не оставляйте места для интерпретации. Это станет смертельным для сплочения команды.
Независимо от того, что решите сделать вы и ваша команда, запишите это. Сообщите своему менеджеру, что вы решили, и работайте над этим.
Если что-то не работает, меняйте это, пока не заработает.
Если у вас есть какие-то мысли по этой теме, поделитесь ими в комментариях, чтобы мы могли учиться друг у друга.
Удачного кодирования! 🚀
Читай еще от меня ✌️
Я написал еще много историй, которые могут вам понравиться, надеюсь, вам понравится!
