Cómo crear aplicaciones grandes

Prestado de tvanfosson:

Comience con una pequeña aplicación y diga sí cada vez que alguien quiere un nuevo característica añadida.

Aquí hay un libro que hemos utilizado para guiar nuestros estándares y métodos de codificación:

Texto alternativo http://ecx.images-amazon.com/images/I/51HNJ7KBBAL._BO2,204,203,200_PIsitb-sticker-arrow-click,TopRight,35,-76_AA240_SH20_OU01_.jpgLarge-Scale C++ Diseño de software

El programa en el que estoy trabajando ha estado en desarrollo durante casi 10 años desde que se redactó por primera vez en la parte posterior de la servilleta proverbial. Y el proyecto sigue siendo fuerte hoy en día. No ha sido perfecto, y todavía hay problemas con las dependencias circulares y algunas interfaces de clase no están muy limpias, pero la mayoría de las clases no son así, el programa funciona y nuestros usuarios están contentos.

También recomendaría, como se ha hecho antes por muchos otros, Code Complete y Software Estimation por Steve McConnell. Me gusta particularmente su metáfora del" crecimiento " del software en lugar de construir o construir. Esta forma de ver el software se presta mejor a algo que tendrá un largo ciclo de vida.

Como he mencionado en otra parte, las aplicaciones grandes no son solo más grandes, son diferentes. Tanto es así que hablamos de programación en-el-pequeño y en-la-grande. Hay un cambio cualitativo importante que ocurre en la naturaleza de los problemas y sus soluciones cuando se está programando en general. La línea es muy borrosa, y hay numerosos problemas específicos que pueden obligarte a cruzar esa línea.

Algunas de esas cuestiones incluir:

• tamaño (como una base de datos que simplemente no cabe en un solo disco duro)
• complejidad (de la aplicación todo en uno a múltiples subsistemas)
• concurrencia (de cero a miles/millones de usuarios simultáneos)
• disponibilidad (de 9% uptime a 99.999% uptime)
• fiabilidad (desde fallos diarios hasta varios años MTBF)
• velocidad (desde horas hasta milisegundos en tiempo de respuesta)
• productización (de su mascota proyecto a una mercancía vendible)
• etc.

Cómo lidiar con todo eso? Aprenda y use todas las técnicas valiosas que pueda, y aprenda a evaluar cuáles son realmente valiosas that eso tomará un tiempo, y no hay una respuesta rápida.

Sin embargo, hay una técnica que es fácil, obvia y de talla única: divide y vencerás. Aísle cada pieza principal de funcionalidad, cada subsistema, cada dependencia externa, para que su sistema principal solo los toque en su borde exterior. Cuando puedes cambiar cada uno de ellos simplemente ajustando una interfaz delgada en un período de tiempo muy corto, entonces has logrado algo. Eso te llevará un largo camino.

Mis mejores deseos.

1. Decide qué características son las más importantes; olvida el resto
2. Decide cuál de esas características son las más importantes y olvida el resto
3. Implementarlos (debe tomar un par de semanas, de lo contrario repita los pasos 1 y 2)
4. Lanzamiento
5. Vea qué características funcionan, cuáles no y cuáles faltan
6. volver al paso 1

Las aplicaciones grandes no se crean en una noche. Las aplicaciones empresariales comienzan con piezas pequeñas y luego se juntan. Si diseña sus aplicaciones es de tal manera que se puede escalar, entonces será más fácil de integrar con todos los factores circundantes, como bases de datos, herramientas de terceros, etc. Si entra en infoq.com usted encontrará un montón de grandes casos de estudios y materiales sobre el escalado y arquitecturas como Myspace, Amazon y muchos otros. Nada más que la experiencia conducirá usted a desarrollar grandes aplicaciones grandes.

Hacerlo extensible utilizando patrones de diseño que significa que usted no va a tener que cambiar todo a la cuña en la nueva funcionalidad.

Decide lo que necesitas construir y construye eso.

Divídalo en módulos que realicen las tareas por separado.

Plan plan plan plan, sepa lo que está construyendo antes de comenzar, y construya eso y nada más.

Solo escriba en las características que necesita, no agregue cosas que piense que podrían ser útiles, pero... dejar flexible lo suficiente para poder agregar algo que pueda necesitar agregar.

De forma incremental, utilizando Diseño basado en pruebas

Es realmente interesante notar cuántos de estos comentarios dicen que la iteración ciega es la única manera.

La iteración es crítica (soy un gran fan), pero hay personas que pueden planear grandes proyectos it es solo que pocos de nosotros hemos conocido uno.

Piensa en ello como todos nosotros jugando baloncesto en nuestras entradas. Somos bastante buenos, podemos conseguir la mayoría de las canastas y realmente tener un gran juego divertido en el parque.

Sin embargo, solo porque nunca hemos conocido jugadores profesionales, no significa que no existan y no puedan patear todos y cada uno de nuestros traseros por la cancha todo el día.

Lo único es que no hay juegos pro de programación maybe tal vez si los hubiera los veríamos un poco más.

