none
Refatoração e linguagens dinâmicas RRS feed

  • Pergunta

  • Olá colegas,

     

    Gostaria da opinião de vocês em relação a dúvida de um colega de trabalho em qual arquitetura desenvolver. Ver abaixo:

     

    "

    Oi, pessoal.

     

    Estamos prestes a iniciar o desenvolvimento de uma grande (estou falando de tamanho mesmo) aplicação empresarial (usando a nomenclatura do Fowler: Enterprise Application). Tomando por base a versão atual dessa aplicação, algo em torno de dois milhões de linhas de código - fora os códigos de testes. Para o back-end , estamos na dúvida entre C# e Ruby. Estamos analisando diversos critérios, tanto do ponto de vista do usuário-cliente quanto do nosso próprio ponto de vista, os desenvolvedores: performance, portabilidade, custo, maturidade, produtividade, longevidade, perspectiva, mercado-alvo, atratividade de profissionais, disponibilidade de profissionais, extensibilidade, suportabilidade, etc.

     

    De maneira geral, minha escolha está praticamente definida por Ruby, apesar de não estar tão seguro. Minha insegurança é fruto de apenas um subcritério   do critério de produtividade: refatoração.

     

    Trabalhamos fortemente com design incremental (YAGNI e KISS ) em ciclos semanais. Se refatoração já é (ou pelo menos deveria ser) uma disciplina ubíqua, imagine então num cenário de design incremental com iterações muito curtas. Pois bem: a questão é que, por razões óbvias, ferramentas de refatoração são muito melhores em linguagens estáticas que em dinâmicas.

     

    Portanto, a pergunta que gostaria de fazer aos colegas é a seguinte: num cenário forte de design incremental, com iterações curtas, vale a pena adotar uma linguagem dinâmica, dada a desvantagem em relação à refatoração. Parafraseando: ainda que haja alguma desvantagem em relação à refatoração, as demais vantagens de uma linguagem dinâmica compensam, levando em consideração um cenário de design incremental e iterações curtas?

     

    Um abraço.

     

    "

    quarta-feira, 20 de janeiro de 2010 18:46

Respostas

  • Olha sei lá... eu particulamente acabei viciando em refatoração... mas acredito que ela pode ser sim substituida por uma metodologia forte no desenvolvimento, porque o maior problema no desenvolvimento usando uma linguagem dinamica para o problema apresentado, vai ocorrer durante as trocas ocasionais dos desenvolvedores..

    Digo isso por que no inicio do projeto, tudo ira funcionar perfeitamente, porem conforme seus desenvovedoures forem sainda da empresa e entrando outros, na maioria com alguns vicios referentes aos projetos q desenvolveram anteriormente, corre o risco de criar-se um "pequeno monstrinho" no qual um dia chegara ao ponto em que ninguem mais sabera medir o impacto de uma determinada implementação ira causar ao sistema....

    Tambem tem que ver exatamente o que é esse "grande" e tambem queria saber direito essa historia de "algo em torno de dois milhões de linhas de código", isso é muito relativo... pois eu mesmo ja vi sistemas deste porte feitos em Delphi (portados de sistemas clipper) que se refeitos usando as frameworks corretas em C# presicavam apenas de algumas poucas centenas de milhares de linhas de codigo... o que não é muito grande se estivermos falando de uma solução modulada....


    What would Brian Boitano do ?
    ((2B || !2B) is Question) ?
    quarta-feira, 20 de janeiro de 2010 19:14
  • Olha,

    Meus 2 cents... a discussão é interessantíssima e longa.

    Eu prefiro linguagens "estáticas" (se é esse o termpo correto para linguagens não-dinâmicas). Gosto de compiladores "chatos" que pegam a maioria das barbeiragens em tempo de compilação.

    Acho que o principal problema aí serão profissionais. Se o desenvolvimento é aqui no Brasil, eu não vejo uma quantidade grande de desenvolvedores Ruby... acho o C# muito mais disseminado.

    E como sempre, eu dou minha opinião que o padrão de arquitetura precisa ser condizente com o nível da equipe. Não adianta fazer rocket science se a equipe não acompanha.

    Se a opção for aplicação Web em C#, recomendo o caminho do MVC, muito mais próximo para quem está habituado com Web, do que o ASP.Net WebForms.


    Abraço,

    Eric
    quinta-feira, 21 de janeiro de 2010 15:50

