Primero, aquí están mis 2 reglas para evitar el síndrome de desperdicio de marco:

• La ausencia de uno existente, que cubra el 80% de mis necesidades y ampliable para igualar el último 20%
• El la certeza de que lo usaré de nuevo, en otra aplicación

Después de pasarlos, revise esto:

• http://www.slideshare.net/brada/framework-design-guidelines-presentation
• http://www.informit.com/podcasts/episode.aspx?e=5a161893-c1ce-4449-8b67-31baa54ce316
• http://www.marlabsblogs.com/?tag=microsoft-framework-design-guidelines

Comentarios

• Yo agregaría que si no puedes ‘ t encontrar un marco que cumpla con tu regla 80/20 o estás trabajando en un dominio extremadamente único O usted ‘ no comprende su dominio lo suficientemente bien.

Experiencia dolorosa y mucho esfuerzo inútil Lleve a este consejo: extraiga o refactorice un marco de trabajo del software. Cree ese software teniendo en cuenta que cree que querrá extraer un marco en el futuro, pero no cree el marco primero.

Sugeriría el libro Framework Design Guidelines . Tiene un par de años, pero los principios siguen siendo ciertos. Tiene un montón de patrones y explica el razonamiento detrás de las decisiones que tomará al crear un marco.

1) Cíñete a las buenas convenciones desde el principio, asegúrate de haber documentado una convención muy específica, los mejores marcos son los que son coherentes internamente.

2) Asegúrate de que todo esté bien documentado, desde bien comentarios de código hasta el final para explicar lo que las funciones más importantes requieren y producen, incluso si le parece muy simple, es posible que alguien lo use en la decimocuarta hora consecutiva y solo necesita esa cosa en ese momento.

3) Establezca un resumen del proyecto para usted, con lo que desea que el marco logre, objetivos realistas y prioridades generales.

4) Si va a estar disponible para que la gente lo use, asegúrese de tener algún tipo de proceso de soporte / seguimiento de errores en su lugar. Habrá errores, nos pasa a todos, pero si puede gestionarlos desde el principio, le facilitará la vida.

En general, un enfoque similar para crear cualquier aplicación, pero los desarrolladores son incluso más exigentes que los usuarios, y los mejores marcos son los que podemos aprender, entender y no tenemos que luchar.

No estoy de acuerdo con mucho de lo que se ha dicho y siento que se ha dejado más sin mencionar, así que empezaré desde cero.

Metodologías ágiles

Adopte metodologías ágiles durante el desarrollo de su marco para que pueda adaptarse a los cambios, reaccionar rápidamente a los obstáculos y garantizar un producto final funcional y de calidad. Las metodologías ágiles son aquellas que, según el «Manifiesto Agile», priorizan:

Individuos e interacciones sobre procesos y herramientas
Software en funcionamiento sobre documentación completa
Colaboración con el cliente sobre negociación de contrato
Responder al cambio sobre siguiendo un plan

Así es. Dije que la funcionalidad es más importante que la documentación. Tenga en cuenta que el «Manifiesto Ágil» menciona que las prioridades de la derecha siguen siendo importantes, pero menos que los de la izquierda.

Comunicación

Quien esté creando el marco debe saber:

1. Cómo se utilizará: el aplicación de destino
2. Qué problema se pretende resolver: el problema de destino
3. Quién lo usará: la audiencia objetivo

Por ejemplo, si una empresa tuviera la intención de desarrollar una aplicación final con ASP .NET, sería una tontería decirle a sus programadores «hacer este marco» sin decirles lo anterior. Si los programadores no conocían la aplicación de destino, es posible que no la hicieran orientada a la web. Si no conocían el problema, podrían crear un marco para un propósito diferente. Si no conocieran a la audiencia, podrían programar el marco en C ++. Cualquiera de estas circunstancias haría que el marco resultante fuera inútil.

Estilo

No hace falta decir que establezca un estilo de programación / y apégate a él.

La E «s

1. Modularidad : reutiliza el código mediante programación, no literalmente.
2. Eficiencia : tu código está destinado a ser reutilizado . Cualquier perjuicio a la velocidad se multiplica.
3. Mantenibilidad : desea poder editar el marco para actualizar varios programas, sin tener que modificar dichos programas.
4. Usabilidad : ¿Pueden las aplicaciones realmente usar su marco sin saltar por el aro?
5. Practicidad : No reinvente la rueda si no tiene para hacerlo. Su marco puede depender de otros marcos.
6. Redundancia : Detecte excepciones / errores. En todos lados. Manéjelos. En todos lados. Nunca confíe en ningún código que no esté en el ámbito local para manejar errores, incluso si sabe que lo hace.

Comentarios

• Bienvenido a P.SE! ‘ no estoy de acuerdo con el n. ° 6 sobre la captura de excepciones en su marco. Yo ‘ soy un gran creyente en que el marco debería ser un mocoso absoluto y lanzar excepciones y dejarlo en manos del programador que usa el marco para detectarlos o (mejor aún) reorientar su código para como para evitar la excepción – alentando la conformidad con la convención.

Estoy seguro de que hay alguna diferencia entre el desarrollo de un marco o biblioteca y una aplicación.

Los procesos de desarrollo son esencialmente los mismos. Las diferencias pueden deberse a cuestiones de marketing e implementación, aunque creo que las mayores diferencias suelen estar en términos del alcance y la definición del proyecto. Recuerde que una Aplicación puede incluir o utilizar un marco o una biblioteca, un marco puede ser una colección de bibliotecas.

Tengo algunas dudas sobre cómo manejar la organización y gestión de ese proyecto: ¿Existen algunas reglas generales para ¿Bajo, consejos, mejores prácticas o algo a tener en cuenta para desarrollar este tipo de proyecto?

La organización y gestión del proyecto vuelven a ser las mismas para cualquier proyecto de desarrollo . De nuevo, todo se reduce al alcance. Sin embargo, cuando se trata de escribir un marco, vale la pena tener una visión muy clara sobre lo que está tratando de lograr y colocar reglas de diseño estrictas en la interfaz pública del marco para garantizar la coherencia en términos de las API. presentación. Si permite que cada desarrollador haga lo suyo, terminará con un lío complicado y un diseño de API muy poco elegante.

Seguiré la recomendación de Ryan Hayes para leer las Directrices de diseño del marco aunque el libro en sí está dirigido a desarrollar marcos basados en .NET, porque el consejo general es aplicable independientemente de las tecnologías de implementación específicas que pueda elegir utilizar.

Por experiencia, aconsejaría seguir el principio clásico de YAGNI implementando primero las interfaces públicas más simplistas y luego expandiéndolas para ofrecer un mayor control y profundidad más adelante, pero tenga cuidado de usar nombres útiles para mostrar por qué se están expandiendo métodos o clases. Nunca he sido un fanático de agregar «Ex» u otros sufijos similares a los nombres de los métodos, o agregar números a las definiciones de interfaz expandidas. Diferencie la funcionalidad, y los nombres de su interfaz / método deberían volverse más claros y, con suerte, menos confusos y confusos.