Evolução de um sistema legado. Estratégias, mindsets, técnicas ninjas...

[Felix Costa]

Pessoal, boa noite!

Acredito que boa parte de vocês devam ter tido experiência ou contato com sistemas legados sem o mínimo de qualquer bateria de testes ou algo assim. A minha dúvida é como evoluir um software nesse estado, seja no quesito de testes, melhor arquitetura, formas de escalar ou mesmo estratégias de upgrade (por exemplo, um sistema usando zf1 para algo mais próximo do expressive).

Sei que é uma questão complicada de debater e ditar uma receita de bolo, mas como vocês encararam isso e que tipo de pensamento ou estratégias é possível adotar para que você consiga evoluir o software, sem esquecer é claro, da questão dos prazos. Há uma forma de receber uma feature X, e conseguir implementar ela e ao mesmo tempo usar a regra do escoteiro (deixar o local mais organizado).

Quais materiais existentes que vocês recomendam que debatem sobre esse tipo de decisão?

ps: sei que em muitos casos, um upgrade não é necessário, mas isso é verdade mesmo para aqueles sistemas sem testes nenhum onde você implementa algo, vai testar e reza pra ter ocorrido tudo bem? Acho esse sentimento tão errado que não me convenci de que um sistema desses não precisa ser refatorado ou algo assim. Valeu!

ps2: já tive uma conversa breve similar sobre isso com o Edy, mas queria que, se possível, ele deixasse registrado aqui para pesquisas futuras e pra quem mais quiser também, hehe.

[Márcio Albuquerque]

Felix, relaxa um pouco... Sempre é bom ter um sistema com tudo em cima, com todo no lugar, mas as vezes não tem jeito!! Eu sempre sigo a seguinte regra: achou um bug, escreve um teste! Com isso, vou aumentando a cobertura de sistemas legados.

A meu ver, vc usa se cobrando demais. Mas isso é bom... Até certo limite! :D

[Paulo de Almeida]

Concordo com Márcio, mas vou deixar minha contribuição.

Se você pensa em upgrade ou mudança de tecnologia, eu recomendo estrangulamento. Já fiz isso antes migrando de .net para laravel e deu certo, toda nova funcionalidade que era implementada, era em laravel e aos poucos fomos migrando, pois quando se cria uma coisa nova, tem que mexer em alguma coisa antiga. Com isso iamos implementando os testes e a arquitetura emergia.

Testes em sistema legado é complicado, se vc para para testar, vc vai achar um monte de decisões arquiteturais que já foram boas, mas não são mais. Então nem esquente com isso, a medida que vc for criando novas funcionalidades, e, se for necessário, crie os testes para o código legado.

Em relação ao tempo de desenvolvimento, ai vai depender de um monte de coisas, e como vc mesmo disse, não tem receita de bolo.

Em 14 de janeiro de 2018 00:44, Márcio Albuquerque <marcio.lima...@gmail.com> escreveu:

Felix, relaxa um pouco... Sempre é bom ter um sistema com tudo em cima, com todo no lugar, mas as  vezes não tem jeito!! Eu sempre sigo a seguinte regra: achou um bug, escreve um teste! Com isso, vou aumentando a cobertura de sistemas legados.

A meu ver, vc usa se cobrando demais. Mas isso é bom... Até certo limite! :D

--
PHPBA
---
Você está recebendo esta mensagem porque se inscreveu no grupo "PHPBA" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para phpba+unsubscribe@googlegroups.com.
Para obter mais opções, acesse https://groups.google.com/d/optout.

--

Paulo de Almeida

Linux User #494076
Ubuntu User # 28289

"In a world without walls who needs windows and gates?"

[Edy]

E para somar.... 

Sigo parecido com a ideia de migração de um aplicação monolítica para uma aplicação em micro serviço. Nesse caso seria com duas opções. Com novas features, isolando em módulos separados e testatos, ou correção de bugs, onde também isolo em modulo separado e vou depreciando os recursos antigos. Uma coisa é certa, dificilmente a empresa vai gastar recursos migrando a aplicação 100%. Só se tiver muita grana. rsrsr

Uma dica que dou é, meta as caras e vá fazendo essa migração aos poucos. Em relação a prazo, não tem jeito meu filho, vai ter que cumprir ele e ainda testar. Assobiar e chupa cana. Caso contrário terá um sofrimento pelo resto da vida!!!

Em dom, 14 de jan de 2018 às 07:06, Paulo de Almeida <paulode...@gmail.com> escreveu:

Concordo com Márcio, mas vou deixar minha contribuição.

Se você pensa em upgrade ou mudança de tecnologia, eu recomendo estrangulamento. Já fiz isso antes migrando de .net para laravel e deu certo, toda nova funcionalidade que era implementada, era em laravel e aos poucos fomos migrando, pois quando se cria uma coisa nova, tem que mexer em alguma coisa antiga. Com isso iamos implementando os testes e a arquitetura emergia.

