Eu me formei recentemente na universidade e comecei a trabalhar como programador. Não acho difícil resolver problemas "técnicos" ou depurar com coisas que eu diria que têm 1 solução.

Mas parece haver uma classe de problemas que não têm uma solução óbvia - coisas como arquitetura de software. Essas coisas me incomodam e me causam grande angústia.

Passo horas e horas tentando decidir como "arquitetar" meus programas e sistemas. Por exemplo - divido essa lógica em 1 ou 2 classes, como nomeio as classes, devo tornar isso privado ou público, etc. Esses tipos de perguntas ocupam muito do meu tempo e isso me frustra bastante. Eu só quero criar o programa - que se dane a arquitetura.

Como posso passar pela fase de arquitetura mais rapidamente e entrar na fase de codificação e depuração de que gosto?

Perfeito é o inimigo do bem.

Dito isto, você não deve cortar custos. O design do software terá um impacto mais duradouro e economizará (e seus colegas) toneladas de tempo e esforço no futuro. Levará mais tempo para acertar. A maior parte do tempo gasto em programação não está martelando em um teclado, mas em um quadro branco descobrindo como resolver um problema.

Mas você também não deve se preocupar com a perfeição. Se dois projetos lutam contra um impasse, isso significa que eles provavelmente têm a mesma bondade. Apenas vá com um. Não é como se você não pudesse mudar as coisas depois de descobrir as falhas desse design.

(E espero que também ajude assim que você descobrir que não há apenas uma maneira de depurar / resolver problemas técnicos.)

Para programas simples e pequenos (por exemplo, com menos de dez mil linhas de código fonte), você pode arquitetá-los enquanto escreve o código. Se você adotar uma abordagem de desenvolvimento iterativa e incremental , tomará decisões de arquitetura progressivamente ao longo do caminho: portanto, escreva algumas dezenas de linhas de código (adicionando um único micro recurso), aprimore-as até que nenhum aviso retorne do seu compilador, teste-o em seu depurador e repita.

divido essa lógica em 1 ou 2 classes, como nomeio as classes, devo tornar isso privado ou público, etc. Esses tipos de perguntas ocupam muito do meu tempo

Eles não deveriam. E eles não importam muito para um programa pequeno (porque programas pequenos e simples são mais fáceis de melhorar, por exemplo, alterar nomes, etc ...). Você só precisa ser consistente e priorizar a legibilidade do seu código-fonte. De tempos em tempos, talvez seja necessário refatorar algumas pequenas partes do seu programa (e isso não é grande coisa).

Compare isso com muitos projetos de software livre (mesmo grandes como o kernel do Linux). Os desenvolvedores não gastaram esforços significativos na "arquitetura" nos estágios iniciais. UML quase nunca é usado em software livre . Além disso, você aprenderá bastante estudando o código fonte de vários projetos de software livre.

Como novato, você trabalha em um grande projeto de software em uma equipe, onde pode simplesmente confiar no desenvolvedor sênior (que toma decisões de arquitetura) ou trabalha sozinho em pequenos projetos (normalmente, menos de algumas dezenas de milhares). linhas de código fonte). Neste último caso, você tomará decisões arquiteturais incrementais, refatorando seu aplicativo de tempos em tempos, após o qual o "design arquitetônico" evoluirá naturalmente.

Como posso passar mais rapidamente a fase de arquitetura e entrar na fase de codificação e depuração, da qual gosto?

Para pequenos projetos de software, que exigem menos de um ano de trabalho, com muita facilidade: não faça arquitetura. Passe talvez meia hora fazendo um brainstorming sobre o design geral. Em seguida, comece a escrever o código, com uma abordagem de desenvolvimento iterativa e incremental : escreva algumas dezenas de linhas, compile-o (com todos os avisos e informações de depuração ativados, por exemplo, g++ -Wall -Wextra -gcom o GCC for C ++) até você não receber nenhum aviso (e transmiti-lo em alguma fonte estática simples analisador de código, se você tiver um, por exemplo , analisador de clang ), teste esse código com um depurador , comprometa-o com o controle de versão (por exemplo git), enxágue e repita. No entanto, certifique-se de evitar dívidas técnicas: quando algo cheira mal, trabalhe (refatorando e reimplementando) para melhorá-lo.

