Tendo mais de um projeto - O que devo perguntar o programador anterior? [fechadas]

Question

Eu estou assumindo o desenvolvimento de um web site comercial. Este site foi desenvolvido ao longo de dois anos por outro programador. É principalmente um trabalho de um homem só (manter e expandir o site). Eu vou ter um período de transição de 2-3 dias quando o outro programador vai me mostrar o sistema. Mas pelo que eu sei, há pouca documentação. Tudo está no código (que é uma espécie de documentada). Aqui está o que estou planejando pedir até agora:

• Explicação sobre os elementos mais complexos do sistema
• Descrição da arquitectura global
• Descrição das ferramentas de suporte (configuração IDE, testes unitários, implantação mecanismo)
• Qualquer livro, website, podcast que ele usou para influenciar a arquitetura do sistema

Qualquer outro que estou perdendo?

[EDIT] Obrigado a todos. Perdeu de boas proposições. Eu gostaria de poder aceitar mais de uma resposta! Além disso, eu também gostaria de acrescentar:

• O que você fez especificamente para melhorar o desempenho do sistema, e onde está o gargalo agora?
• Relacionado a isso, o que você fez em relação à segurança do sistema? (O que você fez, e onde estão as falhas de segurança agora)

Uma última coisa: o desenvolvedor disse que ele estará disponível para responder às minhas perguntas, mais tarde, se eu precisar dele. É o seu "bebê" depois de tudo. Mas eu realmente acho que em 6 meses ele vai se mudaram e sua disponibilidade será muito mais reduzido!

Answer 1

Certifique-se de pedir para todos informações de login para os servidores web, registradores de domínio, servidores de banco de dados, servidores de e-mail, e qualquer outra coisa que você pode pensar . Parece loucura, mas muitas vezes os desenvolvedores irão registrar nomes de domínio com eles mesmos como os contatos administrativos e técnicos. A empresa, então, tem que saltar através de todos os tipos de aros com o secretário, a fim de obter a volta de domínio, se o programador original não pode ser contactado.

Answer 2

Antes de olhar o código:

Limpar os objs e os exes, e deixar que ele / ela reconstruir a coisa. Relógio para qualquer interação manual (não é construir através de "make" sozinho ou se há algum mexendo envolvidos).

Melhor ainda: dar a ele / ela um nu (apenas comprou) máquina, que ele / ela demonstrar uma verificação geral e reconstruir. Em seguida, ver como o aplicativo é iniciado e surge (quaisquer opções secretas para entrada?).

Em seguida:., Em uma sessão de programação em pares, adicione uma ou duas características para o sistema e ver onde e como estes são implementados

A descrição acima pode parecer estúpido, mas eu tenho visto projetos onde a construção sozinha foi um pesadelo, e um monte de conhecimento era no cérebro de apenas o desenvolvedor. Não ter um ambiente de construção de confiança e ter que descobrir como reconstruir é um nighmare.

Answer 3

"Se você pudesse voltar e reconstruir esse sistema, o que você faria diferente"

Answer 4

Pergunte: a) o que você não quer me perguntar-lhe sobre este sistema? b) o que você será mais feliz sobre quando você não está mais trabalhando neste projeto? c) Quais são as partes do sistema que são demasiado complexas para serem documentados?

Answer 5

Seu telefone.

Answer 6

Quem são seus usuários experientes? - cuja opinião eu deveria procurar ou de confiança

Quem são seus usuários não-especialistas perigosas - quem eu deveria ouvir e, em seguida, ignorar ativamente

Answer 7

O que é o periódico "mão de obra" que o sistema requer?

Você sabe, aqueles pequenos empregos que surgem a cada tantas vezes que ainda não foram automatizadas. Como você corrigi-lo e como você reconhecê-lo.

Answer 8

Pergunte o que os reais requisitos são. A maioria dos projectos, quer ter requisitos não têm escrito ou exigências out-of-date escritas. A documentação real é geralmente conversas verbais. Saiba com quem falar. Se você tiver necessidades de diferentes usuários conflitantes, descobrir quem é mais importante para fazer feliz.

Answer 9

• Conhecido ¹ problemas
• Conhecido ¹ áreas de melhoria
• existente dados de cobertura de código, a taxa de passagem de teste etc, para ser utilizada como uma linha de base
• dicas para solução de problemas (arquivos de log compreensão, depuração acidentes, dicas comuns)
• Explicação dos parâmetros de configuração

¹ Conhecida apenas para ele ou ela

Answer 10

A primeira pergunta que eu costumo perguntar ao assumir um projeto é como obtê-lo fora do controle de origem (basicamente, "Onde ele está?"). Fora isso, eu acho que você acertar todos os pontos altos.

configuração IDE, testes de unidade, o mecanismo de implantação

são provavelmente a maioria das coisas importantes que você pode perguntar.

Ao pedir que sites influenciado o que você está tomando, ter certeza de obter uma lista de links. Descobri que um monte de desenvolvedores manter bookmarks para sites que já amostrados a partir. Certifique-se de obter os.