Testes em sistema legado é complicado, se vc para para testar, vc vai achar um monte de decisões arquiteturais que já foram boas, mas não são mais. Então nem esquente com isso, a medida que vc for criando novas funcionalidades, e, se for necessário, crie os testes para o código legado.

Em relação ao tempo de desenvolvimento, ai vai depender de um monte de coisas, e como vc mesmo disse, não tem receita de bolo.

Em 14 de janeiro de 2018 00:44, Márcio Albuquerque <marcio.lima...@gmail.com> escreveu:

Felix, relaxa um pouco... Sempre é bom ter um sistema com tudo em cima, com todo no lugar, mas as  vezes não tem jeito!! Eu sempre sigo a seguinte regra: achou um bug, escreve um teste! Com isso, vou aumentando a cobertura de sistemas legados.

A meu ver, vc usa se cobrando demais. Mas isso é bom... Até certo limite! :D

--
PHPBA
---
Você está recebendo esta mensagem porque se inscreveu no grupo "PHPBA" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para phpba+un...@googlegroups.com.

Para obter mais opções, acesse https://groups.google.com/d/optout.

--

Paulo de Almeida

Linux User #494076
Ubuntu User # 28289

"In a world without walls who needs windows and gates?"

--
PHPBA
---
Você recebeu essa mensagem porque está inscrito no grupo "PHPBA" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para phpba+un...@googlegroups.com.
Para mais opções, acesse https://groups.google.com/d/optout.

[Felix Costa]

Obrigado pelas contribuições, pessoal!

Curti bastante essa ideia do estrangulamento e realmente me parece uma forma até natural de se migrar as coisas e aí pode ficar algo realmente parecido com uma ideia de microserviços, onde basicamente vai ter o legado e para as novas features um "contexto" novo onde faço ambos se comunicarem.... O lance é quando na verdade é uma correção ou mudança de requisito e não uma adição de feature, né?

Acho que estou convencido que começar a criar testes unitários pra essa base de código enorme legada vai ser impossível levando em conta prazos e etc. O Paulo citou uma coisa bem legal que foi: "decisões arquiteturais que já foram boas, mas não são mais". O que vocês pensam sobre o código de hoje, sim, o de hoje mesmo, virar algo legado daqui a 6 meses? Tipo, o processo de decisão de uma arquitetura hoje, quais os critérios que vocês levam em consideração para que essa decisão arquitetural se mantenha boa o suficiente ou ao menos que possa ser mudada, ou escalada, não sei. Ou como Márcio disse, eu to me preocupando demais? Haha..

Penso nessas coisas principalmente porque escrever código simplesmente resolvendo o problema de hoje pode me trazer o dobro de problema. Até que ponto vocês acham sadio pensar dessa forma?

--

Atenciosamente,

Felix Costa

Software Developer
Site: https://fxcosta.github.io

GitHub: https://github.com/fxcosta

[Márcio Albuquerque]

Se for ficar de preocupando em fazer coisas pensando no futuro, vai pirar, cara!! E isso quebra um pouco até os conceitos do ágil... Além disso, imagine o cara trabalhando em sua arquitetura há uns 4 anos atrás, pensando em infraestrutura física ou mesmo VM. De repente, aparece Docker... Ele vai parar todo e redirecionar pra docker? Ou apareceu uma linguagem melhor, vai apagar todo e fazer na nova?

É bom estar antenado, saber que existem conceitos interessantes. Mas se escolheu um caminho, tente não se desviar muito dele. Por isso gosto de micro serviços. Só mesmo jeito que frameworks usam baixo acoplamento, acho que micro serviços permite um baixo acoplamento a nível de ideias.

Marcio Albuquerque
==================
Analista de Infra SERPRO
Celular - 071 98880 4994

[Edy]

Uma forma que vejo para não prever o futuro é uma boa aplicação dos padrões de projeto. Bem aplicado permite uma evolução natural do seu projeto para que mais para frente não seja o legado bizarro.

Em 17 de jan de 2018 09:16, "Márcio Albuquerque" <marcio.lima...@gmail.com> escreveu:

Se for ficar de preocupando em fazer coisas pensando no futuro, vai pirar, cara!! E isso quebra um pouco até os conceitos do ágil... Além disso, imagine o cara trabalhando em sua arquitetura há uns 4 anos atrás, pensando em infraestrutura física ou mesmo VM. De repente, aparece Docker... Ele vai parar todo e redirecionar pra docker? Ou apareceu uma linguagem melhor, vai apagar todo e fazer na nova?

