Trabalho de organização de um único programador

O autor do material, cuja tradução publicamos hoje, diz que a maioria dos programadores trabalha em equipe. No entanto, em algum momento da carreira, um desenvolvedor pode precisar trabalhar sozinho. O principal escopo das abordagens para a organização do trabalho em produtos de software é projetado especificamente para uso em equipes. Essas abordagens são expressas nas regras adotadas pelas organizações. Tais regras agilizam o trabalho, ajudam os programadores a realizar seu trabalho com rapidez e eficiência. Algo semelhante seria muito útil para os programadores que trabalham por conta própria.


E quem trabalha sozinho? Em que focar, buscando criar um fluxo de trabalho claro e eficiente? Quais princípios e regras a seguir? Sugerimos procurar respostas para essas perguntas juntos.

Sobre programadores solitários

Aqui, falando de “programadores solitários”, quero dizer todos aqueles que trabalham em um ambiente não oficial e não estruturado. Pode ser um único programador ou um pequeno grupo de pessoas envolvidas, digamos, em seu tempo livre, com algum tipo de projeto. Aqui estão alguns exemplos:

• Desenvolvimento de um projeto de código aberto, como um pacote ou algum tipo de biblioteca.
• Projeto pessoal de alguém, que pode ser comercial ou gratuito.
• Freelance.

Todos esses exemplos são unidos pelo fato de que o trabalho de programadores envolvidos em algo semelhante geralmente não é regulado por um determinado conjunto de regras, como as que geralmente existem nas empresas.

Por que um único programador se preocupa com as regras?

As regras, ao aplicá-las ao trabalho independente de programadores em determinados projetos, são importantes por vários motivos. Considere-os.

▍ Regras pessoais e possível trabalho em equipe

Um programador cujo trabalho independente seja bem organizado pode muito bem ingressar em uma determinada equipe. Nesse caso, as chances são boas de que ele se torne um membro valioso dessa equipe. Ou seja, estamos falando sobre o seguinte:

• Se ele ingressou em uma equipe que segue as mesmas regras que ele, não precisará perder tempo tentando se aprofundar nas questões organizacionais. Ele, literalmente, desde o primeiro dia, estará pronto para um trabalho produtivo.
• Se ele se tornou parte de uma equipe, cujas regras são diferentes das que ele está acostumado, não levará muito tempo para aprender essas novas regras. Afinal, ele, acostumado a organizar racionalmente seu trabalho, é guiado por certas idéias gerais, que, com certeza, são semelhantes às que subjazem às regras da equipe. Como resultado, ele pode alcançar rapidamente um alto nível de produtividade do trabalho.
• Se ele ingressou em uma equipe na qual não existem regras, é claro que, dependendo da equipe, ele pode oferecer a ela sua própria visão da organização do trabalho dos programadores, o que pode melhorar o trabalho dessa equipe. Se os membros de uma equipe mal organizada se recusam a mudar alguma coisa, então esta é uma ocasião para pensar em deixar essa equipe.

Como resultado, um programador solitário que organiza racionalmente seu trabalho, em qualquer caso, é o vencedor.

▍ Regras e nível profissional de um programador

O desenvolvimento de software não é apenas um processo de escrever código. Existem muitos detalhes responsáveis ​​por transformar uma ideia em um projeto finalizado e, em seguida, mantê-la em condições de funcionamento. A introdução de técnicas avançadas de desenvolvimento de software no fluxo de trabalho pessoal ajudará um programador a seguir com confiança o objetivo para o qual o projeto está sendo criado e evitar situações em que tudo parece tão confuso que não está claro para onde seguir em frente.

Se você, como eu, gosta de programar, sempre será tentado a iniciar um novo projeto e imediatamente, sem olhar para trás, se apressará no abismo de escrever código. Mas a experiência me diz que, se eu tenho um certo plano de trabalho de alto nível, sem prejudicar a flexibilidade de que o desenvolvimento individual é diferente, isso ajuda a evitar muitos problemas de diferentes escalas.

Fale sobre as melhores práticas para desenvolvimento de software.

Siga as regras que descrevem seu fluxo de trabalho.

