Necesito comenzar el diseño y desarrollo de un nuevo marco para interactuar con un ECM de código abierto. Esto incluye un modelo de datos personalizado para ayudar a los desarrolladores de sitios web a interactuar con este ECM, por lo que no necesitan preocuparse por los detalles de la manipulación de nodos y otros detalles de bajo nivel. Eso es solo un montón de clases y métodos para desarrollar.

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

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

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

• La ausencia de una existente, cubriendo el 80% de mis necesidades y ampliable para coincidir con el último 20%
• La casi certeza de que lo usaré nuevamente, en otra aplicación

Después de pasar esos, mira 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

1) Las características solo deben agregarse a un Framework cuando se extraen del código de trabajo. En otras palabras, antes de agregar su nueva idea genial a su nuevo marco genial, asegúrese de que realmente agregue valor y reduzca la repetición en una aplicación funcional del mundo real.

2) Documentación, documentación, documentación.

3) Documentación, documentación, documentación.

Una experiencia dolorosa y un gran esfuerzo desperdiciado llevan a este consejo: extraer o refactorizar un marco de trabajo del software. Cree ese software teniendo en cuenta que cree que querrá extraer un marco en el futuro, pero no lo haga 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 construir un marco.

1) Apéguese a las buenas convenciones desde el principio, asegúrese de haber documentado una convención muy específica, los mejores marcos son los que son consistentes internamente.

2) Asegúrese de que todo esté muy documentado, desde buenos comentarios de código hasta la explicación de las funciones más importantes que requieren y producen, incluso si le parece súper simple, es posible que alguien lo use en la decimocuarta hora consecutiva y ellos solo necesito esa cosa en ese momento.

3) Establezca un resumen del proyecto para usted, con lo que desea que alcance el marco, 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 puedes manejarlos desde el principio, te hará la vida más fácil.

En general, un enfoque similar para construir cualquier aplicación, pero los desarrolladores son aún más exigentes que los usuarios, y los mejores marcos son los que podemos elegir, tener sentido y no tenemos que luchar.

No estoy de acuerdo con mucho de lo que se ha dicho y siento que no se ha mencionado más, así que comenzaré desde cero.

Metodologías ágiles

Adopte metodologías ágiles durante el desarrollo de su marco de trabajo 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, de acuerdo con el "Manifiesto Ágil", priorizan:

Individuos e interacciones sobre procesos y herramientas
Software de trabajo sobre documentación integral
Colaboración del cliente sobre negociación de contratos
Responder al cambio sobre seguir 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, solo que menos que las de la izquierda.

Comunicación

Quien crea el marco debe saber:

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

Por ejemplo, si una empresa tuviera la intención de desarrollar una aplicación final con ASP .NET, sería una tontería decirles a sus programadores que "hagan este marco" sin decirles lo anterior. Si los programadores no conocían la aplicación de destino, podrían no estar orientados a la web. Si no supieran el problema, podrían hacer un marco para un propósito diferente. Si no conocieran al público, podrían programar el marco en C ++. Cualquiera de estas circunstancias haría inútil el marco resultante.

Estilo

No hace falta decir que establezca un estilo / formato de programación y manténgalo.

Las E

1. Modularidad : reutilice el código mediante programación, no literalmente.
2. Eficiencia : su código está destinado a ser reutilizado. Cualquier detrimento de la velocidad se multiplica.
3. Mantenibilidad : desea poder editar el marco para actualizar varios programas, sin tener que modificar dichos programas.
4. Facilidad de uso : ¿Pueden las aplicaciones realmente usar su marco sin saltar por los aros?
5. Practicidad : no reinventes la rueda si no tienes que hacerlo. Su marco puede depender de otros marcos.
6. Redundancia : excepciones / errores de captura. En todas partes. Manejarlos. En todas partes. Nunca confíe en ningún código que no sea en el ámbito local para manejar errores, incluso si sabe que lo hace.

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 problemas de comercialización 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 usar 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 la gestión de ese proyecto: ¿Hay algunas reglas generales a seguir, consejos, mejores prácticas o algo a tener en cuenta para desarrollar este tipo de proyecto?

La organización y gestión de proyectos son nuevamente las mismas para cualquier proyecto de desarrollo. Nuevamente 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 estrictas de diseño en la interfaz pública del marco para garantizar la coherencia en términos de la presentación de la API. Si permites que cada desarrollador haga lo suyo, terminarás con un desorden complicado y un diseño de API muy poco elegante.

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

Por experiencia, recomendaría apegarse al principio clásico de YAGNI mediante la implementación de las interfaces públicas más simplistas primero, y luego expandirlas 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 los métodos o clases. Nunca me ha gustado agregar "Ex" u otros sufijos similares a los nombres de los métodos, ni agregar números a las definiciones de interfaz ampliadas. Diferencie la funcionalidad, y sus nombres de interfaz / método deberían ser más claros y, con suerte, menos confusos y confusos.