Social Icons

^^

sábado, 9 de abril de 2011

Como ser um programador: um breve resumo

Competências Pessoais

Aprenda a depurar

A depuração é a pedra angular de ser um programador. O primeiro significado do verbo para depurar é eliminar os erros, mas o significado que realmente importa éver na execução de um programa de examiná-la . Um programador que não é possível depurar efetivamente é cego.

Idealistas que acreditam que o desenho, ou análise, ou teoria da complexidade, ou outros enfeites, são mais fundamentais não estão funcionando programadores. O programador de trabalho não vivemos em um mundo ideal. Mesmo se você for perfeito, você está cercado por e deve interagir com o código escrito por grandes empresas de software, as organizações como o GNU, e seus colegas. A maior parte deste código é imperfeito e imperfeita documentado. Sem a capacidade de ganhar visibilidade para a execução desse código o menor solavanco vai jogá-lo permanentemente. Muitas vezes, essa visibilidade só pode ser adquirida através da experimentação, ou seja, a depuração.

A depuração é sobre o funcionamento dos programas, não os próprios programas. Se você comprar algo de uma empresa de software grandes, normalmente você não consegue ver o programa. Mas ainda vai surgir locais onde o código não está de acordo com a documentação (bater a máquina inteira é um exemplo comum e espectacular), ou quando a documentação é mudo. Mais comumente, você cria um erro, examine o código que você escreveu e não têm idéia de como o erro pode estar ocorrendo. Inevitavelmente, isso significa alguma suposição que você está fazendo não é totalmente correcta, ou alguma condição que surge você não antecipou. Às vezes, o truque mágico de olhar para as obras do código fonte. Quando não, você deve depurar.

Para obter visibilidade para a execução de um programa que você deve ser capaz de executar o código e observar algo sobre ele. Às vezes isso é visível, como o que está sendo exibido em uma tela, ou o intervalo entre dois eventos. Em muitos outros casos, envolve coisas que não são destinadas a ser visíveis, como o estado de algumas variáveis ​​dentro do código, quais linhas de código estão realmente sendo executado, ou se certas afirmações realizar através de uma estrutura de dados complexas. Essas coisas ocultas devem ser revelados.

As formas mais comuns de olhar para o " entranhas "de um programa em execução podem ser classificados como:

  • Usando uma ferramenta de depuração,

  • Printlining --- Fazendo uma modificação temporária para o programa, normalmente adicionando as linhas que a informação de impressão e

  • Log --- Criando uma janela permanente na execução de programas sob a forma de um log.

ferramentas de depuração são maravilhosos quando são estáveis ​​e disponíveis, mas o printlining e exploração são ainda mais importantes. ferramentas de depuração, muitas vezes ficam para trás no desenvolvimento da linguagem, de modo a qualquer momento eles podem não estar disponíveis. Além disso, porque a ferramenta de depuração pode sutilmente alterar a forma como o programa executa-lo pode não ser prático. Finalmente, existem alguns tipos de depuração, como a verificação de uma afirmação contra uma estrutura de dados de grande porte, que necessitam de escrever código e alterar a execução do programa. É bom saber como usar ferramentas de depuração quando eles são estáveis, mas é fundamental ser capaz de empregar os outros dois métodos.

Alguns novatos medo de depuração quando requer a modificação do código. Isso é compreensível --- é um pouco como a cirurgia exploratória. Mas você tem que aprender a cutucar o código e fazê-lo pular, você tem que aprender a experimentar nele, e entender que nada do que você temporariamente fazer para que irá torná-lo pior. Se você sente este medo, procure um mentor --- perdemos um monte de bons programadores no início delicada de seu aprendizado para esse temor.

Como Depurar Dividindo o espaço do problema

A depuração é divertido, porque ela começa com um mistério. Você acha que deveria fazer algo, mas em vez disso, faz outra coisa. Nem sempre é tão simples assim --- nenhum exemplo que posso dar será artificial em comparação com o que por vezes acontece na prática. Depuração exige criatividade e engenhosidade. Se houver uma única chave para a depuração é usar a dividir e conquistar técnica sobre o mistério.

Suponha, por exemplo, você criou um programa que deveria fazer dez coisas em uma seqüência. Ao executá-lo, ele trava. Desde que você não programá-lo para falhar, você tem agora um mistério. Ao olhar para fora na saída, você vê que os primeiros sete coisas na seqüência foram executados com êxito. Os três últimos não são visíveis a partir da saída, agora o mistério é menor: " Ele caiu na coisa # 8, # 9 ou # 10. "

Você pode criar uma experiência para ver que coisa que ele caiu na? Claro que sim. Você pode usar um depurador ou podemos acrescentar declarações PrintLine (ou o equivalente em qualquer língua que você está trabalhando) depois # 8 e # 9. Ao executá-lo novamente, o nosso mistério será menor, como " Ele caiu na coisa # 9. ' Acho que tendo em mente exatamente o que o mistério é em qualquer ponto do tempo ajuda a manter um foco. Quando várias pessoas estão trabalhando juntos sob pressão em um problema, é fácil esquecer que o mistério mais importante é.

A chave para dividir e conquistar como uma técnica de depuração é o mesmo que é para o projeto algoritmo: enquanto você faz um bom trabalho, dividindo o mistério no meio, você não terá que dividi-lo muitas vezes, e você vai ser depuração rapidamente. Mas o que está no meio de um mistério? E é aí que a verdadeira criatividade ea experiência vem dentro

Para um iniciante verdade, o espaço de todos os erros possíveis parece cada linha do código-fonte. Você não tem a visão que você vai se desenvolver mais tarde para ver as outras dimensões do programa, como o espaço de linhas de execução, a estrutura de dados, o gerenciamento de memória, a interação com o código de estrangeiros, o código que é arriscado, e os código que é simples. Para o programador experiência, essas outras dimensões formam um modelo imperfeito, mas muito útil mental de todas as coisas que podem dar errado. Tendo esse modelo mental é o que ajuda a encontrar a meio do mistério de forma eficaz.

Depois de ter dividido uniformemente o espaço de tudo o que pode dar errado, você deve tentar decidir em que espaço reside o erro. No caso simples, onde o mistério é: " Qual a linha desconhecida único acidente faz meu programa? ", você pode se perguntar: ' É a linha desconhecida executado antes ou depois da linha que julgo ser executado na volta da metade do executar o programa? " Normalmente, você não será a sorte de saber que o erro existe em uma única linha, ou até mesmo um único bloco. Muitas vezes, o mistério vai ser mais parecido com: " há um indicador no mesmo gráfico que aponta para o errado, nó ou meu algoritmo que soma as variáveis ​​no gráfico que não funciona. Ou ' Nesse caso, você pode ter que escrever um pequeno programa para verificar se os ponteiros no gráfico são todos corretos, a fim de decidir qual parte do mistério subdivididos pode ser eliminado.