É bom estar antenado, saber que existem conceitos interessantes. Mas se escolheu um caminho, tente não se desviar muito dele. Por isso gosto de micro serviços. Só mesmo jeito que frameworks usam baixo acoplamento, acho que micro serviços permite um baixo acoplamento a nível de ideias.

Em ter, 16 de jan de 2018 16:16, Felix Costa <fx3c...@gmail.com> escreveu:

Obrigado pelas contribuições, pessoal!

Curti bastante essa ideia do estrangulamento e realmente me parece uma forma até natural de se migrar as coisas e aí pode ficar algo realmente parecido com uma ideia de microserviços, onde basicamente vai ter o legado e para as novas features um "contexto" novo onde faço ambos se comunicarem.... O lance é quando na verdade é uma correção ou mudança de requisito e não uma adição de feature, né?

Acho que estou convencido que começar a criar testes unitários pra essa base de código enorme legada vai ser impossível levando em conta prazos e etc. O Paulo citou uma coisa bem legal que foi: "decisões arquiteturais que já foram boas, mas não são mais". O que vocês pensam sobre o código de hoje, sim, o de hoje mesmo, virar algo legado daqui a 6 meses? Tipo, o processo de decisão de uma arquitetura hoje, quais os critérios que vocês levam em consideração para que essa decisão arquitetural se mantenha boa o suficiente ou ao menos que possa ser mudada, ou escalada, não sei. Ou como Márcio disse, eu to me preocupando demais? Haha..

Penso nessas coisas principalmente porque escrever código simplesmente resolvendo o problema de hoje pode me trazer o dobro de problema. Até que ponto vocês acham sadio pensar dessa forma?

Em seg, 15 de jan de 2018 às 15:23, Edy <edy...@gmail.com> escreveu:

E para somar.... 

Sigo parecido com a ideia de migração de um aplicação monolítica para uma aplicação em micro serviço. Nesse caso seria com duas opções. Com novas features, isolando em módulos separados e testatos, ou correção de bugs, onde também isolo em modulo separado e vou depreciando os recursos antigos. Uma coisa é certa, dificilmente a empresa vai gastar recursos migrando a aplicação 100%. Só se tiver muita grana. rsrsr

Uma dica que dou é, meta as caras e vá fazendo essa migração aos poucos. Em relação a prazo, não tem jeito meu filho, vai ter que cumprir ele e ainda testar. Assobiar e chupa cana. Caso contrário terá um sofrimento pelo resto da vida!!!

Em dom, 14 de jan de 2018 às 07:06, Paulo de Almeida <paulode...@gmail.com> escreveu:

Concordo com Márcio, mas vou deixar minha contribuição.

Se você pensa em upgrade ou mudança de tecnologia, eu recomendo estrangulamento. Já fiz isso antes migrando de .net para laravel e deu certo, toda nova funcionalidade que era implementada, era em laravel e aos poucos fomos migrando, pois quando se cria uma coisa nova, tem que mexer em alguma coisa antiga. Com isso iamos implementando os testes e a arquitetura emergia.

Testes em sistema legado é complicado, se vc para para testar, vc vai achar um monte de decisões arquiteturais que já foram boas, mas não são mais. Então nem esquente com isso, a medida que vc for criando novas funcionalidades, e, se for necessário, crie os testes para o código legado.

Em relação ao tempo de desenvolvimento, ai vai depender de um monte de coisas, e como vc mesmo disse, não tem receita de bolo.

Em 14 de janeiro de 2018 00:44, Márcio Albuquerque <marcio.lima.albuquerque@gmail.com> escreveu:

Felix, relaxa um pouco... Sempre é bom ter um sistema com tudo em cima, com todo no lugar, mas as  vezes não tem jeito!! Eu sempre sigo a seguinte regra: achou um bug, escreve um teste! Com isso, vou aumentando a cobertura de sistemas legados.

A meu ver, vc usa se cobrando demais. Mas isso é bom... Até certo limite! :D

--
PHPBA
---
Você está recebendo esta mensagem porque se inscreveu no grupo "PHPBA" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para phpba+unsubscribe@googlegroups.com.

Para obter mais opções, acesse https://groups.google.com/d/optout.

--

Paulo de Almeida

Linux User #494076
Ubuntu User # 28289

"In a world without walls who needs windows and gates?"

--
PHPBA
---
Você recebeu essa mensagem porque está inscrito no grupo "PHPBA" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para phpba+unsubscribe@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

--
PHPBA
---
Você recebeu essa mensagem porque está inscrito no grupo "PHPBA" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para phpba+unsubscribe@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

--

Atenciosamente,

Felix Costa

Software Developer
Site: https://fxcosta.github.io

GitHub: https://github.com/fxcosta

