Ferramenta de programação mais subestimada [fechada]

35

Temos muitas ótimas ferramentas que ajudam bastante na programação, como bons programadores, editores de texto, IDEs, depuradores, sistemas de controle de versão, etc. Algumas das ferramentas são ferramentas mais ou menos "obrigatórias" para fazer o trabalho ( por exemplo, compiladores).

Ainda existem ferramentas que ajudam bastante, mas ainda não recebem muita atenção, por várias razões, por exemplo, quando foram lançadas, estavam à frente de seu tempo e agora estão mais ou menos esquecidas.

Que tipo de ferramenta de programação você acha que é a mais subestimada? Motive sua resposta.

    
por Anto 11.03.2011 / 19:35
fonte

32 respostas

70

Um pato de borracha. Sim, realmente.

link

Rubber duck debugging, rubber ducking, and the rubber duckie test are informal terms used in software engineering to refer to a method of debugging code. The name is a reference to a likely apocryphal story in which an unnamed expert programmer would keep a rubber duck by his desk at all times, and debug his code by forcing himself to explain it, line-by-line, to the duck.

To use this process, a programmer explains code to an inanimate object, such as a rubber duck, with the expectation that upon reaching a piece of incorrect code and trying to explain it, the programmer will notice the error. In describing what the code is supposed to do and observing what it actually does, any incongruity between these two becomes apparent...

    
por 15.04.2013 / 07:32
fonte
42

Caneta e caderno.

  1. Funciona sem eletricidade.
  2. Portátil.
  3. Doodle ligado / desligado quando entediado em reuniões
  4. Armazene informações úteis.
  5. Se estiver escrito, as pessoas atribuem mais importância a ele.
  6. Outros podem ler e aprender.
por 11.03.2011 / 21:13
fonte
38

Ferramentas de diferenciação parecem ser subutilizadas ao comparar saídas de registros ou dados em arquivos de texto simples. Ou talvez seja apenas um nicho? Eu pareço achar muito útil e útil para a depuração comparar grandes logs de execuções de programas e identificar um ou dois detalhes que foram alterados.

Ferramentas de perfil de desempenho também são muito boas de se ter, especialmente quando você bate em um crítico, mas parece que poucas pessoas estão familiarizadas com elas (e eu me admito até certo ponto nessa categoria) .

Boas ferramentas XML são vitais - se você estiver trabalhando com arquivos XML mais de uma dúzia de linhas ou múltiplos esquemas. Às vezes, você precisa de mais do que apenas a sintaxe básica destacada por outros editores. Além disso, ao trabalhar com XML, o aprendizado de XSL pode ser muito útil. Muitas vezes vejo o que poderia ser feito em uma transformação XSL simples feita em várias linhas no código do aplicativo. Embora para esclarecer: eu sou não sugerindo que o XML em si é uma "ferramenta de programação subestimada"; Estou sugerindo que o valor de bons editores de XML é subestimado pelo que vi.

    
por 11.03.2011 / 22:34
fonte
37

Expressões regulares

Eles são tão úteis. Eles ajudam quando pesquisando através de arquivos de log, analisando texto etc. Eles são extremamente úteis.

Eu acho estranho quantas pessoas eu conheço que nunca as usam porque há uma curva de aprendizado associada a elas. Muitas vezes eu vejo as pessoas fazendo as coisas da maneira mais difícil (Nota: antes de regex eu fiz as coisas da maneira mais difícil) quando um regex simples poderia baixá-lo rapidamente.

    
por 11.03.2011 / 20:20
fonte
24

Seus companheiros de equipe. Quando você está com uma ideia e esquece de incorporar sua equipe, você nunca ouvirá suas preocupações ou ideias sobre por que ela não funciona ou por que ela pode ser ainda melhor.

Eu digo isso, porque é fácil pensar que a programação é algo anti-social que as pessoas fazem nas esquinas com suas idéias brilhantes. Pessoas que acham que isso subestima o valor das equipes e seus colegas de equipe em ajudar a transformar ideias / projetos em mergulho / natação.

    
por 03.06.2014 / 21:37
fonte
19

Google. Existem poucos problemas que ainda não foram resolvidos e documentados. Uma consulta do Google bem ajustada pode economizar muito tempo para todos.

    
por 11.03.2011 / 19:44
fonte
16

De longe, a ferramenta mais subestimada para encontrar "gargalos" é Ctrl + C ou o botão "Pausar", em um depurador.

Verifique o último parágrafo de este post e esta postagem e este post , para começar.

Muitas vezes vejo / ouço falar de pessoas dizendo: "O programa é muito lento! O que eu posso fazer sobre isso? Eu tentei um criador de perfil (se eles o fizeram), mas eu não entendo o que ele diz. Alguém tem algum palpite ? Socorro!" Bem, adivinhações são apenas isso. O que eu sempre fiz, e os outros também, é continuar, interromper e examinar a pilha de chamadas. Se o problema é muito ruim, bingo , está bem na sua frente. Se o problema é apenas leve, você o faz várias vezes. Qualquer coisa que apareça em mais de uma amostra, que você possa evitar, é um gargalo que pode ser corrigido.

