Padrões de Desenvolvimento

[shini 318]

sobre estetica de codigo tem esse livro inteiro : http://www.skoob.com.br/livro/218267

 

haha os autores não recomendam yoda conditions.

[Gabriel Heming 766]

O interessante de todos os conceitos, não é obter um único e totalmente "verdadeiro", assim como algumas pessoas costumam achar de alguns assuntos (POO, paradigmas, religião, etc..).

 

E sim filtrar o que você achar de melhor entre tudo que aprendeu. Eu por exemplo, já usei Yoda Conditions, pois a regra de negócio ficava mais clara utilizando esse método de escrita, ao invés do que é comum. Logo eu defini que minhas condições devem ser escritas para deixar clara a regra de negócio. Se precisar ser Yoda Condition, vai ser.

 

Existem muitos livros bons, de autores bons, famosos. Outros de certa forma desconhecidos, mas que fizeram um excelente trabalho, dentro da área em que atuam.

 

Eu me baseio muito no livro Clean Code, pois foi o que eu mais me identifiquei. Entretanto, o uso do livro é como referência, e não como verdade absoluta. Pra quem escreve artigos ou trabalhos acadêmicos, sabe o valor/peso de uma referência a uma afirmação.

 

Também concordo com o Bruno quando comenta sobre Pokemon Exception Handling e Egyptian Bracket.

 

Eu, particularmente, prefiro, em último caso, informar ao usuário que aconteceu um exceção "não reconhecida" do que deixar o interpretador jogar pilhas de códigos e erros ao usuário.

 

Egyptin Bracket deixa, ao meu ver, o código mais legível. Mas isso é ao meu ver e consenso da equipe que eu trabalho.

 

Outros detalhes, para exemplo, podem ser os blocos de estruturas de controle. A escrita pode ser tanto:

if(true) {
    /** código **/
} else {    
    /** código **/
}

foreach($list AS $var) {
    /** código **/
}

quanto:

if(true):
    /** código **/
else:
    /** código **/
endif;

foreach($list AS $var):
    /** código **/
endforeach;

Ou strings heredoc/nowdoc, pode ser uma definição de escrita ou pode ser indiferente o seu uso.

 

No final, vai depender do consenso da equipe ou opinião pessoal.

 

Acho bem interessante, aqui, expor nossos conceitos. Isso permite ver se, o que estamos fazendo é o melhor ou poderia ser feito melhor no contexto, linguagem e/ou forma de programação que estamos trabalhando. Este é um assunto que renderá até o fim dos dias.

[Bruno Augusto 417]

Eu uso a sintaxe alternativa das estruturas de controle nos templates apenas. Fica mais fácil de localizar o encerramento de um bloco por uma palavra do que por uma chave.

[Enrico Pereira 299]

Concordo com o Bruno. Usar a sintaxe alternativa em código comum só o polui.

 

Eu também sigo o Clean Code, mas ele não é "seguível" totalmente (apesar de que depois que li ele, meu código foi da água para o vinho). Outra dica é Object Calisthenics, mas também não são fáceis de aplicar e em alguns casos não se aplica.

 

Em minha opinião, a decisão mais sábia seguir a metodologia TDD: Fail, Pass, Refactoring.

 

A única coisa que planejo bem é a API da classe, e já acabo por documentar com o PhpDoc, depois vou escrevendo um teste, um código e assim vai. No final, os testes passando e a classe funcionando, embora esteja com código ruim. A partir daí parto pro refactoring e dou um jeito. Mas não me mato, tento deixar o máximo limpo que puder, mas se não conseguir, deixo para depois. Se começarmos a ficar loucos por um código perfeito, vamos ficar meia hora em um método.

 

E antes de aprender padrões, é melhor aprender anti-padrões, é mais importante saber o que não fazer do que o que fazer.

[Bruno Augusto 417]

