Estou trabalhando como desenvolvedor de aplicativos há um ano e meio (não sei muito tempo) e acabei de receber meu primeiro grande projeto.

Escusado será dizer que não correu muito bem, então procurei aconselhamento de um programador sênior envolvido no projeto sobre como abordá-lo.

Ele disse que eu havia pensado drasticamente na tarefa em questão, e isso porque nunca havia abordado um projeto dessa escala antes de ter passado muito tempo pensando nos padrões de design. Nas suas sábias palavras, ele me disse: "F * ck the future, build for now".

Essa é uma tendência que os programadores geralmente seguem ao realizar um projeto como esse? Por exemplo, se você foi solicitado a fazer uma prova de modelo de conceito, é uma tendência típica apenas misturar um exemplo viável o mais rápido possível?

Edit: À luz do debate que provocou, eu gostaria de mencionar que esta situação é bastante extrema: temos prazos muito apertados devido a fatores fora do nosso controle (ou seja, o mercado que pretendemos perderá o interesse se não mostre algo a eles) e seus conselhos provaram ser muito eficazes para essa tarefa em particular.

Capitão Óbvio ao Resgate!

Serei o capitão Óbvio aqui e direi que há algum meio termo a ser encontrado.

Você deseja construir para o futuro e evitar se prender a uma opção tecnológica ou a um design ruim. Mas você não deseja passar três meses projetando algo que deve ser simples ou adicionando pontos de extensão para um aplicativo rápido e sujo que terá uma vida útil de 2 anos e é improvável que tenha projetos de acompanhamento.

É difícil encontrar a distinção, porque nem sempre é possível prever o sucesso do seu produto e se você precisar estendê-lo mais tarde.

Construir para agora se ...

• o projeto vai ser descartado
• o projeto tem uma vida útil curta
• o projeto não deve ter extensões
• o projeto não tem um valor de impacto de risco (principalmente em termos de imagem)

Em geral, projetos internos ou algo criado para um cliente devem ser desenvolvidos por enquanto. Certifique-se de ter requisitos diretos e relacione-os conforme necessário para saber o que é necessário e o que não é. Não queira gastar muito tempo com nada que seja "bom de ter". Mas não codifique como um porco também.

Deixe o problema geral para mais tarde, se for necessário e valer a pena:

Construa para o futuro se ...

• o projeto será público
• o projeto é um componente a ser reutilizado
• o projeto é um trampolim para outros projetos
• o projeto terá projetos de acompanhamento ou lançamentos de serviços com aprimoramentos

Se você está construindo para algo público, ou que será reutilizado em outros projetos, você tem uma probabilidade muito maior de que um projeto ruim volte para assombrá-lo, portanto, você deve prestar mais atenção nisso. Mas nem sempre é garantido.

Diretrizes

Eu diria que adote os seguintes princípios da melhor maneira possível e você deve se colocar na posição de projetar produtos eficientes e adaptáveis:

• sabe que YAGNI ,
• KISS ,
• sempre que sentir vontade de coçar e pensar em uma adição, anote-a. Relembre os requisitos do seu projeto e pergunte a si mesmo se as adições são prioridades ou não. Pergunte se eles agregam valor comercial primário ou não.

Eu sei que pessoalmente tenho a tendência de pensar demais e ser engenheiro demais. Realmente ajuda a escrever idéias e, muitas vezes, repensar se eu precisar de recursos adicionais. Frequentemente, a resposta é não, ou "seria legal depois". Essas últimas idéias são perigosas, porque ficam na parte de trás da minha cabeça, e eu preciso me forçar a não planejar.

A melhor maneira de codificar sem a superengenharia e sem se bloquear para mais tarde é se concentrar em um bom design mínimo. Divida as coisas bem como componentes que você pode estender mais tarde, mas sem pensar em como eles podem ser estendidos mais tarde. Você não pode prever o futuro.

Basta construir coisas simples.

Dilema

Overengineering