"Fluxo de trabalho" é uma sequência de etapas que você precisa seguir no processo de conversão de uma ideia em um produto acabado. Aqui estão algumas perguntas que devem ser respondidas pelas regras que regem o processo de trabalho em um produto de software:

• Quando se decide fazer uma alteração em um produto - qual é a ordem de sua implementação?
• Como é a transferência de novas versões do produto para os usuários?
• Como as alterações do produto são rastreadas?
• Como é organizado o monitoramento de mensagens de erro e problemas encontrados pelos usuários?
• Qual é o processo de planejar novos recursos do produto?

Por que regular tudo isso, direcioná-lo para algum tipo de estrutura, se parece que o trabalho em projetos será muito mais rápido sem um fluxo de trabalho específico? Não é mais fácil imaginar todo o "fluxo de trabalho" desta forma: "basta escrever o código e enviá-lo para o ramo principal"? De fato, à medida que a complexidade do projeto aumenta, a presença de regras claras simplifica a definição do que precisa ser feito no trabalho desse projeto e, consequentemente, sem maiores reflexões, permite que você se concentre nesses assuntos. Ao trabalhar em equipe, o fluxo de trabalho se transforma em algo como uma correia transportadora que melhora a eficiência de cada membro da equipe.

Agora vamos falar sobre como organizar o processo de trabalho em um produto de software.

TrackUtilizar rastreadores de tarefas

Aqui você encontrará os mecanismos das plataformas nas quais você coloca o código útil - GitHub, Gitlab, BitBucket e outros. As tarefas ajudam a acompanhar as mensagens de erro, solicitações para adicionar novas funcionalidades ao produto e organizar informações sobre alterações importantes no projeto. Deve-se notar que, quando você digita o título e a descrição da tarefa, obriga a formular claramente pensamentos e descrever claramente o problema e as possíveis maneiras de resolvê-lo. A idéia de usar tarefas pode ser desenvolvida com a introdução de uma ferramenta de gerenciamento de tarefas como o Trello ou o GitHub Projects em seu fluxo de trabalho.


Desafio

RequestsUsar solicitações pull

Muitos desenvolvedores preferem enviar alterações, usando solicitações push, diretamente para a ramificação principal de seu projeto, chamada mestre. No entanto, a abordagem para fazer alterações no código do projeto usando solicitações pull tem algumas vantagens importantes. Primeiramente, essas consultas facilitam a análise de alterações relacionadas à introdução de um novo recurso ou correção de bug no projeto e como elas, após a fusão com a base de código principal, o afetam. Além disso, se as solicitações pull estiverem associadas a tarefas do rastreador de tarefas, seu uso facilita a compreensão de como o projeto está sendo desenvolvido, eliminando a necessidade de descobrir ao ler o código.


Detalhes da solicitação Pull

▍ Execute revisões de código personalizadas

A recomendação para revisar o código nativo pode parecer estranha, mas, apesar disso, os desenvolvedores devem analisar seu próprio código como se alguém o tivesse escrito. Alguns programadores aconselham fazer uma solicitação pull, distrair por um tempo e depois checá-la antes de incluí-la no código. A realização de verificações de código realizadas fora do ambiente usual para o programador na forma de seu IDE permite que você dê uma nova olhada no código. Isso ajuda a encontrar erros e detectar no código algo que em condições normais pode ser ignorado. As revisões de código, além disso, forçam o desenvolvedor a fazer várias perguntas: “Por que essa oportunidade foi implementada dessa maneira? O que poderia ser feito de errado aqui? Existe uma maneira mais eficiente de resolver esse problema? ”

▍ Mantenha um histórico significativo do projeto no repositório

Tente fazer confirmações como se estivesse trabalhando em equipe. Ou seja - evite confirmações muito grandes, tente garantir que as mensagens das confirmações descrevam clara e claramente seu significado. Assim como no caso de revisões de código, escrever mensagens de confirmação de alta qualidade obriga o desenvolvedor a pensar com cuidado sobre suas ações, fazendo a si mesmo perguntas como as seguintes: “O que estou tentando alcançar com esse commit? Como estou tentando conseguir isso? ”

