Por exemplo, há um trecho comum em JS para obter um valor padrão:
function f(x) {
x = x || 'default_value';
}
Esse tipo de trecho não é facilmente compreendido por todos os membros da minha equipe, sendo o nível de JS baixo.
Não devo usar esse truque então? Torna o código menos legível pelos pares, mas mais legível do que o seguinte, de acordo com qualquer desenvolvedor JS:
function f(x) {
if (!x) {
x = 'default_value';
}
}
Claro, se eu usar esse truque e um colega o vir, eles poderão aprender alguma coisa. Mas o caso é que eles veem isso como "tentando ser esperto".
Então, devo diminuir o nível do meu código se meus colegas de equipe tiverem um nível inferior ao meu?
teamwork
communication
skills
Florian Margaine
fonte
fonte
Respostas:
Ok, aqui vai minha opinião sobre esse tópico grande e complicado.
Prós por manter seu estilo de codificação:
x = x || 10são idiomáticas no desenvolvimento de JavaScript e oferecem uma forma de consistência entre seu código e o código de recursos externos que você usa.Contras por manter seu estilo de codificação:
Minha opinião pessoal
Você não deve diminuir a habilidade do seu código. Você deve escrever um código expressivo, claro e conciso. Se você tiver alguma dúvida sobre o nível de sua equipe, informe-a . As pessoas estão mais do que dispostas a aprender do que você imagina e estão dispostas a adaptar novas construções quando convencidas de que são melhores.
Se eles acham que você está "apenas sendo esperto", tente argumentar. Esteja disposto a admitir que às vezes está errado e, não importa o quê, tente manter os estilos consistentes em todo o ambiente de trabalho. Fazer isso ajudará a evitar hostilidade.
O mais importante é permanecer consistente.
O código de uma equipe deve ser escrito como se uma pessoa o codificasse. Você absolutamente tem que concordar com as diretrizes de codificação. Você deve respeitar essas diretrizes. Se as diretrizes de codificação especificarem que a leitura de parâmetros opcionais deve ser feita da maneira 'menos inteligente', é esse o caminho.
fonte
Comentar bem
Você deve diminuir a habilidade do seu código? Não necessariamente, mas você definitivamente deve aumentar a habilidade de seus comentários . Inclua bons comentários em seu código, especialmente nas seções que você acha que podem ser mais complicadas. Não use tantos comentários que o código se torne difícil de seguir, mas certifique-se de deixar claro o objetivo de cada seção.
A realidade é que ser um pouco mais detalhado com os comentários pode ser útil para os membros da equipe menos habilidosos, mas aqueles com a menor habilidade os ignoram, especialmente se houver muitos, por isso não exagere.
Uma questão de estilo?
O exemplo que você forneceu é um pouco básico, mas também bastante estilístico. Um comentário em torno de cada variável padrão seria bastante tedioso para manter e ler. Em vez disso, atalhos estilísticos ou repetidos ou padrões de código provavelmente devem ser estabelecidos como padrão. Se você acha que algo como esse tipo de parâmetro padrão deve ser entendido por todos e usado sempre, escreva essas idéias e leve-as ao seu líder de equipe. É possível que tudo o que seja necessário para ensinar seus colegas de equipe seja uma reunião simples, na qual você discuta os padrões que propôs.
Como outra resposta já declarada, mantenha-a consistente .
Ensine um homem a pescar ...
Ensinar seus colegas de equipe é provavelmente a melhor maneira de ajudar todos os envolvidos. Deixe claro que, se alguém tiver uma pergunta sobre um pedaço de código com seu nome no log de confirmação ou nos carimbos de data e hora, fique à vontade para perguntar sobre isso. Se sua equipe tiver revisões de código, esta é uma ótima oportunidade para explicar qualquer código bem comentado aos seus colegas de equipe. Se sua equipe não possui revisões de código, por que não? Chegue lá!
Você precisa ter cuidado, no entanto. Você pode nem sempre estar por perto para ensinar as pessoas e até esquecer o que estava tentando fazer em uma determinada seção de código.
Truques "inteligentes"
É importante manter em mente as habilidades de seus colegas de equipe, mas escrever código de manutenção geralmente significa não usar atalhos misteriosos para problemas que possam ter soluções mais comuns. Isso é importante mesmo quando seus colegas de equipe são inteligentes. Você não quer que o código demore muito para compreender ou ter efeitos colaterais sutis, mas importantes, que podem ser perdidos. Em geral, é melhor evitar truques "inteligentes" quando houver alternativas adequadas. Você nunca sabe quem pode precisar manter o código na linha - geralmente as versões mais antigas de nós mesmos não se lembram dos detalhes ou dos motivos desses truques.
Se você acha que deve implementar um truque inteligente, siga pelo menos o próximo conselho ...
BEIJO
Em caso de dúvida, mantenha-o simples . Se o código é simples ou não, não corresponde necessariamente à habilidade do programador, como você imagina. De fato, algumas das soluções mais brilhantes para um problema são as mais simples, e algumas das soluções mais complicadas acabam no TheDailyWTF . Manter seu código simples e conciso pode facilitar a compreensão de algumas das decisões mais inteligentes, mas possivelmente contra-intuitivas.
fonte
Parece haver uma enorme aversão à criação de uma função em JS. Essa aversão faz com que as pessoas tentem ser inteligentes e usar truques ridículos apenas para manter as coisas em uma linha, como uma chamada de função teria sido. Obviamente, o nome da função em uma chamada também funciona como documentação extra. Não podemos anexar um comentário a uma expressão complicada, porque isso seria derrotado, então nós o chamamos de "js idiom" e, de repente, é compreensível.
Javascript é extremamente acessível, a maioria das pessoas não come especificações para o café da manhã como nós. Portanto, eles nunca entenderão quais são as suposições ocultas e os casos extremos de um idioma.
O joe médio não entende isso ou memorizou que é o idioma para o valor padrão. Ambos são prejudiciais, na verdade, o último é ainda mais prejudicial. Ele não entenderá as suposições e casos extremos aqui. Ele não se importará de ler a especificação e entendê-la sempre.
Quando eu olho para que o código eu ver "se é
nullouundefined, então configurá-lo para esse valor padrão. Embora também irá tratar implicitamente+0,-0,NaN,false, e""valores como não adequados. Vou ter que lembrar que 3 meses a partir de agora, quando que as necessidades mudar. Provavelmente esquecerei. "É extremamente provável que a suposição implícita cause um erro no futuro e, quando sua base de código estiver cheia de truques como esse, não haverá chance de você mantê-los todos em sua mente sempre que estiver pensando sobre o que uma modificação afetará. E isso é para o "JS pro", o joe médio teria escrito o bug, mesmo que os requisitos aceitassem um valor falso, para começar.
Seu novo snippet tem uma sintaxe mais familiar, mas ainda tem o problema acima.
Você pode ir com:
Agora você pode ter uma lógica muito complexa para lidar com casos extremos e o código do cliente ainda parece bonito e legível.
Agora, como você diferencia o recurso de linguagem avançada, como passar uma função como argumento ou como um truque inteligente
|| "default"?Truques inteligentes estão sempre operando sob algumas suposições ocultas que podem ser ignoradas quando o código foi criado inicialmente. Eu nunca terei que modificar um IIFE para outra coisa porque um requisito mudou, ele sempre estará lá. Talvez em 2020 quando eu possa usar módulos reais, mas sim.
| 0ou a versão de culto à carga~~numusada para pisos assume limites inteiros positivos e assinados de 32 bits.|| "default"assume que todos os valores falsos são iguais a não passar um argumento.E assim por diante.
fonte
Você não deve diminuir sua habilidade de programação, mas pode ser necessário ajustar a forma como escreve o código. O objetivo, quase acima de tudo, é tornar seu código claro para as pessoas que precisam lê-lo e mantê-lo.
Infelizmente, pode ser um pouco de julgamento se algum estilo em particular é "inteligente" ou apenas uso avançado. O código da pergunta é um bom exemplo disso - sua solução não é necessariamente melhor que a outra. Alguns argumentam que sim, outros discordam. Como as duas soluções têm desempenho de tempo de execução efetivamente igual (leia-se: o usuário nunca saberá a diferença), escolha o estilo com o qual a equipe como um todo se sente mais confortável.
Em alguns casos, você precisa ensiná-los a melhores maneiras de codificar, mas em outros momentos, você precisa se comprometer por uma questão de clareza.
fonte
Isso já pode ter sido dito em outra resposta, mas eu gostaria de responder a essa pergunta por minhas próprias ordens.
Diretrizes Gerais
Quando você trabalha em equipe, não é o público-alvo de um pedaço de código. Seu público é o desenvolvedor da sua equipe. Não escreva códigos que eles não possam entender sem uma boa razão.
Exemplo Específico
Temos um grande número de scripts perl em nossa base de código. Normalmente, usamos perl apenas para operações muito simples e a grande maioria do código é escrita por desenvolvedores java, portanto, é semelhante ao java. Temos um conjunto de scripts perl e uma estrutura que foi escrita por um 'perl guru' que deixou nossa empresa desde então. Esse código contém muitos dos idiomas perl mais obscuros e nenhum de nossos desenvolvedores, inclusive eu, pode ler esse código perl sem esforço. Muitas vezes o amaldiçoamos por isso. :)
fonte
Se você escreve um bom código, mas acha que seus colegas atuais ou futuros podem ter dificuldade em segui-lo, adicione um breve comentário para explicá-lo.
Dessa forma, você pode ensinar-lhes algo sem insultar sua inteligência individual ou embaraçar ninguém em uma discussão em grupo.
fonte
Eu não chamaria seu exemplo de truque, mas apenas idiomático. Se você deve usá-lo, depende do IMHO, não tanto do nível atual de sua equipe, mas se (pelo menos alguns) seus companheiros de equipe estiverem dispostos a aprender algumas novas expressões idiomáticas. Obviamente, você deve discutir esse tópico com eles e não aplicar esse estilo a eles. E você não deve pedir que aprendam todos os dias 5 coisas novas ou "truques". Mas, honestamente, se você tem apenas colegas de equipe que não estão dispostos a aprender algo novo, mesmo que seja tão simples e pequeno que esse idioma, considere mudar para um time diferente.
fonte
Lendo esta pergunta e as respostas e discussões subsequentes, parece haver dois pontos. O primeiro: é bom usar recursos avançados de idioma? A segunda: como posso fazer isso sem parecer que estou me exibindo?
No primeiro caso, faz sentido usar melhorias e recursos avançados. Por exemplo: em C #, você não precisa usar expressões Linq ou Lambda, mas a maioria das pessoas usa, porque torna o código mais organizado e fácil de entender, uma vez que você realmente sabe o que está fazendo. No começo, parece estranho.
As pessoas se acostumam a padrões e, em muitos casos, usam a maneira definida de fazer as coisas apenas para realizar o trabalho. Sou tão culpado disso quanto o próximo homem. Todos temos prazos. Em alguns aspectos, você é culpado de introduzir novas idéias e novas maneiras de pensar! Isso vem para o segundo ponto e provavelmente é onde você pode encontrar mais resistência.
Para a pessoa que usa o site, eles não se importam com qual estilo é usado, apenas se preocupam com isso. É rápido? Portanto, se não houver vantagem de desempenho no seu caminho, não haverá caminho certo ou errado no exemplo que você fornecer. Seu caminho torna o código mais legível ou não? Isso pode acontecer quando seus colegas estiverem acostumados.
Então, como você introduz essas mudanças? Tente discutir com seus colegas desta maneira: você sabia que essa função pode ser escrita dessa maneira? Revisões de código e programação de pares podem ser bons momentos para permitir a polinização cruzada de idéias. É difícil para mim prescrever o que fazer porque não conheço o ambiente em que você está trabalhando. Acho que alguns programadores podem ser muito defensivos e resistentes a mudanças. Mais uma vez eu fui culpado disso. A melhor maneira de trabalhar com esses tipos de programadores é gastar algum tempo aprendendo o que os faz funcionar, aprender seus antecedentes e comparar e contrastar seus estilos e experiências com os deles. Leva tempo, mas é um tempo bem gasto. Se possível, tente incentivá-los.
fonte
Só não vá trabalhar para a Royal McBee Computer Corp, porque quem pode dizer que você não é o programador inexperiente.
com certeza, é ótimo escrever um código conciso e curto e pode ser útil em um ambiente javascript (bem, até que alguém produza um compilador js para baixar nos navegadores, mas isso é outra história).
o que é importante, porém, é a capacidade do seu código viver além dos poucos minutos que você levou para escrevê-lo. Claro, é rápido e fácil e você pode dividir tudo e seguir em frente, mas se precisar voltar anos depois, é quando você pode pensar em "que muppet escreveu isso" e perceber que era você! (Eu fiz isso, com certeza a maioria das pessoas também ... culpo os prazos excessivamente agressivos, honestamente).
Essa é a única coisa importante a ter em mente, então, enquanto eu diria que sim - vá com esse operador específico, se funcionar e estiver claro, e seus desenvolvedores 'inexperientes' (porém, isso está sendo depreciativo para eles, eu sei bastante de desenvolvedores inexperientes que conhecem todos os operadores e truques ao memorizarem vários tutoriais e referências de páginas da web, escrevem o pior código mesmo sabendo todos os pequenos truques ... pode haver mais do que coincidência)
De qualquer forma, se você pudesse ler a história de Mel , perceberia que os truques não são a melhor coisa para colocar em qualquer código, mesmo que Mel fosse um verdadeiro programador de primeira ordem. Isso coloca qualquer argumento em que alguém diga que pode escrever um bom código e que todos os demais precisam aprender mais para acompanhar.
fonte
Bem, para iniciantes que parece JS básico para mim.
Mas, em geral - você não deve usar hackers inteligentes, parafraseando "a depuração é duas vezes mais difícil que a programação. Se você escrever um código da maneira mais inteligente possível, será por definição incapaz de depurá-lo".
Isso não significa que você deva evitar o código apenas porque outras pessoas não o entenderão - você deve escrever o código da maneira mais clara e consistente possível. Mas seu critério de clareza deve ser "entenderei isso na primeira leitura de um ano", não "alguém pode entender".
Escreva de maneira clara, que você não tem dificuldade em entender e deixe que os outros trabalhem para aumentar suas habilidades - não se prejudique para salvar outros problemas hipotéticos.
fonte
Eu discutia com meus colegas de equipe que tipo de padrões de codificação queremos ter, pois trata-se principalmente de como deve ser feito algo que pode ser feito de várias maneiras para a nossa base de códigos. Se houver um consenso, essa seria minha tentativa inicial de resposta.
Se não houver, provavelmente consideraria que tipo de padrão proposto faz sentido e começaria a colocá-lo em prática assim que o esclarecesse com a gerência e parte da equipe. A idéia aqui é garantir que a gerência esteja de acordo com essa ideia e que eu não esteja apenas fazendo minhas próprias coisas e forçando todos os outros a aceitá-la.
Eu consideraria isso mais como a questão de que tipo de padrões e práticas sua equipe possui, em vez de apenas o nível de habilidade, pois existem várias maneiras de avaliar o código. Quão bem os outros podem manter esse é um desses critérios.
fonte
O problema é que você deseja boa legibilidade da fonte, mas a legibilidade está nos olhos de quem vê.
Eu sugeriria que precisamos de melhores ferramentas para resolver esse problema. Nada complexo, lembre-se, temos a tecnologia para fazer isso há mais de 50 anos. Inclua um analisador no editor e faça com que o editor salve a fonte na forma de sexps (sim, assim como o lisp). Em seguida, a fonte é lida, o editor a analisa em sintática e tipográfica (você sabe, espaços, tabulações, vírgulas), da forma que o usuário preferir.
Dessa forma, você pode digitar e ler
x = x || 10e outros programadores o lerão comoO emacs tem todas as peças para fazer isso facilmente.
fonte
Em vez de emburrecer o código, por que não melhorar a qualidade da equipe? Treinamento, treinamento, educação e práticas de contratação aprimoradas podem fazer muito para garantir a melhoria contínua.
Estatística, apodrecimento do código, recusando-se a melhorar e inovar porque alguém não quer trabalhar no auto-aperfeiçoamento, apenas causam problemas na linha e mais cedo ou mais tarde.
Obviamente, no caso específico que você mostra, você está apenas tentando ser inteligente e deliberadamente escrevendo código ofuscado, o que nunca é uma boa idéia. Em primeiro lugar, o código deve ser legível, prontamente compreensível, não escrito para mostrar o quão inteligente você é em criar algo com o mínimo de instruções possível (casos especiais, exceto casos em que mais instruções levariam a um desempenho inaceitavelmente ruim, nesse caso comentários copiosos são chamados para).
fonte