Neste post, gostaria de compartilhar alguns aprendizados importantes, técnicos e não técnicos, que obtive ao realizar esse projeto individual do início ao fim em um mês.
Aprecie o valor de reescrever o código antigo
Para projetos de CS na escola, raramente tenho a oportunidade ou experimento a necessidade de revisitar meu código.
No entanto, esse não é o caso quando trabalho em meus projetos apaixonados: adoro aproveitar todas as oportunidades para melhorar sua usabilidade e capacidade de reutilização, na esperança de que meu código seja útil para outros desenvolvedores.
Este motor de xadrez é baseado em um motor de xadrez que criei em Ren’Py e vanilla Python enquanto aprendia Python sozinho durante minhas primeiras férias de verão na faculdade.
Esse velho mecanismo de xadrez, por sua vez, é baseado em um projeto em minha aula de introdução ao CS (um jogo de xadrez GUI escrito em Racket, uma linguagem de programação funcional). Ou seja, reescrevi meu código duas vezes para produzir esse mecanismo de xadrez final.
Para minha primeira reescrita, eu simplesmente “traduzi” a lógica do xadrez (para determinar se um movimento é legal, condições de final de jogo e assim por diante) do Racket para Python. Eu também experimentei a Programação Orientada a Objetos, escrevi um Minimax Xadrez AI seguindo tutoriais online e implementei a GUI no Ren’Py.
Como eu só conhecia o básico do xadrez e escrevia minha lógica de xadrez de acordo com as especificações de classificação do meu projeto escolar, minha primeira máquina de xadrez não suportava movimentos especiais como en passant, roque ou promoção.
Para resolver esse problema em minha segunda reescrita, pesquisei bibliotecas Python de código aberto e encontrei xadrez python, uma biblioteca com suporte total para movimentos de xadrez e condições de final de jogo, como reivindicar um empate quando ocorre a repetição de três vezes.
Além disso, também integrou Stockfish, um AI de xadrez, e essa integração permitirá que meu mecanismo de xadrez configure a força do AI de xadrez.
Esses dois recursos agregaram um grande valor ao meu mecanismo de xadrez versão 2.0 e me permitiram focar nos aspectos mais importantes da minha reescrita, que descreverei a seguir.
Leia a documentação e mantenha a compatibilidade em mente
Tornou-se meu hábito folhear a documentação das bibliotecas de que preciso para meu projeto antes de pular para o design e o código. Isso me ajuda a avaliar qualquer problema de dependência e compatibilidade que possa surgir.
Este problema do Ren’Py GitHub aponta para o fato de que Ren’Py usa Python 2 e ainda não foi portado para Python 3. Então, reconheci que precisava de uma versão de python-chess que suporte Python 2, como a versão mais recente suporta apenas Python 3.7+.
Felizmente, versão 0.23.10 suporta Python 2.7 e Python 3.4+. Por fim, optei pela versão 0.23.11, pois é a última versão que ainda oferece suporte ao Python 2.7.
Tendo resolvido os problemas de dependência e compatibilidade, eu estava pronto para passar para o design e a codificação.
Siga as práticas recomendadas de engenharia de software
Observação: muitos termos mencionados nesta seção são de Agile / Scrum.
Reúna os requisitos de recursos para o design do projeto
Embora seja tentador pular direto para a codificação, não consigo enfatizar o suficiente a importância do design.
Pense no design como um roteiro de alto nível que delineia claramente o ponto de partida, marcos e pontos finais do projeto. Isso permite que os desenvolvedores consultem quando estão mergulhados na cintura em detalhes de implementação complexos.
Isso é especialmente importante para projetos extracurriculares, pois eles geralmente não têm especificações detalhadas e altamente técnicas, ao contrário da maioria dos projetos escolares.
Para meu mecanismo de xadrez, identifiquei as seguintes reescritas / recursos adicionais:
- Integre a lógica do xadrez do python-chess
- No meu código da GUI do Ren’Py, substitua a lógica do xadrez e a IA do xadrez que escrevi pela lógica do xadrez e APIs do Stockfish do python-chess
- Suporta vários modos de jogo: Jogador vs. Jogador, Jogador vs. Computador (onde o Jogador pode escolher jogar como preto ou branco), força ajustável do xadrez AI através de ajustes nos parâmetros de configuração do Stockfish
- Desenvolva uma GUI Ren’Py para promoção de peão
- Desenvolva uma GUI Ren’Py para reivindicar um empate no caso de repetição tripla ou regra de cinquenta movimentos
Desenvolva um protótipo de prova de conceito
Um protótipo de Prova de Conceito (POC) me ajuda a avaliar o tempo e o esforço necessários para implementar os recursos necessários.
Para o POC do meu mecanismo de xadrez, integrei o python-chess com meu código de GUI Ren’Py original. Certifiquei-me de que seu conjunto de recursos fosse mínimo, mas prontamente extensível:
- Eu integrei o python-chess com meu código Ren’Py GUI original e fui capaz de mover as peças
- Eu só implementei Player vs. Player para adiar a integração do Stockfish para o xadrez AI
- Eu só permiti movimentos de não promoção para adiar o desenvolvimento da GUI para promoção de peão
Identifique a definição de pronto e a definição de pronto do projeto
A Definição de Pronto (DoR) do meu projeto segue naturalmente a minha investigação inicial sobre compatibilidade de versão de biblioteca e meu POC.
Paralelamente, a Definição de Pronto (DoD) do meu projeto segue os requisitos de recursos que identifiquei na fase de design.
Entregue um produto mínimo viável, ou melhor ainda, um produto mínimo adorável
Quando eu estava na fase de design, reunindo requisitos, sabia que havia muitos objetivos ambiciosos para meu projeto – talvez até mais do que eu poderia realizar.
Portanto, era importante para mim implementar o conjunto básico de recursos necessários, entregar um Produto Mínimo Viável (MVP) e coletar feedback para iterar sobre ele.
Melhor ainda, gostaria de entregar um Produto Mínimo Adorável (MLP) na minha primeira iteração. A diferença mínima é que, enquanto um MVP não requer nada mais do que recursos funcionais, um MLP tem uma experiência de usuário adorável por design.
Por exemplo, para implementar movimentos de promoção de peão, para um MVP eu poderia pedir aos usuários que pressionassem diferentes teclas para selecionar o tipo de peça que eles desejam promover (como B para bispo e K para cavalo).
Para um MLP, eu implementaria uma IU com botões em formato de peça que mudam de cor quando pairados ou selecionados.
Seja seu próprio gerente de projeto
Se você acha que manter o controle da lista de recursos (além da lista cada vez maior de bugs e correções) é complicado, você não está sozinho. É hora de ser seu próprio gerente de projeto.
eu encontrei Trello para ser uma ferramenta incrível para projetos de uma única pessoa e projetos de grandes equipes.
É assim que geralmente organizo minha placa Trello para um projeto de codificação:
Tenha quatro listas: Backlog (para recursos a serem triados), FAÇAM, Fazendo, e Feito.
Têm rótulos codificados por cores:
- Pronto para controle de qualidade: Um rótulo vermelho para chamar a atenção dos meus companheiros de equipe
- Impacto: baixo (amarelo) vs. alto (laranja), determinado pela quantidade de impacto que um recurso ou uma correção de bug irá gerar. Por exemplo, um painel de IU ligeiramente desalinhado é de baixo impacto, enquanto um bug de falha determinística é de alto impacto.
- Uma estimativa do tempo que levará para implementar: trivial (<1 hora, verde-azulado), médio (1–2 horas, azul claro) e difícil (2–4 horas, azul escuro).
Minha outra regra prática é: se eu estimar que um cartão levará mais de 4 horas para ser implementado, provavelmente devo dividi-lo em vários cartões mais granulados. - A cor serve como uma ótima dica visual: eu sempre lido com cartões com etiquetas laranja e verde-azulado (alto impacto e baixo comprometimento de tempo) antes de enfrentar aqueles com etiquetas amarelas e difíceis (baixo impacto, mas alto comprometimento de tempo).
Escreva a documentação e reflita sobre o seu aprendizado
Depois de enviar todas as cartas do Trello de TODO para Doing to Done e corrigir todos os bugs desagradáveis, é finalmente hora de encerrar o projeto? Sim e não.
Para maximizar meu aprendizado em um projeto, acho que vale a pena refletir sobre minhas lições, habilidades técnicas ou sociais:
- Escreva um README claro e conciso no repositório do projeto GitHub. Isso ajuda outros desenvolvedores a entender e se interessar pelo projeto.
- Escreva uma postagem no blog (como a que estou escrevendo agora) sobre os aspectos de nível superior, por exemplo, visão geral da arquitetura, design de recursos, desafios e soluções e assim por diante.
Créditos e links
Muito obrigado a Tim Min por me alertar para trabalhar neste projeto, por suas contribuições (novas idéias de recursos + QA) no quadro do Trello e por me responsabilizar. Tim é o escritor do jogo do romance cinético, O vento ao amanhecer.
Vamos ficar em contato! Conecte-se com o meu LinkedIn, GitHub, Médio, ou verifique meu site pessoal.
