Preso devido a "saber demais" [fechado]

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

Uma abordagem que funciona muito bem (especialmente com 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 engenharia excessiva. A maioria das mudanças de desempenho ou arquitetura que você está contemplando provavelmente não serão necessárias de qualquer maneira, então não se incomode em escrevê-las até que elas se tornem necessárias. Por exemplo, não se preocupe com o desempenho até que um profiler 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 em quanto tempo você pensa em algo antes de escrever o código. Na maior parte do tempo, o código ficará melhor se você pensar um pouco, escrever, perceber seus erros e corrigi-los refatorando.

Existe um saldo a ser atingido aqui. Você não deve simplesmente pular de cabeça e não pensar nas consequências, mas também não deve tentar fazer engenharia excessiva no código.

A Wikipédia o nomeia "Paralisia da análise" no software. A receita é seguir metodologias ágeis. Significa que qualquer atividade ou ação individual tem muito mais valor do que tentar estabelecer práticas ou políticas. Todo colaborador na equipe é valioso, não importa quão bem ou mal as habilidades da pessoa se encaixem nos ideais arquitetônicos. Em ágil, indivíduos, 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 o quão imperfeita e ineficiente você e a equipe se sintam. Talvez as primeiras ações possam estar desmantelando políticas inadequadas.

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

Is this wrong? Is this a natural evolution, or did I drive myself into a rut?

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 superengenharia do inferno de tudo, perceba que YAGNI
3. Prepare-se em um meio-termo pragmático, onde as coisas fáceis são colocadas juntas e as coisas difíceis / com provável mudança recebem engenharia suficiente para tornar mais fácil trabalhar com / alterar.

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

Uma das coisas que sempre gosto de ter em mente é o ditado "o futuro não é 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 vão querer imediatamente. Isso também não significa que eles vão querer mais algum outro recurso conflitante. Então você realmente precisa limitar quanto tempo você gasta hoje planejando para o futuro. Você precisa especialmente limitar quanto tempo você gasta criando coisas que só serão úteis no futuro.

A pergunta que eu faço e que me mantém no caminho certo é "quanto mais difícil será construir esse recurso mais tarde do que construir suporte para esse recurso agora?" Normalmente, a resposta é que o esforço futuro é aproximadamente o mesmo ou talvez o dobro do que seria fazer agora. Nesse caso, porque não posso prever o futuro, não tenho problema em não construí-lo agora. Se a resposta chegar a 10x ou mais, começarei a perguntar sobre a probabilidade de as pessoas pensarem que precisaremos disso no próximo ano ou dois. Mesmo assim, a menos que haja amplo consenso, eu simplesmente me limitaria a garantir que não fosse necessário desfazer as coisas que estamos fazendo hoje para atingir esse objetivo no futuro.

Por exemplo, trabalhei em alguns projetos em que gastamos muito tempo abstraindo o fato de que estávamos usando o Hibernate como um acesso de dados mais tarde. (Nunca vi o projeto construído no Hibernate parar de usá-lo, então isso foi uma perda de tempo para começar, mas vamos deixar isso de lado.) Mesmo que tenha sido uma possibilidade razoável podermos querer 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 a flexibilidade de alterar o Hibernate e alterá-lo ao mesmo tempo em que precisávamos dele do que criar a flexibilidade desde o início. Diante de uma situação como essa agora, eu apenas deixaria de ter essa flexibilidade até que realmente precisássemos dela.

A menos que você esteja fazendo planejamento estratégico para uma grande corporação, dificilmente vale a pena pensar em questões arquitetônicas a mais de dois ou três anos, porque a tecnologia está mudando tão 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 construir um sistema que faça o que você precisa hoje, de que você tenha orgulho, e que você ficará feliz 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 para projetos incríveis que (em sua primeira versão) podem acabar sendo impraticáveis e danificar um projeto do ponto de vista comercial.

1. Identifique o epicentro : Pense no seu projeto como uma barraca de cachorro-quente, o epicentro seriam os cachorros-quentes. Você pode tirar todos os outros temperos / molhos / vegetais do seu stand e ainda assim vender cachorros-quentes. Qual é o objetivo principal do seu software? Isole cada outra adição e / ou valor acrescentado e concentre-se primeiro no epicentro.
2. Continue repetindo para si mesmo "fazer isso depois significa melhorar" : veja onde faz sentido e coloque um pouco "para depois". Se você fizer isso bem e pensar em seu uso no mundo real, você terá o mesmo design, mas terá prioridade em um roteiro.
3. Diminish-Decouple-Discard : Qualquer que seja o design do módulo, você pode torná-lo o mais simples / essencial / puro / universal possível (às vezes isso pode ser feito sem remover recursos). Quando você não pode simplificá-lo ainda mais, inicie o desacoplamento de elementos que poderiam viver por si mesmos e ter uma finalidade. No final, se você ainda tiver alguma gordura, poderá cortá-la.
4. Separar "código da biblioteca" de "código de produção" : sempre haverá código que não pode ser reutilizado, mas sempre adiciona ruído ao design. Este código é aquele que contém regras de negócios. Você descobrirá que às vezes algumas regras de negócios são mais fáceis e rápidas de alterar ( extremamente importante ) do que com um design robusto. Você encontrará o código em que pode confiar e codificará as necessidades do cliente para alterar ou reimplementar no futuro. Você vai querer que eles sejam mantidos o mais separados possível.

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

Eu peguei 1 & 2 de Retrabalho .

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

Existem 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 separar a interface do usuário do modelo (garantindo que o modelo não saiba nada sobre a interface do usuário), uma vez que estou convencido de que é viável. Se eu esperasse muito por esse passo, conseguiria algo insustentável. Se eu começar com as camadas separadas, simplesmente não consigo começar, pois fico preso no que a interface do usuário precisa saber sobre o modelo.

Quando estou preso em situações como essas, descobri que é teimoso imaginar que sou um usuário final usando o programa hipotético para fazer algo razoavelmente trivial. Então eu tento me concentrar no que os pontos de entrada programáticos necessários para suportar essas ações seriam, tentando, tanto quanto possível, ignorar outros aspectos do sistema. A partir daqui, muitas vezes é possível construir uma (pequena!) 'Lista de whish' de recursos do sistema finalizado, e escrever algum código irreal que inicie para implementá-lo. Depois desse 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 dos softwares são as ações iniciais dos usuários finais com um programa.

Eu acho que é uma syndrom que as tarefas que você está fazendo são muito fáceis para você.

Há alguns anos, o desafio para você foi escrever um código que cumprisse a tarefa dada. Foi isso que envolveu totalmente sua mente. Agora, sua mente (sua experiência, etc.) está trabalhando mais eficaz e fazer a mesma tarefa requer apenas uma parte da energia que era necessária anteriormente. É por isso que você está terminando nessa espiral de pensamentos profundos. Sua mente está se defendendo da rotina e está lutando pelo desafio.

Acho que você deveria pensar em mudar seu trabalho. Talvez você devesse 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 vejo isso como Gold plating . O que me ajudou muito foi um conselho de um colega:

• se você tiver uma ideia do que pode melhorar a funcionalidade, torná-la mais universal, ... anote essa ideia em um arquivo de texto separado "ideas.txt", mas não implemente isso agora .
• continue implementando as tarefas urgentes.
• após seis meses, revise seu "ideas.txt" e analise quais dessas mudanças realmente beneficiariam o projeto.

Isto é simplesmente paralisia por análise. Acontece com muitas pessoas em muitos campos. Você pode passar por isso.

A resposta é: APENAS SE ENCONTRE COM ELE; -)

