Como codificar mais rapidamente (sem sacrificar a qualidade) [fechado]

144

Sou codificador profissional há vários anos. Os comentários sobre meu código geralmente são os mesmos: escreve um ótimo código, bem testado, mas poderia ser mais rápido .

Então, como me torno um codificador mais rápido, sem sacrificar a qualidade? Para fins de pergunta, vou limitar o escopo ao C #, já que é basicamente isso que eu codifico (por diversão) - ou Java, que é bastante semelhante em muitos aspectos importantes.

Coisas que eu já estou fazendo:

  • Escreva a solução mínima que fará o trabalho
  • Escreva uma série de testes automatizados (evita regressões)
  • Escreva (e use) bibliotecas reutilizáveis ​​para todos os tipos de coisas
  • Use tecnologias conhecidas onde elas funcionam bem (por exemplo, Hibernate)
  • Use padrões de design onde eles se encaixam no lugar (por exemplo, Singleton)

Tudo isso é ótimo, mas não sinto que minha velocidade esteja aumentando com o tempo. Eu faço cuidado, porque se eu puder fazer algo para aumentar a minha produtividade (até 10%), que é 10% mais rápido do que meus concorrentes. (Não que eu tenha.)

Além disso, eu sempre recebi esse feedback dos meus gerentes - fosse em desenvolvimento em pequena escala do Flash ou em desenvolvimento Java / C ++ corporativo.

Edit: Parece haver muitas perguntas sobre o que quero dizer com rápido, e como sei que sou lento. Deixe-me esclarecer com mais alguns detalhes.

Trabalhei em equipes pequenas e médias (5-50 pessoas) em várias empresas em vários projetos e tecnologias (Flash, ASP.NET, Java, C ++). A observação dos meus gerentes (que eles me disseram diretamente) é que sou "lenta".

Parte disso ocorre porque um número significativo de meus colegas sacrificou a qualidade pela velocidade; eles escreveram códigos com erros, difíceis de ler, difíceis de manter e difíceis de escrever para testes automatizados. Meu código geralmente é bem documentado, legível e testável.

Na Oracle, eu solucionava os bugs de forma consistente mais lentamente que os outros membros da equipe. Eu sei disso, porque gostaria de receber comentários nesse sentido; isso significa que outros desenvolvedores (sim, mais seniores e experientes) poderiam fazer meu trabalho em menos tempo do que o necessário, com quase a mesma qualidade (legibilidade, capacidade de manutenção e testabilidade).

Por quê? o que estou perdendo? Como posso melhorar nisso?

Meu objetivo final é simples: se eu posso fabricar o produto X em 40 horas hoje, e posso me aperfeiçoar de alguma forma para poder criar o mesmo produto às 20, 30 ou até 38 horas amanhã, é isso que eu quero saber - como eu chego lá? Que processo posso usar para melhorar continuamente? Eu pensei que era sobre reutilizar código, mas isso não é suficiente, ao que parece.

cinza
fonte
4
Os outros codificam mais rápido que você na mesma qualidade? Caso contrário, aponte para seus registros de manutenção e relatórios de erros para indicar que a velocidade não é um problema.
Michael K
11
Para tentar ganhar a corrida, alguns escolherão seus cavalos mais rápidos e vencê-los para ir mais rápido. Alguma pergunta?
Paul
24
Não tenho uma resposta para você, mas tenho algo que pode fazer você se sentir melhor. Por mais lento que você seja como programador, por mais ineficiente que seja, seu gerente é muito, muito pior. Que tipo de idiota diz: "Ei, Bob, você é muito lento" sem ajudá-lo a melhorar? Pode muito bem dizer que você é muito baixo. Isso não é liderança, é apenas incômodo. Acho que tenho uma sugestão: encontre um emprego com um gerente competente, alguém que trabalhe com você para superar suas deficiências.
Malvolio
11
Todas as respostas me deixam infeliz. Se você quer apenas o passo noob-> medíocre, talvez fazer uma coisa esteja bem. Mas medíocre-> especialista sempre exige aprender tudo. Você precisa aprender o seu VCS, seu editor, sua linguagem de programação e suas estruturas em profundidade. Você precisa repetir etapas difíceis e interessantes que podem ser executadas sem pensar. E então você precisa encontrar uma maneira de aplicar o contexto, como a diferença entre as necessidades do cliente e as necessidades do seu colega de trabalho, como o seu humor diário influencia sua capacidade de codificar / projetar / discutir. Se você quer uma coisa, faça o seguinte: aprenda tudo.
Erikbwork

Respostas:

158

Gosto da abordagem de Jeff Atwood para isso, que pode ser encontrada aqui http://www.codinghorror.com/blog/2008/08/quantity-always-trumps-quality.html .

Basicamente, no artigo, ele faz referência a uma passagem do livro Art & Fear, de David Bayles e Ted Orland. A passagem diz:

O professor de cerâmica anunciou no dia da abertura que estava dividindo a turma em dois grupos. Todos os que estavam no lado esquerdo do estúdio, disse ele, seriam classificados apenas na quantidade de trabalho que produziram, todos aqueles no lado direito apenas em sua qualidade. Seu procedimento era simples: no último dia de aula, ele trazia suas balanças de banheiro e pesava o trabalho do grupo "quantidade": cinquenta libras de panelas com classificação "A", quarenta libras com "B" e assim por diante. Aqueles classificados em "qualidade", no entanto, precisavam produzir apenas um pote - ainda que perfeito - para obter um "A". Bem, chegou a hora da classificação e surgiu um fato curioso: os trabalhos de mais alta qualidade foram todos produzidos pelo grupo avaliado por quantidade. Parece que enquanto a "quantidade"

Essencialmente, sujar as mãos mais rapidamente e mais frequentemente melhora suas habilidades melhor do que gastar seu tempo estudando e teorizando sobre a maneira "perfeita" de fazê-lo. Meu conselho é continuar praticando, acompanhar a tecnologia e estudar o design.

chrisw
fonte
12
Essa analogia não implica que os oleiros tenham produzido uma pilha de potes de lixo antes de produzir os de qualidade? Você poderia fazer isso em um ambiente profissional, com toda a consciência? E aqueles que estudaram e teorizaram e depois concluíram o trabalho antes do prazo?
quer
4
Eu estou bem com 20 potes de lixo para experiência em programação de hobby. Isso também me ajuda com minha experiência profissional em programação; além disso, tenho que começar em algum lugar.
precisa saber é o seguinte
23
Eu apenas escolhi olhar para isso em busca de valor superficial, "a prática leva à perfeição". Não olhar muito profundo para ele;)
ChrisW
6
Não gosto dessa resposta, porque ela pode ser facilmente tomada de maneira errada, assim como "protótipos descartáveis" nunca parecem realmente ser jogados fora.
Rudolf Olah
2
Acho estranho que muitas pessoas tenham um problema com isso. É quase uma analogia perfeita para o processo de desenvolvimento iterativo. Você cria algo rápido para atender aos requisitos, corrige bugs e refatora até que esteja correto e bom o suficiente. Se você não está construindo software dessa maneira, você realmente precisa experimentá-lo. A ruminação e a observação do umbigo são muito menos eficazes do que fazer algo e deixar as pessoas baterem nele.
precisa saber é o seguinte
72

Uma possibilidade que ninguém mais parece ter mencionado é que você está indo muito bem e seus gerentes não são muito bons. Como eles estão medindo a produtividade? Eles podem dar exemplos específicos ou é apenas uma percepção geral? Eles levaram em conta a quantidade de tempo gasto consertando o trabalho de outras pessoas em comparação com o seu?

Eu já vi muitas pessoas receberem crédito por fazer as coisas, enquanto o restante da equipe arruma a bagunça que deixou para trás.

pdr
fonte
11
Esta é provavelmente uma grande parte do problema. Olhando para isso em retrospecto, parece muito casual que eu sempre seja comparada às pessoas que trabalham na minha empresa anos mais do que eu. Hmm ...
ashes999
Se for esse o caso, o meu conselho é pedir as duas primeiras das minhas perguntas diretamente e ver o que a resposta que você começa, a partir daí
PDR
16
Quão verdadeiro, tantas vezes encontrei gerentes declarando que eu era incompetente quando os projetos que produzi em produção geram sistematicamente uma ou duas ordens de suporte de magnitude de ordem menos menos do que o trabalho equivalente de outras equipes. Muitos simplesmente não conseguem ver a imagem maior. O Metrics ajuda tanto quanto é um incômodo. Geralmente, esse gerente tenta jogar o sistema de modo que suas estatísticas pareçam boas.
Newtopian
Isso é mais um comentário do que uma resposta. Pessoalmente, sempre quero me tornar mais rápido e eficiente como codificador, independentemente do que os outros pensam. Definitivamente, há muito o que discutir sobre o assunto.
Andres Canella
@AndresCanella Todas as respostas nesta pergunta são basicamente um longo comentário. Você está certo, há muito o que discutir. Este realmente não é um bom formato para discussão (nem pretende ser). Mas era uma boa pergunta para começar, e é por isso que está fechada e marcada como Wiki da Comunidade - para a qual ninguém recebe pontos de reputação - em vez de excluída.
pdr
39

A maior parte do que as pessoas pensam ser importante não é importante. A velocidade de digitação não é importante. Máquinas ou ferramentas mais rápidas não são importantes. Não somos datilógrafos ou operadores de máquinas. Somos pensadores. Somos tomadores de decisão .

