Meu design proposto é geralmente pior do que o do meu colega - como melhorar? [fechadas]

Acho que isso é um sinal muito positivo de suas habilidades. É muito mais comum que as pessoas que têm dificuldade em criar o design 'melhor' em uma equipe sejam completamente incapazes de reconhecer por que outro design é melhor.

Você tem dois pontos strongs muito bons (e surpreendentemente incomuns) para você:

• Você é capaz de avaliar seus projetos em relação a outros objetivamente
• Você tem o desejo e se esforça para tornar seus projetos ideais

Você está há apenas alguns anos e tem um longo caminho a percorrer, mas com essa atitude você definitivamente chegará lá, apenas não desista; Todos nós lidamos com retrocessos mentais como este. Sempre que tenho uma chance, gosto de ligar Princípios de Design (NÃO é o mesmo que os padrões de design ) e eu acho que este é um exemplo perfeito de onde eles vêm a calhar. Estude-os e pratique-os em seus projetos, antes que você perceba que deu mais um passo nesse sentido.

No final do dia, lembre-se, projetar é difícil. Estamos lidando com abstrações complexas de alto nível todos os dias, para criá-las do nada, para que funcionem bem e fáceis de usar pelos colegas é uma tarefa extremamente difícil. Isso requer prática, por anos .

Editar:
Depois de dar uma olhada em princípios e praticar um pouco a sua aplicação, eu acho que há outra jóia de outra questão aqui falando sobre o valor de estudar uma variedade de linguagens que têm diferentes propósitos e regras:

Ideally, every programmer should know a language from each class. What could you learn:

1. A static typed OOP mainstream language: Java, C# (mostly used in enterprise software) and C++ (system programming and complex desktop applications)
2. A prototype-based OOP language: Javascript (client side web programming)
3. A procedural language: C (embedded software and system programming)
4. A functional language: Haskell, ML or Lisp (functional languages are good for highly parallelized software).

A logic programming language (Prolog) probably is not that useful in industry, being used mostly in research in AI.

Isso ajudará a ampliar a variedade de ideias que vêm à mente ao tentar criar uma solução.

1. Isso é absolutamente normal para várias pessoas criarem designs de qualidade diferente. Eu fui convidado no passado para julgar concursos em design de software, então eu testemunhei isso em primeira mão: até mesmo os designs mais simples resultaram em soluções de qualidade drasticamente diferentes, todas provenientes de pessoas inteligentes e experientes.
2. A leitura do código-fonte é de nível muito baixo para ajudar você a melhorar suas habilidades de design: a complexidade dos endereços de código no nível inferior ao design geral.

A melhor maneira de melhorar o design do software é projetar o software ^* . Uma maneira de fazer isso é observar as competições de design: o TopCoder tem um arquivo com mais de 100 designs de componentes, completo com documentação de projeto UML e implementações em Java e / ou C #. Pegue um componente pronto que você goste, leia a especificação de requisitos e tente criar um design original para atender aos requisitos. Passe uma ou duas horas pensando no problema e desenhando um diagrama de classes, abra o design vencedor e leia o que o autor fez. Compare o seu design ao seu, identifique as diferenças e veja se o seu design é melhor. Verifique o scorecard da competição para ver como os juízes avaliaram o projeto. Isso lhe dará o feedback de que você precisa para decidir como melhorar suas habilidades de design.

Bem, não desista do seu trabalho. É melhor trabalhar com alguém que tenha habilidades melhores do que você, para que você possa aprender com ele ou ela.

Veja o melhor design e determine por que ele é melhor. Liberte-se do design aceito e pense em maneiras de aplicar um design semelhante em outras situações. Uma vez que você sabe por que é melhor do que o seu design, então você sabe o que não deve fazer na próxima vez que fizer um design. Converse com o outro desenvolvedor e pergunte como ele criou o design.

Para melhorar as habilidades de design, a melhor coisa a fazer é criar projetos, depois ser brutal consigo mesmo ao avaliá-los e determinar como eles podem ser melhorados. Faça a si mesmo perguntas como: Será que vai funcionar e atende ao requisito em todos os aspectos, é sustentável, como poderei testar isso, vai causar problemas de desempenho, qual a probabilidade de mudança e quão bem será o design? ser capaz de lidar com a mudança. Leia sobre padrões de design e tente aplicá-los aos seus projetos. Refatore impiedosamente depois de criar um design inicial. Se você estiver projetando um banco de dados junto com o aplicativo, leia bastante sobre normalização e ajuste de desempenho do banco de dados, aprenderá muito sobre design de banco de dados se aprender como fazer um banco de dados funcionar de maneira mais eficiente e eficaz. Para as aplicações, pense nos princípios DRY e SOLID ao fazer o seu design. Leia sobre antipadrões para saber o que evitar.

