Difference between revisions of "Development Introduction"
(→Patches) |
(→Criar pequenos patches) |
||
Line 33: | Line 33: | ||
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 [http://www.eurekalert.org/pub_releases/2005-03/aps-hmc030805.php 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. | 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 [http://www.eurekalert.org/pub_releases/2005-03/aps-hmc030805.php 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. | 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. | ||
− | |||
=== Notice the risks which are associated with applying the patch === | === Notice the risks which are associated with applying the patch === |
Revision as of 22:10, 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.
Contents
Documentação
Existem alguns pontos importantes se você quiser ajudar a ReactOS documentos:
- Certifique-se que a documentação ainda não existe (se isso acontecer, ajude melhorá-la).
- Respeite práticas de engenharia reversa sala limpa.
- 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.
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.
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
- Microsoft Developer Network (MSDN) – Your search should start here.
- External Documentation Links – Otherwise you should try to find something here.
- ReactOS Techwiki – Documentation provided or collected by ReactOS developers.
- HOWTO Install a driver in ReactOS
- Advanced Windows Debugging
- Windows Internals Fifth Edition (or later versions)
- Windows via C/C++