Por outro lado, em um ambiente de equipe, o trabalho de arquitetura envolve a discussão inicial para definir a responsabilidade de cada membro da equipe. Essa discussão é liderada pelo desenvolvedor sênior (que não é um novato). Leia sobre desenvolvimento ágil de software e The Mythical Man-Month .

Eu só quero criar o programa, a arquitetura seja danificada.

Excelente intuição (pelo menos para pequenos projetos). Portanto, pense alguns minutos sobre seu programa e comece a codificá-lo com uma abordagem de desenvolvimento iterativa e incremental : codifique algumas dezenas de linhas e verifique se elas funcionam bem e repita. Antes disso, estude o código-fonte (e observe a arquitetura) de projetos similares de software livre e, geralmente, faça algum trabalho e pesquisa bibliográfica.

Em alguns casos, pense em uma abordagem de metaprogramação : há situações em que você gostaria de gerar algum "arquivo de origem" (exemplos incluem o uso de geradores de analisador como bison , geradores de código de cola como SWIG , Google protobuf e, às vezes, você pode escrever um script simples - ou use um pré-processador genérico como GPP - para emitir parte do seu código C ++ ou Java para evitar a codificação repetitiva).

PS. Sou engenheiro de pesquisa, tenho doutorado em ciência da computação e 40 anos de experiência e nunca fiz "arquitetura" como a sua pergunta sugere, apesar de ter trabalhado com sucesso em vários projetos de médio porte e alguns grandes (o próprio compilador GCC ) Para mim, "arquitetura" é apenas a fase de planejamento do trabalho dos próximos dias ou semanas (e costumo fazer isso enquanto sonho ou durmo e certamente sem computador, e geralmente sem lápis). Além disso, ao escrever bolsas de pesquisa , estou de alguma forma e incompletamente projetando uma arquitetura.

Nota: alguns projetos de software precisam de muito mais arquitetura do que outros. Por exemplo, se você escrever o sistema de controle de um coração artificial ou de um robô de neurocirurgia, não funcionará da mesma maneira que ao escrever um aplicativo comum para celular. Veja também a página de Norvig Teach a programar em dez anos .

Gostaria de ter em mente três lemas.

• "Tudo deve ser feito o mais simples possível, mas não mais simples"

  Para dar o seu exemplo de "uma aula ou duas?", Eu perguntaria: "qual é a solução mais simples?"

• "Sem erros óbvios" versus "Obviamente sem erros"

  O último é preferível!

  E é por isso que precisa ser simples, ou seja, para que você possa argumentar sobre isso. Uma classe grande pode ser (ou pode se tornar) muito grande e muito complicada para se raciocinar; nesse caso, você a divide em várias classes menores, onde você pode dizer "Cada classe é pequena e faz o que diz que fará - e suas interfaces são simples e combinam da maneira certa ".

  1. O código deve ser executado na teoria (ou seja, na sua cabeça).
  2. Então, se não funcionar na prática, você poderá depurá-lo até que a prática corresponda à teoria.

  Às vezes, um iniciante não se incomoda com o passo 1, ou seja, executá-lo em sua cabeça (por exemplo, porque é muito complicado) - mas, nesse caso, está executando apenas "por acidente" e não "em teoria", possivelmente porque você não testou o suficiente para encontrar erros não óbvios.

• Lei de Gall

  Isso é conhecido como "refator".

  Na prática, isso significa:

  1. Comece com um [ny] sistema simples que funciona
  2. Agora é hora de adicionar um novo recurso
  3. Refatorar o sistema existente para que (ou seja, até) o novo recurso seja fácil de adicionar

  4. Adicione o novo recurso

  5. ... e repita como acima

  Isso corresponde a lemas como YAGNI, ou seja, não refatorar (se preocupe com a arquitetura) antes que você precise ... mas crie a arquitetura certa na hora certa, ou seja, quando você precisar para algum propósito específico.