Reconhecer um design melhor é uma habilidade importante. Você deve promover isso ao seguir algumas das sugestões anteriores sobre a observação de designs.

Em que critérios você julgou melhor o outro design? Era mais simples e mais fácil de entender? Isso proporcionou uma vantagem no desempenho? Foi mais extensível? Existem muitos princípios de design, como decomposição, abstração, ocultação de informações e modularidade de componentes, que você pode usar para avaliar projetos e que você já pode reconhecer.

• Tente nomear seus critérios, entendê-los, expandi-los e reutilizá-los ao analisar outros designs. Quando você cria as coisas sozinho, faça parte do seu processo usar esses critérios e medir conscientemente seus projetos contra eles. Então, esteja preparado para modificar completamente ou descartar seu design se ele não atender aos seus critérios.

Você terá ideias sobre princípios diferentes para projetos de algumas das seguintes fontes: link Design de software na wikipedia Google "Princípios de design de software"

• Entenda modelos diferentes para design de software, como Design Orientado a Objetos ou Design Funcional ou Design de Análise Estruturada. Estes podem ser mentalidades totalmente diferentes para abordar uma tarefa de design e cada um deles tem áreas onde eles se destacam. Aprenda isso como ferramentas para sua caixa de ferramentas. link

• Verifique se você está separando o design da implementação, tente diagramar as coisas que você vê como bons designs, para separar as especificidades de linguagem e implementação dos princípios de design de nível superior. E para desenvolver seu "olho de design" e habilidades de comunicação.

• Por último, mas talvez o mais importante, ler amplamente é uma ferramenta muito boa - há muitas coisas interessantes, desde a análise Bayesiana até a lógica fuzzy e o processamento de linguagem natural, que podem fornecer informações para as idéias que surgirão mais tarde. inesperadamente. Com a web, você pode ler tópicos em toda parte, apenas para sua diversão e edificação, e ela se beneficiará. Você não precisa se tornar especialista, apenas familiarizado com termos e ideias.

Divirta-se - não faça isso se você não gostar nem um pouco!

Bem, você já deu o primeiro passo. Você admite que tem algo a aprender, que o trabalho do seu colega é melhor que o seu e quer aprender e melhorar.

O segundo passo é analisar. Olhe para o trabalho dele e não diga apenas que é melhor; descobrir porque é melhor. Procure por detalhes específicos e pontos que ele fez melhor.

Depois de entender isso, extraia os princípios por trás dele. Faça perguntas como estas:

• E esse design é melhor que meu design?
• Este ponto é específico para esse design, ou é um princípio geral que poderia ser aplicado a outros designs no futuro?
• Se é um princípio geral, quais são seus limites? Quando é uma boa ideia não fazer as coisas desta maneira? (Este é muito importante. Ele impede que você trate alguma idéia útil como um golden hammer , mesmo em casos inapropriados.)

Tente descobrir as coisas por conta própria, porque você internalizará melhor as ideias se tiver uma cadeia de raciocínio que o tenha levado à conclusão, mas também converse com seu colega de trabalho para garantir está fazendo as coisas direito. (Você não quer cometer erros no seu raciocínio e internalizar um princípio ruim, afinal.) E sinta-se à vontade para pedir ajuda ao seu colega de trabalho, caso não consiga descobrir as coisas. A programação é uma disciplina onde a humildade tende a ser respeitada, e muitos codificadores aproveitarão a chance de ensinar algo novo a alguém, o que provavelmente é uma grande parte do motivo pelo qual o StackOverflow ficou tão grande tão rápido.

Eu também gostaria de acrescentar (além das ótimas respostas) que existe mais do que "Ele pode criar um design melhor que eu". As outras respostas se concentram em como você pode melhorar no Design, o que é bom e tudo o mais ... mas ...

Aposto que você pode fazer algo melhor que seu colega de trabalho. Não para criar um jogo de puta ou qualquer coisa (você pode fazer melhor para você? Dane-se, eu posso fazer X melhor!), Mas para mostrar a verdade que todos têm pontos strongs e fracos.

No meu trabalho, existem 4 desenvolvedores. Há momentos em que os dois "programadores" principais podem criar coisas que me deixam na poeira. Faz minha cabeça girar tentando envolver minha cabeça em torno de suas criações.