Essa é uma tendência que os programadores geralmente seguem ao realizar um projeto como esse?

Isso aí. É um dilema conhecido e mostra apenas que você se importa com o produto. Se não, isso é mais preocupante. Há desacordo sobre se menos é sempre realmente mais e se o pior é sempre realmente melhor . Você pode ser do tipo MIT ou New Jersey . Não há uma resposta fácil aqui.

Prototipagem / Rápido-e-Sujo / Menos é Mais

É uma tendência típica apenas misturar um exemplo viável o mais rápido possível?

É uma prática predominante, mas não é assim que a grande maioria dos projetos é abordada. Ainda assim, a prototipagem é uma boa tendência na minha opinião, mas com uma desvantagem média. Pode ser tentador promover protótipos rápidos e sujos para produtos reais ou usá-los como base para produtos reais sob pressão de gerenciamento ou restrições de tempo. É quando a prototipagem pode voltar para assombrá-lo.

Existem vantagens óbvias na criação de protótipos , mas também muito potencial para uso indevido e abuso (muitas exatamente o inverso das vantagens listadas anteriormente como resultado).

Quando usar prototipagem?

Há dicas sobre os melhores tipos de projetos para usar a prototipagem :

[...] a prototipagem é mais benéfica em sistemas que terão muitas interações com os usuários.

[...] a prototipagem é muito eficaz na análise e design de sistemas on-line, especialmente no processamento de transações, onde o uso de diálogos na tela é muito mais evidente. Quanto maior a interação entre o computador e o usuário, maior o benefício [...]

"Um dos usos mais produtivos da prototipagem rápida até hoje foi como uma ferramenta para a engenharia de requisitos iterativos do usuário e o design da interface homem-computador".

Por outro lado:

Sistemas com pouca interação do usuário, como processamento em lote ou sistemas que fazem cálculos, beneficiam-se pouco da prototipagem. Às vezes, a codificação necessária para executar as funções do sistema pode ser muito intensa e os ganhos potenciais que a prototipagem poderia proporcionar são muito pequenos.

E se você tem um monstro verde por perto, mantenha um protótipo dentro do orçamento ...

Quando você inicia a programação, tudo é uma prova de conceito, mesmo que seja apenas para você. Há casos em que uma ideia exige algo rápido e sujo ou um protótipo porque o tempo é um fator-chave. O grande medo entre os desenvolvedores é que as partes interessadas acham que o pequeno aplicativo está pronto para produção ou você poderá adicionar recursos na mesma taxa para sempre. Você trabalha em um grande projeto e descobre que esse não é o caso.

Projetos grandes geralmente têm requisitos mais complexos, portanto há uma tentação de tentar implementar projetos complexos. Você passará muito tempo lendo, pesquisando e tentando implementá-los. Isso pode se tornar um grande desperdício de tempo, mas tudo faz parte do aprendizado e do ganho de experiência. Saber quando usar um design específico é difícil e geralmente vem com a experiência. Eu tentei "that" neste projeto e não funcionou, mas agora vejo que deve funcionar aqui.

Você precisa planejar e planejar muito, mas não faça tudo de uma vez. Definitivamente, não precisa ser feito tudo no começo. Prefiro ver alguém criar seu primeiro grande projeto como este:

1. Projete e discuta um pouco.
2. Escreva um monte de código que faça alguma coisa.
3. Reconheça os problemas e pare a codificação.
4. Leve a sério o design e pare de se preocupar com a perda de impulso ou seu código-mojo e ignore o gerente de projeto (você está fazendo um favor a ele).
5. Controle o projeto. Corrija suas bagunças. Certifique-se de que todos entendam o plano. Mantenha o projeto sob controle.

