Latest / Entre Chaves / Por que código é reflexo da especificação

Transcript

Por que código é reflexo da especificação · Entre Chaves

• 0:02
  E no final das contas, a gente não chegou ainda em uma
• 0:05
  consolidação em conceito como engenharia de software do que
• 0:09
  que é uma boa especificação, dado que eu não sei o que que é
• 0:12
  uma boa especificação, é difícil demais.
• 0:15
  De eu chegar e produzir um bom código, porque o fato é o
• 0:18
  código, ele é determinístico o código eu posso achar, eu posso
• 0:22
  achar o que eu quiser, mas se eu fizer um if e a Rafa eu fizer um
• 0:24
  if, a gente provavelmente vai fazer Oo mesmo.
• 0:27
  If se a gente está resolvendo o mesmo problema.
• 0:28
  Agora, se eu estou escrevendo uma especificação, ela está
• 0:31
  escrevendo uma especificação para o mesmo objetivo.
• 0:33
  A gente pode escrever de milhões de formas diferentes.
• 0:37
  Eu acho que o ponto seria a ambiguidade, né?
• 0:39
  Eu acho que talvez a ambiguidade seria uma boa métrica.
• 0:42
  Para. Exatamente, mas ainda subjetivo.
• 0:45
  Ô, Fernandinha, mas você trouxe um bom ponto, você está falando
• 0:47
  sobre, né? Que se você escrever uma
• 0:49
  especificação e a Rafa escrever uma, as especificações vão ser
• 0:52
  diferentes, beleza. Se vocês escreverem um hífen,
• 0:55
  vai ser igual. Mas se vocês escreverem um
• 0:57
  software inteiro, ele pode gerar o mesmo resultado.
• 1:00
  Mas o software vai ser diferente?
• 1:01
  Não. Não tem uma forma única de de
• 1:04
  desenvolver software, e isso talvez, né?
• 1:06
  Contribui pra pra geração de resultados tão diversos pela
• 1:10
  pelas, pelas ias, porque elas elas são treinadas, né?
• 1:13
  Os bilhões de parâmetros que forem foram usados lá no
• 1:16
  treinamento dela. Tem formas diferentes de fazer
• 1:19
  AA coisa também. Então ela já tem uma
• 1:21
  característica não determinista ali.
• 1:22
  Isso eu acho que amplifica ainda mais essas.
• 1:25
  Essas diferenças, essas nuances que vão que vão existir.
• 1:28
  Mas o meu ponto é assim, é que se a gente conseguisse, né?
• 1:31
  Se a gente conseguisse estabelecer com muita certeza,
• 1:34
  com muita objetividade, uma boa especificação e ter certeza que
• 1:38
  essa boa especificação ela produz um bom código, pronto.
• 1:41
  Aí meu desafio tá quase que resolvido, né?
• 1:44
  Por mais que assim às vezes eu vou, eu vou.
• 1:46
  Se eu rodar aquela especificação 15 vezes, eu vou produzir 15
• 1:49
  códigos diferentes por causa dessa, de tudo isso que a gente
• 1:52
  tá falando, nunca vai ser um pra um.
• 1:54
  Mas se eu tiver certeza que uma boa especificação cria um bom
• 1:58
  código, tá ótimo, né? Mas não é isso que a gente tem
• 2:01
  hoje, por isso que a gente precisa.
• 2:02
  Ficar revisando, por isso que a gente precisa, né?
• 2:04
  Ter todos os cuidados. A gente precisa não só revisar
• 2:07
  especificação, a gente vai vai precisar pra sempre, né?
• 2:10
  Pensando que o sdd vai ser a metodologia que a gente vai
• 2:13
  seguir, né? Revisar código pode ser que no
• 2:15
  limite a gente não precise mais, mas hoje a gente precisa porque
• 2:18
  afinal, né, enfim, somos responsáveis e a gente ainda não
• 2:21
  confia. É e, né?
• 2:22
  No No ponto que você falou? Das evoluções do dos framux
• 2:26
  voltados para que eu gere cada vez mais uma uma especificação
• 2:29
  que produza bom código, né? Eu acrescentaria, né?
• 2:32
  Que reduza as as alucinações, né?
• 2:35
  Minimize esse efeito do do do não determinismo da IA pra gente
• 2:38
  chegar justamente nesse ponto que você falou de Ah, eu tenho a
• 2:41
  consciência aqui. Eu tenho a confiança que se eu
• 2:44
  passar uma boa especificação para IAO código gerado vai ser é
• 2:49
  confiável. Eu não preciso me preocupar em.
• 2:51
  Tanto com a revisão dele, eu acho que isso é uma realidade,
• 2:54
  talvez um pouco. Distante é, acho que essa ainda
• 2:56
  vai ser bem distante. Tem 11.
• 2:58
  Detalhe que vai bem nessa vertente da do código que vai
• 3:01
  ser gerado a partir da da especificação, que é a primeira
• 3:04
  etapa de especificação dele, né? Na maioria dos dos frams que a
• 3:08
  gente tem hoje para para para a espec drib a primeira etapa, ela
• 3:12
  é muito focada na parte funcional da especificação, né?
• 3:15
  Então é é criada de uma forma AAO artefato é criado de uma
• 3:19
  forma. Que eu poderia definir EEO ideal
• 3:23
  é que seja assim. A tecnologia é só depois que já
• 3:25
  tiver especificado. Então eu não estou focando em
• 3:27
  tecnologia, não estou focando em como que isso vai ser feito, em
• 3:31
  qual linguagem que vai ser feito.
• 3:33
  Eu estou focando em especificar o que eu quero, né?
• 3:36
  Que é aquela ideia que a gente tinha de bhavle.
• 3:38
  Então assim é focar na intenção e a IA consegue criar essa
• 3:42
  especificação que vai poder ser usada.
• 3:45
  Em qualquer tecnologia, você vai poder migrar isso depois muito
• 3:49
  facilmente, então isso fica com uma documentação muito viva e
• 3:53
  fácil de utilizar de várias formas.
• 3:55
  E aí o desenvolvedor, né? Assim é a carga cognitiva dele.
• 4:00
  Vai muito mais pra esse lado, né?
• 4:01
  Da intenção do software, né? Do que o software tem que fazer,
• 4:05
  de qual é o comportamento dele. Do que pro como, de qual
• 4:08
  linguagem ou de qual arquitetura, ou de como no
• 4:12
  detalhe resolver aquele problema de negócio, né?
• 4:14
  Então a gente fica muito mais sendo essa ponte, né?
• 4:18
  Do negócio, que eu acho que é um negócio que a gente sempre teve
• 4:22
  dificuldade na ti, né, que é aproximar o negócio, né, do
• 4:27
  software, né, da tecnologia, como que a gente diminui essa
• 4:30
  distância, né, entre quem conhece a intenção e quem produz
• 4:34
  o código, né? A gente começa a tentar fazer
• 4:38
  com que essas coisas aproximem mais, né?
• 4:40
  E assim, e a gente se torne talvez como desenvolvedores,
• 4:44
  muito mais essa ponte, né? Entre negócio e tecnologia do
• 4:47
  que a gente era antes até, né?