O que você pode fazer é começar com o número mínimo de abstrações necessárias. Por exemplo, uma classe Person em um arquivo. Agora, ao continuar adicionando código e recursos, você começa a ver coisas que precisam ser movidas para uma abstração diferente. Por exemplo, o princípio de responsabilidade única (S do SOLID) diz para você não ter métodos relacionados à análise de endereço na classe Person. Então agora você sabe que precisa de uma classe Address.

Mas é sempre bom levar algum tempo para pensar sobre como é o "número mínimo de abstrações" para o seu sistema. Comece com uma arquitetura suficientemente boa e melhore-a à medida que avança.

edit: a resposta @Basile fornece um exemplo de como você pode iterar e melhorar sua arquitetura mínima.

O tempo gasto pensando na arquitetura de um sistema não é desperdiçado.

Acredito que sua pergunta possa ser reformulada como "como posso ser mais eficiente na tomada de decisões de arquitetura?".

Minha resposta curta seria: você precisa descobrir os princípios básicos que permitirão tomar decisões de maneira confiável e eficiente e, em seguida, precisa realmente criar um software do mundo real. Será uma longa jornada de busca de conhecimento, tentativa e erro e desenvolvimento pessoal.

-

E para uma resposta mais longa ...

Devo primeiro esclarecer os conceitos: uso a palavra arquitetura para descrever a estrutura de um sistema de software complexo quando trabalho com processos, serviços, APIs e bancos de dados. Uso a palavra design para descrever a estrutura de apenas uma parte de um sistema mais complexo, quando trabalho com classes, funções e bibliotecas. Estas são minhas definições, algumas pessoas têm definições diferentes. Mas neste contexto, acredito que você está falando sobre design .

Eu acho que há três coisas importantes a serem lembradas ao discutir este tópico:

• arquitetura e design existem sem que sejam descritos explicitamente por diagramas ou documentação, também sem que sejam mantidos por uma equipe ou pessoa (um arquiteto ). Qualquer sistema possui uma arquitetura intrínseca e um design intrínseco que pode ser descrito após o fato.

• desenvolvimento de software não é programação, é programação ao longo do tempo. Estou fazendo essa distinção porque acho que é um dos maiores pontos cegos para as pessoas que estão no setor (inclusive eu, em um momento). O que isso significa é que, comparado a projetos universitários ou projetos pessoais, trabalhar em um sistema de software do mundo real é exponencialmente mais complexo, porque qualquer decisão de arquitetura terá um grande impacto no desenvolvimento do sistema com o tempo. Suas decisões agora voltarão para assombrá-lo, garantido.

• como a arquitetura e o design existem instrinsicamente e porque a base de código é uma coisa viva que evolui com o tempo, a arquitetura e o design também precisam evoluir. Eles evoluirão de maneira controlada por meio de decisões conscientes tomadas no momento correto ou evoluirão caoticamente, impulsionados pela codificação. Isso é crucial para entender, porque significa que a abordagem tradicional do "arquiteto primeiro e escrever o segundo do código" é falha. Obviamente, ao iniciar um projeto do zero, é necessário realizar alguns trabalhos de arquitetura e design com antecedência. Mas, além disso, ainda haverá muitas decisões de arquitetura e design a serem tomadas durante o desenvolvimento do sistema.

Para destilar ainda mais o exposto, é muito importante estar ciente do fato de que você tomará decisões de design enquanto estiver escrevendo código, consciente ou não. Você deve se esforçar para tomar tantas dessas decisões de maneira consciente e crítica, pois qualquer decisão tomada de ânimo leve pode ter um grande impacto em trabalhos futuros (esse impacto geralmente se manifesta na base de código, tornando-se muito difícil mudar para corrigir bugs ou implementar recursos). Robert C. Martin ilustra isso lindamente, com dados, em seu livro "Arquitetura Limpa" (que eu recomendo a propósito).

