Conselhos de um velho programador antissocial e ranzinza

Assuntos Gerais
#21

[quote=Impossivel][quote=adriano_si]
Achei sua definição perfeita… Nem é pra se focar só nisso, nem pra esquecer de vez. Por isso dá pra entender a preocupação do Yvga, pois se preocupar com manutenção de baixo custo e fácil escalabilidade é também pensar no seu cliente.[/quote]

Falando como se todo software fosse precisar escalar e sofrer manutenção constante…
[/quote]

Vc inclui o software pra pizzaria ou boteco do vizinho neste ‘todo’? Porque se sim, está correto, pois o software é muito simples e pequeno. Não compensaria investir tempo em arquitetar algo que vai ficar na mesma sempre. Mas em se tratado de softwares mais robustos, pensar em escalabilidade e manutenção de baixo custo é certíssimo. Um desenvolvedor Jr. (uns 3 anos de experiência no máximo) é capaz de determinar o contexto em que se encontra.
Mesmo falando de jogos, se tivermos falando de bubble witch (comparável a pizzaria ou boteco) ou War Thunder (toda semana recebo pelo menos uma atualização). i.e. vale a regra acima.
O cliente realmente não tá nem ai pro pattern que será utilizado pra desenvolver seu produto, mas existirem técnicas boas à serem escolhidas pra se fazer qualquer coisa e bem feita.
Em vários casos, quando o analista pega o programa pra desenvolver e entende o que deve ser executado, seu conhecimento, se bem propagado dentro da empresa, pode trazer melhora até para os processos internos dentro da empresa. e.g. quem trabalha com workflow, certamente já deve ter sentindo falta de algum processo ou encontrado algo desnecessário em alguma sequencia de eventos. Algo que quando informado dentro da empresa certamente traz valor.
Supondo que seja um desenvolvedor com experiência de pelo menos 5 ou 6 anos à desenvolver um software, creio que ele já deva conhecer os instrumentos e tecnicas basicas de desenvolvimento de softwares ao ponto de desenvolver com boa qualidade. Neste caso, para um software agregar valor, na maioria das vezes depende da idéia do cliente. Raramente o desenvolvedor é culpado do software não agregar valor. Desconsiderando os insumos da produção, a culpa de um software não agregar valor só é do desenvolvedor quando a usabilidade do software se torna muito complexa, não otimizada (lenta) ou pouco instintiva. Realmente, se a manutenção não melhorar a usabilidade ou corrigir bugs, pra que falar de ‘agregar valor’?

#22

Bom, você estava falando de desenvolver produto e de repente me diz que os produtos que você desenvolve não escalam e não sofrem manutenção constante?

Então realmente não temos o que discutir aqui.

Por isso trabalhamos em equipes. Existem pessoas para os 2 papéis que são de extrema importância. Mesmo uma Startup que nasceu em um concurso de universidade e foi campeã com sua ideia inovadora, terá muita dificuldade de crescer somente com aquele único desenvolvedor RoR que teve a ideia. COm o tempo ele terá que crescer e trazer pessoas (tanto as que focam no produto, quanto as que focam do desenvolvimento).

Claro que o cenário do autor é pra freelancer, e aí olha que engraçado, já estamos falando 90% em manutenção. Não? É pra desenvolver um produto freelancer? E esse produto não vai crescer e escalar??? Sei não hein.

Eu lhe respondi a um Quote anterior, então sim, disse pra você… Talvez se reler pode ver que posso estar reforçando ou completando sua frase.

Confirmando minha opinião = Javaflex: Nem 8, nem 80. Se essa também é a sua opinião, estamos concordando.

Só pra ficar claro, trabalho e sempre trabalhei com Softwares que vivem em manutenção constante, quer por mudanças de mercado, quer sejam por leis. Até mesmo quando trabalhei com Sistema de Escola de Caixinha, ele ficava em constante manutenção tendo em vista novas necessidades do cliente, portanto, eu realmente fico totalmente VOANDO quando o assunto é Sistema que não escala, não evolui e não muda.

