Se você projetar corretamente, durará para sempre.
Por que os projetos falham?
Se eu fizesse essa pergunta, dos desenvolvedores aos gerentes de projeto, eu estaria recebendo uma miríade de respostas ( ou explicações ).
Mas em todo o processo de ” explicar o fracasso “, ignoramos convenientemente o fator mais importante que resultou em fracasso em primeiro lugar.Gerenciando a Complexidade.
Sim. O software tornou-se tão complexo que chegou a um estágio em que ninguém sabia o que faz.
E quando qualquer projeto atinge um ponto em que ninguém entende completamente como o impacto das alterações de código em uma área afetará qualquer outra área, podemos ter certeza de que o projeto está fadado ao fracasso. Mais cedo ou mais tarde, o projeto chega a um impasse.
Por enquanto, tudo bem. Chegamos à próxima grande questão.Por que os projetos se tornam complexos?
A resposta curta é design fedorento .
É por isso que Steve Jobs estava no alvo quando disse.“
Não é apenas o que parece e se sente. Design é como funciona. “
e o design é como uma geladeira – quando funciona, ninguém percebe, mas quando isso não acontece, certamente fede. e fede o inferno fora do projeto.
Você pode argumentar aqui.
“ Hey, eu sou um desenvolvedor. Eu sou o único que escreve o código e constrói o produto com minhas próprias mãos. Como pode ser que alguém determine como isso funciona? ”
A realidade de todos os desenvolvedores é que eles estão completamente imersos no back-end, mas nunca estão cara a cara com o usuário final. O usuário final pode ser o usuário final do produto ou até mesmo o indivíduo de suporte “ amigável ” que precisa suportar seu aplicativo posteriormente.
E na maioria das vezes, o usuário não interage diretamente com seu trabalho – o usuário interage com o produto final que é dado para seu consumo e o produto final, seja em termos de código, interface do usuário ou facilidade de uso depende apenas do design.
Um bom design significa que os usuários estão felizes. Bad design significa que eles são penalizados sem culpa deles. Período.
A diferença de perspectiva é importante para ser entendida aqui. Os desenvolvedores estão perdendo a parte mais importante ao escrever o código; o design.
E esse conhecimento crucial de projeto permite que você monte todo o sistema em sua mente – desde como o usuário interage com o produto, até o último link onde você armazena as informações no banco de dados. Essa trajetória completa permite desenvolver um produto melhor do que a concorrência.
E aqui estão algumas das maravilhosas regras do design que me ajudaram em toda a minha carreira de programação.
Criar Abstrações Consistentes
Josef Albers disse com razão.
“A abstração é real, provavelmente mais real que a natureza. “
A abstração é a capacidade de se envolver com um conceito, ignorando com segurança os detalhes mais sutis existentes em diferentes níveis. Encontramos e usamos abstração em todo o mundo real. Por exemplo, quando nos referimos a qualquer objeto como um carro , nos referimos automaticamente a ele como um todo, em vez de dividi-lo em suas partes individuais, como chassi, motor, freios, etc.
Em termos de software, a necessidade da hora é criar classes base poderosas que permitam que você se concentre em um conjunto de atributos comuns de um conjunto de classes derivadas enquanto ignora os detalhes de classes específicas.
Assim, uma boa interface de classe é uma abstração que permite que você se concentre na interface sem se preocupar com o funcionamento interno da classe. Isso cria um design que é simples e, em seguida, facilmente desacoplado.
Um ótimo design de software significa abstrações criadas no nível de interface de rotina, nível de interface de classe e nível de interface de pacote, e isso resulta em uma programação mais rápida e segura.
Ocultar os detalhes da implementação
Len Wein acerta na cabeça quando ele diz.
“Em geral, menor é melhor. Se você puder encapsular sua ideia em uma única frase cativante, estará na metade do caminho para casa. ”
Escondendo ou encapsulando pega onde a abstração sai. Enquanto a abstração diz “Você pode olhar para qualquer objeto com um nível mais alto de detalhes” , os encapsulamentos vão um passo além e dizem: “Você não tem permissão para olhar para esse objeto com qualquer outro nível de detalhe também”.
É aqui que entra o maravilhoso conceito de herança .
Ao projetar qualquer sistema de software, muitas vezes podemos descobrir que os objetos são muito semelhantes entre si, com exceção de algumas diferenças.
Por exemplo, ao projetar um sistema de contratação, podemos ter tipos diferentes de contratos (fixo, tempo e material, baseados em incentivos, etc.), mas os atributos gerais de cada contrato permanecem os mesmos. Assim, você pode criar um objeto genérico chamado “contrato” e, em seguida, definir o contrato de “preço fixo” como “herdado” do objeto de contrato com alguns atributos adicionais e assim por diante.
A herança simplifica o design porque você escreve uma rotina genérica para manipular qualquer coisa e depois escreve rotinas específicas para cuidar de cenários específicos. Não apenas o código é “ limpo ”, mas também oferece uma ótima maneira de desvincular detalhes desnecessários do desenvolvedor que usará a classe ou o objeto para herdar.
A herança é uma das ferramentas mais poderosas da programação orientada a objetos. É uma espada de dois gumes; Ele pode fornecer grandes benefícios quando usado corretamente e pode causar grandes danos quando usado ingenuamente.
Mudança vai acontecer. Planeje isso.
Amit Ray mata lindamente quando ele diz.
“Em toda mudança, em toda folha que cai, há alguma dor, alguma beleza. E é assim que novas folhas crescem.
Ao projetar qualquer sistema, as mudanças antecipadas precisam ser mantidas em consideração e as provisões devem ser mantidas no lugar para evitar qualquer azia e luto posterior. Como regra geral, você precisa projetar seu sistema de forma que o efeito ou o escopo da mudança seja diretamente proporcional à probabilidade de o mesmo acontecer.
Quanto mais a probabilidade, mais o sistema precisa estar pronto para acomodar a mudança.
Um bom ponto de partida pode ser identificar as áreas que têm o potencial de mudar e, então, identificar o subconjunto mínimo que deve permanecer constante. Todo o planejamento subsequente pode ser feito em cima desse subconjunto mínimo.
Assim, identificando o núcleo primeiro, você pode ver claramente quais componentes complementares precisam ser criados e, consequentemente, deixar ” saídas ” no código para planejar a implementação em um momento posterior.
Assim, em poucas palavras, crie um conjunto de classes e rotinas com relações pequenas, diretas e flexíveis com classes principais de uma maneira “ fracamente acoplada ”. Esse acoplamento flexível permite que o projeto seja flexível o suficiente para acomodar as mudanças e facilitar a implementação.
Iterar até você acertar.
Sebastian Thrun disse com razão.
“Poucas ideias funcionam na primeira tentativa. A iteração é fundamental para a inovação ”.
O design é sempre um processo iterativo. Você frequentemente acha que vai do ponto A ao ponto B e depois volta ao ponto A para começar tudo de novo. É frustrante, mas não há atalhos para chegar a um design robusto e viável. Paciência é a chave.
Ao percorrer o caminho de A a B, você verá vários designs, experimentará várias abordagens e visualizará várias visualizações de alto e baixo nível. A visão inicial de alto nível é fluida e, à medida que você caminha, você solidifica a mesma em visualizações concretas de baixo nível. Finalmente, você decide sobre uma abordagem; top-down ou bottom-up e, em seguida, criar uma estrutura baseada nisso.
A chave não está parando na primeira tentativa. A segunda tentativa é sempre melhor que a primeira e você aprende as coisas em cada tentativa, o que melhora progressivamente o design geral. O refino incremental é uma ferramenta muito poderosa para reduzir a complexidade.Como Polya disse corretamente.
“Entenda o problema, planeje um plano, execute o plano e depois olhe para trás para ver como você se saiu.”
Prototipagem é a prova no pudim
Laurie Anderson corretamente disse.
“O problema dos protótipos é que nem sempre funcionam. Mas é assim que deve ser ”
Talvez a maior vantagem da prototipagem seja a representação visual de um desenho, uma imagem, mesmo que em menor escala, tenha mais de mil palavras. Essa imagem não apenas nos convence da operacionalidade do design, mas também ajuda a conseguir que os “ buy-ins ” e as aprovações necessárias sigam em frente.
Mas tendo dito isso, Prototipagem não é para todos os projetos, mas para os projetos, é certo, pode ser um grande trunfo.
Um protótipo serve como um modelo descartável feito para entender os requisitos de um projeto antes do projeto e codificação começarem. Em essência, a prototipagem é uma execução de teste do projeto.
Há muitos problemas inesperados que podem ocorrer durante o processo de desenvolvimento de software, mesmo que você tenha revisado o design várias vezes. O teste de prototipagem permitirá, pelo menos, que a equipe de desenvolvimento saiba quais são os problemas e tenha a oportunidade de aprimorá-la antes de liberar o público do produto.
Usada com disciplina, a prototipagem é a ferramenta de trabalho, um designer tem à sua disposição para combater a maldade do design. O retorno pode ser imenso; basta olhar para o iPhone.
Então, quanto é projeto suficiente
Infelizmente, não há resposta racional ou lógica para essa questão. Na maioria dos casos, é mais um julgamento do que qualquer outra coisa. Mas enquanto você não pode garantir com precisão a quantidade certa de design necessária em qualquer projeto; duas abordagens de design estão fadadas a falhar todas as vezes.
· Não tendo nenhum design
· Projetando tudo antecipadamente até o último detalhe.
Lute pela simplicidade e persista dogmaticamente com iteração até chegar ao design mais ideal. Quanto mais o seu design está mais próximo do problema da vida real, ele é projetado para resolver, mais são suas chances de sucesso, tão simples quanto isso.
Como Steve Jobs disse apropriadamente.“Design não é apenas o que parece e se sente. O design é como funciona. ”