Resenha: Lições aprendidas em 15 anos de SumatraPDF, um aplicativo Windows de código aberto

Se você é uma pessoa desenvolvedora de software com espírito empreendedor, gestora de tecnologia e gerencia projetos ou tem ideia de lançar um MVP em qualquer segmento, eu trago uma ótima referência para você finalmente estruturar seus primeiros passos.

Essa primeira publicação se trata de uma resenha rápida sobre um artigo, original em inglês, que não é extenso, mas é cirúrgico: "Lessons learned from 15 years of SumatraPDF, an open source Windows app", autoria do criador do software citado, o software leitor de PDF open source mais famoso e robusto da internet.

"SumatraPDF é o que chamo de sucesso acidental. Eu nunca quis escrever um leitor de PDF para Windows."

O autor nos traz os percalços e prazeres do desenvolvimento open source. Porém o que mais agrega é o viés empírico e técnico do artigo que traz à luz conceitos bem primordiais de desenvolvimento de software e user experience graciosamente de mãos dadas, gerando ótimos aprendizados durante o processo solitário de desenvolvimento desse software que se tornou um sucesso, ao longo dos seus 15 anos de desenvolvimento solo, e a adoção do mindset de user-centered design desde o primeiro momento.

Ao longo do artigo, o desenvolvedor traz reflexões importantes, soluções em nível de otimização ( spoiler para devs: C++ ), resolução criativa de problemas que um desenvolvedor solitário enfrenta, citações pontuais de Jeff Bezos e algumas conclusões polêmicas sobre o dogma do desenvolvimento.

Todo esse conhecimento em open source, facilmente aplicável a softwares com fins comerciais.

Seguem abaixo alguns dos aprendizados compartilhados no artigo:

Simplicidade versus customização

Simplicidade vende.

"Eu aprendi isso a partir da história do Mozilla Firefox.

Antes do Firefox, havia o Netscape Navigator. Era um aplicativo pesado, combinando navegador web com cliente de e-mail.

O Netscape não conseguia se conter e adicionava recursos após recursos, levando a uma interface de usuário muito complexa.

Um pequeno grupo de renegados dentro da Mozilla bifurcou o código e focou em uma interface simples.

O Firefox simples foi muito mais popular do que o Navigator complexo e eventualmente o eliminou completamente.

Desde o início, meu objetivo foi manter a interface do SumatraPDF o mais simples possível. Um aplicativo 80⁄20: 80% de funcionalidade com 20% de interface.

Eu constantemente recebo solicitações para adicionar mais ícones à barra de ferramentas e eu constantemente tenho que dizer "não", porque adicionar 2 ícones à barra de ferramentas para satisfazer 10% dos usuários torna o aplicativo ligeiramente pior para 100% dos usuários."

Painel de Configurações muito complexo

"Outra armadilha é a canção da sereia de configurações adicionais. Às vezes, as pessoas sugerem que, em vez de fazer X, o programa deve fazer Y. Não querendo remover X, elas sugerem adicionar uma nova configuração de interface do usuário "[ ] Fazer Y em vez de X".

Ter um diálogo de configurações com 100 configurações não é uma boa solução. Isso torna o aplicativo pior para todos, sobrecarregando-os com escolhas e ocultando opções importantes em um mar de opções não importantes.

Sem mencionar que cada comportamento condicional requer mais código, mais bugs potenciais e mais testes.

Dito isso, também acredito que a customização é importante. Acredito que uma grande razão pela qual o Winamp era um player de música tão dominante (na época) era sua capacidade de personalizar toda a interface do usuário.

Algumas funcionalidades avançadas podem ser usadas apenas por 20% dos usuários, mas esses usuários provavelmente são usuários avançados que evangelizarão o aplicativo mais do que os outros 80% dos usuários.

Minha solução para a simplicidade versus a customização da interface do usuário: arquivo de configurações avançadas.

Projetei um formato textual simples e legível por humanos (e escrevível por humanos) para configurações avançadas. Pense em JSON, mas melhor.

Não me preocupei em escrever uma interface do usuário para alterar essas configurações avançadas. Eu simplesmente abro o bloco de notas.exe com o arquivo. Quando o usuário altera as configurações e salva o arquivo, eu o recarrego e aplico as alterações."

Pense fora da caixa

Pensar fora da caixa é difícil porque a caixa é invisível.

"O SumatraPDF não foi o primeiro aplicativo leitor de PDF já escrito.

Mas a maioria dos leitores de PDF não se torna leitores de múltiplos formatos.

Em retrospectiva, é uma ideia óbvia apoiar o máximo de formatos de documento possível, **mas levei 5 anos para perceber isso**.

A maioria dos leitores ainda é de formato único e acredito que ser de múltiplos formatos ajudou o SumatraPDF a se tornar popular.

Não posso dizer que é uma ideia totalmente única. Já havia visualizadores de imagem de múltiplos formatos muito antes do SumatraPDF e provavelmente fui inspirado por eles."

Multiplataforma é superestimado

"O SumatraPDF é, sem desculpas, um aplicativo apenas para Windows.

O suporte a outras plataformas (Linux, Mac, Android) é um dos pedidos mais frequentes. Um pedido que tenho que recusar.

Primeiro, há uma razão pragmática: simplesmente não tenho largura de banda para escrever código para 3 plataformas.

Em segundo lugar, acredito que um excelente aplicativo para uma plataforma pode se tornar mais popular do que um aplicativo medíocre para 3 plataformas.

Voltando à primeira razão: não tenho largura de banda para escrever 3 excelentes aplicativos. Parte da razão pela qual o SumatraPDF é pequeno é meu uso de APIs win32 para a interface do usuário.

A única maneira para que uma única pessoa possa tentar um aplicativo multiplataforma é usar uma camada de abstração da interface do usuário, como Qt, WxWidgets ou Gtk.

O problema é que o Gtk é feio, o Qt é extremamente inchado e o WxWidgets mal funciona."

Testes não são necessários, assim como revisões de código

"Não estou dizendo que os testes são ruins ou que você não deve escrever testes ou fazer revisões de código.

Estou dizendo que eles não são necessários.

O dogma é poderoso. Às vezes, em minha vida corporativa, senti que escrever testes era apenas uma formalidade. Talvez devêssemos gastar mais tempo escrevendo código, pensei?

Mas tente fazer um ponto matizado sobre mais testes vs. mais código para seus colegas desenvolvedores e você será queimado na estaca e seu cadáver ardente será jogado aos cães selvagens. Crianças da vila usarão sua cabeça cortada para jogar futebol.

E ainda assim eu sei que você pode escrever código complexo, relativamente livre de bugs, sem testes, porque eu fiz isso.

Eu sei que você pode escrever código complexo, relativamente livre de bugs, sem ninguém olhar seu código, porque eu fiz isso.

Se ninguém usa seu aplicativo, quem se importa se ele falha.

Se muitas pessoas usam seu aplicativo e ele falha, elas vão te dizer e então você vai consertá-lo."

/* Fim da resenha

Vamos compartilhar conhecimento!

Qual assunto mais interessa a você? ✒️