Você as vezes vai a um dentista, faz um tratamento, mas acaba não gostando muito do serviço dele. Contrata um “faz tudo” pra arrumar algumas coisas na sua casa, mas alguma coisa nele não te agrada e você não chama mais. Compra um telefone celular de uma marca, mas a bateria acaba muito rápido e a tela quebra fácil.
Enfim, não gostar de um serviço ou não se adequar a um fornecedor é uma coisa muito normal e acontece em todas as áreas.
Na tecnologia não poderia ser diferente. Uma pessoa (ou empresa) contrata outra (pessoa ou empresa) para fazer um software, mas por um motivo ou outro acaba preferindo levar seu código para outra pessoa continuar. E é sobre isso que venho falar; você não vai levar seu código pra outra empresa. Siga lendo o post e entenda o porque.
Trabalho intelectual ou arte?
A tendência é pensar que programação é algo como engenharia ou arquitetura, que tem um padrão no qual o profissional segue afim de que o outro possa, ao olhar, entender.
Linguagens e todas as outras coisas
O cliente pergunta “o software é feito em que?” e você diz “C#“, então ele pensa “pronto, agora é só encontrar qualquer programador que saiba C# e levar o código”, simples assim né?
Quem dera, ledo engano… em C# por exemplo, existem dezenas de padrões de projeto, vários frameworks e ferramentas, que irão fazer com que um projeto seja completamente diferente de outro. Entity Framework? WPF? WCF? Asp .Net? .Net Core? Mono? DevExpress? Model First? NUnit, MSTest ou xUnit?
Imaginar que qualquer programador C# irá conseguir assumir qualquer projeto feito em C#, é uma ilusão. Seria como dizer que ao saber nadar em piscina, você estaria apto a nadar alto mar e em corredeiras. Ou que ao saber andar de bicicleta, saberá fazer downhill e speed (talvez você não saiba a diferença, mas são técnicas completamente diferentes).
Seguindo em frente, no tal projeto C#, temos algumas coisas para saber. O projeto roda local e acessa um banco remoto? O projeto é uma API? É um serviço? Ela foi feita pra se adequar ao ISS ou Azure? O banco é SQL Server, Postgres ou algum tipo de NoSql? É utilizado o C# em uma versão mais antiga ou nas mais novas? Enfim, todas estas informações dizem respeito ao projeto e seu “ecossistema” de funcionamento, e precisará ser dominado por quem assumir o projeto.
Eu diria que saber a linguagem de programação do projeto representa algo como 30% da solução. Além destes detalhes tecnológicos, o novo programador deverá lidar com o que vem na continuidade deste post.
É a cara do pai
Cada desenvolvedor ou empresa escolhe algumas linguagens para trabalhar. Nestas linguagens eventualmente optam por usar frameworks, que são pacotes de ferramentas que auxiliam no desenvolvimento naquela linguagem, do ponto de vista de algumas pessoas. Para outras, usar framework é quase inaceitável, faz pensar que o programador é preguiçoso ou que não domina de verdade a linguagem.
Quem começa o projeto é quem define o ferramental; linguagem, framework, bibliotecas, banco de dados, tipo de servidor, serviços de terceiros e por ai vai.
Então aquele sistema, quando está funcionando, fica com a cara do pai. Fica do jeitinho que o desenvolvedor imaginou e como ele gostaria que ficasse. É lindo!
Eu quero o código fonte!
Imagine que você tem um carro Honda e não tem gostado muito da performance dele, da marcha ré que as vezes não engata, e pra piorar o atendimento na autorizada não tem te agradado.
Dai você pensa “ok, vou levar meu Honda para manutenção na Chevrolet“. Chegando na Chevrolet eles abririam o capo do carro e falariam “nossa, que confusão, tudo mal feito, como isso funciona?”. A primeira reação seria não reconhecer aquilo como algo aceitável. “É um absurdo!”. Mas você insiste “não me atendem bem lá na Honda e preciso que vocês assumam este carro”.
Dai começa uma longa jornada dos mecânicos da Chevrolet tentando entender o que foi feito, intercalando com reclamar que foi mal feito, dizer que tal parte não tem como mexer, e dizer que talvez seja melhor comprar um Chevrolet novo e se desfazer do Honda.
E na programação é exatamente assim. O programador que possivelmente receberá aquele código dominará uma parte das tecnologias usadas, mas talvez não domine todas, o que fará que ele se sinta desconfortável com isso (igual aos mecânicos da Chevrolet).
Para piorar a situação, se um carro fosse um software, não haveria UM CARRO SEQUER igual ao outro! Mesmo que um programador faça o mesmo software duas ou três vezes, é praticamente impossível que ele consiga fazer do mesmo jeito. Nesta hora o código passa a se parecer mais com uma obra de arte (fruto de criatividade) do que com um projeto arquitetônico.
Ler o código que outra pessoa fez pode ser pouco ou muito desconfortável. Alguns programadores gostam mais de ler e tentar entender, outros gostam menos. Alguns gostam de escrever código fácil de ser lido por outros, outros nem tanto. Imagine então um projeto sendo passado de um desenvolvedor que não gosta de escrever “código fácil” pra um que não gosta de “entender código dos outros”, ta feita a m#&$a.
Claro que o programador que recebe o código sempre irá reclamar do código que o outro escreveu, gostando ele de ler ou não.
Transferindo o código pra outra empresa
Decidi por escrever este post em uma semana onde uma pessoa me procurou querendo que eu assumisse um projeto de terceiros, e um cliente quis passar nosso código para outro programador.
Fiz uma retrospectiva de quantas vezes ao longo da vida fui procurado para receber um projeto, e quantas vezes clientes quiseram levar um projeto para outros developers… e constatei que isso só aconteceu mesmo, efetivamente, uma ou duas vezes ao longo de uns 15 anos.
Mas, porque?
Se entra um desenvolvedor novo na minha equipe e preciso incluí-lo em um projeto nosso, será um pouco complicado até que ele entenda o que faz o sistema (pra que ele serve), como ele foi arquitetado, as nuances do código, como ele é executado e tal. Isso levará vários dias, conosco explicando sempre que ele “agarrar” em algo.
Mas terá um dia, que enquanto ele estiver lá programando, acontecerá um erro, um erro bem estranho que ele não vai sequer imaginar como pode acontecer. Ele então irá perguntar pra nós (que estamos desde o começo no projeto); “deu um erro aqui XPTO 215 comigo, o que é isso?”, e existe uma chance da gente responder “não sabemos também, acontece as vezes desde o começo e não conseguimos ainda descobrir a causa”.
O novo programador, quando vai publicar o aplicativo, segue pelo “jeito padrão” de fazer isso e não consegue, pergunta o porque e dizemos “neste projeto, tem que adicionar um parâmetro a mais aqui pra compilar, senão não vai, é alguma característica desta versão 1.68.4 do compilador, demoramos alguns dias para descobrir também”.
Quando o novo programador vai subir os códigos para o servidor a gente fala “peraí, tem que apagar um arquivo lá na pasta /storage/review/ps74.232/ antes de subir, senão o servidor não entenderá que o banco foi modificado e o serviço irá travar”.
O que estou dizendo é que existem uma série de detalhes que não são tão fáceis de se perceber, escrever, explicar para um novo membro do time. Muitas vezes a solução está na nossa cabeça porque ainda não conseguimos entender exatamente o porque aquilo acontece, dai ainda não registramos.
Agora, imagina isso tudo sendo enfrentado por uma pessoa totalmente externa, que não “tem culpa” do projeto ser assim, que não quer ter contato com quem criou o código, que preferia fazer do zero..
Pegar códigos dos outros para continuar em 95% das vezes é a maior roubada! É algo que você simplesmente não quer fazer.
Mas na empresa que meu conhecido trabalha…
“Lá, eles pegaram um projeto gigante de outra empresa e continuaram, depois a empresa foi vendida e o projeto continuou. “
Não estou falando que isso não acontece. Nem estou falando que não existem códigos maravilhosamente documentados. Isso existe sim, principalmente em grandes empresas, onde o software é o principal produto, que vem sendo desenvolvido, melhorado e documentado ao longo dos anos.
Mas em uma empresa pequena, média, isso é raro.
Imagina falar para o cliente que 30% do valor que ele irá pagar é tempo a ser usado documentando código, revisando código para ficar de fácil leitura de um possível próximo programador… o cliente vai rir da sua cara. Mas, na hora que as coisas começam a ficar estranhas, ele vai sentir falta disto, vai reclamar que não tem. É a vida.
Algumas empresas cobram 30% a mais por um projeto “com código fonte”, ou seja, se o cliente quer ter acesso ao código fonte ele para mais caro no projeto. Sempre achei isso bem estranho, porque entendo que o código fonte sempre é do cliente, mas talvez seja uma justificativa para fazer um código fonte mais bem feito, mais fácil de se entender.
Ele falou que o código é uma zona
“Passei o código para um amigo e ele falou que o código esta todo bagunçado”. Eu diria que “bagunçado” é muito relativo, vai depender do nível de organização de cada um, e do tipo de organização que cada um tem.
Se você olhar o guarda roupas de uma pessoa, provavelmente irá achar bagunçado a primeira vista. Se abrir uma gaveta então (aquelas cheias de pequenas coisas), será uma verdadeira zona!
De verdade é raro ver um código de terceiros e achar organizado. Em uma empresa onde o código é o produto, ou até em um projeto open source, existe mais chance do código estar certinho do que em um projeto feito para um cliente.
“O cliente não paga pelo código, ele paga pelo software”
Enfim, não venho trazer boas notícias
Detesto ser a pessoa que dá a má notícia… mas você não vai levar seu código pra outra empresa.
Eu sei que é ruim disser isso, mas talvez seja melhor tentar se adequar com o desenvolvedor atual, ou então, começar do zero com alguém com mais experiência.
E você? Já passou por isso em qualquer dos lados (cliente, programador inicial, programador que recebeu o código)? Comente ai e me ajude a fazer este post ser ainda mais completo!
Se você já teve sucesso levando um projeto de um responsável para outro, comente também!