Pode haver situações em que você pode se desviar das regras. Por exemplo, você pode decidir que, para não desacelerar o trabalho devido a insignificantes, você, ao fazer alterações muito pequenas no código (como corrigir erros de digitação), pode, sem movimentos desnecessários, enviar uma solicitação por push diretamente para a ramificação principal.

Independentemente das regras subjacentes ao seu fluxo de trabalho, o mais importante é que tudo o que você faz é feito intencionalmente, e não por coincidência. Projetos bem-sucedidos não surgem por si mesmos: são criados com amor e carinho. As ações executadas intencionalmente envolvem determinados períodos de análise da situação, análise de casos complexos e reflexão sobre como, por exemplo, com a ajuda de quais ferramentas você pode lidar com elas.

Criar componentes e módulos reutilizáveis

Implemente os princípios de SECO , SÓLIDO e PRIMEIRO . Crie programas a partir de componentes atômicos pequenos, encapsulados e adequados para reutilização. Mantenha esses componentes atualizados, monte-os em coleções usando plataformas apropriadas como o Bit . Tudo isso ajudará você a aumentar a velocidade e a qualidade do trabalho.

Escrever documentação

Documentação ... Para muitos, esse é um ponto delicado. Muitas pessoas sabem que os projetos de software precisam de documentação. Aqueles que escrevem boa documentação já são muito menos e menos ainda gostam de fazer isso. Depois que o próximo estágio fascinante de escrever o código for concluído, a necessidade de documentá-lo geralmente se torna uma tarefa que você apenas deseja esquecer. Como, na forma de textos simples, expressar todos os meandros do código do programa?

E, a propósito, é apropriado fazer uma pergunta sobre por que tudo isso é necessário. O fato é que as pessoas tendem a cometer erros. Podemos esquecer algo. Temos dias ruins. Ou, trabalhando em um determinado projeto, podemos simplesmente continuar trabalhando em outra coisa. A documentação permite capturar conhecimento sobre o código, que, caso contrário, estará vinculado a uma determinada pessoa. A documentação do código também ajuda os desenvolvedores a ver o código em termos mais gerais do que o disponível ao escrevê-lo e a entender mais claramente os objetivos dos projetos.

As idéias a seguir o ajudarão a escrever uma boa documentação.

• Entenda que sua documentação não é como um livro. A documentação não deve constituir um exemplo de alta arte literária. Ninguém a avaliará em termos de seu mérito artístico. Não tente explicar tudo nele. Esforce-se para ser claro e compreensível. Às vezes, apenas algumas frases são suficientes para descrever algo.
• Escrevendo documentação antes de escrever código. Documente as interfaces dos seus módulos, descreva a ordem do trabalho deles do ponto de vista de um observador externo. Essa documentação desempenhará o papel das especificações do produto e o ajudará no processo de desenvolvimento.
• Escrevendo documentação após escrever código. Aqui, novamente, vale a pena aderir à posição de "observador externo". O que é importante no fragmento de código descrito? O que você precisa saber sobre o uso (ou contribuir para o seu desenvolvimento?). As especificações especificadas pela documentação criada antes da gravação do código durante o desenvolvimento estão sujeitas a alterações. Portanto, é importante verificar essa documentação quanto à conformidade com o estado real das coisas após a conclusão do trabalho.
• Escrevendo documentação no processo de escrever código. Essa abordagem da documentação é principalmente aplicável a algo como comentários adicionados ao código durante o desenvolvimento. Existem muitos materiais sobre esse tópico, então não entrarei em detalhes aqui.
• Documentação e "módulos". Todos os princípios acima se aplicam aos módulos. Aqui, o conceito de "módulo" é usado em um sentido bastante amplo. Isso pode ser uma função, uma classe, uma nova oportunidade, uma mudança no comportamento de um programa, de fato, um determinado módulo de programa ou todo o projeto. Se a documentação desses “módulos” parecer um desafio muito grande, tente dividi-los em partes menores. Ou, se for mais fácil pensar em categorias mais gerais, considere escrever documentação para os blocos maiores do projeto.

Comunique-se com clientes e pessoas envolvidas no desenvolvimento de produtos junto com você

Aqui, o que chamamos de "comunicação" se aplica principalmente a situações em que um projeto é desenvolvido por uma equipe pequena ou feito sob encomenda.