--
PHPBA
---
Você recebeu essa mensagem porque está inscrito no grupo "PHPBA" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para phpba+unsubscribe@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

--

Marcio Albuquerque
==================
Analista de Infra SERPRO
Celular - 071 98880 4994

--

PHPBA
---
Você recebeu essa mensagem porque está inscrito no grupo "PHPBA" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para phpba+unsubscribe@googlegroups.com.

[Márcio Albuquerque]

Verdade... Padrões junto com micro serviços da pra melhorar sempre. Mas vcs da Olaria sabem disso    :D

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para phpba+un...@googlegroups.com.

Para obter mais opções, acesse https://groups.google.com/d/optout.

--

Paulo de Almeida

Linux User #494076
Ubuntu User # 28289

"In a world without walls who needs windows and gates?"

--
PHPBA
---
Você recebeu essa mensagem porque está inscrito no grupo "PHPBA" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para phpba+un...@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

--
PHPBA
---
Você recebeu essa mensagem porque está inscrito no grupo "PHPBA" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para phpba+un...@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

--

Atenciosamente,

Felix Costa

Software Developer
Site: https://fxcosta.github.io

GitHub: https://github.com/fxcosta

--
PHPBA
---
Você recebeu essa mensagem porque está inscrito no grupo "PHPBA" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para phpba+un...@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

--

Marcio Albuquerque
==================
Analista de Infra SERPRO
Celular - 071 98880 4994

--
PHPBA
---
Você recebeu essa mensagem porque está inscrito no grupo "PHPBA" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para phpba+un...@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

--
PHPBA
---
Você recebeu essa mensagem porque está inscrito no grupo "PHPBA" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para phpba+un...@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

[Vinicius Cruz]

Pegando gancho do que Márcio falou, considero importante nesse cenário ter um código portátil, onde aquele que a regra de seu negócio não dependa nem de framework. Obviamente, algumas camadas terá dependência, tal como repository (ainda mais com active record). Por isso gosto muito do PSR-7, ele permite definir as interfaces e alinhar a compatibilidade entre fw.

Exemplificando com o que vc conhece (em off kkk): vc passa um, dois anos desenvolvendo um projeto em silex. Aí, pouco antes de publicar, lançam o symfony 4 e mataram o silex. E aí? Já é código legado, pra reescrever todo?

Hj eu tenho uma app em zend, eu posso portar ele pra o slim, por exemplo, sem muito esforço. Mas ainda assim, por mais hypes e barulho que a comunidade faça por um novo fw que lançou, é preciso ter cautela.

Att,
Vinicius Cruz

2018-01-17 10:11 GMT-03:00 Márcio Albuquerque <marcio.lima...@gmail.com>:

Verdade... Padrões junto com micro serviços da pra melhorar sempre. Mas vcs da Olaria sabem disso    :D

Em qua, 17 de jan de 2018 09:48, Edy <edy...@gmail.com> escreveu:

Uma forma que vejo para não prever o futuro é uma boa aplicação dos padrões de projeto. Bem aplicado permite uma evolução natural do seu projeto para que mais para frente não seja o legado bizarro.

Em 17 de jan de 2018 09:16, "Márcio Albuquerque" <marcio.lima.albuquerque@gmail.com> escreveu:

Se for ficar de preocupando em fazer coisas pensando no futuro, vai pirar, cara!! E isso quebra um pouco até os conceitos do ágil... Além disso, imagine o cara trabalhando em sua arquitetura há uns 4 anos atrás, pensando em infraestrutura física ou mesmo VM. De repente, aparece Docker... Ele vai parar todo e redirecionar pra docker? Ou apareceu uma linguagem melhor, vai apagar todo e fazer na nova?

É bom estar antenado, saber que existem conceitos interessantes. Mas se escolheu um caminho, tente não se desviar muito dele. Por isso gosto de micro serviços. Só mesmo jeito que frameworks usam baixo acoplamento, acho que micro serviços permite um baixo acoplamento a nível de ideias.

Em ter, 16 de jan de 2018 16:16, Felix Costa <fx3c...@gmail.com> escreveu:

Obrigado pelas contribuições, pessoal!

Curti bastante essa ideia do estrangulamento e realmente me parece uma forma até natural de se migrar as coisas e aí pode ficar algo realmente parecido com uma ideia de microserviços, onde basicamente vai ter o legado e para as novas features um "contexto" novo onde faço ambos se comunicarem.... O lance é quando na verdade é uma correção ou mudança de requisito e não uma adição de feature, né?