Mas eu sou muito melhor em scripts de SQL e de linha de comando do que eles, e posso automatizar coisas que os deixam na poeira.

Eles são melhores que eu? Em alguma área definitivamente. Inferno, em um monte de área eles são - eu sou o desenvolvedor júnior na minha loja de longe e individualmente eles têm anos de experiência em mim. Apesar desses anos de experiência, eu sou melhor em algumas áreas do que elas são.

Pare de se concentrar no fato de que alguém é melhor em X do que você. Essa pessoa, sem tentar ou mesmo pensar sobre isso, pode ser capaz de projetar você mesmo depois de praticar nos próximos 10 anos. Não que você não deva trabalhar para consertar suas fraquezas, mas lembre-se que, para cada força, existe uma fraqueza.

Concentre-se em ambos - pontos strongs e fracos - de você e seus colegas de trabalho.

Em todos os aspectos da vida você encontrará pessoas que não são tão boas quanto você, assim como pessoas que são melhores que você, especialmente depois de apenas "alguns anos" de experiência.

Você precisa aprender com todos.

Não se sinta mal. Talvez você colega seja natural. Você deve parabenizá-lo sinceramente e aprender o máximo que puder com ele.

Não deixe que profissionais ciosamente fiquem entre você e uma oportunidade de aprender.

1. Um par de anos realmente não é muito. E há pessoas com melhores ou piores visões de design de alto nível. Por exemplo, eu conheço pessoas capazes de escrever algoritmos complexos para programas de baixo nível em um piscar de olhos, mas incapazes de entender design de nível superior e conceitos como coesão e dependências. No entanto, este não é um estado de fato. Tanto você pode ficar melhor em um design de nível superior (ler alguns livros, tentar alguns truques em casa, etc) e também você pode descobrir que em outras áreas da programação seu colega programador é menos bom. Além disso, se você acha que está no mesmo nível tanto em experiência quanto em conhecimento técnico, isso pode ter tido uma situação aleatória. Da próxima vez, talvez você tenha melhores ideias de design. Além disso, em vez de deixar seu emprego, aproveite esta oportunidade e aprenda com seu colega. Da próxima vez, faça um design juntos, tente pegar seus segredos, seus pensamentos. A programação é como um ofício, é aprendida fazendo e observando os outros.

2. As habilidades de design vêm principalmente com experiência e depois de ler alguns livros importantes. Eu recomendaria os seguintes:

   • Robert C. Marting - Princípios Ágeis, Padrões e Práticas (existem 2 versões, uma em Java e outra em C #. Não importa qual você escolher, as idéias e princípios podem ser aplicados a qualquer objeto orientado - e não apenas - código fonte)
   • Than, Robert C. Marting tem 2 outros livros interessantes: Clean Code e The Clean Coder
   • Mesmo que Martin cubra todos os padrões de design moderno em seu primeiro livro, você quer procurar o livro de padrões de design original da Gang of Four.
   • Finalmente, há outros livros que são altamente valorizados hoje: Software Orientado a Objetos em Desenvolvimento Guiado por Testes, ou Refatoração por M. Feathers (eu acho), ou Escrevendo Casos de Uso Eficaz por A. Cockburn e mais alguns você descobrirá em o caminho.

Nenhum desses livros é uma mágica, mas ler as duas primeiras recomendações provavelmente mudará sua visão e percepção sobre programação para sempre.

Não deixe que isso chegue até você. Se você tem anos de experiência corrigindo bugs e fazendo pequenos programas, é nisso que você se destacará. Seu colega de trabalho provavelmente tem anos de experiência na criação de projetos maiores.

Estar familiarizado com os bits subjacentes é incrivelmente útil, mas se você quiser melhorar no design, terá que criar alguns projetos. Repita até que a habilidade afunde.

Em resumo, "anos de experiência" nem sempre são equivalentes. Vá fazer seus anos valerem alguma coisa.

"Melhorar" muitas vezes implica medir seus projetos ou código contra algo / alguém melhor, comparar cuidadosamente o que é diferente, aprender com essas diferenças e tentar melhorar continuamente seus projetos futuros com base nisso. Sentir-se muito mal em descobrir que você precisa aprender mais irá retardar esse processo benéfico. Se você for para algum lugar onde não haja pessoas (ou outros recursos) que possam, às vezes ou sempre, fornecer uma comparação melhor, poderá perder essa oportunidade de aprender e desacelerar seu processo de apostar melhor.