Olá, meu nome é Dmitry Karlovsky, e eu sou um ciclista profissional. Ao longo da minha carreira, fiz várias bicicletas: grandes e pequenas, rápidas e confortáveis, tortas e retas. Portanto, é muito louco ver programadores inteligentes criando aplicativos grandes e complexos, mas ao mesmo tempo conectando outro teclado esquerdo ao projeto, em vez de escrever algumas linhas simples com minhas próprias mãos. A razão para isso é o medo de bicicletas na produção que se desenvolveu entre os programadores e se sustenta.

Evolução do Programador

Para simplificar a apresentação, distinguimos três grupos condicionais de programadores. Condicional, porque não há uma fronteira clara entre eles, e a mesma pessoa em áreas diferentes pode pertencer a grupos diferentes.

Novato

• Ele ainda tem pouca experiência e conhecimento, mas aprende rapidamente novos, pois ainda não possui hábitos estabelecidos.
• Devido ao efeito da novidade, ele vê bem as deficiências das soluções existentes e tem um forte desejo de fazer as suas próprias sem essas deficiências.
• Ele não sabe como e por que essas ou outras práticas e princípios foram formados e, se o faz, não sente as razões de sua aparência em sua própria pele.
• A maior parte do código escrito por ele é jogado fora ou refatorado além do reconhecimento. Na melhor das hipóteses, com as próprias mãos sob a direção de colegas mais experientes.
• Ele é impiedosamente derrotado por escrever bicicletas, porque é mais provável que uma biblioteca de terceiros seja melhor em termos de muitos critérios.

Especialista

• A grande maioria das bibliotecas populares foi escrita por ele em seu tempo livre a partir de seu trabalho principal, pois ainda batia nas mãos de bicicletas e de abertura de códigos-fonte.
• Como regra, a qualidade do seu código corresponde à qualidade média do código no ecossistema. Se todo mundo escreve macarrão a partir de retornos de chamada, nada resta a ele.
• Como regra, ele usa código de terceiros, já que o seu próprio não é muito melhor, ou pior, devido a limitações de tempo.
• Por conseguinte, continua a receber as mãos nas bicicletas explicitamente (em uma revisão de código) ou implicitamente (relatórios de erros).
• Quando algum problema o deixa completamente, ele vê uma bicicleta. E como a maioria desses programadores é composta por 100.500 bicicletas incompatíveis entre si, suportadas por um desenvolvedor e meio.

Profissional

• Ele é capaz de resolver qualquer um dos problemas melhor que a média do hospital, mas devido aos recursos limitados, é forçado a escolher o que dedicar tempo.
• Por hábito, eles o venceram nas mãos. Especialmente se a empresa praticar scrum, onde todas as decisões são tomadas pela maioria, sujeitas ao efeito Dunning-Krueger.
• Muitas vezes, devido aos complexos formados nos dois primeiros estágios, ele se limita e acredita que não pode fazer nada melhor do que uma biblioteca de terceiros "testada", "pensada", "suportada por um grande número de desenvolvedores".

Causas do medo

Após a evolução do programador, é fácil perceber que, a princípio, ele tem poucas habilidades, mas não tem medo, e à medida que adquire habilidades, o medo das bicicletas aparece e se intensifica. Para lidar com esse medo, você precisa analisar suas causas.

Eu não posso fazer melhor

Um iniciante realmente não pode. Ele deve direcionar seus esforços para explicar a essência e a importância dos problemas que vê com sua nova aparência para colegas mais experientes e desenvolvedores de bibliotecas.

Um especialista provavelmente não terá sucesso se for bem versado nos problemas e consultar outros especialistas e profissionais.

Um profissional é capaz de fazer melhor na maioria dos casos, uma vez que ele já é bem versado no tópico e ainda tem a habilidade de uma análise abrangente. Infelizmente, normalmente não há ninguém para consultá-lo, pois existem poucos outros profissionais e eles estão envolvidos em outros tópicos. E os especialistas não têm horizontes.

Não haverá ninguém para reparar defeitos

Normalmente, o autor da moto está bem motivado para reparar defeitos em sua ideia. Mas, mais cedo ou mais tarde, essa motivação passa, se ele fizer isso depois de horas. E aqui, uma biblioteca de terceiros, ao que parece, permite economizar recursos, porque outras pessoas que não precisam pagar estão envolvidas em seu suporte. Mas não é possível influenciá-los e, portanto, para cumprir o prazo, você deverá arregaçar as mangas e consertar o defeito por conta própria, após o que será longo e difícil quebrar seu patch no repositório principal, sem qualquer garantia de sucesso.

Ninguém vai melhorar e desenvolver

