Há muitas coisas que precisam ser consideradas ao criar um sistema, vamos usar, por exemplo, um sistema baseado na Web em que os usuários se conectam e interagem entre si, criando e editando conteúdo. Agora eu tenho que pensar em segurança, validação (eu nem acho que tenho 100% de certeza do que isso implica), "garantir que os usuários não pisem uns nos outros" (termo para isso?), Evitando erros em muitos casos, garantindo que os dados do banco de dados não se tornem problemáticos através de ... situações inesperadas? Todas essas coisas que eu não sei como ou onde aprender, existe um livro sobre esse tipo de coisa? Como eu disse, parece haver uma enorme diferença entre escrever código e realmente escrever o código certo, entende o que quero dizer? Sinto que meu trabalho de programação atual não possui muito do que descrevi e posso ver os problemas que ele causa mais tarde, e então os problemas são muito mais difíceis de resolver porque existem dados e as pessoas os estão usando. Então, alguém pode me indicar livros ou recursos ou o subconjunto adequado de programação (?) Para esse tipo de aprendizado?
PS: fique à vontade para corrigir minhas tags, não sei do que estou falando.
Edit: Eu assumo que alguns dos exemplos que escrevi se aplicam a outros tipos de sistemas também, apenas não conheço outros bons exemplos porque estive envolvido principalmente no trabalho na web.
fonte
Quando se trata de aplicativos da Web, há mais informações boas compiladas nesta resposta do que em qualquer outro lugar que eu já vi.
Mas a realidade é que há muito a saber para montar bem um sistema completo. Existem estudos para apoiar 10.000 horas como a quantidade de prática necessária para atingir um nível de domínio e o desenvolvimento de sistemas de informação não é exceção.
fonte
Eu gosto muito da resposta de William Pietri (+1), mas acredito que ela precisa ser adicionada. Mesmo presumindo que o que você entende por sistemas compreenda apenas software.
Mas, antes de entrar no assunto, não conheço um livro para ajudar. Tudo o que se segue, aprendi com a experiência (ou seja, os três pontos que William fez).
O que você está falando abrange, no mínimo, quatro funções amplas. Às vezes, uma pessoa pode preencher todas essas funções, para projetos de pequeno e médio porte, mas quando você inicia em grandes projetos, precisa pelo menos separar essas funções. É difícil para alguém ser especialista em todos eles de qualquer maneira significativa.
Analista de negócios
Essa é a pessoa que conversa com o cliente e traduz seus requisitos em algo que um arquiteto pode entender. Basicamente, uma lista de requisitos adequadamente formulados. Isso inclui os requisitos funcionais óbvios (o que esse sistema deve fornecer?), Mas também os requisitos não funcionais (quais são as características gerais que o sistema deve atender? Isso pode incluir segurança, confiabilidade, disponibilidade, resiliência, capacidade, desempenho, robustez e outros requisitos do ponto de vista do usuário).
Esta é a primeira vez que o sistema deve fazer, o início do pensamento sério.
Arquiteto de sistemas
Essa pessoa produz a estrutura técnica de alto nível dentro da qual trabalhar. Eles fornecem o plano de correspondência de estrutura de tópicos. As ferramentas gerais, técnicas, construções. Eles decompõem todo o sistema em componentes menores, como eles se encaixam, como se encaixam no mundo exterior ...
Isso ajuda de várias maneiras a refinar o que precisa ser pensado. Muitas vezes, problemas são descobertos nesse estágio sobre os requisitos, conforme escrito pelo analista de negócios. Volte a eles para algumas iterações para melhorar sua compreensão do que eles querem e sua expressão.
Designer de sistema
Esse papel é sobre como fazer tudo funcionar. Isso pode ser mais trabalho em equipe do que um show individual. Mas é provável que haja um designer líder para supervisionar todo o design do sistema. Essa pessoa deve se aprofundar nos detalhes e garantir que a visão do arquiteto seja algo que possa realmente ser construído.
Espere um aprimoramento adicional da arquitetura do sistema e, portanto, potencialmente da análise de negócios.
Gerente de testes
Este papel é muitas vezes esquecido. Mas no final do dia, se você não pode testá-lo, como pode provar que pode construí-lo? Deve haver uma revisão dos resultados de todas as etapas: análise de negócios, arquitetura e design por alguém competente em testes, capaz de destacar deficiências e, portanto, permitir correções precoces, muito antes de qualquer código ser escrito.
Esse é um breve resumo.
Esses caras / moças são apenas a direção geral do pessoal da fábrica para pensar sobre o que deve ser pensado.
Para projetos complexos, como grandes aplicativos bancários ou espaciais, apenas para dar dois exemplos (pense de centenas a milhares de dias úteis), existem muitos especialistas no assunto, como os chamamos para revisar e apoiar projetos em todas as etapas. Essas funções incluem análise de segurança, dimensionamento do sistema, capacidade, desempenho, bancos de dados, clustering e muitas outras áreas estreitas de especialização, incluindo áreas de negócios precisas. A variedade de funções depende do tamanho e da complexidade dos sistemas.
Tudo isso para dizer que você não deve tentar saber tudo, não o fará. No entanto, você pode ter uma idéia geral da situação geral e, em pequenos projetos, pode se aprofundar muito mais do que em grandes projetos, simplesmente porque o nível de complexidade permite que você seja mais arredondado.
Se você quiser saber como projetar sistemas, precisará começar a fazer perguntas pensando fora da caixa. Coloque-se o suficiente no lugar do cliente e tente pensar no que poderia dar errado, no que precisa ser testado. Depois, reúna-se com um cliente real e incentive-o a explicar as extensões e os limites do sistema que eles imaginam que precisam. Além disso, sempre que digo "cliente", você deve entender que isso abrange várias pessoas muito diferentes. Existe a pessoa que usa o sistema dia após dia para o que foi projetado para fazer. Há o operador, o suporte técnico, o gerente que precisa de um relatório ou outro, o auditor, a equipe de infraestrutura, a parte interessada que pagou, o gerente de qualidade que precisa de meios para testar seu sistema ... Pergunte a todos eles (e se eles são uma pessoa, peça a eles que coloquem todos esses chapéus um de cada vez), então pergunte a eles tudo o que precisam e você terá um bom começo para saber quais são os requisitos do sistema. De lá, você pode derivar a arquitetura e, a partir daí, o design.
Para sistemas complexos (seja apenas software ou para integrar-se ao hardware no sentido mais genérico), não apenas uma pessoa é suficiente para cada uma das quatro funções listadas acima, mas você precisa gerenciar o projeto até a definição do que o sistema deve fazer, muito menos as outras fases.
HPH, asm.
fonte
Não é "um livro". Muitos livros.
Não há estrada real
Certo.
Você está falando sobre "arquitetura", programação em geral.
Etapa 1. Leia muito código. Muito. Pense nas coisas que você gostaria de fazer. Encontre projetos de código aberto relacionados. Leia o código. Tudo isso.
Etapa 2. Leia mais código. Muito mais.
Etapa 3. Leia livros sobre arquitetura.
fonte
Para amplificar ler muitos livros ....
Agora que você sabe que tem um problema, há algum motivo em pedir para você ler esses livros. (Antes de você fazer algum trabalho real, há pouco sentido em discutir esses livros)
Padrões de Design por Gamma, Helm, Johnson e Vlissides Pattern Languages of Program Design 1,2,3 e 4.
Mas não tente aplicar todos os padrões em todos os lugares que você vê que podem ser usados
isso também é uma coisa ruim.
Espero que isto ajude.
fonte
A melhor maneira de aprender a fazer qualquer coisa é fazê-lo. Se você quer aprender a falar francês, precisa falar francês, ler francês, escrever francês e ler sobre francês, ir à França e conversar com o francês em francês. Se você quer saber como tocar piano, você precisa realmente tocar piano. Você tem que tocar músicas simples e aprender a estrutura do piano e a estrutura da música. Você precisa aprender a ler música e a expressar música através de um piano usando os dedos. Você precisa aprender como a música soa e que tipos de sons um piano pode emitir versus o que uma guitarra, flauta ou saxofone pode fazer.
A programação é exatamente a mesma. Para saber como projetar um banco de dados, é necessário projetar bancos de dados. Se você deseja entender a criptografia, implemente algoritmos criptográficos e protocolos criptográficos. Se você deseja escrever um software que possa atender a vários usuários simultaneamente, é necessário entender como as E / S de disco, E / S de rede e threads funcionam. Para entender como isso funciona, você deve escrever um código que leia e grave arquivos, transmita dados através de uma rede e sincronize o acesso aos recursos. Tudo isso requer prática.
Um "sistema" é, geralmente, apenas uma coleção de coisas. Peças que se coordenam para formar um todo. Para construir algo grande, você precisa construir um monte de peças pequenas. Portanto, se você quiser aprender a construir sistemas, comece a criar sistemas. Resolva um problema, divida em pedaços e implemente cada um, um por um. Eventualmente, você terá um "sistema" integrado. Você provavelmente falhará algumas vezes ao longo do caminho, mas tudo bem. Se você não está falhando, geralmente significa que não está se esforçando o suficiente.
Além disso, eu recomendaria ir à escola para estudar Ciência da Computação. Isso não vai ajudar muito com a parte "prática". Você terá que fazer isso por conta própria, mas isso ajudará na parte da exposição. Você aprenderá muito, praticamente tudo relacionado a como os computadores e sistemas de computadores funcionam, o que é difícil de aprender por conta própria.
fonte