Eu faço postagens em um fórum de fitness e muitas vezes as pessoas postam sobre rotinas diferentes, tentando encontrar o nome perfeito para elas. Então, dizemos a eles que comecem a treinar e trabalhem conforme você avança. Você quer ficar mais strong, fazer alguns exercícios de força e, em seguida, ajustar as coisas à medida que avança.

Quando você tem um programa grande e seu cérebro trabalha horas extras - apenas codifique primeiro os casos simples. Inicialmente, o programa deve ser executado, depois deve ser inserido etc. Seu desafio é deixar as coisas mais 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.

Lembre-se, no futuro, de refatorar código para atender a novas prioridades. Você não pode prever todos eles na frente, então não tente.

Codifique a próxima tarefa - SOMENTE. O código é simples e bom, então é fácil refatorar se você precisar. Verifique se o programa funciona. Repita.

Como você está ficando "preso" ao pensar em possíveis cenários de casos de uso do usuário final, há algo a considerar aqui se você for publicar uma API e esperar que pessoas desconhecidas utilizem essa API . Uma vez que uma API é publicada, você tem que continuar a apoiá-la, mesmo depois de perceber o quão ruim é seu primeiro lançamento, ou você tem que quebrar o código de todos, possivelmente desconhecido para você, que escreveu contra ele, arriscando alienar -los para todo o tempo futuro.

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