Abs []

#23

[quote=Luiz Augusto Prado]
Vc inclui o software pra pizzaria ou boteco do vizinho neste ‘todo’? Porque se sim, está correto, pois o software é muito simples e pequeno. Não compensaria investir tempo em arquitetar algo que vai ficar na mesma sempre. Mas em se tratado de softwares mais robustos, pensar em escalabilidade e manutenção de baixo custo é certíssimo. Um desenvolvedor Jr. (uns 3 anos de experiência no máximo) é capaz de determinar o contexto em que se encontra.
Mesmo falando de jogos, se tivermos falando de bubble witch (comparável a pizzaria ou boteco) ou War Thunder (toda semana recebo pelo menos uma atualização). i.e. vale a regra acima. [/quote]

Pizzarias e botecos ainda usam software!!! Achei que estavam usando facebook…

sabe, aquele site feito por um programador PHP e nenhum padrão GoF?

[quote=Luiz Augusto Prado]
O cliente realmente não tá nem ai pro pattern que será utilizado pra desenvolver seu produto, mas existirem técnicas boas à serem escolhidas pra se fazer qualquer coisa e bem feita. [/quote]

Concordo. Mas o que está sendo dito é que o desenvolvedor não esta nem ai pro produto que está sendo desenvolvido porque ele acha que pode fazer a coisa bem feita apenas focando nas técnicas e frameworks que existem. Disso não estou convencido.

Sinceramente parece mais uma desculpa conveniente pra quem é anti-social continuar isolado e não ter que interagir com outras pessoas!!

[quote=Luiz Augusto Prado]
Em vários casos, quando o analista pega o programa pra desenvolver e entende o que deve ser executado, seu conhecimento, se bem propagado dentro da empresa, pode trazer melhora até para os processos internos dentro da empresa. e.g. quem trabalha com workflow, certamente já deve ter sentindo falta de algum processo ou encontrado algo desnecessário em alguma sequencia de eventos. Algo que quando informado dentro da empresa certamente traz valor.
Supondo que seja um desenvolvedor com experiência de pelo menos 5 ou 6 anos à desenvolver um software, creio que ele já deva conhecer os instrumentos e tecnicas basicas de desenvolvimento de softwares ao ponto de desenvolver com boa qualidade. Neste caso, para um software agregar valor, na maioria das vezes depende da idéia do cliente. Raramente o desenvolvedor é culpado do software não agregar valor. Desconsiderando os insumos da produção, a culpa de um software não agregar valor só é do desenvolvedor quando a usabilidade do software se torna muito complexa, não otimizada (lenta) ou pouco instintiva. Realmente, se a manutenção não melhorar a usabilidade ou corrigir bugs, pra que falar de ‘agregar valor’? [/quote]

Resumindo, não tenho a mínima idéia do que estou falando.

#24

Ache um trecho sequer onde alguém disse isso. Mas QUOTE o trecho.

#25

https://www.google.com.br/?gws_rd=ssl#q=site:guj.com.br+melhor+framework

#26

Bom… Acho que ficou claro. Com essa eu me retiro… Bom texto do cara, eu particularmente gostei e boa colocação do Yvga.

Abs []

#27

[quote=adriano_si]
Por isso trabalhamos em equipes. Existem pessoas para os 2 papéis que são de extrema importância. Mesmo uma Startup que nasceu em um concurso de universidade e foi campeã com sua ideia inovadora, terá muita dificuldade de crescer somente com aquele único desenvolvedor RoR que teve a ideia. COm o tempo ele terá que crescer e trazer pessoas (tanto as que focam no produto, quanto as que focam do desenvolvimento).

Claro que o cenário do autor é pra freelancer, e aí olha que engraçado, já estamos falando 90% em manutenção. Não? É pra desenvolver um produto freelancer? E esse produto não vai crescer e escalar??? Sei não hein.

