Vale a pena? ultilizar frameworks ?

[Vinicius Rangel 208]

Criar um framework não é fritar um ovo e nem criar uma aplicação, é algo muito mais complexo e que demanda tempo, estudo e dedicação, acho algo positivo demais e só melhora a comunidade pois aumenta a "concorrência", gerando mais opções e etc. Só que não tem receita de bolo muito menos um tutorial/livro/whatever que vai guiar como criar um.

Concordo em partes cara, eu vi uma vez uma receita de framework no programa da palmerinha..

aauhuahhuahuahuahua zueira

 

realmente não esta nada comparado a fritar um ovo, vc pode gastar meses ai até consegui lançar UMA versão instável.

[Alaerte Gabriel 662]

Poderíamos criar o Framework Ovofrito.

 

Valerme....

 

Criar um framework, além de disport de tamanho conhecimento, é necessário concentração, tempo, dedicação e muita paciência. Estou falando de mêses, talvez 1 ano... até que esteja seguro do que vai lançar, pois se caso isso ocorra, de fato, você deverá lançar melhorias para o mesmo, afim de estabilizar a aplicação e trazer confiabilidade para os programadores, o que não é uma tarefa fácil.

[Rogério Santana 172]

ZF2 N motivos, dentre eles, está o costume e a intimidade com o framework. Nada mais. Porém, vou passar a fazer uns testes com esse Laravel, baixei e me parece ser legalzinho.

 

Hum.... entendi .... vlw então.

[Rudy_jr 47]

Podiamos é criar o frameworks "Imasters" colocamos no GitHub e todo mundo colabora xD

[Evandro Oliveira 331]

http://code.google.com/p/imns/

[Alaerte Gabriel 662]

Boa... quem vai ser o primeiro ? quem dará início ? rs

[Henrique Barcelos 290]

Eu acho que usar um framework só vale a pena a partir do momento em que você consegue entender o que ele faz por baixo dos panos. Achar que é mágica e pular etapas te faz dependente da ferramenta.

O maior exemplo: hoje em dia tem muito nego por aí querendo aprender jQuery sem saber Javascript. Aí o cara fica com dúvida sobre como somar 2 inteiros usando jQuery --'.

[Enrico Pereira 299]

Um framework não substitui uma linguagem. É fato.

[Alaerte Gabriel 662]

concordo

[mangakah 217]

Seria bom agora uma lista de conhecimentos que são recomendáveis para um iniciante ter antes de encarar um framework:

 

• Experiência de pelo menos dois anos programando em PHP e saber como usar cookies, sessões, Filesystem, Datetime, cURL, Sockets, XML, PDO e Prepared Statements, e o que mais você encontrar no manual.
• Saber o máximo possível de patterns, principalmente: Singleton, Observer, Factory, Composite, Chain of Command e Strategy.
• MVC
• URL Routing
• Compilação de templates
• ORM e AL
• ...mais o que?

 

E também duas coisas que muitos negligenciam: Testes (Unit Tests, Test-driven dev/TDD) e Refatoração.

 

 

 

Esta não é uma lista exaustiva e não é uma lista de requisitos sem os quais é impossível ou prejudicial começar a usar um framework. São apenas algumas recomendações de conhecimentos que na minha opinião seria bom ter bem já calcificados no cérebro para saber como frameworks funcionam antes de começar usar frameworks.

 

 

Se alguém quiser adicionar alguma coisa ou corrigir outra, fique a vontade.

[hinom 5]

..mais o que?

 

Começar a fazer o 1º e colocá-lo em prática, sem se preocupar muito se está certo ou não.. mas obviamente evite aplicar em projetos sérios. Use projetos pessoais como cobaia.

 

Assim, com o tempo, obterá experiência para melhorar.

[Enrico Pereira 299]

 

• Experiência de pelo menos dois anos programando em PHP

 

Discordo, experiência não é medida por quantidade de anos.

 

 

E também duas coisas que muitos negligenciam: Testes (Unit Tests, Test-driven dev/TDD) e Refatoração.

 