Acho que estou convencido que começar a criar testes unitários pra essa base de código enorme legada vai ser impossível levando em conta prazos e etc. O Paulo citou uma coisa bem legal que foi: "decisões arquiteturais que já foram boas, mas não são mais". O que vocês pensam sobre o código de hoje, sim, o de hoje mesmo, virar algo legado daqui a 6 meses? Tipo, o processo de decisão de uma arquitetura hoje, quais os critérios que vocês levam em consideração para que essa decisão arquitetural se mantenha boa o suficiente ou ao menos que possa ser mudada, ou escalada, não sei. Ou como Márcio disse, eu to me preocupando demais? Haha..

Penso nessas coisas principalmente porque escrever código simplesmente resolvendo o problema de hoje pode me trazer o dobro de problema. Até que ponto vocês acham sadio pensar dessa forma?

Em seg, 15 de jan de 2018 às 15:23, Edy <edy...@gmail.com> escreveu:

E para somar.... 

Sigo parecido com a ideia de migração de um aplicação monolítica para uma aplicação em micro serviço. Nesse caso seria com duas opções. Com novas features, isolando em módulos separados e testatos, ou correção de bugs, onde também isolo em modulo separado e vou depreciando os recursos antigos. Uma coisa é certa, dificilmente a empresa vai gastar recursos migrando a aplicação 100%. Só se tiver muita grana. rsrsr

Uma dica que dou é, meta as caras e vá fazendo essa migração aos poucos. Em relação a prazo, não tem jeito meu filho, vai ter que cumprir ele e ainda testar. Assobiar e chupa cana. Caso contrário terá um sofrimento pelo resto da vida!!!

Em dom, 14 de jan de 2018 às 07:06, Paulo de Almeida <paulode...@gmail.com> escreveu:

Concordo com Márcio, mas vou deixar minha contribuição.

Se você pensa em upgrade ou mudança de tecnologia, eu recomendo estrangulamento. Já fiz isso antes migrando de .net para laravel e deu certo, toda nova funcionalidade que era implementada, era em laravel e aos poucos fomos migrando, pois quando se cria uma coisa nova, tem que mexer em alguma coisa antiga. Com isso iamos implementando os testes e a arquitetura emergia.

Testes em sistema legado é complicado, se vc para para testar, vc vai achar um monte de decisões arquiteturais que já foram boas, mas não são mais. Então nem esquente com isso, a medida que vc for criando novas funcionalidades, e, se for necessário, crie os testes para o código legado.

Em relação ao tempo de desenvolvimento, ai vai depender de um monte de coisas, e como vc mesmo disse, não tem receita de bolo.

Em 14 de janeiro de 2018 00:44, Márcio Albuquerque <marcio.lima.albuquerque@gmail.com> escreveu:

Felix, relaxa um pouco... Sempre é bom ter um sistema com tudo em cima, com todo no lugar, mas as  vezes não tem jeito!! Eu sempre sigo a seguinte regra: achou um bug, escreve um teste! Com isso, vou aumentando a cobertura de sistemas legados.

A meu ver, vc usa se cobrando demais. Mas isso é bom... Até certo limite! :D

--
PHPBA
---
Você está recebendo esta mensagem porque se inscreveu no grupo "PHPBA" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para phpba+unsubscribe@googlegroups.com.

Para obter mais opções, acesse https://groups.google.com/d/optout.

--

Paulo de Almeida

Linux User #494076
Ubuntu User # 28289

"In a world without walls who needs windows and gates?"

--
PHPBA
---
Você recebeu essa mensagem porque está inscrito no grupo "PHPBA" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para phpba+unsubscribe@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

--
PHPBA
---
Você recebeu essa mensagem porque está inscrito no grupo "PHPBA" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para phpba+unsubscribe@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

--

Atenciosamente,

Felix Costa

Software Developer
Site: https://fxcosta.github.io

GitHub: https://github.com/fxcosta

--
PHPBA
---
Você recebeu essa mensagem porque está inscrito no grupo "PHPBA" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para phpba+unsubscribe@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

--

Marcio Albuquerque
==================
Analista de Infra SERPRO
Celular - 071 98880 4994

--
PHPBA
---
Você recebeu essa mensagem porque está inscrito no grupo "PHPBA" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para phpba+unsubscribe@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

--
PHPBA
---
Você recebeu essa mensagem porque está inscrito no grupo "PHPBA" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para phpba+unsubscribe@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

--

Marcio Albuquerque
==================
Analista de Infra SERPRO
Celular - 071 98880 4994

--
PHPBA
---
Você recebeu essa mensagem porque está inscrito no grupo "PHPBA" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para phpba+unsubscribe@googlegroups.com.

[Edy]

O Isolamento da sua camada de aplicação da camada de framework é algo que o expressive nos dar com muita facilidade. É obvio que você acaba criando muitos códigos auxiliares, como fabricas e interfaces, mas no contexto geral o ganho é muito maior. Como Vinão falou, hoje para migrarmos de Expressive para Symfony 4 seria um copiar e colar, e depois só configurar dentro do Symfony.

