architecture - publicidad - Cómo construir aplicaciones grandes

programa para crear aplicaciones android gratis (12)

Creo que me he vuelto bastante bueno en lo básico de programación (para una variedad de idiomas). Puedo escribir una * buena ** línea de código. Puedo escribir un buen método. Puedo escribir una buena clase. Puedo escribir un buen grupo de clases. Puedo escribir buenas aplicaciones pequeñas o medianas.

No obstante, no sé cómo crear una buena aplicación grande. Particularmente en el caso en que se involucran múltiples tecnologías y es probable que más se involucren con el tiempo. Digamos un proyecto con un front-end web grande, un back-end de servidor grande que se conecta con algún otro back-end de integración y finalmente una base de datos grande y compleja. Oh, he estado involucrado en algunas de estas aplicaciones y podría construir una, estoy seguro. Sin embargo, no estoy tan seguro de que pueda calificar como "bueno".

Mi pregunta es, por lo tanto, una referencia a un libro u otra buena fuente de lectura donde pueda aprender cómo distribuir y organizar código y datos para grandes proyectos generales. Por ejemplo, ¿quisiera capas de cosas muy estrictamente o me gustaría encapsularlo unidades independientes en su lugar. ¿Me gustaría tratar de mantener la mayor parte de la lógica en el mismo grupo, o debería distribuirse como parece lógico al agregar cualquier característica que agregue?

He visto muchos directores generales sobre estos temas (por ejemplo, sin código de spaghetti, código de albóndiga ...) y leí algunos excelentes artículos que discuten el tema, pero nunca he encontrado una fuente que me lleve a conocimientos prácticos concretos. Me doy cuenta de lo difícil que es la pregunta y, por lo tanto, me gustaría escuchar las lecturas que otros han encontrado para ayudarlos en su búsqueda de tal conocimiento.

Como siempre, gracias por tus respuestas.

**** Dada la naturaleza debatida de la definición de código "bueno", el término "bueno" en este contexto no se definirá (significa lo que creas que debería significar).

Decidir qué características son más importantes; Olvida el resto
Decida cuál de esas características es más importante y olvídese del resto
Implementarlos (debe tomar un par de semanas, de lo contrario repita los pasos 1 y 2)
Lanzamiento
Ver qué funciones funcionan, cuáles no y cuáles faltan
Regresa al paso 1

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

alt text http://ecx.images-amazon.com/images/I/51HNJ7KBBAL._BO2,204,203,200_PIsitb-sticker-arrow-click,TopRight,35,-76_AA240_SH20_OU01_.jpg Diseño de software en gran escala de C ++

El programa en el que estoy trabajando ha estado en desarrollo durante casi 10 años desde que se diseñó por primera vez en la parte posterior de la proverbial servilleta. Y el proyecto sigue siendo fuerte hoy. 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 ya lo han hecho muchos otros, Code Complete y Software Estimation de Steve McConnell. Particularmente me gusta su metáfora del software "creciente" en lugar de construir o construir. Esta forma de ver el software se presta mejor a algo que tendrá un ciclo de vida largo.

Bueno, podrías echarle un vistazo al proceso unificado racional. Verifique las partes esenciales, seleccione algunos de los artefactos que cree que necesitará. Haga una lista de todas las funciones que desee y organícelas en una lista de requisitos. También planifique su archivo de software con cuidado, para que no tenga que cambiarlo 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, diría

Use un marco no invasivo como Spring
Reducir el acoplamiento
Cree objetos inmutables siempre que sea posible: son aptos para el hilo
Acepte que su aplicación podría necesitar ser dividida en procesos separados para escalar mejor y planear para eso.
Construya un conjunto de herramientas sólido y aprenda las herramientas.

NO PÁNICO

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-el-grande . Hay un cambio cualitativo importante que ocurre en la naturaleza de los problemas y sus soluciones cuando se programa en general. La línea es muy borrosa, y hay numerosos problemas específicos que pueden forzarlo a cruzar esa línea.