O que é importante é usar o feedback para melhorar continuamente o seu processo de tomada de decisão. A única maneira de fazer isso, como adquirir qualquer outra habilidade, é através da experiência, prática proposital e feedback contínuo.

  • Trabalhe em projetos paralelos.
  • Trabalhe em projetos de código aberto.
  • Trabalhe com desenvolvedores que são melhores que você. Emparelhe o programa!
  • Exponha-se a novas ferramentas e técnicas. Mantenha o que funciona.
  • Faça exercícios de programação projetados para treinar seu aparelho de tomada de decisão *.
  • Monitore sua melhoria com base em métricas objetivas, como taxa e velocidade de defeitos, e métricas subjetivas, como qualidade e adequação do código.

Finalmente: lembre-se de que velocidade sem qualidade é inútil e vice-versa. Para maximizar sua utilidade, encontre um equilíbrio entre essas tensões.

* http://codekata.pragprog.com/

Rein Henrichs
fonte
Você pode sugerir outros sites / termos para o google? Acho que enfrentar um desafio estranho por semana pode fazer meu cérebro se mover em diferentes dimensões.
precisa saber é o seguinte
A recente favorito da mina é pragprog.com/titles/btlang/seven-languages-in-seven-weeks
Rein Henrichs
11
A parte no início não faz sentido. Tudo o que o torna mais rápido, o torna mais rápido. Se você gastar pelo menos parte do seu tempo digitando, melhorar sua velocidade de digitação o tornará mais rápido. Se pelo menos parte do seu tempo for gasta aguardando o computador, um computador mais rápido o tornará mais rápido. Quando você está em uma busca para se tornar o mais rápido possível e melhorar constantemente, nada deve ser esquecido.
still_dreaming_1
12
As pequenas coisas como digitação e velocidade do computador fazem uma grande diferença. Isto é devido aos efeitos colaterais inesperados. Quando você precisa esperar pelo computador, a maioria das pessoas fica frustrada e algumas até se distraem. A combinação de frustração e distração é uma grande ameaça à produtividade. Algo semelhante se aplica à digitação. Se você for rápido na digitação, isso provavelmente significa que você ficou muito bom na digitação por toque e provavelmente não pensa muito em digitar. Isso libera seus olhos e cérebro para se concentrar na tarefa em questão, um enorme aumento de produtividade.
still_dreaming_1
@INTPnerd Eu concordo. Se você passa um tempo pensando em como a palavra "arremesso" aparece na tela ("Preciso mover o mouse para lá, clique em seguida, preciso encontrar o 't' no teclado"), seu cérebro também não tem tempo para considere as decisões reais.
21715 Erikbwork
25

É bem possível que, na verdade, você esteja sendo solicitado a sacrificar um pouco de qualidade, para maior velocidade.

Em alguns ambientes de desenvolvimento 1 , simplesmente não vale o tempo extra para produzir algo polido, quando "apenas o suficiente" será suficiente.


1 - Estou pensando em "ferramentas internas" em particular, mas provavelmente existem outras.

Jens Bannmann
fonte
5
Foi o que concluí dos meus primeiros trabalhos - outros escreviam qualidade significativamente mais baixa, ao custo de grande velocidade. Esse é o meu calcanhar de aquiles; Acho muito difícil escrever um código ruim que eu sei que vai me morder mais tarde.
ashes999
Esse é um problema fácil de resolver. você precisa alterar seu ambiente de software. Você precisa trabalhar em um ambiente em que acertar é mais valioso do que fazê-lo rapidamente. Existem empregos por aí onde isso importa.
Michael Shaw
Tendo trabalhado em ambientes onde ambos são igualmente valorizados, entre todos os que acertam - aqueles que acertam mais rápido estão superando os que acertam mais devagar. E acho que estou no último grupo.
ashes999
2
tudo bem, nesse caso, provavelmente se deve às estratégias usadas para escrever, testar e depurar código. pergunte se você pode emparelhar um programa com um programador "rápido" e ver como eles organizam seus processos de pensamento?
Michael Shaw
11
@ ashes999: Com prática, experiência e paciência, você passará do último grupo para o primeiro. Não há pílula mágica para tomar que fará a transição da noite para o dia.
FrustratedWithFormsDesigner
12

Parece que você está fazendo todas as coisas boas - que a médio prazo o tornará mais rápido, portanto não é óbvio se você é realmente lento. Só você realmente sabe disso. (mas é uma possibilidade muito real - o PeopleWare reivindica uma diferença de produtividade de até 10X entre os desenvolvedores para a mesma tarefa).

Então, eu tenho algumas sugestões para você:

  1. O tempo é uma coisa relativa, então talvez o problema não seja a sua velocidade real, mas a percepção do tempo que você está dando. Você pode sugerir que demorará uma semana, mas acabará passando duas semanas, onde outros podem passar três semanas ... mas você parece uma semana lenta.

  2. Como você recebe esse feedback frequentemente, talvez seja hora de conversar com seu gerente e colegas para ver o que eles dizem - deve haver muito a aprender com eles.

  3. Faça alguma programação em pares com um desenvolvedor de "qualidade rápida" para ver se você consegue identificar a diferença.