Como remover um erro

Eu intencionalmente separou o ato de examinar a execução de um programa do ato de corrigir um erro. Mas, claro, de depuração também significa remover o bug.Idealmente, você terá um perfeito entendimento do código e vai chegar a um ' a-ha! " momento em que você vê perfeitamente o erro e como corrigi-lo. Mas desde que o seu programa, muitas vezes utilizam sistemas insuficientemente documentados em que você não tem visibilidade, nem sempre isso é possível. Em outros casos, o código é tão complicada que o seu entendimento não pode ser perfeito.

Na fixação de um bug, você quer fazer a mais pequena alteração que corrige o bug. Você pode ver outras coisas que precisam ser melhoradas, mas não corrigir esses, ao mesmo tempo. Tentativa de empregar o método científico de mudar uma coisa e apenas uma coisa de cada vez. O melhor processo para isso é ser capaz de facilmente reproduzir o bug, em seguida, colocar seu reparo no local, e, em seguida, execute novamente o programa e observe que o bug não existe mais. Claro que, às vezes mais de uma linha deve ser mudado, mas você ainda deve conceitualmente aplicar uma única mudança atômica para corrigir o erro.

Às vezes, existem realmente alguns bugs que se parecem com um. É até você para definir os erros e corrigi-los um de cada vez. Às vezes não está claro o que o programa deveria fazer ou o que o autor original pretendia. Neste caso, você deve exercer a sua experiência e julgamento e atribuir o próprio significado do código.Decidir o que deve fazer, e comentá-lo ou esclarecê-lo de alguma forma e, em seguida, faça o código em conformidade com o seu significado. Este é um nível intermediário ou avançado que às vezes é mais difícil do que escrever a função original, em primeiro lugar, mas o mundo real é por vezes confuso. Você pode ter que consertar um sistema que você não pode reescrever.

Como depurar usando um log

Log é a prática de escrever um sistema de forma que ela produza uma seqüência de registros informativos, chamado de log . Printlining é apenas produzir um, geralmente temporária, log simples. Os principiantes devem compreender e utilizar os logs, pois seu conhecimento da programação é limitada, arquitetos de sistema deve entender e usar os logs, devido à complexidade do sistema. A quantidade de informação que é fornecida pelo diário deve ser configurável, de preferência, enquanto o programa está sendo executado. Em geral, os registros oferecem três vantagens básicas:

  • Os registros podem fornecer informações úteis sobre os erros que são difíceis de reproduzir (como os que ocorrem no ambiente de produção, mas que não podem ser reproduzidas no ambiente de teste).

  • Os registros podem fornecer estatísticas e dados relevantes para o desempenho, como o tempo que passa entre as declarações.

  • Quando configurável, registros permitem que as informações gerais a serem capturados, a fim de depurar imprevistos problemas específicos sem ter de modificar e / ou redistribuir o código apenas para lidar com esses problemas específicos.

O montante a saída para o log é sempre um compromisso entre as informações e concisão. Demasiada informação faz com que o log caro e produz rolar a cegueira, o que torna difícil encontrar a informação que você precisa. Muito pouca informação e não pode conter o que você precisa. Por esta razão, fazendo o que está de saída configurável é muito útil. Normalmente, cada registro no log irá identificar sua posição no código-fonte, o segmento que executa-lo se for o caso, o tempo preciso de execução, e, comumente, uma útil informação adicional, como o valor de alguma variável, o quantidade de memória livre, o número de objetos de dados, etc Estas declarações de registro são espalhados por todo o código-fonte, mas são particularmente nos pontos de maior funcionalidade e em torno do código arriscado. Cada declaração pode ser atribuído um nível e apenas um registro de saída se o sistema está configurado para a saída desse nível. Você deve projetar as declarações de registo para resolver os problemas que se antecipa. Antecipar a necessidade de medir o desempenho.

Se você tiver um registro permanente, printlining agora pode ser feito em termos de registros de log, e algumas das declarações de depuração provavelmente será permanentemente adicionados ao sistema de registro.

Como entender os problemas de desempenho

Aprender a compreender o desempenho de um sistema de execução é inevitável, pela mesma razão que a aprendizagem é depuração. Mesmo se o código perfeitamente entender precisamente o custo do código que você escreve, seu código irá fazer chamadas para outros sistemas de software que têm pouco controle sobre ou visibilidade. No entanto, na prática, problemas de desempenho são um pouco diferente e um pouco mais fácil do que a depuração em geral.

Suponha que você ou seus clientes consideram um sistema ou subsistema a ser demasiado lento. Antes de tentar torná-lo mais rápido, você deve construir um modelo mental do porquê ele é lento. Para isso você pode usar uma ferramenta de análise ou um registro bom para descobrir onde o tempo ou outros recursos estão sendo realmente gasto. Há um famoso ditado que 90% do tempo será gasto em 10% do código. Eu acrescentaria a isso a importância da entrada custa / saída (I / O) para problemas de desempenho. Muitas vezes, a maior parte do tempo é gasto em I / O, de uma forma ou de outra. Encontrar o cara que eu / O e os 10% caro do que o código é um bom primeiro passo para a construção de seu modelo mental.

Existem muitas dimensões para o desempenho de um sistema de computador, e muitos recursos consumidos. O primeiro recurso é a medida de parede - relógio , o tempo total que passa para o cálculo. Log-relógio de parede é particularmente valioso porque pode informar sobre as circunstâncias imprevisíveis que surgem em situações em que outros perfis é impraticável. No entanto, isto nem sempre representa a imagem inteira. Às vezes, algo que demora um pouco mais, mas não queimar o processador segundo muitos, assim será muito melhor no ambiente de computação que você realmente tem de lidar. Da mesma forma, a memória, largura de banda de rede, banco de dados ou acessa outro servidor poderá, no final, ser muito mais caro do que o segundo processador.

Contenção de recursos partilhados que são sincronizados podem causar impasse e da fome. O impasse é a impossibilidade de prosseguir por causa de sincronização impróprio ou demandas de recursos. A fome é a falta de agendar uma componente corretamente. Se ela pode ser antecipada em todas, é melhor ter uma forma de medir esta afirmação a partir do início de seu projeto. Mesmo que essa afirmação não ocorre, é muito útil para ser capaz de afirmar que com confiança.

Como corrigir problemas de desempenho

A maioria dos projetos de software podem ser feitas com pouco esforço 10 a 100 vezes mais rápido do que eles são o que são os primeiros lançados. De acordo com o tempo de pressão do mercado, é sábio e eficaz para escolher uma solução que começa o trabalho feito de forma simples e rápida, mas menos eficiente do que qualquer outra solução. No entanto, o desempenho é uma parte da usabilidade, e muitas vezes deve, eventualmente, ser considerada com mais cuidado.

