OFF: VB.NET X C#
PessoALL,
Vou expor minha opinião sobre o assunto e gostaria de saber a opinião de vocês. Mas SEM gerar brigas infrutÃferaas, okay? Pode ser?
Em primeiro lugar...
1º) Vamos [Ô]pôr no gráfico[Ô], observando o [Ô]TIOBE Index for April 2015[Ô] (vi pelo site do Macoratti):
=============================================================
» .NET - As linguagens de programação mais populares (posição abril/2015)
Enviado por: Macoratti | Data: 1/5/2015
http://www.macoratti.net/15/05/net_pop1.htm
=============================================================
[th]Apr 2015
Existem gráficos mais especÃficos dentro do site da TIOBE.
Aparentemente este gráfico ficou +/- estável, mas se você observar os detalhes...
... percebemos a liderança do Java (*parâmetro geral em todas as áreas da programação, sistemas transacionais, sistemas embarcados, tablets, notebooks, desktops, geladeiras (opa! A geladeira está em sistemas embarcados!), etc. Puxa! pensei que o RUBY iria crescer com o tempo, mas acho que ele é acadêmico demais.... vai saber...
Outras assunto: O que é [Ô]Visual Basic[Ô]? Será o velho, obsoleto, sem suporte e não-orientado a objeto (mas orientado à eventos) VB6???
Onde eu queria chega (Aleluia!) ... é que (pelo menos no Brasil) vemos uma crescente FEBRE por C#. Porxa, tenho certeza que o C# ANTES da versão 2010 era superior ao VB.Net, mas hoje em dia acredito que está pau-a-pau com a diferença que é bem mais fácil de usar.
Última observação refere-se ao post de hoje do Macoratti:
=============================================================
C# - Tudo certo como dois e dois são cinco
Enviado por: Macoratti | Data: 13/5/2015
http://www.macoratti.net/15/04/c_matc1.htm
=============================================================
Veja que no VB.Net no caso de estouro do tamanho de uma variável apresenta uma mensagem de erro:
[Ô]An unhandled exception of type [ô]System.OverflowException[ô] occurred in Matematica_VBNET.exe[Ô]
Já o C#, simplesmente dá uma de [Ô]desentendido[Ô] e apresenta uma valor: [Ô]-294967296[Ô].
Na minha opinião, o VB.Net assessora muito melhor o programador tornando a programação mais fácil, vide que o VB.Net nem tem restrição de [Ô]case sensitive[Ô].
Será que existem real vantagem, velocidade, performance de processamento, tamanho do campo do C# em relação ao VB.Net ou tudo vira um código fonte só no compilador [Ô]MSIL - MicroSoft Intermediate Language[Ô] tonando os códigos (VB.Net e C#) idênticos no final do funil?
Obrigado,
Tunusat.
Vou expor minha opinião sobre o assunto e gostaria de saber a opinião de vocês. Mas SEM gerar brigas infrutÃferaas, okay? Pode ser?
Em primeiro lugar...
1º) Vamos [Ô]pôr no gráfico[Ô], observando o [Ô]TIOBE Index for April 2015[Ô] (vi pelo site do Macoratti):
=============================================================
» .NET - As linguagens de programação mais populares (posição abril/2015)
Enviado por: Macoratti | Data: 1/5/2015
http://www.macoratti.net/15/05/net_pop1.htm
=============================================================
| Apr 2014 | Change | Programming Language | Ratings | Change | [/th]|
| 1 | 2 | + | Java | 16.041% | -1.31% |
| 2 | 1 | - | C | 15.745% | -1.89% |
| 3 | 4 | + | C++ | 6.962% | +0.83% |
| 4 | 3 | - | Objective-C | 5.890% | -6.99% |
| 5 | 5 | = | C# | 4.947% | +0.13% |
| 6 | 9 | + | JavaScript | 3.297% | +1.55% |
| 7 | 7 | = | PHP | 3.009% | +0.24% |
| 8 | 8 | = | Python | 2.690% | +0.70% |
| 9 | - | ++ | Visual Basic | 2.199% | +2.20% |
| 10 | 10 | = | Visual Basic .NET | 2.126% | +0.38% |
Existem gráficos mais especÃficos dentro do site da TIOBE.
Aparentemente este gráfico ficou +/- estável, mas se você observar os detalhes...
... percebemos a liderança do Java (*parâmetro geral em todas as áreas da programação, sistemas transacionais, sistemas embarcados, tablets, notebooks, desktops, geladeiras (opa! A geladeira está em sistemas embarcados!), etc. Puxa! pensei que o RUBY iria crescer com o tempo, mas acho que ele é acadêmico demais.... vai saber...
Outras assunto: O que é [Ô]Visual Basic[Ô]? Será o velho, obsoleto, sem suporte e não-orientado a objeto (mas orientado à eventos) VB6???
Onde eu queria chega (Aleluia!) ... é que (pelo menos no Brasil) vemos uma crescente FEBRE por C#. Porxa, tenho certeza que o C# ANTES da versão 2010 era superior ao VB.Net, mas hoje em dia acredito que está pau-a-pau com a diferença que é bem mais fácil de usar.
Última observação refere-se ao post de hoje do Macoratti:
=============================================================
C# - Tudo certo como dois e dois são cinco
Enviado por: Macoratti | Data: 13/5/2015
http://www.macoratti.net/15/04/c_matc1.htm
=============================================================
Veja que no VB.Net no caso de estouro do tamanho de uma variável apresenta uma mensagem de erro:
[Ô]An unhandled exception of type [ô]System.OverflowException[ô] occurred in Matematica_VBNET.exe[Ô]
Já o C#, simplesmente dá uma de [Ô]desentendido[Ô] e apresenta uma valor: [Ô]-294967296[Ô].
Na minha opinião, o VB.Net assessora muito melhor o programador tornando a programação mais fácil, vide que o VB.Net nem tem restrição de [Ô]case sensitive[Ô].
Será que existem real vantagem, velocidade, performance de processamento, tamanho do campo do C# em relação ao VB.Net ou tudo vira um código fonte só no compilador [Ô]MSIL - MicroSoft Intermediate Language[Ô] tonando os códigos (VB.Net e C#) idênticos no final do funil?
Obrigado,
Tunusat.
Desenvolvo em VB.Net e Java e pra mim VB.Net nunca vai deixar de ser queridinho...
Alguns dizem que C# é melhor pelo fato de achar muito mais conteúdo do que em VB.net mais até agora nunca tive problema com isso..
Sobre o C# acho bacana mais já que o sistema já foi iniciado em VB.Net e ta rodando pra que mexer e transformar tudo pra C#? sendo que eles
tem as mesmas coisas.. agora a partir do momento se o VB.Net sumir do Visual Studio 2015 por ex ai eu ja pensaria em migrar pro C#.. más
como vem andando lado a lado acho q não vale tanto a pena migrar por hora..
Alguns dizem que C# é melhor pelo fato de achar muito mais conteúdo do que em VB.net mais até agora nunca tive problema com isso..
Sobre o C# acho bacana mais já que o sistema já foi iniciado em VB.Net e ta rodando pra que mexer e transformar tudo pra C#? sendo que eles
tem as mesmas coisas.. agora a partir do momento se o VB.Net sumir do Visual Studio 2015 por ex ai eu ja pensaria em migrar pro C#.. más
como vem andando lado a lado acho q não vale tanto a pena migrar por hora..
Ah! A velha discussão C# vs. VB.NET! Já conversei muito, com muitos programadores sobre isso. Para encurtar a conversa, tudo se resume a preferência, nada mais. O que um faz, o outro também faz. O caso é que a maioria dos programadores não entendem bem o que é a plataforma .NET. Não se trata da linguagem de front-end, mas sim de um Framework completo, capaz de interpretar múltiplas linguagens, até mesmo é possÃvel ter vários projetos de diferentes linguagens em uma mesma solution e o Framework é capaz de compilar isso sem problemas. Como já disse, o caso é entender a plataforma. Muitos programadores confundem a IDE Visual Studio com o .NET Framework em si. [Ô]Ah, o 2010 não faz isso ou aquilo[Ô], [Ô]A versão express não é boa...[Ô] e muitos outros comentários que não fazem nem sequer sentido. Para começo de conversa, o Visual Studio nem sequer é necessário para se criar um programa em .NET, é possÃvel até mesmo usar o bloco de notas, escrever tudo à mão e executar a compilação no prompt de comando. Claro que seria uma trabalheira desnecessária e muito sujeito a erros que seriam prontamente detectados pelo JIT(Just-In-Time debugger), mas o caso é que o Visual Studio é simplesmente a ferramenta para facilitar escrever código em uma das linguagens de Front-End(que são várias, não só VB.NET ou C#), ele possui vários recursos para que você possa ser mais produtivo. Quando se referir à .NET, o mais correto é citar a versão do Framework, essa sim é a coisa que faz diferença. A IDE(Visual Studio), pode trabalhar com várias versões do .NET framework e é nela que estão os recursos em si. Quem já programou em Clipper vai conhecer muito bem a sequencia: Você usa um editor qualquer para escrever seu programa, roda o compilador Clipper, que transforma o seu programa criado em um editor qualquer em um(ou vários) arquivos OBJ. Esses arquivos OBJ, são em seguida transferidos à um outro executável, que transforma os OBJ em um arquivo executável. Com o .NET framework é parecido. Você usa um editor para escrever seu programa, em seguida ocorre uma compilação do mesmo para uma linguagem intermediária(MSIL) e somente depois disso vai ser transformado em executável ou website. Então o caso é entender a plataforma. Minha opinião pessoal, é que qualquer programador .NET deve ser fluente tanto em C# quanto em VB.NET, isso não deve ser nenhum problema. Mas o modo de pensar da maioria dos programadores vindos de linguagens mais procedurais como o nosso querido VB6, deve ser modificado. Não se deve usar uma bazuca para matar uma mosca, assim como não se deve usar .NET para programar do mesmo modo que se fazia com VB6. O VB.NET apenas herdou a sintaxe e ainda assim, algumas adaptações à essa sintaxe foram feitas, para poder usar ao máximo todos os recursos que o .NET Framework oferece. Volto a bater na mesma tecla que bato sempre: Não se prenda a linguagem humana, entenda a estrutura, como a coisa funciona que todo o resto virá naturalmente. Uma comparação, seria assim: Você aprendeu a dirigir em uma brasÃlia. Direção dura, marcha manual. Se você pegar um carro com direção hidráulica e marcha automática você vai conseguir dirigir? Se você entender o princÃpio da ação de dirigir(pisar nos pedais, girar o volante), você terá um curto perÃodo de adaptação ao novo modo, mas você vai acabar conseguindo. Com programação é assim. Seja VB.NET ou C#, se você entender como deve ser usado, você vai conseguir adaptar de uma para outra sem o menor problema.
KERPLUNK,
Okay, concordo com você. Mas antes da versão .Net 2008 não era bem assim... Embora no Wikipédia diga que desde a versão do Visual Studio .Net 2002 já seu usava MSIL. Talvez o MSIL não tratava bem código VB.Net e tratava melhor código C#, sei lá.
Eu me lembro de ter feito um curso de .Net 2005 no qual o instrutor enfatizou que algumas coisas não funcionavam bem em VB.Net e funcionavam certinho em C#. E ele demostrou isso, mas era projetos bem especÃficos usando portas de comunicação ou algo assim. Acho que hoje em dia tudo está bem equiparado.
=========================
Visual Studio .NET
http://pt.wikipedia.org/wiki/Visual_Studio_.NET
=========================
Compilação para MSIL
https://msdn.microsoft.com/pt-br/library/c5tkafs1(v=vs.90).aspx
=========================
[][ô]s,
Tunusat.
Okay, concordo com você. Mas antes da versão .Net 2008 não era bem assim... Embora no Wikipédia diga que desde a versão do Visual Studio .Net 2002 já seu usava MSIL. Talvez o MSIL não tratava bem código VB.Net e tratava melhor código C#, sei lá.
Eu me lembro de ter feito um curso de .Net 2005 no qual o instrutor enfatizou que algumas coisas não funcionavam bem em VB.Net e funcionavam certinho em C#. E ele demostrou isso, mas era projetos bem especÃficos usando portas de comunicação ou algo assim. Acho que hoje em dia tudo está bem equiparado.
=========================
Visual Studio .NET
http://pt.wikipedia.org/wiki/Visual_Studio_.NET
=========================
Compilação para MSIL
https://msdn.microsoft.com/pt-br/library/c5tkafs1(v=vs.90).aspx
=========================
[][ô]s,
Tunusat.
Hoje VB.Net e C# estão equiparados, e o resultado ao cliente final vai ser o mesmo, mesmo sendo desenvolvido em VB.Net ou C#..
O Que o pessoal diz é que C# tem muito mais conteúdo na internet que VB.Net más até agora não tive problema com isso.. por isso o pessoal anda falando melhor do C#.. más os dois fazem a mesma coisa.. Concordo com o KERPLUNK, e acho errado as pessoas acomodadas que pensam [Ô]Ah desenvolvo em VB.net então não preciso aprender C#[Ô]..
O Que o pessoal diz é que C# tem muito mais conteúdo na internet que VB.Net más até agora não tive problema com isso.. por isso o pessoal anda falando melhor do C#.. más os dois fazem a mesma coisa.. Concordo com o KERPLUNK, e acho errado as pessoas acomodadas que pensam [Ô]Ah desenvolvo em VB.net então não preciso aprender C#[Ô]..
No m eu ponto de vista, apenas DOIS pontos diferenciam C# de VB.NET.
Conteúdo dissiminado na web
Sintaxe de escrita do código.
Conteúdo dissiminado na web
Sintaxe de escrita do código.
MESTRE, KERPLUNK and FOXMAN,
Sim, acho que nós fazermos o código (não importando se VB.Net ou C#) e depois é compilado tudo para um CL (Common Language), para finalmente ser link-editado, gerando um produto-final exatamente com a mesma performance de processamento... bom ... isso se os códigos VB.Net e C# forem [Ô]idênticos[Ô] (entre aspas).
Mas como colocar na cabeça dos gerentes e usuários que tanto faz fazer em um ou em outro?
Ou então a intenção deles é passar tudo para C#, matar o VB.Net e nivelar o salário de todos por baixo?
[][ô]s,
Tunusat.
Sim, acho que nós fazermos o código (não importando se VB.Net ou C#) e depois é compilado tudo para um CL (Common Language), para finalmente ser link-editado, gerando um produto-final exatamente com a mesma performance de processamento... bom ... isso se os códigos VB.Net e C# forem [Ô]idênticos[Ô] (entre aspas).
Mas como colocar na cabeça dos gerentes e usuários que tanto faz fazer em um ou em outro?
Ou então a intenção deles é passar tudo para C#, matar o VB.Net e nivelar o salário de todos por baixo?
[][ô]s,
Tunusat.
Citação:No m eu ponto de vista, apenas DOIS pontos diferenciam C# de VB.NET.
Conteúdo dissiminado na web
Sintaxe de escrita do código.
Exatamente isso que eu penso também..
Citação:Sim, acho que nós fazermos o código (não importando se VB.Net ou C#) e depois é compilado tudo para um CL (Common Language), para finalmente ser link-editado, gerando um produto-final exatamente com a mesma performance de processamento... bom ... isso se os códigos VB.Net e C# forem [Ô]idênticos[Ô] (entre aspas).
Mas como colocar na cabeça dos gerentes e usuários que tanto faz fazer em um ou em outro?
Ou então a intenção deles é passar tudo para C#, matar o VB.Net e nivelar o salário de todos por baixo?
Na verdade as vezes não é nem o usuário, mais os gerentes mesmo.. acho que eles querem padronizar uma linguagem só nos projetos.. más falar mal do VB.Net isso é errado, um cara que desenvolve em C# falar que C# é melhor é puro fanatismo e não sabe da besteira que tá falando.. normalmente quem fala mal do .NET são os desenvolvedores Java .. ja ouvi várias piadinhas na facul de alunos e até mesmo do professor dizendo (Então java não é que nem o .Net que você arrastou tá pronto) quase mostrei pra ele o arrastou tá pronto kkkkkkk.
TUNUSAT, Só para dar um [Ô]pitaco[Ô].
Como foi dito, as versões 2002 e 2003 do Visual Studio [Ô]carregaram[Ô] algumas diferenças que já existiam entre o VB6 e o C++, é fato. Mas desde a versão 2005, aquela que trazia o JSharp, essa história acabou. Ou seja, há uma década, VB.Net, CSharp e outras linguagens da plataforma são todas convertidas para um mesmo formato, de modo que não há diferenças de desempenho.
No entanto, isso não quer dizer que o VB e o CSharp são 100% idênticos, não. Há diferenças ainda, além da sintaxe, notadamente no tocante ao tratamento de números. Parece brincadeira, mas não é. E reforço, nesse sentido, o que disse o TUNUSAT.
Ao usar o CSharp. o tratamento de estouros de tipos é bastante diferente, e por padrão, não mostra esses estouros como erro. Desse modo, o código final, já convertido, pode não apresentar erro nenhum, mas ainda assim, ter resultados errados. Já com o VB, isso não ocorre, pois uma excessão é disparada. Desconfio, mas não sei se, ao converter para CL, o que é VB acessa bibliotecas matemáticas distintas daquelas usadas quando é CSharp, mas acontece o problema.
Por favor, não interpretem errado: Eu não estou fazendo apologia nenhuma.
Mas a questão sobre essa ou aquela linguagem ser a [Ô]preferida[Ô] nas empresas não tem nada á ver com a suposta [Ô]qualidade[Ô] da linguagem, se é que isso existiria. é uma questão fundamentalmente econômica. Veja bem:
Ao criar um dispositivo mecânico, uma empresa busca componentes que possam ser facilmente encontrados e que tenha vários fornecedores. Isso torna o componente mais barato e, mais tarde, a empresa não vai ficar [Ô]nas mãos[Ô] de um só fornecedor.
Da mesma forma, se há mais desenvolvedores Java ou PHP no mercado, contratar um desenvolvimento em Fortran ou em ADA não é uma decisão interessante, pois será mais caro e bem mais difÃcil repor a mão-de-obra. Isso é o que importa, e assim, vagas para CSharp, Java e PHP são muito mais comuns, pois há mais profissionais atualizados para essas atividades, acarretando um custo mais baixo e uma substituição mais fácil.
Não é nenhuma novidade, é um fato. Há dez anos atrás, o mesmo acontecia com o VB6, e há 20 anos atrás, com o Clipper.
A diferença entre hoje e 20 anos atrás é que hoje qualquer quitanda, barzinho, birosca, tem computador, usa sistemas comerciais e por esse motivo, vai atrás do prestador de serviços, ao passo que até a década de 90, era o desenvolvedor quem saia para o mercado com uma ideia, ou ás vezes com um produto já pronto, ou seja, era ele quem escolhia plataforma, linguagem, IDE, a base de dados etc. Como não havia tanto interesse na área, eram os desenvolvedores que buscavam também o material para se aprimorar, de acordo com o seu interesse próprio, ao passo que hoje, há muita divulgação e incentivo, principalmente quando se fala da Internet. Por exemplo, com poucos minutos de trabalho, dá para criar um site inteiro, responsivo e contemporâneo, sem nem sequer saber alguma linguagem de programação, usando apenas um smartphone. Antigamente, você tinha de usar um FrontPage, um Macromedia Dreamweaver e similares, perder alguns dias de trabalho e ainda apresentar um resultado questionável.
Mais tarde vou postar outra mensagem para dizer o que eu acho que seja o problema de verdade.
Como foi dito, as versões 2002 e 2003 do Visual Studio [Ô]carregaram[Ô] algumas diferenças que já existiam entre o VB6 e o C++, é fato. Mas desde a versão 2005, aquela que trazia o JSharp, essa história acabou. Ou seja, há uma década, VB.Net, CSharp e outras linguagens da plataforma são todas convertidas para um mesmo formato, de modo que não há diferenças de desempenho.
No entanto, isso não quer dizer que o VB e o CSharp são 100% idênticos, não. Há diferenças ainda, além da sintaxe, notadamente no tocante ao tratamento de números. Parece brincadeira, mas não é. E reforço, nesse sentido, o que disse o TUNUSAT.
Ao usar o CSharp. o tratamento de estouros de tipos é bastante diferente, e por padrão, não mostra esses estouros como erro. Desse modo, o código final, já convertido, pode não apresentar erro nenhum, mas ainda assim, ter resultados errados. Já com o VB, isso não ocorre, pois uma excessão é disparada. Desconfio, mas não sei se, ao converter para CL, o que é VB acessa bibliotecas matemáticas distintas daquelas usadas quando é CSharp, mas acontece o problema.
Por favor, não interpretem errado: Eu não estou fazendo apologia nenhuma.
Mas a questão sobre essa ou aquela linguagem ser a [Ô]preferida[Ô] nas empresas não tem nada á ver com a suposta [Ô]qualidade[Ô] da linguagem, se é que isso existiria. é uma questão fundamentalmente econômica. Veja bem:
Ao criar um dispositivo mecânico, uma empresa busca componentes que possam ser facilmente encontrados e que tenha vários fornecedores. Isso torna o componente mais barato e, mais tarde, a empresa não vai ficar [Ô]nas mãos[Ô] de um só fornecedor.
Da mesma forma, se há mais desenvolvedores Java ou PHP no mercado, contratar um desenvolvimento em Fortran ou em ADA não é uma decisão interessante, pois será mais caro e bem mais difÃcil repor a mão-de-obra. Isso é o que importa, e assim, vagas para CSharp, Java e PHP são muito mais comuns, pois há mais profissionais atualizados para essas atividades, acarretando um custo mais baixo e uma substituição mais fácil.
Não é nenhuma novidade, é um fato. Há dez anos atrás, o mesmo acontecia com o VB6, e há 20 anos atrás, com o Clipper.
A diferença entre hoje e 20 anos atrás é que hoje qualquer quitanda, barzinho, birosca, tem computador, usa sistemas comerciais e por esse motivo, vai atrás do prestador de serviços, ao passo que até a década de 90, era o desenvolvedor quem saia para o mercado com uma ideia, ou ás vezes com um produto já pronto, ou seja, era ele quem escolhia plataforma, linguagem, IDE, a base de dados etc. Como não havia tanto interesse na área, eram os desenvolvedores que buscavam também o material para se aprimorar, de acordo com o seu interesse próprio, ao passo que hoje, há muita divulgação e incentivo, principalmente quando se fala da Internet. Por exemplo, com poucos minutos de trabalho, dá para criar um site inteiro, responsivo e contemporâneo, sem nem sequer saber alguma linguagem de programação, usando apenas um smartphone. Antigamente, você tinha de usar um FrontPage, um Macromedia Dreamweaver e similares, perder alguns dias de trabalho e ainda apresentar um resultado questionável.
Mais tarde vou postar outra mensagem para dizer o que eu acho que seja o problema de verdade.
Para finalizar, o problema - se é que se pode chamar assim - é a facilidade de acesso à informação, mas é principalmente a completa falta de postura do profissional de desenvolvimento de sistemas. Digo isso sem ofensas, por favor, e eu explico:
Hoje, quem recebe o conteúdo acadêmico e o treinamento para atuar na área de desenvolvimento, não pesquisa nem procura saber se há alternativas de linguagem, de bases de dados, de plataformas. Simplesmente [Ô]engolem[Ô] o que lhes ensinam e, só depois de formados, já no mercado, é que passam a apresentar algum interesse por essa ou aquela corrente. Dessa forma, não cobram das entidades de ensino e dos cursos (livres ou certificados) que haja um conteúdo diversificado. E ainda, pela mesma razão, ou seja, se formam sem nenhum outro interesse senão [Ô]arrumar um emprego[Ô], chegam ao mercado com aquela [Ô]garra[Ô] e [Ô]dinamismo[Ô] que os levam a desvalorizar, não apenas a própria capacidade laborativa, mas também a de todos os demais profissionais, e aceitam qualquer oferta de remuneração, por temor de ficar sem trabalho.
Assim, quanto mais o tempo avança, menos receberá o desenvolvedor de sistemas que não é, de fato, afeito á atividade. E ao mesmo tempo, aqueles poucos que de fato têm interesse e fazem o que fazem por gosto e satisfação pessoal, acabam mais cedo ou mais tarde sendo reconhecidos e se estabelecendo com uma remuneração mais alta que a média.
O verdadeiro problema, então, na minha opinião, não é linguagem de programação, mas sim profissional de desenvolvimento. Apesar de tão mais fácil hoje em dia o acesso à informação, o bom profissional não é aquele que as empresas contratam para cobrir vagas, esse é só o [Ô]peão[Ô] do desenvolvimento.
é preciso, ao bom profissional:
1. Gostar do que faz – Sem interesse pessoal, o profissional acaba sempre no tédio da rotina e se torna improdutivo;
2. Abraçar as dificuldades – Sempre que algo sai errado, ao invés de enxergar um problema, entenda que se trata de um desafio, e isso é sempre uma oportunidade de se superar, de conquistar conhecimento e acumular experiência.
3. Saber dizer não – A primeira questão: seu trabalho custa caro, e você é quem tem a obrigação de defender isso. Se o valor ofertado é baixo, pode ser mais lucrativo vender sanduiches naturais para o pessoal do mesmo escritório. Só para comparar, se eu prestar serviços de faxina, a diária aqui onde moro não sai por menos de R$ 130,00 e há trabalho para todos os dias, então, por qual razão eu deveria aceitar um valor mensal de R$ 1.500,00 como desenvolvedor e “queimar miolo†com problemas alheios, se eu posso ganhar R$ 2.600,00, muitas vezes trabalhando menos? A segunda questão: Se o cliente me pede alguma coisa que legalmente é questionável, você precisa saber que, independentemente de ser funcionário ou prestador de serviços, quem responderá judicialmente pela implementação da rotina e seu eventual uso, será você. Na balança, será que compensa fazer? Terceira questão: O processo que o cliente informou não faz sentido, é apenas mais um “apêndice†no sistema. Em teoria, o problema é do cliente, se ele quer perder tempo ou não, mas a obrigação do bom profissional é sempre orientar no sentido de um melhor desempenho, com menor custo e facilidade na manutenção. Muitas vezes, o cliente pede um processo porquê já fazia assim e está acostumado, mas não percebeu que há alternativas. Outras vezes, é o profissional quem não entendeu as razões, a motivação do processo. Assim, mesmo que o cliente informe tudo em detalhes, é obrigação do bom profissional questionar cada passo de cada processo, até não haver mais dúvidas, e dizer “não†aos processos que não façam sentido.
4. Orientar conscientemente – O bom profissional visualiza o cliente ou a empresa sempre no contexto futuro, e assim, não orienta ao uso de um determinado mecanismo de dados só porque é aquele que ele conhece, ou porque já tem instalado em seu ambiente de desenvolvimento. Acompanhei uma situação prática no final dos anos 90. Uma empresa contratou um prestador de serviços, que criou aplicação em VB6 e base de dados em MS-Access, e uns meses depois, optou por montar uma lanchonete e abandonou a atividade de desenvolvimento. Anos depois, o sistema ainda funcionava sem nenhum problema, mas extremamente lento. Depois de algumas análises, cheguei à conclusão de que o código-fonte era impecável, boas regras, boa documentação, bem orientado, mas, infelizmente, a base de dados não tinha nem de perto “arranhado†o conceito de normatização, e ao criar o modelo normatizado, era visÃvel que o Jet como mecanismo não seria suficiente para garantir o desempenho. No relatório da análise, mostrei os problemas e ofereci ao cliente a opção do MS-SQL Server, com uma proposta de valor pela prestação dos serviços. O que eu não sabia, é que a empresa havia feito cotação com outros prestadores de serviço e, um deles, apesar de apresentar valores mais altos, oferecia como opções de base de dados o MS-SQL Server, o Oracle e o Firebird. A empresa acabou por descartar a minha proposta. Se eu houvesse feito uma análise mais apurada, saberia que a empresa já possuÃa outras aplicações usando o Oracle, e o teria incluÃdo na minha proposta. Mas eu me deixei levar pelo meu ambiente de trabalho, e acabei arcando com as consequências.
5. Regras, regras, regras – O maior desafio de um bom profissional é criar regras de trabalho coerentes e que ele siga impreterivelmente. Um tópico difÃcil, pois essas regras não são tão genéricas assim, elas “nascem†da vivência e experiência do profissional. Mas para dar uma ideia, imagine o seguinte: é mais fácil desenhar um formulário de atendimento médico do que administrar a recepção de um hospital, certo? Da mesma forma, ainda que a análise de sistema gere um módulo chamado “Recepção Hospitalarâ€, será muito mais fácil implementar esse módulo se eu o dividir em tarefas ou passos, um dos quais é o desenho do formulário de atendimento médico. Isso serve para qualquer problema: Divida-o até que não seja mais possÃvel, e cada uma das divisões encontradas terá uma solução simples, que, em conjunto, compõe a solução do problema. Bem, essa é uma regra fácil de seguir. Outra regra, é a de sempre imaginar obstáculos à uma solução, de forma que o resultado final seja mais “blindadoâ€. Por exemplo: O problema é criar um editor gráfico para HTML. Uma vez que você criou um componente baseado na StringBuilder com um dicionário de tags, e que em tese faz o que é necessário para solucionar o problema, imagine agora como o usuário final vai “destruir†a sua solução. Por exemplo, o usuário pode precisar utilizar CSS, além de HTML, ou pode ainda precisar usar um Twitter Boostrap ou outra biblioteca baseada em jQuery, e só isso já inutiliza sua solução. Seja qual for o conjunto de regras que você vá desenvolvendo para o seu dia-a-dia, o mais importante é se convencer a seguir sempre essas regras, sem exceções.
6. Sempre estar atualizado – Não é fácil, apesar da facilidade de acesso â informação, estar sempre em dia com as últimas novidades, pois quando você tem trabalho a fazer e compromissos firmados, entender uma nova metodologia, componente ou conceito pode parecer perda de tempo. Mas, ao contrário disso, é somente assim que o bom profissional pode se poupar de muito trabalho na tarefa conhecida como “reinventar a rodaâ€. Por exemplo, no VB6, a biblioteca Microsoft VBScript Regular Expressions 5.5 traz uma facilidade enorme na validação de entradas de dados, mas pouquÃssimas pessoas sabem como usar essa biblioteca, e “para ganhar tempoâ€, criam rotinas das mais variadas para a mesma finalidade. Esse é um exemplo pequeno, mas há muitos outros.
7. Conhecer-se a si mesmo – O bom profissional sabe quais são os seus limites e as suas dificuldades. Dessa forma, ele não passa ao cliente uma ideia de prazo de entrega sem antes considerar uma margem de segurança de ao menos 60% em relação ao prazo no qual ele de fato possa cumprir. Além de imprevistos por parte do profissional, podem ocorrer imprevistos por parte do cliente, e ainda assim, o prazo será coerente. Da mesma forma, o bom profissional sabe que não sabe tudo e sabe o que não sabe, e não tem medo de, no momento que a situação se apresente, perguntar. Com isso, ele não promete cumprir tarefas das quais ele não possa garantir a qualidade ou a confiabilidade.
8. Conhecer “pesos e medidas†sociais – O bom profissional é um ser humano, e como tal, ele tem uma imagem, que é aquela que os outros enxergam. Estar sempre fazendo piadas e comentários jocosos não ajuda profissionalmente em nada, pode até mesmo atrapalhar. Da mesma forma, ser extremamente técnico 100% do tempo acaba por passar uma impressão de “criatura antissocialâ€, ou até mesmo aquela figura racional estereotipada do personagem Spok de Jornada Nas Estrelas, que não é todo mundo que quer fazendo parte da equipe. é importante fazer amizades, é importante transmitir confiança e é importante compartilhar, mas tudo isso dentro de limites que não causem impacto negativo nos outros e sempre considerando o bom ambiente do empreendimento. A imagem profissional é algo que precisa ser definido, cultivado e aprimorado, sempre, pois é essa imagem que “vende†o seu trabalho.
9. Não esperar a chuva parar – Nem sempre a solução de um problema é encontrada apenas olhando-se o Google ou o Bing. Afinal, cada situação é única, mesmo aquelas que sejam parecidas. Nesses momentos, o bom profissional é aquele que expõe suas dificuldades ao cliente, ao patrão e à sua equipe, e em seguida, produz uma reanálise do problema e começa a elaborar passos para chegar à uma solução. Claro, todo mundo sabe que isso é o procedimento esperado, mas curiosamente, é muito mais comum do que deveria ser, o profissional que “despeja†os problemas na Internet e fica sentado, esperando os outros resolverem por ele.
10. Saber receber crÃticas – Não é porque a solução que você criou foi fruto de um processo laboral enorme que ela vai agradar todo mundo. Aliás, se ela func
Hoje, quem recebe o conteúdo acadêmico e o treinamento para atuar na área de desenvolvimento, não pesquisa nem procura saber se há alternativas de linguagem, de bases de dados, de plataformas. Simplesmente [Ô]engolem[Ô] o que lhes ensinam e, só depois de formados, já no mercado, é que passam a apresentar algum interesse por essa ou aquela corrente. Dessa forma, não cobram das entidades de ensino e dos cursos (livres ou certificados) que haja um conteúdo diversificado. E ainda, pela mesma razão, ou seja, se formam sem nenhum outro interesse senão [Ô]arrumar um emprego[Ô], chegam ao mercado com aquela [Ô]garra[Ô] e [Ô]dinamismo[Ô] que os levam a desvalorizar, não apenas a própria capacidade laborativa, mas também a de todos os demais profissionais, e aceitam qualquer oferta de remuneração, por temor de ficar sem trabalho.
Assim, quanto mais o tempo avança, menos receberá o desenvolvedor de sistemas que não é, de fato, afeito á atividade. E ao mesmo tempo, aqueles poucos que de fato têm interesse e fazem o que fazem por gosto e satisfação pessoal, acabam mais cedo ou mais tarde sendo reconhecidos e se estabelecendo com uma remuneração mais alta que a média.
O verdadeiro problema, então, na minha opinião, não é linguagem de programação, mas sim profissional de desenvolvimento. Apesar de tão mais fácil hoje em dia o acesso à informação, o bom profissional não é aquele que as empresas contratam para cobrir vagas, esse é só o [Ô]peão[Ô] do desenvolvimento.
é preciso, ao bom profissional:
1. Gostar do que faz – Sem interesse pessoal, o profissional acaba sempre no tédio da rotina e se torna improdutivo;
2. Abraçar as dificuldades – Sempre que algo sai errado, ao invés de enxergar um problema, entenda que se trata de um desafio, e isso é sempre uma oportunidade de se superar, de conquistar conhecimento e acumular experiência.
3. Saber dizer não – A primeira questão: seu trabalho custa caro, e você é quem tem a obrigação de defender isso. Se o valor ofertado é baixo, pode ser mais lucrativo vender sanduiches naturais para o pessoal do mesmo escritório. Só para comparar, se eu prestar serviços de faxina, a diária aqui onde moro não sai por menos de R$ 130,00 e há trabalho para todos os dias, então, por qual razão eu deveria aceitar um valor mensal de R$ 1.500,00 como desenvolvedor e “queimar miolo†com problemas alheios, se eu posso ganhar R$ 2.600,00, muitas vezes trabalhando menos? A segunda questão: Se o cliente me pede alguma coisa que legalmente é questionável, você precisa saber que, independentemente de ser funcionário ou prestador de serviços, quem responderá judicialmente pela implementação da rotina e seu eventual uso, será você. Na balança, será que compensa fazer? Terceira questão: O processo que o cliente informou não faz sentido, é apenas mais um “apêndice†no sistema. Em teoria, o problema é do cliente, se ele quer perder tempo ou não, mas a obrigação do bom profissional é sempre orientar no sentido de um melhor desempenho, com menor custo e facilidade na manutenção. Muitas vezes, o cliente pede um processo porquê já fazia assim e está acostumado, mas não percebeu que há alternativas. Outras vezes, é o profissional quem não entendeu as razões, a motivação do processo. Assim, mesmo que o cliente informe tudo em detalhes, é obrigação do bom profissional questionar cada passo de cada processo, até não haver mais dúvidas, e dizer “não†aos processos que não façam sentido.
4. Orientar conscientemente – O bom profissional visualiza o cliente ou a empresa sempre no contexto futuro, e assim, não orienta ao uso de um determinado mecanismo de dados só porque é aquele que ele conhece, ou porque já tem instalado em seu ambiente de desenvolvimento. Acompanhei uma situação prática no final dos anos 90. Uma empresa contratou um prestador de serviços, que criou aplicação em VB6 e base de dados em MS-Access, e uns meses depois, optou por montar uma lanchonete e abandonou a atividade de desenvolvimento. Anos depois, o sistema ainda funcionava sem nenhum problema, mas extremamente lento. Depois de algumas análises, cheguei à conclusão de que o código-fonte era impecável, boas regras, boa documentação, bem orientado, mas, infelizmente, a base de dados não tinha nem de perto “arranhado†o conceito de normatização, e ao criar o modelo normatizado, era visÃvel que o Jet como mecanismo não seria suficiente para garantir o desempenho. No relatório da análise, mostrei os problemas e ofereci ao cliente a opção do MS-SQL Server, com uma proposta de valor pela prestação dos serviços. O que eu não sabia, é que a empresa havia feito cotação com outros prestadores de serviço e, um deles, apesar de apresentar valores mais altos, oferecia como opções de base de dados o MS-SQL Server, o Oracle e o Firebird. A empresa acabou por descartar a minha proposta. Se eu houvesse feito uma análise mais apurada, saberia que a empresa já possuÃa outras aplicações usando o Oracle, e o teria incluÃdo na minha proposta. Mas eu me deixei levar pelo meu ambiente de trabalho, e acabei arcando com as consequências.
5. Regras, regras, regras – O maior desafio de um bom profissional é criar regras de trabalho coerentes e que ele siga impreterivelmente. Um tópico difÃcil, pois essas regras não são tão genéricas assim, elas “nascem†da vivência e experiência do profissional. Mas para dar uma ideia, imagine o seguinte: é mais fácil desenhar um formulário de atendimento médico do que administrar a recepção de um hospital, certo? Da mesma forma, ainda que a análise de sistema gere um módulo chamado “Recepção Hospitalarâ€, será muito mais fácil implementar esse módulo se eu o dividir em tarefas ou passos, um dos quais é o desenho do formulário de atendimento médico. Isso serve para qualquer problema: Divida-o até que não seja mais possÃvel, e cada uma das divisões encontradas terá uma solução simples, que, em conjunto, compõe a solução do problema. Bem, essa é uma regra fácil de seguir. Outra regra, é a de sempre imaginar obstáculos à uma solução, de forma que o resultado final seja mais “blindadoâ€. Por exemplo: O problema é criar um editor gráfico para HTML. Uma vez que você criou um componente baseado na StringBuilder com um dicionário de tags, e que em tese faz o que é necessário para solucionar o problema, imagine agora como o usuário final vai “destruir†a sua solução. Por exemplo, o usuário pode precisar utilizar CSS, além de HTML, ou pode ainda precisar usar um Twitter Boostrap ou outra biblioteca baseada em jQuery, e só isso já inutiliza sua solução. Seja qual for o conjunto de regras que você vá desenvolvendo para o seu dia-a-dia, o mais importante é se convencer a seguir sempre essas regras, sem exceções.
6. Sempre estar atualizado – Não é fácil, apesar da facilidade de acesso â informação, estar sempre em dia com as últimas novidades, pois quando você tem trabalho a fazer e compromissos firmados, entender uma nova metodologia, componente ou conceito pode parecer perda de tempo. Mas, ao contrário disso, é somente assim que o bom profissional pode se poupar de muito trabalho na tarefa conhecida como “reinventar a rodaâ€. Por exemplo, no VB6, a biblioteca Microsoft VBScript Regular Expressions 5.5 traz uma facilidade enorme na validação de entradas de dados, mas pouquÃssimas pessoas sabem como usar essa biblioteca, e “para ganhar tempoâ€, criam rotinas das mais variadas para a mesma finalidade. Esse é um exemplo pequeno, mas há muitos outros.
7. Conhecer-se a si mesmo – O bom profissional sabe quais são os seus limites e as suas dificuldades. Dessa forma, ele não passa ao cliente uma ideia de prazo de entrega sem antes considerar uma margem de segurança de ao menos 60% em relação ao prazo no qual ele de fato possa cumprir. Além de imprevistos por parte do profissional, podem ocorrer imprevistos por parte do cliente, e ainda assim, o prazo será coerente. Da mesma forma, o bom profissional sabe que não sabe tudo e sabe o que não sabe, e não tem medo de, no momento que a situação se apresente, perguntar. Com isso, ele não promete cumprir tarefas das quais ele não possa garantir a qualidade ou a confiabilidade.
8. Conhecer “pesos e medidas†sociais – O bom profissional é um ser humano, e como tal, ele tem uma imagem, que é aquela que os outros enxergam. Estar sempre fazendo piadas e comentários jocosos não ajuda profissionalmente em nada, pode até mesmo atrapalhar. Da mesma forma, ser extremamente técnico 100% do tempo acaba por passar uma impressão de “criatura antissocialâ€, ou até mesmo aquela figura racional estereotipada do personagem Spok de Jornada Nas Estrelas, que não é todo mundo que quer fazendo parte da equipe. é importante fazer amizades, é importante transmitir confiança e é importante compartilhar, mas tudo isso dentro de limites que não causem impacto negativo nos outros e sempre considerando o bom ambiente do empreendimento. A imagem profissional é algo que precisa ser definido, cultivado e aprimorado, sempre, pois é essa imagem que “vende†o seu trabalho.
9. Não esperar a chuva parar – Nem sempre a solução de um problema é encontrada apenas olhando-se o Google ou o Bing. Afinal, cada situação é única, mesmo aquelas que sejam parecidas. Nesses momentos, o bom profissional é aquele que expõe suas dificuldades ao cliente, ao patrão e à sua equipe, e em seguida, produz uma reanálise do problema e começa a elaborar passos para chegar à uma solução. Claro, todo mundo sabe que isso é o procedimento esperado, mas curiosamente, é muito mais comum do que deveria ser, o profissional que “despeja†os problemas na Internet e fica sentado, esperando os outros resolverem por ele.
10. Saber receber crÃticas – Não é porque a solução que você criou foi fruto de um processo laboral enorme que ela vai agradar todo mundo. Aliás, se ela func
Esse topico veio me confortar, rsrsr, estava meio que arrependido de ter migrado do vb6 para o vb.net a 5 anos atras. Estavam tanto colocando o vb abaixo do c#.
Tópico encerrado , respostas não são mais permitidas