Às vezes, você encontra um desses recursos que realmente o preocupa em como implementá-lo na base de código existente. Este não é o momento de "apenas fazê-lo funcionar". Eu tive um chefe que disse: "Às vezes você tem que pegar um banquinho ao invés de um martelo". Ele me disse isso depois que me pegou "pensando" na minha mesa. Ao contrário de muitos chefes, ele não assumiu que eu estava enganando e fez questão de entender que ele queria que eu fizesse mais. Gênio.

Por fim, seu código é o design. É suportado por documentos, diagramas, reuniões, e-mail, discussões no quadro branco, perguntas de SO, argumentos, xingamentos, acessos de raiva e conversas tranqüilas sobre o café. Há um ponto em que você não pode mais projetar e corre o risco de perder mais tempo com o design, devido às falhas que você descobrirá tentando escrever o código. Além disso, quanto mais código você escrever, maior será a chance de apresentar uma falha de design da qual você não pode sair do código. Hora do banquinho novamente.

Os programadores geralmente criam algo que funciona agora sem pensar no futuro?

Sim.

Eles deveriam fazer isso?

Não.

À primeira vista, parece que "pensar no futuro" viola princípios de design estabelecidos como o KISS e o YAGNI , que afirmam que não deve ser implementado nada que não seja necessário no momento.

Mas na verdade não. Pensar no futuro significa projetar software simples, extensível e gerenciável. Isso é especialmente importante para projetos de longo prazo. Novos recursos serão necessários com o tempo e, com um design sólido, será mais fácil adicionar novas peças.

Mesmo que você não vá trabalhar em um projeto depois de concluí-lo, você ainda deve desenvolvê-lo de maneira inteligente. É o seu trabalho, e você deve fazê-lo bem, pelo menos para não esquecer como o bom trabalho é feito.

Os desenvolvedores ágeis têm um ditado, "Você não precisa disso (YAGNI)", que incentiva o design para o que você precisa agora e não para o que acha que pode precisar no futuro. Para estender um design para funcionar no futuro, a rota recomendada é refatorar.

O aspecto importante disso é manter os requisitos do seu produto em mente ao projetar e garantir que você não esteja projetando para um monte de requisitos que possam ocorrer no futuro.

Há algo a ser dito para os desenvolvedores que podem pensar duas ou três iterações à frente - eles conhecem seus clientes ou o domínio tão bem que podem antecipar necessidades futuras com altos graus de precisão e criar para eles, mas se você não tiver certeza, é melhor não gastar muito tempo com coisas que você ou os clientes não precisam.

Essa é uma tendência que os programadores geralmente seguem ao realizar um projeto como esse?

Suspeito que o seu mentor quis dizer foi que você não deve criar uma complexidade adicional que talvez não seja necessária pela solução final.

É muito fácil pensar que um aplicativo deve fazer isso e aquilo e ser desviado em massa.

Quanto aos padrões de design, vale lembrar que eles são um meio para atingir um fim. Se, com a experiência, você descobrir que um determinado padrão de design não se encaixa, apesar de seu palpite anterior, isso pode indicar um cheiro de código.

Por exemplo, se você foi solicitado a fazer uma prova de modelo de conceito, é uma tendência típica apenas misturar um exemplo viável o mais rápido possível?

Vale a pena dar uma guinada antes do início do projeto sobre quais marcos existem e se eles querem ver um pouco de tudo (fatia vertical) ou apenas cada parte em detalhes à medida que você a desenvolve (fatia horizontal). Como parte do design inicial, acho que vale a pena abordar todo o aplicativo, portanto, mesmo que o código não esteja escrito, você pode fazer uma exibição de helicóptero da coisa toda ou mergulhar profundamente em uma determinada área.

Ele disse que eu havia pensado drasticamente na tarefa em questão e que, como nunca havia enfrentado um grande projeto como esse, passava muito tempo pensando nos padrões de design. Nas suas sábias palavras, ele me disse: "F * ck the future, build for now".

Eu acho que isso é um pouco de mentalidade de cowboy do outro desenvolvedor. A versão moderna de um nerd durão que apenas "faz isso agora". Tornou-se um tema popular entre as startups e não agradece às pessoas do Facebook por iniciarem a frase "fazer o que é melhor do que fazer o que é certo".