Essa questão me lembra muito quando falamos que, você deve sempre se preparar para trocar uma tecnologia. Tipo, trocar de Mysql para Postgress, e vem um cabra e pergunta, "Quantas vezes na sua vida você já fez isso". O problema de software legado muitas vezes está associado a esse pensamento. Esteja preparado para tudo. Troca de ORM ou até o Framework.

@Marcio irmão.... Olaria e Micro Serviço parece irmãos gêmeos. Rrsrsrsrssr

Em qua, 17 de jan de 2018 às 15:18, Vinicius Cruz <vina...@gmail.com> escreveu:

Pegando gancho do que Márcio falou, considero importante nesse cenário ter um código portátil, onde aquele que a regra de seu negócio não dependa nem de framework. Obviamente, algumas camadas terá dependência, tal como repository (ainda mais com active record). Por isso gosto muito do PSR-7, ele permite definir as interfaces e alinhar a compatibilidade entre fw.

Exemplificando com o que vc conhece (em off kkk): vc passa um, dois anos desenvolvendo um projeto em silex. Aí, pouco antes de publicar, lançam o symfony 4 e mataram o silex. E aí? Já é código legado, pra reescrever todo?

Hj eu tenho uma app em zend, eu posso portar ele pra o slim, por exemplo, sem muito esforço. Mas ainda assim, por mais hypes e barulho que a comunidade faça por um novo fw que lançou, é preciso ter cautela.

Att,
Vinicius Cruz

2018-01-17 10:11 GMT-03:00 Márcio Albuquerque <marcio.lima...@gmail.com>:

Verdade... Padrões junto com micro serviços da pra melhorar sempre. Mas vcs da Olaria sabem disso    :D

Em qua, 17 de jan de 2018 09:48, Edy <edy...@gmail.com> escreveu:

Uma forma que vejo para não prever o futuro é uma boa aplicação dos padrões de projeto. Bem aplicado permite uma evolução natural do seu projeto para que mais para frente não seja o legado bizarro.

Em 17 de jan de 2018 09:16, "Márcio Albuquerque" <marcio.lima...@gmail.com> escreveu:

Se for ficar de preocupando em fazer coisas pensando no futuro, vai pirar, cara!! E isso quebra um pouco até os conceitos do ágil... Além disso, imagine o cara trabalhando em sua arquitetura há uns 4 anos atrás, pensando em infraestrutura física ou mesmo VM. De repente, aparece Docker... Ele vai parar todo e redirecionar pra docker? Ou apareceu uma linguagem melhor, vai apagar todo e fazer na nova?

É bom estar antenado, saber que existem conceitos interessantes. Mas se escolheu um caminho, tente não se desviar muito dele. Por isso gosto de micro serviços. Só mesmo jeito que frameworks usam baixo acoplamento, acho que micro serviços permite um baixo acoplamento a nível de ideias.

Em ter, 16 de jan de 2018 16:16, Felix Costa <fx3c...@gmail.com> escreveu:

Obrigado pelas contribuições, pessoal!

Curti bastante essa ideia do estrangulamento e realmente me parece uma forma até natural de se migrar as coisas e aí pode ficar algo realmente parecido com uma ideia de microserviços, onde basicamente vai ter o legado e para as novas features um "contexto" novo onde faço ambos se comunicarem.... O lance é quando na verdade é uma correção ou mudança de requisito e não uma adição de feature, né?

Acho que estou convencido que começar a criar testes unitários pra essa base de código enorme legada vai ser impossível levando em conta prazos e etc. O Paulo citou uma coisa bem legal que foi: "decisões arquiteturais que já foram boas, mas não são mais". O que vocês pensam sobre o código de hoje, sim, o de hoje mesmo, virar algo legado daqui a 6 meses? Tipo, o processo de decisão de uma arquitetura hoje, quais os critérios que vocês levam em consideração para que essa decisão arquitetural se mantenha boa o suficiente ou ao menos que possa ser mudada, ou escalada, não sei. Ou como Márcio disse, eu to me preocupando demais? Haha..

Penso nessas coisas principalmente porque escrever código simplesmente resolvendo o problema de hoje pode me trazer o dobro de problema. Até que ponto vocês acham sadio pensar dessa forma?

Em seg, 15 de jan de 2018 às 15:23, Edy <edy...@gmail.com> escreveu:

E para somar.... 

Sigo parecido com a ideia de migração de um aplicação monolítica para uma aplicação em micro serviço. Nesse caso seria com duas opções. Com novas features, isolando em módulos separados e testatos, ou correção de bugs, onde também isolo em modulo separado e vou depreciando os recursos antigos. Uma coisa é certa, dificilmente a empresa vai gastar recursos migrando a aplicação 100%. Só se tiver muita grana. rsrsr