Então, agora que sabemos por que a arquitetura e o design são importantes, quais são os princípios fundamentais que podem nos fornecer uma estrutura adequada para uma boa tomada de decisão? Eu tive essa pergunta no início da minha carreira, senti que havia algo faltando no meu conjunto de ferramentas, mas não sabia o que, não sabia como descrevê-la ou procurar por ela. Compartilharei alguns desses princípios que descobri com o tempo e espero que eles facilitem sua vida um pouco:

• um conjunto de truques de codificação muito simples, porém poderosos, pode ser lido lendo o livro de Martin Fowler "Refatoração: melhorando o design do código existente". Há muitos para listar aqui, mas essas são decisões de tempo de codificação de nível muito baixo que você pode tomar para melhorar bastante sua estrutura de código e ajudá-lo a tomar as decisões de design. O livro também é um bom argumento para integrar o teste de unidade ao seu fluxo de trabalho pessoal e como escrever código testável.

• especificamente para OOP, você deve observar os princípios do SOLID . Eles são um pouco abstratos e difíceis de entender em primeiro lugar, mas muito poderosos. Sugiro que você comece com os dois primeiros para obter o máximo benefício rapidamente:

Princípio de responsabilidade única : uma classe deve ter apenas uma única responsabilidade (ou seja, apenas alterações em uma parte da especificação do software devem poder afetar a especificação da classe).

Princípio aberto / fechado : "entidades de software ... devem estar abertas para extensão, mas fechadas para modificação".

• o conceito de composição sobre herança

  o princípio de que as classes devem obter comportamento polimórfico e reutilização de código por sua composição (contendo instâncias de outras classes que implementam a funcionalidade desejada) em vez de herança de uma classe base ou pai.

• os conceitos de acoplamento ("o grau de interdependência entre os módulos de software") e coesão ("o grau em que os elementos dentro de um módulo pertencem").
• o conceito DRY (não se repita)
• o conceito de separação de comando / consulta ("todo método deve ser um comando que executa uma ação ou uma consulta que retorna dados ao chamador, mas não ambos")
• o conceito de sistema com estado ou sem estado (minha regra geral é: evitar lidar com o estado; criar sistemas sem estado o máximo possível).

Claro, estes são apenas conceitos, não regras. O primeiro passo é entendê-los e estar ciente deles. Em seguida, vem realmente usá-los na prática e desenvolver experiência sobre quando você deve segui-los e quando não deve. E há um processo contínuo de refinar sua compreensão desses conceitos, seus lados negativos e suas complexas interações entre si.

Acho que o conselho mais valioso que posso lhe dar é: tenha paciência consigo mesmo. Você acabou de começar um caminho longo, mas gratificante. Continue praticando e experimentando, tome nota do que funciona e do que não funciona e você só ficará melhor com o tempo.

A maior parte do que você descreve não é realmente arquitetura (importante) - boa nomeação e bom design de classe é algo que deve ser uma segunda natureza para você. Isso simplesmente melhorará quanto mais você codificar. O mais útil para essas preocupações é geralmente a programação em pares - ajuda a esclarecer esses problemas e a aprender a fazer isso com eficiência.

Onde a arquitetura é necessária, ANTES do projeto:

1. Reúna os requisitos exatos e os requisitos não funcionais (quantas solicitações / segundo eu preciso dar suporte?). Qualquer falha nesta fase levará à codificação do inferno - integração de idéias perdidas depois que o fato é demorado, irritante e às vezes impossível. Eu sei que isso não é divertido como codificação, mas tentar obter o código para fazer algo para o qual não foi projetado é ainda menos divertido.

2. Se apropriado, defina os contextos limitados do seu sistema e verifique se o seu vocabulário está correto, por exemplo, se a empresa falar sobre "Frobbels", certifique-se de nomear classes / interfaces etc. com "*** Frobbels". Parece trivial, mas se você fala sobre fluxos de trabalho, enquanto a empresa fala sobre operações, a tradução fica irritante muito rápido.

3. Se você trabalha com várias pessoas / equipes, descreve suas interfaces com antecedência e garante que todas as suposições e problemas sejam entendidos por todos - se você não tiver um contexto compartilhado, a integração será "divertida". Por exemplo, você constrói um gerador de imagens de banana, mas o seu frontend-dev precisa de um gerador de imagens da apple. Ou você cria algo que pode atender 100 solicitações / segundo, mas são necessários 10000 r / s.

