Um Problema Comum?

eu estava assistindo/ouvindo esta grande conversa por Simon Brown, Modular Monólitos de ir para 2018.

in this he mentions a term called Cargo Cult Programming and it really strike a chord with me.Recentemente juntei-me a uma nova empresa com uma nova linguagem de programação, novas ferramentas, novos processos e uma nova equipa. Na verdade, é praticamente tudo “novo”.Isso me fez aprender muito nos últimos meses. Sendo relativamente experiente, gosto de olhar para os “porquês” em vez dos “Como” quando se aprende coisas novas. O que percebi é que esta não é a abordagem mais comum.

quando um usuário é encarregado de adicionar a uma base de código existente, estendendo a solução atual, eles provavelmente irão verificar como isso foi feito anteriormente, copiando a abordagem para sua solução. Eles podem / vão seguir cegamente este padrão como é como tem sido feito antes. Blocos adicionais são adicionados no topo da torre, sem questionar se é a coisa certa a fazer. Se todos fizerem isto, isto acabará por acontecer.

Este é o lugar onde o termo “Carga Culto de Programação’ vem.

Wikipedia explains it like this:

programação cult de carga é um estilo de programação de computador caracterizado pela inclusão ritual de código ou estruturas de programa que não servem a nenhum propósito real. Programação de seita de carga é tipicamente sintomático de um programador não entender nem um bug que eles estavam tentando resolver ou a solução aparente (compare shotgun debugging, deep magic). O termo “programador de carga cult” pode aplicar-se quando um programador de computador não especializado ou novato (ou um inexperiente com o problema em mãos) copia algum código de programa de um lugar para outro com pouca ou nenhuma compreensão de como ele funciona ou se é necessário em sua nova posição.

carga cult programação também pode se referir à prática de aplicar um padrão de design ou estilo de codificação cegamente sem entender as razões por trás desse princípio de design. Exemplos são a adição de comentários desnecessários ao código auto-explicativo, a adesão exagerada às convenções de um paradigma de programação específico, ou a adição de código de exclusão para objetos que a coleta de lixo teria coletado automaticamente.

Imagine um cenário onde você está trabalhando em um bug, encontrando o código que está causando a falha. Não tens a certeza do que se passa, por isso … ;

1. Google the error.
2. você encontra uma questão StackOverflow.
3. procurar a resposta mais elevada.
4. copiar e colar a solução no seu código.
5. tente depuração para ver se isso corrigiu o seu problema.

tem, então você verifica e segue em frente.Parece-te familiar?Porque fazemos isso? Por que razão pegamos cegamente neste trecho e o usamos como está, na nossa implementação?

o caso de uso provavelmente não é o mesmo, então eu ficaria surpreso se as soluções fossem. Exemplos simples à parte, compreender o raciocínio por trás da solução é mais importante do que a própria solução. Há muitas coisas que não podes fazer com algo que não compreendes. Você não pode modificá-lo, melhorá-lo ou testá-lo. Não podes documentá-lo e não podes possuí-lo.

todos nós amamos o que é novo, e a gestão especialmente parece gostar de seguir as tendências populares, acompanhando o avanço tecnológico.

a maioria das equipas irá agora seguir uma abordagem ágil. TDD e Testes Automatizados pode ser muito útil em determinados cenários, Integração Contínua remove muito da sobrecarga da equipe de infra-estrutura, Big Data e AI pode melhorar consideravelmente a satisfação do usuário e Conteinerização e, mais recentemente, Microservices shift nosso velho monólito de arquitetura em menor auto-contido serviços.Cada um destes avanços é brilhante por direito próprio, E eu não aprovo nenhum deles. O meu problema é se precisamos de adoptá-los a todos em todos os nossos processos e Código? Vemos posts de blogs do Netflix, Facebook, Twitter mostrando como seu uso transformou como eles funcionam. Se as grandes empresas as considerarem necessárias, não deveríamos nós também? É aqui que a programação de seitas de carga volta à sua cabeça feia.Precisamos entender os problemas com nossos projetos atuais, por que eles aconteceram, e como eles podem ser descartados no futuro. Sim, estes novos processos podem ajudar – nos com os nossos problemas, mas segui-los cegamente na esperança ténue de que o façam não é o caminho a seguir, nem faz qualquer sentido lógico.

eu mencionar Microservices especificamente como um monte de empresas que parecem estar a fazer a transição, citando benefícios, tais como:

• o desenvolvimento mais Rápido
• Alta escalabilidade
• Fácil para melhorar a
• Facilidade de implantação
• Autónomas equipes com a liberdade de escolha de tecnologia

Com uma lista como essa, o que há para pensar? Vamos todos Saltar para o comboio!

Espere um segundo… há alguma desvantagem dessa abordagem?

• Arquitectónico Complexidade

Em arquiteturas monolíticas, a complexidade e o número de dependências residem dentro da base de código, enquanto em microservices arquiteturas de complexidade move-se para as interações do indivíduo serviços que implementam um determinado domínio

• Complexidade Operacional
• Como a provisão de recursos em uma solução escalável e de baixo custo
• Como operar dezenas ou centenas de microservice componentes de forma eficaz sem multiplicar os esforços
• Como lidar com a falta de padrões e heterogêneos ambientes que incluem diferentes tecnologias e pessoas com diferentes conjuntos de habilidades
• Como lidar com o controle de versão
• Como controlar e depurar medicamentosas de todo o sistema
• Como manter o controle de centenas de condutas de código de implantações e suas interdependências

Estes são levantadas a partir da Amazon próprio “Desafio de Microservices” do white paper. Não sei quanto a ti, mas as desvantagens parecem-me mais assustadoras do que os benefícios. Mais uma vez, não estou a dizer que esta não é a abordagem certa para descer, mas a menos que estes benefícios superem os inconvenientes que estás a ganhar ao seguir esta abordagem?

o problema “Público”.

é realmente simples, pare de usar a palavra-chave pública, pare de criar automaticamente classes públicas. Porque o fazemos?

o problema com o uso da palavra-chave pública é que você está perdendo os benefícios relacionados à encapsulação. Porque o usamos tanto? É praticamente a palavra padrão que usamos ao criar classes, todos os exemplos irão usar classes públicas, feiticeiros e excertos irão implementar classes públicas. Está na hora de parar. Quantas pessoas têm uma conta pública no Facebook? A maioria das coisas neste mundo são privadas, como deveriam ser as nossas aulas. Torna-os privados por defeito, e se precisares que sejam públicos, muda-os.Com grande experiência vem grande apreensão.

quanto mais tempo você estiver em um campo, menos ingênuo você é para perceber melhorias que uma nova ferramenta ou processo trará. A maioria das ideias de hoje vem de décadas de pesquisa sobre o campo que estão finalmente a ser abraçados. Uma vez que algo ganhou adoção em massa, é mais fácil se sentir confortável em abraçá-lo totalmente. Isto é, se for a coisa certa a fazer.

“o Bom julgamento vem da experiência, e a experiência vem do mau julgamento”

– Rita Mae Brown

Então sinta-se livre para manter-se no vasculhando a internet para soluções e tutoriais para os seus problemas; manter a exploração de novas linguagens, estruturas e implementações. Basta estar ciente de por que eles funcionam, em vez de simplesmente como. Todos aprendemos com as nossas próprias experiências e erros, por isso a compreensão dos fundamentos irá impedir-vos de continuar pelo mesmo caminho no futuro.