A chave para melhorar o desempenho de um sistema muito complicado é analisar bem o suficiente para encontrar os pontos de estrangulamento , ou em locais onde a maioria dos recursos são consumidos. Não há muito sentido na otimização de uma função que representa apenas 1% do tempo de computação. Como regra geral, você deve pensar cuidadosamente antes de fazer qualquer coisa a não ser que você acha que vai tornar o sistema ou uma parte significativa do mesmo, pelo menos, duas vezes mais rápido. Geralmente, há uma maneira de fazer isso. Considere o teste de esforço e garantia de qualidade que sua mudança vai exigir. Cada mudança traz uma carga de ensaio com ela, por isso, é muito melhor ter um grande poucas alterações.

Depois de ter feito um incremento de duas vezes em alguma coisa, você precisa de, pelo menos, repensar e talvez reanalisar a descobrir o próximo gargalo-mais-caras do sistema, e ataque que para conseguir outro incremento de duas vezes.

Muitas vezes, os gargalos de desempenho será um exemplo de contagem de vacas contando pernas e dividir por quatro, em vez de contar as cabeças. Por exemplo, eu tenho feito erros como deixar de fornecer um sistema de banco de dados relacional com um bom índice em uma coluna eu olho para um monte, o que provavelmente fez pelo menos 20 vezes mais lento. Outros exemplos incluem fazer desnecessária I / O em laços internos, deixando na depuração de declarações que não são mais necessários, alocação de memória desnecessária, e, inexperiente, o uso particular das bibliotecas e outros subsistemas que são muitas vezes mal documentado no que diz respeito ao desempenho. Este tipo de melhoria é às vezes chamado de frutas mais baixas , o que significa que ele pode ser facilmente escolhida para fornecer algum benefício.

O que você faz quando você começar a correr fora de frutas mais baixas? Bem, você pode chegar mais alto, ou cortar a árvore para baixo. Você pode continuar a fazer pequenas melhorias ou você pode seriamente redesenhar um sistema ou subsistema. (Esta é uma grande oportunidade para usar suas habilidades como um bom programador, não só no novo design, mas também convencer o seu patrão que esta é uma boa idéia.) No entanto, antes de defender o redesenho de um subsistema, você deve perguntar se ou não a sua proposta irá fazê-lo de cinco a dez vezes melhor.

Como Otimizar Loops

Às vezes, você vai encontrar loops, ou funções recursivas, que levam um longo tempo para executar e são pontos de estrangulamento em seu produto. Antes de tentar fazer o loop um pouco mais rápido, mas gastar alguns minutos ponderando se existe uma maneira de removê-lo totalmente. Será que um algoritmo diferente fazer? Você poderia calcular que, enquanto algo de computação mais? Se você não consegue encontrar um caminho em torno dela, então você pode otimizar o loop.Isto é simples, fora o material se mover. No final, isso vai exigir não apenas ingenuidade, mas também uma compreensão da despesa de cada tipo de afirmação e de expressão. Aqui estão algumas sugestões:

  • Remover operações de ponto flutuante.

  • Não alocar novos blocos de memória desnecessariamente.

  • constantes Dobre juntos.

  • Move I / O em um buffer.

  • Tente não se dividir.

  • Tente não fazer typecasts caro.

  • Mover um ponteiro ao invés de recalcular os índices.

O custo de cada uma dessas operações depende do seu sistema específico. Em alguns compiladores de sistemas e hardware de fazer essas coisas para você. Claro, o código é mais eficiente que o código que requer uma compreensão de uma determinada plataforma.

Como lidar com a E / S de Despesa

Para um monte de problemas, os processadores são rápidos em comparação com o custo de se comunicar com um dispositivo de hardware. Esse custo é geralmente abreviada E / S, e podem incluir custos de rede, disco I / O consultas, banco de dados, arquivo I / O, e outra utilização de alguns hardwares não muito perto do processador. Portanto, a construção de um sistema rápido que muitas vezes é mais uma questão de melhorar a I / O de melhorar o código em algum laço apertado, ou mesmo a melhoria de um algoritmo.

Existem duas técnicas fundamentais para a melhoria muito I / O: cache e representação. O cache é evitar I / O (geralmente evitando a leitura de algum valor abstrato), armazenando uma cópia desse valor localmente de modo nenhum I / O é realizada para obter o valor. A primeira chave para o cache é tornar claro quais dados é omestre e que são exemplares . Há somente um mestre --- período. Cache traz consigo o perigo de que a cópia é às vezes pode não reflectir as alterações ao mestre instantaneamente.

Representação é a abordagem da tomada de I / O mais barato em representação de dados mais eficiente. Isso é muitas vezes em tensão com outras demandas, como a legibilidade humana e portabilidade.

Representações muitas vezes pode ser melhorada por um fator de duas ou três das suas primeiras implementações. Técnicas para fazer isso incluem o uso de uma representação binária em vez de um que seja legível, transmitindo um dicionário de símbolos, juntamente com os dados de forma que símbolos de comprimento não tem que ser codificada, e, ao extremo, coisas como a codificação de Huffman.

Uma terceira técnica que às vezes é possível a melhoria da localidade de referência, empurrando a computação mais perto dos dados. Por exemplo, se você estiver lendo alguns dados de um banco de dados e algo simples de computação a partir dele, como um somatório, para tentar obter o servidor de banco de dados para fazer isso por você. Isso é altamente dependente do tipo de sistema que você está trabalhando, mas você deve explorá-lo.

Como gerenciar a memória

A memória é um recurso precioso que você não pode dar ao luxo de ficar sem. Você pode ignorá-la por um tempo, mas eventualmente você terá que decidir como gerenciar a memória.

Espaço que precisa persistir para além do escopo de uma única sub-rotina é muitas vezes chamada pilha alocada . Um pedaço de memória é inútil, portanto, de lixo, quando nada se refere a ele. Dependendo do sistema que você usa, você pode ter que explicitamente desalocar memória mesmo quando ele está prestes a se tornar lixo. Mais frequentemente do que você pode ser capaz de usar um sistema que fornece um coletor de lixo . Um coletor de lixo de lixo avisos e libera seu espaço sem qualquer ação exigida pelo programador. A coleta de lixo é maravilhoso: ele reduz erros e aumenta a brevidade e concisão de código mais barato. Use-o quando puder.

Mas mesmo com a coleta de lixo, você pode preencher toda a memória com o lixo. Um erro clássico é usar uma tabela de hash como um cache e se esqueça de remover as referências na tabela de hash. Como a referência continua a ser, o referente é noncollectable mas inútil. Isso é chamado de fuga de memória . Você deve procurar e corrigir vazamentos de memória mais cedo. Se você tem memória de longa duração sistemas nunca pode ser esgotado em testes, mas será esgotado pelo usuário.

