Miedo a que la aplicación web no sea "preparada para el futuro"

106

Soy desarrollador web de una pequeña aplicación web SaaS local. Actualmente tiene alrededor de media docena de clientes.

A medida que continúo diseñando la aplicación, me resulta cada vez más difícil convencerme de comprometerme en cualquier momento con el proyecto, lo que ha sucedido en la fase inicial. Después de haberme apegado al proyecto y al código que ya he escrito, tengo miedo de que todo el trabajo adicional que comprometo se anule en un futuro próximo, cuando la aplicación no se adapte bien a medida que crezca el negocio.

Como estudiante universitario que solicita pasantías, he hecho que los empleadores cuestionen mi elección de no usar ningún marco web durante las entrevistas, lo que solo me ha hecho dudar aún más de mi trabajo anterior. Simplemente no conozco ningún framework web y no sé cuál comenzar a usar.

Obtuve una pasantía como desarrollador de pila completa en enero, donde comenzaré a aprender frameworks front-end, pero la presión para terminar la aplicación está aumentando, y estoy considerando eliminar la aplicación por completo y comenzar de nuevo, que es algo que he hecho antes La aplicación actualmente está construida en PHP y jQuery (para llamadas AJAX) y utiliza MySQL para su base de datos. ¿Alguna idea sobre cómo puedo superar este bloqueo mental y para garantizar que mi aplicación sea escalable? Gracias por adelantado.

cameraguy258
fuente
93
El uso de un marco pretende ser más barato, no objetivamente mejor. Las empresas siempre preguntarán "por qué no más barato" porque ese es su trabajo. Se necesitan muchos años de experiencia para responder "por qué este marco no es ese o personalizado". No puede dar una respuesta significativa a esa pregunta como estudiante / pasante simplemente porque no ha participado en suficientes proyectos para presenciar cómo funciona un marco determinado para un problema dado. Sin esa experiencia, lo único que puede hacer es ser presa de un marco de marketing determinado.
Agent_L
24
Lo único que sabes sobre el futuro es que no sabes nada al respecto. Así que sigue viviendo en el presente. ¡El futuro encontrará formas de patearte en el *** sin importar cuánto tiempo pierdas intentando evitarlo!
alephzero
20
"Habiéndome apegado al ... código que ya he escrito" Es nuestra naturaleza apegarnos a nuestro trabajo y resistirnos a cambiarlo. Pero incluso si lo hace, sigue vivo en el control de versiones. El software está destinado a ser cambiado, tal como lo hace el mundo real. No tenga miedo de eliminar el código o cambiarlo sustancialmente cuando lo desarrolle.
bitsoflogic
8
En cuanto a eliminar el proyecto, desaconsejaría. Por lo general, se siente genial comenzar desde cero, porque obtienes un gran impulso frente a muchos problemas que ya has resuelto. Eventualmente, sin embargo, regresa a un nuevo problema que no encaja en el modelo. El tiempo de reescritura podría dedicarse a resolver los nuevos problemas. Siempre puede abordar los cuellos de botella una vez que sepa cuáles son.
bitsoflogic
66
@james_pic ¿Realizas proyectos web sin un marco básico (por ejemplo, asp.net core en .NET, etc.)? ¿Entonces reimplementa la lógica de enrutamiento y todas las demás cosas encima de una simple biblioteca http? Eso parece excesivo y no veo qué ventaja debería darte.
Voo

Respuestas:

201

Lo perfecto es enemigo de lo bueno.

O dicho de otra manera, no te preocupes por eso hoy. Si su aplicación hace lo que debe hacer, entonces está bien. Es no es una mala cosa para reescribir partes de software de más abajo en la línea; para ese momento usted 1) sabe más claramente lo que está tratando de construir y 2) sabe qué partes son realmente el cuello de botella. Podrías pasar una enorme cantidad de tiempo escribiendo una aplicación que se escalaría a un millón de usuarios, pero no sería mejor para tus seis clientes actuales que lo que tienes hoy .