Naquela solução, acho que é sua própria solução. Escreva apenas uma coisinha que faça uma ou duas coisas, talvez faça com que eles fiquem bem, mantendo o entendimento para si mesmo de que qualquer coisa que você faça pode mudar no futuro.

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

Você não pode criar uma API imediatamente e nunca precisa dividi-la entre seus consumidores. Você entende porque é isso. Da mesma forma, você não pode escrever software e não ter que jogar tudo fora e começar de novo com uma nova abordagem.

Eu não acho que você tenha um problema no sentido de ter evoluído acidentalmente para algo menos criativo, produtivo ou desejável. Eu acho que você tem altos padrões que você está acidentalmente aplicando mal a 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 cínico sabe-tudo, feito-tudo, e isso realmente soa como o oposto da sua situação.

Eu tenho algumas imagens que eu mantenho em mente quando fico grande. Um é jogar com o Lego. Eu coloquei tudo junto e desmontei à vontade. O que eu começo a fazer pode não ser o que acabo fazendo. Eu estou surfando e me beneficiando das possibilidades que vêm à minha mente à medida que vou junto, muitas vezes recriando meus objetivos inteiramente no local em um flash de inspiração ... é isso que a criatividade é.

A outra imagem é uma analogia que ouvi descrever descrevendo a verdadeira ciência. Você está tateando em um quarto escuro para um gato preto que pode não estar lá. É enervante só se você se considera um fracasso por não encontrar o gato. Não há outra maneira de encontrar gatos pretos. Essa é a única atividade que os localiza. Qualquer outra coisa é alguma forma de ter o que você supostamente está procurando.

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

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

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

Pratique a codificação. Crie exercícios ou encontre-os on-line e tente terminá-los corretamente o mais rápido possível. Quando você aumentar sua velocidade, adicione considerações como manutenção e desempenho. Você perceberá que é interessante codificar as coisas que não entram em produção e isso pode ajudá-lo a sair do medo de codificação.

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

Torne-se um gerente de equipe e direto 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:

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

Não overengineer. Prepare-se 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 fica muito grande, altere-a. Dividir e conquistar. Use interfaces, use mais funções. Se você acha que se dividiu demais (ou seja, tornou-se mais sofisticado, mas menos legível), desfaça sua última mudança.

Em resumo: torne o 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 é suficiente saber muito. Você tem que ter opiniões sobre o que vale a pena implementar. Eu pessoalmente vejo o TDD como uma muleta que permite uma arquitetura ruim. Dada a enorme quantidade de opinião popular que funciona contra mim sobre isso, eu provavelmente estou errado, mas se implementar TDD em JavaScript não é um problema que eu coloquei em qualquer pensamento, porque a depuração nunca foi uma dor de cabeça enorme para mim e hey, não seria a primeira vez que a opinião popular na comunidade de desenvolvimento seria mais tarde vista 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 em coisas que podem não funcionar.

2. Parece que você está começando com o micro. Comece com macro. Primeiro, as ferramentas de que você precisa para fazer o que seu aplicativo precisa fazer. Essa parte deve ser fácil. Em seguida, comece com as preocupações de arquitetura / interface. Como o encanamento se conecta e ao que ele se conecta deve ser apenas os bits 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. Embrulhado corretamente, estes podem ser substituídos / editados com facilidade.

but every time I try to attack it, I end up spiraling in deep thoughts

Não há nada errado. Você só percebeu que é hora de melhorar seu processo: nesse caso, seu processo de raciocínio.

Muitas pessoas se perdem na análise ou se desviam de outras maneiras e nem percebem isso. Você percebeu 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 é a restrição de tempo. Antes de começar, decida quanto tempo (1 hora?) Você dedicará a analisar e pensar sobre isso. Definir um temporizador.

Então, quando o temporizador se apagar, inicie a codificação. Se você estiver pensando em coisas por muito tempo novamente, basta tomar uma decisão instantânea. O que quer que você decida naquele momento é a decisão correta. Você sempre pode fazer alterações e melhorias mais tarde.

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

Sim, esse horror codificante acontece mesmo para mim. Ficando atingido com o Stack Overflow. Codificando em detalhes para uma pequena aplicação. Mas quando é um projeto terceirizado, não consome muito tempo devido a restrições de tempo. E também trabalhar com um grupo de novas pessoas pode superar isso, eu sinto.

You Are Not Ruthless Enough

link

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