A criação de novos objetos é moderadamente caro em qualquer sistema. Memória alocada diretamente nas variáveis ​​locais de uma sub-rotina, no entanto, é geralmente mais barato, porque a política para libertá-la pode ser muito simples. Você deve evitar a criação desnecessária de objetos.

Um caso importante ocorre quando você pode definir um limite superior sobre o número de objetos que você vai precisar de uma só vez. Se esses objetos ocupam todos a mesma quantidade de memória, você pode ser capaz de atribuir um único bloco de memória, ou um tampão, para mantê-los todos. Os objetos que você precisa podem ser alocados e liberados dentro deste buffer em um padrão definido de rotação, por isso é muitas vezes chamado de buffer de anel. Isso geralmente é mais rápido que a alocação de heap.

Às vezes você tem que explicitamente liberar espaço alocado para que ele possa ser realocado em vez de confiar na coleta de lixo. Então você deve aplicar a inteligência cuidado para cada bloco de memória alocada e desenhar um caminho para que ele seja desalocado no momento oportuno. O método pode ser diferente para cada tipo de objeto que você cria. Você deve se certificar de que cada execução de uma operação de alocação de memória é acompanhada por uma memória desalocando operação acabou. Isto é tão difícil que os programadores muitas vezes simplesmente implementar uma forma rudimentar ou coleta de lixo, como a contagem de referência, para fazer isso por eles.

Como lidar com os erros intermitentes

O bug intermitente é um primo dos 50 metros de escorpião invisível, a partir do espaço exterior tipo de bug. Este pesadelo ocorre tão raramente que é difícil de observar, ainda, muitas vezes suficiente para que ele não pode ser ignorado. Você não pode depurar porque você não consegue encontrá-lo.

Apesar de, após oito horas você vai começar a duvidar dele, o bug intermitente tem que obedecer as mesmas leis da lógica de tudo o mais faz. O que torna difícil é que isso ocorre somente sob condições desconhecidas. Tente gravar as circunstâncias em que o bug não ocorrer, de modo que você pode adivinhar o que a variabilidade é realmente. A condição pode estar relacionada a valores de dados, como " Isso só acontece quando entramos em Wyoming como um valor. " Se essa não é a fonte de variabilidade, o suspeito seguinte deve ser indevidamente sincronizado simultaneidade.

Tente, tente reproduzir o bug de forma controlada. Se você não pode reproduzi-lo, armaram uma armadilha para ele através da construção de um sistema de registro, um em especial se for preciso, que pode registrar o que você acho que você precisa quando realmente ocorre. Resignar-se a que, se o erro só ocorre na produção e não ao seu capricho, isso é pode ser um processo longo. As dicas que você começa a partir do registro não pode fornecer a solução, mas pode lhe dar informações suficientes para melhorar a exploração madeireira. O melhor sistema de log pode levar um longo tempo para ser colocado em produção. Então, você tem que esperar o erro para reaparecer para obter mais informações. Este ciclo pode continuar por algum tempo.

A mais estúpida que eu já bug intermitente foi criado em uma aplicação multi-threaded de uma linguagem de programação funcional para um projeto de classe. Eu tive muito cuidado segurado avaliação simultânea correta do programa funcional, uma boa utilização de todos os processadores disponíveis (oito, no caso). Eu simplesmente esqueci de sincronizar o coletor de lixo. O sistema poderia funcionar muito tempo, muitas vezes, terminando o que comecei a tarefa, antes de qualquer coisa perceptível deu errado. Eu tenho vergonha de admitir que eu tinha começado a questão do hardware antes do meu erro me ocorreu.

No trabalho, tivemos recentemente um bug intermitente, que nos levou várias semanas para encontrar. Temos rosca servidores de aplicação multi-em Java ™ atrásApache servidores web ™. Para manter a página de voltas rápidas, o que fazemos todos os I / O no pequeno conjunto de quatro segmentos separados que são diferentes do que os tópicos de viragem de página. De vez em quando estes seriam, aparentemente, ficar ' preso 'e deixar de fazer alguma coisa útil, na medida do nosso registro nos permitiu contar, por horas. Como tínhamos quatro segmentos, isso não foi em si um problema gigante --- a menos que todos os quatro ficou preso. Em seguida, as filas esvaziado por esses segmentos rapidamente preencher toda a memória disponível e crash nosso servidor. Demorou cerca de uma semana para descobrir isso muito, e nós ainda não sabemos o que causou isso, quando isso iria acontecer, ou mesmo que os segmentos que fazer quando eles se ' preso '.

Isso ilustra alguns dos riscos associados, software de terceiros. Nós estávamos usando um pedaço de código licenciado que removeu tags HTML de texto. Devido ao seu lugar de origem que carinhosamente se refere a isso como " a stripper francesa. " Embora tivéssemos o código-fonte (graças a Deus!) Não havia estudado com cuidado até ligando o registro em nossos servidores, finalmente, percebeu que os segmentos de e-mail foi ficar preso no stripper francesa.

A stripper bom desempenho, exceto em alguns tipos de longo e incomum de textos. Sobre estes textos, o código foi quadrática ou pior. Isso significa que o tempo de processamento foi proporcional ao quadrado do comprimento do texto. Teve textos ocorreu normalmente, teríamos encontrado o erro imediatamente. Se nunca tivesse ocorrido em tudo, nunca teríamos tido um problema. Quando isso acontece, ele nos levou semanas para finalmente entender e resolver o problema.

Como Aprender Skills Design

Para saber como design de software, estudar a ação de um tutor por estar fisicamente presente quando eles estão projetando. Então estude peças bem escrito de software. Depois disso, você pode ler alguns livros sobre as mais recentes técnicas de design.

Então você deve fazê-lo sozinho. Comece com um projeto pequeno. Quando você está finalmente pronto, considere como o projeto ou não conseguiu e como divergiu da sua concepção original. Eles se mudam para projetos maiores, espero que em conjunto com outras pessoas. Design é uma questão de julgamento que leva anos para adquirir. Um programador inteligente pode aprender o básico de forma adequada em dois meses e pode melhorar a partir daí.

É natural e útil para desenvolver seu próprio estilo, mas lembre-se que o design é uma arte, não uma ciência. As pessoas que escrevem livros sobre o assunto têm interesse em fazê-lo parecer científico. Não se torne dogmática sobre estilos de design especial.

Como conduzir experimentos

A tarde, grande Edsger Dijkstra eloquentemente explicou que a Ciência da Computação não é uma ciência experimental [ ExpCS ] e não depende de computadores eletrônicos. Como ele diz referindo-se a década de 1960 [ faca ],

... O dano foi feito: o tema tornou-se conhecido como " ciência da computação "--- que, na verdade, é como se referindo à cirurgia como" ciência da faca "--- e foi firmemente implantado na mente das pessoas é que a ciência da computação é de cerca de máquinas e seus equipamentos periféricos.