Philip Kendall
fuente
23
Buen punto. Si pasas 2 meses intentando que sea a prueba de futuro para evitar una posible reescritura de 1 semana, has perdido 7 semanas de tu tiempo. Acepte que habrá cambios, y pruebe en el futuro solo cuando sea casi seguro que tendrá que hacerse.
Neil
83
YAGNI, bebé, YAGNI
Kevin
32
Otro caso de " Optimización prematura es la raíz de todo mal ". Quizás valga la pena mencionar que no pasarás de 6 usuarios a un millón. Si 6 clientes son suficientes para pagar por un desarrollador, incluso para cuando llegue a 100 clientes, el código podría necesitar una estructura diferente solo para permitir que múltiples desarrolladores trabajen en él al mismo tiempo. Eso es bastante diferente de optimizar el rendimiento y sucede mucho antes que tener que hacer malabarismos con un millón de usuarios.
R. Schmitz el
22
@ R.Schmitz Esa cita se usa en estos días en un contexto completamente diferente a la forma en que Knuth la usó en la programación de computadoras como arte. Knuth está decididamente en contra de todo "simplemente comience a programar y preocúpese por optimizar más tarde". Lo que dice es que las personas optimizan las partes incorrectas del código en el momento incorrecto. Eso de ninguna manera significa que no deba pasar un tiempo pensando en su arquitectura para asegurarse de que sea eficiente antes de comenzar a escribir código. Es posible que prefiera el otro sentimiento, pero no debería citar a Knuth como defensor allí.
Voo
20
@ R.Schmitz Cuando Hoare / Knuth hizo esa declaración, "optimización" significaba contar el ciclo y otras cosas que ya no hacemos hoy de todos modos, no "pensar en una buena arquitectura antes de comenzar a codificar". Usar la cita como una excusa para simplemente no pensar en un buen diseño del sistema simplemente no es lo que tenían en mente.
Voo
110

¿Alguna idea sobre cómo puedo superar este bloqueo mental y para garantizar que mi aplicación sea escalable?

El quid de la cuestión no es la escalabilidad. El quid de la cuestión es pensar que lo hará bien la primera vez .

Debes concentrarte en escribir código limpio. Porque el código limpio maximiza la conveniencia cuando (inevitablemente) tiene que cambiar algo en el futuro. Y ese es el verdadero objetivo que debes tener.

Lo que está tratando de hacer ahora es pensar en el código perfecto para escribir. Pero incluso si logras hacer eso, ¿quién dice que los requisitos no van a cambiar, o tal vez tomaste tus decisiones basándose en información incorrecta o falta de comunicación?

No puedes evitar cometer errores, incluso si no son tu culpa. Concéntrese en escribir código en el que sea fácil cambiar las cosas más tarde, en lugar de esperar escribir código que no necesitará cambiar en el futuro.

Habiéndome apegado al proyecto y al código que ya escribí,

Absolutamente simpatizo con este sentimiento. Pero apegarse al código que ha escrito es un problema.

Lo único que debería ser una constante es su deseo de resolver un problema específico . La forma de resolver ese problema es solo una preocupación secundaria.

Si mañana se lanza una nueva herramienta que reduce su base de código en un 80%, ¿le molestará que su código ya no se use; ¿o te alegrará que tu base de código se haya vuelto más pequeña y mucho más limpia / manejable?

Si es lo primero, tiene un problema: no está viendo la solución para el código . En otras palabras, te estás enfocando en el código y no estás viendo la imagen más grande (la solución que pretende proporcionar).

Tengo miedo de que todo el trabajo adicional que realice se anule en el futuro cercano, cuando la aplicación no se adapte bien a medida que crezca el negocio.

Ese es un problema diferente para un día diferente.

Primero, construyes algo que funciona. En segundo lugar , mejora el código para corregir cualquier falla que aún pueda mostrar. Lo que estás haciendo actualmente es retener la primera tarea por miedo a tener que hacer la segunda tarea.

