A riesgo de actuar como si pensara que soy genial (estoy orgulloso de mi trabajo, así que no me disculpo por eso), voy a opinar sobre lo que creo que * hago * que hace que * yo * haya hecho bastante solido Otros son libres de tener su propia idea de lo que significa “buena arquitectura”.
1. Demanda de pensamiento a largo plazo. Hay * siempre * problemas momento a momento, día a día que deben abordarse. Esas son * no * la principal preocupación del arquitecto de software, incluso en empresas más pequeñas, proyectos más pequeños o entornos con equipos de desarrollo limitados. Si deja que la política de la empresa o las quejas de Loudest Voice determinen su dirección de desarrollo, fracasará. Si usted también está a cargo de esos requisitos, como yo lo hago, es un equilibrio delicado, pero absolutamente necesario. Puede destruir una empresa completa satisfaciendo “las necesidades de hoy”.
2. Desarrolle un esquema flexible antes del código. Determine qué datos tiene, qué datos necesita, qué debe hacer con ellos y cómo deben presentarse antes de comenzar a crear funciones y clases. Su trabajo como arquitecto de software no es * solo * dirigir la creación de código, es comprender el proceso. La dirección en la que decida ir no debe depender particularmente del idioma en el que se está escribiendo el código o de la plataforma para la que se está escribiendo. Se trata de administrar los datos con los que está trabajando de manera efectiva y eficiente. Suponga que habrá más datos. Suponga que deberá usarse de formas diferentes a las que anticipa actualmente.
- ¿Quién ofrece capacitación en pruebas de software?
- ¿Cuál es el puntaje mínimo de GRE requerido para la maestría en ingeniería de software en Canadá?
- ¿Cuáles son algunos temas de investigación actuales en ingeniería de software?
- ¿Cómo procede una sesión típica de programación de pares?
- Completé mi BTech (ECE) con el 70% en 2014 y me colocaron en una pequeña empresa de software. Estoy trabajando con Qualcomm en chipsets, pero no estoy satisfecho con esto. ¿Cómo me puedo mudar a los Estados Unidos?
3. Recopile datos que aún no esté utilizando. No puede usar datos que no está recopilando. Si hay una razón válida e insondable para recopilar datos, diseñe un código para preservar los datos recopilados, incluso si le da una fecha de vencimiento o desactiva la recopilación de datos. Prepárese para recopilar errores de software y datos de perfiles de errores creados por el usuario. Los errores del usuario apuntan a problemas en la implementación de la interfaz de usuario. Tómalos en serio. Hago que los errores generados por los usuarios me envíen un correo electrónico cada vez que suceden. Si comienzan a molestarme, hago un punto para abordar la interfaz de usuario que está engañando a los usuarios a hacer cosas estúpidas e incorrectas.
4. Los procesos comunes usan rutinas comunes. ¿Escribir muchos archivos XML? Escribe un controlador para eso. Está muy bien que exista una forma estándar de hacerlo fuera de su propio código, pero 100 piezas diferentes de código propio no deberían referirse a una biblioteca de terceros. Si esos archivos XML van a una aplicación externa, le garantizo que los requisitos de la aplicación externa cambiarán. Querrá un XML con un formato diferente, palabras clave diferentes, tal vez un formato completamente diferente como YAML o JSON. * No * escriba esos archivos XML desde 20 lugares diferentes. ¿Trabajando con una base de datos? NO escriba un montón de código específico de DB en miles de rutinas diferentes. Lo mismo ocurre con cualquier otra cosa que hagas que tenga incluso la más vaga esperanza de cambiar. Si está trabajando con datos similares de manera similar, trabaje con ellos en un solo lugar. Haga esto todos los días, sin excepciones.
5. La arquitectura es arquitectura. Su objetivo como arquitecto de software es crear un edificio de código que sobrevivirá a la prueba del tiempo. Si pasa mucho tiempo escribiendo o dirigiendo la creación de líneas individuales o bloques de código, no está haciendo arquitectura. Con frecuencia paso una parte sustancial de mi día escribiendo código, pero paso días, incluso semanas, sin escribir nada importante, sino más bien considerando lo que el próximo código debe hacer de la manera más minimalista posible. La modularidad y la capacidad de reutilización son clave: desea piezas de código que puedan reemplazarse, desea herramientas que puedan ampliar su capacidad a medida que cambian las necesidades.
6. Las soluciones a corto plazo son a corto plazo. ¿Necesita obtener algún código esta mañana porque mantiene las ventas en espera? Adelante: retoca y empuja. Entonces hazlo bien. Hoy. Mañana. No “después de que el proyecto haya terminado”, no “después de que Bob regrese de vacaciones”. Las emergencias no pueden definir la dirección del desarrollo del código. Puede y destruirá un gran desarrollo al no implementar un código robusto y duradero.