Sobre aquela de padrões vs flexibilidade

Uau, eu acabei de notar que eu perdi o prazo pra entregar-lhes uma nova postagem no blog. Mas é que as festas de fim de ano... tá! Não tem desculpa, eu vacilei...

Mas eu tenho estudado e pesquisado sobre aquela coisa de padronização do ambiente de desenvolvimento que eu falei no último post. Eu não fui o primeiro a questionar a padronização vs flexibilidade. Na verdade eu encontrei uma discussão muito boa (em inglês) aqui no StackOverflow. Claro né ;p. Há muitas opiniões interessantes como os...

Contras:

  • Padronização que burocratiza demais as coisas. Por isso a gente vê softwares de governo que ainda estão na versão 6 do IE.

É.. é basicamente isso mesmo, engessar o ambiente de desenvolvimento de forma que incluir novas tecnologias se torna uma pain in the ass. Porém isso afeta mais empresas que não possuem um foco no desenvolvimento, que faz várias aplicações diferentes. Quando não existe padrão algum entre as aplicações, todo dia é uma novidade. Nesse caso o foco é dentro de cada aplicação, ter tudo muito bem estruturado para que a manutenção não seja onerosa.

Poderíamos considerar os cacoetes do programador, como espaço ou tab, ou a IDE que ele prefere usar... Isso vai depender muito da linguagem e do foco da empresa. Portanto, não vou entrar nessa parte.

Prós:

  • Contratar é mais fácil: Você sabe as competências que busca.
  • Cortar custos de licença... As vezes você vai comprar softwares e se você usa em muitos projetos o custo cai.
  • Consistência na entrega do produto.
    • Você vai ter padrões de desempenho já conhecidos.
    • Documentação mais rica.
    • Um time pode pegar o trabalho do outro na metade e não vai ser um problema, porque a estrutura já vai ser conhecida.
  • Ajuda na inovação (!)
    • Temos que concordar que é muito mais fácil atualizar um código que tá bem documentado e tem uma arquitetura conhecida.
A lista de prós é MUITO maior e nem vale a pena no momento estender mais do que isso. Porque em resumo... Padronização e Flexibilização não são opostos extremos. E o padrão pode ser constantemente revisado, e não quer dizer que você vai ter que rever todo o padrão, só em casos pontuais, como incluir uma nova library ou framework, trocar linguagem.
 Padronização e flexibilidade não são inimigos.

Coisas como análise de requisitos, ciclos de desenvolvimento, containers vs maquina virtual, linguagem, geração automática de documentação, etc... são coisas que podem mudar de forma independente uma das outras. O principal ponto é que, com um padrão, você pode botar o básico rodando sem muito esforço e focar apenas nos problemas que o produto final precisa resolver.

 Conclusão

Minha conclusão é a seguinte, quando você tem uma rotina de desenvolvimento, sempre os mesmos produtos, sempre a mesma "base" os padrões emergem naturalmente. Então, trabalhe a favor da natureza, nunca contra. E por mais que cada caso seja um caso a padronização ainda pode ser um fator facilitador nos processos de atualização, porque tudo que já foi feito está claro e bem documentado.

But beware
 Quando você não tem esse padrão emergente através das aplicações, você tem vários clientes e cada um quer uma coisa diferente, como faz? Você precisa ser ágil ir adequando e estabelecendo as coisas a medida que-- eita, desenvolvimento ágil também é um padrão... mas o que?




Fontes:
Stack(Love)Overflow - Should developer tools, languages, frameworks, etc. be standardized across an organization? [closed]
Software Engineering Stack Exchange - Standards In Enterprise Development
Minha experiência - (drops the mic)
 

Comentários

Postar um comentário

Postagens mais visitadas deste blog

Como ler cada linha de um arquivo no Powershell

Imagem
Eu estava no sofa e tinha um computador conectado a TV tocando Reginaldo Rossi e estando nessa situação crítica eu percebi que deveria resolver isso da forma mais rápida possível.  É claro que isso significa fazer um pequeno script que acessa tenta acessar via SSH cada computador conectado ao roteador, assim eu poderia desligar ele. A primeira parte é simples, acessar o roteador e pegar a lista de IPs conectados. usei o ATOM para deixar só uma coluna de com os IPs, da seguinte forma: 1: 192.168.0.10 2: 192.168.0.12 3: 192.168.0.13 4: 192.168.0.16 5: 192.168.0.17 Até ai tranquilo, mas eu tava utilizando o Windows, o que significa aprender a fazer um for no Linux pegar cada linha do arquivo e executar alguma ação com cada uma delas... Sem mais delongas, aqui vai o pedaço de código: 1: foreach($line in Get-Content .\ips.txt) { 2: ssh $line 3: } E no fim! Não consegui acessar via SSH :(, mas já sei como fazer um foreach no powershell e pegar cada ...
Leia mais

Uma série sobre Python - Ambiente de desenvolvimento

Imagem
Esse post não estava nos planos, mas se fez relevante e na verdade é bem objetivo. No meu trabalho eu utilizo Ubuntu e nosso ambiente de desenvolvimento consiste em uma máquina vagrant e dentro dela um virtualenv com o código. A minha IDE é o PyCharm <3, que se conecta e identifica o ambiente de desenvolvimento dentro da máquina virtual. Já em casa, como eu gosto de jogar... utilizo o Windows 10. Mas enquanto levantava meu ambiente de desenvolvimento encontrei uma série de problemas com o Vagrant e o Virtualbox. Que já resolvi mas acabei pensando, "Porque não levantar tudo no windows?" A maneira fácil - em 3 passos Eu recomendo para iniciantes ou pra quem tá com pressa pra já chegar e desenvolver. E é minha configuração atual. Instale o Python e instale o PyCharm, e deixe que ele lide com os ambientes virtuais. Se você é universitário o PyCharm permite que use a versão profissional, você só precisa de um e-mail acadêmico. Então, três passos: Baixe o Python e instal...
Leia mais

Wagtail CMS para construção de sites - Apresentação

Imagem
O Wagtail é um CMS (Content Managment System) ou seja, um sistema de gerenciamento de conteúdo, porém, baseado em Django! Yes. Python! <3 O que não é Primeiramente, um pouco de contexto. O Wagtail não é como o Wordpress, ele se comporto muito mais como uma framework, como se fosse um superset de Django focado em CMS. Em outras palavras, é como se Django fosse um lego e o Wagtail já junta algumas peças, que você combina pra formar estruturas maiores ainda. Então, não espere instalar o Wagtail no seu projeto Python e ter um site rodando. Você antes de tudo vai precisar criar pelo menos um app (no modelo do django) e dentro de seu models, criar uma classe e dar vida à uma página. Para entender melhor porque funciona assim, vamos falar sobre o Zen do Wagtail. O Zen do Wagtail Se você nunca ouviu falar, comece com o Zen do Python . Da mesma forma, o Wagtail tem princípios de desenvolvimento para quem usa, como para quem trabalha no código fonte, de maneira simples e resu...
Leia mais