Preso devido a "saber demais" [fechado]

Observe mais discussões em http://news.ycombinator.com/item?id=4037794

Eu tenho uma tarefa de desenvolvimento relativamente simples, mas toda vez que tento atacá-la, acabo entrando em espiral - como isso poderia estender o futuro, quais serão os clientes de segunda geração que precisam, como isso afeta "não-funcional" aspectos (por exemplo, desempenho, autorização ...), como seria melhor arquitetar para permitir mudanças ...

Lembro-me de um tempo atrás, mais jovem e, talvez, mais ansiosa. O "eu" que eu era então não teria pensado em tudo isso - ele teria ido em frente e escreveu algo, depois reescreveu e reescreveu novamente (e novamente ...). O "eu" hoje é mais hesitante, mais cuidadoso.

Hoje acho muito mais fácil sentar e planejar e instruir outras pessoas sobre como fazer as coisas do que realmente ir em frente e fazê-las eu mesmo - não porque eu não gosto de codificar - pelo contrário, eu amo! - mas porque toda vez que sento no teclado, acabo no mesmo lugar irritante.

Isso está errado? Esta é uma evolução natural, ou eu me meti em uma rotina?

Divulgação justa - no passado eu era desenvolvedor, hoje meu cargo é "arquiteto de sistema". Boa sorte para entender o que isso significa - mas esse é o título.

Uau. Sinceramente, não esperava que essa pergunta gerasse tantas respostas. Vou tentar resumir.

Razões:

1. Paralisia da análise / excesso de engenharia / revestimento de ouro / (qualquer outro "muito pensamento antecipado pode prejudicá-lo").
2. Muita experiência para a tarefa em questão.
3. Não focando no que é importante.
4. Experiência insuficiente (e percebendo isso).

Soluções (sem correspondência com os motivos):

1. Testando primeiro.
2. Comece a codificar (+ por diversão)
3. Um para jogar fora (+ uma API para jogar fora).
4. Defina restrições de tempo.
5. Retire o cotão, fique com o material.
6. Faça um código flexível (meio oposto a "um para jogar fora", não?).

Obrigado a todos - acho que o principal benefício aqui foi perceber que não estou sozinho nessa experiência. Na verdade, eu já comecei a codificar e algumas das coisas grandes demais caíram, naturalmente.

Como esta pergunta está encerrada, aceitarei a resposta com mais votos a partir de hoje. Quando / se mudar - tentarei seguir.

Pensar nessas coisas é definitivamente bom, mas não deixe que isso pare seu progresso.

Uma abordagem que funciona muito bem (especialmente no desenvolvimento iterativo) é implementar uma solução simples e refatorar conforme necessário posteriormente. Isso mantém o código o mais simples possível e evita o excesso de engenharia. A maioria das alterações de desempenho ou arquitetura que você está contemplando provavelmente não serão necessárias, de modo que não se preocupe em escrevê-las até que elas se tornem oficialmente necessárias. Por exemplo, não se preocupe com o desempenho até que um criador de perfil tenha informado que é hora de melhorar o desempenho.

Uma coisa que você pode fazer para ajudá-lo a se ajustar é definir um limite de tempo difícil para quanto tempo você pensa em algo antes de escrever o código. Na maioria das vezes, o código fica melhor se você pensar um pouco, escrever, perceber seus erros e corrigi-los refatorando.

Há um equilíbrio a ser encontrado aqui. Você não deve simplesmente entrar na discussão e não pensar nas consequências, mas também não deve tentar exagerar o seu código.

A Wikipedia o chama de "paralisia da análise" no software. A receita é seguir as metodologias ágeis. Significando que qualquer atividade ou ação individual tem muito mais valor do que tentar estabelecer práticas ou políticas. Todo colaborador da equipe é valioso, não importa quão bem ou mal as habilidades da pessoa se ajustem aos ideais arquitetônicos. Em indivíduos ágeis, os egos são os primeiros, as políticas são as últimas.

Minha resposta favorita é "Arquitetura é verbo". Pare de pensar, comece a agir, não importa quão imperfeita e ineficiente você e a equipe se sintam. Talvez as primeiras ações possam ser desmantelar políticas inadequadas.

40 anos atrás, Fred Brooks escreveu sobre isso "Escreva alguém para jogar fora, você vai de qualquer maneira". Nada mudou........

Isso está errado? Esta é uma evolução natural, ou eu me meti em uma rotina?

