Desafio "Aumento de Salário": o risco de inventar suas regras (e não perguntar para o cliente).

Participando de um bootcamp aqui da DIO, mais especificamente o da "Localiza Labs", me deparei com um desafio que me chamou a atenção: a solução do Aumento de Salário.

Basicamente, a idéia era calcular o aumento de salário dos funcionários de acordo com uma tabela definida.

E a tabela partia do salário 0,00 até salários acima de 2000,00, sendo que a primeira faixa de valores considerada, para salários de 0,00 a 400,00, o reajuste deveria ser de 15%.

Ao participar dos grupos de discussão sobre o bootcamp, encontrei muitos amigos com dificuldades em passar nos testes fechados. Os mais problemáticos eram os testes #4 e #8.

Um desses testes - por serem fechados, não sei precisar qual - dizia respeito a "o que fazer quando o usuário informar um salário negativo?".

E algumas sugestões dadas nos grupos de discussão me alertaram para um ponto muito importante e que frequentemente passa desapercebido.

Muita gente dizia que, quando o salário fosse negativo, deveríamos igualá-lo a zero. Consequentemente, seria aplicada a taxa de reajuste da primeira faixa (15%).

Aí ocorre um erro que cometemos e é difícil de identificar (confesso que o cometo eventualmente, perdão!): o de atribuir valores por experiências/sentimentos pessoais.

Em nenhum momento do enunciado foi explicitado o que fazer com valores negativos. Não é um requisito do sistema!

Temos que tomar cuidado com nossas interpretações pessoais sobre esses valores. Não podemos simplesmente atribuir o valor 0,00 - sim, em programação zero é valor! - se assim não for definido.

No dia a dia, isso pode trazer consequências ruins para nosso produto. 

Imagine o seguinte cenário (hipotético!): 

• Preciso calcular a quantidade de aço que irei utilizar para produzir uma barra de aço.
• Imaginemos ainda que, em entrevista com o cliente, ficou definido que eu devo considerar 10kg de aço para cada metro da barra, porém preciso adicionar 1kg a mais ao resultado do cálculo. A fórmula seria Consumo = (comprimento * 10) + 1;
• Ou seja, se eu for fazer uma barra de 1 metro, pela fórmula, meu consumo seria de ((1 * 10) + 1) = 11kg de aço.

Ao executar os testes iniciais do meu módulo de cálculo, um dos valores de entrada é "-1" metro de comprimento.

O resultado desse cálculo seria ((-1 * 10) + 1) = -9kg de aço. Isso não pode! 

Por deliberação defino que, caso o valor vier negativo, vou atribuir a ele o valor 0.

O resultado passa a ser ((0 * 10) + 1) = 1kg de aço. Veja, para cada valor negativo informado (um erro de digitação?), meu cliente estaria consumindo 1 kg de aço!

Devemos sempre estar atentos, tentar identificar essas "lacunas" no levantamento de requisitos e alinhar com o cliente, pois é ele quem tem conhecimento para "bater o martelo" sobre as regras do negócio. Do contrário, podemos tomar decisões erradas em cima de informações que não são verdadeiras, e isso pode ser muito prejudicial.

Ah, e no caso do desafio: como não foi definido o que fazer, caso encontre um valor negativo, simplesmente aborte a execução do cálculo:

if (valor < 0) {
	return;
}	

O desafio é em C#.