Recientemente me gradué de la universidad y comencé a trabajar como programador. No me resulta tan difícil resolver problemas "técnicos" o depurar con cosas que diría que tienen 1 solución.

Pero parece haber una clase de problemas que no tienen una solución obvia: cosas como la arquitectura de software. Estas cosas me confunden y me causan gran angustia.

Paso horas y horas tratando de decidir cómo "diseñar" mis programas y sistemas. Por ejemplo: ¿divido esta lógica en 1 o 2 clases? ¿Cómo nombro las clases? ¿Debería hacer esto privado o público? Etc. Solo quiero crear el programa: maldita sea la arquitectura.

¿Cómo puedo pasar por la fase de arquitectura más rápidamente y pasar a la fase de codificación y depuración que disfruto?

Lo perfecto es enemigo de lo bueno.

Dicho esto, no debes cortar esquinas. El diseño del software tendrá un impacto más duradero y le ahorrará a usted (y a sus pares) toneladas de tiempo y esfuerzo en el futuro. Tardará más en hacerlo bien. La mayor parte del tiempo dedicado a la programación no es martillar en un teclado, sino en una pizarra que descubre cómo resolver un problema.

Pero tampoco debes preocuparte por la perfección. Si dos diseños luchan para llegar a un punto muerto, significa que probablemente tengan la misma bondad. Solo ve con uno. No es que no puedas cambiar las cosas una vez que descubres las fallas en ese diseño.

(Y es de esperar que también ayude una vez que descubra que no hay una sola forma de depurar / resolver problemas técnicos).

Para programas simples y pequeños (por ejemplo, con menos de diez mil líneas de código fuente), puede diseñarlos mientras escribe el código. Si adopta un enfoque de desarrollo iterativo e incremental , tomará decisiones arquitectónicas progresivamente a lo largo del camino: por lo tanto, escriba unas pocas docenas de líneas de código (agregando alguna micro función única), mejórelas hasta que el compilador no devuelva advertencias, pruébelo en su depurador, y repita.

¿Divido esta lógica en 1 o 2 clases? ¿Cómo nombro las clases? ¿Debería hacer esto privado o público? etc.

No deberian. Y no importan demasiado para un programa pequeño (porque los programas pequeños y simples son más fáciles de mejorar, por ejemplo, para cambiar nombres, etc.). Solo necesita ser coherente y priorizar la legibilidad de su código fuente. Puede encontrar la necesidad, de vez en cuando, de refactorizar ligeramente algunas partes pequeñas de su programa (y eso no es gran cosa).

Compare esto con muchos proyectos de software libre (incluso grandes como el kernel de Linux). Los desarrolladores no gastaron un esfuerzo significativo en "arquitectura" en las primeras etapas. UML casi nunca se usa en software libre . Además, aprenderá bastante estudiando el código fuente de varios proyectos de software libre.

Como novato, trabajará en un gran proyecto de software en un equipo, donde simplemente puede confiar en el desarrollador senior (que toma decisiones arquitectónicas), o trabajará solo en proyectos pequeños (generalmente, menos de unas pocas docenas de miles líneas de código fuente). En el último caso, tomará decisiones arquitectónicas incrementales, refactorizando su aplicación de vez en cuando, después de lo cual el "diseño arquitectónico" evolucionará naturalmente.

¿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?

Para proyectos de software pequeños, que requieren menos de un año de trabajo, muy fácilmente: no hagas arquitectura. Dedique quizás media hora a una lluvia de ideas sobre el diseño general. Luego comience a escribir código, con un enfoque de desarrollo iterativo e incremental : escriba algunas docenas de líneas, compílelo (con todas las advertencias e información de depuración habilitada, por ejemplo, g++ -Wall -Wextra -gcon GCC para C ++) hasta que no obtenga advertencias (y páselo en una fuente estática simple) analizador de código, si tiene uno, por ejemplo, clang-analyzer ), pruebe ese código con un depurador , confírmelo a su control de versión (por ejemplo git), enjuague y repita. Sin embargo, asegúrese de evitar la deuda técnica.: cuando algo huele mal, trabaje (refactorizando y reimplementando) para mejorarlo.

Por otro lado, en un entorno de equipo, el trabajo de arquitectura implica la discusión inicial para definir la responsabilidad de cada miembro del equipo. Esa discusión está dirigida por el desarrollador senior (que no es un novato). Lea sobre el desarrollo ágil de software y The Mythical Man-Month .