Nota: isso é fortemente influenciado pelo meu trabalho em uma arquitetura de microsserviço. Como os saques são criados internamente, PODE ser arquitetado também - mas na maioria das vezes é muito menos importante do que acertar o quadro geral.

Não vou apresentar muitos termos e abreviações para você (a maioria dos quais dificilmente é aceita pela maioria dos codificadores / engenheiros de software). Em vez disso, considere o seguinte:

1. Você está aprendendo - não está perdendo tempo, está tentando diferentes abordagens e aprendendo o que funciona. Você pode fazer isso sem planejar muito, mergulhando em um problema com a primeira solução que lhe vem à cabeça e alterando-o se ou quando não funcionar. Se funcionar bem, ótimo! Você encontrou uma solução simples para um problema. Soluções simples são boas se funcionam bem e, às vezes, são boas o suficiente .

2. Tudo é uma troca - você pode projetar o mesmo sistema de muitas maneiras diferentes, trocando tempo e espaço, complexidade e flexibilidade, abstração e legibilidade, ou qualquer uma das muitas trocas possíveis. Nenhuma solução é perfeita em todos os aspectos e nenhuma regra é sem exceções na engenharia de software. Quem diz o contrário, é ingênuo ou vende alguma coisa.

3. Recém-formado, a codificação e a depuração podem ser muito empolgantes, mas isso desaparece com o tempo e as habilidades que você está aprendendo agora o ajudarão muito bem.

4. Eu argumentaria que a construção de software é mais arte / artesanato do que engenharia. A grande arte não se refere apenas às pinceladas individuais, mas às decisões e trocas de alto nível feitas pelo artista / artesão.

Tentarei responder a essa pergunta do ponto de vista do desenvolvimento da Web (ou seja: proveniente de um campo em que as pessoas sofrem muito com a arquitetura). Começarei explicando por que as pessoas se preocupam com a arquitetura e, em seguida, descrevemos maneiras de superar a parte da arquitetura mais rapidamente.

A arquitetura faz duas coisas no seu código:

1. Isso facilita a compreensão do seu código para você e outras pessoas.
2. Isso ajuda a estruturar seu código de maneira a facilitar a extensão e a integração.

Um estilo de código facilita a leitura de uma parte específica do código, fornecendo convenções que você pode reconhecer e usar para navegar nele. Da mesma forma, uma boa arquitetura ajuda a identificar onde você realmente encontrará o código que lida com um recurso específico. Por exemplo, na maioria dos projetos da Web, a arquitetura está intimamente relacionada à forma como as pastas e os arquivos são classificados. Por outro lado, uma boa arquitetura deve realmente ajudá-lo a pensar menos sobre o código, porque já deve ter um local intuitivo ao qual pertence qualquer parte do código.

Além disso, uma boa arquitetura fornece um atalho para evitar muitas armadilhas que poderiam impedir o uso fácil do seu código. Novamente, se você tomar uma decisão de arquitetura, deve configurar uma convenção que o ajude a pensar menos em como escrever código.

Agora, a parte para a qual você está realmente aqui:

O que você pode fazer com a parte da arquitetura mais rapidamente:

1. Não faça

Como muitas respostas já foram apontadas. Primeiro pergunte a si mesmo se você realmente precisa de arquitetura. Se você não tiver muito código (e tiver certeza razoável de que o projeto não crescerá no futuro próximo), basta pular a parte da arquitetura e juntar algo que simplesmente funcione. No entanto, se você está no início de sua carreira, eu usaria a oportunidade para praticar sempre que puder. Em algum momento, você estará fazendo projetos maiores e, nesse momento, provavelmente é tarde para aprender.

Com isso fora do caminho, o que você pode fazer para tornar a arquitetura menos dolorosa:

1. Faça cedo
2. Roubar
3. Aprender / cumpri-lo
4. Não exagere