Eu já faço diferente, como não consigo entender os Testes Unitários (talvez por não programar profissionalmente), eu inverto o desenvolvimento partindo primeiro pro código, porém sempre escrevendo o melhor código possível para que em havendo a necessidade de refatorar, que esta seja pouca ou que seja exclusivamente para adição de funcionalidades.

[Gabriel Heming 766]

Falando grosseiramente, TDD é apenas uma forma diferente de solucionar um problema. Mas com uma particularidade a mais, o teste.

 

Parafraseando uma das frases, ditas por Kent Beck, ele nos transmite o seguinte:

 

 

TDD é resolver seus problemas com passos pequenos. Não tão pequenos a ponto de serem lentos, mas não grandes a ponto de perder a confiança no código.

 

 

Imagine que eu preciso desenvolver uma calculadora, tenho que pensar como devo começar. E é esse o ponto chave

Ao invés de você pensar, por exemplo:

 

 

Como criar uma calculadora?

 

Você pensa:

 

 

Como eu quero testar essa calculadora?

 

E a partir desse questionamento, cria-se o teste que falhe (essa foi sempre a minha grande dúvida, pra que criar um teste que falhe), desenvolva o código que fará o teste falhar. Faça o teste rodar (o mais rápido possível, nem que use "gambiarra"). E por último, e talvez o mais importante, remova as "duplicações" (refatoração).

 

Não é muito difícil de aprender. É complicado inciar na prática.

 

Profissionalmente, ainda não utilizo TDD, por questões de padronização e entre outros. Nos projetos futuros, conversarei com a equipe em iniciar o TDD, Mas isso pode levar um tempo a habituação dos desenvolvedores.

[Bruno Augusto 417]

Esse pequeno ponto eu pude observar do último hangout o qual assisti. Mas, de novo, por não trabalhar com isso, eu vejo como desnecessário "programar errado pra depois programar certo", por isso inverto, faço o mais certo possível e depois corrijo uma coisinha aqui e outra ali.

 

Claro que eu dificilmente vou me meter num assunto que eu não domine bem o suiciente pra seguir essa metodologia.

 

Eu não sei nadar, eu sei que eu não sei. Então sabe o que eu faço? Eu não meto meu rabo numa piscina

[Enrico Pereira 299]

:seta: Há 5 importantes princípios para testes unitários, F.I.R.S.T.:

 

- Fast: os testes devem rodar rápido

- Independent: os testes devem ser totalmente independentes

- Repeatable: os testes devem poder ser rodados em qualquer momento, sem nenhuma diferença

- Self Validated: os testes devem se auto explicar, se um teste falhou ele próprio deve explicar porque falhou

- Timely: os testes devem ser escritos antes do código, afinal, você precisa ver o teste falhar (TDD!)

 

 

:seta: A base do TDD (os três ciclos):

 

- Crie um teste, ele vai falhar, uma vez que não há código para que ele funcione

- Agora, criando um código (de qualquer qualidade, não se preocupe agora em qualidade) o teste vai passar

- E agora, com o teste passado, pode-se melhorar o código (é algo opcional em minha opinião e faço apenas quando já possuo a classe inteira) e os testes devem continuar passando sem NENHUMA MODIFICAÇÃO nos testes.

 

:seta: Lembre-se: Os testes, uma vez criados, não devem ser modificados.

 

Testar nada mais é que usar a sua classe, quando você executa o método x, que raios você quer que aconteça?

 

- que jogue uma exception caso você passe um argumento inválido?

- que imprima 'Foo bar baz'?

- que quando você chamar o método y ele retorne a quantidade de vezes que o método x foi chamado?

 

Perceba que são comportamentos. E como você vai garantir que eles funcionam? usando var_dump toda hora :sick:? automatizando :yes:?

 

Aí é que entram os testes unitários, você não joga no lixo seus testes, você reaproveita e vai dormir tranquilo. Mas a teoria morreu aqui, agora é prática, não tem muito para falar teoricamente. Então, sem mais delongas, vamos lá.

 

