Difference between revisions of "Development Introduction"

From ReactOS Wiki
Jump to: navigation, search
(Keep focus when developing the patch)
(Review Patches)
Line 49: Line 49:
 
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.
 
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.
  
=== Review Patches ===
+
=== Revisão  de Patches ===
  
Drupal has some tips for reviewing patches.
+
Drupal tem algumas dicas para a revisão de patches.
  
[http://drupal.org/patch/review Tips for reviewing patches]
+
[http://drupal.org/patch/review Dicas para analisar patches]
  
 
== Implement new things ==
 
== Implement new things ==

Revision as of 23:27, 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

Implement new things

Considering ReactOS is alpha quality software, there is a lot of missing functionality that Windows operating systems have. Before starting a project to implement something, find out if another person is working on the same thing. If you find that someone is already working on it, ask if any assistance is needed for what specifically is being worked on or a related project. Plenty of times a person will start to implement something and never finish before moving to something else. Make sure you stay committed to what you are going to implement, and do not be afraid to ask for assistance if you need help with something.

See also

Places to find information