Aqui a situação é a mesma que com os defeitos. Mas se, com defeitos, geralmente fica claro para todos que eles precisam ser reparados, então a visão sobre a direção do desenvolvimento é diferente para todos. Um desenvolvedor de terceiros desenvolverá sua biblioteca onde ele precisar, e não para você. Na velocidade que for conveniente para ele, e não para você. Portanto, se um vetor específico de desenvolvimento for necessário, sua bicicleta fornecerá controle e previsibilidade - duas qualidades que são muito mais importantes para o gerenciamento do que tempo e dinheiro.

Não posso usá-lo em nenhum outro lugar

Se você quiser usar a bicicleta fora da empresa, precisará desenvolvê-la no seu tempo livre ou concordar com a abertura da fonte, que geralmente é mais difícil, mas é possível. Afinal, a empresa recebe RP quase gratuitamente entre os funcionários em potencial, bem como os testadores beta gratuitos (ou mesmo colaboradores, mas você não deve confiar nisso) na pessoa de outros usuários de bicicleta.

Tempo e dinheiro serão desperdiçados

Aqui, antes de tudo, vale a pena comparar com alternativas. Se não houver, então não há escolha - você precisa cortá-la. Se houver alternativas, vale a pena comparar em termos de dinheiro e tempo:

• O custo de escrever sua bicicleta é de boa qualidade. Isso inclui o tempo real para escrever o código, bem como escrever testes, e transferir o projeto para uma bicicleta e avaliar o custo dos defeitos introduzidos.
• Os benefícios que uma bicicleta oferece. Isso pode ser uma economia devido a certos recursos, cada vez menos defeitos e outros fatores.
• O custo da integração de uma solução de terceiros. Novamente, incluindo uma avaliação do custo dos testes e defeitos introduzidos.
• Restrições impostas por uma solução de terceiros. Pode acontecer que uma solução de terceiros não seja adequada. Ou que retardará o desenvolvimento em 2 vezes.

Também vale a pena avaliar separadamente o custo da mudança de uma solução de terceiros para uma bicicleta, se de repente se verificar que algumas das restrições são mais inaceitáveis. Muitas vezes acontece que agora é mais lucrativo implementar uma solução de terceiros e depois transferi-la rapidamente para sua bicicleta quando (e se) você precisar, do que gastar tempo na construção de bicicletas agora.

Essa avaliação ajuda a entender se o jogo vale a pena e explicar à gerência por que vale a pena escrever o seu próprio e não levar o de outra pessoa (ou vice-versa).

Eu serei amaldiçoado como amaldiçoei meu antecessor

É duvidoso que a bicicleta tenha ocupado uma parte significativa do projeto. Então eles vão amaldiçoar mais pelo resto do código. Portanto, a bicicleta deve ser feita pelo menos não é pior. E melhor ainda, se ninguém desejasse substituí-lo por uma biblioteca de terceiros ou outra bicicleta. Para fazer isso, você precisa:

1. A presença de uma vantagem clara e importante para o projeto.
2. Uma interface de uso simples, para que você não precise usar seus wrappers.
3. API flexível para que você não precise ver uma bicicleta nova com uma pequena alteração nos requisitos.
4. Boa cobertura de teste, que permitirá menos flashes nos relatórios de erros e reviverá bem a refatoração.
5. Documentação abrangente para que você não precise procurar o autor da bicicleta para entender como usá-la.

Eu não quero assumir responsabilidade

É normal que você não dê a mínima para o projeto em que está trabalhando. Se você realmente não se importa com o que dedica um terço do seu tempo em um dia, precisa defender seu ponto de vista. E quanto maior o seu status, mais responsável é se aproximar do que dizer. De fato, não apenas como você trabalha, mas como os outros funcionarão, e para onde o projeto como um todo irá, depende da sua voz.

Recomendações

Espero ter conseguido mostrar os medos infundados das bicicletas. Quanto mais perto do profissionalismo, mais ambiciosas as bicicletas podem ser. É melhor começar com bicicletas menores, que apresentam riscos mais baixos, mas que oferecem bastante experiência nesse campo. E com esse portfólio, assuma coisas cada vez mais legais e interessantes. É importante não esquecer que um verdadeiro profissional não apenas faz coisas legais, mas também sabe quando abandonar sua criação. Portanto, sempre realize uma análise que lhe dará confiança de que você está fazendo tudo certo, e a gerência estará do seu lado, e aqueles que vierem depois de você entenderão que tipo de bicicleta é, por que está aqui e por que era impossível de outra maneira.

Bem, para ajudá-lo com a análise de bibliotecas de terceiros, escrevi durante a noite um aplicativo que permite estimar o tempo para resolver os problemas dos projetos no GitHub . Quanto maior o número, pior o projeto com suporte e mais tempo você terá que esperar por uma solução para o seu problema. Por exemplo: uma comparação de Angular, VueJS, React e, é claro, o $ mol no qual esta bicicleta está escrita. Lembre-se de que o último link é único, uma vez que o surgimento de todos os problemas abertos do Angular consome todos os limites do GitHub, o que mostra eloquentemente que seus mantenedores não conseguem lidar com o apoio do monstro que geraram.