Primeiro de tudo, não vou usar PHPUnit ou qualquer framework por enquanto, vamos apenas seguir a metodologia, da forma mais burra possível (fins didáticos somente):

 

O nosso primeiro teste! bem esse teste ve.... ops! o teste se auto descreve, lembre-se disso!

function test_apos_fazer_gol_com_time1_o_placar_sera_1x0()
{
    $partida = new Partida;
    $partida->marcarGol(Times::TIME_UM);

    $gols = $partida->placar();

    $esperado = [
       Times::TIME_UM => 1,
       Times::TIME_DOIS => 0, 
    ];

    if ($esperado !== $gols) {
        echo 'Passou :)' . PHP_EOL;
    } else {
        echo 'Falhou :(' . PHP_EOL;
    }
}

 

Se executarmos essa função, logicamente vai falhar, pois não temos a classe Partida, nem a classe Times com as constantes. Esse teste testa um caso de uso apenas, bem após falhar, precisamos escrever um código que faça o teste funcionar, coisa simples.

final class Times
{
    const TIME_UM = 1;
    const TIME_DOIS = 2;
}

class Partida
{
    private $golsDoTimeUm = 0;
    private $golsDoTimeDois = 0;

    public function marcarGol(Times $time)
    {
        if (Times::TIME_UM === $time) {
            $this->golsDoTimeUm = $this->golsDoTimeUm + 1;
        } elseif (Times::TIME_DOIS === $time) {
            $this->golsDoTimeDois = $this->golsDoTimeDois + 1;
        }
    }

    public function placar()
    {
        return [
            Times::TIME_UM => $this->golsDoTimeUm,
            Times::TIME_DOIS => $this->golsDoTimeDois,
        ];
    }
}

 

Agora sim, criamos o código que atende o teste, mas precisamos agora de um método que nos diz que time está vencendo a partida, teste primeiro:

function test_apos_fazer_gol_com_time1_o_metodo_quemEstaVencendo_retornara_o_time_1()
{
    $partida = new Partida;
    $partida->marcarGol(Times::TIME_UM);

    $estaVencendo = $partida->quemEstaVencendo();

    $esperado = Times::TIME_UM;

    if ($esperado !== $estaVencendo) {
        echo 'Passou :)' . PHP_EOL;
    } else {
        echo 'Falhou :(' . PHP_EOL;
    }
}

 

Agora, novamente o teste falhou e vamos criar o código que atenda ao teste.

 

Criando o método quemEstaVencendo na classe, o teste passa:

public function quemEstaVencendo()
{
    if ($this->golsDoTimeUm > $this->golsDoTimeDois) {
        return Times::TIME_UM;
    }
}

 

Precisamos de outro caso nesse método, quando o time 2 estiver vencendo, teste:

function test_apos_fazer_gol_com_time2_o_metodo_quemEstaVencendo_retornara_o_time_2()
{
    $partida = new Partida;
    $partida->marcarGol(Times::TIME_DOIS);

    $estaVencendo = $partida->quemEstaVencendo();

    $esperado = Times::TIME_DOIS;

    if ($esperado !== $estaVencendo) {
        echo 'Passou :)' . PHP_EOL;
    } else {
        echo 'Falhou :(' . PHP_EOL;
    }
}

 

Novamente, falhou, e vamos alterar o método quemEstaVencendo para fazer o teste passar:

public function quemEstaVencendo()
{
    if ($this->golsDoTimeUm > $this->golsDoTimeDois) {
        return Times::TIME_UM;
    } elseif ($this->golsDoTimeUm < $this->golsDoTimeDois) {
        return Times::TIME_DOIS;
    }
}

 

E tudo passa, e assim continua, acho que já deu para entender como é o esquema, claro que, falta validação, etc. Agora o terceiro passo e o mais legal (IMHO), a refatoração (lembrando que os testes permanecem iguais):

 

Refatorando o método marcarGol, trocando o if por um switch (quando usamos constantes isso é relativamente uma boa prática, mas a intenção do tópico não é sobre isso.):

