O artigo foi muito interessante, pois consegui descobrir que tipo de programador sou, e com base nele pretendo melhorar meu desempenho em desenvolvimento de software.
Depois de ler este texto, vi que realmente é difícil programar e requer tempo, não somente chegar e começar a escrever linhas e linhas de código. Um bom software deve ter uma boa analise antes de ser feito, pesquisas de como você melhor pode desenvolvê-lo. Ou seja, é melhor demorar mais um pouco e fazer um coisa caprichada, do que fazer rápido e tudo bagunçado e com erros. Agora, em relação aos APRESSADINHOS né, nada a declarar!
Após ler este texto (e baseado em minha experiência como programador, embora medíocre) entendi a importância do planejamento e da parte estrutural no desenvolvimento de um software, e como erros nesta parte podem ter um grande impacto na hora de escrever o código.
A linha geral do texto mostra as principais diferenças entre bons e maus programadores. Vários fatos mencionados, como o problema de entregar um software que não corresponde às necessidades do cliente, nos fazem levar em conta a tão alta importância de modelar um projeto antes de tudo, mesmo que este seja muito simples de ser implementado. Nenhum projeto pode ser modelado de cabeça, nem ser feito da noite pro dia. Eles tendem a crescer e mudar constantemente devido às exigências dos clientes por modificações e melhorias. É necessário que o engenheiro de software realmente compreenda aquilo que o usuário precisa! Enfim, programar é um trabalho que requer atenção, compromisso e qualidade.
O texto abre uma importante e difícil discussão sobre modelagem versus codificação. Concordo que não basta ter um vasto conhecimento quanto ao código: é preciso entender o problema e fazer uma boa modelagem visando entender as suas necessidades. Embora muitos acreditem que isso acaba atrasando a construção e finalização do projeto, o planejamento evita que trabalho seja perdido, ou seja, que tempo seja perdido à toa.
Não concordo que um bom programador faça de 10 a 12 linhas por dia: acredito que isso aconteça perto da finalização do código, quando a maior parte do projeto já está concluída.
No geral, gostei da maneira como o autor do texto fala sobre o tema (apesar de alguns termos que possam ofender uma parte dos programadores, eles ajudam na compreensão do mesmo).
realmente, a eficiencia de um projeto depende da qualidade e da estrutura que foi pensado e organizado mas olha eu ate entendo o ponto de vista e inclusive concordo, mas falar que bons programadores programam no chuveiro e nos sonhos??? aaaaaa tah viu....
Como nosso amigao "Fabio" disse, muito inteligentemente, nos fez enxergar o verdadeiro modo de ler e refletir sobre um assunto e ser capaz de comertar tao bem depois.. Apenas mudando algumas ideias, superficialmente, pois ainda nao refleti totalmente, eu acho que: O artigo foi muito interessante, pois consegui descobrir que tipo de programador sou, e com base nele pretendo melhorar meu desempenho em desenvolvimento de software.
Ótimo artigo. Realmente temos algumas manias muito 'toscas', desperdiçamos nosso tempo apenas programando, e não nos preocupamos muito com a documentação.
Sabias palavras do nosso amigo Vini. Só tenho uma coisa a comentar a respeito disso: O artigo foi muito interessante, pois consegui descobrir que tipo de programador sou, e com base nele pretendo melhorar meu desempenho em desenvolvimento de software.
O artigo mostra que nosso amigo aprendeu muito durante sua vida de programação. Algumas coisas são óbvias, como um bom programador ser mais produtivo do que um programador na média, mas outras são realmente interessantes, como gastar 10 a 20% do seu tempo programando.
A partir da leitura do tópico sobre algumas verdades pouco conhecidas sobre a programação, pudemos ver que somos programadores de muito baixo nível, pois desperdiçamos um tempo absurdamente grande somente corrigindo o código, sendo que se estudássemos um pouco mais como implementá-lo, conseguiríamos "enxugar" um pouco mais o código e deixá-lo mais plástico e limpo, gastando um tempo maior para desenvolver poucas linhas, mas linhas que não serão alteradas para correção, o que acaba economizando tempo.
Mas, como os outros colegas disseram e o amigão Fábio:
"O artigo foi muito interessante, pois consegui descobrir que tipo de programador sou, e com base nele pretendo melhorar meu desempenho em desenvolvimento de software."
Concordo em partes com o autor, mas com minha experiência na área, sendo principalmente baseada em projetos e pequenos problemas. No começo já começava codificando, sem antes ter pensando em uma solução realmente funcional e acabava gastando tempo em corrigir possíveis erros e na maioria das vezes tinha que voltar e pensar em uma solução realmente funcional. Logo aprendi, que ser um bom programador é saber resolver problemas e para isso devemos pensar realmente no problema, depois na sua solução e por fim codificar o problema. Chego à conclusão, que seria 70% como resolver o problema e 30% em transformar a resolução em código, logo para ser um bom programador é ter soluções para os problemas e uma boa base em diversos problemas diferentes, logo muito treino e um pouco de teoria.
Realmente é um texto muito interessante e sobre o qual é possível refletir bastante. Mas, apesar de entender o ponto de vista e as explicações do texto, não consigo concordar totalmente com ele. Acredito que um bom sistema deva sim ser pensado e planejado antes e durante a sua codificação, mas não acredito que para isso seja necessário gastar 90% de seu tempo de projeto e pensar nisso 24/7. Após definido os primeiros problemas e escopo geral do projeto, já é um bom ponto para começar a dar forma a tudo que foi planejado, a começar a codificar, pois certos problemas e condições, mesmo com um bom planejamento, só são encontrados durante a codificação, pois nem sempre tudo que foi planejado pode ser codificado exatamente como se havia pensado. Planejamento e documentação de um projeto é algo realmente importante, porém a codificação também é muito importante pois como já foi dito, certos detalhes só são corretamente enxergados durante esta fase.
Bom.. fazendo um comentario serio agora vai professor.. *-* Acho q o planejamento é muito importante, seja qual for a atividade a ser realizada. Ainda mais programando, pois se for programar direto e sem planejar, suas chances de erro sao grandes, alem de se errar ter q mudar quase o projeto todo. Como estamos vendo em aula, estamos aprendendo muito mais vendo casos de uso e etc.. do que se fossemos programar e programar sem nenhum plnejamento, até porque se um dia precisarmos fazer um projeto diferente do aprendido em aula, teremos muito mais dificuldades pois nao saberiamos planejar e só programar, e programar um codigo espcifico(aprendido em aula) e os projetos sao diferentes.. Bom [é isso, pode ter ficado meio confuso, mas eu explicando sou melhor q eu escrevendo.. Mas é isso, sucesso ai professor!
A perte mais relevante do texto é a opnião que diz que "bons programadores pensam antes de escrever um codigo o que gera menos dor de cabeça para concertar depois" isso eu concordo interamente. É verdade que o processo de planejamento da estrutura dos codigos é fundamental pois evita muitos desabores mais tarde como concertar erros de bugs (o que gera trabalho em dobro ou triplo...) mas a parte da codificação em sí também é muito importante pois é necessário boa abilidade em codificar para conseguir resolver problemas de forma eficiente. Chuto que a relação de importância entra as duas seria: de 40% codificando e 60% planejando.é só um chute pois não tenho experiências na prática...
A perte mais relevante do texto é a opnião que diz que "bons programadores pensam antes de escrever um codigo o que gera menos dor de cabeça para concertar depois" isso eu concordo interamente. É verdade que o processo de planejamento da estrutura dos codigos é fundamental pois evita muitos desabores mais tarde como concertar erros de bugs (o que gera trabalho em dobro ou triplo...) mas a parte da codificação em sí também é muito importante pois é necessário boa abilidade em codificar para conseguir resolver problemas de forma eficiente. Chuto que a relação de importancia entra as duas seria: de 40% codificando e 60% planejando.é so um chute pois não tenho experiência na prática.
Esta publicação sobre programação, mostra como programar vai muito mais além de somente escrever linhas de código. Para David Veksler, 90% do tempo de um software é composto pela parte abstrata, pensar, pensar e pensar! Eu não acredito que seja exatamente assim para todos os casos, depende muito do programa e do programador. Mas eu acredito, e já comprovei que, analisar, estudar e pensar no programa antes de escreve lo, resulta em ganho de tempo e um programa de maior eficiência. Um programador completo é um profissional com conhecimentos em diversas áreas, além de um grande conhecimento em programação. Isso prova que, assim como a publicação diz: programar é um trabalho difícil. Quem nunca ouviu a frase " Quem não usa a cabeça, trabalha por dois", é isso, sem pensar, irá perder horas programando. Um forte abraço e bora programar!!!
Eu acho que houve uma generalização desnecessária a respeito que todo programador ruim passam tempo mudando o código tentando tirar bugs, eles fazem isso procurando melhorar o código fazendo as mudanças necessárias, claro que tem aquela parcela que quanto mais mexe no problema pior fica. Acho que endeusaram demais o bom programador, claro que o mesmo acaba sendo mas eficiênte que os demais, mas na maioria das vezes todo mundo acaba chegando em um solução que não se diferenciam muito em si. Eu concordo que mudar constantemente um software o deixe ruim, talvez isso seja mais importante que o cliente, por isso é importante fazer um planejamento antes Concordo em partes que adicionar mais tempo no trabalho ou mais pessoas no projeto pode ter um efeito negativo, mas depende da situação, adicionar pessoas evita uma sobrecarga encima do programador, isso se a pessoa trabalha melhor livre de pressão.
Concordo com algumas idéias e vivo algumas na prática, quanto melhor a análise e o entendimento do processo a chance de acertar na programação é maior. O retrabalho é desperdícil de tempo em um projeto grande pode comprometer seriamente a sua entrega. É comprovado cientificamente em estudos que a vida útil e a manutenção barata de um sistema deve-se á uma análise e coompreesão de um projeto.
A profissão de programador e muito mais exigida que as demais, em relação ao desempenho,podendo ser ate prejuizo pra uma empresa contratar um programador medio,diante disso aprendi que tenho que ser o melhor programador.
23 comentários:
O artigo foi muito interessante, pois consegui descobrir que tipo de programador sou, e com base nele pretendo melhorar meu desempenho em desenvolvimento de software.
Depois de ler este texto, vi que realmente é difícil programar e requer tempo, não somente chegar e começar a escrever linhas e linhas de código. Um bom software deve ter uma boa analise antes de ser feito, pesquisas de como você melhor pode desenvolvê-lo. Ou seja, é melhor demorar mais um pouco e fazer um coisa caprichada, do que fazer rápido e tudo bagunçado e com erros.
Agora, em relação aos APRESSADINHOS né, nada a declarar!
Após ler este texto (e baseado em minha experiência como programador, embora medíocre) entendi a importância do planejamento e da parte estrutural no desenvolvimento de um software, e como erros nesta parte podem ter um grande impacto na hora de escrever o código.
A linha geral do texto mostra as principais diferenças entre bons e maus programadores. Vários fatos mencionados, como o problema de entregar um software que não corresponde às necessidades do cliente, nos fazem levar em conta a tão alta importância de modelar um projeto antes de tudo, mesmo que este seja muito simples de ser implementado.
Nenhum projeto pode ser modelado de cabeça, nem ser feito da noite pro dia. Eles tendem a crescer e mudar constantemente devido às exigências dos clientes por modificações e melhorias. É necessário que o engenheiro de software realmente compreenda aquilo que o usuário precisa! Enfim, programar é um trabalho que requer atenção, compromisso e qualidade.
O texto abre uma importante e difícil discussão sobre modelagem versus codificação. Concordo que não basta ter um vasto conhecimento quanto ao código: é preciso entender o problema e fazer uma boa modelagem visando entender as suas necessidades. Embora muitos acreditem que isso acaba atrasando a construção e finalização do projeto, o planejamento evita que trabalho seja perdido, ou seja, que tempo seja perdido à toa.
Não concordo que um bom programador faça de 10 a 12 linhas por dia: acredito que isso aconteça perto da finalização do código, quando a maior parte do projeto já está concluída.
No geral, gostei da maneira como o autor do texto fala sobre o tema (apesar de alguns termos que possam ofender uma parte dos programadores, eles ajudam na compreensão do mesmo).
realmente, a eficiencia de um projeto depende da qualidade e da estrutura que foi pensado e organizado mas olha eu ate entendo o ponto de vista e inclusive concordo, mas falar que bons programadores programam no chuveiro e nos sonhos??? aaaaaa tah viu....
Como nosso amigao "Fabio" disse, muito inteligentemente, nos fez enxergar o verdadeiro modo de ler e refletir sobre um assunto e ser capaz de comertar tao bem depois..
Apenas mudando algumas ideias, superficialmente, pois ainda nao refleti totalmente, eu acho que: O artigo foi muito interessante, pois consegui descobrir que tipo de programador sou, e com base nele pretendo melhorar meu desempenho em desenvolvimento de software.
Ótimo artigo. Realmente temos algumas manias muito 'toscas', desperdiçamos nosso tempo apenas programando, e não nos preocupamos muito com a documentação.
Sabias palavras do nosso amigo Vini.
Só tenho uma coisa a comentar a respeito disso: O artigo foi muito interessante, pois consegui descobrir que tipo de programador sou, e com base nele pretendo melhorar meu desempenho em desenvolvimento de software.
O artigo mostra que nosso amigo aprendeu muito durante sua vida de programação. Algumas coisas são óbvias, como um bom programador ser mais produtivo do que um programador na média, mas outras são realmente interessantes, como gastar 10 a 20% do seu tempo programando.
A partir da leitura do tópico sobre algumas verdades pouco conhecidas sobre a programação, pudemos ver que somos programadores de muito baixo nível, pois desperdiçamos um tempo absurdamente grande somente corrigindo o código, sendo que se estudássemos um pouco mais como implementá-lo, conseguiríamos "enxugar" um pouco mais o código e deixá-lo mais plástico e limpo, gastando um tempo maior para desenvolver poucas linhas, mas linhas que não serão alteradas para correção, o que acaba economizando tempo.
Mas, como os outros colegas disseram e o amigão Fábio:
"O artigo foi muito interessante, pois consegui descobrir que tipo de programador sou, e com base nele pretendo melhorar meu desempenho em desenvolvimento de software."
Concordo em partes com o autor, mas com minha experiência na área, sendo principalmente baseada em projetos e pequenos problemas. No começo já começava codificando, sem antes ter pensando em uma solução realmente funcional e acabava gastando tempo em corrigir possíveis erros e na maioria das vezes tinha que voltar e pensar em uma solução realmente funcional. Logo aprendi, que ser um bom programador é saber resolver problemas e para isso devemos pensar realmente no problema, depois na sua solução e por fim codificar o problema. Chego à conclusão, que seria 70% como resolver o problema e 30% em transformar a resolução em código, logo para ser um bom programador é ter soluções para os problemas e uma boa base em diversos problemas diferentes, logo muito treino e um pouco de teoria.
Realmente é um texto muito interessante e sobre o qual é possível refletir bastante. Mas, apesar de entender o ponto de vista e as explicações do texto, não consigo concordar totalmente com ele.
Acredito que um bom sistema deva sim ser pensado e planejado antes e durante a sua codificação, mas não acredito que para isso seja necessário gastar 90% de seu tempo de projeto e pensar nisso 24/7.
Após definido os primeiros problemas e escopo geral do projeto, já é um bom ponto para começar a dar forma a tudo que foi planejado, a começar a codificar, pois certos problemas e condições, mesmo com um bom planejamento, só são encontrados durante a codificação, pois nem sempre tudo que foi planejado pode ser codificado exatamente como se havia pensado.
Planejamento e documentação de um projeto é algo realmente importante, porém a codificação também é muito importante pois como já foi dito, certos detalhes só são corretamente enxergados durante esta fase.
Bom.. fazendo um comentario serio agora vai professor.. *-*
Acho q o planejamento é muito importante, seja qual for a atividade a ser realizada. Ainda mais programando, pois se for programar direto e sem planejar, suas chances de erro sao grandes, alem de se errar ter q mudar quase o projeto todo.
Como estamos vendo em aula, estamos aprendendo muito mais vendo casos de uso e etc.. do que se fossemos programar e programar sem nenhum plnejamento, até porque se um dia precisarmos fazer um projeto diferente do aprendido em aula, teremos muito mais dificuldades pois nao saberiamos planejar e só programar, e programar um codigo espcifico(aprendido em aula) e os projetos sao diferentes..
Bom [é isso, pode ter ficado meio confuso, mas eu explicando sou melhor q eu escrevendo..
Mas é isso, sucesso ai professor!
A perte mais relevante do texto é a opnião que diz que "bons programadores pensam antes de escrever um codigo o que gera menos dor de cabeça para concertar depois"
isso eu concordo interamente.
É verdade que o processo de planejamento da estrutura dos codigos é fundamental pois evita muitos desabores mais tarde como concertar erros de
bugs (o que gera trabalho em dobro ou triplo...) mas a parte da codificação em sí também é muito importante pois é necessário boa abilidade em codificar para conseguir resolver
problemas de forma eficiente.
Chuto que a relação de importância entra as duas seria: de 40% codificando e 60% planejando.é só um chute pois não tenho experiências na prática...
A perte mais relevante do texto é a opnião que diz que "bons programadores pensam antes de escrever um codigo o que gera menos dor de cabeça para concertar depois"
isso eu concordo interamente.
É verdade que o processo de planejamento da estrutura dos codigos é fundamental pois evita muitos desabores mais tarde como concertar erros de
bugs (o que gera trabalho em dobro ou triplo...) mas a parte da codificação em sí também é muito importante pois é necessário boa abilidade em codificar para conseguir resolver
problemas de forma eficiente.
Chuto que a relação de importancia entra as duas seria: de 40% codificando e 60% planejando.é so um chute pois não tenho experiência na prática.
Esta publicação sobre programação, mostra como programar vai muito mais além de somente escrever linhas de código.
Para David Veksler, 90% do tempo de um software é composto pela parte abstrata, pensar, pensar e pensar!
Eu não acredito que seja exatamente assim para todos os casos, depende muito do programa e do programador.
Mas eu acredito, e já comprovei que, analisar, estudar e pensar no programa antes de escreve lo, resulta em ganho de tempo e um programa de maior eficiência.
Um programador completo é um profissional com conhecimentos em diversas áreas, além de um grande conhecimento em programação. Isso prova que, assim como a publicação diz: programar é um trabalho difícil.
Quem nunca ouviu a frase " Quem não usa a cabeça, trabalha por dois", é isso, sem pensar, irá perder horas programando.
Um forte abraço e bora programar!!!
Eu acho que houve uma generalização desnecessária a respeito
que todo programador ruim passam tempo mudando o código tentando
tirar bugs, eles fazem isso procurando melhorar o código fazendo
as mudanças necessárias, claro que tem aquela parcela que quanto mais
mexe no problema pior fica. Acho que endeusaram demais o bom programador,
claro que o mesmo acaba sendo mas eficiênte que os demais, mas na maioria
das vezes todo mundo acaba chegando em um solução que não se diferenciam muito
em si. Eu concordo que mudar constantemente um software o deixe ruim, talvez isso
seja mais importante que o cliente, por isso é importante fazer um planejamento antes
Concordo em partes que adicionar mais tempo no trabalho ou mais pessoas no projeto
pode ter um efeito negativo, mas depende da situação, adicionar pessoas evita uma
sobrecarga encima do programador, isso se a pessoa trabalha melhor livre de pressão.
Concordo com algumas idéias e vivo algumas na prática, quanto melhor a análise e o entendimento do processo a chance de acertar na programação é maior. O retrabalho é desperdícil de tempo em um projeto grande pode comprometer seriamente a sua entrega. É comprovado cientificamente em estudos que a vida útil e a manutenção barata de um sistema deve-se á uma análise e coompreesão de um projeto.
A profissão de programador e muito mais exigida que as demais, em relação ao desempenho,podendo ser ate prejuizo pra uma empresa contratar um programador medio,diante disso aprendi que tenho que ser o melhor programador.
Postar um comentário