Uma dica que dou é, meta as caras e vá fazendo essa migração aos poucos. Em relação a prazo, não tem jeito meu filho, vai ter que cumprir ele e ainda testar. Assobiar e chupa cana. Caso contrário terá um sofrimento pelo resto da vida!!!

Em dom, 14 de jan de 2018 às 07:06, Paulo de Almeida <paulode...@gmail.com> escreveu:

Concordo com Márcio, mas vou deixar minha contribuição.

Se você pensa em upgrade ou mudança de tecnologia, eu recomendo estrangulamento. Já fiz isso antes migrando de .net para laravel e deu certo, toda nova funcionalidade que era implementada, era em laravel e aos poucos fomos migrando, pois quando se cria uma coisa nova, tem que mexer em alguma coisa antiga. Com isso iamos implementando os testes e a arquitetura emergia.

Testes em sistema legado é complicado, se vc para para testar, vc vai achar um monte de decisões arquiteturais que já foram boas, mas não são mais. Então nem esquente com isso, a medida que vc for criando novas funcionalidades, e, se for necessário, crie os testes para o código legado.

Em relação ao tempo de desenvolvimento, ai vai depender de um monte de coisas, e como vc mesmo disse, não tem receita de bolo.

Em 14 de janeiro de 2018 00:44, Márcio Albuquerque <marcio.lima...@gmail.com> escreveu:

Felix, relaxa um pouco... Sempre é bom ter um sistema com tudo em cima, com todo no lugar, mas as  vezes não tem jeito!! Eu sempre sigo a seguinte regra: achou um bug, escreve um teste! Com isso, vou aumentando a cobertura de sistemas legados.

A meu ver, vc usa se cobrando demais. Mas isso é bom... Até certo limite! :D

--
PHPBA
---
Você está recebendo esta mensagem porque se inscreveu no grupo "PHPBA" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para phpba+un...@googlegroups.com.

Para obter mais opções, acesse https://groups.google.com/d/optout.

--

Paulo de Almeida

Linux User #494076
Ubuntu User # 28289

"In a world without walls who needs windows and gates?"

--
PHPBA
---
Você recebeu essa mensagem porque está inscrito no grupo "PHPBA" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para phpba+un...@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

--
PHPBA
---
Você recebeu essa mensagem porque está inscrito no grupo "PHPBA" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para phpba+un...@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

--

Atenciosamente,

Felix Costa

Software Developer
Site: https://fxcosta.github.io

GitHub: https://github.com/fxcosta

--
PHPBA
---
Você recebeu essa mensagem porque está inscrito no grupo "PHPBA" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para phpba+un...@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

--

Marcio Albuquerque
==================
Analista de Infra SERPRO
Celular - 071 98880 4994

--
PHPBA
---
Você recebeu essa mensagem porque está inscrito no grupo "PHPBA" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para phpba+un...@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

--
PHPBA
---
Você recebeu essa mensagem porque está inscrito no grupo "PHPBA" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para phpba+un...@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

--

Marcio Albuquerque
==================
Analista de Infra SERPRO
Celular - 071 98880 4994

--
PHPBA
---
Você recebeu essa mensagem porque está inscrito no grupo "PHPBA" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para phpba+un...@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

--
PHPBA
---
Você recebeu essa mensagem porque está inscrito no grupo "PHPBA" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para phpba+un...@googlegroups.com.

[Helder Santana]

Meus 2 gramas de contribuiçao...

Como já foi dito tem várias maneiras de ir melhorando seu code base pra manter o mínimo de qualidade no seu projeto.

Recpatular o que foi dito e adicionar mais algumas informaçoes...

### Aumentando a cobertura de testes do código

1) Achou bug, escreve um caso de teste

2) Adicionou um classe nova, escreve caso(s) de teste(s) pra ela

3) Nao dá pra isolar e fazer teste unitario, tenta funcional (behat, codeception)

4) Ainda assim é dificil, duplica seu banco e tenha um banco onde vc pode rodar seus testes (trunca, rodar as fixtures e depois seu teste

### Migrando seu projeto

1) Isola seu dominio (ele é o que importa no final das contas)

2) Vai migrar de framework/linguagem?

  2.1) https://www.martinfowler.com/bliki/StranglerApplication.html

  2.2) https://martinfowler.com/bliki/ParallelChange.html

  2.3) https://martinfowler.com/articles/evodb.html

Exemplo de design parttern pra quem tá migrando aplicaçao. Quer ver algo um pouco mais prático, https://speakerdeck.com/sgrodzicki/from-legacy-to-symfony-at-symfonycon-cluj-2017

Usando symfony como exemplo, mas vocé pode aplicar a tecnica com qualquer framework.