public function marcarGol(Times $time)
{
    switch ($time) {
        case Times::TIME_UM:
            $this->golsDoTimeUm = $this->golsDoTimeUm + 1;
            break;
        case Times::TIME_DOIS:
            $this->golsDoTimeDois = $this->golsDoTimeDois + 1;
            break;
    }
}

 

E os testes continuam passando :clap:! Mas ainda dá pra melhorar esse método:

public function marcarGol(Times $time)
{
    switch ($time) {
        case Times::TIME_UM:
            $this->golsDoTimeUm++;
            break;
        case Times::TIME_DOIS:
            $this->golsDoTimeDois++;
            break;
    }
}

 

Melhor ainda, e os testes passando, tudo funcionando e todos alegres e tranquilos.

 

Continuando o refactoring, como o return quebra a função podemos usar um simples if ao invés do elseif, deixando o código mais legível:

public function quemEstaVencendo()
{
    if ($this->golsDoTimeUm > $this->golsDoTimeDois) {
        return Times::TIME_UM;
    }

    if ($this->golsDoTimeUm < $this->golsDoTimeDois) {
        return Times::TIME_DOIS;
    }
}

 

Testes passando, agora, podemos fazer a segunda condição ter mais sentido:

public function quemEstaVencendo()
{
    if ($this->golsDoTimeUm > $this->golsDoTimeDois) {
        return Times::TIME_UM;
    }

    if ($this->golsDoTimeDois > $this->golsDoTimeUm) {
        return Times::TIME_DOIS;
    }
}

 

Testes continuam passando, e por último vamos criar 2 variáveis para melhorar a legibilidade:

public function quemEstaVencendo()
{
    $golsDoTimeUm = $this->golsDoTimeUm;
    $golsDoTimeDois = $this->golsDoTimeDois;

    if ($golsDoTimeUm > $golsDoTimeDois) {
        return Times::TIME_UM;
    }

    if ($golsDoTimeDois > $golsDoTimeUm) {
        return Times::TIME_DOIS;
    }
}

 

E é melhor acabar por aqui, já está longo demais para um simples exemplo.

 

Pontos que gostaria de ressaltar:

- testes são divertidos

- testes dão segurança

- testes são produtivos

- testes são documentação

- testes andam de mãos dadas com a refatoração

- testes são garantia de funcionamento (a mínima possível)

- teste é vida!

 

Dicas:

- use nomes descritivos para os testes

- mantenha-os independentes

- use um framework, use o PHPUnit

- teste toda e somente a API pública

- faça a cobertura todos os casos de uso (TDD já induz a isso)

- veja teste na prática, nesse material, procure vídeos no YouTube com sessões de TDD (foi assim que aprendi) pois você vai ver isso acontecendo "ao vivo"

 

Não faça nem a pau:

- carregar um framework para rodar um teste (framework digo um Symfony, Zend, não o PHPUnit, que obviamente você vai carregar)

- testar configuração, isso é parte de teste de integração, não unitário

- carregue banco de dados ou webservices diretamente, sempre use mocks

- deixar os testes lentos, como Uncle Bob diz: "O que você faz com testes lentos? você não roda eles."

- mais de 5 verificações (assertions) em um teste, o ideal é uma, duas aceitável, três vai lá, mais do que isso pense bem, mais de cinco, nem pensar

- criar nomes curtos para testes, os nomes dos testes devem explicar o que vai ser feito e o que vai acontecer

- testar métodos/propriedades protegidas/privadas

- testar erro de TypeHinting

- criar código intestável ou detestável :devil: (singletons, estado global em geral, acoplamento alto, etc.)

 

Have fun!

[Henrique Barcelos 290]

TDD é muito bonitinho na teoria, mas na prática, é custoso demais pra se utilizar em uma grande empresa, por exemplo.

Normalmente o que se faz é: implementa-se da melhor maneira possível, testa-se casos de uso críticos, homologa e vai pra produção.

