Побоювання того, що веб-додаток не є "захищеним від майбутнього"

Я веб-розробник невеликого локального веб-додатку SaaS. Наразі це близько півтисячі клієнтів.

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

Будучи студентом університету, який претендує на стажування, у мене були роботодавці сумнівом у виборі не використовувати будь-яких веб-рамок під час співбесіди, що лише змусило мене ще більше сумніватися у своїй попередній роботі. Я просто не знаю жодної веб-рамки і не знаю, яку з них почати використовувати.

У січні я пройшов стажування як повнорозмірний розробник, де я почну вивчати фронтальні рамки, але тиск, щоб закінчити додаток, зростає, і я розглядаю можливість повністю скасувати додаток і почати спочатку, що я робив раніше. Зараз додаток вбудований у PHP та jQuery (для дзвінків AJAX) та використовує MySQL для своєї бази даних. Будь-які думки про те, як я можу подолати цей ментальний блок і переконатися, що додаток буде масштабованим? Заздалегідь спасибі.

Досконалий - ворог добра.

Або кажучи іншим способом, не хвилюйтеся про це сьогодні. Якщо ваш додаток робить те, що йому потрібно зробити, це добре. Це НЕ погана річ , щоб переписати частини програмного забезпечення далі вниз по лінії; до цього моменту ви 1) чіткіше знаєте, що ви намагаєтеся побудувати, і 2) знаєте, які біти насправді є вузьким місцем. Ви можете витратити величезну кількість часу, написавши додаток, яке охоплює мільйон користувачів, але це не буде кращим для ваших поточних шести клієнтів, ніж те, що у вас сьогодні .

Будь-які думки про те, як я можу подолати цей ментальний блок і переконатися, що додаток буде масштабованим?

Суть проблеми - не масштабованість. Суть проблеми полягає в тому, що ви вперше зрозумієте це .

Ви повинні зосередитись на написанні чистого коду. Тому що чистий код максимізує зручність, коли вам (неминуче) доведеться щось змінити в майбутньому. І це справжня мета, яку ви повинні мати.

Що ви зараз намагаєтеся зробити, це спробувати придумати ідеальний код для написання. Але навіть якщо вам це вдасться зробити, хто каже, що вимоги не змінюватимуться, або ви, можливо, приймали свої рішення на основі неправильної інформації чи неправильної комунікації?

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

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

Я абсолютно співчуваю цим настроям. Але приєднатися до написаного вами коду - це проблема.

Єдине, що повинно бути постійним, - це ваше бажання вирішити конкретну проблему . Як ви вирішуєте цю проблему, є лише другорядним питанням.

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

Якщо перший, у вас є проблема: ви не бачите рішення коду . Іншими словами, ви зосереджуєтесь на коді і не бачите більшого зображення (рішення, яке воно має на меті запропонувати).

Мені страшно, що вся додаткова робота, яку я виконую, буде скасована найближчим часом, коли додаток виявиться не таким масштабним, як бізнес росте.

Це вже інша проблема для іншого дня.

По-перше, ви будуєте щось, що працює. По-друге , ви вдосконалюєте код, щоб виправити будь-які недоліки, які він все ще може показувати. Те, що ви зараз робите, - це стриматись над першим завданням, не боячись потім виконати друге завдання.

Але який ще варіант є? Ви не можете сказати майбутнє . Якщо ви витратите свій час на роздуми над майбутніми можливостями, то все одно довідаєтесь . Здогадка завжди схильна до того, що неправильно помер.

Натомість складіть програму та доведіть, що дійсно є проблема. І як тільки проблема буде зрозумілою, тоді ви почнете її вирішувати.

Інакше кажучи: Генрі Форд ніколи не будував автомобіль, який відповідає стандартам / очікуванням 2018 року. Але якби він не побудував Model T, несправний автомобіль за сучасними мірками, ніхто б не почав користуватися автомобілями, не було б автомобільної промисловості, і ніхто не мав би автомобіль, який вони могли б потім спробувати вдосконалити.

У мене роботодавці ставили під сумнів свій вибір щодо використання веб-рамок під час співбесіди, що лише змусило мене ще більше сумніватися в попередній роботі.

Важлива частина тут не в тому, які рамки ви використовуєте (будь-який роботодавець, який вас оцінює, не виконує свою роботу належним чином). Важлива частина тут - знати, що ти робиш, і чому ти це робиш .