Pra finalizar, cuidado com o "micro" (nao micro-service, nao estou falando de arquitetura). Já fui fan de micro-framework, hoje sou racional :D
Micro-frameworks nao sao sinonimos de peformance, normalmente vocé precisa escrever grande quantidade de código para agregar tudo que voce

precisa e garanto pra voce, que ao menos que peformance seja um requisito do seu produto, nao escreve código peformático no dia a dia (até porque

poucas pessoas sabem como faze-lo). Com isso, frameworks como Symfony tachado de "pesado", peforman muito, mas muito melhor que nosso mediocre código.

O mesmo em relaçao as dependencias, uma vez que micro-frameworks nao sao feature rich, voce acaba adicionando um monte de dependencias na sua aplicaçao.

Enfim, escolha seu framework de acordo com o tamanho do seu problema.

Desculpem a falta de acentos, ainda nao sei como por em teclados nao ABNT rsrsrs

Espero ter ajudado.

Em 18 de janeiro de 2018 13:59, Edy <edy...@gmail.com> escreveu:

O Isolamento da sua camada de aplicação da camada de framework é algo que o expressive nos dar com muita facilidade. É obvio que você acaba criando muitos códigos auxiliares, como fabricas e interfaces, mas no contexto geral o ganho é muito maior. Como Vinão falou, hoje para migrarmos de Expressive para Symfony 4 seria um copiar e colar, e depois só configurar dentro do Symfony.

Essa questão me lembra muito quando falamos que, você deve sempre se preparar para trocar uma tecnologia. Tipo, trocar de Mysql para Postgress, e vem um cabra e pergunta, "Quantas vezes na sua vida você já fez isso". O problema de software legado muitas vezes está associado a esse pensamento. Esteja preparado para tudo. Troca de ORM ou até o Framework.

@Marcio irmão.... Olaria e Micro Serviço parece irmãos gêmeos. Rrsrsrsrssr

Em qua, 17 de jan de 2018 às 15:18, Vinicius Cruz <vina...@gmail.com> escreveu:

Pegando gancho do que Márcio falou, considero importante nesse cenário ter um código portátil, onde aquele que a regra de seu negócio não dependa nem de framework. Obviamente, algumas camadas terá dependência, tal como repository (ainda mais com active record). Por isso gosto muito do PSR-7, ele permite definir as interfaces e alinhar a compatibilidade entre fw.

Exemplificando com o que vc conhece (em off kkk): vc passa um, dois anos desenvolvendo um projeto em silex. Aí, pouco antes de publicar, lançam o symfony 4 e mataram o silex. E aí? Já é código legado, pra reescrever todo?

Hj eu tenho uma app em zend, eu posso portar ele pra o slim, por exemplo, sem muito esforço. Mas ainda assim, por mais hypes e barulho que a comunidade faça por um novo fw que lançou, é preciso ter cautela.

Att,
Vinicius Cruz

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para phpba+unsubscribe@googlegroups.com.

Para obter mais opções, acesse https://groups.google.com/d/optout.

--

Paulo de Almeida

Linux User #494076
Ubuntu User # 28289

"In a world without walls who needs windows and gates?"

--
PHPBA
---
Você recebeu essa mensagem porque está inscrito no grupo "PHPBA" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para phpba+unsubscribe@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

--
PHPBA
---
Você recebeu essa mensagem porque está inscrito no grupo "PHPBA" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para phpba+unsubscribe@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

--

Atenciosamente,

Felix Costa

Software Developer
Site: https://fxcosta.github.io

GitHub: https://github.com/fxcosta

--
PHPBA
---
Você recebeu essa mensagem porque está inscrito no grupo "PHPBA" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para phpba+unsubscribe@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

--

Marcio Albuquerque
==================
Analista de Infra SERPRO
Celular - 071 98880 4994

--
PHPBA
---
Você recebeu essa mensagem porque está inscrito no grupo "PHPBA" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para phpba+unsubscribe@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

--
PHPBA
---
Você recebeu essa mensagem porque está inscrito no grupo "PHPBA" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para phpba+unsubscribe@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

--

Marcio Albuquerque
==================
Analista de Infra SERPRO
Celular - 071 98880 4994

--
PHPBA
---
Você recebeu essa mensagem porque está inscrito no grupo "PHPBA" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para phpba+unsubscribe@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

--
PHPBA
---
Você recebeu essa mensagem porque está inscrito no grupo "PHPBA" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para phpba+unsubscribe@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

--
PHPBA
---
Você recebeu essa mensagem porque está inscrito no grupo "PHPBA" dos Grupos do Google.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para phpba+unsubscribe@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

--

Helder Santana - http://www.heldersantana.net
Graduando em Ciência da Computação - UFBA - http://www.dcc.ufba.br
Linux Registered User #429933