Depende. Isso tende a ser um passo comum ao longo do caminho de um desenvolvedor.

1. Comece a jogar porcaria juntos, ser mordido na bunda por ele
2. Comece a projetar demais o inferno de tudo, perceba que YAGNI
3. Resolva-se em um meio termo pragmático, onde as coisas fáceis são colocadas juntas e as coisas difíceis / com possibilidade de mudança recebem engenharia suficiente para facilitar o trabalho / mudança.

É apenas uma rotina se você ficar no número 2.

Uma das coisas que eu sempre gosto de lembrar é o ditado "o futuro não é mais o que costumava ser".

Com uma certa quantidade de experiência, torna-se tentador acreditar que você pode prever o futuro, mas não pode. É fácil visualizar recursos que futuros clientes / usuários / o que quiserem, mas isso não significa que eles os desejem imediatamente. Isso também não significa que eles os desejem sobre algum outro recurso conflitante. Então, você realmente precisa limitar quanto tempo gasta hoje planejando o futuro. Você precisa limitar especialmente quanto tempo gasta construindo coisas hoje que só serão úteis no futuro.

A pergunta que faço, que me mantém em linha reta e estreita, é "quanto mais difícil será criar esse recurso mais tarde do que agora criar suporte para esse recurso agora?" Normalmente, a resposta é que o esforço futuro é aproximadamente o mesmo ou talvez o dobro do que seria fazê-lo agora. Nesse caso, como não posso prever o futuro, não tenho nenhum problema em não construí-lo agora. Se a resposta chegar a 10x ou mais, começarei a perguntar sobre a probabilidade das pessoas pensarem que precisaremos disso nos próximos dois anos. Mesmo assim, a menos que haja um amplo acordo, eu me limitaria a garantir que não seja necessário desfazer as coisas que estamos fazendo hoje, a fim de alcançar esse objetivo no futuro.

Por exemplo, trabalhei em alguns projetos em que passamos muito tempo abstraindo o fato de que estávamos usando o Hibernate como acesso a dados posteriormente. (Nunca vi o projeto construído no Hibernate parar de usá-lo, portanto, foi um desperdício de tempo, mas vamos deixar isso de lado.) Mesmo que houvesse uma possibilidade razoável de querermos mudar mais tarde, porque também estávamos usando um padrão de objeto de acesso a dados, não seria mais difícil criar flexibilidade para mudar o Hibernate e alterá-lo ao mesmo tempo em que precisávamos do que criar flexibilidade desde o início. Diante de uma situação como essa agora, eu apenas adiaria ter essa flexibilidade até realmente precisarmos dela.

A menos que você esteja fazendo um planejamento estratégico para uma grande corporação, nem vale a pena pensar em questões de arquitetura a mais de dois ou três anos, porque a tecnologia está mudando muito rapidamente. O recurso que você pode estar pensando em construir hoje pode estar disponível gratuitamente em código aberto em dois ou três anos. Quase certamente a análise de custo-benefício terá mudado.

Limite-se a criar um sistema que faça o que você precisa hoje, do qual tenha orgulho e que terá prazer em trabalhar em alguns meses, independentemente da próxima rodada de mudanças. Realmente é o melhor que você pode fazer.

Aqui está o meu processo pessoal de eliminação de designs malucos que (em sua primeira versão) podem acabar sendo impraticáveis ​​e danificar um projeto da perspectiva dos negócios.

1. Identifique o epicentro : pense no seu projeto como uma barraca de cachorro-quente, o epicentro seriam os cachorros-quentes. Você pode retirar qualquer outro tempero / molho / vegetal do seu estande e ainda poder vender cachorros-quentes. Qual é o principal objetivo do seu software? Isole qualquer outra adição e / ou valor agregado dela e concentre-se primeiro no epicentro.
2. Continue repetindo para si mesmo "fazê-lo mais tarde significa melhor" : veja onde faz sentido e coloque um pouco de "para mais tarde". Se você fizer isso bem e pensando em seu uso no mundo real, terá o mesmo design, mas será priorizado em um roteiro.
3. Diminuir, desacoplar e descartar : qualquer que seja o design do módulo, você o torna o mais simples / essencial / puro / universal possível (às vezes isso pode ser realizado sem a necessidade de remover recursos). Quando você não puder simplificá-lo ainda mais, comece a dissociar os elementos que poderiam viver sozinhos e ter um objetivo. No final, se você ainda tiver um pouco de gordura, poderá cortá-la.
4. Separe "código de biblioteca" de "código de produção" : sempre haverá código que não pode ser reutilizado, mas sempre adiciona ruído ao design. Esse código é o que contém regras de negócios. Você verá que algumas vezes algumas regras de negócios são mais fáceis e rápidas de mudar ( extremamente importantes ) do que com um design robusto. Você encontrará códigos nos quais pode confiar e codificará o cliente para alterar ou reimplementar no futuro. Você deseja que eles sejam mantidos o mais separados possível.