Programação não deveria ser uma ciência experimental, mas a maioria dos programadores que trabalham não têm o luxo de praticar o que significa Dijkstra pela ciência da computação. Temos de trabalhar no reino da experimentação, assim como alguns, mas não todos, os físicos fazem. Se 30 anos a partir de agora a programação pode ser realizada sem a experimentação, ela será uma grande realização de Ciência da Computação.

Os tipos de experiências que você terá que executar são:

  • Os sistemas de testes com pequenos exemplos para verificar a sua conformidade com a documentação ou para compreender a sua resposta quando não há nenhuma documentação,

  • alterações no código de teste pequeno para ver se eles realmente corrigir um erro,

  • Medir o desempenho de um sistema em duas condições diferentes, devido ao conhecimento imperfeito do que as características de desempenho,

  • Verificando a integridade dos dados, e

  • Recolha de dados estatísticos que podem sugerir a solução para o difícil ou difícil de bugs repetir.

Eu não acho que, neste ensaio, eu posso explicar o projeto de experimentos, você vai ter que estudar e praticar. No entanto, posso oferecer duas pitadas de conselho.

Em primeiro lugar, tentar ser muito claro sobre a sua hipótese, ou a afirmação de que você está tentando teste. Também ajuda a escrever a hipótese de baixo, especialmente se você está confuso ou está trabalhando com os outros.

Muitas vezes você vai encontrar-se ter que projetar uma série de experimentos, cada um dos quais é baseado no conhecimento adquirido a partir da experiência passada. Portanto, você deve projetar suas experiências para oferecer o máximo de informação possível. Infelizmente, isso está em tensão com a colocação de cada experimento simples --- você terá que desenvolver este juízo através da experiência.

Equipe de Perícias

Por Estimativa é importante

Para obter um sistema de software que trabalham em uso o mais rapidamente possível exige não só o planejamento do desenvolvimento, mas também a documentação do planejamento, implantação de marketing. Em um projeto comercial que também exige vendas e finanças. Sem previsibilidade do tempo de desenvolvimento, é impossível para estas plano de forma eficaz.

fornece uma boa estimativa da previsibilidade. Gerentes de amá-lo, assim que deveriam. O fato de que é impossível, tanto teórica como prática, prever com precisão quanto tempo levará para desenvolver software é muitas vezes perdida em gestores. Somos chamados a fazer esta coisa impossível o tempo todo, e temos de enfrentá-lo honestamente. No entanto, seria desonesto não admitir a impossibilidade de esta tarefa, e quando necessário, explicar. Há muito espaço para mal-entendidos sobre as estimativas, como as pessoas têm uma tendência surpreendente pensar ansiosos para que a frase:

Estimo que, se eu realmente compreender o problema, é cerca de 50% provável que venhamos a ser feito em cinco semanas (se ninguém nos incomoda durante esse tempo).

realmente significa:

Eu prometo a ter tudo feito cinco semanas a partir de agora.

Esse problema interpretação comum requer que você explicitamente discutir o que significa que a estimativa com seu chefe ou cliente, como se fossem um simplório.Reafirme suas premissas, não importa o quanto eles parecem óbvias para você.

Como estimar o tempo de programação

Estimativa requer prática. Ele também leva trabalho. Demora tanto trabalho pode ser uma boa idéia para estimar o tempo que levará para fazer a estimativa, especialmente se você for solicitado para estimar algo em grande.

Quando solicitado a fornecer uma estimativa de algo grande, a coisa mais honesta a fazer é parar. A maioria dos engenheiros estão entusiasmados e ansiosos para agradar, e de adiamento certamente vai desagradar ao impasse. Mas uma estimativa no local, provavelmente não serão precisos e honestos.

Enquanto a parada, talvez seja possível considerar fazer ou protótipos da tarefa. Se houver pressão política, esta é a maneira mais precisa a estimativa de produção, e faz um verdadeiro progresso.

Quando não for possível tomar o tempo de alguma investigação, você deve primeiro estabelecer o significado da estimativa de forma muito clara. Reafirmar que significa que a parte inicial e final de sua estimativa por escrito. Prepare uma estimativa escrito por desconstruir a tarefa em subtarefas progressivamente menores até que cada pequena tarefa não é mais do que um dia, idealmente, no máximo, no comprimento. A coisa mais importante é não deixar nada de fora. Por exemplo, documentação, testes, tempo para o planejamento, o tempo para a comunicação com outros grupos, e tempo de férias são todos muito importantes. Se você gastar parte de cada dia lidando com knuckleheads, colocar um item de linha para que, na estimativa. Isto dá a seu chefe visibilidade para o que está usando o seu tempo, no mínimo, e você pode ficar mais tempo.

Sei que bons engenheiros pad estimativas implicitamente, mas eu recomendo que você não faz. Um dos resultados do estofamento é a confiança em você pode ser esgotado. Por exemplo, um engenheiro pode estimar três dias para uma tarefa que ela realmente acha que levará um dia. O engenheiro pode programar para passar dois dias documentá-lo, ou dois dias trabalhando em algum projeto que seja útil. Mas será detectável que a tarefa foi realizada em apenas um dia (se ele sair dessa forma), eo aparecimento de desertar ou superestimando nasce. É muito melhor para dar visibilidade adequada para o que você está realmente fazendo. Se a documentação tem o dobro do tempo de codificação ea estimativa diz assim, é tremenda vantagem adquirida, tornando esta visível para o gerente.

Pad explicitamente em seu lugar. Se uma tarefa vai levar um dia --- mas pode levar dez dias se a sua abordagem não funciona --- esta nota de alguma forma, a estimativa se você pode, se não, pelo menos, fazer uma média ponderada de suas estimativas das probabilidades. Qualquer fator de risco que você pode identificar e atribuir uma estimativa deve ir para o horário. Uma pessoa não é provável que esteja doente, numa dada semana. Mas um projeto grande, com muitos engenheiros terão algum tempo doente, o mesmo tempo de férias. E qual é a probabilidade de um seminário de formação à escala da empresa é obrigatório? Se ele pode ser estimado, furá-la dentro Há, naturalmente, desconhecidos desconhecidos, ou desconhe-unks . Unk-unks, por definição, não pode ser calculada individualmente.Você pode tentar criar um item de linha global para todos desconhe-unks ou manuseá-los de alguma outra maneira que você se comunica com seu chefe. Você não pode, no entanto, deixar seu chefe esquecer que eles existem, e é diabolicamente fácil para uma estimativa de se tornar uma programação sem o desconhe-unks considerado.

Em um ambiente de equipe, você deve tentar fazer as pessoas que irão fazer o trabalho fazer o cálculo, e você deve tentar um consenso em toda a equipe em estimativas. As pessoas variam muito em habilidade, experiência, preparação e confiança. Calamity greves quando um programador forte estima por si mesma e então os programadores fracos são realizadas para esta estimativa. O ato de ter toda a equipe concordar com uma linha por linha de base para a estimativa clarifica o entendimento da equipe, bem como permitir a possibilidade de mudança de tática dos recursos (por exemplo, deslocando carga longe dos membros mais fracos da equipe mais forte).