Solo quiero crear el programa, la arquitectura se condenará.

Excelente intuición (al menos para pequeños proyectos). Así que piense unos minutos sobre su programa y comience a codificarlo con un enfoque de desarrollo iterativo e incremental : codifique unas pocas docenas de líneas y asegúrese de que funcionen bien, luego repita. Antes de eso, estudie el código fuente (y observe la arquitectura) de proyectos similares de software libre y, en general, realice algunos trabajos bibliográficos e investigaciones.

En algunos casos, piense en un enfoque de metaprogramación : hay situaciones en las que le gustaría generar algún "archivo fuente" (los ejemplos incluyen el uso de generadores de analizadores como bison , generadores de código de pegamento como SWIG , protobuf de Google , y a veces es posible que desee escribir un script simple, o use un preprocesador genérico como GPP , para emitir parte de su código C ++ o Java para evitar la codificación repetitiva).

PD. Soy ingeniero de investigación, tengo un doctorado en ciencias de la computación y 40 años de experiencia, y nunca hice "arquitectura" como sugiere su pregunta, mientras trabajé con éxito en varios proyectos medianos y algunos grandes (el compilador GCC en sí mismo ) Para mí, la "arquitectura" es solo la fase de planificación del trabajo de los próximos días o semanas (y generalmente lo hago soñando o durmiendo y sin ninguna computadora, y generalmente sin un lápiz). Además, cuando escribo becas de investigación , de alguna manera y de forma incompleta estoy diseñando una arquitectura.

NB: algunos proyectos de software necesitan mucha más arquitectura que otros. Por ejemplo, si escribe el sistema de control de un corazón artificial o de un robot de neurocirugía, no trabajará de la misma manera que cuando escribe una aplicación promedio de teléfono móvil. Vea también la programación de Enseñarse a sí mismo de Norvig en la página de diez años .

Hay tres lemas que me gusta tener en cuenta.

• "Todo debe hacerse lo más simple posible, pero no más simple"

  Para tomar su ejemplo de "¿una clase o dos?", Preguntaría, "¿cuál es la solución más simple?"

• "Sin errores obvios" versus "Obviamente sin errores"

  ¡Lo último es preferible!

  Y esa es la razón por la que debe ser simple, es decir, para que pueda razonar al respecto. Una gran clase puede ser (o puede llegar a ser) demasiado grande y demasiado complicada para razonar, en cuyo caso la divide en varias clases más pequeñas, donde puede decir "Cada clase es pequeña y hace lo que dice que hará: y sus interfaces son simples, y se combinan de la manera correcta ".

  1. El código debería ejecutarse en teoría (es decir, en su cabeza).
  2. Luego, si no funciona en la práctica, puede depurarlo hasta que la práctica coincida con la teoría.

  Sin embargo, un novato a veces no se molesta con el paso 1, es decir, ejecutarlo en su cabeza (por ejemplo, porque es demasiado complicado), pero en ese caso solo se ejecuta "por accidente" en lugar de "en teoría", posiblemente porque no Lo probé lo suficiente como para encontrar errores no obvios.

• Ley de hiel

  Esto es también conocido como "refactor".

  En la práctica esto significa:

  1. Comience con un sistema simple [ny] que funcione
  2. Ahora es el momento de agregar una nueva característica
  3. Refactorice el sistema existente para que (es decir, hasta) la nueva característica sea fácil de agregar

  4. Agregar la nueva característica

  5. ... y repita como arriba

  Esto coincide con lemas como YAGNI, es decir, no refactorizar (preocuparse por la arquitectura) antes de que lo necesite ... pero cree la arquitectura correcta justo a tiempo, es decir, cuando la necesite para algún propósito específico.

Lo que puede hacer es comenzar con la cantidad mínima de abstracciones que necesita. Por ejemplo, una clase de persona en un archivo. Ahora, a medida que continúa agregando código y características, comienza a ver cosas que deben moverse a una abstracción diferente. Por ejemplo, el principio de responsabilidad única (S de SOLID) le dice que no tenga métodos relacionados con el análisis de direcciones en la clase Persona. Entonces ahora sabe que necesita una clase de Dirección.

