Ser rigoroso ou pragmático?

Estou começando a perceber que o desenvolvimento de software é (entre outros) um processo de se fazer perguntas constantemente. Perguntas sobre qualidade de código, separação de preocupações, minimização de dependências, ...

Mas a questão principal é: até onde você pode ir sem acabar em um hospital psiquiátrico?

Estou me candidatando a um novo emprego. Ontem eu estava com um possível futuro empregador que queria testar meus recursos de programação. Um dos exercícios foi: explique o que esse código faz. Passei por algum código do aplicativo (winforms no vb.net) que eles desenvolvem (é um aplicativo administrativo para um hospital). Isso me deu a oportunidade de realmente ver como eles abordam as coisas e foi bastante decepcionante.

Alguns exemplos:

• Vi em algum lugar: Ligue [insira o nome da sub-rotina aqui] -> fiquei impressionado: isso não é algo do VB6?
• Eles têm uma camada de dados separada, usando ado.net, mas um método que eu tive que examinar retorna um conjunto de dados para a camada de chamada. Portanto, separador de dados separado ou não, o aplicativo está vinculado ao ado.net (o que também pode nunca ser um problema se nunca mudar para outra abordagem de acesso a dados).
• Esse conjunto de dados é lido como está, por isso ainda é uma abordagem centrada em dados (é claro, pode-se argumentar quanta lógica / comportamento você pode colocar em classes como "Paciente" ou "LabAnalysisRequest".
• Eu também acredito ter visto a construção de uma consulta sql por concatenação de strings.
• Eles usam procedimentos armazenados (o que, para mim, significa: dispersão da lógica)
• nenhuma menção de visualizações / controladores: tudo é orientado
• A coisa mais feia que vi foi:

      Se TestEnvironment.IsTesting,
         someVar = [algum valor codificado]
      outro
         someVar = [algum valor recuperado dinamicamente]
      fim se
      [restante da função aqui]
  

É tudo tão diferente do que aprendi na escola: camada de domínio (independente de persistência), camada de persistência, camada de apresentação, teste de unidade, ...

Por isso, refiz minha pergunta: quão fundamental ou dogmático deve ser? Até que ponto um programador deve seguir seus princípios ou apenas escrever um código que faça o trabalho?

Sei que isso não responde diretamente à sua pergunta, mas ainda acho que vale mais do que um comentário:

Quando você faz uma entrevista de emprego, você está entrevistando eles tanto quanto eles . Quebre o hábito de ver uma entrevista como algo que você rasteja na barriga, pedindo que eles lhe ofereçam algo. Eles fazem checkout em você, mas você faz check-out também. Se eles não gostam de você, não o contratam. Se você não gosta, não vá trabalhar lá.

Sim, na indústria, com uma base de código legada de dez anos que foi hackeada ao longo do tempo por três dúzias de desenvolvedores com formação, habilidade e paixão diferentes, impulsionados por prazos apertados, falta de recursos e restrições financeiras, o código nunca olhe da maneira que você (deveria) ter aprendido. Você terá que fazer algumas concessões. Mas quantos, e onde você desenha a linha, isso depende totalmente de você.
Obviamente, é mais difícil encontrar trabalhos com menos concessões. Mas eles podem ser mais agradáveis.

FWIW, até agora (até 10 anos na indústria) nunca trabalhei em uma grande empresa com muitos desenvolvedores (~ 30 desenvolvedores era o mais, uma dúzia da norma), porque é muito mais provável que você mude algo em um pequeno companhia. Enquanto eu ganhar dinheiro suficiente para não deixar as crianças morrerem de fome, não gostaria de ser uma pequena roda dentada em uma grande empresa, onde tudo o que tenho a fazer é sincronizar-me com o resto das artes.
Recusei as ofertas de emprego depois de ver os testes que eles queriam que eu passasse. Eu sou um desenvolvedor de C ++, e há muitos testes de C ++ por aí que são tão ruins que fazem as unhas dos pés se encolherem de nojo, e eu não quero gastar meu tempo lutando contra moinhos de vento porque eles contrataram idiotas que não conseguem escrever código limpo.
Também deixei os empregos depois de alguns meses porque sua filosofia de programação (objetivos de curto prazo, não importa no próximo ano) não se encaixava com minhas habilidades (estabilidade de código de longo prazo), apesar de dizerem algo diferente na entrevista.

Nunca escreva código que apenas faça o trabalho. No entanto, esteja igualmente disposto a examinar sua doutrina. Só porque você aprendeu na escola, não significa que seja o pensamento atual, ou mesmo o pensamento válido. O ciclo de vida do design de software tornou-se obsoleto, devido à programação ter que ser mais reativa ao mundo dos negócios. Às vezes, as soluções de software desajeitadamente vinculadas são desajeitadamente vinculadas porque as peças foram substituídas conforme o tempo permitido.

Aqui está uma lista dos problemas que compilei que determinarão como você se encaixa no estilo de vida de codificação de uma empresa.

1. Quanto eles valorizam reservar um tempo para refatorar e atualizar sua base de códigos. O modo como eles vêem a atualização da base de código será um fator determinante importante para a sua adequação.
2. Com que frequência eles compram terceiros, em vez de codificar internamente.
3. O que eles pensam do software de código aberto. Eles percebem que têm flexibilidade para alterar o código. Eles vêem da mesma maneira que compram terceiros.
4. Você estará trabalhando em uma certa camada de abstração. A equipe com a qual você faz interface determina sua interface para você? Qual camada / equipe / lado da interface tem mais poder na tomada de decisão.
5. Quanto o supervisor ouve os programadores ao tomar decisões. Quando um programador lança uma bandeira vermelha, o supervisor para e revisa sua decisão.
6. Você considera os programadores experientes em gerenciamento? Como eles veem sua experiência? A experiência deles é válida? Eles estão deixando a experiência desatualizada afetar a tomada de decisão?
7. Qual é a aderência da base de código?
8. Com que frequência eles atualizam suas ferramentas de programação (IDE, etc.)

As respostas a essas perguntas se encaixam melhor em como você valorizará o estilo de vida da programação, do que ver se elas correspondem ao seu dogma.

O dogma inevitavelmente será quebrado (nós simplesmente não temos tempo para atualizar o X). No entanto, as prioridades definirão o quanto você entra em conflito com o estilo e a tomada de decisões.

Eu acho que você tem que pesar isso como parte do todo. Lembro que um dos meus primeiros trabalhos foi uma posição em um grupo que me disse que eles estavam fazendo C ++ orientado a objetos - que foi o que eu acabara de fazer vários anos na escola.

A autoavaliação deles estava errada - eles estavam fazendo um C um tanto robusto. Ainda era muito funcionalmente desenhado na natureza e eu tive que pegar um livro em C para me ensinar como imprimir e obter e outros mecanismos que eu nunca havia aprendido. O fato de ninguém na equipe sequer ter percebido como o C era o código indica o quão errado esse "design C ++" havia caído. Meu objetivo na época era fazer o desenvolvimento de OO, então isso foi meio desanimador.

Mas estou feliz, no final, por ter ficado com o time. Eles eram um grupo dinâmico de pessoas muito inteligentes e eu me molhei com muitos problemas difíceis, trabalhei durante todo o ciclo de vida e as coisas que aprendi sobre o domínio do problema (PKI) alimentaram minha carreira desde então. O trabalho que a equipe estava realizando no espaço funcional foi incrível e ainda penso com muito carinho naquele produto e nessa experiência de trabalho. Melhor ainda - eu ainda trabalho com algumas dessas pessoas hoje (várias empresas depois), elas ainda são uma inspiração e ainda estamos fazendo um bom trabalho.

Não acho que a implementação perfeita das melhores práticas de uma linguagem de codificação seja a criação ou quebra de uma boa experiência de trabalho ou de uma boa equipe - o trabalho que alimenta uma carreira é muito mais do que isso, e se o produto tiver um desempenho decente qualidade, a equipe tem condições de trabalho decentes (como o Joel Test) e a equipe está cheia de pessoas inteligentes e que realizam as tarefas; então, a perfeição da implementação é secundária. Afaste fatores como bom trabalho, boas pessoas, boas condições de trabalho - e não vale a pena ficar por aqui - independentemente de o código ser ou não organizado de maneira estranha.

quão fundamental ou dogmático deve ser? Até que ponto um programador deve seguir seus princípios ou apenas escrever um código que faça o trabalho?

A coisa mais importante a lembrar aqui é qual é o seu propósito ?

Na maioria das empresas, seu objetivo na vida não é escrever um código perfeito. Seu objetivo é agregar valor ao usuário. Escrever um bom código geralmente é a melhor maneira de fornecer um bom produto que também é fácil de manter, solucionar problemas e desenvolver.

O código bom é uma ferramenta que você deve aplicar onde lhe der um bom ROI.

Alguns exemplos:

1. Eu passava muito tempo projetando e codificando minhas APIs, especialmente a API da minha camada de negócios. Muitos outros programadores vão usá-los e economizarão muito tempo e problemas se forem projetados corretamente
2. Vou relaxar um pouco as regras na minha camada de apresentação. Lá estarei mais inclinado a sacrificar a "perfeição" do código em favor da adição de mais recursos

Resumindo, você precisa ter princípios, mas também deve ser flexível o suficiente para quebrá-los quando eles trazem mais mal do que valor.

Eu trabalhei para um varejista de comércio eletrônico por alguns anos. Quando eu comecei lá, o código para seus aplicativos internos estava todo escrito em VB para MS Access, e era horrível, para dizer o mínimo. Eu tinha uma equipe de 3 desenvolvedores e, nos próximos anos, substituímos isso por aplicativos VB.Net adequados.

Mas como meu orçamento de contratação era extremamente limitado, eu só podia pagar programadores juniores. E, é claro, o código que eles produziram não foi tão bom assim. Mas funcionou, e a empresa usou esses aplicativos para ganhar dinheiro todos os dias.

E então eu comecei a trabalhar com meus caras. Um pouco de treinamento em OOD, em design de banco de dados, em MVC e C #. E ao longo dos anos, as coisas melhoraram. Quando saí depois de quatro anos, a base de código ainda não era boa, mas era 100 vezes melhor do que quando comecei.

Uma situação como a que você descreve é ​​geralmente a consequência de se contentar com os recursos disponíveis. Nós não vivemos em um mundo ideal. Ao mesmo tempo, esta é uma ótima oportunidade para realmente fazer a diferença.

Entre: alguns desses aplicativos ainda estão em uso, praticamente inalterados em relação a cerca de três anos atrás, e ainda ganham dinheiro.

Eu acho que seguir seus princípios é muito importante. Você deve sempre se esforçar para produzir o melhor código possível dentro das restrições fornecidas. No entanto, se você adicionar "nunca deve ler ou alterar código incorreto" à sua lista de princípios, terá muita dificuldade em encontrar trabalho. Lembre-se de que 50% dos programadores se formaram na metade inferior da turma. Mesmo em uma equipe individual, "hoje você" está mais qualificado para resolver um problema do que "você no mês passado". Ser capaz de trabalhar com código não ideal é apenas parte do trabalho.

Muitos empregadores reconhecem isso; portanto, o código que eles fornecem para você ler pode ser representativo do pior código em sua base de código, e não do melhor. Se isso não estiver claro no contexto, você deve perguntar. Um colega com quem às vezes entrevisto tem uma página de código que ele propositadamente escreveu mal apenas para usar como pergunta de entrevista.

Em 99% dos casos, você deve seguir o "dogma" como você o chama. O dogma é feito por pessoas experientes ao longo de anos de prática, e o que parece pragmático em algum momento realmente não é. Isso geralmente é mais relevante do que o fato de você não ser bom o suficiente para lidar com esse problema corretamente.

No entanto, não siga o dogma cegamente. Lembre-se de que conclusões levam as pessoas a seguir esse dogma. Porque você encontrará uma pequena parte dos casos em que não deve ser seguida. De qualquer forma, esses casos serão muito raros e você sempre deve discutir com outros programadores experientes antes de tomar essa decisão.

Seja rigoroso quando for importante. Estilo de chave (ou outras convenções de codificação)? Não importa. Use o que a loja usa. Quebrar o encapsulamento (ou outros princípios fundamentais de programação) sem um bom motivo? Não é tão trivial.

O Stack Exchange usa tabelas para layout (como muitos outros sites importantes que estão lucrando ). Isso faz a fumaça sair dos ouvidos dos puristas? Claro que sim. Mas o pragmatismo vence sempre a pureza. O produto de remessa vence sempre que é perfeito, sempre.

Toda a camada de domínio, camada de persistência, camada de apresentação, coisa de teste de unidade ainda é relativamente nova, do ponto de vista histórico. Existem muitos pacotes de software por aí que ainda usam um modelo de Cliente / Servidor e não serão alterados para o estilo arquitetural mais recente apenas porque é "melhor".