O programa tem um objetivo que às vezes é esquecido
Imagem de um martelo deitado sobre um quadro-negro. Um parafuso estava preso no quadro, que eles marcaram muito láParece que os programadores se esqueceram do objetivo do software - resolver problemas do mundo real.
Há 50 anos, em 1968, uma
conferência de trabalho sobre engenharia de software foi organizada pelo Comitê de Ciências da OTAN. Então eles começaram a perceber que o software estava se tornando uma parte fundamental da sociedade. E, ao mesmo tempo, fica mais difícil de entender. Após essa conferência, a programação começou a se transformar em uma indústria real. Começou a sair do controle dos negócios.
Independentemente do destino da indústria, ainda existe um problema com a separação entre negócios e desenvolvimento de software - ou "engenharia", como foi anunciado pela primeira vez na conferência. Se os programadores se concentrarem muito estreitamente no desenvolvimento, poderão perder a meta para a qual o programa está sendo criado. Eles podem perder soluções ocultas que não exigem código.
Aqui está um exemplo.
Uma startup criou um dispositivo que abriu a porta de uma casa via Bluetooth. Interface gráfica para comunicação com o dispositivo - um widget em uma tela de telefone bloqueada. Ele tem um botão chamado "Abra a porta".
Quando o usuário se aproxima da casa, ele pega o telefone, encontra o widget e pressiona o botão.
Alguém olhou para esse mecânico e perguntou:
Se usarmos o Bluetooth e presumirmos que o proprietário do telefone possa entrar na casa, por que forçá-lo a pegar o telefone e pressionar o botão? Deixe a porta se destrancar quando o telefone estiver dentro de um raio de 1 metro. Não há necessidade de perder tempo com design e código GUI!Este é um excelente exemplo de foco restrito: o objetivo era abrir a fechadura com o mínimo esforço. Não faz sentido criar uma interface gráfica se os sensores forem sem fio.
Se você conhece os desafios de negócios e as necessidades dos usuários, pode combinar esse conhecimento com o seu conhecimento de tecnologia. Somente então você terá informações suficientes para encontrar uma solução melhor e entender que o programa não precisa de uma interface.
Um ótimo exemplo de como resolver um problema de software
sem uma única linha de novo código , além do código para realmente abrir a trava. Mas,
como dever técnico ,
nada pode justificar a programação desnecessária de todo o resto.
Nem todo código vale a pena escrever.
Às vezes, corrigir um bug sério não é a tarefa principal. Se você é uma troca de criptomoedas e o sistema permite um
depósito duplo , a intervenção humana pode ser a melhor solução em termos de relação custo-benefício, se o custo da solução for alto.
Essa troca entre Importância e Prioridade me lembra um modelo recentemente mostrado por um
colega . É chamado de matriz prioritária - um
modelo bidimensional que pode ser usado para priorizar bugs com base na gravidade e no número de usuários afetados.
Matriz bidimensional de prioridades. O eixo vertical representa o número de "vítimas" com os valores "um", "vários" e "todos". O eixo horizontal representa "seriedade" com os valores "cosmético", "desconfortável" e "para de funcionar". A prioridade do bug é determinada pela posição nos eixos. Por exemplo, se o erro for estético e afetar um usuário, a prioridade será 4 (mínimo). Se um bug interrompe alguns usuários, a prioridade é 1. Se ele interromper todos os usuários, possui a maior prioridade.O problema do depósito duplo mencionado acima se enquadra na categoria de
inconveniência que afetou
um usuário . Portanto, prioridade 3.
Nem todo bug vale a pena consertar.
Os desenvolvedores geralmente procuram prever todos os casos. Mas algumas tarefas repetitivas podem não merecer automação. Não há necessidade de perder tempo escrevendo scripts, se um resultado importante sobre o trabalho da equipe principal estiver oculto.
Há uma diferença entre encapsular lógica complexa e abstração de conhecimento útil. Às vezes, apenas informações claras podem ser entendidas. Se abstraímos, podemos obter o efeito oposto: a compreensão é difícil.
É mais útil usar alguns tipos de comandos de baixo nível na CLI do que comandos de nível superior com conhecimento abstrato,
como aliases do Git .
Nem toda equipe vale a descrição.
Muitos anos atrás, eu estava trabalhando em um projeto com
entrega incremental . Foi um sistema de verificação de identidade que solicitou ao usuário que fornecesse alguns dados pessoais para verificação por terceiros.
E lá a equipe queria codificar uma função incomum de validação de campo. No entanto, essa validação foi adiada em cada plantadora à medida que o prazo se aproximava. No final, eles decidiram que essa função incomum não faz sentido.
E aqui está o porquê: a validação já é forçada!
O fornecimento de informações confiáveis era do interesse do usuário. Se ele forneceu dados incorretos, eles não serão aprovados na verificação e ele não poderá usar o sistema. Além disso, a maioria dos navegadores suporta validação HTML padrão bastante boa.
Na pior das hipóteses, se o usuário não puder ser verificado, ele ligará para o suporte para verificação manual.
Nem toda função vale a pena codificar
Se você entende a essência do problema que está sendo resolvido, como desenvolvedor, pode criar um código melhor e, às vezes, sem código. Você não é um
byldoder pago para escrever linhas para a tarefa. Você é um profissional que é pago para resolver problemas.
Mas não há necessidade de resolver sem problemas qualquer problema com as tecnologias, como se o código do programa fosse uma solução universal para tudo. Caso contrário, você terá problemas para entender as necessidades do cliente e gerar ótimas idéias.
Seu objetivo e a tarefa do código é criar valor e tornar o mundo um lugar melhor, e não satisfazer sua idéia egocêntrica de como o mundo deveria ser.
Há um ditado: "Se você só tem um martelo, tudo se torna um prego".
É melhor ver primeiro um prego para considerar a necessidade de um martelo.
Se você realmente precisa martelar esta unha.