Traduzido do 日本語 • Ver original Introdução
Olá. Sou TORII, um antigo programador do Colorkrew (doravante chamado de CK).
Bem, hoje gostaria de falar sobre o passado e o presente relacionados à programação da minha parte, que sou um dos três principais (não sei exatamente) da Associação de Idosos de Programação do Colorkrew.
Na verdade, ainda sou um bom lugar para jovens nas associações de idosos do mundo todo em programa, mas recentemente, enquanto o número de engenheiros jovens, iniciantes e enérgicos em nossa empresa aumentou um após o outro, os idosos perderam a cabeça, e antes que eu percebesse, era assim. Era assim quando eu simplesmente sentava. Existem coisas realmente estranhas.
Vamos começar.
Episódio 1 Engenheiros e Programadores
Desde o início da humanidade, muitas pessoas chamadas engenheiros de sistemas lidam com processos a montante, mas nos últimos 10 anos, o número de pessoas que se autodenominam engenheiros e ganham a vida escrevendo programas aumentou consideravelmente.
Não, pode ter sido assim por muito tempo, mas para ser honesto, não sei quando começou a se multiplicar. Como impressão subjetiva, é uma impressão de que aumentou de repente. Isso já é uma parede.
Qual é a diferença entre um engenheiro e um programador?
Acho que comecei a me chamar de engenheiro no início dos anos 2010, mas antes disso, eu me via como programador.
O motivo da mudança foi que, quando escrevi minha posição no meu cartão de visita, me disseram para escrever "produtor" de acordo com as regras da empresa, e como resultado de protestos e ajustes, protestei e ajustei, e quando decidi tomar uma decisão após consultar meu superior, inicialmente disse que queria ser um "programador", mas por algum motivo foi rejeitado, então escrevi relutantemente "engenheiro de software".
Parece que programador é geralmente referido como uma pessoa que só codifica e modifica com base em um documento de design criado por alguém. Ou uma pessoa que não gerencia.
Parece haver uma teoria popular de que engenheiros são pessoas com diploma em engenharia e, na verdade, parece que há países no exterior onde é difícil conseguir emprego na área de TI sem um diploma. Claro, esse diploma não é exigido no Japão. Até mesmo alunos do ensino fundamental podem se chamar de engenheiros.
Isso realmente muda dependendo da indústria, situação e contexto, e hoje em dia há muitas profissões de TI que não escrevem programas, e também são chamadas de engenheiros, então para quem escreve programas, basicamente é uma questão de humor (parece mais incrível dizer engenheiro do que programador), e parece bom pensar nisso como um termo geral que inclui várias ocupações de TI.
Por isso me chamo de engenheiro agora. Mas, no fundo, sou um programador eterno.
Episódio 2 Abas, Espaços e Parênteses
Esta é uma história sobre se deve usar abas ou espaços para indentação do código-fonte. Eu tinha a impressão de que antes havia muitas abas aparte, mas agora a maioria são espaços. Foi resolvido sem saber. Não, estou surpreso.
Sei que o problema das abas é que o layout quebra quando usado para outros fins além de estruturar.
Mas espaço é espaço, e é complicado pressionar espaço/retrocesso N vezes para escrever, e se você cometer um erro no número de vezes, a indentação estará errada. A posição do cursor pode estar desalinhada ao copiar e colar.
Hã? Você só aperta a tecla tab? Esse é o poder do editor (tab suave).
Se você usar um bom editor de programação, quase não haverá problemas. No caso de um editor de programação normal, se você copiar acidentalmente do meio do espaço, uma linha de recuação com um caractere em excesso ou deficiência ocorrerá. Se estiver um caractere errado, você não vai perceber.
O pior é que você só pode usar um editor barato que não tenha uma aba suave, e você precisa apertar o espaço N repetidamente, então fica tão doloroso que você quer xingar: "Quem é a pessoa que me instruiu a usar o espaço indentado?"
Bem, um ambiente assim é raro hoje em dia, então não há problema nenhum com espaço, sim.
Várias vezes por ano, há momentos em que vira uma marca com um excesso ou deficiência parcial de um caractere, mas eu corrigo quando vejo e não me importo muito com sua existência (ah, se você vir, por favor faça um pull request).
Em uma história semelhante, há também uma história sobre onde começar os parênteses das instruções de control, como if e for. Ela é escrita no final da mesma linha que o controle ou na linha seguinte.
Hoje em dia, exceto por algumas linguagens como C#, parece que escrever na mesma linha da frase controle é comum.
Quando comecei a escrever programas, escrevia na mesma linha da instrução control, mas no projeto que fiz logo no início, havia erros frequentes que faziam com que o início e o fim dos parênteses fossem separados. Com esse modo de escrever, você não consegue perceber à primeira vista onde os parênteses estão faltando, são excessivos ou estão indentados.
Bem, estou falando de não escrever declarações de controle que pareçam distantes, mas é o auge da juventude.
O número de rótulos na frase de troca era cerca de 1000, mas foi tão estúpido que ultrapassou isso e um bug misterioso aconteceu.
Então mudei o estilo para escrever o início entre parênteses na próxima linha. Então esses erros idiotas pararam de acontecer. Se não houver parênteses começando na próxima linha, não será recuado, então você pode ver onde está o problema só olhando. É o melhor.
Desde então, tenho escrito assim quando escrevo individualmente.
Mas parece que o mundo hoje não escreve da melhor forma. Acho que o maior fator provavelmente é que não é permitido consumir uma linha só com a linha inicial entre parênteses, mas está cada vez menos provável que parênteses não possam ser lidados (devido ao poder do editor, etc.).
Bem, não importa como você escreva sobre espaço de tabulação ou parênteses, o editor vai corrigir automaticamente de acordo com o formato definido pelo projeto no momento em que você salva, então é um bom momento para escrever em qualquer estilo, desde que você queira.
Notação de Licença do Episódio 3
Quando eu ainda era novato no treinamento para novos recrutas, aprendi a escrever a anotação de licença com o nome da empresa no início do código-fonte durante o treinamento para novos funcionários.
Pela lei japonesa de direitos autorais, você não é obrigado a escrevê-lo, mas eu sabia que deveria escrevê-lo além disso porque ia postar uma descrição do arquivo de qualquer forma.
No entanto, nesta indústria web, ou melhor, Colorkrew, nunca vi código open source ter uma notação de licença sólida, mas o código-fonte que eles escrevem é licenciado. Nunca vi um cabeçalho explicando o conteúdo de um arquivo. (*1)
Parece que não existe costume de escrever sobre isso. No começo, fiquei confuso, mas recentemente comecei a pensar que não preciso escrever sobre isso.
Mesmo que você não escreva, o direito autoral é estabelecido, e se o código-fonte vazar...... Era o que eu pensava.
Mas hoje em dia, acho melhor anexar corretamente o código-fonte dos produtos da sua empresa.
Finalmente
Tenho escrito muitas frases ruins, mas se for popular, pode continuar. Membro da nossa Associação de Idosos do Programa Colorkrew...... Estamos recrutando funcionários de tempos em tempos.
Se você tiver interesse, entre em contato conosco abaixo.
https://recruit.colorkrew.com/
*1) A exceção é um arquivo criado pelo Xcode. Ele cria automaticamente um nome de arquivo e direitos autorais.
Por isso, às vezes, você vê código-fonte gerado pelo Xcode com nome pessoal como Copyright em vez de nome de empresa.
Como o arquivo do projeto Xcode está configurado assim, se você criar código-fonte via Xcode, ele será protegido por direitos autorais dessa pessoa, não importa quem o faça......