diff --git a/Gruntfile.js b/Gruntfile.js index dceae81..43f0a69 100644 --- a/Gruntfile.js +++ b/Gruntfile.js @@ -5,7 +5,9 @@ module.exports = function(grunt) { pkg: grunt.file.readJSON('package.json'), staticHandlebars: { simpleTarget: { - files:{'dist/*/*.html':'src/*/*.hbs'} + files: { + 'dist/*/*.html': 'src/*/*.hbs' + } } }, watch: { diff --git a/package.json b/package.json index f34c6e8..a315fb8 100644 --- a/package.json +++ b/package.json @@ -14,5 +14,12 @@ "url": "git://github.com/ericdrowell/CheatSheetWorld.git" }, "author": "Eric Rowell", + "contributors": [ + { + "name" : "Olivier Colonna", + "email" : "oliviercolonna@gmail.com", + "url" : "https://github.com/OlivierCo" + } + ], "license": "MIT" } diff --git a/src/programming/extreme-programming.hbs b/src/programming/extreme-programming.hbs new file mode 100644 index 0000000..c91b97b --- /dev/null +++ b/src/programming/extreme-programming.hbs @@ -0,0 +1,20 @@ + \ No newline at end of file diff --git a/src/programming/extreme-programming.json b/src/programming/extreme-programming.json new file mode 100644 index 0000000..1666bcd --- /dev/null +++ b/src/programming/extreme-programming.json @@ -0,0 +1,150 @@ +{ + "items": [ + { + "title": "History", + "topics": [ + { + "topic": "Origins", + "definition": "Software development in the 1990s was shaped by two major influences: internally, object-oriented programming replaced procedural programming as the programming paradigm favored by some in the industry; externally, the rise of the Internet and the dot-com boom emphasized speed-to-market and company growth as competitive business factors. Rapidly changing requirements demanded shorter product life-cycles, and were often incompatible with traditional methods of software development." + }, + { + "topic": "Current state", + "definition": "XP generated significant interest among software communities in the late 1990s and early 2000s, seeing adoption in a number of environments radically different from its origins." + } + ] + }, + { + "title": "Concept", + "topics": [ + { + "topic": "Goals", + "definition": "Extreme Programming Explained describes extreme programming as a software-development discipline that organizes people to produce higher-quality software more productively. XP attempts to reduce the cost of changes in requirements by having multiple short development cycles, rather than a long one. In this doctrine, changes are a natural, inescapable and desirable aspect of software-development projects, and should be planned for, instead of attempting to define a stable set of requirements. Extreme programming also introduces a number of basic values, principles and practices on top of the agile programming framework." + }, + { + "topic": "Activities", + "definition": "XP describes four basic activities that are performed within the software development process: coding, testing, listening, and designing. Each of those activities is described below.", + "sub_topics": [ + { + "sub_topic": "Coding", + "definition": "The advocates of XP argue that the only truly important product of the system development process is code – software instructions that a computer can interpret. Without code, there is no working product. Coding can also be used to figure out the most suitable solution. Coding can also help to communicate thoughts about programming problems. A programmer dealing with a complex programming problem, or finding it hard to explain the solution to fellow programmers, might code it in a simplified manner and use the code to demonstrate what he or she means. Code, say the proponents of this position, is always clear and concise and cannot be interpreted in more than one way. Other programmers can give feedback on this code by also coding their thoughts." + }, + { + "sub_topic": "Testing", + "definition": "Extreme programming's approach is that if a little testing can eliminate a few flaws, a lot of testing can eliminate many more flaws." + }, + { + "sub_topic": "Listening", + "definition": "Programmers must listen to what the customers need the system to do, what \"business logic\" is needed. They must understand these needs well enough to give the customer feedback about the technical aspects of how the problem might be solved, or cannot be solved. Communication between the customer and programmer is further addressed in the planning game." + }, + { + "sub_topic": "Designing", + "definition": "Extreme programming's approach is that if a little testing can eliminate a few flaws, a lot of testing can eliminate many more flaws." + } + ] + }, + { + "topic": "Values", + "definition": "Extreme programming initially recognized four values in 1999: communication, simplicity, feedback, and courage. A new value, respect, was added in the second edition of Extreme Programming Explained. Those five values are described below.", + "sub_topics": [ + { + "sub_topic": "Communication", + "definition": "Building software systems requires communicating system requirements to the developers of the system. In formal software development methodologies, this task is accomplished through documentation. Extreme programming techniques can be viewed as methods for rapidly building and disseminating institutional knowledge among members of a development team. The goal is to give all developers a shared view of the system which matches the view held by the users of the system. To this end, extreme programming favors simple designs, common metaphors, collaboration of users and programmers, frequent verbal communication, and feedback." + }, + { + "sub_topic": "Simplicity", + "definition": "Extreme programming encourages starting with the simplest solution. Extra functionality can then be added later. The difference between this approach and more conventional system development methods is the focus on designing and coding for the needs of today instead of those of tomorrow, next week, or next month. This is sometimes summed up as the \"You aren't gonna need it\" (YAGNI) approach.[8] Proponents of XP acknowledge the disadvantage that this can sometimes entail more effort tomorrow to change the system; their claim is that this is more than compensated for by the advantage of not investing in possible future requirements that might change before they become relevant. Coding and designing for uncertain future requirements implies the risk of spending resources on something that might not be needed, while perhaps delaying crucial features. Related to the \"communication\" value, simplicity in design and coding should improve the quality of communication. A simple design with very simple code could be easily understood by most programmers in the team." + }, + { + "sub_topic": "Feedback", + "definition": "Feedback is closely related to communication and simplicity. Flaws in the system are easily communicated by writing a unit test that proves a certain piece of code will break. The direct feedback from the system tells programmers to recode this part. A customer is able to test the system periodically according to the functional requirements, known as user stories. To quote Kent Beck, \"Optimism is an occupational hazard of programming. Feedback is the treatment.\"" + }, + { + "sub_topic": "Courage", + "definition": "Several practices embody courage. One is the commandment to always design and code for today and not for tomorrow. This is an effort to avoid getting bogged down in design and requiring a lot of effort to implement anything else. Courage enables developers to feel comfortable with refactoring their code when necessary. This means reviewing the existing system and modifying it so that future changes can be implemented more easily. Another example of courage is knowing when to throw code away: courage to remove source code that is obsolete, no matter how much effort was used to create that source code. Also, courage means persistence: A programmer might be stuck on a complex problem for an entire day, then solve the problem quickly the next day, but only if they are persistent." + }, + { + "sub_topic": "Respect", + "definition": "The respect value includes respect for others as well as self-respect. Programmers should never commit changes that break compilation, that make existing unit-tests fail, or that otherwise delay the work of their peers. Members respect their own work by always striving for high quality and seeking for the best design for the solution at hand through refactoring. Adopting the four earlier values leads to respect gained from others in the team. Nobody on the team should feel unappreciated or ignored. This ensures a high level of motivation and encourages loyalty toward the team and toward the goal of the project. This value is very dependent upon the other values, and is very much oriented toward people in a team." + } + ] + }, + { + "topic": "Rules", + "definition": "The first version of rules for XP was published in 1999 by Don Wells at the XP website. 29 rules are given in the categories of planning, managing, designing, coding, and testing. Planning, managing and designing are called out explicitly to counter claims that XP doesn't support those activities. Another version of XP rules was proposed by Ken Auer in XP/Agile Universe 2003. He felt XP was defined by its rules, not its practices (which are subject to more variation and ambiguity). He defined two categories: \"Rules of Engagement\" which dictate the environment in which software development can take place effectively, and \"Rules of Play\" which define the minute-by-minute activities and rules within the framework of the Rules of Engagement." + }, + { + "topic": "Principles", + "definition": "The principles that form the basis of XP are based on the values just described and are intended to foster decisions in a system development project. The principles are intended to be more concrete than the values and more easily translated to guidance in a practical situation.", + "sub_topics": [ + { + "sub_topic": "Feedback", + "definition": "Extreme programming sees feedback as most useful if it is done frequently and promptly. It stresses that minimal delay between an action and its feedback is critical to learning and making changes. Unlike traditional system development methods, contact with the customer occurs in more frequent iterations. The customer has clear insight into the system that is being developed, and can give feedback and steer the development as needed. With frequent feedback from the customer, a mistaken design decision made by the developer will be noticed and corrected quickly, before the developer spends much time implementing it." + }, + { + "sub_topic": "Assuming simplicity", + "definition": "This is about treating every problem as if its solution were \"extremely simple\". Traditional system development methods say to plan for the future and to code for reusability. Extreme programming rejects these ideas." + }, + { + "sub_topic": "Embracing change", + "definition": "The principle of embracing change is about not working against changes but embracing them. For instance, if at one of the iterative meetings it appears that the customer's requirements have changed dramatically, programmers are to embrace this and plan the new requirements for the next iteration." + } + ] + } + ] + }, + { + "title": "Practices", + "definition": "Extreme programming has been described as having 12 practices.", + "sub_topics": [ + { + "sub_topic": "Pair programming", + "definition": "Pair programming is an agile software development technique in which two programmers work together at one workstation. One, the driver, writes code while the other, the observer or navigator, reviews each line of code as it is typed in. The two programmers switch roles frequently." + }, + { + "sub_topic": "Planning game", + "definition": "The main planning process within extreme programming is called the Planning Game. The game is a meeting that occurs once per iteration, typically once a week. The planning process is divided into two parts: Release Planning, Iteration Planning." + }, + { + "sub_topic": "Test-driven development", + "definition": "Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards. Kent Beck, who is credited with having developed or 'rediscovered' the technique, stated in 2003 that TDD encourages simple designs and inspires confidence." + }, + { + "sub_topic": "Whole team", + "definition": "Within XP, the \"customer\" is not the one who pays the bill, but the one who really uses the system. XP says that the customer should be on hand at all times and available for questions. For instance, the team developing a financial administration system should include a financial administrator." + }, + { + "sub_topic": "Continuous integration", + "definition": "Continuous integration (CI) is the practice, in software engineering, of merging all developer working copies to a shared mainline several times a day. It was first named and proposed by Grady Booch in his 1991 method, although Booch did not advocate integrating several times a day. It was adopted as part of extreme programming (XP), which did advocate integrating more than once per day, perhaps as many as tens of times per day." + }, + { + "sub_topic": "Refactoring or design improvement", + "definition": "Code refactoring is the process of restructuring existing computer code – changing the factoring – without changing its external behavior. Refactoring improves nonfunctional attributes of the software. Advantages include improved code readability and reduced complexity; these can improve source code maintainability and create a more expressive internal architecture or object model to improve extensibility." + }, + { + "sub_topic": "Small releases", + "definition": "The delivery of the software is done via frequent releases of live functionality creating concrete value. The small releases help the customer to gain confidence in the progress of the project. This helps maintain the concept of the whole team as the customer can now come up with his suggestions on the project based on real experience." + }, + { + "sub_topic": "Coding standard", + "definition": "Coding standard is an agreed upon set of rules that the entire development team agree to adhere to throughout the project. The standard specifies a consistent style and format for source code, within the chosen programming language, as well as various programming constructs and patterns that should be avoided in order to reduce the probability of defects. The coding standard may be a standard conventions specified by the language vendor (e.g. The Code Conventions for the Java Programming Language, recommended by Sun), or custom defined by the development team." + }, + { + "sub_topic": "Collective code ownership", + "definition": "Collective code ownership means that everyone is responsible for all the code; this, in turn, means that everybody is allowed to change any part of the code. Pair programming contributes to this practice: by working in different pairs, all the programmers get to see all the parts of the code. A major advantage claimed for collective ownership is that it speeds up the development process, because if an error occurs in the code any programmer may fix it. By giving every programmer the right to change the code, there is risk of errors being introduced by programmers who think they know what they are doing, but do not foresee certain dependencies. Sufficiently well defined unit tests address this problem: if unforeseen dependencies create errors, then when unit tests are run, they will show failures." + }, + { + "sub_topic": "Simple design", + "definition": "Programmers should take a \"simple is best\" approach to software design. Whenever a new piece of code is written, the author should ask themselves 'is there a simpler way to introduce the same functionality?'. If the answer is yes, the simpler course should be chosen. Refactoring should also be used, to make complex code simpler." + }, + { + "sub_topic": "System metaphor", + "definition": "The system metaphor is a story that everyone - customers, programmers, and managers - can tell about how the system works. It's a naming concept for classes and methods that should make it easy for a team member to guess the functionality of a particular class/method, from its name only. For example a library system may create loan_records(class) for borrowers(class), and if the item were to become overdue it may perform a make_overdue operation on a catalogue(class). For each class or operation the functionality is obvious to the entire team." + }, + { + "sub_topic": "Sustainable pace", + "definition": "The concept is that programmers or software developers should not work more than 40 hour weeks, and if there is overtime one week, that the next week should not include more overtime. Since the development cycles are short cycles of continuous integration, and full development (release) cycles are more frequent, the projects in XP do not follow the typical crunch time that other projects require (requiring overtime). Also, included in this concept is that people perform best and most creatively if they are rested. A key enabler to achieve sustainable pace is frequent code-merge and always executable & test covered high quality code. The constant refactoring way of working enforces team members with fresh and alert minds. The intense collaborative way of working within the team drives a need to recharge over weekends. Well-tested, continuously integrated, frequently deployed code and environments also minimize the frequency of unexpected production problems and outages, and the associated after-hours nights and weekends work that is required." + } + ] + } + ] +} \ No newline at end of file