É atraente. É encorajador e oferece visões de desenvolvedores em pé ao redor de um console, batendo palmas enquanto lançam seu grande projeto no mundo dentro do prazo, do orçamento e tudo porque não fizeram nada demais.

É uma fantasia idealista e a vida não funciona dessa maneira.

Um tolo se apressa em um projeto pensando que ele pode simplesmente "fazê-lo" e fazê-lo. O sucesso favorecerá o desenvolvedor que se prepara para os desafios invisíveis e trata sua profissão como um bom artesanato.

Qualquer desenvolvedor sênior pode criticar, condenar e reclamar - e a maioria faz!

Enquanto ele / ela lhe diz que você está "pensando demais" no projeto. Parabenizo você por "pensar" primeiro. Você deu os primeiros passos para ser um desenvolvedor melhor do que o outro cara.

Essa é uma tendência que os programadores geralmente seguem ao realizar um projeto como esse? Por exemplo, se você foi solicitado a fazer uma prova de modelo de conceito, é uma tendência típica apenas misturar um exemplo viável o mais rápido possível?

Isso é exatamente o que é uma prova de conceito. É uma tentativa de misturar algo o mais rápido possível, para que as pessoas possam dar um passo atrás e olhar para ele. É feito para evitar erros, direção incorreta e perda de tempo / dinheiro.

Existem muitos tipos diferentes de prova de conceitos. Você pode criar algo que é jogado fora no lixo quando terminar ou pode criar algo que represente um ponto de partida para o projeto. Tudo depende do que você precisa e de quão próximo o conceito está do produto final.

Também é uma oportunidade de demonstrar suas idéias. Houve momentos em que apresentei um protótipo que levou as coisas a um nível que elas não esperavam.

Normalmente, o design é aberto, por isso é muito fácil aplicar muito ou pouco. E você saberá a quantidade correta somente depois que o projeto for concluído ou descartado. Ou mesmo não então.

Não existe uma receita geral para o sucesso, mas você pode aprender a reconhecer extremos. O design completo de tudo no início quase nunca funciona além de coisas triviais. Não há problema em deixar componentes para refino e apenas ter a sensação de que isso pode ser feito, ou existe uma maneira de descobrir problemas mais cedo.

Você pode procurar como o desenvolvimento incremental funciona se você não estiver familiarizado. Os métodos de sucesso geralmente são iterativos em um ou mais níveis, buscam feedback rígido e crescem em algum esqueleto.

Existem algumas boas razões para ouvir conselhos para interromper o planejamento e começar a codificar;

1. Depois de apenas 18 meses como desenvolvedor, é improvável que você possa antecipar o futuro suficientemente bem para planejar, independentemente do GPA da faculdade. Isso é extremamente difícil para os desenvolvedores brilhantes, mas inexperientes, porque é tudo sobre não saber o que você não sabe. Mãos velhas podem ter reconhecido essa fraqueza em sua visão e sabiamente o encorajaram a entrar nela e fazer o seu melhor.

2. Os desenvolvedores jovens podem ficar obcecados em aperfeiçoar o design antes de começarem a codificar. Eles podem estar cobrindo o medo de escrever o código (ansiedade de desempenho) ou podem ter bloqueio de codificador (como bloqueio de escritor). Eles se divertem no design porque não há saída de trabalho necessária. O jovem desenvolvedor provavelmente responderá com raiva à sugestão de que "tem medo" de qualquer coisa. Talvez no final do projeto eles percebam que estavam. O conselho para não se preocupar e obter a codificação constitui a única cura conhecida para o bloqueio do codificador. Um veterano pode sabiamente oferecer esse conselho.