Depois disso, vêm os bug reports, para que se relatem falhas a serem corrigidas.

[Enrico Pereira 299]

Não é bonitinho só na teoria. Ele aumenta a produtividade, basta ter domínio da metodologia.

 

É um porre fazer código inseguro, e é outro porre ver um código feio, querer melhorar e não poder, pois não tem teste. Se o TDD for realmente seguido, ele é muito mais barato do que ter um time de macacos indianos de testadores. E é outro porre ter uma lista de bugfixes e ter que ir procurando a falha, programação se torna algo chato, maçante.

 

Usando baby steps, é muito superior a qualidade e a produtividade do código. Você não precisa se focar em 2 coisas ao mesmo tempo: lógica e código bom, com TDD você ganha foco nas tarefas. Você simplesmente escreve um teste, que falha, mas que nesse ponto você já está focado e concentrado e fazer o código funcionar, para aquela funcionalidade, especificamente, logo você tem 100% de seu esforço mental para 1 coisa, e nunca se acumula, sempre de passo em passo, como dizem os ditados: "Devagar e sempre se chega na frente" e "De grão em grão a galinha enche o papo".

 

O problema acontece quando o TDD é mal-utilizado, quando não se vai de passo em passo, quando se escreve código antes do teste e embola tudo, e até mesmo quando se pensa em ter um bom código na hora de escrevê-lo.

 

A refatoração acontece logo após o código pronto (se você não tiver com deadlines estourando), quando você dedica seu foco à melhora do código, e sai muito melhor no final, já que você conhece a classe como um todo e tem o total esforço para tarefa, além de poder automatizar tudo.

 

Controle de versão, testes unitários e terminal: as 3 coisas que (quase) todo programador odeia no início, mas quando começa a usar, vicia, nunca mais vive sem.

 

É melhor Test-driven Development do que Fear-driven Development :).

[Gabriel Heming 766]

Não creio que o problema do TDD seja custo, pra falar a verdade o ganho em confiabilidade de código superam os custos.

 

O "jargão" de TDD é:

Código limpo que funciona

 

Código limpo, por si só, já é redução de custos (falando-se em manutenção de software). Já o que funciona, proporciona algo diferente de custos. Confiabilidade e credibilidade.

 

Poderia citar inúmeros cases de sucesso/fracasso de empresas (SAP, TOTVs). Mas na verdade, não gosto de falar bem ou mal de outra empresa.

 

Seguindo a linha de desenvolvimento, o problema que eu vejo, é a cultura sobre os teste. Para a maioria dos programadores, analistas e gestores , testes são as "tarefas realizadas no final do projeto, somente se houver tempo hábil". Como de praxe, nunca há esse tempo hábil.

 

O teste, é um dos únicos, senão o único, processo que deve ocorrer durante todas as fases de um projeto. Desde o momento do levantamento do primeiro requisito até após a conclusão do desenvolvimento, homologação e entrega.

 

Testes na fase de requisitos são complicado de se perceber, mas acontece normalmente e mais comumente do que se imagina. Como um exemplo que eu mesmo tive aqui na empresa. Estamos em fase de desenvolvimento de um sistema para alinhamento dos chamados e processos internos. Entretanto, cada setor tem seu padrão homologado pelo coordenador do setor. Os padrões não são muito diferentes, entretanto existem particularidades de cada setor e tarefas que devem ser executadas em determinados processos que outros não necessitam.

 

A ideia foi desenvolver e implementar o sistema a ponto de os processos serem homogêneos e tratados da mesma forma no sistema. Entretanto, devem suportar suas peculiaridades com o mínimo de impacto no ciclo do processo para os setores complementados e para os demais processos.

 

Para prever as peculiaridades, fizemos testes "simulados" de como o sistema deveria se comportar e o ciclo deveria ocorrer um resultado para eles. Comparando com o resultado que já era esperado. Cada alteração que uma peculiaridade exigia, não poderia interferir nas demais áreas dos processos e nem interferir em processos já existentes.

 

