Development Introduction

From ReactOS Wiki
Revision as of 21:35, 27 July 2014 by Magnos15 (talk | contribs) (Documentação)
Jump to: navigation, search

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.

Write tests

Tests are used to check the functionality and correctness of APIs on ReactOS compared to Windows implementations. There are also some unit tests that you could help ReactOS pass, which can be found here.

Patches

A patch is a set of changes to existing source code. The changes in a patch can be merged into existing source code. This process is referred to as applying a patch (to source code). Which changes a patch contains and the way the patch is structured can have significant impact on the consequences that can happen from applying the patch. Below are a few recommendations on how to create and use patches.

Create small patches

Reviewing has proven to be an effective method of discovering bugs, so one should strive towards creating patches that are easy to review. Unfortunately, humans are terrible at tracking large amount of information. Therefore keep the patches as small as possible to make reviewing easier.

Put only related changes in a patch

Putting only related changes in a patch will make reviewing easier as the reviewer needs to recall less information about the existing source code that is changed.

Notice the risks which are associated with applying the patch

The risk of introducing a bug is higher with some types of changes than others. Formatting is a relatively safe change while semantic changes to complex code is a highly risky change. This means that reviewing a formatting-only patch is not as important as reviewing a patch with semantic changes to complex code (and thus it doesn't hurt so much if a formatting patch is large). When mixing safe and unsafe changes, the overall risk of introducing a bug in a given patch is the same as if the changes were spread over several patches. However, the risk of the individual patch is equal to risk of the most risky change in the patch. So if a 1 line highly risky change is hidden in a 2000 line otherwise safe patch, then the overall risk for the whole patch is highly risky. Therefore strive towards putting changes of similar risk into the same patch.

Set goals for your next patch

To help prevent your patches from becoming too large, set one or more goals for your next patch before you start making any changes. A goal could be to refactor a part of the source code which is hard to understand. It could be to implement part or all of a new feature, or fix a bug that exists in the existing source code. If achieving the goals require too many changes and would make the patch become large and/or contain many unrelated changes, then define new goals which, when reached, would ensure that the original goals would be partially achieved.

Keep focus when developing the patch

While developing a patch, it can be tempting to fix existing issues as you come across them while reading the source code. This can however quickly cause the patch to become large and contain several unrelated changes which have nothing to do with achieving the goals which were defined for the patch. Resist the temptation and put in a note in the source code instead, or (even better) put the issue in the issue tracking system.

Review Patches

Drupal has some tips for reviewing patches.

Tips for reviewing 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