Usted necesita tener un diseño sobresaliente para escribir un código impresionante

Si lo diseñas bien, durará para siempre.

En términos generales, puede haber seis fases en cada proyecto

– Entusiasmo

– Desilusión

– Pánico

Buscar la causa raíz

– Castigo de los inocentes

– Elogios y honores para los no participantes

La fase ” búsqueda de la causa raíz ” es muy agotadora y exigente, especialmente cuando un proyecto está condenado al fracaso. Aquí, miramos hacia atrás a proyectos que fueron horriblemente mal y nos preguntamos, ” What happened ?” Hacemos una autopsia y tratamos de juntar las piezas rotas que explicarán cómo fracasamos.

Y luego se nos ocurren razones válidas como.

– Requisitos pobres ( El cliente no sabe lo que quiere!!!!)

– Mala planificación ( nuestro jefe de proyecto lo arruinó!!!!)

– Mala gestión ( Ojalá el CEO hubiera mostrado más pelotas!!!!)

Y las razones siguen………..

Finalmente, lanzamos un buen PPT, damos “grandes garantías” para futuros proyectos, “shuffle” “shuffle” dos o tres recursos fuera del proyecto y luego cerramos majestuosamente ese jodido proyecto dolorosamente largo para “satisfacción de todos” .

Pero en todo el proceso de encubrimiento, convenientemente ignoramos el factor más importante que resultó en el fracaso

Gestión de la complejidad.

El software se volvió tan complejo que llegó a un punto en el que nadie sabía lo que hacía. Cuando un proyecto llega a un punto en el que nadie entiende completamente cómo el impacto de los cambios de código en un área afectará a cualquier otra área, podemos estar seguros de que el proyecto está condenado al fracaso. Tarde o temprano el proyecto llega a un punto muerto.

Y se crea un proyecto complejo debido a un diseño apestoso.

Como bien ha dicho Irene Au.

“El buen diseño es como una nevera – cuando funciona, nadie lo nota, pero cuando no, apesta”.

Y aquí están algunos de los maravillosos principios de diseño que me ayudaron a lo largo de mi carrera como programador.

Crear abstracciones consistentes

Josef Albers dijo con razón.

“La abstracción es real, probablemente más real que la naturaleza.”

La abstracción es la habilidad de comprometerse con un concepto mientras se ignoran con seguridad los detalles más finos que existen en los diferentes niveles. Encontramos y utilizamos la abstracción en todas partes del mundo real. Por ejemplo, cuando nos referimos a cualquier objeto como un coche , automáticamente nos referimos a él como un todo en lugar de dividirlo en sus partes individuales como chasis, motor, frenos, etc.

En términos de software, la necesidad de la hora es crear clases base potentes que le permitan centrarse en un conjunto de atributos comunes de un conjunto de clases derivadas mientras ignora los detalles de clases específicas.

Por lo tanto, una buena interfaz de clase es una abstracción que le permite centrarse en la interfaz sin preocuparse por el funcionamiento interno de la clase. Esto crea un diseño que es simple y luego fácilmente desacoplable.

Un gran diseño de software significa abstracciones creadas a nivel de la interfaz de rutina, de la interfaz de clase y de la interfaz de paquete, lo que resulta en una programación más rápida y segura.

Ocultar los detalles de implementación

Len Wein golpea el clavo en la cabeza cuando dice.

“En general, más corto es mejor. Si puedes encapsular tu idea en una sola frase cautivadora, estás a mitad de camino”.

Ocultar o encapsular recoge donde sale la abstracción. Mientras que la abstracción dice “You are allowed to look at any object at a higher level of detail” , encapsulations va un paso más allá y dice “You are not allowed to look at that object with any other level of detail also”.

Aquí es donde entra en juego el maravilloso concepto de herencia .

En el diseño de cualquier sistema de software, a menudo podemos encontrar que los objetos son muy similares entre sí, excepto por algunas diferencias. Por ejemplo, al diseñar un sistema de contratación, podemos tener diferentes tipos de contratos (fijos, temporales y materiales, basados en incentivos, etc.), pero los atributos generales de cada contrato siguen siendo los mismos. Así, puede crear un objeto genérico llamado “contract” y luego definir “fixed price” contract como “heredado” de contract object con algunos atributos adicionales, etc.

La herencia simplifica el diseño porque se escribe una rutina genérica para manejar cualquier cosa y luego se escriben rutinas específicas para ocuparse de escenarios específicos. No sólo el código ” está limpio ” sino que también ofrece una gran manera de desacoplar detalles innecesarios del desarrollador que usará la clase u objeto para heredar.

La herencia es una de las herramientas más poderosas de la programación orientada a objetos. Es una espada de doble filo; puede proporcionar grandes beneficios cuando se usa correctamente y puede hacer mucho daño cuando se usa ingenuamente.

El cambio ocurrirá. Planifique para ello.

Amit Ray lo mata maravillosamente cuando dice.

“En cada cambio, en cada hoja que cae hay algo de dolor, algo de belleza. Y así es como crecen las nuevas hojas.”