Abs [][/quote]

A importância do papel depende da facilidade em substituir aquela pessoa por outra, sem causa transtornos ou atrasos significantes no projeto.

Sendo assim, podemos concluir que o papel do responsável pelo produto geralmente É muito mais importante do que quem foca apenas no desenvolvimento.

#28

[quote=adriano_si]Bom… Acho que ficou claro. Com essa eu me retiro… Bom texto do cara, eu particularmente gostei e boa colocação do Yvga.

Abs [][/quote]

Nada como um exemplo do mundo real para demonstrar o que estou dizendo né mesmo? :wink:

#29

Sério? Eu lhe peço um exemplo de onde que alguém na discussão em questão afirmou o que você disse aí em cima e você me vem com um link do Google de pessoas perguntando qual o melhor framework e tals.

Pra mim o exemplo foi de que além de não saber interpretar um texto, você não sabe discutir a um nível aceitável sequer tendo em vista que tira conclusões do que os outros dizem, sem que eles tenham dito.

Talvez haja um mundo aí só seu, onde você lê o que quer e escuta o que quer. Como seu nick diz, realmente é Impossível vencê-lo com argumentos tão sólidos dentro do seu Fantástico mundo ilusório.

Sem mais.

Até que você seja homem e ponha a sua cara a tapa (e não esse fake que nasceu na discussão do PJ), simplesmente você pra mim é troll que se esconde sobre uma máscara pra cuspir asneiras.

Abs []

#30

Quanto mais saber… melhor. Pra qualquer caso. Com isso também concordo.

É claro que a forma como o produto ou serviço oferecido deve funcionar vai refletir no software desenvolvido. A abstração do produto ou serviço deve corresponder com as abstrações do funcionamento dos softwares. O arquiteto de software é quem deve estar capacitado à fazer estas correlações e é o responsável por decidir como e o que seria melhor utilizar. Muitas vezes, quem desenvolve, não tem a visão do todo (negócio), mas é capaz de executar as tarefas que lhe foram delegadas. Por que o desgosto com isso? Isso vai ocorrer sempre porque as empresas visam economia. Então, por que contratar Analista Sênior pra fazer o trabalho de Júnior sendo que podemos alocar a concentração dos sêniores por um preço maior em gargalos mais genéricos e impactantes e alocar vários júniores por preços menores para trabalhos mais localizados e de menores riscos?
Os motivos de existir cargos como por exemplo de analista de requisitos, desenvolvedores de softwares… é para que a transferência das demandas sejam filtradas e delegadas à pessoas capacitadas da empresa (toda a engrenagem pode ser encaixada). Juniores só viram seniores com tempo de experiência. Erros vão ocorrer. Se o resultado não foi o esperado, a culpa não é das técnicas ou frameworks e sim de quem as escolheu.
Se vc passa uma tarefa para um pedreiro construir sua casa, vc iria à construção somente de 4 em 4 meses pra ver como tá ficando a obra?
Atenção deve ser constante. Não existe bala de prata.
Frameworks e até técnicas vc mesmo pode criar.

#31

talvez vc esteja se referindo a isso:

deve existir feedback pra que o sistema não deixe o funcionário como um zumbi.

#32

Sério? Eu lhe peço um exemplo de onde que alguém na discussão em questão afirmou o que você disse aí em cima e você me vem com um link do Google de pessoas perguntando qual o melhor framework e tals.

Pra mim o exemplo foi de que além de não saber interpretar um texto, você não sabe discutir a um nível aceitável sequer tendo em vista que tira conclusões do que os outros dizem, sem que eles tenham dito.

Talvez haja um mundo aí só seu, onde você lê o que quer e escuta o que quer. Como seu nick diz, realmente é Impossível vencê-lo com argumentos tão sólidos dentro do seu Fantástico mundo ilusório.

Sem mais.

