PHP
A maneira errada
Última atualização: 2023-01-31
No mundo da programação PHP um conjunto de tendências estão sendo massivamente propagadas por algumas pessoas (em seus livros e websites) como “PHP Moderno” enquanto todas as outras abordagens são vistas como atrasadas, estúpidas, ou simplesmente erradas.
Essas pessoas parecem trabalhar incansavelmente no sentido de conseguir que as outras pessoas sigam sua maneira de fazer as coisas.
Esse website foi criado numa tentativa de apresentar uma visão pragmática sobre a programação PHP. Uma visão ditada pela experiência e consequências práticas ao invés de tendências populares, teorias, ou dogmas acadêmicos.
O website PHP - The Wrong Way é um documento livre e continuará sendo atualizado com mais informações assim que estiverem disponíveis.
Sinta-se livre para contribuir.
Um problema com regras e diretrizes na programação é que elas geralmente só servem a um propósito em um contexto específico. Saindo desse contexto, uma boa regra pode se tornar uma regra horrível. De fato, toda boa regra se torna ruim quando levada ao extremo.
Isso é importante entender porque muitos princípios e regras do desenvolvimento de software desenvolvidas ao longo do tempo e apresentadas por diferentes pessoas frequentemente se tornam mal utilizadas nas mãos de extremistas.
A experiência ensinou que o uso indevido de regras e diretrizes gerais sempre resulta em complicações, falta de segurança, resultados propensos a erros e, em alguns casos, desastre total e completo.
O princípio KISS, que é um acrônimo para “Keep It Simple, Stupid”, é um bom e extremamente sábio princípio que geralmente é visto por pessoas experientes como um conselho muito bom a seguir, mas mesmo este grande princípio torna-se um perigo para um projeto, se levado ao extremo. Existe tal coisa como “muito simples” resultando em falta de funcionalidade necessária.
A maneira errada: Aplicação religiosa de regras e diretrizes. 
Todos os frameworks PHP de uso geral são uma merda!
Na comunidade PHP uma tendência muito ruim se tornou um padrão no desenvolvimento de aplicações web que é o uso de frameworks populares de uso geral.
Essa tendência surgiu e se tornou popular, não porque de alguma forma melhore o resultado do processo de desenvolvimento ou é a coisa certa a se fazer do ponto de vista da tecnologia e da arquitetura. Essa tendência se tornou popular porque alguns dos desenvolvedores que trabalham com frameworks conseguiram espalhar para um grande público a polêmica opinião contra a programação do zero, usando frases como “Não reinvente a roda!” e “Não faça você mesmo, os outros são mais hábeis que você”.
Muitos dos programadores de hoje ignoram completamente os princípios fundamentais da programação e passam muito tempo fantasiando novas camadas de complexidade, de modo a parecerem mais inteligentes, mais legais e mais aceitáveis em seu meio.
Essas pessoas parecem estar apaixonadas pelo pensamento de fazer com que outras sigam a sua “maneira de fazer as coisas”, tornando-se algum líder da comunidade PHP e fazendo com que outras pessoas usem suas mais recentes ferramentas de código-fonte “modernas”, que esquecem de garantir que os conselhos que estão dando são sólidos.
Nessa indústria de software você pode comparar uma casa pré-construída com um framework. Construir um software usando um framework faz de você um desenvolvedor ou programador que monta uma casa já pronta, um carpinteiro.
Nesse site, nós diferenciamos frameworks de bibliotecas dessa maneira:
No mundo do Python e Ruby, construir um site do zero é cansativo, porque nem o Python e nem o Ruby foi originado para criação de sites. Como resultado, frameworks como o Django e o Ruby on Rails rapidamente se tornaram porpulares entre os desenvolvedores de sites dessas linguagens.
O PHP, no entanto foi criado desde o início por Rasmus Lerdorf como um conjunto de ferramentas escritas em C que permitiam desenvolver de forma fácil e rápida um HTML dinâmico. Como tal, PHP era, e ainda é, um framework por si só.
O PHP evoluiu bastante desde então, e hoje o PHP pode ser usado para mais do que construir sites, mas olhar para o PHP como um tipo de framework não é errado. PHP é por natureza uma camada de abstração para desenvolvimento de aplicações web escritos inteiramente em C procedural.
Usar uma biblioteca dentro do seu projeto é normal. O próprio PHP vem com um conjunto de bibliotecas que você pode usar para estender para seu código. O PDO, por exemplo, é uma leve biblioteca que fornece uma interface consistente para conectar ao banco de dados pelo PHP.
Usar um framework por cima do PHP é outra coisa.
Quando você usa um framework no PHP, você adiciona uma camada de abstração em cima de outra camada de abstração, uma que já foi colocada para você no início. Adicionada a segunda camada de abstração, ou seja, o framework pode simplesmente servir para organizar o seu código em um conjunto de padrões pré-fixados, ou pode adicionar ainda mais complexidade entrelaçando centenas, ou até milhares de classes e métodos dentro de um pesadelo de dependências. De qualquer maneira você está adicionando camadas de complexidade para seu código que não são necessárias.
Toda a experiência começa com a interface. A experiência da interface é o resultado da tecnologia subjacente e da quantidade de camadas de abstração. Quanto mais abstração você usa, menos eficiente a interface se torna e mais suscetível a erros a aplicação se torna. Quanto maior a abstração, mais detalhes e eficiência são perdidos.
Entenda isso claramente: O número ideal de linhas de código em qualquer projeto é o mínimo possível, ao mesmo tempo que é o mais claro e legível possível!
O que todo mundo não precisa é de um framework genérico. Ninguém tem um problema genérico, todo mundo tem um problema muito específico que está tentando resolver.
Algumas empresas começaram a ouvir o borborinho sobre os frameworks PHP e iniciaram seus próximos projetos com esses frameworks genéricos só para ver esses projetos acabarem em um desastre. Eles não apenas descobriram que um framework genérico era muito ruim para resolver suas necessidades muito específicas, mas também eram extremamente lentos em fazê-los. Era impossível escalar, e como resultado, eles começaram a mexer no framework a parte, numa tentativa desesperada de retirar todas as coisas que realmente não precisavam.
Sempre use a abordagem pragmática:
Ação ou política ditada pela consideração das conseqüências práticas imediatas, e não pela teoria ou dogma.
– Collins English Dictionary, Complete and Unabridged, 12th Edition 2014
A maneira errada: Sempre use um framework em cima do PHP.
Tenho uma grande alergia aos Padrões de Projeto (Design Patterns). Peter Norvig, quando estava na Harlequin, escreveu esse artigo sobre como os padrões de projetos são apenas falhas nas suas linguagens de programação. Pegue uma linguagem de programação melhor. Ele estava absolutamente certo. Adorando padrões e pensando “Oh! Vou usar o padrão X.”
– Brendan Eich em Coders at work - Reflections on the Craft of Programming
Na engenharia de software, um padrão de projeto é uma solução reutilizável para um problema no design de software. Um padrão de projeto não é um design acabado que pode ser transformado diretamente em código. É uma descrição ou uma ideia de como solucionar um problema que pode vir a aparecer em muitas situações diferentes. Orientação a Objetos tipicamente demonstra relações e interações entre classes e objetos, sem especificar a aplicação final destes que estão envolvidos.
O PHP suporta paradigmas imperativos, funcionais, orientados a objetos, procedural e paradigmas reflexivos. O PHP é uma enorme caixa de ferramentas que faz o possível para solucionar muitos problemas de maneiras diferentes - não de um único jeito.
O PHP disponibiliza liberdade, soluções rápidas e escaláveis, e muitas outras maneiras diferentes de lidar com os problemas.
Quando tenta melhorar a si mesmo, e, neste caso, mais especificamente o código, às vezes fica-se presos a filosofia de um padrão ou ideia e tende-se a esquecer das situações que possuem suas próprias particularidades.
Quando vejo um padrão de projeto em meu programa, considero um sinal de problema. A forma de programar deve refletir somente os problemas que precisam de solução. Qualquer outra regularidade é um sinal, pelo menos pra mim, que estou usando abstrações que não são suficientes - frequentemente estou gerando manualmente algumas expansões macro que eu preciso escrever.
Não se deve agarrar em uma filosofia ou ideia por trás de um padrão específico ou solução. A principal preocupação é manter o código fácil de navegar e entender o máximo possível e como resultado, será manutenível e seguro.
Deve-se lembrar sempre que existem antipadrões. É um padrão comumente utilizado, mas é ineficiente e/ou contraprodutivo na prática.
Penso que os padrões começaram como melhores soluções para problemas comuns. Mas agora eles já existem há um tempo e temos experienciado aplicativos feitos dez vezes mais complicados que eles necessitavam, por conta das pessoas tentarem se concentrar em todos os padrões sobre os quais leram (“minha aplicação está muito bem arquitetada, porque é feita com padrões de projetos.”) minha impressão do valor de um padrão de projeto mudou um pouco.
– Paul Weaton in Evil Design Patterns
Sempre use a abordagem pragmática:
Ação ou política ditada pela consideração das consequências práticas imediatas ao invés de pôr teoria ou dogma.
– Collins English Dictionary, Complete and Unabridged, 12th Edition 2014
A maneira errada: Procure um padrão de projeto para resolver um problema.
O problema com programação orientação a objetos é que ela possui todo um contexto. Você queria uma banana, mas você acaba recebendo um gorila segurando uma banana e toda a floresta. – Joe Armstrong no Coders at work - Reflections on the Craft of Programming
Abstração é poderosa. O que eu realmente sou alérgico, e o que eu tive reação nos anos 90, foi todo o COBRA, COM, DCOM e orientação objetos sem noção. Toda ‘stratup’ unicórnio tinha algo extraordinário que levava 200 mil chamadas de métodos para iniciar e exibir um “Olá mundo”. Isso é uma tragédia! Você não quer ser um programador que associa-se a esse tipo de coisa. – Brendan Eich no Coders at work - Reflections on the Craft of Programming
Muitos outros desenvolvedores, e muitas empresas, acham que a orientação a objetos é a única maneira de razoável para desenvolver ‘softwares’ no atualmente. Qualquer um que argumenta contra a programação orientada a objetos é imediatamente conscientizada do fato de estarem argumentando contra a “sabedoria convencional” da indústria.
Nos blogs e foruns de programação, existem muitas pessoas que defendem a programação orientada a objetos, e que tem certeza de que sabem do que estão falando, apesar da falta de qualquer padrão de definição.
O fato é que a chamada programação orientada a objetos, como tal, frequentemente inflige um fardo pesado de complexidade desnecessária!
Como cientistas computacionais e programadores, devemos aprender a deixar de lado os preconceitos e encontrar a melhor solução para um determinado problema.
Hoje em dia, um dos principais pontos fortes do PHP é o suporte a paradigmas imperativos, funcionais, orientado a objetos, procedural e paradigmas reflexivos. O PHP é uma enorme caixa de ferramentas com muitas ferramentas diferentes que possibilitam resolver muitros problemas de várias maneiras - não apenas de uma maneira!
Assim que tentá-se forçar a alimentação de diferentes problemas dentro de uma aplicação para o único paradigma de orientação a objetos, não está trabalhando com eficiência!
Uma das inúmeras formas de entender um específico paradigma de programação é olhar como ele evoluiu. Qual foi a razão para esse desenvolvimento? Quais problemas existem com outros paradigmas de programação e do que precisavam de novo para resolver? Era um problema comum no trabalho ou simplesmente academico? E como isso evoluiu desde então?
Isso não importa que pessoa X disse ou qual a definição que a pessoa Y desenvolveu, o que importa no contexto do paradigma é a história que o criou.
Existem duas formas de construir um ‘design’ de software. Um das formas é deixa-lo simples para que não aja deficiências. E outra forma é deixa-lo tão complicado que não existem deficiências óbvias.
No passado, antes do advento da programação orientada a objetos, cerca dos anos 50, muitos ‘softwares’ foram desenvolvidos usando a linguagem de programação que enfatizavam a programação não estruturada, algumas vezes denominada de linguagens de primeira e segunda geração. Programação não estruturada é historicamente o paradigma de programação mais antigo. Foi muito criticado por porduzir código “espaguete”.
Existem linguagens programação de alto e baixo nível que usam programação não estruturada. Isso inclui versões anteriores do BASIC, COBOL, MUMPS, JOSS, FOCAL, TELCOMP, nível-máquina, novos sistemas assemblers (estas sem meta operadores procedurais) e algumas linguagens de scripts.
Um programa em uma linguagem não estruturada usualmente consiste do sequenciamento ordenado de comandos ou declarados, usualmente um em cada linha. As linhas são usualmente numeradas ou podem ter rótulos que permitem que o fluxo de execução salte para qualquer linha do programa (como na declaração impopular GOTO).
Então, nos anos sessenta, a programação estruturada surgiu - principalmente devido à famosa carta de Edsger W. Dijkstra Go To statements considered harmful.
Programação estruturada é um paradigma de programação que melhora a clareza, qualidade e desenvolvimento do software por meio de sub-rotinas, estruturas de blocos e laços de repetições. Isso constrata com o uso de saltos como a declaração GOTO.
Mais tarde, a programação procedural foi derivada da programação estruturada; Programação procedural é baseada no conceito de “chamada de procedimmento”. Uma chamada de procedimento é apenas um outro nome para chamada de função. Os procedimentos também são chamados de rotinas, subrotinas e métodos. Um procedimento simplesmente contém uma série de etapas computacionais a serem executadas. Qualquer procedimento pode ser chamado a qualquer momento durante a execução do programa, incluindo por outros procedimentos ou a si próprio.
No começo, todos os procedimentos eram disponibilizados para qualquer parte do programa, como dados globais. Em programas pequenos não apresentava problemas, mas conforme a complexidade do programa aumentava e o programa crescia, pequenas mudanças em uma parte do programa afetavam muitas outras partes.
Ninguém estava planejando mudanças no programa e muitas dependências existiam. Um pequena alteração em um procedimento resultaria em uma cascata de erros em muitos outros procedimentos que dependiam do código original.
Uma nova técnica surgiu e permita que os dados fossem divididos entre escopos separados chamados “objetos”. Apenas procedimentos específicos pertencentes ao mesmo escopo poderia acessar os mesmos dados. Isso é chamado de encapsulamento. O resultado foi um código muito mais organizado.
No começo, os objetos não eram chamados de objetos, eram apenas vistos como escopos separados. Mais tarde, quando as dependências foram reduzidas e as conexões entre procedimentos e variáveis dentro desses escopos foram vistas como segmentos isolados, do resultado nasceu os conceitos de “objetos” e “programação orientada a objetos”.
Mais tarde, principalmente devido ao desenvolvimento do Java, surgiram certas “palavras-chave” e um “procedimento” (ou “função”, não era mais chamado de função, mas foi renomeado para “método”, quando residia dentro de um escopo separado. As variáveis foram também deixaram de ser “variáveis” e foram renomeadas para “atributos”, quando residia dentro de um escopo separado.
Então, um objeto é uma coleção de funções e variáveis, que agora se chamam de “métodos” e “atributos”, respectivamente.
O modo que os métodos e atributos são isolados dentro de um escopo separado é pelo uso de uma “classe”. Uma classe, uma vez instanciada, é chamada de objeto.
Objetos podem referenciar outros objetos por métodos (funções) internas, podendo comunicar-se entre si. Objetos também podem “herdar” métodos de outros objetos estendendo-os, isso é chamado de “herança”. Isso é uma maneira de reusar código e permitir extensões independentes de software por meio classes e interfaces públicas. O relacionamento dos objetos dão origem a uma hierarquia. Herança foi inventada em 1967 para a linguagem de programação Simula 67.
Objetos também podem herdar métodos de outros objetos e sobrescrevê-los com funcionalidades adicionais, isso é chamado “polimorfismo”.
Como essas ideias diferentes são implementadas variam muito de linguagem de programação para linguagem de programação.
Programação orientada a objetos trata-se de organizar o código de uma maneira diferente das anteriores. É uma extensão da programação procedural e trata-se de ocultar dados (encapsulamento) e evitar o escopo global. Trata-se de estender funções herdando seu escopo sem afetar atualmente o código original (herança). Trata-se de sobrescrever funções sem afetar o código original (polimorfismo).
O modelo de orientação a objeto torna fácil a criação de programas por acréscimo. O que frequentemente significa, na prática, é o que fornece uma maneira estruturada para código espaguete.
– Paul Graham em Ansi Common Lisp
A maneira errada: Sempre use programação orientada a objetos.
Um argumento frequentemente expresso para o uso de um framework é que as pessoas não querem lidar com códigos que foram escritos do zero por outras pessoas.
Esta é, no entanto, uma mentalidade estranha, encontrada principalmente entre web developers na comunidade PHP, que exala uma falta de profissionalismo e experiência.
Escrever software e lidar com o código de outras pessoas é normal, é parte do trabalho diário de quem programa profissionalmente, não é algo para se ter medo.
Quem programa profissionalmente não olha para o código de outras pessoas e começa a se lamentar sobre como está à mercê completa do ex-programador, que talvez não esteja mais associado à empresa ou projeto, e se apenas o antigo programador tivesse usado uma estrutura A ou framework B o dia teria sido salvo.
Esta não é a mentalidade de quem programa de maneira profissional. Ninguém faz isso.
Talvez a facilidade de entrada no desenvolvimento web do PHP desempenhe um papel nesse tipo de mentalidade. Independentemente disso, é um sinal de uma pessoa estar na linha errada de trabalho.
Uma grande parte da programação lida com pessoas que precisam trabalhar com código de outras pessoas. Faz parte do trabalho tentar melhorar a base de código existente e, por vezes, isso envolve uma reescrita completa.
Tome nota de pessoas que são grandes referências da programação, leia o livro Coders at work - Reflections on the Craft of Programming.
Algumas das bases de código maiores e mais bem sucedidas do mundo são bases de código que foram desenvolvidas por centenas de pessoas que nunca se conheceram, bases de código desenvolvidas sem o uso de qualquer tipo de framework, bases de código feitas inteiramente em uma linguagem de programação procedural sem o uso de qualquer coisa, mas o paradigma procedural, e eles não sonham em fazê-lo de forma diferente.
O Kernel do Linux consiste em mais de 20 milhões de linhas de código que foram inteiramente escritas utilizando programação procedural por mais de 14.000 pessoas sem o uso de qualquer tipo de framework.
Os diferentes sabores BSD e a maioria do Linux GNU foram escritos inteiramente usando programação procedural sem o uso de qualquer tipo de framework.
O mesmo vale para centenas de projetos de código aberto em torno desse mundo que acabaram sendo abandonados pela (s) pessoa (s) que os desenvolvia (m) originalmente apenas para serem escolhidos por outras pessoas habilidosas. Muitos desses projetos tinham pouca documentação (se é que tinham alguma), nenhum comentário na base de código e nenhuma orientação ou ajuda para oferecer.
Toda a base de código PHP é feita em C, uma linguagem de programação puramente procedural, sem o uso de qualquer tipo de framework.
A base de código PHP inteira é feita em C, uma linguagem de programação processual pura, sem o uso de qualquer tipo de framework que assim sempre.
Sempre que você define uma classe em PHP ou sempre que usa o seu framework PHP favorito, sua aplicação roda sobre o trabalho puramente procedural de outra pessoa!
Claro, existem coisas como código horrível, código que talvez não tenha sido projetado desde o início, ou código que talvez tenha crescido demais, mas o cliente não queria lidar com uma reescrita, código tão ruim você não pode fazer cara ou coroa dele por mais tempo, mas nenhum tipo de framework teria evitado essa situação. Este é frequentemente o processo natural de crescimento de um programa. Eventualmente, qualquer tipo de estrutura teria sido destruída de qualquer maneira.
E com certeza existe código spagetti horrível, mas ninguém produz um código horrível de propósito. Às vezes isso é resultado da falta de experiência, muitas vezes é culpa do cliente porque ele altera as especificações várias vezes no meio do desenvolvimento, em qualquer um dos dois casos, mesmo que um framework seja usado, o resultado ainda seria código spagetti, e não importa quanto do paradigma orientado a objeto fosse usado, o resultado ainda seria código spagetti.
Como pessoas desenvolvedoras, tentamos evitar essas situações, mas isso é normal, isso é a arte da programação, isso é parte do que significa ser uma pessoa que programa!
O caminho errado: Ter medo do código de outras pessoas.
O acrônimo FIG significa “Framework Interoperability Group” (Grupo de Interoperabilidade de Framework).
O PHP-FIG foi criado por alguns desenvolvedores de framework na conferência php|tek em 2009. Desde então vários outros membros foram aceitos, aumentando o tamanho do grupo de 5 para mais de 20.
Muita controvérsia existe a respeito do PHP-FIG. Algumas pessoas consideram o PHP-FIG a melhor coisa que aconteceu para a comunidade PHP desde o PHP em si, enquanto outros consideram o grupo como melhor ser esquecido.
Um dos problemas do PHP-FIG é que ele se apresenta dessa forma no seu FAQ:
A idéia por trás do grupo é que representantes de projetos falem sobre os pontos em comum entre nossos projetos e encontrem maneiras de trabalharmos juntos. Nossa principal audiência somos nós mesmos, mas estamos muito cientes que o resto da comunidade PHP está acompanhando. Se outras pessoas quiserem adotar o que estamos fazendo eles serão bem vindos, mas esse não é o objetivo. Ninguém no grupo quer ensinar você como construir sua aplicação.
Entretando, quando vemos o trabalho de vários membros do grupo, podemos ver claramente que o objetivo é exatamente o contrário do que foi dito acima. Estes membros trabalham incansavelmente na tentativa de fazer o PHP-FIG se tornar um padrão PHP aceito (“PHP standards group”), que aliás era o nome original do grupo. Eles tentam isso classificando o trabalho do PHP-FIG como “PHP moderno” em seus livros, em seus sites, em seus blogs, fóruns, etc., e classificando as outras formas como antiquadas.
Um dos problemas do PHP-FIG é que mesmo que muitos projetos de frameworks de código aberto adotem vários de seus padrões, esses padrões lidam com problemas “da perspectiva do framework”, que os torna inúteis em várias situações da vida real.
Muitas pessoas desenvolvem softwares para o comércio em geral que devem ser extremamente eficiêntes, seguros, e com bom custo-benefício, softwares que clientes querem comprar e usar. Eles não precisam se incomodar com padrões para atender as necessidades de fanáticos por frameworks. Se eles tentassem seria um desastre para os negócios.
Se algum tipo de grupo de padrõres precisa ser criado ele tem que refletir os interesses da comunidade PHP como um todo, não apenas desenvolvedores de frameworks de código aberto e sistemas de CMS. O grupo terá que ser representado por desenvolvedodres da linguagem PHP e também deverá ter um número maior de membros com o direito de votar.
Se você escolher adotar os padrões propostos pelo PHP-FIG, você tem que entender que alguns dos padrões - como o de auto-carregamento (autoloader) PSR-0 e PSR-4, entre outros - tem um efeito direto em como você desenvolve seu software.
Muitos negócios requerem softwares com alta escalabilidade, sistemas críticos de tempo real, e com bom custo-benefício que simplesmente não podem ser desenvolvidos utilizando estes padrões do PHP-FIG.
A maneira errada: Seguir o PHP-FIG de maneira religiosa.
O problema com os programadores é que você nunca sabe dizer o que eles estão fazendo, até que seja tarde demais.
– Seymour Cray on defprogramming.com
A programação segura é a prática de escrever programas que são resistentes ao ataque de pessoas maliciosas ou outros programas. A programação segura ajuda a proteger os dados contra roubo ou corrupção. Além disso, um programa inseguro pode fornecer acesso a um invasor para assumir o controle de um servidor ou a identidade de um usuário, resultando em qualquer coisa, de uma negação de serviço para um usuário ao comprometimento de dados sigilosos, perda de serviço ou danos aos sistemas de milhares de usuários
Todo programa de computador é um alvo em potencial para um ataque de segurança. Os atacantes tentarão encontrar vulnerabilidades de segurança em suas aplicações. Eles tentarão então usar essas vulnerabilidades para roubar ou corromper programas e dados, e ganhar controle de servidores e redes. Os dados de seus clientes e sua reputação estão em jogo.
A segurança não é algo que pode ser adicionado ao software!
Uma aplicação insegura pode exigir um redesenho extenso para protegê-la. Deve-se identificar a natureza das ameaças ao seu software e incorporar práticas de programação seguras antes e durante o planejamento e desenvolvimento de sua aplicação.
Proteger os recursos críticos do software é mais importante do que nunca, pois o foco dos atacantes se moveu constantemente para a camada de aplicação. Um estudo de 2009, da SANS, descobriu que ataques contra aplicações web representam mais de 60% das tentativas de ataque total observadas na Internet.
O PHP é incomum, pois é uma linguagem de programação e uma estrutura da web ao mesmo tempo. Isso significa que o PHP tem muitos recursos da web incorporados a linguagem, o que torna muito fácil escrever um código inseguro.
A complexidade mata. Isso suga a vida dos desenvolvedores, torna os produtos difíceis de planejar, desenvolver e testar, introduz desafios de segurança e causa frustração de usuários finais e administradores.
Para que as aplicações sejam projetadas e implementadas com requisitos de segurança adequados, práticas de programação segura e um foco em riscos de segurança devem ser integrados nas operações do dia-a-dia, nos pensamentos e nos próprios processos de desenvolvimento.
Geralmente, é muito mais barato construir software seguro do que corrigir problemas de segurança após o pacote de software ter sido concluído, para não mencionar os custos que podem estar associados a uma violação de segurança.
A maneira errada: Não desenvolvendo software seguro por padrão.
É fácil interpretar de forma errada um documento escrito, então vamos esclarecer algumas coisas.
P: Qual é a intenção desse site e por que essa abordagem de confronto?
R: Para criar uma discussão e reflexão sobre as práticas atuais e visões extremas.
P: Você está dizendo que a programação orientada à objetos é ruim ou errada?
R: Não, claro que não! Nós estamos dizendo que “sempre pensar e sempre usar somente o paradigma de orientação à objetos na resolução de problemas é ruim”. Sempre que você pensa em preto e branco somente, isso é errado.
Mesmo dentro de uma única aplicação existem diferentes problemas. Multi-paradigma é, por vezes, a melhor solução, tudo depende do problema que você está tentando resolver.
Sempre que você força soluções impróprias para um problema específico, coisas ruins acontecem.
P: Você está dizendo que todos os frameworks são ruins?
R: Nós não estamos tentando julgar frameworks específicos. Estamos lidando com a questão de sempre usar um framework para trabalhar com PHP.
P: Se um framework pode me ajudar e executa rápido, por que é tão ruim?
R: Se você analisar a situação e as implicações a longo prazo e, em seguida, ver que “executar rapidamente” é o único problema que você sempre tem que lidar, não é ruim, mas então não estamos trabalhando com programação ou desenvolvimento de software, estamos lidando principalmente com soluções “apontar e clicar”.
Executar rapidamente não é projetar um software, isso significa, principalmente, que você não analisou o problema que você está enfrentando e você não ter entendeu as implicações a longo prazo de sua escolha.
P: Você está dizendo que bibliotecas de terceiros são ruins?
R: Não. Nós estamos promovendo o uso de bibliotecas de terceiros. O código que você pode facilmente integrar em seus próprios projetos sem nunca impor quaisquer limitações ou restrições. Esses são ótimos!
P: Quem é você?
R: Este site é sobre algumas ideias e sobre combater o extremismo na comunidade PHP, não é sobre a fama pessoal ou reconhecimento. Nomear pessoas só vai mudar o foco dos problemas abordados no site para as pessoas que tratam os problemas. Vamos manter o foco nas idéias.
P: Qual é a sua experiência no desenvolvimento de software?
R: As ideias, pensamentos e conclusões expressas neste site não necessitam de muita experiência para serem alcançadas, se você apenas manter o foco sobre o tema principal, que é fazer sempre uma coisa em particular porque outras pessoas dizem isso.
PHP The Wrong Way on Hacker News
Why bad scientific code beats code following “best practices”
Coders at work - Reflections on the Craft of Programming
The traits of a proficient programmer
OWASP Secure Coding Guidelines
Survive The Deep End: PHP Security
Refactoring Improving the Design of Existing Code
Understanding programming languages
Contribua no GitHub.