Métricas
29.10.2009
Voltar para o topo
As imagens e idéias contidas nesse blog estão sob uma
Licença Creative Commons Atribuição.
Você pode publicar e alterar as imagens, mas deve citar a autoria.
Isso foi feito na cultura escolar e o dano disso é praticamente irremediável. É o tal culto da nota.
Eu acho que se por algum acidente um aluno perguntar se beber água e ir ao banheiro ganha nota e eu disser que não, eles param de beber/mijar/cagar.
huaehueahuaeae boa! o típico “funcionário do mês”
Sério! Getters e setters são inúteis, não faz sentido criar método pra simplesmente retornar e atribuir um atributo quando ele pode simplesmente ser público. Propriedades, essas sim tem alguma utilidade.
huaehueahuaeae boa! o típico “funcionário do mês” +1
Putz, sorte que nunca aconteceu disso comigo. Mas já ví códigos que o cidadão deve ter sido pago pela quantidade de linhas, pois não era brinquedo não a quantidade de linha em branco que tinha! uhoauh
@Mamutti
Getters e Setters são muito úteis, sim. Com eles você pode fazer validação dos dados entre outras coisas que podem ser úteis.
Nessa sua abordagem uma classe representando uma pessoa com uma variável de data representando a data de nascimento dessa pessoa aceitaria uma data no futuro, por exemplo, sendo que o sistema (nesse exemplo) não deveria permitir isso.
Agora, realmente, gosto muito mais da abordagem de propriedades, tipo o C# (não sei quais outras linguagens tem isso), é até mais intuitivo.
Isso me lembra outro dia quando vieram pro meu lado com essas papagaiadas…
Eu respondi que preferia minha parte em dinheiro. Ele é mais fotogênico !
Oh, e eu aqui tentando reduzir meus codigos o maximo possivel
Sou o oitavo, o oitavo a comentar! Agora vou ler o quadrinho.
Rsss! Ótima sacada
Uma vez um professor do meu técnico disse: “E se vocês recebessem por linha de código digitada?” para poder justificar um algoritmo maior e mais lento… Eu ainda vou achar ele e dar uma voadora nele.
@Lucas Polo Eu gostaria de dar voadoras em muitos professores que já tive.
Bozo programa em Cobol, só pode. Se bem que nessa comparação, Java não ficou muito atrás.
euaheuahuea ótimo..
Quem dera eu ganhasse por linhas de código, meus códigos nunca seriam tão espaçados XD hail \n
ahauehauaheuehaeuhaeuaheuae, muito boa
O que parece incentivar a produtividade na verdade acaba por incentivar a produção de código longo. Realmente, não é raro ouvir associações entre qualidade e LOC ou mesmo quantidade de recursos e LOC.
Se incentivasse dizendo “quem fechar mais casos de uso/histórias ganha um mimo” seria mais eficiente, mas mesmo assim deixariam a refatoração de lado.
Talvez um “quem fechar mais casos/histórias e tiver menos bugs no código que escreveu ganha um mimo” fosse melhor.
O ideal mesmo seria propor que todos indicassem no membro mais produtivo da equipe ao final do mês.
Fico me perguntando qual foi o fato gerador dessa tirinha
Tirinha muito boa, e a ideia do Marcelo Minholi tambem, pois essa é uma boa ideia de produtividade.
Sobre como simplesmente premiar quem faz mais, ou quem é mais rápido, vale a pena dar uma olhada aqui: http://www.agileway.com.br/2009/09/11/recompensas-por-objetivo/
Agora, premiar alguém usando essa métrica de linhas de código é uma das coisas mais idiotas que existem. Pena que não é só piada.
Discordo do cara lá de cima q disse que getters e setters são inuteis, validação na entrada, formatação na saida e muito mais pode ser feito, além de facilitar o uso de alguns frameworks
Pelo visto o paiaço programa em Java né… hehehe
Nisso que dá usar muita ferramenta de geração de código.
As vezes você precisa desenvolver uma coisa pequena que levaria na mão cerca de 200~300 linhas.
Porém com estas ferramentas, o resultado é o “inesperado” aglomerado de 2000~3000 linhas.
Isso me lembra uma certa tirinha…
http://hackles.org/cgi-bin/archives.pl?request=334
Apos ver a tirinha, nao consigo parar de pensar em qualidade x quantidade.
Se não me engano, a IBM comprava softwares baseados na quantidade de linhas escritas, mas isso faz muitos anos…
@Marcelo Minholi
Melhor que incentivar a premiação individual é incentivar o sucesso como equipe.
Criar premiações assim normalmente contribui para aumentar a insatisfação de todos e diminuir o empenho por gerar um bom produto, passando a trabalhar em função dos prêmios.
Isso me lembrou o (old) desafio da calculadora na faculdade, a que tivesse menos erros ganhava a maior pontuação(e a coisa valia metade da prova), acabou que a equipe onde eu fazia parte ficou somente eu programando a coisa enquanto a outra equipe tinha uns 4 fazendo o código. O resultado é que muitos erros simples e óbvios não foram percebidos e nessa onda as 2 equipes acabaram com a mesma pontuação. Até hoje sonho com a calculadora puxando meus pés… :S
Corrigindo, não sonhos e sim pesadelos
Karlisson, todas as tirinhas da dev-dev q vc faz mostram a realidade de todas as empresas de TI por qual eu passei, não importa o tamanho delas… como tem chefe tapado q insiste em fazer milhões de reuniões pra nada (só falam merda), e ainda somos obrigados a aguentar esses papinhos de que “quem fizer mais linhas de código é mais produtivo”, ou “quem fechar mais trouble tickets é mais produtivo” é oq mais me irrita e mais me deixa com vontade de socar esses gerentes fdp. Tipo, eu posso ir lá e para cada linha de código escrever 20 de comentários, ou somente pegar os trouble tickets com defeitos ridículos como “mudar cor de tal botão”, “usuário x não loga no sistema”, entre outros…e fazer mais de 100 tt’s por dia.
E ainda, como vc mesmo mostrou em outra tira…o “fear-driven development”, hahah, acredita que eu já vi gerentes tirarem o scrum ou até mesmo o xp em algumas empresas para implementar a famosa metodologia de : projeto = prazo = alguém responsável?
Uma bela sacada sua também é o bozo…vamos ser sinceros, toda empresa sempre tem um palhaço q adora aparecer, sendo ele sempre contra o linux e o código aberto, e sempre usando geradores de código pra fazer as coisas (o famoso desenvolvimento via arrasta e cola), fazendo sites inteiros em flash/flex e depois ainda de tanto agente tentar convencê-lo a migrar pro linux, o palhaço acaba mudando a bandeira da microsoft para a da apple, e tudo continua a mesma merda de sempre…quem tem o linux como o sistema operacional do coração assim como eu, e for obrigado a usar aquele sistema horrível da apple, sabe doq eu estou falando, afinal, não importa se é microsoft ou apple, enquanto essas empresas continuarem no código-fechado, estarão sempre mil anos luz atrás do nosso tão amado pinguim e de outros projetos de código aberto, como java, php, ruby, python q também estão milhares de anos luz à frente do framework .NET e do Apple Toolkit entre outros.
De mais, a dev-dev é a sua série q eu mais adoro e continue com o bom trabalho q estarei sempre acompanhando ^^ , sei q dá trabalho, mas nunca pensou em fazer animações das suas tirinhas ?
Animações é uma boa
Vai que o Karlisson consegue espaço na indústria de desenho animado, e estampa o Nerdson nas manhãs de todos os dias, só pra garotada já nascer e crescer pensando e vivendo como nerd? xDDDDDDDDDD
Melhor que bitolar a garotada com desenho inútil, ou transformá-las em zumbis sexuais desde cedo, saturando-as com peitos e bundas na telinha todas as manhãs. xDDDDDDDDDD
Hauhuahuahuau!!!!! Ainda bem que nunca tive foto no quadro da empresa!!!! E olha que já estive envolvido com projetos em C/C++!!!!!
Huahuahua! Mais uma genial!
Existem algumas métricas que utilizo para avaliar os desenvolvedores. A quantidade de commits no SourceForge pode refletir com bastante justiça a participação de um desenvolvedor na comunidade opensource.
Dentro da empresa, o tempo dispendido para a execução de uma tarefa avalia a “velocidade” do desenvolvedor, mas seu valor como um todo é mais subjetivo. Por exemplo, conheço alguns desenvolvedores mais “rápidos” que executam a tarefa da forma mais rápida, e outros são mais “lentos” porquê pesquisam mais e prezam mais pela qualidade.
Quem quer “alta produtividade” vai comprometer a qualidade.
Eu avalio os desenvolvedores primariamente pela qualidade.
A cultura da velocidade é das fábricas de software, que ganham por contrato. Em ambientes opensource ou mesmo desenvolvimento interno de empresas, podemos focar mais na qualidade.
Isso me lembrou quando era técnico das linhas robotizadas numa montadora. Tinha gente que só andava anunciando no rádio que havia recuperado equipamento em falha, Mas nas estações mais silenciosas (onde realmente não havia muitos problemas, porque havia manutenção preventiva) o pessoal era esquecido, e visto como preguiçoso. Você era medido pela quantidade de vezes que consertava, e não por não deixar quebrar!!!
tô quase concluindo que o bozo programa em .net ou vb6
O Bozo programa em Mono.
O Bozo é a prova de que há pessoas que tornam coisas boas em ruins.
Nossa cada vez que vejo essas tirinhas eu vejo o meu dia a dia registrano nelas detalhe sou assistente de qualidade e minha colega pega no pé justamente para que eu perca meu tempo prenchendo o que eu realizei diariamente em uma planilha tosca de excel tempo esse que pode ser melhor aproveitado estudando melhor nosso trabalho e outras coisas bom como vcs acham que eu me sinto ???
acho tbm q a dev-dev é sua melhro historia karlison vai em frente que ta cada vez melhor diagamos que nas suas proprias tirinhas em apenas 3 frames nos damos mais risadas que em animações de 2ou 3 minutos. parabens.
@Guilherme Jedi: pra mim isso aí que você exemplificou é pra usar uma propriedade, pelo menos no Python e no C#. Não lembro se Java tem propriedades. =/
Meu tio, nos idos da decada de 70, programou uma folha de pagamento em assembler… na dev-dev ele seria o funcionario do mes direto, para desespero do bozo ahahaha
(puts, meus acentos foram pro saco novamente… isso ja ta merecendo virar um tirinha)
Dick
Além de comentários enormes dentro do código fonte que tal colocar dentro destes mesmos comentários o uml em versão ascii, o pseudo código?… RSRSRS
Em POO eu procuro fazer uso de extensões de classe, quando possível/necessário, para os getters responsabilizando-os pela lógica de teste de valores cujo o resultado, caso seja TRUE será devolvido aos setters contidos na classe principal que funciona como “interface” que contém os getters. Caso o resultado d.* set.* seja FALSE… Embora consiga desenvolver o algoritmo satisfatoriamente em um unico e desorganizado arquivo de leitura estafante.
Logo, vejo que métodos get.* e set.* e padronização de identificadores em Camel Case são uma boa ferramenta na organização de um projeto.
Eu acredito que dividindo o problema e prevendo erros eu me aproximo da conquista da solução definitiva embora, prevejo que problemas sejam de natureza influenciada/composta pela relação ao tempo.
Quantidade é necessariamente proporcional qualidade e vice versa?
Parabéns pela critica aos obsoletos métodos de incentivo a produtividade funcional.
Como sempre ler seus posts e os comentários ( e alguns debates que surgem ) me faz perceber que a “internerd” brasileira é privilegiada por mentes brilhantes.
Faço manutenção em um sistema em VB6 que o Sr. Rocha ia amar … kkkkkkkkkkkkkkk
Com esse sistema eu ia ser o funcionário do século!!
“linhas”+
“assim”+
“contam?”;