Lo Que Debe Saber Todo Ingeniero De Sw

97 Cosas Que Todo Arquitecto De Software Debería Conocer (Tomado del libro 97 Things Every Software Architect Should Know )

1 No utilices un proyecto de un cliente para aprender una tecnología nueva que te interesa si no es lo que más le conviene a él.

2 Evita utilizar herramientas que aporten mayor complejidad al proyecto. Mantén el nivel de complejidad tan bajo como puedas.

3 Losproyectos triunfan o fracasan por las personas, no por la tecnología. Aprende a tratar y a conversar con tu equipo.

4 La comunicación es clave: procura ser claro, conciso y contar con el respeto bien ganado de tu equipo de desarrolladores.

5 El diseño y arquitectura de una aplicación inciden mucho más en su rendimiento que utilizar una u otra tecnología o hardware.

6 Descubre la necesidad realdel cliente detrás de la característica que solicita: puede haber una solución mejor y más sencilla.

7 Para conseguir comunicarte mejor con tu equipo, tanto verbalmente como no verbal, levántate, hazlo de pie.

8 Los sistemas fallan. Es inevitable. Acéptalo y planifica modos seguros para cuando lo hagan o quedarás en manos del azar.

9 Estás siempre en plena negociación, así que no cedasen aquellos requisitos que sean fundamentales para el proyecto.

10 Rápido, escalable, muchos... eso no son cuantificadores válidos. Tienes que cuantificar de modo objetivo y comprobable.

11 Los diseños no tienen valor por sí mismos, sólo son medios para lograr el objetivo, así que escucha a los programadores.

12 No existen soluciones de diseño universales. Debes tener la experiencia parasaber cuáles aplicar en cada caso (y cuáles no).

13 No dejes el análisis del rendimiento para el final. Hazlo desde el principio y verás rápidamente cuándo se vuelve un problema.

14 Además de las cuestiones técnicas, debes considerar los intereses de negocio de todos aquellos relacionados con el proyecto.

15 Crea y mantén un sistema de tests fácil y rápido de ejecutar para que losprogramadores se sientan cómodos utilizándolo.

16 No te aferres a la pureza técnica de un diseño ideal si otro menos rígido puede servir mejor a los intereses del cliente.

17 No pierdas de vista que el desarrollo de software está al servicio del negocio y sus intereses... y no al revés.

18 Hacerlo general y reutilizable está bien, pero asegúrate que primero cumple el objetivo de ser concreto yfuncional.

19 Debes liderar a tu equipo de desarrolladores desde dentro. Que tu liderazgo comience en el terreno de la tecnología.

20 Practica la integración continua en tus proyectos: compilar a menudo y de modo automático, pasar tests, reportar resultados...

21 Evita que te adelanten las fechas de entrega. Si no es posible, negocia que ciertas partes queden para futuras versiones.

22No existe un diseño con niveles altos de rendimiento, disponibilidad, seguridad y abstracción. Busca un equilibrio adecuado.

23 Presta gran atención al modelo de datos y hazlo robusto. La GUI cambia, la lógica de negocio también, los datos permanecen.

24 Si tienes que escoger entre dos opciones, replantéate aspectos del diseño que hagan que esa decisión sea menos trascendente.

25 Prestaatención a los problemas de desarrollo tan pronto como alguien los identifique y trata los riesgos como si fueran bugs.

26 Para que tu equipo reutilice un elemento es necesario que conozca de su existencia, sepa cómo se utiliza y crea que es bueno.

27 No dejes que tu ego te haga ignorar las ideas de tus programadores ni creer que conoces los requisitos mejor que el cliente.

28 Para medir lacalidad no basta con los diagramas generales y el código fuente. Crea unas métricas a medio camino para ello.

29 No bases las decisiones de diseño sólo en información teórica. Lleva a cabo pruebas prácticas de las distintas opciones.

30 Además del plano técnico, debes dominar al máximo el negocio en el que opera el cliente para entender del todo sus objetivos.

31 Programar implica más...