Stephen Bailey
fonte
8

Efetivamente, o que se resume a experiência é . Para ser mais rápido no que você faz, é como dirigir um carro, inicialmente você está com medo, já que outros são motoristas velozes (ou bêbados) (ou ambos) e deseja chegar em casa com segurança (em termos de software, deseja garantir que seu código funciona como desenvolvido e funciona bem).

Ao longo dos anos / meses, depois de aprender a dirigir e as estradas, você aprende alguns truques ao longo do caminho que tornam sua condução divertida. É o que chamamos de experiência. Esses "truques" (que eu chamo de traços) são o que ajuda.

No meu caso, aprendi o uso real de padrões de design codificando (até @ home) e aprendendo os usos de alguns. Assim, quando encontro um problema que requer um padrão de design, uso a experiência passada para ver quais funcionaram e por que funcionaria / não funcionaria para a minha situação.

Em suma:

  • A experiência cria características que aumentam a confiança e melhor software.

PS: A experiência também vem do aprendizado de outras pessoas. Por exemplo: Ajuda da SO, Programação em pares, Revisões entre pares, etc. Você não pode ter uma experiência se não puder olhar para trás e aprender com os erros (ou se alguém nunca desafiar seu esforço).

Buhake Sindi
fonte
Eu realmente espero que essa não seja a resposta certa; Eu já passo muito do meu tempo livre codificando e espero que algo que esteja faltando me dê uma vantagem significativa.
ashes999
@ ashes999, ok! com codificação de tempo livre, você revisa seu trabalho? O que quero dizer é que deve haver tempo para trabalhar na otimização do código e pegar o jeito dele. Todos nós podemos codificar, mas quantas vezes nos damos tempo para otimização?
Buhake Sindi
@TEG Eu o reviso entre projetos; por exemplo. se eu codificasse algo de uma certa maneira no projeto nº 1, em um projeto semelhante nº 2, eu poderia refletir sobre as falhas de design e refatorar bastante.
ashes999
@ashes - "refatorar muito" significa que você tem um tempo gasto ali porque seu design inicial não foi o ideal. Se o seu chefe não souber, você tem um problema para explicar para onde foram as horas. Se o chefe sabe, você tem um problema para explicar por que seu projeto não foi revisado por um colega de trabalho experiente.
@ TRA desculpe, eu deveria ter especificado - em projetos de hobby refatoro muito. No trabalho, refatoro levemente ou crio tarefas visíveis para que meu gerente saiba que estou refatorando.
precisa saber é o seguinte
8

A questão é se você é menos dispendioso quando olha para o custo total de longo prazo.

Em outras palavras, suas correções de bugs cuidadosamente elaboradas são de alta qualidade (incluindo casos de teste e documentação) que superam os custos de manter as correções feitas por seus colegas de trabalho mais rápidos?

Se sim, você precisa conscientizar seus superiores sobre esse fato. Pode ser difícil argumentar se eles não medem e têm os dados necessários para confirmar sua avaliação.

Se não, você deve considerar fortemente por que esse é o caso:

  • Você é muito inexperiente?
  • Você gasta muito tempo fazendo coisas não solicitadas que você acredita que deveriam estar lá?
  • Você tem dificuldade em determinar quando a correção está concluída?
  • Afinal, o seu código é de qualidade inferior ao que você pensa que é?
  • Você deve abordar o desenvolvimento de código de uma maneira diferente, porque leva muito tempo para acelerar a maneira como faz isso agora?
  • Você gastou muito tempo em coisas como este site?

Pense bem e edite sua pergunta com suas descobertas.

user1249
fonte
8

Todas as pessoas que fizeram perguntas sobre se você é ou não realmente lento são bobagens. Tornar-se um programador mais rápido sem sacrificar a qualidade é sempre uma boa meta, não importa o quão lento ou rápido você já seja. Este é o meu objetivo número 1 como programador e nunca terminarei. Estou sempre tentando ficar mais rápido sem sacrificar a qualidade, sou obcecado por isso. Aqui está o que funcionou para mim até agora na ordem da ajuda, juntamente com algumas idéias experimentais no final:

1) Nunca pare de aprender: Aprenda tudo sobre programação e uso de computadores em geral. Encontre áreas em que você é fraco e aprenda-as. Mesmo que pareça completamente não relacionado ao seu trabalho e ao C #, garanto que, se você estiver procurando por ele, frequentemente encontrará maneiras de aplicá-lo ao que faz. Aprender também é experiência, por isso não basta ler as coisas, mas experimentar e expandir suas habilidades. Se você está acostumado a usar o Windows, experimente o Unix ou vice-versa. Se você normalmente gosta de usar as ferramentas de linha de comando e editores de texto do IDE, ou vice-versa. Se você ouvir falar de uma ferramenta ou tecnologia que você nunca ouviu falar antes ou que não conhece muito, não ceda à tentação de seguir em frente. Procure! Não tenha medo de pensar fora da caixa e aprender novas tecnologias experimentais que outros dizem não serem práticas;

