From cef3e0233b6abce359e4de8a6a55bf274334ab56 Mon Sep 17 00:00:00 2001 From: teresa-Guilherme Date: Sun, 16 Oct 2016 22:11:33 +0100 Subject: [PATCH] Update Assignment 1.md --- ESOF-docs/Assignment 1.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/ESOF-docs/Assignment 1.md b/ESOF-docs/Assignment 1.md index 830394054..f8527343e 100644 --- a/ESOF-docs/Assignment 1.md +++ b/ESOF-docs/Assignment 1.md @@ -7,7 +7,9 @@ **Development Process** Citra is being developed as a hobby for several programmers and their work schedule on this Open Source Software Project is not very consistent. They are not supported by any company, therefore they don't have a deadline to implement features. Citra has a team of experiences developers that help (begginer/intermediate level) new contributors with the standard level of code that is to be commited. They take a while to accept pull requests, so that they are certain that the pull has the quality they require, in order to avoid bugs or setbacks. + Since the contribution frequency is inconsistent, they can't use any industrial-standard engineering process. They "are constantly working on new features" (as said by one of the project leaders) so it would be considered an Incremental development process. However, as they don´t have any kind of deadlines and they only merge when they are sure the feature is operating correctly, we think they are also using a Slow programming process. + They also use test driven development for certain parts of the emulator, but they fear that making the project only based on test driven, would scare the contributtors with the amounts of bureaucracy needed to implemented. **Opinions, Critics and Alternatives** @@ -18,7 +20,11 @@ * the most important requirement is tested thoroughly; This process provides a more closely and frequently interaction to meet the client's needs. On the other hand the main disadvantage, and the one we consider that might eventually occurr is code degradation. Using this process may degrade the quality of the code, as it is harder to refractor as more features are implemented. + Given the circunstances of this project (hobby, volunteers, low amount of time that developers have to work and inconsistent frequency of commits,specific knowledge about console hardware, emulation, among other areas), we would say that Incremental Development and Deployment process is the most reliable, if not the only plausible development process. + Test-driven development is an alternative to the above. However, this is ill-advised. As with an emulator's nature, it's required to work with multiple games, each with it's own code quirks, while optimizing for playable perfomance. This would mean an excessive amount of tests, and very slow progress towards an acceptable result. + Since it's an open project, it's bound to have disparities in coding methodology. However, there is a guideline on code style. This improves feature recognition by other developers and smoothens development times. + There is a guideline on code style. This improves feature recognition by other developers and smoothens development times. Having a stricter group of developers would potentialy hurt development times, and not necessarily improve code quality, since pull requests are already verified individually before merge.