Coffee break #13: O que todo novato em programação deve saber; 4 maneiras de incorporar o Design Thinking em seu processo de desenvolvimento

O que todo novato em programação deve saber

Fonte: Stackoverflow Como desenvolvedor, você ouvirá muitas teorias diferentes sobre a aparência do código. Algumas pessoas acreditam que quanto menos linhas de código um aplicativo tiver, mais fácil será a leitura. Mas isto é apenas parcialmente verdade. Prefiro avaliar a qualidade do código usando os seguintes critérios:

1. O código deve ser consistente, informativo e bem documentado.
2. O código deve usar recursos modernos e estáveis.
3. O código não deve ser desnecessariamente complexo ou quebrado.

Se você decidir reduzir o número de linhas de código em detrimento de um dos critérios acima, isso se tornará um problema. Não faça isso.

Ler o código de outra pessoa é difícil

Na verdade, a proporção de tempo gasto lendo e escrevendo código é superior a 10 para 1. Mas você não pode ficar sem ler o código de outras pessoas. Você terá que ler o código de outra pessoa. E quanto mais cedo você melhorar suas habilidades, melhor. Tente estudar o código de outras pessoas usando repositórios abertos do GitHub. Você pode praticar a qualquer momento: basta encontrar um projeto que combine com você e se aprofundar em cada linha. Outra maneira de melhorar sua capacidade de ler o código de outras pessoas é começar a copiar o estilo. Quando você escreve código no estilo de outra pessoa, isso não apenas melhora suas habilidades de leitura, mas também torna o código mais familiar para você. De uma chance.

Você nunca escreverá um código “perfeito”

Fui desenvolvedor solo por quatro anos antes de começar a trabalhar em equipe. Durante a maior parte desse tempo, acreditei que qualquer programador experiente escrevia código perfeito. Na minha opinião, aprender a escrever código perfeito é apenas uma questão de tempo e esforço. Mas quando entrei para a equipe, ficou claro que ninguém escreve código “perfeito”. É verdade que o código finalmente incluído no sistema era quase sempre “perfeito”. Por quê isso aconteceu? É tudo uma questão de análise de código. Trabalho com uma equipe de engenheiros verdadeiramente brilhantes. Estes são alguns dos programadores mais competentes e confiantes que o dinheiro pode contratar. Mas cada um deles (inclusive eu) teria um verdadeiro ataque de pânico se alguém sugerisse incluir código não testado no aplicativo. Mesmo que você pense que será o próximo Bill Gates, cometerá erros. Não estou nem falando de erros lógicos, estou falando de erros de digitação, falta de caracteres. Coisas que seu cérebro às vezes simplesmente não capta. Coisas que só podem ser percebidas com novos olhos. Esforce-se para trabalhar com pessoas atentas aos detalhes e dispostas a criticar seu trabalho. Será difícil aceitar críticas no início, mas é a única maneira confiável de melhorar a qualidade do seu código. Faça o possível para não ficar na defensiva ao revisar o código e nunca leve as críticas para o lado pessoal. Você não é o seu código.

Você não deve escrever código 8 horas por dia

Ninguém pode dizer exatamente quanto tempo por dia gasta escrevendo código. Mas, na realidade, poucas pessoas escrevem código mais de 4 horas por dia. As pessoas que discordam disso são a exceção à regra ou trabalham para empresas que tratam mal seus funcionários. Programar é um trabalho intenso e mentalmente desgastante. É completamente errado pensar que alguém escreverá código 8 horas por dia, 5 dias por semana. Haverá raras ocasiões em que você precisará cumprir um prazo, mas quando digo raramente, quero dizer quase nunca. Não deixe que o trabalho o sobrecarregue e o obrigue a fazer horas extras. Não estou sugerindo que você trabalhe apenas quatro horas por dia. As quatro horas restantes geralmente são melhor gastas em coisas como:

• aprender novas ferramentas, funções, aplicações;
• discutir processos de trabalho com colegas;
• ajudar colegas que estão com dificuldades no trabalho;
• planejamento de tarefas;
• análise de código;
• reuniões/reuniões de negócios.