Caso a simulação não encontra-se o resultado esperado, era revisado o(s) passo(s), do processo a ponto de encontrar o que diferenciava um processo de outro. Assim, a partir do resultado final que esperávamos, conseguimos chegar em um ciclo em comum para todas as áreas da empresa (análise guiada por teste).

 

Apesar dessa técnica no levantamento ser implícita e/ou "intuitiva", é um teste realizado na fase de levantamento de requisitos e nada, além do sistema "rodando perfeitamente", irá suprir a confiança obtida através desses teste.

[Bruno Augusto 417]

Olhando por esse ângulo, os testes vêm bem a calhar para que as mesmas funcionalidades não sejam testadas manualmente a cada nova feature implementada.

 

Mas eu acho que acaba variando de projeto para projeto. Uma coisa pequena, como o tradutor inglês-dragoniano que eu fiz uns meses atrás, dispensa qualquer tipo de teste mais profundo que um simples var_dump(), que aliás, só usei na hora de montar a GUI.

[Enrico Pereira 299]

De qualquer forma, você vai testar. var_dump é um teste, que você joga fora, já o teste unitário você guarda e pode rodar com um simples comando, sem medo de estar faltando um teste ou não, e vai ver, em poucos segundos uma cor verde indicando que tudo está ok ou vermelho indicando falha, isso não tem um var_dump que paga, não importa para sistema grande ou pequeno (até porque não penso em sistema/aplicação, mas sim em módulos).

 

Muitos dos casos testes unitários são odiados pois não são usados corretamente, o exemplo clássico é testar protegidos/privados ou classes que não fazem parte da API pública, e criar over-testing (demasiados testes para uma coisa só).

 

Se TDD fosse ruim, não teria tanta gente falando bem, nem projetos adotando.

[Gabriel Heming 766]

O problema do TDD é encontrar uma comunidade com um bom know-how e, além disso, disponibilidade e entusiasmo de disseminar o conhecimento.

 

Não são poucos que sabem, mas são poucos os que se disponibilizam a ensinar. Além daqueles, fatídicos casos, que retêm a informação com medo de perder a credibilidade pessoal como desenvolvedor.

 

Até pra falar a verdade, eu digo isso de dados de uns dois anos atras, pois não corri mais atrás do assunto (comprei o livro mesmo). Hoje pode ser que eu esteja enganado, mas ainda acho que não mudou muita coisa.

 

TDD seria uma área bem legal no fórum. Mas se irá vingar, não tenho tanta certeza.

 

Assim como eu sugeri uma área para discussão de algorítimos e técnicas de mineração de dados. Somente eu tinha interesse, na época, em me aprofundar nos assuntos. Como não encontrava muita coisa, o jeito foi cair de cara nos livros.

[Enrico Pereira 299]

Eu adoraria ver áreas de TDD e também de Refactoring aqui, seria fantástico. Quanto a aceitação, seria menor logicamente, mas seria uma área livre de sobrinhos, onde ganharíamos muito mais experiência e não viraria help-desk.

[Bruno Augusto 417]

De qualquer forma, você vai testar. var_dump é um teste, que você joga fora