¿Pero qué otra opción hay? No puedes decir el futuro . Si pasas tu tiempo pensando en las posibilidades futuras, terminarás adivinando de todos modos. Una suposición siempre es propensa a estar completamente equivocado.

En su lugar, compile la aplicación y pruebe que efectivamente existe un problema. Y una vez que el problema está claro, comienzas a abordarlo.

Para decirlo de otra manera: Henry Ford nunca construyó un automóvil que cumpla con los estándares / expectativas de 2018. Pero si no hubiera construido el Modelo T, un automóvil defectuoso para los estándares modernos, nadie habría comenzado a usar automóviles, no habría industria automotriz, y nadie habría tenido un automóvil que pudieran intentar mejorar.

He hecho que los empleadores cuestionen mi elección de no usar ningún marco web durante las entrevistas, lo que solo me ha hecho dudar aún más de mi trabajo anterior.

La parte importante aquí no es qué marco está utilizando (cualquier empleador que lo juzgue por eso no está haciendo su trabajo correctamente). La parte importante aquí es saber lo que estás haciendo y por qué lo estás haciendo .

Por ejemplo, podría estar evitando el marco existente específicamente porque desea aprender por qué un marco es útil al hacerlo de la manera difícil primero. O podrías estar tratando de hacer tu propio marco.

La única mala respuesta aquí es "No sé", ya que muestra la falta de tomar decisiones informadas. Esa es una bandera roja para un empleador.

Simplemente no conozco ningún framework web y no sé cuál comenzar a usar.

El mismo problema surge aquí. La solución no es pensar más, sino actuar:

  • Deja de pensar en la respuesta perfecta .
  • Elige un marco. A menos que tenga una preferencia, elija una aleatoria. Usa un tablero de dardos, tira un dado, lanza una moneda, elige una carta.
  • Úsalo.
  • ¿Te gustó usarlo? ¿Había algo que encontraras molesto?
  • Busque cómo prevenir estos elementos malos. ¿Utilizaste mal el framework o es así como se supone que funciona?
  • Una vez que sienta que tiene un control sobre el marco (independientemente de si le gusta o no), elija un nuevo marco y repita el ciclo.

Para leer más sobre esto, lea La mentalidad de hacer> la mentalidad de pensar . El autor lo explica mejor que yo.

pero la presión para terminar la aplicación está aumentando, y estoy considerando eliminar la aplicación por completo y comenzar de nuevo

A menos que la base de código actual sea un desastre absolutamente imposible de mantener; Estás tomando la decisión opuesta.
Los desarrolladores a menudo piensan que tirar las cosas sería la mejor opción. Es un sentimiento muy común. Pero rara vez es la elección correcta.

Tirar el código y comenzar desde cero es como quedarse atrapado en el tráfico camino al trabajo, preocupado por llegar tarde al trabajo (perder el plazo) y, en cambio, conducir a casa e intentar conducir por el mismo camino nuevamente. No tiene sentido Puede estar atrapado en el tráfico, pero aún está más cerca del trabajo que cuando estaba en casa.