Até que você seja homem e ponha a sua cara a tapa (e não esse fake que nasceu na discussão do PJ), simplesmente você pra mim é troll que se esconde sobre uma máscara pra cuspir asneiras.

Abs [][/quote]

Bom, esse é o argumento do tópico, que o programador deveria focar mais no produto.

O fato de que você precisa de ajuda pra entender quem disse o que mostra quem tem a dificuldade de entender textos aqui.

Tenha um ótimo dia.

#33

https://www.google.com.br/?gws_rd=ssl#q=site:guj.com.br+melhor+framework
[/quote]

Ninguém discute a importância do cliente ou usuário final para o sistema. Isso é tão óbvio que sequer precisa ser mencionado.

O problema é que eu já vi muito, sob a desculpa de “o usuário não tá nem aí pra qualidade de código”, muita porcaria ser escrita, ir pra produção com bug e levar semanas pra fazer alterações que poderiam ser feitas em horas.

Vale sempre a pena estudar pra saber o que melhor se encaixa para cada situação. Se um desenvolvedor não têm o discernimento do que e quando usar e tenta por uma estrutura de aplicação monstruosa para uma agenda telefônica, isso é um problema dele, e do cliente dele e essa “inexperiência” não invalida tudo que se aprendeu sobre padrões de projetos, de arquitetura e frameworks.

E outra coisa a ser lembrada é que muita gente considera que código bom só traz vantagem para dar manutenção num sistema, que antes dele ir pra produção não faz diferença. Mais uma afirmação que indica inexperiência, porque a manutenção em trechos de código já implementados, normalmente começa muito antes do sistema entrar em produção.

#34

Pra alguns sim e é sobre isso que o texto diz. Há pessoas, e não poucas que isso precisa ser mencionado.

E é pra esses a quem o texto se direciona. Trabalhei recentemente em uma ideia onde um colega queria porque queria fazer com mean stack, sendo que nem eu e nem ele tínhamos a experiência no negócio.

Depois de algumas conversas e brainstormings, cheguei em um protótipo em Java mesmo, a fim de colocar pra alguns conhecidos (potenciais usuários validarem) e ele passou uma tarde tentando me convencer o “porque” de usar mean seria melhor.

No final das contas, seguimos vertentes separadas e passado algumas semanas, ele ainda está apanhando pra fazer a POC dele enquanto as telas JSF já estão sendo criticadas e melhoradas.

Pra esse meu conhecido, esse texto será útil, pois na cabeça dele, a ferramenta e o produto ainda são 1 só. Não que não sejam, mas se o Mean vai realmente resolver o meu problema no futuro, eu primeiro preciso garantir esse meu futuro.

Por isso digo e repito, nem 8, nem 80. Poderia estar até agora fazendo estudos da melhor arquitetura ou tecnologia, mas fiz no que eu sabia e já estamos validando. Claro que esse é 1 cenário isolado e pode haver casos onde a decisão de usar o mean se encaixe melhor desde o início.

O texto é exatamente pra essa galera que não enxerga mais nada a não ser “o que vamos usar pra fazer isso?” e não pra quem já transcendeu dessa ideia.

Abs []

#35

Pra alguns sim e é sobre isso que o texto diz. Há pessoas, e não poucas que isso precisa ser mencionado.

E é pra esses a quem o texto se direciona. Trabalhei recentemente em uma ideia onde um colega queria porque queria fazer com mean stack, sendo que nem eu e nem ele tínhamos a experiência no negócio.

Depois de algumas conversas e brainstormings, cheguei em um protótipo em Java mesmo, a fim de colocar pra alguns conhecidos (potenciais usuários validarem) e ele passou uma tarde tentando me convencer o “porque” de usar mean seria melhor.

No final das contas, seguimos vertentes separadas e passado algumas semanas, ele ainda está apanhando pra fazer a POC dele enquanto as telas JSF já estão sendo criticadas e melhoradas.