A decisão de uma arquitetura deve ser uma parte inicial do processo de planejamento. Assim que tiver uma idéia de que tipo de aplicativo / programa / site você criará, pense em que tipo de arquitetura suportaria isso.

Neste ponto, é hora de roubar descaradamente. Há muita literatura disponível sobre como configurar corretamente uma arquitetura de programa, e uma quantidade impressionante de casos de uso é coberta por esses protótipos de arquitetura existentes. Você deve aprender uma visão geral aproximada de que tipo de arquitetura existe, mesmo que não saiba como implementá-las.

Se você optou por um tipo de arquitetura, siga-o. Na maioria das vezes, a decisão da arquitetura deve ser intuitiva e levar apenas alguns segundos após a configuração inicial. Muito disso se resume à experiência.

Por fim, não pense demais nas coisas. Você dá o exemplo de se algo deve ser público ou privado, e a verdade é que provavelmente não importa se você tornar tudo público. Sim, você não deve fazê-lo dessa maneira, e muitos desses pequenos erros se acumularão após um tempo, mas no final do dia, provavelmente também não matará seu projeto. Antes de mais, crie um software funcional!

(PS: Essa última frase não é desculpa para ser preguiçoso. Priorizar o software em funcionamento não significa que você não precisará aprender uma boa codificação algum dia.)

A resposta é muito simples,

• Criar um protótipo (Time in box)
• Refatorar (gaste o tempo que quiser ou com base em uma ampla variedade de fatores)

Quando você está criando um protótipo, o foco deve estar no Produto Mínimo Viável e, ao refatorar, o foco deve estar em tornar seu projeto ou solução escalável.

Como posso passar mais rapidamente a fase de arquitetura e entrar na fase de codificação e depuração, da qual gosto?

Relegando esta tarefa (ou pedindo ajuda) a seus colegas de trabalho mais experientes.

Você simplesmente não tem a experiência necessária para tomar rapidamente essas decisões. A Uni deu a você uma boa base teórica, mas isso apenas o leva a uma linha de partida. Não há outra maneira de julgar uma determinada arquitetura em uma determinada situação, além de saber como arquiteturas semelhantes haviam se comportado em situações semelhantes no passado.

Trabalhar com pessoas melhores no trabalho do que você é a maneira mais rápida de aprender. Se você não tem ninguém sênior para quem recorrer, precisa de um emprego melhor. "Melhor" como em "atender melhor às suas necessidades". A necessidade de conhecimento e experiência é sua necessidade mais extrema neste momento, conforme comprovado pelo seu dilema. Você gosta da fase de codificação e depuração? Soa como um júnior perfeito. Mas um júnior precisa da orientação do idoso. Esse é o objetivo dessas descrições de cargo. Estranhos na internet só podem ajudá-lo até agora, você precisa de um mentor.

Eu vejo alguns problemas sérios com esta pergunta. Vamos começar.

Como parar de perder tempo projetando arquitetura

Esta questão é bastante carregada. Além disso, você não cria arquitetura. Você arquiteta . Arquitetura e design são atividades complementares e relacionadas, mas não são as mesmas, mesmo que possam se sobrepor.

Da mesma forma, da mesma maneira que é possível perder tempo fazendo arquitetura (arquitetando demais), você também pode perder tempo projetando e codificando demais (codificando coisas de uma maneira muito mais complexa do que o necessário ou falhando em código para as coisas necessárias.)

A arquitetura adequada visa evitar esse desperdício na codificação. Isso é feito limitando, restringindo e documentando as maneiras possíveis de um sistema complexo ser 1) projetado, 2) codificado e testado, 3) entregue, 4) mantido, 5) recuperar-se de falhas e 6) finalmente desativado.

Minha experiência foi que as pessoas que apenas gostam de codificar, simplesmente codificam sem pensar em como um sistema deve operar e manter a longo prazo, passando para a próxima batata quente, deixando uma alma pobre para manter um golem feio.

Mas eu discordo ...

É o seguinte: para sistemas simples o suficiente, a arquitetura é auto-evidente e emana de boas práticas de design e implementação.