2) Divida os projetos: tente dividir seus projetos em mini projetos. Tente fazer um novo lançamento todos os dias ou uma vez a cada poucos dias, no máximo. Pergunte a si mesmo "Qual é a quantidade mínima de funcionalidade que posso liberar e ainda libere algo útil para o usuário". Essa é uma habilidade que você aprenderá fazendo isso. Pode ser necessário convencer seus gerentes a deixarem fazer isso, mas eles geralmente ficam satisfeitos com os resultados rapidamente. Ao fazer isso, você começará a perceber que coisas que considerava essenciais para o seu recurso, na verdade, são recursos adicionais que podem ser desenvolvidos posteriormente. Isso permite que você e seus gerentes priorizem apenas os recursos mais importantes, em vez de todos os recursos relacionados àquele em que você está trabalhando. Isso permite que você pense mais rápido, mantendo a mente clara e focada. Por sua vez, você legitimamente programará mais rapidamente. É provável que seus gerentes ou pelo menos os gerentes de seu gerente percebam que agora você está programando ainda mais rápido do que realmente é porque está obtendo mais lançamentos. Outro grande benefício disso é que você será muito melhor em estimar quanto tempo as versões levarão para serem concluídas, e seus gerentes amarão você por isso. Como você já está realizando muitos testes automatizados, não deve ter problemas ao fazer lançamentos frequentes que são estáveis. Talvez você precise aprimorar seu sistema de compilação automatizado. Eu recomendo a leitura do livro Entrega Contínua da série Martin Fowler. É uma leitura difícil e extremamente repetitiva, mas ainda muito útil. Os gerentes de s também provavelmente perceberão que agora você está programando ainda mais rápido do que realmente porque está obtendo mais lançamentos. Outro grande benefício disso é que você será muito melhor em estimar quanto tempo as versões levarão para serem concluídas, e seus gerentes amarão você por isso. Como você já está realizando muitos testes automatizados, não deve ter problemas ao fazer lançamentos frequentes que são estáveis. Talvez você precise aprimorar seu sistema de compilação automatizado. Eu recomendo a leitura do livro Entrega Contínua da série Martin Fowler. É uma leitura difícil e extremamente repetitiva, mas ainda muito útil. Os gerentes de s também provavelmente perceberão que agora você está programando ainda mais rápido do que realmente porque está obtendo mais lançamentos. Outro grande benefício disso é que você será muito melhor em estimar quanto tempo as versões levarão para serem concluídas, e seus gerentes amarão você por isso. Como você já está realizando muitos testes automatizados, não deve ter problemas ao fazer lançamentos frequentes que são estáveis. Talvez você precise aprimorar seu sistema de compilação automatizado. Eu recomendo a leitura do livro Entrega Contínua da série Martin Fowler. É uma leitura difícil e extremamente repetitiva, mas ainda muito útil. e seus gerentes vão amar você por isso. Como você já está realizando muitos testes automatizados, não deve ter problemas ao fazer lançamentos frequentes que são estáveis. Talvez você precise aprimorar seu sistema de compilação automatizado. Eu recomendo a leitura do livro Entrega Contínua da série Martin Fowler. É uma leitura difícil e extremamente repetitiva, mas ainda muito útil. e seus gerentes vão amar você por isso. Como você já está realizando muitos testes automatizados, não deve ter problemas ao fazer lançamentos frequentes que são estáveis. Talvez você precise aprimorar seu sistema de compilação automatizado. Eu recomendo a leitura do livro Entrega Contínua da série Martin Fowler. É uma leitura difícil e extremamente repetitiva, mas ainda muito útil.

3) Use a técnica pomodoro e adapte / mude o que não funciona para você. Se você combinar isso com o número 2 desta lista, receberá um enorme aumento de produtividade.

4) Aprenda o Vim. Mesmo se você acabar usando esses comandos no Visual Studio via ViEmu, ou a partir do Eclipse por meio de um plug-in ou do Emacs, você ganhará produtividade. A melhor maneira de aprender o Vim é começar a usá-lo e forçar-se a nunca (desabilitá-lo / voltar para suas ferramentas antigas) até que você o domine. É doloroso no começo, mas você nunca vai querer voltar e até se encolher quando precisar trabalhar sem ele. Alguns diriam que isso não aumentará muito sua velocidade. Mas mais rápido é mais rápido, especialmente quando a leitura e modificação de código é O QUE FAZEMOS, e eu me poupou muito tempo com isso de vez em quando.

