Uma área de trabalho de desenvolvimento pode parecer ocupada enquanto oculta a única informação que você precisa. O editor, a visualização, o terminal, a documentação e o rastreador de problemas são todos relevantes, mas não são igualmente relevantes em todos os momentos.
Em vez de escolher um layout porque se assemelha à configuração de outra pessoa, trace uma alteração comum do início ao fim. O melhor arranjo para esse loop é um ponto de partida mais útil do que uma grade permanente de cada ferramenta que você usa.
Resposta rápida
Organize as janelas em torno do loop de edição-execução-inspeção. Dê espaço suficiente ao editor, mantenha o resultado próximo e exiba a documentação ou os registros quando ele responder a uma pergunta específica.
Mapeie um pequeno ciclo de desenvolvimento
Faça uma mudança normal: ajuste um formulário, corrija um teste com falha ou inspecione uma transformação de dados. Anote onde você edita, como você executa e onde você inspeciona o resultado. Estas são as superfícies de trabalho que merecem posições convenientes.
Para uma interface baseada em navegador, o loop pode ser editor, terminal, navegador. Para uma ferramenta de linha de comando, pode ser um editor e um terminal com documentação próxima. Para um aplicativo nativo, o resultado pode ser um aplicativo ou simulador em execução. Um único arranjo prescrito não pode se adequar a todos esses aspectos igualmente bem.
Feche as janelas do projeto não relacionadas somente depois de salvar o trabalho necessário. Deixe a tarefa ativa com um conjunto reconhecível de janelas para que você possa saber se o layout está ajudando antes de adicionar mais ferramentas.
Dê ao editor uma largura baseada em conteúdo
Dimensione o editor de acordo com o código e os painéis que você realmente precisa. Uma árvore de arquivos, um segundo painel do editor e uma barra lateral de diagnóstico consomem espaço antes do início do código. Se o arquivo central ficar desconfortável de ler, remova um painel desnecessário ou amplie a janela.
Um layout com rolagem pode preservar a largura escolhida enquanto janelas adicionais são adicionadas à faixa. No Glidro, as predefinições de redimensionamento facilitam a revisão dos tamanhos recorrentes. Escolha uma pequena faixa útil em vez de tentar antecipar todos os arranjos possíveis.
Não resolva um problema de largura de janela diminuindo o texto até que todas as ferramentas caibam. Se o texto for difícil de inspecionar, a densidade visível tornou-se um custo. Mantenha a largura que suporta edição e navegue até a janela de suporte quando necessário.
Coloque o resultado onde você irá inspecioná-lo
Coloque a visualização ao lado do editor quando você os compara com frequência. Se precisar ver os dois simultaneamente, verifique se as larguras combinadas deixam o conteúdo útil visível. Se a visualização precisar de uma janela de visualização ampla, alterne entre visualizações de trabalho completas em vez de forçar uma comparação estreita e enganosa.
A largura da janela do navegador faz parte do teste de uma interface web, portanto, seja explícito sobre o que você está observando. Uma visualização restrita pelo layout da área de trabalho não substitui um teste responsivo deliberado. Separe a pergunta “posso ver meu resultado?” de “testei a janela de visualização correta?”
Para uma segunda exibição, use-a quando a visibilidade contínua ajudar. Mantenha um substituto apenas para laptop para o mesmo projeto, para que o desencaixe não prejudique sua compreensão do fluxo de trabalho.
Dê um trabalho aos terminais e logs
Mantenha o terminal usado para o comando atual próximo ao editor ou resultado. Rotule ou distinga sessões por meio dos próprios recursos do terminal, se seu aplicativo oferecer suporte a eles. Uma fileira de shells visualmente semelhantes torna a navegação espacial menos útil porque o destino permanece ambíguo.
Avançar um log para responder a uma pergunta e depois retornar ao código. Se você precisar observar a saída continuamente durante uma reprodução, dê espaço visível para essa fase. Não presuma que todo processo em segundo plano merece uma janela permanentemente visível.
Decida se terminais integrados ao editor ou janelas separadas são adequados para este projeto. O gerenciador controla as janelas, não todos os painéis internos do editor. Use a navegação do próprio editor para conteúdo dentro dele e controles de janela para transições entre aplicativos.
Proteja o contexto do projeto e a propriedade dos atalhos
Separe projetos não relacionados quando as janelas e terminais do navegador forem muito fáceis de confundir. Um limite de tarefa pode ajudá-lo a reconhecer qual repositório, visualização e notas pertencem um ao outro. Confirme o diretório de trabalho e o ambiente de destino usando as ferramentas do projeto antes de emitir comandos consequentes.
Audite os atalhos da janela em relação ao seu editor e às ligações do terminal. Uma combinação de teclas usada para movimentação de palavras, um comando de terminal ou navegação no editor não deve se tornar uma ação surpresa de layout. Teste a ligação escolhida nos aplicativos reais em primeiro plano e altere a configuração responsável pelo conflito.
Glidro fornece atalhos editáveis e controles de inclusão de aplicativos. Use-os para se adequar às ferramentas de desenvolvimento que você possui e, em seguida, mantenha uma rota de pausa simples quando uma janela especial precisar de tratamento normal. Nosso guia de configuração de codificação do MacBook existente oferece um passo a passo complementar focado em laptop.
Perguntas frequentes
O terminal deve permanecer sempre visível?
Somente quando a produção contínua é importante. Para muitas tarefas, mantê-lo por perto e fácil de focar é suficiente.
Um gerenciador de janelas pode organizar painéis do editor?
O o gerenciador atua no nível das janelas. Use os controles do próprio editor para guias, painéis internos e terminais integrados.