Sim, é teste unitário é muito importante e infelizmente não é tão popular, principalmente em PHP. E como dizem, código legado é código sem teste.

[Vinicius Rangel 208]

Saber o máximo possível de patterns, principalmente: Singleton, Observer, Factory, Composite, Chain of Command e Strategy.

 

acho que Chain of Responsibility é muito importante também.

[Enrico Pereira 299]

Só o Singleton que é uma tristeza....

[mangakah 217]

Só o Singleton que é uma tristeza....

 

O problema é que usam este pattern demais, em 99% das vezes ele não é necessário mas muitos usam só porque é fácil de implementar.

[Evandro Oliveira 331]

 

 

• Experiência de pelo menos dois anos programando em PHP

 

 

Realmente, como dito, experiência não se mede em anos.

 

2 anos programando quantas horas por dia?? Quantos dias por semana? Ao final de dois anos isso resulta em quantos trabalhos entregues? 2 anos como freela ou numa equipe de 4, 6 pessoas?

 

Aprendi mais sobre PHP ajudando aqui no fórum do que programando profissionalmente.

 

 

• saber como usar cookies, sessões, Filesystem, Datetime, cURL, Sockets, XML, PDO e Prepared Statements, e o que mais você encontrar no manual.

 

 

Discordo dos tachados. Se for pra voltar atrás, concordaria apenas com XML. Trabalhar com Sockets no Windows é um saco. cUrl, na maioria das vezes, a webservices. Acho que este tipo de aprofundamento não deve ser requisito para se compreender um framework.

 

De modo geral, comportamentos presentes na grande maioria dos sistemas são requisitos para se aprender um framework. Particularidades, não. Como, eficientemente, citado, cookies/sessões são parte essencial do processo de autenticação e autorização de usuários. O que nos remete, quase que obrigatoriamente, à uma camada de acesso a dados, onde entra a PDO. Se formos estudar PDO, o próprio manual vai nos direcionar para Prepared Statements. Acabam ficando de fora da lista apenas FileSystem e DateTime que estariam intrinsecamente ligados a um sistema de log. De resto, não é todo sistema que precisa de XML, não é todo sistema que vá realizar requisições URL no lado do servidor e, francamente, o manual - hoje - possui (em sua forma mais sucinta), 5Mb. Sério mesmo que isso é requisito pra mergulhar num framework?

 

 

• Saber o máximo possível de patterns, principalmente: Singleton, Observer, Factory, Composite, Chain of Command e Strategy.
• MVC

 

 

Chain of Responsibility, como já foi corrigido, além de MVC também ser um Design Pattern, dispensando a necessidade de um item de lista exclusivo para ele.

 

Da tua lista, ficaria com: Singleton, MVC, Observer, Stragety e Composite. Ainda acrescentaria Visitor, Façade, Adapter, FluentInterface e FrontController.

 

 

• URL Routing

 

 

Acho que, apenas saber que existe a possibilidade de implementar URL's amigáveis e conhecer uma forma (normalmente .htaccess) já é suficiente. Por isso você vai usar o framework. Pra não ter que sair atrás da chata documentação do IIS e/ou pra não ter que ficar modificando os arquivos de configuração base do NGINX e recarregá-los toda hora.

 

 

• Compilação de templates
• ORM e AL

 

 

Compilação de templates eu acho completamente desnecessário saber pra se trabalhar num framework. PDO já é uma DBAL. Logo, estudando PDO, você já está estudando AL. ORM, nem todo framework disponibiliza. O que cai no nosso primeiro caso de estudar o que não é um cenário geral.

E também duas coisas que muitos negligenciam: Testes (Unit Tests, Test-driven dev/TDD) e Refatoração.

É relativo. Vejo os testes de uma forma similar à documentação/comentários.

Uma m... de código comentado vai continuar sendo uma m... de código

Eu prefiro um milhão de vezes um código com bom filtro e validação do que uma implementação feita de qualquer forma só pra passar nos testes.

 

 

Como você mesmo adiantou...

Esta não é uma lista exaustiva e não é uma lista de requisitos sem os quais é impossível ou prejudicial começar a usar um framework.