Por que isso é necessário? O fato é que a transparência do trabalho leva a um aumento da responsabilidade de seus artistas. Quando você sabe que precisa contar a alguém (um membro da equipe ou representante do cliente), ajuda você a ter mais cuidado com o que está fazendo. É por isso que muitas empresas praticam reuniões curtas nas quais os funcionários relatam seu trabalho.

Além disso, muitas vezes um membro da equipe se depara com um problema difícil para ele, que pode ser facilmente resolvido simplesmente discutindo-o com um cliente ou com outro membro da equipe. Eu já perdi a conta, relembrando os casos em que realmente deixei minhas mãos, tentando entender por que o que escrevi não funciona. E a razão disso foi que outro membro da equipe fez alterações no projeto que interferiram no meu código. Para entender isso, bastava levar o problema à discussão pública.

Aqui estão algumas diretrizes para a comunicação com os clientes e com os membros da equipe do programador.

• Se você encontrar um problema inesperado - informe os membros da equipe ou o representante do cliente.
• Informe regularmente o cliente sobre o andamento do projeto. Ao mesmo tempo, tente que essas informações não estejam vinculadas apenas a problemas técnicos.
• Notifique a equipe de alterações no plano.
• Tente organizar um ambiente conveniente para a comunicação, que, por exemplo, permita que qualquer membro da equipe descubra rapidamente o que outra pessoa está fazendo. Você pode fazer isso usando uma variedade de ferramentas, digamos - pode ser WhatsApp, email, Slack ou qualquer outra coisa que se adapte à sua situação.

Em geral, pode-se observar que você deve tentar garantir que a interação entre todas as partes interessadas seja organizada de maneira conveniente e simples, de modo que, por assim dizer, o "ciclo de feedback" funcione sem demora. Isso ajuda a organizar um ambiente de trabalho saudável e produtivo.

Organizar um sistema de monitoramento

O monitoramento no campo do desenvolvimento de software é uma questão muito importante. Os computadores são propensos a falhas. Durante a implantação do projeto, ocorrem erros. A supervisão dos desenvolvedores leva ao fato de que os programas que parecem ter passado em todas as verificações possíveis e colocados com êxito na operação caem com exceções. É por isso que o desenvolvedor precisa cuidar do sistema de monitoramento do programa. Isso facilitará a resolução de problemas que possam surgir em diferentes estágios do ciclo de vida do produto. Os dados de monitoramento do programa são uma parte do “loop de feedback” mencionado acima. O monitoramento fornece ao programador uma conexão com a realidade, com o ambiente em que seus programas funcionam.

Aqui estão algumas sugestões para monitorar como os programas se comportam:

• Salve logs e resultados da análise automática de código. Sinta-se à vontade para usar o console.log () onde for necessário.É melhor depositar muitas informações do que poucas. No entanto, tente encontrar um "meio termo" para que os logs de seus programas não contenham detalhes desnecessários sobre o trabalho deles. Isso facilitará a localização de informações importantes nos logs.
• Descubra para onde vão os logs de seus aplicativos e configure os mecanismos que tornam mais conveniente trabalhar com eles. A função dos "mecanismos" mencionados acima pode ser qualquer coisa - desde o logon no servidor usando SSH e a exibição dos eventos mais recentes registrados no log, até algo como usar a pilha ELK. O mais importante é saber onde os logs do aplicativo são gerados pelo console.log () ou por qualquer outro meio.
• Não ignore exceções. , , , , «» , «» catch, . . , - API , ( — ), 404. , , . , , , , . , API .
• . , , , . , , . , . , .

. console.log(), . , Sentry, Bugsnag Elastic APM. — , , .

, ,

, , .
, « »

, , , . , . - , , - , . , , , , , , .

, , , . , , , , , . , , , ( A/B- ). «» — , , .

. , . — , « — — ».

. , , . , UTC-. , .

, UTC. , , , 5:30 pm, 5:30 pm UTC. , . , . ? , . .

, , , — , . , , , . «5 » «2 ». , , , .

. , . , , , , , . , , .

Sumário

, , — , . ( ), , , . , , ( , ), , . , , . , , , , .

Caros leitores! , «-»?