On 1/18/16 10:10 AM, Flávio Alves Granato wrote: > On 15-01-2016 22:21, iannsp wrote: >> Implementado no SGDB ou fora dele o custo é dado pela resistencia a >> mudanças que a arquitetura utilizada define. > Pode explicar melhor este conceito? Ficou muito vago. O que manda na capacidade de um software em ser alterado no ritmo que a equipe de negócios precisa mudar é o quanto a arquitetura é capaz de suportar mudanças nesses pontos. Uma arquitetura desenvolvida por alguém que desconhece uma área de negócios normalmente falha em suportar esses hubs de mudança e ai surge o cenário em que o desenvolvedor luta com o software legado para encaixar as mudanças. Isso é oq ue chamo taxa de resistencia a mudança em uma arquitetura de software.
> >> No caso do sgdb, principalmente o postgresql que suporta tipagem dos >> parametros, sobrecarga de metodos, multiplas linguagens de programação e >> níveis de segurança(acesso ao O.S.) creio que a resistencia da >> arquitetura é baixa portanto que desenvolvido por um profissional que >> saiba o que é arquitetura de software, entenda do nicho em que o >> software que esta escrevendo esta inserindo e pratique simplicidade sem >> simplismo. > "Creio", "simplicidade" e "simplismo" são palavras que levam a um > entendimento muito subjetivo e apoiado na experiência pessoal de cada > um. Entender de nicho não deve ser levado em consideração, mas como um > adicional pois se contrato um desenvolvedor/DBA eu espero que ele faça > muito bem é sistemas e que as regras de nicho fiquem muito bem entendida > pelo negócio, aliás é um dos princípios do SOA ( já falaram por ae que > SOA não é sistema nem procotolo? ). Pois bem, com todo o respeito: discordo completamente. Levar o profissional técnico conhecer de técnica sem conhecer o contexto é contra o que acredito. DDD e lean, conceitos que uso no desenvolvimento de sistemas, se referem a isso. Sim, as palavras creio, simplicidade e simplismo são de aplicação pessoal, mas não são de meu uso exclusivo e tampouco são subjetivas. > > No fundo não respondeu à minha pergunta. entendo. >> Uma lista em ptbr sobre o melhor e mais fodastico banco de dados open >> source do mundo. > Concordo contigo, uso ele há mais de 15 anos, mais firme em minha > memória tenho a versão 7.3 que não me lembro quando foi lançada. puxa. >> E SÓ VOCE é 110% do tempo desenvolvedor, eu mesmo sou 99% desenvolvedor, >> mas com aquele 1%... > não entendi. As vezes tenho dificuldades para entender o sacarmos. entendo. >> Testes de aceitação são a exposição de um problema. Pense lean. > Pensar "lean" seria desenvolver sem testes e principalmente sem permitir > aos donos do negócio ter controle sobre as regras e não deveríamos expor > este problema? Como você responde subjetivamente, me permite endenter > subjetivamente. >> >> O melhor software que você já escreveu para um cliente é aquele que você >> não precisou escrever pq entendeu o problema e resolveu sem uma linha de >> código. > Não entendi, se na primeira resposta você me diz que o arquiteto tem que > entender do nicho para poder ser um bom profissional. Estranho virou um > paradoxo. é necessario entender de negócio para resolver um problema sem programar. >> Se você quer resolver o problema do seu cliente você deveria repensar o >> seu 110%. > talvez. >> "quem trabalha com banco de dados" soou preconceituoso. > Como se os teus 110% não tivesse sido. Mera formalidade de uma discussão > acalorada não leve a mal. >> "Empresas grandes ou pequenas", não importa: Se elas tiverem >> programadores dedicados 110% a programar elas terão os mesmos problemas. > Como mudar esta realidade? Parar de acreditar que todo problema exige código em sua solução e que programar mais resolve mais problemas. É a famosa parabola do velho lenhador, aqui tem um video para ilustrar melhor: https://www.youtube.com/watch?v=RGHs8zgZMh0 >> "Mercado brasileiro": tem mais gente nessa lista com experiencia >> internacional do que você imagina e quanto mais cenarios você conhece >> melhor habilitado para analisar o proximo cenario você estará. > Sim, conheço alguns. Já preambulo por esta lista há uns 12 anos. Não é > de hoje que vejo a discussão de onde ficar as regras de negócio e não é > a primeira vez que entro nela. Só ler o histórico da lista. ;-) > > A diferença que hoje não acho que deva ficar em lugar algo, ou melhor > dizendo que é melhor estar em algum lugar porque X ou Y disse, como você > comentou o pragmatismo do movimento Lean leva a se adaptar o tempo todo. > Na minha concepção o modelo relacional, mesmo que ainda claudicante no > PostgreSQL e isso não o desmerece pois os outros bancos de dados são > pernetas mesmo, é a melhor saída para manter a unicidade dos dados, mas > tem outras respostas que preciso dar quando falamos de sistemas para > clientes finais, como em uma tela de formulário de cadastro por exemplo > de um paciênte médico em que eu tenha que colher muitas informações > sobre a saúde dele e até dados pessoais ( poiseh as vezes que imaginou o > formulário pecou no design da informação ), o retorno para a tela como > seria? Dar raise campo a campo não parece ser uma opção muito otimizada > e "eu" não a escolheria. > Entendo a sua questão: Suportar uma modelagem de um problema que esta em constante evolução é um desafio comum para um DBA e para um desenvolvedor, mas isso não tem a ver com regras de negócio mas sim com modelagem e suportar uma modelagem assim pode ser algo simples no postgreSQL, principalmente se você utilizar um campo json ou jsonb. Agora, se você quiser modelar o problema de maneira relacional basta suportar as entidades em separado e modelar tabelas para cada uma delas e permitir relacionamentos 1->N. Claudicante é tudo que o modelo relacional não é nem no PostgreSQL nem nos outros bancos de dados relacionais ou objeto relacionais. >> >> "as coisas mudam rapidamente": Ué, modele as mudanças. Se os dados não >> fossem considerados mutaveis talvez a profissão de DBA nem existisse. > Fiz várias perguntas e agora que consegue me dar alguma resposta mais > assertiva? E aliás, só peguei o teu email como exemplo e não foi > direcionado a você a não ser as 2 ou 3 primeiras linhas. >> "temos que acompanhar, o sistema inteiro". Não confunda praticas ruins >> de programação com programar. > É prática comum em algumas instituições religiosas a pinçagem de > palavras ou parte de frases para poder se apoiar e atacar, se conseguir > ser mais assertivo nas tuas respostas ia ajudar bastante nas discussões. > Não tem como ser mais assertivo por que a asserção esta no kit de conhecimento que você usa para a interpretação. > Senhores já que fomos advertidos, não respondo(do verbo fazer ou > retrucar) mais emails que tenham tom emocional e direto, há não ser que > já conheça a pessoa e saiba que ela reagira bem há uma crítica. Para > evitarmos os flames mesmo... :-) Não considerei nossa troca de emails como um flame. Você não me ofendeu, eu não te ofendi. Surgiram aqui e acolá algumas coisas boas nessa troca de email. > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
