Escribir o no escribir: Frameworks [cerrado]

Hoy algunos amigos y yo comenzamos a discutir marcos ...

Algunos de nosotros creemos firmemente que en el 99.9% de los casos, escribir un nuevo marco es una mala idea. Creemos que probablemente algunos de los millones de marcos existentes deberían ajustarse a nuestro problema, y ​​si no, algún hack, API o configuración debería ser suficiente. Si no, creemos que contribuir a algún marco, sugerir características o algo así debería ser la mejor solución. El 0.1% es cuando ninguno de los marcos se ajusta a nuestro caso.

Pero, algunos de nosotros decimos que es mejor tener un "marco corporativo interno" (por ejemplo), porque es más rápido solucionar problemas, crea un ajuste del 100% con la aplicación, debido al factor de "aprendizaje" (cuando mejora sus habilidades para construir un marco), etc.

Creo que salir de los marcos de codificación como si no hubiera un mañana no es la forma correcta. He visto a muchos equipos pequeños construir su propio marco solo para correr la voz: "construimos nuestro propio marco, nosotros gobernamos, hermano". Generalmente, el framework es basura, sin ninguna documentación, y solo funciona para sus propias aplicaciones.

Las opiniones son opiniones, los desarrolladores son desarrolladores, sin la intención de comenzar ningún tipo de guerra de llamas, pregunto:

¿Qué piensas sobre eso? ¿Qué parámetros considera al construir un marco? Que piensas sobre todo esto?

Estoy en el lado opuesto del espectro de GrandmasterB. Para mí, esta es una pregunta de compra versus construcción.

Desde mi perspectiva, mi tiempo y esfuerzo pueden estar representados por un costo. La pregunta entonces es, ¿cuándo hay suficiente retorno de la inversión para construir un marco? (Si estoy trabajando para un cliente, pienso en estas preguntas desde la perspectiva del cliente).

Aquí están las preguntas que me hago:

• ¿El marco ya existe?
• Si construyo este marco, ¿es algo por lo que quiero ser conocido? En otras palabras, ¿es este marco un diferenciador para mí?

A menudo, encuentro que la respuesta a la segunda pregunta es no. Estoy trabajando para una empresa de salud ahora. No desean ser conocidos como los desarrolladores de los mejores motores de programación. Debería externalizar el desarrollo y mantenimiento de ese marco.

Sin embargo, si estamos hablando de un motor de precios, ese es el pan de cada día de la compañía, por lo que definitivamente debería concentrar mi energía en hacer un motor excelente.

Mi regla general es, si es un producto o una parte importante del producto, hacerlo yo mismo siempre que sea posible. Si no es la funcionalidad principal, o está actuando en apoyo de un negocio (algo que solo se usa internamente), enloquezca con los marcos.

Muchas de las aplicaciones que hago son inversiones a largo plazo, posiblemente más de 10 años, y son productos que se venden a los clientes (por lo tanto, mi responsabilidad). Por lo tanto, ser capaz de comenzar 'rápidamente' usando un marco de terceros no es tan relevante para mí como lo sería para alguien que está haciendo una docena de aplicaciones al año. Por lo tanto, generalmente no me opongo a sumergirme en lo esencial y hacer lo mío. A lo largo de la vida útil del producto, unas pocas semanas adicionales para obtener un marco / componente personalizado no importará mucho. Pero puede significar muchos menos dolores de cabeza y menos paredes de ladrillo, ya que está diseñado específicamente para la aplicación.

Me parece que un marco es una colección de bibliotecas. Una vez que tenga un montón de ellos y se asegure de que tengan API consistentes y jueguen bien juntos, los agrupará y lo llamará un marco. Pero debe asegurarse de que todas las bibliotecas de su empresa tengan API consistentes, ya sea que use la palabra F o no.

Los marcos tienden a escribirse 'accidentalmente' cuando alguien mira todo lo que tiene y dice 'hmmm, este montón de cosas pueden ser útiles para otros'. Eso es a menos que sea una empresa que envía fuente, o se le haya pedido explícitamente que escriba un marco. Hacer cosas por el simple hecho de hacer cosas siempre es una mala idea en la programación.

Hagas lo que hagas, asegúrate de no reinventar la rueda, especialmente como un cuadrado.

Si eres como yo, tu trabajo es proporcionar valor comercial de la manera más eficiente posible, no depurar y modificar proyectos favoritos. Si hay un marco ampliamente utilizado que hace lo que necesita, no pierda su tiempo reinventando la rueda, ya que el marco ampliamente aceptado probablemente lo hace mejor que usted. Han tenido más tiempo, experiencia y recursos para desarrollarlo.

En los últimos 6 meses, mi compañía recientemente me hizo escribir 2 aplicaciones diferentes que hacen muchas cosas similares. Recientemente me han pedido que escriba una tercera aplicación similar, y hay mucho espacio para aplicaciones más similares en el futuro. Como nadie ha desarrollado un marco para la tecnología patentada con la que estoy trabajando, no vi otra opción que desarrollar mi propio marco. Si no desarrollo mi propio marco, pasaré mucho tiempo repitiéndome, y eso será una pérdida de tiempo y dinero.

Creo que esta es la clave para saber si vale la pena construir uno propio o usar el de otra persona. Si tiene que gastar una tonelada de efectivo en los próximos años, o crear un marco, entonces cree el marco.

Es muy difícil predecir con precisión cómo sería un marco ideal sin haber construido primero algo. Cosechadas soluciones son generalmente mejores que los cimientos soluciones (Gracias por los enlaces caarlos0 ), debido a que su código no se basa en conjeturas sobre lo que el programador cliente quiere, pero la experiencia real. Leer: Diseño emergente .

Dicho esto, solo tengo una razón en mi mente para construir su propio marco: si ha hecho el mismo trabajo dos veces y probablemente lo hará varias veces más, y nadie lo ha hecho por usted.

Intento obtener la mayor cantidad de millas de los marcos y herramientas disponibles en cualquier proyecto nuevo. Una vez que el proyecto ha evolucionado, quizás se haya quemado durante uno o dos años, y luego reemplazar las partes del marco que causan más dolor es una opción razonable. A menos que su plan de negocios se centre en crear un nuevo marco, no planearía escribir el suyo.

Cuando una pieza de tecnología realmente falla, mantengo una lista de quejas e ideas específicas sobre cómo debería rediseñarse para que funcione mejor. A corto plazo, este "manifiesto" me da una salida para mis frustraciones mientras sigo usando el marco existente . En el mediano plazo, me ayuda a identificar los peores puntos de dolor para no desperdiciar energía solucionando problemas menores. A largo plazo, el manifiesto puede convertirse en un diseño para un reemplazo parcial o completo, o en una lista de características para elegir un nuevo marco.