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.
fuente
Respuestas:
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 .
fuente
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.
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).
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.
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.
El mismo problema surge aquí. La solución no es pensar más, sino actuar:
Para leer más sobre esto, lea La mentalidad de hacer> la mentalidad de pensar . El autor lo explica mejor que yo.
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.
fuente
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:
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.
fuente
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:
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).
fuente
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.
fuente
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.
fuente
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.
fuente
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.
(énfasis mío)
El hilo del artículo sobre Hacker News también podría ser digno de una lectura.
fuente
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.
fuente