Pra esse meu conhecido, esse texto será útil, pois na cabeça dele, a ferramenta e o produto ainda são 1 só. Não que não sejam, mas se o Mean vai realmente resolver o meu problema no futuro, eu primeiro preciso garantir esse meu futuro.

Por isso digo e repito, nem 8, nem 80. Poderia estar até agora fazendo estudos da melhor arquitetura ou tecnologia, mas fiz no que eu sabia e já estamos validando. Claro que esse é 1 cenário isolado e pode haver casos onde a decisão de usar o mean se encaixe melhor desde o início.

O texto é exatamente pra essa galera que não enxerga mais nada a não ser “o que vamos usar pra fazer isso?” e não pra quem já transcendeu dessa ideia.

Abs [] [/quote]

Concordo com seu comentário, o que eu queria dizer é que isso nem deveria precisar ser mencionado. Mas existem desenvolvedores que não tem realmente essa visão. O meu comentário, o primeiro, não foi contra o texto do blog, mas contra o comentário de quem postou, sugerindo que não devemos nos preocupar com padrões e frameworks e sim com somente com o usuário. Uma coisa não exclui a outra e conhecermos padrões, frameworks e qualquer outra ferramenta que nos ajude a desenvolver, assim como quando e qual usar, está diretamente ligado ao foco no usuário.

#36

Voltei! Entrei de férias e esqueci do post. :stuck_out_tongue:

[quote=YvGa]
Concordo com seu comentário, o que eu queria dizer é que isso nem deveria precisar ser mencionado. Mas existem desenvolvedores que não tem realmente essa visão. O meu comentário, o primeiro, não foi contra o texto do blog, mas contra o comentário de quem postou, sugerindo que não devemos nos preocupar com padrões e frameworks e sim com somente com o usuário. Uma coisa não exclui a outra e conhecermos padrões, frameworks e qualquer outra ferramenta que nos ajude a desenvolver, assim como quando e qual usar, está diretamente ligado ao foco no usuário.[/quote]

“Contra quem postou” você diz eu? Então acho que fui mal interpretado. Não me expressei direito.

Lógico que framework e padrões são importantes para o projeto, mas acho que muitos param de tentar melhorar o sistema quando ele está estabilizado. Não ligam para a interação do usuário com o sistema, quantos clicks você pode reduzir para ele fazer algo ou o workflow.

#37

[quote=YvGa]
O problema é que eu já vi muito, sob a desculpa de “o usuário não tá nem aí pra qualidade de código”, muita porcaria ser escrita, ir pra produção com bug e levar semanas pra fazer alterações que poderiam ser feitas em horas.[/quote]

Se você é o comandante do navio que pode afundar, culpar a tripulação não vai ajudar muito sua causa.

[quote=YvGa]
Vale sempre a pena estudar pra saber o que melhor se encaixa para cada situação. Se um desenvolvedor não têm o discernimento do que e quando usar e tenta por uma estrutura de aplicação monstruosa para uma agenda telefônica, isso é um problema dele, e do cliente dele e essa “inexperiência” não invalida tudo que se aprendeu sobre padrões de projetos, de arquitetura e frameworks.[/quote]

A questão é: se ele é um dos tripulantes do seu navio, acha que o problema é dele também?

[quote=YvGa]
E outra coisa a ser lembrada é que muita gente considera que código bom só traz vantagem para dar manutenção num sistema, que antes dele ir pra produção não faz diferença. Mais uma afirmação que indica inexperiência, porque a manutenção em trechos de código já implementados, normalmente começa muito antes do sistema entrar em produção.[/quote]

Nunca precisei dar manutenção em um sistema antes mesmo de ir entrar em produção.

Imagino que você possa ter um problema de processo se precisa fazer isso com frequência.

#38

