Рамка «Zero to Shipped» для нових розробників

Будь ласка, використовуйте веб-браузер на ноутбуці / робочому столі для кращого досвіду перегляду цієї статті, оскільки ця стаття містить багато візуально приємних творів ASCII для кращого навчання. Будь ласка, використовуйте веб-браузер на ноутбуці / робочому столі для кращого досвіду перегляду цієї статті, оскільки ця стаття містить багато візуально приємних творів ASCII для кращого навчання. Введення Все працює за кодом, і побудова прототипу є необхідним кроком. Вам потрібен досвід, щоб добре кодувати, і вам потрібно добре кодувати, щоб отримати досвід. Breaking the Catch-22 with Framework ================================================ Skill Level ^ | *Framework-Guided Path* | / | / | / Time Key: Framework shortcuts the experience-to-skill gap Діаграма 1: Розрив Catch-22 Діаграма 1: Розрив Catch-22 Однак, наступне є рамкою, яку я хотів би надати, яка може допомогти вам розвиватися швидко. я пропущу частину стратегії продукту та ідеї, оскільки вона заслуговує на власну статтю. рамки Без будь-яких додаткових зусиль рамка: Що знаходиться в передньому кінці, що знаходиться в задньому кінці, яка база даних, який тип API? 1. Decide on the technology stack. При прийнятті рішення розглянемо наступне: Your software should be easy to build and maintain. Select a general-purpose language that can be utilized to get the maximum features you want and support different layers of the stack. While the layers of the design are disparate, you should have a low-latency method for these components to talk with each other. a) Homogeneity & Compatibility: For example: JavaScript is the language of the frontend in frameworks like React and Angular. It can also be used on the backend with Node.js and Express. It's the basis for data formats like JSON, which in turn are used by APIs (like GraphQL) and databases (like MongoDB, which uses a JSON-like structure). By leveraging npm (which is like a JavaScript App Store), you can install thousands of libraries for your project. What you intend to develop must be Scalable. This is critically important. Choose a framework that is used by top multinational corporations (MNCs), or even better, one developed by an MNC. b) Scalability: For example: React and GraphQL were created by Facebook, and they use them internally, so you know they are scalable. On MongoDB's website, you can find that Google, among other companies, is one of its partners - so you know it's scalable. You can also look at a tool's GitHub repository and community support; the more, the better. Finally, you can also see if a major cloud provider supports your development stack, as it’s helpful when you intend to scale after the initial development/ or if you need help with quick prototyping of the software that is being developed. Measuring Community Support ======================================= [Technology/Framework] | +--------+--------+--------+ | | | | v v v v GitHub Stack npm Reddit/ Stars Overflow Downloads Discord | | | | v v v v >1K+ >1K >100+/ Active Qs week Community | | | | +--------+--------+--------+ | v [Strong Ecosystem ✓] Діаграма 2: Вимірювання підтримки спільноти Діаграма 2: Вимірювання підтримки спільноти Homogeneous vs Heterogeneous Stack ============================================== HOMOGENEOUS (Good): JS → JS → JS → JS ✓ Easy to maintain ✓ Low context switching ✓ Unified tooling HETEROGENEOUS (Complex): Python → Java → PHP → Ruby ✗ Multiple paradigms ✗ Different toolchains ✗ Team expertise split Діаграма 3: Гомогенний проти гетерогенного стеку Діаграма 3: Гомогенний проти гетерогенного стеку Scalability Validation Checklist ============================================ Technology Choice: [React] ☑ Used by MNCs? → Facebook, Netflix, Airbnb ✓ ☑ Large Community? → 240K+ GitHub stars ✓ ☑ AWS Support? → AWS Amplify supports React ✓ ☑ Active Development? → Regular updates ✓ Result: SCALABLE ✓✓✓ Діаграма 4: Перевірка валідації масштабуваності (наприклад, React, AWS) Діаграма 4: Перевірка валідації масштабуваності (наприклад, React, AWS) AWS Service Support ================================ Your Stack AWS Service ────────── ─────────── React/Angular → CloudFront | Amplify | S3 Hosting v Node.js/API → Lambda | Elastic Beanstalk | EC2 v MongoDB → DocumentDB | v [Fully Supported!] If AWS supports it, it's production-ready! Діаграма 5: Підтримка хмарних послуг (наприклад, AWS) Діаграма 5: Підтримка хмарних послуг (наприклад, AWS) API Architecture Choice ==================================== REST API: GET /users/1 → Full User Object GET /posts/1 → Full Post Object (Multiple Requests, Over-fetching) GraphQL: query { user(id: 1) { name posts { title } } } (Single Request, Exact Data) ┌──────────────────────┐ │ Facebook uses │ │ GraphQL internally │ │ = Proven at Scale │ └──────────────────────┘ Діаграма 6: Випадок GraphQL Діаграма 6: Випадок GraphQL GitHub. GitLab. Bitbucket. Відкрите джерело є цінним ресурсом для сучасних розробників. Використовуйте його. Якщо ви думали про ідею, є хороша ймовірність, що хтось інший вже реалізував її (ми не можемо завжди бути оригінальним, правильно?). Подивіться на їхній код. Розумійте його. Використовуйте його, покращайте на ньому. Дайте кредит там, де він повинен бути, і ви повинні бути просто добре. Це допоможе вам швидко відслідковувати розвиток і допомогти у швидкому запуску проектів. Ви можете використовувати збережений час, щоб думати про кращі функції. 2. Leverage open source. Standing on Giants' Shoulders ========================================= [Your Innovation] | ╔═════╧═════╗ ║ You ║ <- Your contribution ╠═══════════╣ ║ Library A ║ <- Open source tools ╠═══════════╣ ║ Library B ║ <- Previous work ╠═══════════╣ ║ Library C ║ <- Community effort ╠═══════════╣ ║ Core Lang ║ <- Foundation ╚═══════════╝ Don't reinvent the wheel! Build on existing solutions. Діаграма 7: Будівництво на основі відкритого коду Діаграма 7: Будівництво на основі відкритого коду Time Investment Comparison ====================================== Build From Scratch: ├─ Research: 40 hours ├─ Architecture: 30 hours ├─ Implementation: 120 hours ├─ Testing: 40 hours ├─ Debugging: 50 hours └─ TOTAL: 280 hours (7 weeks) Using Open Source: ├─ Search: 2 hours ├─ Understand: 8 hours ├─ Integrate: 6 hours ├─ Customize: 10 hours └─ TOTAL: 26 hours (3 days) SAVINGS: 254 hours (6+ weeks!) ↓ [Use for Features] Діаграма 8: час, який заощаджується, - це час, який заробляється (приклад сценарію) Діаграма 8: час, який заощаджується, - це час, який заробляється (приклад сценарію) Common Open Source Licenses ======================================= MIT License ├─ ✓ Commercial use ├─ ✓ Modification ├─ ✓ Distribution └─ ✓ Private use [Most Permissive] Apache 2.0 ├─ ✓ Patent protection ├─ ✓ Commercial use └─ ! State changes GPL v3 ├─ ✓ Strong copyleft ├─ ! Must open source └─ ! Derivative works [Most Restrictive] Always check before using! Діаграма 9: Загальні ліцензії відкритого джерела Діаграма 9: Загальні ліцензії відкритого джерела Repository Quality Checklist ========================================= ╭───────────────────────────────────────╮ │ Evaluating: [repository-name] │ ├───────────────────────────────────────┤ │ [ ] README with clear instructions │ │ [ ] License file present │ │ [ ] Active maintenance (commits) │ │ [ ] Issues being addressed │ │ [ ] Good test coverage │ │ [ ] Documentation/Wiki │ │ [ ] Examples provided │ │ [ ] High stars-to-forks ratio │ │ [ ] Contributors > 3 │ │ [ ] Release/version tags │ ├───────────────────────────────────────┤ │ 7+ checked = Safe to use! │ ╰───────────────────────────────────────╯ Діаграма 10: Перевірка якості репозиторію Діаграма 10: Перевірка якості репозиторію Smart Development Strategy =============================================== [ Your Idea ] | v / \ [ Yes ] [ No ] | | | v | | | | [ Yes! ] | | | v | [ Use their work ] | [ + Attribution ] | | +----------+-----------+ | v [ Add YOUR unique value ] ├─ Your UI/UX ├─ Your features ├─ Your integration └─ Your innovation | v [ Ship Product Faster ] Originality ≠ Reinventing Be original where it matters! Діаграма 11: Стратегія розумного розвитку Діаграма 11: Стратегія розумного розвитку Вам не завжди потрібен Mac або Linux для програмування; у вас також є хороші варіанти на Windows. Ви можете вибрати хороший редактор коду, як VS Code, Sublime Text і т. Д. Будь ласка, створюйте репозиторій GitHub для резервного коду. Ви можете створити приватний репозиторій, якщо ви не хочете, щоб хтось інший знав, що ви до. Використовуйте програмне забезпечення для синхронізації, як GitHub Desktop, щоб ви могли працювати на вашій локальній машині і бездоганно натиснути код на GitHub. 3. Choose a proper coding environment. The Complete Coding Environment ============================================ ╔════════════════════════════════════════╗ ║ YOUR DEVELOPMENT SETUP ║ ╠════════════════════════════════════════╣ ║ LAYER 1: Operating System ║ ║ ┌──────────────────────────────────┐ ║ ║ │ Windows / macOS / Linux │ ║ ║ └──────────────────────────────────┘ ║ ╠════════════════════════════════════════╣ ║ LAYER 2: Code Editor ║ ║ ┌──────────────────────────────────┐ ║ ║ │ VS Code + Extensions │ ║ ║ │ • Prettier, ESLint │ ║ ║ │ • GitLens, Live Server │ ║ ║ └──────────────────────────────────┘ ║ ╠════════════════════════════════════════╣ ║ LAYER 3: Version Control ║ ║ ┌──────────────────────────────────┐ ║ ║ │ Git + GitHub Desktop │ ║ ║ └──────────────────────────────────┘ ║ ╠════════════════════════════════════════╣ ║ LAYER 4: Cloud Backup ║ ║ ┌──────────────────────────────────┐ ║ ║ │ GitHub Repository │ ║ ║ │ (Public or Private) │ ║ ║ └──────────────────────────────────┘ ║ ╠════════════════════════════════════════╣ ║ LAYER 5: Language Runtime ║ ║ ┌──────────────────────────────────┐ ║ ║ │ Node.js, Python, etc. │ ║ ║ └──────────────────────────────────┘ ║ ╚════════════════════════════════════════╝ | | v v [Local Code] [Cloud Backup] Professional Setup Complete! Діаграма 12: Приклад налаштування середовища Діаграма 12: Приклад налаштування середовища Command Line vs GitHub Desktop =========================================== COMMAND LINE: GITHUB DESKTOP: ═══════════════ ═══════════════ $ git init Click "New Repo" $ git add . Check boxes $ git commit -m "msg" Type message, click "Commit" $ git remote add origin Paste URL, click "Add" $ git push origin main Click "Push" $ git pull Click "Fetch" $ git log See "History" tab Learning Curve: Learning Curve: ████████░░ 80% ██░░░░░░░░ 20% Both work! Choose comfort level. Діаграма 13: CLI vs UI Діаграма 13: CLI vs UI Managing Repository Privacy ======================================== [New Repository] | +------+------+ | | v v ┌────────┐ ┌────────┐ │ PUBLIC │ │PRIVATE │ └───┬────┘ └───┬────┘ | | v v Visible to: Visible to: • Everyone • You • Employers • Invited • Portfolio • Team only | | v v Can switch Can switch to Private to Public (anytime) (anytime) | | +-----+------+ | v Settings > Danger Zone | v "Change visibility" Start Private → Go Public Later (Common Strategy) Діаграма 14: Управління конфіденційністю репозиторію Діаграма 14: Управління конфіденційністю репозиторію Ви можете зробити це! Однак, якщо ви намагаєтеся копати в документацію окремих компонентів або рамок, ви можете витратити роки, заповнюючи один підручник. Замість цього виберіть книгу або відео-підручник, який синтезує ці компоненти - щось, що допомагає вам розробити хороший проект, що об'єднує всі ці технології. доступна на GitHub. Слідкуйте за експертами на X. Приєднуйтесь до спільнот reddit. Читайте блоги та підручники з пробних проектів. Пошук статей за допомогою "daily.dev/hackernoon/dev.to/freecodecamp". Читати. Читати. Розвивати. Читати. Розвивати. Розвивати. Розвивати. 4. It is completely okay to "Not Know." «Дивовижні списки» The Documentation Rabbit Hole ========================================= [Want to Learn React] | v Read React Docs | +-------+-------+ | | v v Hooks Docs JSX Docs | | v v useState Docs Babel Docs | | v v useEffect Webpack | | +-------+-------+ | v [6 months later...] [Still in docs, no project!] BETTER APPROACH: [Tutorial Project] → Learn by doing! Диаграма 15: Документація Кролик діра Диаграма 15: Документація Кролик діра Effective Content Discovery ========================================================= [ Need to Learn XYZ ] | v +---------------------------------------------------------+ | Step 1: Run Parallel Searches | +----------------+----------------------+-----------------+ | Platform | Action | Refinement | +----------------+----------------------+-----------------+ | Google | Search keywords | "XYZ tut 2025" | | daily.dev | Browse feed/tags | Filter by tag | | Reddit | Find recent posts | Sort by "Top" | | YouTube | Find recent videos | Sort by views | +----------------+----------------------+-----------------+ | v +---------------------------------------------------------+ | Step 2: Consolidate & Vet Results | | (Compare 3-5 top links) | +---------------------------------------------------------+ | v +-----------------+---------------+ | | v v (e.g. 2024+) (Has full examples) | | +----------------+----------------+ | v [ Start Learning! ] Діаграма 16: Ефективне відкриття контенту Діаграма 16: Ефективне відкриття контенту Як ви можете розробити більше функцій? які особливості Ви розвиваєте? Відкидайте свої ідеї від людей і отримуйте хороші відгуки. Дивіться на Product Hunt, a16z, AngelList тощо, щоб отримати хороші ідеї. Слухайте подкасти. Але врешті-решт, Код з пристрастю. 5. Finally, continuously think about how you can improve your project. Можна Розвивати Multi-Channel Feedback Strategy =========================================== [Your Application] | Collect Feedback From: | +-------+-------+-------+-------+ | | | | | v v v v v Users Friends Reddit GitHub X/ Issues Twitter | | | | | v v v v v Real Honest Public Bug Quick world opinion discus- reports reactions usage sions | | | | | v v v v v What Improve- Feature Tech Viral works ments requests debt features | | | | | +-------+-------+-------+-------+ | v [Prioritized Roadmap] Listen > Ego Діаграма 17: Стратегія багатоканального зворотного зв'язку Діаграма 17: Стратегія багатоканального зворотного зв'язку Sources of Product Inspiration ========================================== [Your Project] | What features next? | +---------+----------+---------+ | | | | v v v v ┌─────────┐┌──────┐┌─────────┐┌────────┐ │ Product ││ a16z ││AngelList││Podcasts│ │ Hunt ││ Blog ││ ││ │ └────┬────┘└───┬──┘└────┬────┘└───┬────┘ | | | | v v v v Trending VC Startup Expert Products Insights Trends Advice | | | | v v v v User pain Market Business Best points trends models practices | | | | +----+----+----+---+----+----+ | v [Feature Ideas List] [Innovation Backlog] Діаграма 18: Джерела натхнення для продуктів Діаграма 18: Джерела натхнення для продуктів Резюме Сподіваюся, що ця стаття допоможе вам у вашому програмуванні, дякую за читання моєї статті. Якщо у вас є будь-які питання, будь ласка, не забудьте надіслати мені електронну пошту. Ви також можете зв'язатися зі мною через LinkedIn. Ви також можете слідувати за мною на X. Електронна Електронна Лінконг Лінконг X X Можна прочитати мою статтю на System Design . Тут Тут Тут Можна прочитати мою статтю на . DevOps Тут Якщо ви хочете, щоб я писав про будь-яку іншу тему, будь ласка, повідомте мені в коментарях. Лінк до мого . Профіль хакера Профіль хакера