Bueno, podrías echar un vistazo a rational unified process. Compruebe las partes esenciales, seleccione algunos de los artefactos que cree que necesitará. Haga una lista de todas las características que desee y organícelas en una lista de requisitos. También planifique su arquitectura de software cuidadosamente, para que no tenga que cambiarla más tarde. Con algunos de esos consejos, será relativamente más fácil desarrollar una aplicación grande.

Como alguien a cargo de una gran aplicación yo diría

• Utilice un marco no invasivo como Spring
• Reducir el acoplamiento
• Crea objetos inmutables siempre que sea posible - son compatibles con los hilos
• Acepte que su aplicación puede necesitar ser dividida en procesos separados para escalar mejor y planifique para eso.
• Construya un conjunto de herramientas sólido y aprenda las herramientas.

NO TE ASUSTES

Algunas ideas sobre el bloqueo de productos y proveedores:

• Trate de ser lo más independiente posible del proveedor y la plataforma. Esto evitará que tenga que reimplementar todo desde cero con un nuevo producto / plataforma / marco, etc.
• Esto prácticamente significa usar Java SE + Java EE + y RDBMS de código abierto como PostgreSQL encapsulado por JPA desde Java EE. No utilice bibliotecas adicionales, frameworks (spring, hibernate,...) sucesivamente. De esta manera puede cambiar productos y proveedores de cualquier tiempo que necesitas.
• Creo que solo se puede obtener este nivel de independencia de producto y plataforma con Java. Incluso si utiliza bibliotecas y frameworks OSS, lamentará usarlos si descubre que la implementación no se adapta a sus necesidades y tiene que rehacer todo.
• Puede comprobar la independencia del producto de su código con el Java Application Verification Kit.
• Dedique algún tiempo a la Arquitectura de antemano, pero también rediseñe la Arquitectura durante toda la implementación. Un buen libro (desafortunadamente solo alemán) es "Java EE 5 Architekturen" de Adam Bien.

@j_random_hacker: En realidad, no - Todavía creo que mi primer punto es un argumento para el uso de java en aplicaciones grandes, no en contra de ella. Cada idioma es UN idioma. Así que siempre tienes que comprometerte con un idioma, por supuesto.

• Pero Java SE & EE incluye el lenguaje, el compilador, la máquina virtual, así como todas las bibliotecas/frameworks necesarios. Pero hay diferentes IMPLEMENTACIONES de toda la plataforma Java SE / EE: Java SE (JDK) de Sun, Apache, IBM, HP, Oracle, BEA. Java EE (Servidor de aplicaciones) de Sun, Apache, Red Hat, IBM, Oracle y otros. . Net con C# solo tiene una implementación (de Microsoft y una implementación del lenguaje/plataforma algo similar llamado Mono).
• PHP también tiene solo una implementación, creo. Hay muchos compiladores de C++ diferentes. Pero todos implementan ligeramente diferentes C++-lenguajes y no se incluyen con bibliotecas que comparten la misma API. Al elegir Java, sé que puedo elegir entre media docena de implementaciones de Java SE y media docena de Servidores de aplicaciones Java EE para ejecutar el software, que a su vez se ejecutan en Linux, Solaris, FreeBSD, HP-UX, IBM z/OS, Windows, Mac OS X y en una gran variedad de plataformas de hardware. Así que simplemente no tengo que preocuparme, si encuentro un problema de implementación realmente malo al final del desarrollo o incluso en la producción, lo haría simplemente aléjate del Sol y nunca mirarías atrás. (Esta es la razón por la que recomendé el Kit de Verificación de Aplicaciones Java. Al verificar su fuente con él, puede estar seguro de que Sun, IBM, Oracle o cualquier otra compañía malvada no coló ninguna de sus cosas propietarias como dependencias en su fuente que podría vincularlo a esa compañía. Eres libre como un pájaro.)
• No se puede hacer eso con PHP o Ruby. Con esos lenguajes, tendría que arreglar el problema de implementación por sí mismo, si nadie else lo hace, porque pasar meses de tiempo parcheando errores en PHP o Ruby es aún menos esfuerzo que reescribir su aplicación completa.
• Sun tiene código abierto tanto: Java SE (el JDK completo) como Java EE (servidor de aplicaciones Glassfish). Lo único que no es "código abierto" es que hay una especificación de lenguaje vinculante, que es liderada por sun y recibe contribuciones masivas de otros. Esta es la razón por la que puede tomar la implementación de Java de sun, modificar el lenguaje Java y redistribuir esa fuente y los binarios, pero no puede llamar a que "Java" más si esto no está en línea con la especificación del lenguaje (Sun protege la marca registrada de Java para que solo se aplique a las cosas realmente java). Esto puede sonar " malo "al principio, pero en realidad asegura, que hay tal cosa como" Java": Se puede escribir una aplicación java y ejecutarlo en cualquier implementación de Java. No puede hacer eso con C++, ya que no hay una especificación de C++ que esté de acuerdo con cada implementación de c++ (una fuente el código podría compilarse con el compilador Intel C++, pero no con el GNU) y, lo que es más importante, no hay una biblioteca común: si escribo un programa C++ con la biblioteca QT, no se compilará con la biblioteca GTK, ya que tienen API completamente diferentes.
• Si no puedes soportar nada de Sun microsystems, pero quieres un Java de código abierto, entonces puedes usar Apache Harmony (Java SE) con Apache Geronimo (Java EE) encima.