Também recomendo fortemente fazer pausas regulares ao longo do dia e praticar exercícios (pelo menos um pouco). Os efeitos positivos do exercício foram comprovados há muito tempo.

4 maneiras de incorporar o Design Thinking em seu processo de desenvolvimento

Source Tech Beacon Para criar um produto que atenda às necessidades de seus clientes, você terá que considerar o que eles desejam. Se você escreveu um aplicativo com navegação confusa ou uma interface de carregamento desnecessariamente longa, prepare-se para falhas futuras. Como programador, talvez você precise se aprofundar no design do produto em que sua equipe está trabalhando. Este tipo de colaboração é muito útil porque cada pessoa percebe coisas que a outra pode não perceber. Ofereço 4 dicas sobre como desenvolvedor e designer podem trabalhar juntos.

1. Envolva-se desde o início

Não presuma que o design sempre vem em primeiro lugar e o desenvolvimento em segundo. Isso pode ser verdade, mas não significa que os desenvolvedores não devam estar envolvidos no processo de design. O programador consegue fornecer informações técnicas importantes sobre como o projeto pode ser implementado, enquanto os projetistas entendem melhor os desejos dos usuários. É melhor descobrir o mais cedo possível qual função é tecnicamente impossível ou não atende aos requisitos do usuário. Se designers e desenvolvedores trabalharem juntos, os problemas poderão ser descobertos e resolvidos imediatamente, e não após a aprovação do projeto. Muitas empresas adotam uma abordagem colaborativa para o desenvolvimento de software. Isso significa que os membros da equipe não são responsáveis ​​apenas por seu próprio estágio ou trecho de código, mas assumem responsabilidade coletiva por tudo, desde o design até o teste.

2. Aprenda o processo UX

Aqueles que não estão familiarizados com UX (experiência do usuário) podem não entender por que as equipes mudam os designs continuamente em busca de detalhes aparentemente menores. Cada etapa do processo de UX acontece por um motivo: fornecer a melhor experiência possível ao usuário. Portanto, é importante prestar atenção na criação de um processo de UX desde o início. Pode incluir:

• pesquisar o objetivo do projeto;
• criação de wireframe - um design simples que permite determinar as principais características do produto;
• adicionar detalhes mais sutis ao design do projeto, como a interface do usuário;
• testes de usuários de projetos. Esta é talvez a etapa mais importante do desenvolvimento de UX. Isso fornece informações valiosas sobre o produto antes que você gaste tempo desenvolvendo-o;
• Iteração: Usando a análise dos resultados do teste, itere o design para melhorar a experiência do usuário.

As equipes repetem as etapas de design e teste várias vezes até que não haja mais alterações ou conforme o tempo permitir. Isso geralmente significa que você terá várias versões do design.

3. Acompanhe o desenvolvimento do design

É muito ruim quando os designers criam um projeto sem consultar os desenvolvedores. É contraproducente. É importante que o DevOps estabeleça regras para que os desenvolvedores tenham acesso a projetos em formatos facilmente acessíveis, como PNG ou PDF. A colaboração eficaz entre desenvolvedores e designers é fundamental para o sucesso da implementação de um aplicativo. Evite entregar cegamente um projeto acabado a todo custo. É melhor corrigir um erro no início do que no final.

4. Combine em que fase o projeto será mostrado para você

Quando os desenvolvedores são solicitados a criar uma versão mínima viável de um produto (MVP), eles precisam conhecer os requisitos da versão final desde o início. Isto é necessário para evitar problemas com expectativas injustificadas. Os designers devem mostrar ambas as versões do design ao desenvolvedor: tanto o MVP quanto a versão final. Isso ajudará a implementar o MVP, levando em consideração o que o cliente espera ver na versão final. Quando designers e desenvolvedores trabalham juntos, eles obtêm muitos benefícios. Cada um deles possui conhecimentos que podem ser aplicados à experiência do outro. Os desenvolvedores podem fornecer informações valiosas sobre quais recursos não podem ser implementados no design. Por outro lado, a colaboração com um programador aliviará o designer da necessidade de refazer o projeto, o que, consequentemente, poupará tempo a toda a equipa.