Veo algunos problemas serios con esta pregunta. Empecemos.
Cómo dejar de perder el tiempo diseñando arquitectura
Esta pregunta está bastante cargada. Además, no diseñas arquitectura. Tu arquitecto . La arquitectura y el diseño son actividades complementarias y relacionadas, pero no son lo mismo, incluso si se superponen.
Del mismo modo, de la misma manera es posible perder el tiempo haciendo arquitectura (sobre arquitecturando), también puede perder el tiempo diseñando y codificando en exceso (codificando cosas de una manera mucho más compleja de lo necesario, o no código para las cosas que se requieren)
La arquitectura adecuada tiene como objetivo evitar ese desperdicio en la codificación. Lo hace limitando, reduciendo y documentando las posibles formas en que un sistema complejo debe ser 1) diseñado, 2) codificado y probado, 3) entregado, 4) mantenido, 5) recuperarse de una falla y 6) finalmente desmantelado.
Mi experiencia ha sido que las personas que simplemente disfrutan de la codificación, simplemente codifican sin pensar en cómo debe funcionar y mantenerse un sistema a largo plazo, moviéndose a la próxima papa caliente, dejando un alma pobre para mantener un feo golem.
Pero yo divago...
Esto es lo que sucede: para sistemas lo suficientemente simples, la arquitectura es evidente y emana de las prácticas de diseño e implementación de sonido.
Es solo para sistemas grandes que involucra una gran cantidad de personas o software de nivel de sistema que hace cosas muy complejas que requieren una arquitectura explícita.
Recientemente me gradué de la universidad y comencé a trabajar como programador. No me resulta tan difícil resolver problemas "técnicos" o depurar, cosas que diría que tienen 1 solución.
Ese es el mínimo requerido para esta profesión, y me alegro de que no tenga problemas para hacerlo (me preocuparía si lo hiciera).
Pero parece haber una clase de problemas que no tienen una solución
Esos son el pan de cada día de nuestra profesión, el tipo de problemas por los cuales los empleadores están dispuestos a pagar nuestros (típicamente) salarios muy por encima del promedio.
De hecho, los problemas que vale la pena resolver son aquellos que pueden tener más de una solución. Problemas del mundo real, son así. Y el mundo requiere nuestra experiencia, como desarrolladores de software, para llegar a compensaciones aceptables.
- Cosas como la arquitectura de software.
La arquitectura de las cosas es una característica inevitable de un sistema complejo, ya sea virtual / software o en el mundo concreto. Cada sistema que opera, que toma entrada y produce salida, será complejo y tendrá una arquitectura.
Cuando desarrollamos software para dichos sistemas (un sistema bancario, un sistema de monitoreo de energía, un sistema de venta de boletos, etc.), nuestro objetivo es producir un software que imite las funciones y requisitos de dicho sistema.
Simplemente no podemos simplemente volarlo y codificarlo al estilo vaquero. Necesitamos algún tipo de arquitectura. Esto es particularmente cierto si el proyecto requiere docenas de ingenieros, si no más.
Estas cosas me confunden y me causan gran angustia.
Es correcto. No es un tema fácil de aprender o enseñar, no sin mucha práctica.
Paso horas y horas tratando de decidir cómo "diseñar" mis programas y sistemas. Por ejemplo, si divido esta lógica en 1 o 2 clases, ¿cómo nombro las clases? ¿Debería hacer esto privado o público? Etc. Este tipo de preguntas ocupan mucho de mi tiempo y me frustra mucho. Solo quiero crear el programa, maldita sea la arquitectura.
Desafortunadamente, eso no es arquitectura de software.
Ni siquiera es diseño, sino solo codificación. Proporcionaré algunas sugerencias al final de esta publicación.
¿Cómo puedo pasar más rápidamente por la fase de arquitectura y pasar a la fase de codificación y depuración, que disfruto ?
Me está costando encontrar una manera de responder a esto, porque es bastante emocional.
¿Estamos tratando de hacer un trabajo o solo estamos tratando de disfrutar la práctica? Es genial cuando ambos son lo mismo, pero en la vida real, muchas veces no lo son.
Es genial hacer cosas que disfrutamos, pero en una profesión tan compleja como la nuestra, centrarse solo en lo que disfrutamos, eso no es propicio para tener una carrera fructífera.
No progresarás, no madurarás ni adquirirás nuevos conocimientos.
Hay un dicho en el ejército, "abraza la succión".
Otras frases tienen consejos similares. "Si no apesta, no vale la pena" y mi favorito, "si apesta (y es importante), hágalo hasta que deje de chupar".
Mis recomendaciones:
Me parece que todavía estás luchando por entender las diferencias entre
codificación (cómo codificar sus clases, módulos o qué no, convenciones de nomenclatura, visibilidad de acceso, alcance, etc.),
diseño (cuántos niveles, front-end / back-end / db, cómo se comunica cada uno, qué va a dónde) y las decisiones de arquitectura implícitas que provienen del diseño de sistemas simples,
arquitectura (como se encuentra en sistemas complejos que requieren miles, si no cientos de miles de horas hombre).
Por lo tanto, le sugiero que profundice en el primer tema (codificación) para llevarlo al siguiente nivel.
Código limpio
El "Código limpio " de Robert "tío Bob" Martin es un buen lugar para comenzar.
Cohesión de software
Además, le sugiero que se familiarice con una métrica de software orientada a objetos específica llamada LCOM o más bien LCOM4.
Puede volverse bastante matemático y no es a prueba de balas, pero su objetivo debe ser comprender empíricamente y detectar (o mirar con los ojos si lo desea) si una clase es coherente o carece de cohesión.
http://www.aivosto.com/project/help/pm-oo-cohesion.html#LCOM4
https://www.computing.dcu.ie/~renaat/ca421/LCOM.html
Principios de software
Esto va estrechamente relacionado con el "Principio de responsabilidad única" o SRY con el que todos deberíamos estar familiarizados. SRY es uno de los 5 "SÓLIDOS" con los que todos debemos estar familiarizados si queremos ser expertos en la codificación.
A medida que avanzamos a través de los principios SÓLIDOS, también debemos familiarizarnos con los principios "GRASP" , que rigen, o más bien guían cómo codificamos las clases.
Libros adicionales
Por último, también sugeriría lo siguiente:
"Refactorización" de Martin Fowler y Ken Beck sería el próximo libro que leería en esta lista.
"Diseño por contrato, por ejemplo" de Richard Mitchell, Jim McKim y Bertrand Meyer (el último de la fama de Eiffel). Este libro está agotado, pero puede encontrar copias baratas y usadas en Amazon.
Con esto, debe tener una buena idea de cómo comenzar a codificar y diseñar, y con la práctica, mover y dominar (o al menos comprender) la arquitectura de software.
Estoy seguro de que habrá otros profesionales que agregarán, restarán u objetarán estas sugerencias. Llegarán con otras sugerencias, probablemente validadas por su propia experiencia.
Todo lo que puedo decir es esto: no hay atajos.
Todo lo mejor.