Flater
fuente
99
Comenzar desde cero rara vez es la elección correcta: joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i
Martin Bonner
10
@MartinBonner Si bien eso es cierto en el contexto del que habla Joel en ese artículo, si este es literalmente el primer proyecto en el que ha trabajado, y usted es la única persona que ha trabajado en él, entonces es muy posible que usted sea capaz de escribir algo mejor. Recuerdo que reescribí el primer gran proyecto personal en el que trabajé, y esta fue probablemente la decisión correcta en ese momento: el prototipo original se rompió sin posibilidad de reparación, porque no sabía lo que estaba haciendo cuando lo escribí.
James_pic
44
@Flater Estoy de acuerdo con la mayoría de lo que se ha escrito aquí, excepto una cosa: si elige un marco y no sabe nada de ninguno de ellos, al menos puede verificar el nivel de adopción de ese marco. Por ejemplo, ¿cuántas estrellas tiene en github? ¿Cuántos problemas hay? ¿Cuántos contribuyentes? ¿Cuándo fue la última actualización? La respuesta a estas preguntas puede al menos ayudar en la elección de un marco para las que puede obtener ayuda, contratar a chicos que saben mejor, etc.
Jalayn
@Jalayn Uno supondría que, para empezar, un principiante que no tiene conocimiento previo probablemente tropezará con marcos conocidos.
Flater
3
Esta es una gran respuesta porque fomenta un enfoque disciplinado y metódico. ¡Me tomó varios años antes de que pudiera apreciar plenamente consejos como este!
kashiraja el
18

A pesar de la enorme cantidad de dinero que Facebook y Google han invertido en marketing para convencerlo de lo contrario, los marcos frontales existen por dos razones principales:

  • Primero, descargar las demandas de hardware / red a las operaciones del lado del cliente al poner el estado y la lógica en el cliente
  • Segundo, pertinente a la lógica adicional del cliente necesaria para soportar el primer punto, proporcionan contextos de ejecución aislados para que pueda meter el código de otras personas en una página sin romper nada.

Probablemente solo necesite buscar un marco para resolver estos problemas si su aplicación tiene un estado intrínseco, si la cantidad de estado de la aplicación que está guardando en el lado del cliente es bastante compleja, si espera una gran cantidad de clientes con mala latencia de red (móvil, o distante del servidor), o si existe una fuerte necesidad comercial de admitir CSS particularmente avanzado o creación de elementos dinámicos.

El marketing de marcos quiere que creas que su método especial de arquitectura aumenta la velocidad de desarrollo y facilita el mantenimiento. Esto es evidentemente falso para pequeños equipos que trabajan en proyectos simples. Aislar el código y organizar las importaciones puede ayudar a un gran equipo a lanzar un producto al mercado más rápidamente. Proporciona mucho menos para un equipo de desarrollo de una sola persona que trabaja en un proyecto ya funcional.

Pasará más tiempo aprendiendo cómo encajar el código funcional existente en el marco de lo que realmente implementará las características, y es muy probable que alguien en algún lugar actualice algo, y el código escrito en ese marco dejará de funcionar dentro de 18 meses a menos que alguien está ahí para mantenerlo constantemente.

Vanilla JS, y en menor medida pero aún en gran medida JQuery, no sufren esos problemas. Con algunas excepciones notables, las aplicaciones JQuery + AJAX que no se basan en comportamientos específicos del navegador y renuncian a dependencias externas donde sea razonable, continúan funcionando 10-15 años después de que se escribieron originalmente con cambios muy menores.

Los marcos son excelentes para las startups típicas que admiten aplicaciones web continuas, complejas y públicas. Permiten que los equipos grandes se coordinen bien juntos, se integren bien con los marcos para agregar proveedores y admitan nuevos widgets llamativos y paradigmas de diseño para ayudarlo a mantenerse competitivo.

Nada de eso importa para una pequeña herramienta de software con una audiencia fija que estás a punto de abandonar. Asumir un marco de trabajo ralentiza su velocidad de desarrollo a medida que se adapta a un nuevo paradigma e introduce riesgos de compatibilidad innecesarios. Mantener el código del lado del cliente simple (e idealmente autohospedado) significa que la superficie del riesgo de compatibilidad cae significativamente. Los navegadores cambiarán, las URL de CDN dejarán de funcionar, las dependencias quedarán desactualizadas, pero nadie está tocando ese servidor y seguirá funcionando bien.

No adopte un marco a menos que resuelva un problema arquitectónico específico que tenga hoy o pueda prever pronto, y considere enfáticamente abordar esa preocupación por otros medios, si eso es posible.