Pero siempre es bueno tomarse un tiempo para pensar en el "número mínimo de abstracciones" para su sistema. Comience desde una arquitectura lo suficientemente buena y mejórela a medida que avanza.

editar: @Basile answer da un ejemplo de cómo puede iterar y mejorar su arquitectura mínima.

El tiempo dedicado a pensar en la arquitectura de un sistema no es una pérdida de tiempo.

Creo que su pregunta podría reformularse como "¿cómo puedo ser más eficiente con la toma de decisiones arquitectónicas?".

Mi respuesta breve a eso sería: necesita descubrir los principios básicos que le permitirán tomar decisiones de manera confiable y eficiente y luego debe salir y dar forma a una pieza de software del mundo real. Este será un largo viaje de búsqueda de conocimiento, ensayo y error y desarrollo personal.

-

Y para una respuesta más larga ...

Primero debo aclarar los conceptos: uso la palabra arquitectura para describir la estructura de un sistema de software complejo cuando estoy trabajando con procesos, servicios, API y bases de datos. Utilizo la palabra diseño para describir la estructura de una sola pieza de un sistema más complejo, cuando estoy trabajando con clases, funciones y bibliotecas. Estas son mis definiciones, algunas personas tienen diferentes definiciones. Pero en este contexto, creo que estás hablando de diseño .

Creo que hay 3 cosas importantes a tener en cuenta al discutir este tema:

• la arquitectura y el diseño existen sin que se describan explícitamente a través de diagramas o documentación, también sin que sean mantenidos por un equipo o una persona (un arquitecto ). Cualquier sistema tiene una arquitectura intrínseca y un diseño intrínseco que puede describirse después de los hechos.

• el desarrollo de software no es programación, se está programando con el tiempo. Estoy haciendo esta distinción porque creo que es uno de los puntos ciegos más grandes para las personas que vienen a la industria (incluido yo mismo, en algún momento). Lo que esto significa es que, en comparación con proyectos universitarios o proyectos secundarios personales, trabajar en un sistema de software del mundo real es exponencialmente más complejo, porque cualquier decisión arquitectónica tendrá un gran impacto en el desarrollo del sistema, con el tiempo. Tus decisiones ahora volverán a atormentarte, garantizado.

• porque la arquitectura y el diseño existen de manera intrínseca y porque la base del código es un ser vivo que evoluciona con el tiempo, la arquitectura y el diseño también necesitan evolucionar. Evolucionarán de manera controlada a través de decisiones conscientes tomadas en el momento central, o evolucionarán caóticamente, impulsados ​​por la codificación. Esto es crucial de entender, porque significa que el enfoque tradicional de "arquitecto primero y escribir código segundo" es defectuoso. Por supuesto, cuando se inicia un proyecto desde cero, es necesario realizar algunos trabajos de arquitectura y diseño por adelantado. Pero aparte de eso, habrá muchas decisiones arquitectónicas y de diseño aún por tomar durante el desarrollo del sistema.

Para resumir lo anterior, es muy importante tener en cuenta el hecho de que tomará decisiones de diseño mientras escribe código, ya sea conscientemente o no. Debe esforzarse por tomar la mayor parte de esas decisiones de manera consciente y crítica, ya que cualquier decisión tomada a la ligera puede tener un gran impacto en el trabajo futuro (este impacto generalmente se manifiesta en la base del código que se vuelve muy difícil de cambiar para corregir errores o implementar funciones). Robert C. Martin ilustra esto maravillosamente, con datos, en su libro "Arquitectura limpia" (que recomiendo por cierto).

Entonces, ahora que sabemos por qué la arquitectura y el diseño son importantes, ¿cuáles son los principios básicos que nos pueden dar un marco adecuado para una buena toma de decisiones? Tuve esta pregunta al principio de mi carrera, sentí que faltaba algo en mi conjunto de herramientas, pero no sabía qué, no sabía cómo describirla o buscarla. Compartiré algunos de estos principios que descubrí con el tiempo y espero que te hagan la vida un poco más fácil:

• Un conjunto de trucos de codificación muy simples pero poderosos se puede obtener leyendo el libro de Martin Fowler "Refactorización: Mejorando el diseño del código existente". Hay demasiados para enumerar aquí, pero estas son decisiones de tiempo de codificación de muy bajo nivel que puede tomar para mejorar enormemente la estructura de su código y ayudarlo a tomar las decisiones de diseño. El libro también es un buen caso para integrar pruebas unitarias en su flujo de trabajo personal y cómo escribir código comprobable.