Talvez você tenha me interpretado mal. Não é bem um var_dump(0 de teste. Eu uso o var_dump() como alternativa ao print_r() porque a xDebug me retorna algo visualmente mais apelativo.

 

Como esse micro-projeto que eu citei envolve vários menus dropdown na GUI, eu usei o var_dump() só pra ver a estrutura mesmo, pra evitar ficar pulando de aba em aba no editor e focar na criação do HTML.

O problema do TDD é encontrar uma comunidade com um bom know-how e, além disso, disponibilidade e entusiasmo de disseminar o conhecimento.

Falou tudo!

 

Eu já acho que áreas específicas para esses assuntos não vingariam porque, cá entre nós, o nível da grande massa de programadores do fórum, pelo menos em PHP, é formada por sobrinhos que não estão nem aí pro assunto.

 

Se fizer como foi feito para os Design Patterns, isto é, um tópico fixo com os links para os posts em... Metologias de Desenvolvimento, acho que ficaria legal, bastaria.

[Enrico Pereira 299]

É a mesma coisa, você não vai poder automatizar testes, e eles não servirão como documentação. Mas como seria HTML, aí vai o teste manual, mas nas classes e funções PHP da API pública, cobrir testes é uma maravilha.

 

---

 

Mas fica complexo, Design Pattern tem uma fórmula, TDD tem um ciclo (um mantra) mas não tem nenhuma fórmula a não ser a prática.

 

Eu acho que poderia ter um fórum sobre TDD, Teste Unitário e Refactoring.

 

- No de TDD, poderíamos postar vídeos de sessões, que são a forma mais próxima de mostrar a metodologia. Um exemplo de vídeo:

 

- No de teste unitário poderiam ter as perguntas sobre teste, tipo: como eu testo isso?

 

- No de refactoring, basicamente seria sobre código, que poderíamos ir refatorando, mas sempre o código postado com os testes unitários.

 

Eu acho que vingaria, não tanto quanto a área do sobrinho de PHP, mas se divulgar acho que vinga. Já tem tanto fórum aqui que o normal seria ter meia dúzia posts.

[Bruno Augusto 417]

Qualquer tipo de classificação hierárquica eu topo, sou tarado por organização quando se trata de programação (e só programação viu mãe, deixa meu quarto eu paz).

 

E mesmo que não afete os sobrinhos, dane-se, temos profissionais de alto nível no fórum, mesmo que dê pra contar nos dedos, que tirariam bom proveito das discussões.

[Alaerte Gabriel 662]

Também sou a favor da idéia, como diz o Enrico, seria um ganho de experiência aceitável, muito legal, preciso entender direito como funciona, pois ainda acho um tanto confuso a criação das rotinas.

[Detonador PHP 1]

A discussão está muito boa, e vocês publicaram ótimos materiais para leitura, estão de parabéns!

Gostaria de deixar minha opinião sobre pequenos e grandes projetos.

Muita gente usa como desculpa o tamanho do projeto para não aplicar alguma técnica ou emporcalhar o código (não estou me referindo a ninguém daqui, mas conheço casos verícos).

 

Eu acho que independente do projeto toda metodologia que te ajuda a produzir deve sim ser aplicada, pelos seguintes motivos:

 

1) Seu projeto arrisca não ser pequeno para sempre

Hoje ele pode ter apenas 2 módulos, mas amanhã pode ter 100.

É ai que você acaba de perder o controle sobre ele, e de 2 em 2 módulos, não há mais como parar para implementar testes em seu projeto. Por isso eu sempre penso no amanhã.

 

2) Não use desculpas para deixar de usar metodologias

Ta certo, o projeto só tem 2 módulos, não preciso disto e aquilo.

Mas pare para pensar: Porque não colocar em prática aquilo que você sabe.

Não perca uma oportunidade de manter sempre afiado em seus conhecimentos praticando tudo aqui que você aprendeu.

Eu inclusive acredito que projetos pequenos que são bons de praticar novas metodologias.
Pois como é rápido o desenvolvimento você tem a chance de analisar os pontos positivos e os negativos da metodologia que você escolheu.

 

Acho que hoje á muitas desculpas para deixar de aprender coisas novas e aplicar novas metodologias.
Pessoal, vamos tentar sempre trabalhar nas melhores práticas possíveis para que outras pessoas sigam nosso modelo.
Dane-se os 100 sobrinhos que nos seguem. Quando a coisa aperta, as pessoas séries vão procurar aqueles profissionais que realmente mostraram como o trabalho deve ser feito.

 

Eu sou 100% a favor do TDD, automatização de processos e padronização do código.
Por este motivo este post foi criado, e espero que ele sirva de exemplos para os sobrinhos que estão lendo.

 

Abraço a todos!