Answer 11

Certifique-se de que você pode construí-lo e liberá-lo.

Muitas vezes há problemas com a falta de informação.

Você precisa saber todo o material auxiliar.

Obter uma nova máquina e certifique-se que você pode duplicar a construção e lançamento.

EDIT: depois disso seria: "Quais são as coisas que você tem significado para corrigir, mas não consegui e não estão documentados em qualquer lugar"

Answer 12

Não pergunte. Trancá-lo em uma sala - instruí-lo de que ele não vai conseguir comida ou água até que ele começa a partir do início e diz-lhe tudo o que sabe sobre o sistema. Em seguida, fazer perguntas relevantes como eles vêm para cima. Após este - passar um par de dias olhando para o código. Em seguida, repita o processo. Faça isso até que você se sinta confortável com o sistema.

Answer 13

• Como você instalar o site em um servidor novo.
• O que o site faz e que é utilizado para.
• O que bancos de dados são usados ??e onde eles estão.

Answer 14

Certifique-se de obter todas as "pegadinhas" para a aplicação. Elas são muitas vezes os dados ou itens de negócios que são muito minuto ou peculiar de ter a documentação formal, mas acabam tendo impactos grandes ou muito tempo de depuração se você não sabe o que está acontecendo.

Por exemplo, em uma das aplicações que atualmente mantêm, nós interface com um sistema de terceiros que tem um cliente tipo "visualizador da web". A "pegadinha" com isto é que o espectador web não manter adequadamente o estado da sessão do usuário (quebrado quando foi atualizado para sua versão mais recente para corrigir outros problemas críticos). Como resultado, eu tenho que lembrar os usuários ao longo do tempo para simplesmente minimizar a janela do navegador de modo que o tempo limite ocorre naturalmente, caso contrário, eles vão ficar bloqueado por um período prolongado de tempo até que as pessoas Ops por aqui obter a versão mais recente instalada .

Answer 15

O que os maiores problemas que o site foi executado em ter sido e como eles foram resolvidos? É muito fácil para tentar corrigir algo que não faz sentido em tudo apenas para descobrir que o que parece absurdo é realmente a única correção por algum bug sutil, mas desagradável.

Indo através do código e olhar para tudo o que parece de todo difícil de entender e apenas pedindo "o que isso faz, por que você adicioná-lo?"

Certifique-se de anotar as suas respostas - talvez até mesmo comentá-las no código para que eles estão lá quando você precisar deles. Não há nada mais irritante do que aquela sensação de "I sei me foi dito sobre isso ..."

Answer 16

Assim como o material techy (que de 'fácil' para descobrir :)) descobrir sobre as regras de negócio! Estes raramente são documentados corretamente (na minha experiência) e você geralmente só descobrir a maneira mais difícil quando algo dá errado.

Answer 17

2 a 3 dias sons curtos para a entrega por isso não tenha medo de pedir mais.

Em primeiro lugar obter um ambiente local que trabalha com controle de origem, ide, construção e lançamento passos tudo em execução localmente.

Em seguida, tentar obter uma impressão da qualidade do código, passando por ele brevemente. Se parece ruim, então você pode não obter tanta informação útil sobre a implementação do seu antecessor.

No entanto, tudo sobre as implantações, servidores db, estratégia de backup, registros etc, devem ser verificados. Também todas as licenças para as bibliotecas etc e também uma lista dos erros mais comuns (se eles têm uma ferramenta de bug perseguidor isso pode ser útil)

Além disso, você precisa ver como útil o seu antecessor é como eu já vi vários estilos de handover formulário aqueles onde a pessoa que dá a entrega foi amigável, mas enganoso onde deram respostas sarcásticas às perguntas deles em uma forma de um questionário (que ao mesmo tempo engraçado não era profissional) para simplesmente desinteressado.

Answer 18

Olhando para o código para 5 minutos é o melhor começo, se o código é muito bem organizado e comentado, pode não haver qualquer razão para falar com ele em tudo.

Se o código é horroroso, assim não espera quaisquer razões inteligentes porque ele cortou algo juntos, na melhor das hipóteses, você pode usá-lo como uma referência para algum código fétido e pergunta o que é o propósito.

De qualquer maneira, falando com o desenvolvedor passado é a coisa menos útil para fazer, porque de qualquer forma, você está preso com ele agora.

Answer 19

Analise cuidadosamente a aplicação e tentar descobrir isso em primeiro lugar. Então vá em sua reunião com perguntas e mais importante, contexto .

Answer 20

Você está trabalhando na mesma empresa?
Se não, e isso não está directamente relacionada com o projecto, mas eu perguntar por que ele está saindo. Pode dar-lhe alguns insights sobre a política envolvida ou se alguma coisa está incomodando a trabalhar com ele ou com o cliente.

Answer 21

Pergunte sobre quaisquer bloqueios ou soluções alternativas o desenvolvedor original deparei.

Saiba mais sobre os seus clientes também. eles são esquisitos? O que eles esperam?