• específicamente para OOP, debe mirar los principios SÓLIDOS . Al principio son un poco abstractos y difíciles de entender, pero muy poderosos. Le sugiero que comience con los primeros 2 para obtener el mayor beneficio rápidamente:

Principio de responsabilidad única : una clase debería tener una sola responsabilidad (es decir, solo los cambios en una parte de la especificación del software deberían poder afectar la especificación de la clase).

Principio abierto / cerrado : "las entidades de software ... deben estar abiertas para la extensión, pero cerradas para la modificación".

• El concepto de composición sobre la herencia

  El principio de que las clases deben lograr un comportamiento polimórfico y la reutilización del código por su composición (al contener instancias de otras clases que implementan la funcionalidad deseada) en lugar de la herencia de una clase base o primaria.

• los conceptos de acoplamiento ("el grado de interdependencia entre los módulos de software") y la cohesión ("el grado en que los elementos dentro de un módulo pertenecen juntos")
• el concepto SECO (no te repitas)
• el concepto de separación de comando / consulta ("cada método debe ser un comando que realiza una acción o una consulta que devuelve datos al llamante, pero no ambos")
• El concepto de sistema con estado versus sistema sin estado (mi regla general es: evitar el manejo del estado; construir sistemas sin estado tanto como sea posible).

Por supuesto, estos son solo conceptos, no reglas. El primer paso es comprenderlos y ser conscientes de ellos. Luego viene usarlos en la práctica y construir experiencia sobre cuándo debe seguirlos y cuándo no. Y luego hay un proceso continuo para refinar su comprensión de estos conceptos, sus lados negativos y sus complejas interacciones entre ellos.

Creo que el consejo más valioso que puedo darte es: ten paciencia contigo mismo. Acabas de comenzar por un camino largo pero satisfactorio. Sigue practicando y experimentando, toma nota de lo que funciona y lo que no funciona y solo mejorarás con el tiempo.

La mayor parte de lo que describe no es realmente una arquitectura (importante): una buena denominación y un buen diseño de clase es algo que debería ser una segunda naturaleza para usted. Esto simplemente mejorará cuanto más codifique. Lo más útil para tales inquietudes es generalmente la programación de pares: ayuda a aclarar tales problemas y le ayuda a aprender cómo hacerlo de manera eficiente.

Donde la arquitectura es necesaria ANTES del proyecto:

1. Reúna los requisitos exactos y los requisitos no funcionales (¿cuántas solicitudes / segundo necesito admitir?). Cualquier falta de coincidencia en esta fase conducirá a un infierno de codificación: la integración de ideas perdidas después del hecho lleva mucho tiempo, es molesto y a veces imposible. Sé que esto no es divertido como codificación, pero intentar que el código haga algo para lo que no fue diseñado es aún menos divertido.

2. Si es apropiado, defina los contextos limitados de su sistema y asegúrese de tener su vocabulario correcto, por ejemplo, si la empresa habla de "Frobbels", asegúrese de nombrar clases / interfaces, etc. con "*** Frobbels". Suena trivial, pero si habla de flujos de trabajo, mientras que el negocio habla de operaciones, la traducción se vuelve muy molesta.

3. Si trabaja con varias personas / equipos, describa sus interfaces con anticipación y asegúrese de que todos los supuestos y problemas sean entendidos por todos; si no tiene un contexto compartido, la integración será "divertida". Por ejemplo, construyes un generador de imágenes de banana, pero tu frontend-dev necesita un generador de imágenes de manzana. O construyes algo que puede responder 100 solicitudes / segundo, pero se necesitan 10000 r / seg.

Nota: esto está muy influenciado por mi trabajo en una arquitectura de microservicio. La forma en que los servicios se construyen internamente, PUEDE ser diseñada también, pero la mayoría de las veces es mucho menos importante que tener una idea general correcta.

No voy a lanzar un montón de términos y abreviaturas (la mayoría de los codificadores / ingenieros de software apenas acuerdan la mayoría). En cambio, considere lo siguiente:

1. Estás aprendiendo, no estás perdiendo el tiempo, estás probando diferentes enfoques y aprendiendo lo que funciona. Puede hacerlo sin planificar mucho con anticipación, sumergiéndose en un problema con la primera solución que se le ocurra y cambiándolo si no funciona. Si funciona bien, ¡genial! Has encontrado una solución simple a un problema. Las soluciones simples están bien si funcionan bien, y algunas veces son lo suficientemente buenas .

2. Todo es una compensación: puede diseñar el mismo sistema de muchas maneras diferentes, intercambiando tiempo y espacio, complejidad y flexibilidad, abstracción y legibilidad, o cualquiera de las muchas compensaciones posibles. Ninguna solución es perfecta en todos los sentidos y ninguna regla es sin excepciones en ingeniería de software. Quien te diga lo contrario es ingenuo o vende algo.

3. Como recién graduado, la codificación y la depuración pueden ser muy emocionantes, pero esto desaparecerá con el tiempo, y las habilidades que estás aprendiendo ahora te serán útiles cuando lo hagas.

4. Yo diría que construir software es más arte / artesanía que ingeniería. El gran arte no se trata solo de la pincelada individual, sino más bien de decisiones de alto nivel y compensaciones hechas por el artista / artesano.

Trataré de responder esta pregunta desde el punto de vista del desarrollo web (es decir, desde un campo donde la gente se angustia mucho por la arquitectura). Comenzaré explicando por qué las personas se preocupan por la arquitectura y luego describiré formas de superar la parte de la arquitectura más rápidamente.

La arquitectura hace dos cosas para su código:

1. Facilita la comprensión de su código para usted y para los demás.
2. Ayuda a estructurar su código de una manera que facilita su extensión e integración.

Un estilo de código facilita la lectura de una parte específica del código, al proporcionarle convenciones que puede reconocer y usar para navegar a través de él. Del mismo modo, una buena arquitectura lo ayuda a identificar dónde realmente encontrará el código que maneja una característica específica. Por ejemplo, en la mayoría de los proyectos web, la arquitectura se relaciona estrechamente con cómo se ordenan las carpetas y los archivos. Por otro lado, una buena arquitectura realmente debería ayudarlo a pensar menos sobre el código, porque ya debe tener un lugar intuitivo al que pertenece cualquier parte del código.

Además, una buena arquitectura proporciona una forma abreviada para evitar muchos de los escollos que podrían evitar que su código se use fácilmente. Nuevamente, si toma una decisión de arquitectura, debería establecer una convención que lo ayude a pensar menos sobre cómo escribir código.

Ahora la parte para la que realmente estás aquí:

¿Qué puede hacer para atravesar la parte de arquitectura más rápidamente?

1. No lo hagas

Como muchas respuestas ya han señalado. Primero pregúntese si realmente necesita arquitectura. Si no tiene mucho código (y puede estar razonablemente seguro de que el proyecto no crecerá en el futuro cercano), puede saltear la parte de arquitectura y crear algo que simplemente funcione. SIN EMBARGO, si estás al principio de tu carrera, aprovecharía la oportunidad de practicar siempre que puedas. En algún momento harás proyectos más grandes, y en ese punto probablemente sea demasiado tarde para aprender.

Con eso fuera del camino, ¿qué puedes hacer para que la arquitectura sea menos dolorosa?

1. Hazlo temprano
2. Robar
3. Aprende / Cíñalo
4. No te excedas

Decidir sobre una arquitectura debería ser una parte temprana del proceso de planificación. Tan pronto como tenga una idea de qué tipo de aplicación / programa / sitio web va a crear, debe pensar qué tipo de arquitectura respaldaría esto.

En este punto es hora de robar descaradamente. Existe mucha literatura sobre cómo configurar adecuadamente una arquitectura de programa, y ​​una cantidad asombrosa de casos de uso está cubierta por estos prototipos de arquitectura existentes. Debería obtener una visión general de qué tipo de arquitecturas existen, incluso si no sabe cómo implementarlas.

Si se ha decidido por un tipo de arquitectura, entonces quédese con ella. En su mayor parte, la decisión de la arquitectura debe ser intuitiva y solo tomar unos segundos después de la configuración inicial. Mucho de esto se reduce a la experiencia.

Por último, no pienses demasiado. Usted da el ejemplo de si algo debe ser público o privado, y la verdad es que probablemente no importa si hace público todo. Sí, no debe hacerlo de esta manera, y para muchos de estos pequeños errores se acumularán después de un tiempo, pero al final del día probablemente tampoco matará su proyecto. En primer lugar, crear software de trabajo!