Sim, isso é isca negativa, mas funciona.

    
por 23.05.2017 / 14:40
fonte
14

What type of programming tool do you think is the most underestimated one? Motivate your answer.

O compilador.

A maioria das pessoas não leva tempo para entender o que seu compilador de escolha faz. Eles apenas acham que isso torna o código um programa executável e isso é o máximo possível. Nas mais modernas, existem várias configurações que você pode inserir para fazer o que você precisa. Aqui está um exemplo, aposto que metade dos desenvolvedores em seu escritório não tem idéia de como definir o aviso como nível de erros (supondo que ele realmente tenha um). Quais opções você precisa para gerar símbolos de depuração? Quais otimizações (ou qual nível de) você deseja fazer. A lista continua.

    
por 11.03.2011 / 20:43
fonte
10

Seu cérebro. Outras ferramentas não teriam muito significado sem isso.

    
por 11.03.2011 / 19:38
fonte
10

Bom e velho:

print

Às vezes, um depurador ou um profiler ou um diagrama de fluxo UML é útil. E às vezes eles te deixam louco. Eu sempre me pego recorrendo ao uso de instruções de impressão (ou rastreamento ou NSLog ou what-have-you) apenas para garantir que meu código está fazendo o que eu acho que está fazendo quando eu acho que está fazendo isso.

    
por 12.03.2011 / 17:17
fonte
8

Scripts antigos em ... não importando quantas linguagens de próxima geração nós desenvolvemos, nós ainda dependemos muito de scripts, e a maioria das tarefas do dia a dia pode ser obtida escrevendo-se algumas linhas de scripts.

    
por 12.03.2011 / 03:49
fonte
7

Caneta e quadro branco.

Você não pode vencer a baixa tecnologia ao tentar explicar algo.

    
por 03.06.2014 / 21:54
fonte
6

ack . É como grep -r , mas foi projetado para pesquisar seu código-fonte.

    
por 03.06.2014 / 21:55
fonte
5

Perl e outras linguagens de script. Ótimo para tarefas que são um pouco complicadas demais para ferramentas de GUI como o Agent Ransack.

    
por 11.03.2011 / 22:14
fonte
4

Atalhos de teclado que permitem refatoração rápida, freqüente e segura. Aprender a extrair (ou inline, etc) variáveis, métodos, constantes ou classes ao pressionar algumas teclas alterou fundamentalmente o código. Você só refatorará com frequência (ou seja, o suficiente) quando o custo for mínimo, portanto, tornar esses atalhos uma segunda natureza é essencial para escrever e manter um bom código, no que me diz respeito.

Então, geralmente, use boas ferramentas (IDE / editor) e aprenda como obter o máximo dos recursos que elas oferecem.

O teste de unidade e o TDD vêm em seguida, para manter seu código testável e evitar o medo de refatoração.

Use-os e você se moverá facilmente para escrever um código de manutenção correto que esteja em conformidade com o princípio DRY e seja auto-documentável.

    
por 12.03.2011 / 03:40
fonte
4

O teste de unidade oferece os seguintes benefícios:

  • Os desenvolvedores se tornam os primeiros clientes do código. Quanto mais rápido um bug é detectado, menos caro é consertar. Os erros podem ser detectados antes de uma compilação, instalação ou implementação .
  • O teste altera sua perspectiva sobre o código. O design está claro? Ela lida com casos de esquina?
  • O O Efeito Hawthorne melhorará a qualidade, ao anunciar que uma equipe está publicando métricas de qualidade / teste.
  • Mesmo que os testes não sejam verificados no controle de origem, eles podem ser uma ótima maneira de explorar e aprender novos terrenos.
  • Uma alta probabilidade de menos erros!
por 12.03.2011 / 16:42
fonte
4

Geradores de código

Geradores de código podem criar uma grande quantidade de código eficiente e livre de bugs a partir de uma definição simples. Os usos do tipo ORM são os mais óbvios para criar classes de acesso a dados, mas há muito mais usos em potencial.

O suporte à geração de código parece ainda estar em sua infância, tanto do ponto de vista do programador quanto do framework, mas acredito que seja algo que veremos mais e mais. Em .NET , você pode começar a mexer com o CodeDOM coisas.

    
por 03.06.2014 / 21:43
fonte
3

Eu uso AgentRansack muito. É uma ajuda tremenda pesquisar milhares de arquivos rapidamente. Isso me poupou muito tempo, mas não conheço muitos programadores que os conhecem ou usam.

    
por 11.03.2011 / 20:09
fonte
3

Métodos Formais.

link

link

É difícil exagerar sua importância. Cada loop e cada if começa como uma ideia que requer algum tipo de "prova". A maioria dos programadores faz essa prova a maior parte do tempo em suas cabeças. Você pergunta o que a declaração if faz e eles podem articular - de forma sólida e lógica - quais são as escolhas e por que as escolhas são completas, consistentes e exclusivas.