[quote=YvGa]
Concordo com seu comentário, o que eu queria dizer é que isso nem deveria precisar ser mencionado. Mas existem desenvolvedores que não tem realmente essa visão. O meu comentário, o primeiro, não foi contra o texto do blog, mas contra o comentário de quem postou, sugerindo que não devemos nos preocupar com padrões e frameworks e sim com somente com o usuário. Uma coisa não exclui a outra e conhecermos padrões, frameworks e qualquer outra ferramenta que nos ajude a desenvolver, assim como quando e qual usar, está diretamente ligado ao foco no usuário.[/quote]

É perfeitamente natural se preocupar com o que conhece menos, e “relaxar” com o que já conhece.

Com relação a “conhecer” os padrões, frameworks e técnicas usadas no mercado de TI. Isso não está diretamente ligado a foco no usuário, mas poderia se a comunidade discutisse mais sobre isso.

#39

Não tenho “desgosto” por quem desenvolve software como se fosse uma fábrica. Nem pra quem desenvolve com foco no produto, que convenhamos, também sempre vai ocorrer porque cada vez mais desenvolvedores visam design e usuários visam economia (pergunte para as empresas que vendem software para pizzarias e botecos da esquina!).

[quote=Luiz Augusto Prado]
Então, por que contratar Analista Sênior pra fazer o trabalho de Júnior sendo que podemos alocar a concentração dos sêniores por um preço maior em gargalos mais genéricos e impactantes e alocar vários júniores por preços menores para trabalhos mais localizados e de menores riscos?
Os motivos de existir cargos como por exemplo de analista de requisitos, desenvolvedores de softwares… é para que a transferência das demandas sejam filtradas e delegadas à pessoas capacitadas da empresa (toda a engrenagem pode ser encaixada). Juniores só viram seniores com tempo de experiência. Erros vão ocorrer. Se o resultado não foi o esperado, a culpa não é das técnicas ou frameworks e sim de quem as escolheu.
Se vc passa uma tarefa para um pedreiro construir sua casa, vc iria à construção somente de 4 em 4 meses pra ver como tá ficando a obra?
Atenção deve ser constante. Não existe bala de prata.
Frameworks e até técnicas vc mesmo pode criar. [/quote]

Tu parece tão preocupado em atribuir tarefas e culpas que não percebeu que software não é cimento ou tem engrenagens.

#40

Não caro colega. Só to lhe dizendo que não dá pra focar apenas em produto e os porques de não (Claro, mesmo com a experiência que tenho não deixo de perguntar pra outros colegas, amigos e mesmo no forum). E sobre cimento e engrenagens vou negritar o que disse em um post anterior, pois vale para contexto:

[quote]É claro que a forma como o produto ou serviço oferecido deve funcionar vai refletir no software desenvolvido. A abstração do produto ou serviço deve corresponder com as abstrações do funcionamento dos softwares. O arquiteto de software é quem deve estar capacitado à fazer estas correlações e é o responsável por decidir como e o que seria melhor utilizar.[/quote] Entender os contextos…

Já vi cliente apresentar partes de software desenvolvido por mim como se fosse ele quem o tivesse feito só por ter sugerido. A idéia de um(ns) processo(s), é totamente diferente do software que vair organizar e executar tal(is) processo(s). Então, não dá pra falar em focar apenas em produto ou em apenas em tecnicas de desenvolvimento. “Parafrazeando” algo que ví sobre ITIL:
Felizmente, não é necessário saber tudo sobre ITIL para tirar benefícios, nem é preciso saber como compreender tudo para retirar valor.
E que lembra algo que li no GEB ( ver imagem ou link: niveis de descrição e computadores - selagem - selagem do conhecimento. visivel neste link da descrição da imagem)

Vc pode conseguir fazer seu software sem o uso de orientação a objeto? Pode, mas corre o risco de ter trabalho triplicado. Mas se já conhece bastante, e tem ideias inovadoras… tenta! Quem sou eu pra lhe dizer como deve delegar suas demandas? As faculdades e mentes brilhantes e fermentantes de mais de 100 milhões de desenvolvedores vão criar tecnicas inovadoras a uma taxa maior do que qualquer um possa atualizar-se.