5) Este último não é necessariamente recomendado, pois não tenho certeza de que seja uma boa ideia, e pode realmente diminuir sua produtividade, mas, mesmo assim, vou fazê-lo. Você pode tentar fazer mais testes de aceitação e menos testes de unidade, ou talvez pelo menos não se esqueça de fazer alguns testes de aceitação. Eu tive sucesso com o SpecFlow, mas suspeito que há algo melhor por aí. Até mesmo escrever as especificações pode ser bastante técnico, portanto, você pode apenas solicitar que seu gerente / cliente escreva uma versão preliminar preliminar para que mude significativamente, ou você mesmo pode escrever a coisa toda e apenas ler e aprovar. Isso irá ajudá-lo com o número 2 desta lista. Os testes de aceitação também podem ser mais práticos e requerem menos código que os testes de unidade. Isso não quer dizer que eles sejam substituídos, ferramentas diferentes para coisas diferentes.

6) Este é ainda mais experimental e controverso. Na verdade, eu mesmo não fiz isso, então não posso recomendá-lo exatamente. Aprenda e use o Meta Programming System da JetBrains. Use-o para criar ferramentas que seu gerente / cliente usa para criar o software desejado. Você pode até parar de fazer testes de unidade e aceitação se puder usá-lo para criar ferramentas que seu gerente / cliente usa para especificar o comportamento de uma maneira muito direta e não complicada. A idéia não é se livrar do programador. Os programadores ainda precisariam adicionar novos recursos a essas ferramentas usadas pelo cliente / gerente sempre que eles (as pessoas, não as ferramentas) não puderem criar facilmente algumas funcionalidades desejadas. Acredito que o MPS ou outras ferramentas semelhantes sejam o caminho do futuro.

INTPnerd
fonte
5

Use seu cérebro mais e faça menos testes. Para ser honesto, o teste tem seu lugar, mas é caro.

Leia também The Art of Unix Programming (livro on-line gratuito, vale o preço)

Finalmente, você pode não estar no lugar certo. Peg redondo no trabalho quadrado, etc.

Por fim, é como a escola: "Produzir o que o professor deseja" se torna "produzir o que a gerência pede e paga".

Christopher Mahan
fonte
3
Os testes me tornam mais rápido, não mais lento. Menos testes significam que mais regressões ficam sem manchas por mais tempo e são mais difíceis de corrigir, porque você não pode dar grandes saltos no código por medo de "algo pode quebrar".
ashes999
teste automatizado para mim é o cheiro do código. Isso significa que o código não era simples o suficiente.
21420 Christopher Mahan
6
Se o seu código é tão simples que não precisa de testes, não faz nada de interessante.
Re
Como você sabe exatamente? Ah, supondo novamente ... Vou referir-lhe à regra de modularidade: escreva partes simples conectadas por interfaces limpas. (de The Art of Unix Programming)
Christopher Mahan
Eu acho que você pode ter alguma coisa, Christopher. É aqui que ashes99 está gastando muito tempo, por exemplo, "matou". Muita coisa é uma coisa ruim. Nesse caso, a menos que você esteja corrigindo o código para os sistemas de controle de vôo, convém repensar a quantidade de testes realizados. Ou entre nesse tipo de campo.
user21007
5

Se você pegar um projeto amplo e finalizado e obter o número de linhas "finais" de código por homem-hora, verá que os programadores codificam MUITO mais devagar do que você poderia imaginar.

Estamos falando apenas de algumas linhas de código por dia. O resto do tempo você passa depurando, reescrevendo e fazendo coisas gerais sobre programadores.

Você pode ter ouvido o velho ditado - se você pegar um erro enquanto estiver digitando, ele economizará 10x o tempo que você o tiver capturado no momento da compilação, que é 10x melhor do que pegá-lo durante o controle de qualidade, que é 10x melhor do que pegá-lo após o lançamento ..

Então, como você acelera? Eu não me concentraria em nenhuma forma de velocidade de digitação - reduzir erros e melhorar outras "interações futuras" com o seu código devem ser um investimento muito melhor do seu tempo.

Código legível e claro é essencial. Você escreve seu código uma vez, mas ele será lido dezenas de vezes. Escrever para facilitar a leitura poupa muitos problemas (o que também poupa muito tempo). Se você NUNCA voltar e ler seu código e precisar pensar nisso por um segundo, estará fazendo errado.

A programação em pares pode reduzir o tempo de controle de qualidade e, se você considerar que um programador produz apenas algumas linhas por dia, se dois puderem codificar na mesma taxa que um, mas com menos erros, estará MUITO à frente.

Codificar defensivamente (por exemplo, verificação de parâmetros) pode reduzir problemas ... Se você tem um analista / arquiteto realmente bom em sua equipe, pode economizar tempo com um bom design inicial.

Caso contrário, continue melhorando suas habilidades de design. À medida que você ganha experiência, você se vê mais apto a reconhecer padrões que não funcionarão e evitá-los, será capaz de identificar o tempo gasto mais cedo etc.