E, BTW, o passo 0 é: "enlouqueça com o design". Isso me ajuda a tirá-lo do meu sistema e, muitas vezes, a encontrar novas implicações, requisitos ocultos e até recursos emergentes.

Tirei 1 e 2 do Rework .

Escreva os testes. Você termina quando todos os testes passam: não antes, e certamente não muito tempo depois, durante uma fase épica de excesso de engenharia. Ter um conjunto de testes para o código que você está escrevendo fornecerá um observador independente e imparcial, informando quando você pode parar.

Quando você é jovem, não vê risco (possivelmente o motivo pelo qual os políticos mais jovens são assustadores), mas à medida que envelhece, suas más experiências o paralisam a cada oportunidade (possivelmente o motivo pelo qual os políticos mais velhos estão estagnados). Adote a abordagem guiada por navalhas da Occam - escolha a solução que tem menos necessidades e depois evolua a partir daí.

Há apenas duas coisas que você realmente precisa ter em mente ao escrever e projetar software: manutenção e correção.

A correção é mais importante a curto prazo e pode ser facilmente comprovada por testes.

A manutenção ajudará mais tarde no desenvolvimento, mas é mais difícil de definir.

Minha estratégia atual é primeiro obter uma prova de conceito monolítica e depois separar a interface do usuário do modelo (garantindo que o modelo não saiba nada sobre a interface do usuário) assim que eu estiver convencido de que é viável. Se eu esperasse muito tempo por essa etapa, obteria algo insustentável. Se eu começar com as camadas separadas, simplesmente não consigo começar, pois fico preso ao que a interface do usuário precisa saber sobre o modelo.

Quando estou preso em situações como essas, descobri que ajuda teimosamente imaginar que sou um usuário final usando o programa hipotético para fazer algo razoavelmente trivial. Depois, tento me concentrar em quais seriam os pontos de entrada programáticos necessários para apoiar essas ações, tentando, o máximo possível, ignorar outros aspectos do sistema. A partir daqui, muitas vezes é possível construir uma (pequena!) 'Lista de recursos' do sistema acabado e escrever um código irrealista que começa a implementá-lo. Após esse exercício, geralmente começo e o resto do sistema começa a ficar mais claro. É tudo sobre o ponto de entrada - e o ponto de entrada da grande maioria de todos os softwares são as ações iniciais dos usuários finais de um programa.

Eu acho que é uma síndrome que as tarefas que você está fazendo sejam muito fáceis para você.

Alguns anos atrás, o desafio para você era escrever um código que cumprisse a tarefa em questão. Foi isso que envolveu totalmente sua mente. Agora, sua mente (sua experiência, etc.) está funcionando de maneira mais eficaz e a mesma tarefa requer apenas uma parte da energia necessária anteriormente. É por isso que você está terminando nessa espiral de pensamentos profundos. Sua mente está se defendendo da rotina e lutando por desafios.

Eu acho que você deveria considerar mudar seu trabalho. Talvez você deva aprender uma nova linguagem de programação.

Eu tive o mesmo problema há 15 anos. Eu queria escrever um código perfeito, reutilizável, universal, .... que tornasse a solução muito mais complicada do que o necessário. Hoje eu vejo isso como revestimento de ouro . O que me ajudou muito foi o conselho de um colega:

• se você tem uma idéia do que pode melhorar a funcionalidade, torne-a mais universal, ... escreva essa idéia em um arquivo de texto separado "ideas.txt", mas não implemente isso agora .
• continue implementando as tarefas urgentes.
• Após seis meses, revise suas "ideas.txt" e analise quais dessas mudanças realmente teriam beneficiado o projeto.

Isso é simplesmente paralisia por análise. Isso acontece com muitas pessoas em muitos campos. Você pode romper isso.

A resposta é - APENAS COMEÇA COM ELE ;-)

