Olá!
Faz tempo que não apareço aqui e achei interessante compartilhar com você coisas que acabo conversando formal e informalmente com amigos, colegas e clientes.
Uma das dúvidas recorrentes que ouço é: "Como você consegue programar sem enxergar?" e a resposta curta é "Igual a você!".
Poderia terminar a postagem por aqui, mas vou compartilhar um pouco mais de informações
Tecnologias Assistivas
Para utilizar o computador, o celular e até mesmo a minha TV dependo de um pedaço de software chamado leitor de telas. Ele juntamente com outros tipos de dispositivos tanto de hardware quanto de software são responsáveis por remover barreiras de acesso sejam elas físicas (cadeira de rodas, muleta, corre-mão), sensoriais (leitores de tela, ampliadores, esquema de cores com alto contraste, aparelhos auditivos, óculos e lupas) ou cognitivos (leitor imersivo).
Os leitores de tela são responsáveis por converter informação textual em áudio através de uma voz sintetizada. Eu literalmente escuto o computador o dia todo lendo para mim meus e-mails, minhas mensagens no Teams ou o código que estou criando ou revisando.
Ou seja neste momento estou escrevendo este artigo, com o leitor de telas lendo para mim todos os caracteres que digito, as mensagens do Visual Studio Code que é o o editor que estou utilizando as notificações do Windows que aparecem como mensagens do Teams, novas mensagens de e-mail, etc.
Por curiosidade utilizo o NVDA (Non Visual Desktop Access)] como leitor de telas padrão.
Principais diferenças no fluxo de trabalho
Logicamente que quando digo que programamos de forma igual estou generalizando. Existem diversos momentos em que nosso fluxo de trabalho é completamente diferente.
O leitor de telas lê uma linha de cada vez. Por mais que eu tenha comandos para ler o texto de forma corrida o mesmo é sempre lido de cima para baixo, da esquerda para a direita, uma linha de cada vez.
Mesmo em navegadores, e aplicações baseadas em tecnologias Web como o Electron, o leitor de telas faz a análise do conteúdo e o transforma em um buffer virtual contínuo. Não existe por exemplo esquerda e direita para posicionamento de elementos.
É por isto que reforçamos a importância do HTML semântico, ele deixa bem claro este comportamento para o leitor de telas na hora de fazer o buffer virtual.
Feita esta tangente quando estou codificando, ou realizando qualquer outro tipo de edição de textos, leio e escrevo uma linha de cada vez.
Isto por si só traz consigo alguns desafios:
Quando se enxerga é possível em uma rápida olhada no editor entender sua estrutura e onde blocos de código são abertos e fechados. Em linguagens como Python onde a endentação é o delimitador de bloco existem recursos dos leitores de tela que nos informam o nível de endentação, mas para linguagens que tem as chaves como delimitadores temos controlar de cabeça em quantos níveis estamos e se todos estão fechados.
Outro ponto diferente é que quem enxerga consegue bater rapidamente o olho nas margens, nas janelas de erros e até na barra de status para verificar informações rapidamente. Nós precisamos nos deslocar para estes pontos da tela para verificar a informação e muitas vezes isto quebra nosso fluxo.
E por último duas coisas que nos atrapalham muito são códigos comprimidos (em regiões por exemplo) e comentários longos ou excesso de linhas em branco. Já ouvi em uma revisão de código que as linhas estavam ali porque ficava mais legal de olhar no monitor.
Mas somos exímios usuários do teclado e suas infinitas combinações de tecla. Temos um grande nível de abstração e entendimento do código e das regras de negócio e nossos ouvidos atentos não deixam nada passar no Code Review
Programação em Pares
Apesar de a algum tempo não fazer isto e participar de Code Dojos e outras atividades de codificação empares e/ou grupos, gosto muito desta prática e concordo com a frase: "É o único momento em quem temos 100% de um cérebro programando".
Para isto podemos utilizar algumas estruturas:
No presencial trabalhamos preferencialmente na minha máquina pois já tenho o ambiente com o leitor de telas configurado e com minhas preferências. A pessoa pode pilotar discutindo comigo as suas ideias e vou acompanhando o código dela com o leitor. Já quando eu sou o piloto consigo ouvir o leitor e ao mesmo tempo trocar ideia com a pessoa que me acompanha de boa.
Mas a pandemia chegou e nos mostrou que nem tudo é presencial. Como fazer?
O Visual Studio e o Visual Studio Code tem um recursos muito legal chamado LiveShare. Este recurso permite que tenhamos nossa sessão de codificação compartilhada entre dois ou mais participantes. Todo o código é compartilhado entre os membros do LiveShare e mesmo que a pessoa não tenha o ambiente preparado todas as extensões, IntelliSense e ambiente de depuração estarão disponíveis automaticamente.
Ao se iniciar uma sessão é gerado um link o qual deve ser compartilhado com os participantes. Ao acessar é possível se navegar livremente pelo código ou marcar para seguir um usuário. O código pode ser modificado livremente, a menos que o dono da sessão indique que a mesma é somente leitura.
Ao final da sessão todos os códigos são removidos das 'máquinas remotas.
Este recurso tem me ajudado muito a atender nossos clientes e o índice de satisfação é bem alto. Tenho usado também em sessões de treinamento e mentoria e a agilidade que ganhamos é incomparável.
Outros desafios
Logicamente que existem outros desafios no nosso dia-a-dia. Muitas vezes o conteúdo que precisamos está embarcado em uma imagem.
Por mais que estudemos a especificação do [CSS] (Cascading Style Sheet) por exemplo, ou qualquer outro framework de estilização de interfaces, muitos dos conceitos são muito abstratos ou não fazem sentido algum para nós, como o posicionamento de elementos na tela. Isto diminuiu um pouco com o uso de dispositivos móveis sensíveis ao toque como os celulares, mas mesmo assim é algo bem desafiador.
Durante os últimos quatro anos desenvolvi diversos projetos onde as interfaces eram ricas e de uma perfeição de posicionamento de elementos impar. O que fazíamos no time era me reunir com o gerente de produtos para que ele me descrevesse a tela e seu funcionamento e se havia no projeto alguma outra tela semelhante.
Eu fazia o desenvolvimento da tela dentro daqueles parâmetros passados e implementava a funcionalidade e logo após fazia uma programação em par com alguém do time de qualidade para fazer os últimos ajustes finos.
Outro problema era fazer a revisão de [pull-requests] muito longos. Apesar de uma interface muito amigável do github para isto fazer a revisão de mudanças muito grandes me demandavam muito tempo e esforço, então combinamos um limite de arquivos os quais eu aceitaria fazer a revisão, daquele limite para cima eu passava a bola para outra pessoa no time.
E já que falamos do git somos muito bons em linha de comando e resolvemos se não tudo a maioria das coisas por lá. Mas infelizmente quando nos deparamos com conflitos de merge é realmente bem difícil de se corrigir quando é muito extenso. Não temos o auxílio das interfaces de diff disponíveis nos editores de vocês e temos de nos virar com as marcações que o git coloca no arquivo.
Revisando
Neste primeiro artigo quis apenas reforçar que uma pessoa com deficiência utiliza o computado e realiza tarefas da mesma forma que você com a diferença que de dispomos hoje de tecnologias assistivas que nos auxiliam.
Não reforcei isto no texto, e pode ser tema para uma outra postagem, mas seguir boas práticas de engenharia de software como código limpo, testes, uma boa arquitetura e padrões de projeto ajudam demais na compreensão e inclusão de novos membros no time.
Temos a disposição hoje no Visual Studio e Visual Studio Code inúmeros recursos que ajudam muito como o LiveShare, o IntelliSense e o IntelliCode, que também serão abordados mais profundamente em postagens futuras.
Por último mas não menos importante seja intencional em seu processo de inclusão e entenda que não existe pergunta boba e que cada indivíduo é diferente. Pode ser que o que eu use não funcione para outra pessoa com deficiência visual e tudo bem, neste caso o melhor é entender e adaptar o que eu disse aqui para o fluxo de cada pessoa. Só convivendo e tendo um diálogo aberto é que vocês chegarão ao melhor fluxo de trabalho.
Até a próxima!