Gremlin de hierro
fuente
2
Cuando pienso en "framework", pienso en cosas como jQuery o Angular o React, donde proporciona muchos bloques de construcción para cosas que serían molestas de implementar (y a menudo difíciles de implementar correctamente y compatibles con el navegador cruzado).
esponjoso
@fluffy ¿Qué, específicamente, crees que Angular o React hacen por ti que es significativamente más fácil que hacer lo mismo en Vanilla JS o JQuery en 2018 en navegadores no móviles? FF / Chrome / Edge tiene más que suficiente área de superficie común para crear aplicaciones pequeñas completamente funcionales sin cuñas en estos días.
Iron Gremlin
3
@IronGremlin ¿Estás bromeando? ¿Alguna vez ha usado enlaces de datos bidireccionales o Angular / Vue / lo que sea plantillas? Para aplicaciones donde estas características son útiles, son una gran simplificación y le permiten deshacerse del código frágil basado en eventos. A continuación, CPU. Claro, el uso de JS Framework generalmente requiere algo de carga del servidor, pero es puramente un subproducto , y usted dice que es la razón principal para ellos. A continuación, "La arquitectura simple (...) parece una mejor opción para este proyecto". Bueno, esa es una declaración bastante exagerada, dado lo poco que sabemos sobre el proyecto.
Frax
2
Quiero decir, usted dice que su punto central es "no todo tiene que ser o debería ser una 'aplicación js enriquecida'". Estoy de acuerdo con este punto. Sin embargo, creo que su respuesta no se transmite correctamente; sería mucho mejor si la editara.
Frax
1
Nunca escuché sobre la descarga de CPU al cliente como una razón para usar JS . Diría que la tendencia histórica del uso de JS en el cliente sugiere exactamente eso (no estoy diciendo LA (una razón principal)), y parecía crecer. exponencialmente desde que jQuery cortó el nudo gordiano de las incompatibilidades del navegador.
radarbob
7

Lo mejor que puede hacer para "preparar el futuro" de su aplicación es seguir las mejores prácticas en el diseño de su sistema para maximizar el acoplamiento suelto y la separación de las preocupaciones. No hay ninguna parte de su aplicación que esté a salvo de volverse obsoleta, pero sí puede hacer mucho para aislar el código que se vuelve obsoleto por la razón X del código que no necesariamente tiene que verse afectado por X.

Sin embargo, afirmaría que su preocupación debería ser menor por el crecimiento / escalabilidad de su aplicación que la tasa de crecimiento de su propia experiencia y capacidades. El bloqueo mental que usted describe me suena como un estancamiento del aprendizaje o la conciencia de muchas incógnitas conocidas sin la estrategia o las herramientas para abordarlas.

Los marcos no son particularmente adecuados para resolver el desafío de "preparación para el futuro", aunque pueden proporcionar una guía inicial relevante para los inexpertos, generalmente a través de patrones de diseño de alto nivel como MVC. Por el contrario, tienden a ser más útiles como formas de acelerar el desarrollo al proporcionar una fuerte cohesión y, a menudo, a expensas de un acoplamiento más estricto. Por ejemplo, suponga que utiliza algún sistema de mapeo relacional de objetos proporcionado por el marco en toda la aplicación para interactuar con su base de datos, completa con la integración del sistema de almacenamiento en caché. Quizás más tarde necesite cambiar a un almacén de datos no relacional y ahora todo lo que lo use se ve afectado.

El desorden que ahora tiene no proviene de lo que usó, sino de dónde lo usó (probablemente en casi todas partes en el back-end). Qué mejor será si el código que procesa una página nunca recupera los datos que procesa.