Se há grandes riscos que não podem ser avaliados, é o seu dever de tanta força o suficiente para que o gestor não se compromete com eles e, em seguida, se constrangido quando o risco ocorre. Esperemos que em tal caso, o que for necessário será feito para diminuir o risco.

Se você puder convencer a empresa a utilizar Extreme Programming , você só tem que estimar as coisas relativamente pequenas, e isso é tanto mais divertido e mais produtivo.

Como descobrir informações

A natureza do que você precisa saber determina como você deve encontrá-lo.

Se precisar de informações sobre coisas concretas , objetivas e fáceis de verificar, por exemplo, o nível de patch mais recente de um produto de software, pergunte a um grande número de pessoas educadamente, pesquisando na internet por ele ou por postar em um grupo de discussão. Não se busca na internet para qualquer coisa que cheire a qualquer interpretação subjetiva ou parecer: o rácio de asneiras a verdade é demasiado elevado.

Se você precisa de conhecimento geral sobre algo subjetivo a história do que as pessoas pensaram sobre isso, vá para a biblioteca (a construção física em que os livros estão armazenados). Por exemplo, para aprender sobre a matemática ou cogumelos ou misticismo, ir à biblioteca.

Se você precisa saber como fazer algo que não é trivial obter dois ou três livros sobre o assunto e lê-los. Você pode aprender a fazer algo trivial, como instalar um pacote de software, a partir da Internet. Você pode até aprender coisas importantes, como a técnica de programação boa, mas você pode facilmente gastar mais tempo pesquisando e classificando os resultados e tentar adivinhar a autoridade dos resultados do que seria necessário para ler a parte pertinente de um livro sólido.

Se você precisar de informações que ninguém poderia esperar para saber por exemplo, ' faz isso de software que é novo trabalho da marca em conjuntos de dados gigantesco? ", você ainda deve pesquisar na internet e na biblioteca. Após essas opções são completamente esgotado, você pode projetar um experimento para verificá-la.

Se você quer uma opinião ou um juízo de valor que leva em conta algumas circunstâncias únicas, fale com um especialista. Por exemplo, se você quer saber se é ou não é uma boa idéia para construir um moderno sistema de gestão de banco de dados em LISP, você deve falar com um especialista em LISP e um especialista em banco de dados.

Se você quer saber quão provável é que um algoritmo mais rápido para uma aplicação específica existe que não foi ainda publicada, converse com alguém que trabalha nesse campo.

Se você quiser fazer uma decisão pessoal que só você pode fazer como se você deve ou não iniciar um negócio, tentar colocar em escrever uma lista de argumentos a favor e contra a idéia. Se isso falhar, considere adivinhação. Suponha que você tenha estudado a idéia de todos os ângulos, ter feito seu dever de casa, e trabalhou com todas as consequências e os prós e contras em sua mente, e ainda permanecem indecisos. Agora você deve seguir seu coração e dizer a seu cérebro se calar. A multiplicidade de técnicas de adivinhação disponíveis são muito úteis para determinar seus próprios desejos semi-consciente, uma vez que cada um apresente um ambíguo e aleatória padrão completo que o próprio subconsciente irá atribuir significado ao.

Como utilizar pessoas como fontes de informação

Respeite o tempo de cada pessoa e equilibrá-lo contra o seu próprio. Pedir a alguém uma questão realiza muito mais do que receber a resposta. A pessoa aprende sobre você, tanto por desfrutar da sua presença e ouvir a pergunta específica. Você aprende sobre a pessoa da mesma maneira, e você pode aprender a resposta que você procura. Isso geralmente é muito mais importante que a sua pergunta.

No entanto, o valor deste diminui quanto mais você fizer isso. Está, afinal, com o bem mais precioso que uma pessoa tem: o seu tempo. Os benefícios da comunicação devem ser pesados ​​contra os custos. Além disso, os custos e benefícios derivados particular diferem de pessoa para pessoa. Eu acredito fortemente que um executivo de 100 pessoas devem gastar cinco minutos de um mês conversando com cada pessoa em sua organização, o que seria cerca de 5% do seu tempo. Mas, dez minutos podem ser muito, e cinco minutos é muito se eles têm mil empregados. A quantidade de tempo que você gasta conversando com cada pessoa em sua organização depende de seu papel (mais do que sua posição). Você deve conversar com seu chefe mais de chefe do seu chefe, mas você deve falar com o chefe do seu chefe um pouco. Pode ser desconfortável, mas eu acredito que você tem a obrigação de falar um pouco para todos os seus superiores hierárquicos, a cada mês, não importa o quê.

A regra básica é que todos os benefícios de conversar com você um pouco, e quanto mais ele falar com você, menos benefícios que derivam. É seu trabalho que lhes este benefício, e para obter o benefício de se comunicar com eles, mantendo o benefício em equilíbrio com o tempo gasto.

É importante respeitar o seu próprio tempo. Se falar com alguém, mesmo que isso irá custar-lhes o tempo, você vai economizar uma grande quantidade de tempo, então você deve fazê-lo a menos que você acha que seu tempo é mais valioso do que o seu, para a tribo, por esse fator.

Um exemplo disto é estranho o estagiário de verão. Um estagiário de verão em uma posição altamente técnica não pode ser esperado para realizar muito, pois eles podem ser esperados a importunar o inferno de todos lá. Então, por que isso é tolerado? Porque o importunou estão recebendo algo muito importante do estagiário.Eles ganham a chance de showoff um pouco. Eles ganham a chance de ouvir algumas ideias novas, talvez, eles têm a chance de ver as coisas de uma perspectiva diferente. Podem também estar tentando contratar o estagiário, mas mesmo este não é o caso há muito a ganhar.

Você deve perguntar para as pessoas um pouco de sua sabedoria e juízo, sempre que você honestamente acredito que eles têm algo a dizer. Isto lisonjeia-las e você vai aprender algo e ensinar-lhes algo. Um bom programador nem sempre necessitam do aconselhamento de um vice-presidente de Vendas, mas se algum dia o fizer, não se esqueça de pedir para ela. Uma vez eu perguntei para ouvir em algumas vendas chamadas para entender melhor o trabalho de nossa equipe de vendas. Este não levou mais de 30 minutos, mas eu acho que o esforço pequeno feito uma impressão sobre a força de vendas.

Como documento Sabiamente

A vida é curta demais para escrever uma porcaria que ninguém vai ler, se você escrever uma porcaria, ninguém vai lê-lo. Portanto, um pouco de boa documentação é a melhor. Gestores muitas vezes não entendem isso, porque mesmo a documentação ruim lhes dá uma falsa sensação de segurança que não são dependentes de seus programadores. Se alguém absolutamente insiste em que você escrever documentação verdadeiramente inútil dizer `` Sim''e calmamente começa a procurar um emprego melhor.

