Боязнь веб-приложения не быть «будущим»

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

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

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

Я получил стажировку в качестве разработчика полного стека в январе, где я начну изучать интерфейсные фреймворки, но давление для завершения приложения возрастает, и я собираюсь полностью отказаться от приложения и начать заново, это то, что я делал раньше. В настоящее время приложение построено на PHP и jQuery (для вызовов AJAX) и использует MySQL для своей базы данных. Любые мысли о том, как я могу преодолеть этот ментальный блок, и чтобы мое приложение было масштабируемым? Заранее спасибо.

Совершенный враг хорошего.

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

Любые мысли о том, как я могу преодолеть этот ментальный блок, и чтобы мое приложение было масштабируемым?

Суть проблемы не в масштабируемости. Суть проблемы в том, что вы думаете, что вы поймете это правильно с первого раза .

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

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

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

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

Я абсолютно сочувствую этому чувству. Но привязанность к написанному вами коду является проблемой.

Единственное, что должно быть постоянным, - это ваше желание решить конкретную проблему . То, как вы решаете эту проблему, является второстепенным вопросом.

Если завтра будет выпущен новый инструмент, который уменьшает вашу кодовую базу на 80%, вы будете расстроены тем, что ваш код больше не используется; или вы будете рады, что ваша кодовая база стала меньше и намного чище / более управляемой?

Если первое, у вас есть проблема: вы не видите решение для кода . Другими словами, вы сосредотачиваетесь на коде и не видите более широкой картины (решение, которое оно стремится предоставить).

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

Это другая проблема для другого дня.

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

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

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

Другими словами: Генри Форд никогда не создавал автомобиль, который соответствует стандартам / ожиданиям 2018 года. Но если бы он не создал Model T, дефектную машину по современным стандартам, никто бы не начал использовать машины, не было бы автомобильной промышленности, и ни у кого не было бы машины, которую они могли бы затем улучшить.

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

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

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

Единственный плохой ответ здесь - «Я не знаю», так как он показывает отсутствие принятия обоснованных решений. То есть красный флаг для работодателя.

Я просто не знаю никаких веб-фреймворков и не знаю, с чего начать.

Та же проблема возникает здесь. Решение не думать больше, а действовать:

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

Чтобы узнать больше об этом, читайте Совершение мышление> мыслительный образ мышления . Автор объясняет это лучше, чем я.

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

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

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

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

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

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

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

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

Vanilla JS и, в меньшей степени, но все же в значительной степени JQuery, не страдают от этих проблем. За некоторыми заметными исключениями, приложения JQuery + AJAX, не зависящие от поведения конкретного браузера и не допускающие внешних зависимостей, где это целесообразно, продолжают работать через 10-15 лет после того, как они были изначально написаны с очень незначительными изменениями.

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

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

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

Лучшее, что вы можете сделать, чтобы «заглянуть в будущее» своего приложения, - это следовать передовым методам проектирования вашей системы, чтобы максимизировать слабую связь и разделение проблем. Не существует части вашего приложения, которая была бы защищена от устаревания, но вы можете многое сделать, чтобы изолировать код, который устарел по причине X, от кода, который не обязательно должен подвергаться влиянию X.

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

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

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

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

• Что произойдет, если завтра вы перенесете все свои статические ресурсы (сценарии, изображения и т. Д.) На отдельный сервер, сеть доставки контента и т. Д. Или начнете пытаться объединить их все вместе для повышения производительности?
• Что произойдет, если вы начнете размещать этот виджет на разных страницах или несколько его экземпляров на одной странице?
• Как начать тестирование AB на разных версиях виджета?

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

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

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

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

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

Прежде всего, «слом вещь и начать сначала» не является и не вариант ... В конце концов, вы не сказали , что у вас есть «полдюжины клиентов?» Вы еще не остановились, чтобы подумать, что они могут подумать о вашем заявлении, учитывая, что они сейчас (предположительно) "совершенно довольны вашей работой ?!"

Вот аналогия, которую я люблю использовать:

• «Моя работа состоит в том, чтобы строить дома для людей, в которых они будут жить, для людей, которые будут строить бизнес, и так далее». Моя работа состоит в том, чтобы сделать «эти невероятно крошечные, прославленные кусочки песка» для выполнения полезной работы. (Подобно тому, как строители дома изготавливают дома из гипсокартона, керамической плитки, бетонных блоков и блоков 2х4.)

• Однако, в то время как «гвозди», которые используют строители, действительно не сильно изменились за двести лет (за исключением перехода от «квадратного» к «круглому», а затем пригодного для использования с пневматическими гвоздильными машинами), технология то, что мы используем, постоянно меняется и иногда претерпевает очень глубокие изменения. ("Такие вот дела.")

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

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

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

Что касается фреймворка, я бы не беспокоился о производительности и масштабируемости. Это то, что вы можете легко проверить и, скорее всего, исправить. Большая проблема - безопасность. Веб-фреймворки обычно помогают вам написать правильный код аутентификации, файлы cookie, защиту CSRF и т. Д. Особенно с учетом вашего отсутствия опыта, лучше сосредоточиться на этой области.

Я начал писать комментарий об обучающих структурах, но в конце концов он превратился в нечто похожее на ответ, так что вот оно.

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

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

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

Эта статья привлекла много внимания к Hacker News 2,5 года назад: написать код, который легко удалить, а не просто расширить. Эта перспектива может помочь, а может и не помочь вам разобраться с вашей нынешней базой кода, но в будущем она может помочь предотвратить разочарование, вызванное перфекционизмом / чрезмерной инженерией.

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

Мне не нужно говорить, что удаление кода веселее, чем его написание.

(акцент мой)

Тема статьи на Hacker News может также стоить прочитать.

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

Держите ваш код в чистоте, следуйте принципам SOLID, DRY> google.

Примените балансировщик нагрузки как можно скорее.

Встаньте как минимум на два веб-сервера, обработайте сценарии балансировки нагрузки в коде.

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

Случай и точку см .: https://stackoverflow.com/questions/1276/how-big-can-a-mysql-database-get-before-performance-starts-to-degrade Точка верна, но 10 ГБ тривиален в качестве подопытного.