Todas as Respostas

  • Olá colegas,

     

    Gostaria da opinião de vocês em relação a dúvida de um colega de trabalho em qual arquitetura desenvolver. Ver abaixo:

     

    "

    Oi, pessoal.

     

    Estamos prestes a iniciar o desenvolvimento de uma grande (estou falando de tamanho mesmo) aplicação empresarial (usando a nomenclatura do Fowler: Enterprise Application). Tomando por base a versão atual dessa aplicação, algo em torno de dois milhões de linhas de código - fora os códigos de testes. Para o back-end , estamos na dúvida entre C# e Ruby. Estamos analisando diversos critérios, tanto do ponto de vista do usuário-cliente quanto do nosso próprio ponto de vista, os desenvolvedores: performance, portabilidade, custo, maturidade, produtividade, longevidade, perspectiva, mercado-alvo, atratividade de profissionais, disponibilidade de profissionais, extensibilidade, suportabilidade, etc.

     

    De maneira geral, minha escolha está praticamente definida por Ruby, apesar de não estar tão seguro. Minha insegurança é fruto de apenas um subcritério   do critério de produtividade: refatoração.

     

    Trabalhamos fortemente com design incremental (YAGNI e KISS ) em ciclos semanais. Se refatoração já é (ou pelo menos deveria ser) uma disciplina ubíqua, imagine então num cenário de design incremental com iterações muito curtas. Pois bem: a questão é que, por razões óbvias, ferramentas de refatoração são muito melhores em linguagens estáticas que em dinâmicas.

     

    Portanto, a pergunta que gostaria de fazer aos colegas é a seguinte: num cenário forte de design incremental, com iterações curtas, vale a pena adotar uma linguagem dinâmica, dada a desvantagem em relação à refatoração. Parafraseando: ainda que haja alguma desvantagem em relação à refatoração, as demais vantagens de uma linguagem dinâmica compensam, levando em consideração um cenário de design incremental e iterações curtas?

     

    Um abraço.

     

    "

    quarta-feira, 20 de janeiro de 2010 18:35
  • Olha sei lá... eu particulamente acabei viciando em refatoração... mas acredito que ela pode ser sim substituida por uma metodologia forte no desenvolvimento, porque o maior problema no desenvolvimento usando uma linguagem dinamica para o problema apresentado, vai ocorrer durante as trocas ocasionais dos desenvolvedores..

    Digo isso por que no inicio do projeto, tudo ira funcionar perfeitamente, porem conforme seus desenvovedoures forem sainda da empresa e entrando outros, na maioria com alguns vicios referentes aos projetos q desenvolveram anteriormente, corre o risco de criar-se um "pequeno monstrinho" no qual um dia chegara ao ponto em que ninguem mais sabera medir o impacto de uma determinada implementação ira causar ao sistema....

    Tambem tem que ver exatamente o que é esse "grande" e tambem queria saber direito essa historia de "algo em torno de dois milhões de linhas de código", isso é muito relativo... pois eu mesmo ja vi sistemas deste porte feitos em Delphi (portados de sistemas clipper) que se refeitos usando as frameworks corretas em C# presicavam apenas de algumas poucas centenas de milhares de linhas de codigo... o que não é muito grande se estivermos falando de uma solução modulada....


    What would Brian Boitano do ?
    ((2B || !2B) is Question) ?
    quarta-feira, 20 de janeiro de 2010 19:14
  • Olha,

    Meus 2 cents... a discussão é interessantíssima e longa.

    Eu prefiro linguagens "estáticas" (se é esse o termpo correto para linguagens não-dinâmicas). Gosto de compiladores "chatos" que pegam a maioria das barbeiragens em tempo de compilação.

    Acho que o principal problema aí serão profissionais. Se o desenvolvimento é aqui no Brasil, eu não vejo uma quantidade grande de desenvolvedores Ruby... acho o C# muito mais disseminado.

    E como sempre, eu dou minha opinião que o padrão de arquitetura precisa ser condizente com o nível da equipe. Não adianta fazer rocket science se a equipe não acompanha.

    Se a opção for aplicação Web em C#, recomendo o caminho do MVC, muito mais próximo para quem está habituado com Web, do que o ASP.Net WebForms.


    Abraço,

    Eric
    quinta-feira, 21 de janeiro de 2010 15:50