(PD: Esa última oración no es excusa para ser flojo. Priorizar el software de trabajo no significa que no tendrá que aprender un buen código algún día).

La respuesta es muy simple.

• Crear un prototipo (Tiempo en caja)
• Refactorizar (dedica todo el tiempo que quieras o tengas en función de una amplia gama de factores)

Cuando esté creando un prototipo, el enfoque debe estar en el Producto Mínimo Viable, y cuando está refactorizando, el enfoque debe estar en hacer que su proyecto o solución sea escalable.

¿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?

Al relegar esta tarea a (o pedir ayuda a) sus compañeros de trabajo más experimentados.

Simplemente carece de la experiencia necesaria para tomar rápidamente tales decisiones. Uni te dio una buena base teórica, pero solo te lleva a una línea de partida. No hay otra manera de juzgar una arquitectura dada en una situación dada que saber cómo se comportaron arquitecturas similares en situaciones similares en el pasado.

Trabajar con personas que son mejores en el trabajo que usted es la forma más rápida de aprender cosas. Si no tiene a nadie mayor a quien recurrir, necesita un mejor trabajo. "Mejor" como en "satisfacer mejor sus necesidades". La necesidad de conocimiento y experiencia es su necesidad más extrema en este momento, como lo demuestra su dilema. ¿Te gusta la fase de codificación y depuración? Suena como un junior perfecto. Pero un junior necesita la orientación del senior. Ese es el punto de esas descripciones de trabajo. Los extraños en Internet solo pueden ayudarlo hasta ahora, necesita un mentor.

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

1. codificación (cómo codificar sus clases, módulos o qué no, convenciones de nomenclatura, visibilidad de acceso, alcance, etc.),

2. 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,

3. 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.

Hay mucha información aquí y, francamente, TL; DR. Creo que hay una cosa importante que las personas se equivocan cuando intentan aprender a diseñar un sistema: intentan pensarlo en el orden en que se realizará el trabajo. En cambio, necesitas trabajar al revés. Es decir, el objetivo principal del diseño / arquitectura es determinar cuál debería ser el resultado final.

Como analogía, considere la arquitectura de un hogar. Un arquitecto no comienza a hacerse preguntas como: "¿cuántas ventanas debería tener esta casa?", "¿Dónde debería colocarse el primer ladrillo?". Esos detalles de implementación no son el diseño, se derivan del diseño. El archivo comienza con una visión, tal vez un bosquejo de cómo se vería la casa terminada. ¿Es una casa unifamiliar, un dúplex? ¿Es una casa de lujo o una casa fácilmente accesible? Del mismo modo, si las variables son privadas y si divide una clase tiene muy poco que ver con la arquitectura.

Comience primero descubriendo cuáles son los objetivos de su diseño. Por ejemplo, ¿es esta una solución única? ¿Se ampliará, revisará y mantendrá durante décadas? La respuesta a eso indicará diseños muy diferentes y ese es el punto de la arquitectura. Una vez que haya descubierto lo que necesita hacer, los detalles del diseño siguen naturalmente. No es que estos detalles sean obvios o fáciles, pero es el plan de alto nivel en el que se basan estas opciones.

Cómo juzgar cuánto tiempo debe dedicar a la arquitectura de cualquier pieza de software antes de obtener un bucle de prueba de compilación de escritura de algún tipo es bastante sencillo: suficiente información para caber en su cabeza, y nada más que eso. A menos que el proyecto en el que esté trabajando requiera una metodología más estricta. En cuyo caso, como principiante, probablemente debería leer un documento de arquitectura, no escribirlo.

En cuanto a nombrar cosas, para mí eso es parte de "escribir", pero sin duda es una parte muy importante de la programación: no dudes en pensar mucho sobre cómo nombras las cosas, y pensar con más fuerza cuanto mayor sea el alcance del nombre.

Encontrar los nombres correctos, la arquitectura correcta, la modularidad correcta y las abstracciones correctas es parte de la experiencia que obtendrá al cometer errores. A lo largo de los años, he escrito un programa que hace lo mismo unas cinco veces y el código fue muy diferente cada vez porque cada iteración pasada me dio pistas sobre un mejor diseño.