Наприклад, ви можете уникати існуючих рамок спеціально, тому що хочете дізнатися, чому рамка корисна, спочатку зробивши її важким шляхом. Або ви могли б спробувати створити власну основу.

Єдина погана відповідь тут - «я не знаю», оскільки це свідчить про відсутність прийняття обґрунтованих рішень. Те є червоний прапор для роботодавця.

Я просто не знаю жодної веб-рамки і не знаю, яку з них почати використовувати.

Ця ж проблема виникає і тут. Рішення - не думати більше, а скоріше діяти:

• Перестаньте міркувати про ідеальну відповідь .
• Виберіть рамку. Якщо у вас немає переваг, виберіть випадковий. Використовуйте дартс, закатайте штамп, переверніть монету, виберіть картку.
• Використай це.
• Вам сподобалось його використовувати? Чи було щось, що вас дратує?
• Подивіться, як запобігти цим поганим стихіям. Ви неправильно використовували фреймворк, чи це так, як має працювати рамка?
• Як тільки відчуєте, що у вас є захоплення рамки (незалежно від того, подобається вам це чи ні), виберіть новий фреймворк і повторіть цикл.

Щоб дізнатись більше про це, читайте «Мислення»> мислячий спосіб мислення . Автор пояснює це краще, ніж я можу.

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

Якщо тільки поточна база даних коду не є абсолютно нездійсненним безладом; ти приймаєш протилежне рішення.
Розробники часто думають, що викидання речей було б кращим вибором. Це дуже поширене почуття. Але це рідко правильний вибір.

Викидати код і починати з нуля - це як застрягти в трафіку на шляху до роботи, переживаючи, що ти запізнишся на роботу (пропустиш термін), а замість цього їдеш додому і спробуєш знову їхати тією ж дорогою. Це не має сенсу. Можливо, ви застрягли в дорожньому русі, але ви все ще ближче до роботи, ніж ви були вдома.

Незважаючи на величезну кількість грошей, Facebook та Google вклали в маркетинг, щоб переконати вас у противному, рамки передньої частини існують з двох основних причин:

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

Вам, напевно, потрібно знайти рамку для вирішення цих проблем, якщо ваш додаток за своєю суттю є надзвичайним, якщо обсяг стану програми, який ви зберігаєте на стороні клієнта, досить складний, якщо ви очікуєте, що велика кількість клієнтів із поганою затримкою мережі (мобільний, або віддалений від сервера) або якщо є сильна потреба в бізнесі для підтримки особливо розвинених CSS або створення динамічних елементів.

Рамочний маркетинг хоче, щоб ви повірили, що їхній спеціальний метод архітектури збільшує швидкість розвитку та полегшує обслуговування. Це мабуть неправда для невеликих команд, які працюють над простими проектами. Ізоляція коду та організація імпорту може допомогти великій команді швидше вивести продукт на ринок. Це забезпечує набагато менше для однієї людини, яка працює над розробкою вже функціонального проекту.

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

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

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

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

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

Найкраще, що ви можете зробити, щоб "підтвердити майбутнє" вашого додатка, - це дотримуватися кращих практик в розробці вашої системи, щоб максимально розширити зв'язок і розділити проблеми. Немає жодної частини вашого додатка, яка б не була застарілою, але ви можете багато чого зробити, щоб ізолювати код, який застарілий з причини X, від коду, який не обов'язково повинен впливати на X.

Однак я запевняю, що ваша стурбованість повинна бути меншою за зростання / масштабованість вашої програми, ніж темп зростання вашого власного досвіду та можливостей. Психічний блок, який ви описуєте, звучить для мене, як або навчання стагнації, або усвідомлення багатьох відомих невідомих без стратегії чи інструментів для їх подолання.

Каркаси не дуже добре підходять для вирішення завдання, що захищає майбутнє, хоча вони можуть дати відповідні початкові вказівки недосвідченим, як правило, за допомогою високоякісних моделей дизайну, таких як MVC. Вони, скоріше, є більш корисними як способи прискорити розвиток, забезпечуючи міцну згуртованість і часто за рахунок більш жорсткої зв'язку. Наприклад, припустимо, що ви використовуєте якусь програмно-реляційну систему відображення об'єктів у всьому додатку для взаємодії з вашою базою даних, що комплектується інтеграцією системи кешування. Можливо, пізніше вам потрібно буде перейти на нереляційну сховище даних, і тепер все, що вона використовує, впливає.

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