Algunos de esos problemas incluyen:

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 subsistemas múltiples)
concurrencia (de cero a miles / millones de usuarios simultáneos)
disponibilidad (desde el 9% de tiempo de actividad hasta el 99.999% de tiempo de actividad)
fiabilidad (desde fallas diarias hasta varios años MTBF)
velocidad (desde horas hasta milisegundos en tiempo de respuesta)
Productización (desde su proyecto favorito hasta un producto 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, eso llevará un tiempo, y no hay una respuesta rápida.

Sin embargo, hay una técnica que es fácil, obvia y única para todos: dividir y conquistar. Aísle cada pieza principal de funcionalidad, cada subsistema, cada dependencia externa, de modo que su sistema principal solo los toque en su borde exterior. Cuando puede cambiar cada uno de ellos simplemente ajustando una interfaz delgada en un lapso de tiempo muy corto, entonces ha logrado algo. Eso te llevará un largo camino.

Los mejores deseos.

Es realmente interesante observar cuántos de estos comentarios dicen que la iteración a ciegas es la única forma.

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

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

Sin embargo, el hecho de que nunca nos hayamos topado con jugadores profesionales no significa que no existan y que no puede patear a todos y cada uno de nosotros durante todo el día.

Lo único es que no hay juegos profesionales de programación, tal vez si los viéramos un poco más.

Haz que sea extensible usando patrones de diseño que signifiquen que no vas a tener que cambiar todo para adaptarlo a una nueva funcionalidad.

Decide lo que necesitas para construir y construir eso.

Divídala en módulos que realizan las tareas por separado.

Planea el plan del plan, conoce lo que estás construyendo antes de comenzar y construye eso y nada más.

Solo escriba las características que necesita, no agregue cosas que crea que podrían ser útiles, pero ... déjelas lo suficientemente flexibles como para poder agregar el sonido que posiblemente necesite agregar.

Incrementalmente, usando Test Driven Design

Prestado de tvanfosson:

Comience con una pequeña aplicación y diga sí cada vez que alguien quiera agregar una nueva función.

Las aplicaciones grandes no se crean en una noche. Las aplicaciones empresariales comienzan con piezas pequeñas y luego se juntan. Si diseñas tus aplicaciones de tal manera que se puedan ampliar, será más fácil integrarse con todos los factores que lo rodean, como bases de datos, herramientas de terceros, etc. Si vas a infoq.com , encontrarás una gran cantidad de casos importantes de estudios y materiales sobre escala y arquitecturas como Myspace, Amazon y muchos otros. Nada más que la experiencia te llevará a desarrollar grandes aplicaciones grandes.

Algunas consideraciones sobre el bloqueo del producto y del proveedor:

Trate de ser el proveedor y la plataforma más independiente posible. Esto evitará tener que volver a implementar todo desde cero con un nuevo producto / plataforma / marco, etc.
Esto significa prácticamente usar Java SE + Java EE + y RDBMS de código abierto como PostgreSQL encapsulado por JPA desde Java EE. No utilice bibliotecas adicionales, marcos (primavera, hibernación, ...) etc. De esta manera puede cambiar productos y proveedores en cualquier momento que lo necesite.
Creo que solo puedes obtener este nivel de independencia de producto y plataforma con Java. Incluso si usa bibliotecas y marcos OSS, se arrepentirá de usarlos si descubre que la implementación no se ajusta a sus necesidades y tiene que volver a hacer todo.
Puede verificar la independencia del producto de su código con el Kit de verificación de aplicaciones Java .
Dedique un tiempo a la Arquitectura de antemano, pero también rediseñe la Arquitectura a lo largo de 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 usar Java en aplicaciones grandes, no en contra de ella. Cada idioma es UN idioma. Entonces siempre tienes que comprometerte con un idioma, por supuesto.

Pero Java SE y EE incluyen el lenguaje, el compilador, la máquina virtual y todas las bibliotecas / marcos necesarios. Pero existen diferentes IMPLEMENTACIONES de toda la plataforma Java SE / EE: Java SE (JDK) de Sun, Apache, IBM, HP, Oracle, BEA. Java EE (Application Server) 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 similar llamada Mono).
PHP también tiene una sola implementación, creo. Hay muchos compiladores de C ++ diferentes. Pero todos implementan lenguajes C ++ levemente diferentes y no están agrupados 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 no tengo que preocuparme, si encuentro un problema de implementación realmente malo al final del desarrollo o incluso en la producción, me alejaría de Sun y nunca miraría hacia atrás. (Es por eso que recomendé el Kit de Verificación de la Aplicación Java. Al verificar su fuente con él, puede estar seguro de que Sun, IBM, Oracle o cualquier otra compañía malvada no introdujeron ninguna de sus pertenencias patentadas como dependencias en su fuente que podría vincular usted a esa compañía. Usted es libre como un pájaro.)
No puedes hacer eso con PHP o Ruby. Con esos idiomas, debería parchear el problema de implementación usted mismo, si nadie más lo hace, porque pasar meses de tiempo de corrección de errores en PHP o Ruby es aún menos esfuerzo que reescribir su aplicación completa.
Sun tiene fuentes abiertas tanto para Java SE (el JDK completo) como para Java EE (servidor de aplicaciones de Glassfish). Lo único que no es "de código abierto" es que existe una especificación de lenguaje vinculante, que es liderada por el sol y recibe contribuciones masivas de otros. Esta es la razón por la que puede tomar la implementación de Java desde Sun, modificar el lenguaje Java y redistribuir esa fuente y binarios, pero ya no puede llamar a esa "Java" si no está en línea con la especificación del idioma (Sun protege la marca Java únicamente ser aplicado a cosas realmente java). Esto puede sonar "malo" al principio, pero en realidad asegura que existe algo como "Java": puede escribir una aplicación Java y ejecutarla en cualquier implementación de Java. No se puede hacer eso con C ++ ya que no hay especificaciones C ++ acordadas por cada implementación de C ++ (un código fuente puede compilarse con el compilador Intel C ++, pero no con 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 con los microsistemas de Sun, pero quieres una fuente abierta de Java, entonces puedes usar Apache Harmony (Java SE) con Apache Geronimo (Java EE) encima.

Como programadores, nos gusta creer que somos personas inteligentes, por lo que es difícil admitir que algo es demasiado grande y complejo como para pensarlo todo a la vez. Pero para un proyecto de software a gran escala es cierto, y cuanto antes reconozca su capacidad cerebral finita y empiece a idear formas de simplificar el problema, mejor le irá.

La otra cosa importante es darse cuenta de que pasarás la mayor parte de tu tiempo cambiando el código existente . Construir la base de código inicial es solo el período de luna de miel: necesitas diseñar tu código con la idea en mente de que, 6 meses después, estarás sentado frente a él tratando de resolver algún problema sin una idea de cómo funciona este módulo en particular, incluso aunque lo escribiste tú mismo.

¿Entonces, qué podemos hacer?

Minimice el acoplamiento entre partes no relacionadas de su código. El código va a cambiar con el tiempo en formas que no se puede anticipar: habrá problemas importantes para integrarse con productos desconocidos, cambios en los requisitos, y eso provocará cambios inesperados. Si ha establecido interfaces estables y las ha codificado, puede realizar los cambios que necesite en la implementación sin que esos cambios afecten al código que usa la interfaz. Debe dedicar tiempo y esfuerzo al desarrollo de interfaces que resistan el paso del tiempo; si una interfaz también necesita cambiar, vuelve al punto de partida.

Establezca pruebas automatizadas que pueda usar para las pruebas de regresión. Sí, es mucho trabajo por adelantado. Pero valdrá la pena en el futuro cuando pueda realizar un cambio, ejecutar las pruebas y establecer que sigue funcionando sin la ansiosa sensación de preguntarse si todo se derrumbará si compromete su último cambio con el control de la fuente.

Deja las cosas difíciles. De vez en cuando veo algún ingenioso truco de plantilla de C ++ y pienso: "¡Guau! ¡Es justo lo que necesita mi código!" Pero la verdad es que la disminución de la legibilidad y la facilidad de comprensión del código a menudo no justifica el aumento de la genérica. Si eres alguien como yo, cuya inclinación natural es tratar de resolver todos los problemas de la manera más general posible, debes aprender a restringirlo hasta que encuentres la necesidad de esa solución general. Si surge esa necesidad , es posible que tenga que volver a escribir un código, no es gran cosa.