Как это возможно? Почему бы не написать код, если вы хотите создать приложение?

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

Причина 1. План сражения

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

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

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

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

Я обещал вам несколько советов и подсказок для боевого плана и, как всегда, сдержу свои обещания.

Первый совет будет заключаться в том, чтобы лучше изучить технологии, которые вы хотите использовать. Даже если вы работали с ним/ними, вы обнаружите, что вы никогда не охватывали все области и никогда не знали всей силы, которой они/они обладают. Думали ли вы о том, как можно добиться наилучшей производительности или наилучшей безопасности (скажем) в .NET, или как вы можете повторно использовать компоненты Angular или создавать пользовательские директивы, чтобы помочь вам с манипулированием DOM? Или, что еще лучше, вы думали, как использовать виртуальные таблицы?

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

Вторым советом будет подумать о том, какой у вас будет пользователь: это приложение, которое позволяет гостям (учетная запись не требуется), вам нужна учетная запись администратора или базовая учетная запись? Потому что на основе этих вариантов вам нужно будет увидеть, как они будут взаимодействовать, что они смогут увидеть или сделать, как вы можете манипулировать этим в коде.

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

Скажем, третий совет — подумайте, сколько денег вы хотите инвестировать, потому что самой дорогой частью может быть часть хостинга и развертывания (облако AWS и Azure не такие уж и дешевые), и если у вас небольшой бюджет, вам нужно будет найти другой провайдер.

После того, как вы найдете ответ на эти советы, вы увидите, что вопросы (и ответы) начнут приходить к вам, и все они помогут вам иметь твердую основу в качестве отправной точки.

Причина 2. Диаграммы

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

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

Небольшой совет, интегрируйте с самого начала принципы чистого кода (SOLID, KISS/DRY) и шаблоны проектирования, применимые в вашем случае, не откладывайте их, потому что гораздо сложнее начать рефакторинг кода.

Причина № 3: исследуйте архитектуру с открытым исходным кодом

Последняя и важная причина «не писать код» — изучить другую архитектуру приложений с открытым исходным кодом. Невозможно не найти (хотя бы) одну аналогичную деталь с изделием, которое вы хотите изготовить. Очень полезно посмотреть, как об этом думают другие люди, и вы увидите, что найдете случаи, о которых вы забыли, проигнорировали или даже не знали. Если вы не знаете, какую архитектуру рассмотреть, попробуйте поговорить с более опытным инженером-программистом, чтобы дать вам несколько советов или предложить архитектуру программного обеспечения, которая поможет вам с меньшими трудностями обнаружить проблемные области в вашем приложении.

Причина автора

Хм… После того, как я перечитал эти несколько мыслей, я понял, что не сказал слишком много о своем опыте и о том, как я понял, что эти 3 важные причины существуют. По крайней мере, для моего первого приложения мне очень не терпелось немедленно приступить к написанию кода и посмотреть, как моя рука и мозг смогут создать новое приложение с нуля (это было приложение, созданное для учебных целей).

Целый месяц я писал строки кода за строками кода в Angular 8 и .Net. Через какое-то время я понял, что застрял и больше не могу масштабировать свое приложение, так как у меня было много дублированного кода и я не знал, что хочу добавить дальше.

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

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

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