Eu publico em um fórum de fitness e muitas vezes as pessoas postam sobre diferentes rotinas, tentando encontrar o perfeito para elas. Por isso, dizemos a eles que comecem a treinar e trabalhem à medida que avança. Você quer ficar mais forte, fazer alguns exercícios de força e depois ajustar as coisas à medida que avança.

Quando você tem um programa grande e seu cérebro trabalha horas extras - basta codificar primeiro os casos simples. Inicialmente, o programa deve ser executado, deve receber informações, etc.
Seu desafio é deixar as coisas fáceis de atualizar e refatorar mais tarde, mas o código NÃO DEVE ser mais complicado do que o necessário para realizar a tarefa em questão.

Lembre-se de que no futuro é bom refatorar o código para atender às novas prioridades. Você não pode prever todos eles com antecedência, portanto, não tente.

Código para a próxima tarefa - SOMENTE. O código é simples e bom, por isso é fácil refatorar, se necessário. Verifique se o programa funciona. Repetir.

Como você está ficando "paralisado" ao pensar em possíveis cenários de caso de uso do usuário final, há algo a considerar aqui se você estiver publicando uma API e espera que pessoas desconhecidas utilizem essa API. Depois que uma API é publicada, você precisa continuar a suportá-la, mesmo depois de perceber o quão ruim é seu primeiro lançamento ou quebrar o código de todos, possivelmente desconhecidos por você, que escreveram contra ela, arriscando assim alienar para todo o tempo futuro.

A solução padrão é publicar com a estipulação de que a API pode mudar de qualquer forma a qualquer momento até que você tenha uma noção do que seus usuários precisam e que os consumidores da API estão fazendo.

Nessa solução, acho que é sua própria solução. Escreva apenas uma coisinha que faça uma ou duas coisas, talvez faça tudo bem, mantendo o entendimento de que tudo o que você fizer poderá mudar no futuro.

Não é possível acertar tudo ou, em alguns casos, mesmo QUALQUER, quando você começa, porque o design é realmente uma jornada de descoberta; é o último a surgir, não a primeira coisa a ser feita.

Você não pode criar uma API imediatamente e nunca precisará quebrá-la para seus consumidores. Você entende o porquê disso. Da mesma forma, você não pode escrever software e não precisa jogar tudo fora e começar de novo com uma nova abordagem.

Não acho que você tenha um problema no sentido de que acidentalmente evoluiu para algo menos criativo, produtivo ou desejável. Eu acho que você tem altos padrões que acidentalmente aplica incorretamente à sua situação - um erro comum em pensar que todo mundo faz.

A experiência nunca conta contra você, a menos que você se torne um sabe-tudo cínico, fez tudo, e isso realmente soa como o oposto de sua situação.

Tenho algumas imagens que tenho em mente quando fico grande. Um é brincar com Lego. Eu montei e desmontei à vontade. O que começo a fazer pode não ser o que acabo fazendo. Estou surfando e me aproveitando das possibilidades que vêm à minha mente, muitas vezes recriando meus objetivos totalmente no local em um flash de inspiração ... é isso que é a criatividade.

A outra imagem é uma analogia que ouvi descrever a ciência real. Você está tateando em um quarto escuro à procura de um gato preto que pode não estar lá. É irritante apenas se você se considerar um fracasso por não encontrar esse gato. Não há outra maneira de encontrar gatos pretos. Essa é a única atividade que os localiza. Qualquer outra coisa é alguma forma de já ter o que você está procurando.

Você não sabe muito; você não sabe o suficiente! E você só percebeu isso recentemente.

Não pense nas suas escolhas de design como algo que você precisa "acertar", porque não há "certo" - existem muitos "erros", mas também existem desvantagens (em velocidade de execução, tempo para concluir a codificação) tarefa, extensibilidade etc.). O código que você escreve se bem concebido ainda terá vários pontos fortes e fracos.

O objetivo deve ser chegar ao ponto em que entender esses pontos fortes e fracos no contexto do uso e manutenção atuais e futuros não seja muito mais difícil do que escrever código em primeiro lugar.

Portanto, não evite pensamentos profundos, mas lembre-se de que você precisa de experiência, não apenas pensamento, para se tornar um mestre nesse tipo de design. Pense até chegar a um ponto em que não tenha certeza de uma escolha específica, depois implemente o que você espera que seja o melhor, tente e aprenda como foi.

