Content deleted Content added
No edit summary |
Adding local short description: "Software development methodology", overriding Wikidata description "agile software development methodology" |
||
(5 intermediate revisions by 3 users not shown) | |||
Line 1:
{{Short description|Software development methodology}}
'''[[Extreme programming]]''' ('''XP''') is an [[agile software development]] methodology used to implement [[software]] systems. This article details the practices used in this methodology. Extreme programming has 12 practices, grouped into four areas, derived from the [[best practices]] of [[software engineering]].<ref name="XPExplained">Beck, K. ''Extreme Programming Explained: Embrace Change'' 2nd. ed. Addison-Wesley, 2000 pp. 54</ref>
==Fine
=== Pair programming ===
{{Confusing|date=June 2023|reason=the first sentence of the following paragraph seems to be an incomplete sentence. Where is the verb phrase?}}
[[Pair programming]] is a
The pairs are not fixed; programmers switch partners frequently, so that everyone knows what everyone is doing, and everybody remains familiar with the whole system, even the parts outside their skill set. This way, pair programming also can enhance team-wide communication. (This also goes hand-in-hand with the concept of Collective Ownership).
Line 112 ⟶ 113:
* Get a task card: The programmer gets the task card for one of the tasks to which he or she has committed.
* Find a
* Design the task: If needed, the programmers will design the functionality of the task.
* Implement the task using [[
* Run
=== Test driven development ===
Line 152 ⟶ 153:
=== Collective code ownership ===
{{main|Code ownership}}
Collective code ownership (also known as "team [[code ownership]]" and "shared code") means that everyone is responsible for all the code; therefore, everybody is allowed to change any part of the code. Collective code ownership is not only an organizational policy but also a feeling. "Developers feel team code ownership more when they understand the system context, have contributed to the code in question, perceive code quality as high, believe the product will satisfy the user needs, and perceive high team cohesion."<ref>{{cite book|last1=Sedano|first1=Todd|last2=Ralph|first2=Paul|last3=Péraire|first3=Cécile|title=Proceedings of the 20th International Conference on Evaluation and Assessment in Software Engineering|chapter=Practice and Perception of Team Code Ownership|year=2016|pages=1–6|chapter-url=http://dl.acm.org/citation.cfm?doid=2915970.2916002|publisher=ACM|doi=10.1145/2915970.2916002|isbn=9781450336918|s2cid=10016345}}</ref> Pair programming, especially overlapping pair rotation, contributes to this practice: by working in different pairs, programmers better understand the system context and contribute to more areas of the code base.
Collective code ownership may accelerate development because a developer who spots an error can fix it immediately, which can reduce bugs overall. However, programmers may also introduce bugs when changing code that they do not understand well. Sufficiently well-defined unit tests should mitigate this problem: if unforeseen dependencies create errors, then when unit tests are run, they will show failures.
Line 177 ⟶ 179:
== See also ==
* [[Continuous integration]]
* [[Multi-stage continuous integration]]
|