Ícone do site Aprenda Delphi

Lei do Instrumento e a Maldição do Programador

Se você não está familiarizado com o Lei do Instrumento, otherwise known as Maslow’s hammer/gavel, or the golden hammer it is often expressed as

Se sua única ferramenta for um martelo, você trata tudo como um prego.

Meu entendimento é que a lei do instrumento significa que você está limitado por instrumentos ou ferramentas que você sabe como usar. Por exemplo, se você tiver um parafuso, um pouco de madeira e um martelo, poderá enfiar o parafuso na madeira com sucesso, mas uma chave de fenda seria uma alternativa melhor.

A lei do instrumento também significa um obsessão com a perfeição dos instrumentos que você conhece. I remember back in the day when I was convinced there was no reason to bother with any other programming languages because Delphi was the best. Now I’ve spent some time using a lot of other programming languages, and so I can confidently say Delphi is the best, while I can also see the value and use of other programming languages.

Acredito que vale a pena aprender sobre novas tecnologias, frameworks, linguagens ou metodologias. Então você pode escolher o correto para o trabalho. Isso não significa que você precisa ser um especialista em todos eles, mas você deve saber o suficiente para estar confiante em sua escolha.

O reverso disso é a obsessão em perseguir tecnologias novas e interessantes e recriar coisas a cada poucos anos. Isso mantém os desenvolvedores entretidos, mas não fornece valor de negócios. Mais uma vez, acredito que o Delphi faz um bom trabalho com isso, pois respeita o código existente enquanto avança para novas plataformas, recursos e estruturas.

Então, qual é o Maldição do Programador?

Quando estou conversando com outros programadores, vejo dois comportamentos. A primeira é que todos os problemas que encontram na vida (no trabalho e fora dela) eles respondem com “Eu poderia escrever um programa para fazer isso, ”Ou alguma variação. Por extensão, eles também lançam um olhar crítico em relação a qualquer sistema de software (mesmo aqueles desenvolvidos por eles mesmos) para ver como melhorá-los. Isso resulta em um grande acúmulo de projetos que eles criam para consertar problemas, consertar um problema melhor ou apenas por curiosidade para ver se podem.

This is similar to the Law of the Instrument, but I see it more as your learning the flexibility and power of programming results in your seeing many opportunities to apply it. I’ve talked to people in other industries, and I think the general tendency is fairly universal, it is just that programming is (in my opinion) so much more powerful and flexible than many other applied technologies.

O segundo comportamento, que é algo para ser mais cauteloso ao cair, é o desejo de criar um “biblioteca”Ou“estrutura”Em vez de terminar o programa em mãos. For example, you are creating a program to solve a problem, and in the process, you create series of libraries just in case you need to solve similar problems.

Há valor em ter bibliotecas, funções, componentes e estruturas reutilizáveis. O truque é não deixar que a criação deles atrapalhe o transporte. A melhor maneira que encontrei de lidar com isso é criar a biblioteca apenas quando você precisar dela. Escreva seu código com o nível apropriado de acoplamento para resolver o problema em questão. Quando você precisar reutilizar um pouco dele em outro lugar, considere refatorá-lo em algo reutilizável. Então, conforme você o usa em mais lugares, você pode continuar a refatorá-lo e expandi-lo até ter uma estrutura completa.

Como você vê a maldição do programador em sua vida? O que você usa para evitar que cada projeto gere uma série de estruturas reutilizáveis?

Fonte:http://delphi.org/2018/01/curse-of-the-programmer/

Sair da versão mobile