Não há nada tão eficaz como a colocação de uma estimativa precisa da quantidade de tempo que levará para produzir uma boa documentação em uma estimativa abrandar a procura de documentação. A verdade é fria e dura: documentação, como teste, pode levar muitas vezes maior do que o desenvolvimento de código.

Escrever boa documentação é, em primeiro lugar, boa escrita. Eu sugiro que você encontrar livros sobre a escrita, estudá-los, e prática. Mas mesmo se você é um mau escritor ou ter mau comando da língua em que você deve documento, a Regra de Ouro é tudo o que você realmente precisa:. `` Faz aos outros como você gostaria que fizessem a você''Reserve um tempo para realmente pensar em quem vai ler a documentação, o que eles precisam sair dela, e como você pode ensinar isso a eles. Se você fizer isso, você será um escritor de documentação acima da média, e um bom programador.

Quando se trata realmente de documentar o código em si, ao invés de produzir documentos que realmente pode ser lido por não-programadores, os melhores programadores que eu sempre soube manter um sentimento universal: escrever código auto-explicativo e código do documento apenas em lugares que você não pode deixar claro ao escrever o próprio código. Há duas boas razões para isso. Em primeiro lugar, quem precisa ver a documentação no nível do código, na maioria dos casos, ser capaz de ler e preferem o código de qualquer maneira. Evidentemente, esta parece mais fácil para o programador experiente do que para o iniciante.Mais importante, no entanto, é que o código ea documentação não pode ser inconsistente se não existe documentação. O código fonte pode estar errado na pior das hipóteses e confusa. A documentação, se não está escrito na perfeição, pode mentir, e isso é mil vezes pior.

Isso não torna mais fácil para o programador responsável. Como se escrever um código auto-explicativo? O que isso significa? Isso significa que:

  • Escrever código sabendo que alguém vai ter que lê-lo;

  • Aplicando a regra de ouro;

  • Escolhendo uma solução que seja simples, mesmo se você poderia conseguir com uma outra solução mais rápida;

  • Sacrificar pequenas otimizações que ofuscar o código;

  • Pensando no leitor e passar algum do seu precioso tempo para torná-lo mais fácil para ela, e

  • Nem sempre usando um nome de função como ``''foo bar'',``, ou ``''bagatela!

Como trabalhar com Poor Código

É muito comum ter que trabalhar com o código de má qualidade que alguém tenha escrito. Não pense muito mal deles, porém, até que tenha andado em seus sapatos. Eles podem ter sido convidado muito consciente que algo seja feito rapidamente para atender a pressão do cronograma. Não obstante, a fim de trabalhar com código claro que você deve entendê-lo. Para entender o que leva tempo de aprendizagem, e que o tempo vai ter que sair de algum programa, em algum lugar, e você deve insistir. Para compreendê-lo, você terá que ler o código-fonte. Você provavelmente terá de experimentar com ela.

Este é um bom momento para documento, mesmo que seja só para si, porque o ato de tentar documentar o código irá forçar você a considerar ângulos que você pode não ter considerado, eo documento resultante pode ser útil. Enquanto estiver fazendo isso, considerar o que seria necessário reescrever alguns ou todos do código. Será que realmente economizar na hora de reescrever algumas delas? Você poderia confiar nele melhor se você reescreveu-lo? Tenha cuidado com a arrogância aqui. Se você reescrevê-lo, será mais fácil para você lidar, mas será que vai ser realmente mais fácil para a próxima pessoa que tem que ler isso? Se você reescrevê-lo, o que vai ser a carga de teste? Será que a necessidade de re-teste que superam quaisquer benefícios que possam ser adquirida?

Em qualquer estimativa que você faz para o trabalho contra o código você não escrever, a qualidade do que o código deve afectar a sua percepção do risco de problemas de e-unk unks.

É importante lembrar que a abstração e encapsulamento, duas das melhores ferramentas que um programador, são particularmente aplicável a código ruim. Você pode não ser capaz de redesenhar um grande bloco de código, mas se você pode adicionar uma certa quantidade de abstração para que você pode obter alguns dos benefícios de um bom projeto sem retrabalhar toda a bagunça. Em particular, você pode tentar cercar as peças que são particularmente ruins para que eles possam ser redesenhados de forma independente.

Como usar o controle do código fonte

sistemas de controle de código permite que você gerenciar projetos de forma eficaz. Eles são muito úteis para uma pessoa e essencial para um grupo. Eles acompanham todas as alterações em versões diferentes, de modo que nenhum código seja perdida e significado pode ser atribuído a alterações. Pode-se criar jogadas fora e depuração de código com a confiança com um sistema de controle de código fonte, uma vez que o código que você modificar é mantido cuidadosamente separado do código, cometida oficiais que serão compartilhadas com a equipe ou liberado.

Eu estava atrasado para apreciar os benefícios dos sistemas de controle de código, mas agora eu não viveria sem uma sequer em um projeto de uma pessoa.Geralmente são necessárias quando se tem equipe trabalhando na mesma base de código. No entanto, eles têm uma outra grande vantagem: eles estimulam o pensamento sobre o código como um sistema, o crescimento orgânico. Uma vez que cada mudança é marcada como uma nova revisão com um novo nome ou número, a pessoa começa a pensar no software como uma série de melhorias visivelmente progressivo. Eu acho que isso é especialmente útil para os iniciantes.

Uma boa técnica para usar um sistema de controle de código-fonte é ficar dentro de poucos dias de ser up-to-date em todos os tempos. Código que não pode ser terminado em poucos dias é devolvido, mas de uma forma que ele está inativo e não será chamado, e, portanto, não cria nenhum problema para ninguém. Cometer um erro que atrasa seus companheiros de equipe é um erro grave, que muitas vezes é tabu.

Como teste de unidade

Unidade de teste, o ensaio de uma peça individual de funcionalidade codificadas pela equipe que o escreveu, é uma parte da codificação, e não algo diferente dele.Parte da concepção de que o código é projetar como será testado. Você deve escrever um plano de teste, mesmo que seja apenas uma frase. Às vezes, o teste será muito simples: `` O botão de boa aparência''Às vezes, será complexa:? `` Será que esse retorno algoritmo de correspondência correspondem precisamente à correta?''

Use o teste de afirmações e pilotos de testes sempre que possível. Isto não só capturas bugs cedo, mas é muito útil mais tarde, e permite que você elimine mistérios que você teria que se preocupar.

Os desenvolvedores do Extreme Programming a escrever extensivamente sobre testes unitários de forma eficaz; não posso fazer melhor do que recomendar aos seus escritos.

Fazer intervalos quando Stumped