Bill K
fonte
3

Você já pensou em fazer uma auditoria detalhada de si mesmo enquanto trabalha? Acompanhe com caneta e papel como está gastando seu tempo ou use algo como o Rescue Time para se controlar.

Quando você estiver mais ciente de exatamente como você gasta seu tempo, poderá ter uma idéia melhor do que precisa ser aprimorado e concentrar seus esforços lá.

Idealmente, você pode desafiar alguns de seus colegas de trabalho a fazer isso também, comparar seus resultados e obter idéias uns dos outros. Você provavelmente tem alguns pontos fortes dos quais eles também poderiam se beneficiar.

Talvez você descubra que está gastando muito tempo em uma parte do seu processo que pode ser automatizada ou apenas que você tem muitas distrações durante uma determinada parte do dia e outra parte do dia está quieta, então você pode planejar suas tarefas isso etc.

Ou talvez você descubra que o teste está demorando mais do que você pensava e precisa repensar sua percepção de que o está tornando mais rápido.

Se nada mais, você fornecerá alguns benchmarks com os quais você poderá trabalhar.

DKnight
fonte
3

Da sua lista, você está bem.

Se seus colegas estiverem criando código com um número CRAP maior, eles serão mais rápidos. CRAP é uma métrica comicamente nomeada que combina complexidade ciclomática e cobertura de teste.

Não escreva códigos com mais CRAP do que você precisa. ;)

Minha única alteração a sugerir para você é usar bibliotecas, não as escreva, a menos que:

  1. Sua empresa vende bibliotecas
  2. Você refatorou o código recorrente em uma biblioteca

Você está lendo e fazendo e isso é ótimo. Mas você pode ficar parado pensando em código procuedural ou OO. Você se expôs à programação funcional (digamos Haskell?) E ao Prolog?

Para aprimorar sua técnica de programação OO, você já brincou com Smalltalk / Squeak?

E, finalmente, teoria. Você tem pelo menos uma compreensão rudimentar da teoria dos grafos? (Alguns programas funcionam com árvores, DAGs ou apenas gráficos simples em algum momento. Redes são gráficos)

Tim Williscroft
fonte
Muitos ótimos pontos aqui. Preciso de bibliotecas porque preciso de um recurso para o jogo X (por exemplo, armazenamento do Silverlight em várias sessões do meu jogo) e posso dizer que eles precisarão mais tarde - ou são apenas códigos abstratos (como busca de caminhos) que não tenho nada especificamente a ver com o meu jogo. Eu tenho um background de comp-sci, então fiz procedimentos, OO, funcionais e o outro (Prolog). Teoria dos grafos, sim; recursão gráfica de profundidade que usei com bastante frequência, curiosamente.
precisa saber é o seguinte
3

Tanto quanto eu sei, é:

  1. Boa
  2. velozes
  3. barato

Como gerente, você pode escolher qualquer 2.

Não se preocupe com os comentários que você está recebendo em alta velocidade. Como um programador, prefiro manter um código bem pensado e bem escrito do que algo que foi batido juntos.

Nico
fonte
2

As principais coisas em que consigo pensar são as seguintes

  • Aumente sua velocidade de digitação.
  • Use ferramentas que fornecem ganhos de produtividade. Por exemplo ReSharper.
  • Máquinas ou ferramentas mais rápidas. Como mais memória RAM ou uma unidade de estado sólido.

Tenho certeza de que há algumas coisas que você também pode fazer na área de habilidades de codificação, mas parece que você está envolvido com esse tipo de coisa. As coisas listadas acima geralmente são ignoradas pelos desenvolvedores.

mpenrow
fonte
Estou em pé de igualdade com meus colegas de trabalho em relação a essas coisas (talvez eu tenha uma vantagem na velocidade de digitação); eles ainda são mais rápidos, de alguma forma. Experiência, talvez?
ashes999
11
Acima de um mínimo mínimo de "caçar e picar", a velocidade de digitação não é o fator limitante.
2
Você pode estar no nível deles em ter as ferramentas (por exemplo, Resharper), mas você sabe como usá-las efetivamente? Já vi muitas pessoas instalarem o Resharper e depois não aprenderem a usar 80% dos recursos. Para esse assunto, certifique-se de entender todos os recursos de refatoração e atalho do Visual Studio. Eu recebo uma vantagem fácil de 2-3% sobre qualquer outra pessoa no meu escritório, apenas mantendo as mãos no teclado o dia todo. Os ratos são :) lento
EZ Hart
@EZ Hart: Muito bom ponto. Alguns IDEs modernos (estou pensando no Eclipse, de cabeça para baixo) têm ferramentas muito poderosas para refatoração, procurando por referências de código (como onde é uma classe ou método referenciado, não simplesmente onde o texto "myMethod" aparece ) Para alguns desses recursos "avançados", vale a pena gastar 5 minutos para aprender a gerenciar o banco de código com muito mais eficiência.
FrustratedWithFormsDesigner
Estamos todos nivelados. Nenhum de nós tem as ferramentas :)
ashes999
2

