Difference between revisions of "Development Introduction"

From ReactOS Wiki
Jump to: navigation, search
(Implement new things)
(Implementar coisas novas)
Line 57: Line 57:
 
== Implementar coisas novas ==  
 
== Implementar coisas novas ==  
  
Considerando que o ReactOS é um software de qualidade alfa, há um monte de [[Missing ReactOS Functionality|funcionalidades ausentes]] que os sistemas operativos Windows têm. Antes de iniciar um projecto para implementar alguma coisa, saiba se outra pessoa está trabalhando na mesma coisa. Se achar que alguém já está trabalhando nisso, pergunte se é necessário qualquer assistência para o que especificamente está sendo trabalhado ou um projeto relacionado. Muitas vezes uma pessoa vai começar a implementar algo e nunca termina sem antes de passar por outra coisa. Certifique-se de ficar comprometida com o que você está para implementar, e não tenha medo de pedir ajuda se precisar de ajuda com alguma coisa.
+
Considerando que o ReactOS é um software de qualidade alfa, há um monte de [[Missing ReactOS Functionality|funcionalidades ausentes]] que os sistemas operativos Windows têm. Antes de iniciar um projecto para implementar alguma coisa, saiba se outra pessoa está trabalhando na mesma coisa. Se achar que alguém já está trabalhando nisso, pergunte se é necessário qualquer assistência para o que especificamente está sendo trabalhado ou um projecto relacionado. Muitas vezes uma pessoa vai começar a implementar algo e nunca termina sem antes de passar por outra coisa. Certifique-se de ficar comprometida com o que você está para implementar, e não tenha medo de pedir ajuda se precisar de ajuda com alguma coisa.
  
 
== See also ==
 
== See also ==

Revision as of 23:35, 27 July 2014

Existem várias formas de contribuir para o desenvolvimento do ReactOS. O problema mais frequentemente encontrado é não saber por onde começar ou o que fazer. Se você é capaz de programar ou entender as informações técnicas que são pertinentes a este projecto, ajudando o desenvolvimento pode ser fácil.

Documentação

Existem alguns pontos importantes se você quiser ajudar a ReactOS documentos:

  1. Certifique-se que a documentação ainda não existe (se isso acontecer, ajude melhorá-la).
  1. Respeite práticas de engenharia reversa sala limpa.
  1. Adicione o seu conhecimento para um lugar onde os outros desenvolvedores possam encontrá-lo.

Teste ReactOS

Localize erros

Como o código é adicionado, alterado ou removido, é possível que os resultados não intencionais ocorram. Estes resultados não intencionais são conhecidos como bugs. Ao localizarem os erros, os desenvolvedores podem identificar o que causa o erro e o que ela afecta. Há uma variedade de métodos para depuração ReactOS enquanto o testa. Depois de identificar um erro, verifique se já é conhecido pesquisando JIRA e adicione qualquer informação adicional com o relatório. Se você acha que isso é um erro não identificado, considere apresentação de um relatório de erro.

Corrigir bugs

Em vez de olhar para os erros, também pode tentar corrigir alguns que já estão listados no Bugzilla. Corrigindo erros exige muito mais habilidade do que simplesmente procurar por eles, e pode ser demorado.

Escrever testes

Os testes são usados ​​para verificar a funcionalidade e correção de APIs no ReactOS em comparação com implementações do Windows. Existem também alguns testes de unidade que poderia ajudar o ReactOS a ultrapassar e que podem ser encontrados aqui.

Patches

Um patch é um conjunto de alterações no código fonte existente. As mudanças em um patch podem ser misturadas em código-fonte existente. Este processo é referido como aplicar um patch (para código fonte). O que altera um conteudo patch e a forma como o patch está estruturado pode ter um impacto significativo sobre as consequências que podem acontecer com a aplicação do patch. Abaixo estão algumas recomendações sobre como criar e usar patches.

Criar pequenos patches

A revisão provou ser um método eficaz de descobrir erros, por isso deve-se esforçar para criar patches que sejam fáceis de rever. Infelizmente, os humanos são terríveis no rastreamento de grande quantidade de informações. Portanto, mantenha os patches tão pequenos quanto possível para fazer a revisão mais fácil.

Coloque apenas as alterações relacionadas em um patch

Colocar apenas mudanças relacionadas em um patch vai tornar a revisão mais fácil com o revisor precisar de lembrar menos informações sobre o código fonte existente que é alterado.

Observe os riscos que estão associados com a aplicação do patch

O risco de introduzir um erro é maior com alguns tipos de mudanças do que outros. A formatação é uma mudança relativamente segura enquanto as alterações semânticas ao código complexo é uma mudança altamente arriscada. Isso significa que rever um patch somente formatado não é tão importante quanto analisar um patch com as mudanças semânticas ao código complexo (e portanto, não dói tanto, se um patch formatado é grande). Ao misturar mudanças seguras e inseguras, o risco global de introduzir um bug em um determinado patch é o mesmo que se as mudanças fossem distribuídas por vários patches. No entanto, o risco de o patch individual é igual ao risco da mudança mais arriscada no patch. Então, se a 1 linha de troca de alto risco está escondido em uma linha 2000 patch de outro modo seguro, então o risco global para todo o patch é altamente arriscado. Por isso nos esforçamos para colocar as mudanças de riscos semelhantes no mesmo patch.

Definir metas para o seu próximo patch

Para ajudar a evitar que os patches se tornem muito grandes, defina um ou mais objectivos para o seu próximo patch antes de começar a fazer qualquer alteração. A meta pode ser refazer uma parte do código-fonte que é difícil de entender. Poderia ser a implementação da totalidade ou parte de um novo recurso ou corrigir um bug existente no código fonte . Se alcançar as metas requere muitas mudanças e faria o patch se tornar grande e/ou conter muitas mudanças não relacionadas, em seguida, definiria novas metas que, quando atingido, seria garantir que os objectivos originais seria parcialmente alcançados.

Foque-se no desenvolvimento do patch

Ao desenvolver um patch, pode ser tentador corrigir problemas existentes, quando se depara com eles, durante a leitura do código fonte. Isto pode, contudo, rapidamente fazer com que o patch se torne grande e contenha várias alterações não relacionadas que não tenham nada a ver com o alcançar dos objectivos que foram definidos para o patch. Resista à tentação e coloque numa nota no código fonte em vez disso, ou (melhor ainda) coloque a questão no sistema de acompanhamento de questões.

Revisão de Patches

Drupal tem algumas dicas para a revisão de patches.

Dicas para analisar patches

Implementar coisas novas

Considerando que o ReactOS é um software de qualidade alfa, há um monte de funcionalidades ausentes que os sistemas operativos Windows têm. Antes de iniciar um projecto para implementar alguma coisa, saiba se outra pessoa está trabalhando na mesma coisa. Se achar que alguém já está trabalhando nisso, pergunte se é necessário qualquer assistência para o que especificamente está sendo trabalhado ou um projecto relacionado. Muitas vezes uma pessoa vai começar a implementar algo e nunca termina sem antes de passar por outra coisa. Certifique-se de ficar comprometida com o que você está para implementar, e não tenha medo de pedir ajuda se precisar de ajuda com alguma coisa.

See also

Places to find information