Quando desafiado, faça uma pausa. Às vezes eu medito por 15 minutos, quando o perplexo eo problema magicamente se desfaz quando eu voltar para ele. uma noite de sono, por vezes, faz a mesma coisa em uma escala maior. É possível que, temporariamente, a mudança para qualquer outra atividade pode funcionar.

Como reconhecer quando Go Home

programação de computadores é uma atividade que também é uma cultura. O fato lamentável é que não é uma cultura que valoriza a saúde física ou mental muito.Para tanto cultural / razões históricas (a necessidade de trabalhar à noite em computadores descarregados, por exemplo) e por causa da pressão do tempo de colocação no mercado e oprimindo a escassez de programadores, programadores de computador são tradicionalmente sobrecarregados. Eu não acho que você pode confiar em todas as histórias que você ouve, mas eu acho que 60 horas por semana é comum, e 50 é muito bonito um mínimo. Isto significa que, muitas vezes muito mais do que é exigido. Este é um problema sério para um bom programador, que é responsável não só para si, mas seus companheiros de equipe também.Você tem que reconhecer quando voltar para casa, e às vezes quando a sugerir que outras pessoas vão para casa. Não pode haver nenhuma regra fixa para resolver este problema, mais do que não pode haver regras fixas para a criação de uma criança, pelo mesmo motivo --- cada ser humano é diferente.

Além de 60 horas por semana é um esforço extraordinário para mim, que eu possa aplicar para períodos curtos de tempo (cerca de uma semana), e que às vezes é esperado de mim. Eu não sei se é justo esperar 60 horas de trabalho de uma pessoa, eu nem sei se 40 é justo. Estou certo, no entanto, que é estúpido para tanto trabalho que você está recebendo pouco fora de hora extra que você trabalha. Para mim, pessoalmente, isso é mais do que 60 horas por semana. Eu pessoalmente acho que um programador deve exercer noblesse oblige e ombros um pesado fardo. No entanto, ele não é programador dever de ser um bode expiatório. O fato triste é que os programadores são frequentemente chamados a ser bodes expiatórios, a fim de dar um show para alguém, por exemplo, um gerente de tentar impressionar um executivo. Os programadores geralmente sucumbem a isso porque eles estão ansiosos para agradar e não muito bom em dizer não. Há quatro defesas contra isto:

  • Comunique-se, tanto quanto possível com todos na empresa, de modo que ninguém pode enganar os executivos sobre o que está acontecendo,

  • Aprenda a prever e programar defensivamente e explicitamente e dar visibilidade a todos para que a programação é e onde está,

  • Aprenda a dizer não e dizer não como uma equipe, quando necessário, e

  • Saia, se for preciso.

A maioria dos programadores são bons programadores, programadores e boa quero fazer muita coisa. Para isso, eles têm que gerir o seu tempo de forma eficaz. Há uma certa quantidade de inércia mental associados com a obtenção aquecido para um problema e profundamente envolvido nela. Muitos programadores acham que trabalham melhor quando têm tempo, os blocos ininterrupta do tempo em que para começar aquecido e concentrado. No entanto, as pessoas precisam dormir e realizar outras tarefas. Cada pessoa precisa encontrar uma maneira de satisfazer tanto o ritmo quanto a sua formação humana e seu ritmo de trabalho. Cada programador tem de fazer o que for preciso para adquirir períodos de trabalho eficiente, tal como reservar certos dias em que você vai atender apenas as reuniões mais importantes.

Desde que eu tenho filhos, eu tento passar noites com eles algumas vezes. O ritmo que funciona melhor para mim é um dia de trabalho muito longo, dormir no escritório ou perto do escritório (eu tenho uma longa viagem de casa para o trabalho) e depois ir para casa cedo o suficiente no dia seguinte para passar o tempo com meus filhos antes de eles ir para a cama. Eu não estou confortável com isso, mas é o melhor compromisso que eu tenho sido capaz de trabalhar para fora. Vá para casa se tiver uma doença contagiosa. Você deveria ir para casa se você está tendo pensamentos suicidas. Você deve fazer uma pausa ou voltar para casa, se você tem pensamentos homicidas por mais de alguns segundos. Você deve enviar a casa de alguém se mostrar mau funcionamento mental grave ou sinais de doença mental para além de depressão leve. Se você é tentado a ser desonesto ou enganosa de uma maneira que você normalmente não são devido ao cansaço, você deve fazer uma pausa. Não uso de cocaína ou anfetaminas para combater a fadiga. Não abuse da cafeína.

Como Lidar com Pessoas Difíceis

Você provavelmente terá que lidar com pessoas difíceis. Você pode até mesmo ser uma pessoa difícil mesmo. Se você é o tipo de pessoa que tem um monte de conflitos com os colegas e figuras de autoridade, você deve cultivar a independência isso implica, mas trabalhar em suas habilidades interpessoais, sem sacrificar a sua inteligência ou princípios.

Isso pode ser muito perturbador para alguns programadores que não têm experiência neste tipo de coisa e cuja vida anterior experiência ensinou-lhes padrões de comportamento que não são úteis no trabalho. Pessoas difíceis são, muitas vezes acostumados a divergências e eles são menos afetadas pela pressão social ao compromisso do que outros. A chave é a respeitá-los adequadamente, o que é mais do que você vai querer, mas não tanto como desejariam.

Os programadores têm de trabalhar juntos como uma equipe. Quando desacordo, deve ser resolvido de alguma forma, ele não pode ser desviou por muito tempo.Pessoas difíceis são extremamente inteligentes e têm uma coisa muito útil a dizer. É fundamental que você ouvir e compreender a pessoa difícil, sem prejuízo causado pela pessoa. A falta de comunicação é muitas vezes a base de desacordo, mas às vezes pode ser removida com muita paciência. Tente manter essa comunicação legal e cordial, e não aceitam as iscas de maior conflito que podem ser oferecidos. Após um período razoável de tentar compreender, tomar uma decisão.

Não deixe que um valentão forçá-lo a fazer algo que você não concorde. Se você for o líder, fazer o que você acha que é melhor. Não tomar uma decisão por motivos pessoais, e estar preparado para explicar as razões da sua decisão. Se você é um companheiro com uma pessoa difícil, não deixe a decisão do líder ter qualquer impacto pessoal. Se ele não seguir o seu caminho, faça-o todo outra forma o coração.

Difícil fazer as pessoas mudar e melhorar. Eu vi com meus próprios olhos, mas é muito raro. No entanto, todo mundo tem altos e baixos transitória.

Um dos desafios que todos os programadores, mas sobretudo face líderes é manter a pessoa difícil plenamente. Eles são mais propensos a trabalhar pato e resistir passivamente que outros.

Nenhum comentário:

Postar um comentário

Popular Posts

- Arquivo -

 

Seguidores

Hora exata:

Total de visualizações de página