Resolvi tentar minificar a lista ao que eu acredito que sejam reais requisitos para se trabalhar bem sob um framework. Excetuando a lista de Design Patterns, ao meu ver, o que restou é essencial para estar apto a aprender qualquer framework. Inclusive julgá-los bons ou ruins.

[...]ter bem já calcificados no cérebro[...]

Pra não dizer impossível, eu acredito que isso seja bem difícil :D

 

Se alguém quiser adicionar alguma coisa ou corrigir outra, fique a vontade.

Apenas para complementar que, como você deixou bem claro ser o seu ponto de vista, não estou querendo impor a minha verdade ou dizer que você está certo ou errado. Estamos apenas movimentando ideias, correto?

[Vinicius Rangel 208]

Depois desse belo discurso do Evandro, vem a pergunta.

 

Dao, seria uma maneira inteligente de trabalhar em um framework?

 

sendo que o usuário teria que criar e manipular vários objetos que seriam as tabelas mapeadas.

[Enrico Pereira 299]

Sobre cURL, é complicado, cURL é poderoso para caramba, mas é uma experiência terrível para usar. é complexo, não é nada amigável (digo a implementação em PHP.). Em minha opinião, você deve saber o que está acontecendo e etc. mas não necessariamente saber como implementar no PHP. E muitos dos casos, aprende-se algo depois de estar usando um framework.

 

E vai na mesma linha: frameworks fazem marketing e querem que você use tudo dele e somente dele. Bem, é complexo, eu acho que frameworks que são uma coisa só são uma porcaria, pois eles são como um deus supremo que resolve tudo. É por isso que eu prefiro bibliotecas ou frameworks baseados em componentes (como ZF2 e Symfony2). Com esse tipo de framework, você resolve os problemas que precisa, não um trambolho que te dá um monte de coisas, muita das vezes inúteis.

 

Eu não vejo necessidade em saber (como um requisito p/ um framework, mas saiba, por favor) design patterns. Até porque estamos, novamente, generalizando porque estamos falando que todo framework usa design patterns e é orientado a objetos, o que não é a verdade.

 

E um ponto: você pode aprender algo enquanto você aprende um framework e isso é bem comum de acontecer.

 

---

 

Evandro, quando você falou isso:

 

 

Eu prefiro um milhão de vezes um código com bom filtro e validação do que uma implementação feita de qualquer forma só pra passar nos testes.

 

Você esqueceu do terceiro passo do TDD: a refactoring. Criar código bom "de primeira" é difícil e menos produtivo, quando você tem um código pronto com os testes (para poder confiar que a refactoring não quebra) é mais fácil executar uma refactoring, além de que você vai ter todo o foco para a refactoring.

 

---

 

 

Dao, seria uma maneira inteligente de trabalhar em um framework?

 

Polêmica. Eu sinceramente gostaria de ver isso sendo debatido mais profundamente, se pudesse criar um tópico seria bom. Patterns para persistência são complexos. Em minha opinião, existe vantagens e desvantagens, o próprio livro Clean Code diz isso quando menciona ActiveRecord (e olha que tio Bob é xiita com tudo).

 

 

O problema é que usam este pattern demais, em 99% das vezes ele não é necessário mas muitos usam só porque é fácil de implementar.

 

Outra polêmica. Esse 1% das vezes em que singleton presta eu não encontro :lol:, mas novamente repito: deveria ser debatido em um tópico separado com mais calma. E sim, design patterns viram doenças de vez em quando. Põe pattern lá, pattern aqui, pattern acolá.....

[Alaerte Gabriel 662]

Pois então, lendo todos os fatos, lá vai minha opinião:

 

Requisitos para se desenvolver um framework:

 

 

 

- Conhecimento

- Iniciativa

[mangakah 217]

#56:

 

Tecnicamente, MVC não é um design pattern, mas um modelo de desenvolvimento (architecture pattern). :D

 

Ao citar PDO, eu quis dizer como usar PDO. Ao citar ORM e AL eu quis dizer como implementar (como funciona, qual a lógica, etc).