Припустимо, ви хочете додати невеликий віджет на сторінку, яка потребує додаткових сценаріїв та ресурсів для належної роботи. Якщо ви використовуєте фреймворк, ви можете запитати "Як мені потрібно додати залежності до сторінки для цієї речі?" Якщо ви цього не зробите, тоді питання є більш відкритим: "Які технічні проблеми я зачіпаю, які слід якось розділити?" На це питання потрібно більше досвіду, щоб відповісти, але ось кілька підказок:

• Що буде, якби завтра ви перенесли всі свої статичні ресурси (сценарії, зображення тощо) на окремий сервер, мережу доставки вмісту тощо, або почали намагатися їх упакувати разом для підвищення продуктивності?
• Що станеться, якщо ви почали розміщувати цей віджет на різних сторінках або кілька примірників його на одній сторінці?
• Як ви можете почати виконувати тестування AB на різних версіях віджета?

Якщо якісь - або з цього звучить переважною, то я пропоную вам слід використовувати рамки в даний час, не стільки заради вашого застосування , але заради свого власного особистісного зростання. Не обов’язково починати все з початку. Натомість використовуйте рамки як навчальну програму, щоб допомогти керувати еволюцією вашої програми.

Навчитися є лише два способи. Одне - шляхом випробувань та помилок, а інше - шляхом вивчення досвіду інших. Пробну та помилку не можна усунути. За своєю суттю розробка програмного забезпечення - це безперервне поле навчання, і будь-який код, який не робить щось нове чи інше, за визначенням непотрібний. (Замість цього використовуйте вже написаний код.)

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

Що стосується програми ви в даний час пишете, однак, ваше перше занепокоєння повинно бути просто , щоб зробити це з мінімумом мирських зусиль (що - щось на зразок коду запаху, але і для процесу розвитку). Враховуючи природу навчання людини, найшвидший спосіб досягти високої якості - почати з чогось . Набагато простіше зрозуміти мету, коли ти можеш її сформувати, критикуючи щось, що ти вже маєш.

Якщо ви можете прийняти, що більша частина написаного вами коду є одноразовим навчальним процесом і необхідна для пошуку хороших конструкцій, це допоможе мотивувати вас дотримуватися цього. Зрештою, саме завдання вирішення проблем змушує розробку програмного забезпечення залучатись, і це завдання постійно присутнє, якщо те, що ви робите, варто (див. "Постійне навчання" вище).

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

Ось аналогія, яку я люблю використовувати:

• "Моя робота полягає в тому, щоб будувати будинки для людей, в яких живуть, люди будують бізнес тощо." Моя робота - змусити «тих неможливо-крихітних, надто прославлених шматочків піску» зробити корисну роботу. (Так само, як будівельники будинків майструють будинки з гіпсокартону, керамічної плитки, бетонного блоку та 2х4.

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

• "Тим не менш, кожен будинок, щойно побудований, назавжди буде жити в ньому". Ви не можете їх виселити. Після того як ви побудуєте його і передасте ключі, "це вже не" ваш "будинок". Це те, що зараз є, і простоятиме дуже довго.

Значна частина мого бізнесу в наші дні полягає в тому, щоб допомогти клієнтам впоратися з програмним забезпеченням, яке було побудоване десять, двадцять, тридцять і більше років тому, використовуючи "найсучасніші" технології, що існували в ті часи - (і які, так, Пам’ятаю) - і які досі на службі (!).

Забезпечити щось є доказом у майбутньому майже неможливо. Перевірка масштабування програми не є надто складною. Потрібно просто написати тест на ефективність програми і подивитися, скільки клієнтів він може впоратися. Написання тестів, безумовно, зробить ваш додаток більш надійним у майбутньому, оскільки ви зможете оцінити, як поводиться додаток після впровадження в нього додаткових змін.

wrt Framework, я б не надто хвилювався про продуктивність / масштабованість. Це те, що ви можете легко перевірити і, швидше за все, виправити. Більш важливим питанням є безпека. Веб-фрейми зазвичай допомагають написати правильний код автентифікації, файли 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 Точка дійсна, але 10gb є тривіальною як предмет тесту.