É apenas para sistemas grandes que envolvem um número bastante grande de pessoas ou software em nível de sistema que faz coisas muito complexas que exigem arquitetura explícita.

Eu me formei recentemente na uni e comecei a trabalhar como programador. Não acho tão difícil resolver problemas "técnicos" ou depurar, coisas que eu diria que têm uma solução.

Esse é o requisito mínimo para esta profissão e fico feliz que você não tenha problemas em fazê-la (eu ficaria preocupado se você o fizesse).

Mas parece haver uma classe de problemas que não têm uma solução

Esses são os pães e a manteiga de nossa profissão, o tipo de problemas pelos quais os empregadores estão dispostos a pagar nossos salários (normalmente) muito acima da média.

De fato, os problemas que vale a pena resolver são aqueles que podem ter mais de uma solução. Problemas do mundo real, eles são assim. E o mundo exige que a nossa experiência, como desenvolvedores de software, tenha vantagens e desvantagens aceitáveis.

- coisas como arquitetura de software.

A arquitetura das coisas é uma característica inevitável do sistema complexo, seja virtual / software ou no mundo concreto. Todo sistema que opera, que recebe entrada e produz saída, será complexo e terá uma arquitetura.

Quando desenvolvemos software para esses sistemas (um sistema bancário, um sistema de monitoramento de energia, um sistema de venda de ingressos etc.), nosso objetivo é produzir um software que imite as funções e os requisitos desse sistema.

Nós simplesmente não podemos simplesmente improvisar e codificá-lo no estilo cowboy. Precisamos de algum tipo de arquitetura. Isso é particularmente verdadeiro se o projeto exigir dezenas de engenheiros, se não mais.

Essas coisas me incomodam e me causam grande angústia.

Está bem. Não é um assunto fácil de aprender ou ensinar, não sem muita prática.

Passo horas e horas tentando decidir como "arquitetar" meus programas e sistemas. Por exemplo, divido essa lógica em 1 ou 2 classes, como nomeio as classes, devo tornar isso privado ou público, etc. Esses tipos de perguntas ocupam muito do meu tempo e isso me frustra bastante. Eu só quero criar o programa, a arquitetura seja condenada.

Infelizmente, isso não é arquitetura de software.

Nem sequer é design, mas apenas codificação. Vou fornecer algumas sugestões na parte inferior deste post.

Como posso passar mais rapidamente a fase de arquitetura e entrar na fase de codificação e depuração, da qual gosto ?

Estou tendo dificuldades para encontrar uma maneira de responder a isso, pois é bastante emocional.

Estamos tentando fazer um trabalho, ou estamos apenas tentando aproveitar a prática? É ótimo quando ambos são um e o mesmo, mas na vida real, muitas vezes eles não são.

É ótimo fazer coisas que gostamos, mas em uma profissão tão complexa como a nossa, focar apenas no que gostamos, que não é condutivo para ter uma carreira frutífera.

Você não progride, não amadurece ou adquire novos conhecimentos.

Há esse ditado no Exército: "abrace a merda".

Outras frases têm conselhos semelhantes. "Se não chupar, não vale a pena" e meu favorito: "Se chupar (e é importante), faça até parar de chupar".

Minhas recomendações:

Parece-me que você ainda está lutando para entender as diferenças entre

1. codificação (como codificar suas classes, módulos ou não, convenções de nomenclatura, visibilidade de acesso, escopo etc.),

2. design (quantas camadas, front-end / back-end / db, como cada um se comunica, o que vai aonde) e as decisões implícitas de arquitetura que resultam do design de sistemas simples,

3. arquitetura (como encontrada em sistemas complexos que exigem milhares, senão centenas de milhares de horas de trabalho).

Então, eu sugiro que você mergulhe profundamente no primeiro assunto (codificação) para levá-lo ao próximo nível.

Código Limpo

O "Código Limpo " de Robert "Tio Bob" Martin é um bom lugar para começar.

Coesão de software

Além disso, sugiro que você se familiarize com uma métrica específica de software orientada a objetos chamada LCOM ou melhor, LCOM4.