3. Na presença de severas restrições de cronograma, suas chances de concluir o projeto são limitadas. Planeje por muito tempo e, por melhor que seja o plano, você não poderá executá-lo a tempo e nunca chegará ao mercado. Comece a hackear desde o início, e talvez você tenha sorte e esteja certo na primeira vez. Você entrega o produto milagrosamente. Ou talvez você não tenha tanta sorte e entregue um pedaço de escória pela metade, mas ela chega ao mercado a tempo e você aprende alguma coisa. Ou talvez você falhe. Mas "talvez você falhe" ainda é uma probabilidade melhor do que "nunca chegou ao mercado" porque você planejou por muito tempo. O entendimento principal é que suas chances são limitadas desde o início, para que você não perca nada ao invadir. Seu gerente pode saber que há poucas chances de sucesso e atribuiu um recurso júnior apenas como exercício de aprendizado. Aprendemos melhor com o fracasso do que com o sucesso. Você já perguntou: "Quando posso ter um projeto inteiro?"

É preciso um desenvolvedor introspectivo e isento de ego para ver suas próprias imperfeições; portanto, medite um pouco antes de ler o resto disso, para que você não se dê desculpas para ignorar suas próprias fraquezas ...

Nem todo desenvolvedor é particularmente bom em análise, planejamento e outras tarefas que requerem reflexão. O pensamento é difícil e nojento. Requer um tipo de suor mental que o deixa desconfortável e torcido após um dia de trabalho. Não é tão divertido quanto entrar no estado de fluxo com suas duas latas de Monster e seu rock ficou alto e codificando, codificando, codificando. Os desenvolvedores que não gostam de pensar resistirão à noção de que o planejamento é uma boa idéia. Eles recomendam metodologias de desenvolvimento que não exigem planejamento antecipado. Eles gostam de empresas e gerentes que não enfatizam o planejamento. Eles gravitam para trabalhos onde o custo de não planejar não é muito alto. Eles valorizam todas as sessões noturnas de codificação e disponibilizam esse hotfix para clientes cujos negócios estão inoperantes por causa de um bug.

Alguns desenvolvedores até perceberam que fazer algo funcionar bem o suficiente para demonstrar significa que fazê-lo funcionar completamente e sob todas as circunstâncias pode ser adiado e talvez até empurrado para outro desenvolvedor, enquanto eles recebem elogios por "fazer o trabalho" inicialmente.

Existem gerentes que não conseguem identificar uma tendência até que ela já esteja quebrando no facebook. Em vez de encontrar um emprego gerenciando uma loja de pneus com desconto, esses gerentes criam seu problema de que precisam do código em execução na sexta-feira. Eles não querem saber que você precisa projetar a API ou testar se seu algoritmo é escalável. Isso é apenas tecnologia para eles. Eles o incentivarão a codificar, porque é tudo o que eles entendem sobre o software quando estavam escrevendo scripts perl para ajudar os clientes a transferir seus arquivos. (Eles tinham o título de 'engenheiro de software' em seu primeiro trabalho de vendas. Quem sabia que o software seria tão chato e difícil?)

Mostre-me seu código e eu direi quem você é

Seu código é seu cartão de visita. Se você escreve um código confuso, o que você diz sobre você para as outras pessoas? Apenas pense nisso. Toda vez que encontramos no escritório um fragmento de código realmente ruim, perguntamos a nós mesmos: quem o escreveu e como diabos ele passou pela universidade?

Você está se tornando o que codifica

Seu código é seu programa para toda a vida.

Um programador escrevendo código ruim é como uma dançarina de balé dançando no clube de strip-tease

Algumas pessoas não se importam em dançar no clube de strip-tease. Mas se eles são dançarinos, eles estão desperdiçando suas habilidades. Se você é pobre dançarino, mas tem pernas bonitas, pode despir-se para muitos.

Finalmente, você deve ler o romance de Gogol, 'The Portrait', e ser avisado pela história do personagem principal. Seu amigo é semelhante ao homem do retrato. Ele está atraindo você com dinheiro, mas você pagará o preço alto por isso.