El marco "Zero to Shipped" para nuevos desarrolladores

Por favor, use un navegador web en un ordenador portátil / escritorio para la mejor experiencia de visualización para este artículo, ya que este artículo contiene una gran cantidad de obras de arte ASCII visualmente agradables para un mejor aprendizaje. Por favor, use un navegador web en un ordenador portátil / escritorio para la mejor experiencia de visualización para este artículo, ya que este artículo contiene una gran cantidad de obras de arte ASCII visualmente agradables para un mejor aprendizaje. Introducción El desarrollo de software es esencial.Todo se ejecuta en código, y construir un prototipo es un paso necesario.En cierto modo, el software es la manifestación física de la mente del programador. Es bastante difícil comenzar con el desarrollo. Necesitas experiencia para codificar bien, y tienes que codificar bien para ganar experiencia. Breaking the Catch-22 with Framework ================================================ Skill Level ^ | *Framework-Guided Path* | / | / | / Time Key: Framework shortcuts the experience-to-skill gap Diagrama 1: Quebrando el Catch-22 Diagrama 1: Quebrando el Catch-22 Sin embargo, lo siguiente es un marco que me gustaría proporcionar que pueda ayudarle a desarrollar rápidamente. saltaré la parte de estrategia del producto e ideación, ya que eso merece su propio artículo. El marco Sin más, el marco: ¿Qué hay en el front-end, qué hay en el backend, qué base de datos, qué tipo de API? 1. Decide on the technology stack. Al tomar una decisión, considere lo siguiente: 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 ✓] Diagrama 2: Medir el apoyo de la comunidad Diagrama 2: Medir el apoyo de la comunidad 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 Diagrama 3: Estaca homogénea vs estaca heterogénea Diagrama 3: Estaca homogénea vs estaca heterogénea 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 ✓✓✓ Diagrama 4: Lista de verificación de validación de escalabilidad (React, AWS, por ejemplo) Diagrama 4: Lista de verificación de validación de escalabilidad (React, AWS, por ejemplo) 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! Diagrama 5: Soporte de servicios en la nube (AWS, por ejemplo) Diagrama 5: Soporte de servicios en la nube (AWS, por ejemplo) 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 │ └──────────────────────┘ Diagrama 6: El caso de GraphQL Diagrama 6: El caso de GraphQL GitHub. GitLab. Bitbucket. Open source es un recurso valioso para los desarrolladores modernos. Utilízalo. Si has pensado en una idea, hay una buena posibilidad de que otra persona ya la haya implementado (no siempre podemos ser el original, ¿verdad?). Mire su código. Entenderlo. Utilízalo, mejorarlo. Dale crédito donde se debe, y debería estar bien. Esto te ayudará a desarrollar rápidamente y ayudar en proyectos de arranque rápido. Puedes usar el tiempo ahorrado para pensar en mejores características. 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. Diagrama 7: Construyendo sobre código abierto Diagrama 7: Construyendo sobre código abierto 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] Diagrama 8: El tiempo ahorrado es el tiempo ganado (escenario de ejemplo) Diagrama 8: El tiempo ahorrado es el tiempo ganado (escenario de ejemplo) 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! Gráfico 9: Licencias de código abierto comunes Gráfico 9: Licencias de código abierto comunes 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! │ ╰───────────────────────────────────────╯ Diagrama 10: Lista de comprobación de calidad del repositorio Diagrama 10: Lista de comprobación de calidad del repositorio 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! Diagrama 11: Estrategia de desarrollo inteligente Diagrama 11: Estrategia de desarrollo inteligente No siempre necesitas un Mac o Linux para programar; también tienes buenas opciones en Windows. Puedes elegir un buen editor de código como VS Code, Sublime Text, etc. Por favor, crea un repositorio GitHub para copiar tu código. Puedes crear un repositorio privado si no quieres que nadie más sepa lo que estás haciendo. Utilice una aplicación de sincronización como GitHub Desktop para que puedas trabajar en tu máquina local y empujar el código a GitHub sin problemas. 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! Diagrama 12: Ejemplo de una configuración ambiental Diagrama 12: Ejemplo de una configuración ambiental 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. Diagrama 13: CLI vs UI Diagrama 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) Diagrama 14: Gestión de la privacidad del repositorio Diagrama 14: Gestión de la privacidad del repositorio Usted puede hacer esto! Sin embargo, si intenta cavar en la documentación de componentes o marcos individuales, puede pasar años completando un tutorial. En su lugar, elija un libro o un video tutorial que sintetice estos componentes - algo que le ayuda a desarrollar un buen proyecto que combine todas estas tecnologías. Disponible en GitHub. Siga los expertos en X. Únete a las comunidades de Reddit. Lee blogs y tutoriales de proyectos de muestra. Busque artículos usando "daily.dev/hackernoon/dev.to/freecodecamp". Leer. Leer. Desarrollar. Leer. Desarrollar. Desarrollar. Desarrollar. 4. It is completely okay to "Not Know." “Listas increíbles” 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! Diagrama 15: El agujero de conejo de documentación Diagrama 15: El agujero de conejo de documentación 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! ] Diagrama 16: Descubrimiento de contenido efectivo Diagrama 16: Descubrimiento de contenido efectivo ¿Cómo puedes desarrollar más características? qué características ¿Estás desarrollando? Bounce tus ideas de las personas y obtenga un buen feedback. Mire a Product Hunt, a16z, AngelList, etc. para obtener buenas ideas. Escucha los podcasts. Pero finalmente, Código con pasión. 5. Finally, continuously think about how you can improve your project. Puede Desarrollo 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 Diagrama 17: Estrategia de Feedback Multi-Channel Diagrama 17: Estrategia de Feedback Multi-Channel 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] Diagrama 18: Fuentes de inspiración del producto Diagrama 18: Fuentes de inspiración del producto Resumen Espero que este artículo te ayude en tu viaje de programación, gracias por leer mi artículo. Si tienes alguna pregunta, no dudes en enviarme un correo electrónico.También puedes ponerte en contacto conmigo a través de LinkedIn.También puedes seguirme en X. El email El email Linkedin Linkedin X X Puedes leer mi artículo en System Design . here Aquí Aquí Puedes leer mi artículo en . DevOps Aquí Si desea que escriba sobre cualquier otro tema, por favor déjame saber en los comentarios. Enlace a mi . HackerNoon profile Perfil de hacker