Pode ser um pouco matemático e não é à prova de balas, mas seu objetivo deve ser o de entender e detectar empiricamente (ou usar um olho ocular, se desejar) se uma classe é coesa ou se não tem coesão.

http://www.aivosto.com/project/help/pm-oo-cohesion.html#LCOM4 https://www.computing.dcu.ie/~renaat/ca421/LCOM.html

Princípios de Software

Isso está intimamente relacionado com o "Princípio da responsabilidade única" ou SRY, com o qual todos devemos estar familiarizados. O SRY é um dos 5 "SÓLIDOS" com os quais todos precisamos estar familiarizados para nos tornarmos proficientes em codificação.

À medida que avançamos nos princípios do SOLID, também precisamos nos familiarizar com os princípios "GRASP" , que governam, ou melhor, orientam como codificamos as classes.

Livros adicionais

Por fim, também sugiro o seguinte:

• "Refatoração", de Martin Fowler e Ken Beck, seria o próximo livro que eu havia lido nesta lista.

• "Design by Contract, by Example", de Richard Mitchell, Jim McKim e Bertrand Meyer (o mais recente da fama de Eiffel.) Este livro está esgotado, mas você pode encontrar cópias usadas e baratas na Amazon.

Com isso, você deve ter uma boa noção de como iniciar a codificação e o design e, com a prática, mover e dominar (ou pelo menos entender) a arquitetura de software.

Tenho certeza de que haverá outros profissionais que adicionarão, subtrairão ou contestarão essas sugestões. Eles apresentarão outras sugestões, provavelmente validadas por sua própria experiência.

Tudo o que posso dizer é isso - não há atalhos.

Muito bem sucedida.

Há muita informação aqui e, francamente, TL; DR. Há uma coisa principal que acho que as pessoas erram ao tentar aprender como projetar um sistema: elas tentam pensar nisso na ordem em que o trabalho será realizado. Em vez disso, você precisa trabalhar para trás. Ou seja, o principal objetivo do design / arquitetura é determinar qual deve ser o resultado final.

Como analogia, considere a arquitetura de uma casa. Um arquiteto não começa se perguntando: "quantas janelas essa casa deve ter?", "Onde o primeiro tijolo deve ser colocado?". Esses detalhes de implementação não são o design, eles são derivados do design. A arquitetura começa com uma visão, talvez um esboço de como a casa acabada pode ser. É uma casa unifamiliar, um duplex? É uma casa de luxo ou facilmente acessível? Da mesma forma, se as variáveis ​​são privadas e se você divide uma classe, tem muito pouco a ver com arquitetura.

Comece primeiro descobrindo quais são os objetivos do seu design. Por exemplo, essa é uma solução pontual? Será expandido, revisado e mantido ao longo de décadas? A resposta para isso indicará designs muito diferentes e esse é o ponto da arquitetura. Depois de descobrir o que você precisa fazer, os detalhes do design seguem naturalmente. Não que esses detalhes sejam óbvios ou fáceis, mas é o plano de alto nível em que essas escolhas se baseiam.

Como julgar quanto tempo você deve dedicar à arquitetura de qualquer software antes de obter algum tipo de loop de teste de compilação e gravação é bastante direto: informações suficientes para caber em sua cabeça e não mais do que isso. A menos que o projeto em que você esteja trabalhando exija uma metodologia mais rigorosa. Nesse caso, como iniciante, provavelmente você deve estar lendo um documento de arquitetura, não o escrevendo.

Quanto a nomear coisas, para mim isso faz parte da "escrita", mas é sem dúvida uma parte muito importante da programação: não hesite em pensar muito em como você nomeia as coisas e em pensar mais quanto maior o escopo do nome.

Encontrar os nomes certos, a arquitetura certa, a modularidade correta e as abstrações certas faz parte da experiência que você obterá ao cometer erros. Ao longo dos anos, escrevi um programa fazendo a mesma coisa cerca de cinco vezes e o código era muito diferente a cada vez, porque todas as iterações anteriores me deram dicas de um design melhor.