Mientras se diseña cualquier sistema, los cambios anticipados deben tenerse en cuenta y las disposiciones deben mantenerse en su lugar para prevenir las quemaduras de corazón y el duelo más adelante. Como regla general, debe diseñar su sistema de manera que el efecto o alcance del cambio sea directamente proporcional a la probabilidad de que ocurra lo mismo.

Cuanto mayor sea la probabilidad, mayor será la necesidad de que el sistema esté preparado para adaptarse al cambio.

Un buen punto de partida puede ser identificar las áreas que tienen el potencial de cambiar y luego identificar el subconjunto mínimo que se espera que permanezca constante. Toda la planificación posterior se puede hacer en la parte superior de este subconjunto mínimo.

Así, identificando primero el núcleo, puede ver claramente qué componentes adicionales necesitan ser construidos y dejar ” exit ” en el código para planificar la implementación en un momento posterior.

Así, en pocas palabras, crear un conjunto de clases y rutinas con relaciones pequeñas, directas y flexibles con las clases principales de una manera ” libremente acoplada “. Este acoplamiento suelto permite que el diseño sea lo suficientemente flexible para adaptarse a los cambios y facilitar la implementación.

Iterar hasta que lo hagas bien.

Sebastian Thrun dijo con razón.

“Pocas ideas funcionan en el primer intento. La iteración es la clave de la innovación”.

El diseño es siempre un proceso iterativo. A menudo te encuentras con que vas del punto A al punto B y luego vuelves de nuevo al punto A para empezar de nuevo. Es frustrante, pero no hay atajos para llegar a un diseño robusto y viable. La paciencia es la clave.

A medida que camina por el sendero de A a B, verá varios diseños, probará varios enfoques y contemplará varias vistas de alto y bajo nivel. La vista inicial de alto nivel es fluida y a medida que se camina, se solidifica la misma en vistas de bajo nivel de concreto. Finalmente, se decide por un enfoque; de arriba hacia abajo o de abajo hacia arriba y luego se crea un marco de trabajo basado en ello.

La clave no está en detenerse en el primer intento. El segundo intento es siempre mejor que el primero y en cada intento se aprenden cosas que mejoran progresivamente el diseño general. El refinado incremental es una herramienta muy poderosa para reducir la complejidad.

Como bien ha dicho Polya.
“Comprende el problema, diseña un plan, lleva a cabo el plan y luego mira hacia atrás para ver cómo te fue”.

El prototipo es la prueba en el pudín

Laurie Anderson ha dicho correctamente.

“El problema con los prototipos es que no siempre funcionan. Pero así es como debe ser”

Quizás la mayor ventaja del prototipado es la representación visual del diseño, una imagen aunque a menor escala sea de más de mil palabras. Esta imagen no sólo nos convence de la trabajabilidad del diseño, sino que también nos ayuda a conseguir las ” buy-ins ” y las aprobaciones necesarias para seguir adelante.

Pero dicho esto, el prototipado no es para todos los proyectos, pero para los proyectos, es lo correcto, puede ser una gran ventaja.

El Modelo de Creación de Prototipos es un método de desarrollo de sistemas (MDF) en el que se construye un prototipo (un borrador preliminar de un sistema o producto final), se prueba y luego se vuelve a trabajar según sea necesario hasta que se logra un prototipo aceptable a partir del cual se puede desarrollar el sistema o producto completo.

Un prototipo sirve como un modelo desechable hecho para entender los requisitos de un proyecto antes de que comience el diseño y la codificación. En esencia, la creación de prototipos es una prueba de proyecto.

Hay muchos problemas inesperados que pueden ocurrir durante el proceso de desarrollo de software, incluso si usted ha revisado el diseño varias veces. La prueba de prototipado permitirá al menos que el equipo de desarrollo sepa dónde están los problemas y tenga la oportunidad de mejorarlo antes de lanzar el producto al público.

Utilizado con disciplina, el prototipado es la herramienta de trabajo, un diseñador tiene a su disposición para combatir la maldad del diseño. La venganza puede ser inmensa; basta con mirar el iPhone.

Entonces, ¿cuánto es suficiente diseño

?

Desafortunadamente, no hay una respuesta racional o lógica a esta pregunta. En la mayoría de los casos, es más un juicio que cualquier otra cosa. Pero aunque no se puede garantizar con precisión la cantidad correcta de diseño requerida en cualquier proyecto, dos enfoques de diseño están destinados a fallar cada vez.

– No tener ningún diseño

– Diseñando todo por adelantado hasta el último detalle.

Esfuércese por la simplicidad y persista dogmáticamente con la iteración hasta que llegue al diseño más óptimo. Cuanto más se acerque su diseño al problema de la vida real, está diseñado para resolverlo, más posibilidades de éxito tiene, tan simple como eso.

Como Steve Jobs ha dicho acertadamente.

“El diseño no es sólo lo que parece y se siente. El diseño es como funciona”.

Sobre el autor-:

Ravi Rajan es un administrador de programas globales de TI con sede en Mumbai, India. También es un ávido bloguero, escritor de poesía haiku, entusiasta de la arqueología y maníaco de la historia. Conectar con Ravi en LinkedIn , Medium y Twitter .

ConsejosLecciones de vidaTecnologíaCodificaciónProgramaciónContinuar la discusión