Mas alguns parecem adivinhar aleatoriamente. Eles precisam de mais ajuda e os métodos formais podem ser o tipo de ajuda de que precisam.

É apenas álgebra (e cálculo) para código. Nada muito complexo ou sofisticado.

    
por 11.03.2011 / 20:22
fonte
3

Padrões de design físico, como deixar a cadeira para uma corrida rápida à luz do sol e ar fresco, mantêm nossos cérebros funcionando no auge do auge.

    
por 12.03.2011 / 04:23
fonte
3

Bem, é Half Life 2 (insira seu jogo favorito aqui). Se eu tiver um problema que não consigo resolver, simplesmente paro e começo a jogar com meu jogo favorito e, de repente, a solução aparece em minha mente. Então, para ser honesto, não é um jogo ou algo assim, mas fazendo algo mais . Muitas vezes vejo pessoas sentadas em um problema por horas sem resolvê-lo e tudo o que devem fazer é colocar o cérebro fora do ar por um curto período.

    
por 12.03.2011 / 19:44
fonte
3

Estouro de pilha - ajuda especializada rápida quando você está preso

question and answer site for professional and enthusiast programmers. It's built and run by you as part of the Stack Exchange network of Q&A sites. With your help, we're working together to build a library of detailed answers to every question about programming...

    
por 23.05.2017 / 14:40
fonte
3

Eu acho que é o Bloco de Notas / TextPad / programas simples de edição de texto. Todo mundo tem um tempo em que precisa de uma solução rápida que não exija a abertura de um IDE e precise apenas de uma edição rápida. E todos os computadores têm algum tipo de programa simples de edição de texto.

    
por 03.06.2014 / 21:53
fonte
2

Confirma e uma boa função alwaysAssert() . IMHO estes são mais importantes que os testes de unidade, porque os testes de unidade só podem encontrar erros nos casos específicos que você pensou em testar. Se o mesmo programador escrever o código e os testes, ele provavelmente perderá os mesmos casos de borda em ambos. Além disso, às vezes o teste de unidade é impraticável porque o ambiente no qual o componente funciona e / ou os dados em que opera são muito complicados para criar um caso de teste planejado.

A beleza das afirmações está na capacidade de documentar suposições e testá-las em entradas não planejadas . Se qualquer uma dessas suposições estiver errada, seu código falhará em voz alta em vez de "funcionar", mas produzirá resultados sutilmente incorretos. Também falha mais perto da raiz do problema do que sem as afirmações. Na prática, se você declarar suposições suficientes sobre um pedaço de código e todas essas suposições estiverem corretas, o código estará correto.

Uma queixa comum sobre as afirmações é que elas podem ser desativadas. IMHO toda linguagem ou biblioteca padrão deve ter uma função alwaysAssert() ou equivalente que faz a mesma coisa que assert mas não pode ser desativada. Isso pode ser usado para verificar hipóteses em áreas críticas de código sem desempenho, em que os benefícios de desativar as declarações são insignificantes.

    
por 12.03.2011 / 05:11
fonte
2

A tecla F1. - Útil para programas que você não conhece e para programas em que você está trabalhando. (Supondo que seja um aplicativo grande).

Poderosos para filtrar problemas foram os erros de um relatório de usuários com base em sua interpretação de como o software deve funcionar. Claro, pode ser que o projeto em si tenha falhas. Mas isso é outra história.

    
por 12.03.2011 / 05:35
fonte
2

Vários utilitários principais do UNIX, mas principalmente find e ocasionalmente grep ou ed . A capacidade de encontrar coisas em ninhos profundos de arquivos é inestimável, especialmente quando você de repente herda uma base de código e precisa consertá-la. Mesmo que o dito código esteja bem documentado, você provavelmente terá que caçar, e um strong entendimento de find o mata.

    
por 12.03.2011 / 05:36
fonte
2

Curiosidade

Chame de "enigma da programação". O que é uma ferramenta em comparação com a pessoa que a usa? O desejo de saber como e por que algo funciona ou não funciona expande o conhecimento de alguém mais do que qualquer ferramenta específica e isso é verdade além da programação.

    
por 12.03.2011 / 19:29
fonte
2
Ctrl + C    
Ctrl + V

Salvo inúmeras horas em todo o mundo!

    
por 13.03.2011 / 17:29
fonte
1

Cauda

Tail pode ser usado para monitorar o arquivo de saída do log do programa em tempo real. Tem sido de grande ajuda no desenvolvimento de sistemas que não fornecem outros meios de leitura do log.

Programas de exemplo são;

por 12.03.2011 / 18:43
fonte
0

Eu juntei um gerador gráfico de chamadas Perl uma vez. Foi extremamente útil, mas caiu muito em código não processual ou em rotinas fora de arquivo.

    
por 11.03.2011 / 22:37
fonte