Suponga que desea agregar un pequeño widget a una página que requiere scripts y recursos adicionales para funcionar correctamente. Si está utilizando un marco, puede preguntar "¿Cómo quiere que agregue las dependencias a una página para esto?" Si no lo está, la pregunta es más abierta: "¿Qué preocupaciones técnicas estoy tocando que de alguna manera deberían estar separadas?" Esa pregunta requiere más experiencia para responder, pero aquí hay algunos consejos:

  • ¿Qué pasaría si mañana moviera todos sus recursos estáticos (secuencias de comandos, imágenes, etc.) a un servidor separado, red de entrega de contenido, etc., o comenzara a tratar de agruparlos todos para mejorar el rendimiento?
  • ¿Qué sucedería si comenzara a colocar este widget en diferentes páginas, o en varias instancias del mismo en la misma página?
  • ¿Cómo podría comenzar a realizar pruebas AB en diferentes versiones del widget?

Si nada de esto suena abrumadora, entonces te sugiero que debe utilizar un marco, por ahora, no tanto por el bien de su aplicación, pero en aras de su propio crecimiento personal. Sin embargo, no necesariamente empieces de nuevo. En su lugar, use marcos como plan de estudios para ayudar a guiar la evolución de su aplicación.

Solo hay dos formas de aprender. Uno es por prueba y error, y el otro es por aprender de la experiencia de otros. Prueba y error no pueden ser eliminados. El desarrollo de software es, por su propia naturaleza, un campo de aprendizaje continuo y cualquier código que no haga algo nuevo o diferente es innecesario por definición. (En su lugar, use el código que ya está escrito).

El truco consiste en minimizarlo mediante la búsqueda proactiva de conocimientos preexistentes (estrategias, mejores prácticas y código / bibliotecas / marcos) a lo largo de cada paso del proceso de desarrollo para que no te encuentres reinventando constantemente la rueda.

Sin embargo, en cuanto a la aplicación que está escribiendo actualmente, su primera preocupación debería ser simplemente hacerlo con un mínimo de esfuerzo mundano (que es algo así como un olor a código, pero para el proceso de desarrollo). Dada la naturaleza del aprendizaje humano, la forma más rápida de lograr alta calidad es comenzar con algo . Es mucho más fácil entender el objetivo cuando puedes darle forma al criticar algo que ya tienes.

Si puedes aceptar que gran parte del código que escribes es un proceso de aprendizaje desechable y necesario para encontrar buenos diseños, eso te motivará a seguir adelante. Después de todo, es el desafío de la resolución de problemas lo que hace que el desarrollo de software sea atractivo, y ese desafío está siempre presente si lo que está haciendo vale la pena (vea la declaración de "aprendizaje continuo" más arriba).

HonradoMule
fuente
5

Por encima de todo, "desechar la cosa y comenzar de nuevo" nunca es una opción ... después de todo, ¿no dijiste que tienes "media docena de clientes?" Tiene sin embargo, hizo una pausa para considerar lo que podrían pensar en su pronunciamiento, dado que son en este momento (presumiblemente) "perfectamente feliz con su trabajo ?!"

Aquí hay una analogía que me gusta usar:

  • "Mi trabajo es construir casas para que la gente viva, para que la gente construya negocios, y así sucesivamente". Mi trabajo es hacer que "esos trozos de arena imposiblemente diminutos y sobre glorificados " hagan un trabajo útil. (Del mismo modo que los constructores construyen casas con paneles de yeso, baldosas de cerámica, bloques de hormigón y 2x4).

  • Sin embargo, mientras que los "clavos" que usan los constructores de casas realmente no han cambiado mucho en doscientos años (excepto para pasar de "cuadrado" a "redondo", y luego ser útiles con máquinas de clavado neumático), la tecnología que usamos cambia constantemente y a veces sufre cambios muy profundos. ("Así que va.")

  • "Sin embargo, cada casa, una vez construida, será para siempre, después se vivió en". No puedes desalojarlos. Una vez que lo construyes y entregas las llaves, "ya no es 'tu' casa". Es lo que es en este momento, y durará mucho tiempo.

Una gran parte de mi negocio en estos días es ayudar a los clientes a hacer frente al software que se construyó hace diez, veinte, treinta o más años, utilizando las tecnologías "de vanguardia" que existían en esos días - (y que, ejem, Lo recuerdo) , y que todavía están en servicio (!) Hoy.

