RSS Feed
InoReader
Chaves no Festival SBT 30 Anos
O famoso garoto que mora em um barril teve sua história e de toda a sua turma contada desde o início, com direito a muitas curiosidades sobre os episódios, cenas de bastidores com o elenco e erros de gravação.
A surpresa deste programa veio pelas mãos da apresentadora Patricia Abravanel, que teve a missão de investigar o que aconteceu com os famosos "episódios perdidos". Ela investigou em todos os lugares da emissora, prováveis e improváveis, até conseguir alcançar seu objetivo.
Relembre as entrevistas que o SBT produziu com Roberto Gomez Bolaños para o "SBT Repórter" e para o "Domingo Legal", a entrevista de Édgar Vivar no "Programa do Ratinho" e a entrevista de María Antonieta de Las Nieves para o programa "Falando Francamente", em 2003.
Fale menos, codifique mais
"Só o código importa". Essa frase nem sempre disse tanto quanto diz hoje em dia. Sua simplicidade desafia a compreensão de um profissional que vivenciou e ainda vivencia projetos de software nos quais o código é apenas mais uma das coisas que podem dar errado. Em um contexto no qual passamos boa parte da graduação aprendendo a montar diagramas e no mercado em que os profissionais passam o dia montando documentos, essa frase realmente não pode fazer sentido.
Teorias e soluções são comprovadas com código
Uma coisa comum em projetos é que, ao nos depararmos com um problema, teorizamos sobre as possíveis soluções. Soluções que podem ser desde um simples design de classes até um projeto secundário que vai revolucionar o mundo. A questão é: documentos e diagramas aceitam qualquer coisa, o código, não.
Nenhuma solução é válida até que se prove sua viabilidade no código. Felizmente, na área de desenvolvimento, o custo para se criar uma prova de conceito não é alto. Podemos passar trinta minutos discutindo possíveis soluções para um problema em um quadro branco ou folha de papel e já partir para construção do seu código.
Prolongar o tempo da solução fora do código é prejudicial, pois somente o código fornece o feedback necessário para uma avaliação. Na prática, o ideal é ficar o menor tempo possível com uma solução fora do código.
O código traz resultados. Documentos, não.
Sabe o que você consegue quando gasta tempo confeccionando documentos e diagramas? Documentos, diagramas e nenhum software funcionando. Em um contexto no qual o objetivo é conseguir o software funcional rápido, tudo que não for essencial deve ser descartado ou simplificado, pois não há tempo a perder.
Software não é um fim, mas sim um meio. O objetivo do time de desenvolvimento não é desenvolver um requisito, mas sim entender a necessidade do cliente e atendê-la com uma solução de software. Apesar dos conceitos parecerem semelhantes, na prática são completamente diferentes.
Artefatos válidos são artefatos úteis. A utilidade do artefato está na informação em si, não no seu formato ou nas assinaturas de aprovação do requisito no fim da página. Reduzir o tempo de confecção de artefatos e investir em codificação é certamente uma das melhores práticas para se obter resultados rápidos.
Nenhum documento diz mais sobre o software do que seu próprio código
Uma linguagem de programação é tão útil para registrar uma informação quanto qualquer outro documento, com a vantagem de nunca ficar desatualizada.
Geralmente documentos são gerados para expressar regras de negócio que seriam difíceis de entender no próprio código, além de outras razões burocráticas. Meu ponto não é contra documentações, mas sim a favor de um código expressivo, que não necessite de artefatos externos para ser compreendido.
É claro que, até o código ser produzido, podemos precisar de documentos auxiliares para expressar as regras que devemos codificar. Porém, depois de escrito, o código passa a ser a única referência confiável sobre aquela regra. Muitas empresas acreditam que uma boa documentação irá auxiliar na passagem de conhecimento entre programadores, mas nada é tão útil quanto um código expressivo e com testes unitários que não só expressem a intenção do código, mas também garantam que o mesmo está funcionando corretamente.
É possível ter um código expressivo. Investir na qualidade do código traz mais resultados do que gastar tempo na confecção de artefatos para traduzi-lo.
O código levanta questões sobre o domínio
Construir software é expressar através de código as coisas como elas de fato acontecem, ou seja, as imperfeições e as indefinições do ambiente do cliente ficarão explicitas no momento da codificação, o que levanta a questão: o que fazer nesse momento?
A comunicação entre cliente e time de desenvolvimento não é uma via de mão única, sendo totalmente plausível existirem questionamentos sobre o processo do cliente, afinal, tudo é passível de melhoria.
O time de desenvolvimento não pode ser omisso ao encontrar deficiências no domínio. Uma coisa que não funciona na vida real também não vai funcionar no software, podendo inclusive potencializar problemas que não eram tão evidentes quando o processo era feito manualmente.
Convenções e regras de criação de código podem auxiliar na detecção de falhas em um processo.
O código mostra o nível de experiência de um profissional
Não importa quantas certificações ou quantos anos de experiência um profissional tenha. O código que ele produz é a uma das maiores evidências de sua competência.
Alguns minutos de codificação ao lado de um profissional dizem muito sobre ele. Essa percepção foi a grande responsável por introduzir técnicas como Pair Programming e Coding Dojos em processos de seleção.
Conclusão
Em um cenário em que a entrega de software funcionando é o maior objetivo, o código se torna o bem mais precioso do projeto. O código é capaz de provar teorias, mostrar a experiência de um profissional, documentar uma regra e ainda trazer propostas de melhoria para o ambiente no qual será inserido.
iMasters
Teorias e soluções são comprovadas com código
Uma coisa comum em projetos é que, ao nos depararmos com um problema, teorizamos sobre as possíveis soluções. Soluções que podem ser desde um simples design de classes até um projeto secundário que vai revolucionar o mundo. A questão é: documentos e diagramas aceitam qualquer coisa, o código, não.
Nenhuma solução é válida até que se prove sua viabilidade no código. Felizmente, na área de desenvolvimento, o custo para se criar uma prova de conceito não é alto. Podemos passar trinta minutos discutindo possíveis soluções para um problema em um quadro branco ou folha de papel e já partir para construção do seu código.
Prolongar o tempo da solução fora do código é prejudicial, pois somente o código fornece o feedback necessário para uma avaliação. Na prática, o ideal é ficar o menor tempo possível com uma solução fora do código.
O código traz resultados. Documentos, não.
Sabe o que você consegue quando gasta tempo confeccionando documentos e diagramas? Documentos, diagramas e nenhum software funcionando. Em um contexto no qual o objetivo é conseguir o software funcional rápido, tudo que não for essencial deve ser descartado ou simplificado, pois não há tempo a perder.
Software não é um fim, mas sim um meio. O objetivo do time de desenvolvimento não é desenvolver um requisito, mas sim entender a necessidade do cliente e atendê-la com uma solução de software. Apesar dos conceitos parecerem semelhantes, na prática são completamente diferentes.
Artefatos válidos são artefatos úteis. A utilidade do artefato está na informação em si, não no seu formato ou nas assinaturas de aprovação do requisito no fim da página. Reduzir o tempo de confecção de artefatos e investir em codificação é certamente uma das melhores práticas para se obter resultados rápidos.
Nenhum documento diz mais sobre o software do que seu próprio código
Uma linguagem de programação é tão útil para registrar uma informação quanto qualquer outro documento, com a vantagem de nunca ficar desatualizada.
Geralmente documentos são gerados para expressar regras de negócio que seriam difíceis de entender no próprio código, além de outras razões burocráticas. Meu ponto não é contra documentações, mas sim a favor de um código expressivo, que não necessite de artefatos externos para ser compreendido.
É claro que, até o código ser produzido, podemos precisar de documentos auxiliares para expressar as regras que devemos codificar. Porém, depois de escrito, o código passa a ser a única referência confiável sobre aquela regra. Muitas empresas acreditam que uma boa documentação irá auxiliar na passagem de conhecimento entre programadores, mas nada é tão útil quanto um código expressivo e com testes unitários que não só expressem a intenção do código, mas também garantam que o mesmo está funcionando corretamente.
É possível ter um código expressivo. Investir na qualidade do código traz mais resultados do que gastar tempo na confecção de artefatos para traduzi-lo.
O código levanta questões sobre o domínio
Construir software é expressar através de código as coisas como elas de fato acontecem, ou seja, as imperfeições e as indefinições do ambiente do cliente ficarão explicitas no momento da codificação, o que levanta a questão: o que fazer nesse momento?
A comunicação entre cliente e time de desenvolvimento não é uma via de mão única, sendo totalmente plausível existirem questionamentos sobre o processo do cliente, afinal, tudo é passível de melhoria.
O time de desenvolvimento não pode ser omisso ao encontrar deficiências no domínio. Uma coisa que não funciona na vida real também não vai funcionar no software, podendo inclusive potencializar problemas que não eram tão evidentes quando o processo era feito manualmente.
Convenções e regras de criação de código podem auxiliar na detecção de falhas em um processo.
O código mostra o nível de experiência de um profissional
Não importa quantas certificações ou quantos anos de experiência um profissional tenha. O código que ele produz é a uma das maiores evidências de sua competência.
Alguns minutos de codificação ao lado de um profissional dizem muito sobre ele. Essa percepção foi a grande responsável por introduzir técnicas como Pair Programming e Coding Dojos em processos de seleção.
Conclusão
Em um cenário em que a entrega de software funcionando é o maior objetivo, o código se torna o bem mais precioso do projeto. O código é capaz de provar teorias, mostrar a experiência de um profissional, documentar uma regra e ainda trazer propostas de melhoria para o ambiente no qual será inserido.
iMasters
Assinar:
Postagens (Atom)