Pratique a codificação. Crie exercícios ou encontre-os online e tente finalizá-los corretamente o mais rápido possível. Quando você acelerar, adicione considerações como manutenção e desempenho. Você perceberá que é refrescante o código que não entra em produção e pode ajudá-lo a sair do seu medo de codificar.

Faça codificação no seu tempo livre, como você fez há 10 anos, com menos preocupações e apenas diversão.

Torne-se gerente de equipe e direcione desenvolvedores mais jovens - que agora estão no mesmo estado mental que você estava há 10 anos.

Não, você ainda não sabe o suficiente.

Enriqueça seu conhecimento, por exemplo, por estas regras simples:

• BEIJO: Mantenha pequeno e simples.
• YAGNI: Você não vai precisar.
• Pior é melhor: algumas soluções piores são realmente melhores em termos de manutenção.

Não overengineer. Esteja pronto para a mudança com habilidades de refatoração, mas não codifique todas as alterações possíveis no código. Se você perceber que, com o tempo, uma classe ou função cresce muito, altere-a. Dividir e conquistar. Use interfaces, use mais funções. Se você acha que dividiu demais (ou seja, ficou mais extravagante, mas menos legível), desfaça sua última alteração.

Em resumo: torne seu código flexível o suficiente, mas não mais. Em vez disso, torne-se flexível, compre um livro sobre refatoração.

Duas coisas:

1. Não basta saber muito. Você precisa ter opiniões sobre o que vale a pena implementar. Pessoalmente, vejo o TDD como uma muleta que permite uma arquitetura ruim. Dada a enorme quantidade de opinião popular que funciona contra mim nisso, eu provavelmente estou errado, mas a implementação do TDD no JavaScript não é um problema que eu tenha em mente, porque a depuração nunca foi uma grande dor de cabeça para mim e ei, não seria a primeira vez que a opinião popular na comunidade de desenvolvimento seria vista mais tarde como falha anos depois. Então aprenda a ser um idiota arrogante. Pelo menos por dentro. Você pode estar errado, mas pelo menos se comprometer com coisas que funcionam para você, em vez de pensar demais em coisas que talvez não funcionem.

2. Parece que você está começando com o micro. Comece com macro. Primeiro, as ferramentas necessárias para fazer o que seu aplicativo precisa. Essa parte deve vir com bastante facilidade. Comece com as preocupações de arquitetura / interface. Como o encanamento se conecta e ao que ele se conecta deve realmente ser apenas os fragmentos frágeis em cima de tudo que você pode simplesmente deslizar para o lado e substituir por um capricho. Da mesma forma com os detalhes de como as coisas são feitas. Embrulhados adequadamente, estes podem ser substituídos / editados com facilidade.

mas toda vez que tento atacá-lo, acabo espiralando em pensamentos profundos

Não há nada errado. Você só percebeu que é hora de melhorar seu processo: neste caso, seu processo de pensamento.

Muitas pessoas se perdem na análise ou se desviam de outras maneiras e nem percebem. Você notou que pode mudar seu processo de raciocínio para permanecer no caminho certo.

Existem muitas soluções para isso, e a melhor que eu já vi acima é definir uma restrição de tempo. Antes de começar, decida quanto tempo (1 hora?) Você dedicará a analisar e pensar sobre isso. Defina um cronômetro.

Então, quando o timer disparar, inicie a codificação. Se você estiver pensando nas coisas por muito tempo novamente, tome uma decisão instantânea. Tudo o que você decide naquele momento é a decisão correta. Você sempre pode fazer alterações e melhorias posteriormente.

Além disso, nosso ambiente está sempre mudando. Muitas vezes, precisamos atualizar nosso código para lidar com novos requisitos, novas tecnologias, novo hardware, idioma e atualizações do sistema, etc.

Sim, esse horror de codificação acontece até para mim. Ficar impressionado com o Stack Overflow. Codificação em detalhes para um pequeno aplicativo. Mas quando é um projeto terceirizado, ele não consome muito tempo por causa de restrições de tempo. E também trabalhar com um grupo de novas pessoas pode superar isso, eu acho.

Você não é cruel o suficiente

http://playswithfire.com/blog/2012/02/19/you-are-not-ruthless-enough/

Edit: O objetivo deste artigo é prestar atenção a pequenos detalhes durante o desenvolvimento, mas descobri que ajuda a abordar qualquer tarefa simples ou complexa com uma atitude implacável, a fim de encontrar a solução mais eficiente possível e apenas fazer o trabalho.