Você pode fazer um curso de digitação rápida. Não sei se digitar mais rápido é um problema, mas "codificar muito lentamente" pode ser causado por velocidades de digitação simplesmente lentas.

E os geradores de código? Às vezes, o código fica repetitivo. A refatoração pode remover parte dela, mas mesmo assim você pode ter chamadas repetitivas para a mesma função refatorada. Dependendo dos dados e código com os quais você trabalha, os geradores de código (escritos em Excel, Perl, Java, qualquer que seja ...) podem economizar muito tempo. E o uso de ferramentas de geração de código para o desenvolvimento da interface do usuário geralmente não é óbvio.

E, finalmente, talvez as métricas estejam erradas. Você considerou que está codificando na velocidade mais rápida possível, considerando todo o resto, e que as linhas de tempo são muito curtas, fazendo você parecer um codificador lento?


Com base nas edições da sua pergunta, parece que você pode seguir o caminho de alguns de seus colegas de trabalho e criar a solução mais rápida que funcionará - e a documentação e o controle de qualidade são condenados!

Ou ... obtenha mais experiência e prática em uma área específica para conhecer a base de código e a API tão bem que você poderá codificar as soluções enquanto dorme. Isso pode ser feito, mas requer mais tempo. Se os outros desenvolvedores mais rápidos do que você são mais experientes e experientes, existe apenas uma coisa a fazer: você deve se tornar mais experiente e experiente!

FrustratedWithFormsDesigner
fonte
Não são cronogramas; outros colegas de trabalho podem fazer o mesmo trabalho mais rapidamente. Talvez seja experiência. +1 para digitar velocidade; Eu posso digitar em torno de 100WPM, então também não é.
precisa
@ ashes999: e se as pessoas que podem fazer o mesmo trabalho mais rapidamente forem mais experientes, provavelmente você se beneficiará mais com mais experiência com os sistemas em questão. Experiência requer tempo ...
FrustratedWithFormsDesigner
geradores de código são uma benção mista. Eles podem economizar seu tempo, mas se você gastar muito tempo no código gerado, a economia poderá se transformar em uma perda incontrolável.
2

Eu tenho uma objeção à visão de "qualidade sacrificada pela velocidade" do OP.

Codificadores profissionais (programadores) precisam satisfazer 3 objetos:
1) O código deve ser executado conforme o esperado
2) A entrega deve ser feita dentro do prazo
3) Tenha boa qualidade, documentação etc.
4) Outros etc.

Eu acho que o OP foi considerado lento, provavelmente porque o OP não foi feito a tempo.

9dan
fonte
2

É um problema 22 difícil de contornar. Embora você ainda não possua experiência e alguma quantidade de conhecimento em muitos aspectos já seja mais rápida que a maioria, o problema é que é mais difícil de medir .

Pessoalmente, o melhor que você pode fazer neste momento é se medir. Forneça feedback sobre como você trabalha, talvez mudanças simples nos seus hábitos de trabalho possam torná-lo mais produtivo.

Eu descobri que os e-mails estavam corroendo muito mais do que eu pensava simplesmente por causa da interrupção. Agora, só respondo e-mails duas vezes por dia e ganhei quase 1 hora de produtividade em alguns dias. Tente métodos como o pomodoro , usei-o como medida. A intervalos regulares (15 minutos), anotava o que estava fazendo naquele momento. Isso me permitiu ver como meus dias foram estruturados e o que eu poderia fazer para maximizar a eficiência.

Newtopian
fonte
Então você está dizendo que é exemplo de perfil? Interessante. :)
sum1stolemyname
na verdade, foi um efeito colateral de um método de rastreamento de tempo que tentei por um tempo ( davidseah.com/tools/ett/alpha ). Descobri algumas tendências de dados interessantes e inesperadas quando comecei a analisá-las além da parte do rastreador de tempo. É depois que eu aprendi sobre pomodoro, GTD e tal.
Newtopian
0

A vantagem de Squeak para codificação rápida vai muito além de apenas "aperfeiçoar as habilidades de OOP". Há uma razão pela qual GUIs modernas, assim como IDEs, foram inventadas no Smalltalk, sem mencionar que JUNIT era uma porta do SUNIT para Java, o termo "OOP" foi inventado para descrever o Smalltalk, etc., etc.

É preciso sempre usar a linguagem e o ambiente mais adequados para o que se espera alcançar, mas para a prototipagem geral, pelo menos, eu compararia o squeak contra qualquer coisa, com a possível exceção do HyperCard, e mesmo isso exigiria comparações para ver qual era na verdade, mais rápido, uma vez que existem recursos semelhantes ao hipercard embutidos no Squeak.

user22340
fonte