Mike Robinson
fuente
3

Asegurar que algo es una prueba futura es casi imposible. Sin embargo, verificar que la aplicación sea escalable no es demasiado difícil. Solo necesita escribir alguna prueba de rendimiento para la aplicación y ver cuántos clientes puede manejar. Escribir pruebas definitivamente hará que su aplicación esté más preparada para el futuro porque podrá evaluar cómo se comporta la aplicación después de implementar más cambios en ella.

wrt framework, no estaría demasiado preocupado en cuanto a rendimiento / escalabilidad. Esto es algo que puede verificar fácilmente y lo más probable es que lo arregle. El mayor problema es la seguridad. Los marcos web generalmente lo ayudan a escribir el código de autenticación adecuado, cookies, protección CSRF, etc. Especialmente dada su falta de experiencia, mejor enfoque en esa área.

akostadinov
fuente
3

Comencé a escribir un comentario sobre marcos de aprendizaje, pero finalmente se convirtió en algo que parecía más una respuesta, así que aquí está.

No conocer ningún marco parece un problema. Básicamente, en cualquier trabajo de webdev, deberá trabajar con algún marco. Aprender otro marco después de conocer uno no es que gran cosa, pero el aprendizaje de la primera puede tomar un tiempo - por lo que los empleadores pueden preocuparse por eso. Evitar marcos puede indicar el síndrome no inventado aquí , que es un enfoque muy poco práctico.

Como el punto principal de conocer sus primeros marcos es aprender un idioma común, tal vez solo intente aprender algo popular entre sus compañeros. Puede intentar modificar algún proyecto simple escrito en un marco. Comenzar un proyecto desde cero en un marco que no conoces es una forma de aprendizaje muy ineficaz.

Ahora, su pregunta real era sobre un proyecto específico y portarlo a un marco. Para eso, la respuesta parece ser: depende, y realmente no podemos decírtelo. Sin embargo, portar cosas a un marco que no conoces es casi una mala idea, ya que ni siquiera puedes saber si tiene sentido . Por lo tanto, parece que debe dejarlo como está y volver a visitar esta decisión en algún momento, una vez que sepa y le guste algún marco. Otras respuestas contienen buenos puntos sobre lo que debe buscar al tomar tal decisión.

Frax
fuente
2

Este artículo recibió mucha atención en Hacker News hace 2.5 años: escriba un código que sea fácil de eliminar, no fácil de extender. Esta perspectiva puede o no ayudarlo a lidiar con su base de código actual, pero en el futuro, podría ayudar a prevenir la frustración que proviene del perfeccionismo / sobreingeniería.

Si vemos 'líneas de código' como 'líneas gastadas', cuando eliminamos líneas de código, estamos reduciendo el costo de mantenimiento. En lugar de crear software reutilizable, deberíamos intentar crear software desechable.

No necesito decirte que borrar código es más divertido que escribirlo.

(énfasis mío)

El hilo del artículo sobre Hacker News también podría ser digno de una lectura.

jasonszhao
fuente
-1

En cuanto a prepararlo para el futuro y aplicar los principios de escala y marco, es una tarea difícil de asumir, probablemente no me preocupe, pero si debe:

Mantenga su código limpio, siga los principios SÓLIDOS, SECOS> google.

Aplique un equilibrador de carga lo antes posible.

Poner de pie al menos dos servidores web, manejar escenarios de equilibrio de carga en el código.

Y por último, pero no menos importante, hay mejores pilas para manejar un millón de usuarios que LAMP, pero estoy seguro de que es totalmente factible.

Caso y punto, consulte: https://stackoverflow.com/questions/1276/how-big-can-a-mysql-database-get-before-performance-starts-to-degrade El punto es válido, pero 10 gb es trivial como sujeto de prueba.

RandomUs1r
fuente