Miroirs/cooperative-software-development
1
0
Fork 0
mirror of https://github.com/amyjko/cooperative-software-development synced 2024-12-26 21:58:27 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions

Removed spaces in front of citations.

Browse source
This commit is contained in:
Amy J. Ko 2020-09-11 10:37:17 -07:00
parent 6bfb475a4d
commit 08a6e558ff
13 changed files with 83 additions and 83 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
chapters/evolution.md
View file

@ -4,7 +4,7 @@ Nowhere is this constant evolution more apparent then in our daily encounters wi
To manage change, developers use many kinds of tools and practices.
One of the most common ways of managing change is to *refactor* code. Refactoring helps developers modify the _architecture_ of a program while keeping its behavior the same, enabling them to implement or modify functionality more easily. For example, one of the most common and simple refactorings is to rename a variable (renaming its definition and all of its uses). This doesn't change the architecture of a program at all, but does improve its readability. Other refactors can be more complex. For example, consider adding a new parameter to a function: all calls to that function need to pass that new parameter, which means you need to go through each call and decide on a value to send from that call site. Studies of refactoring in practice have found that refactorings can be big and small, that they don't always preserve the behavior of a program, and that developers perceive them as involving substantial costs and risks<kim12>
One of the most common ways of managing change is to *refactor* code. Refactoring helps developers modify the _architecture_ of a program while keeping its behavior the same, enabling them to implement or modify functionality more easily. For example, one of the most common and simple refactorings is to rename a variable (renaming its definition and all of its uses). This doesn't change the architecture of a program at all, but does improve its readability. Other refactors can be more complex. For example, consider adding a new parameter to a function: all calls to that function need to pass that new parameter, which means you need to go through each call and decide on a value to send from that call site. Studies of refactoring in practice have found that refactorings can be big and small, that they don't always preserve the behavior of a program, and that developers perceive them as involving substantial costs and risks<kim12>.
Another fundamental way that developers manage change is *version control* systems. As you know, they help developers track changes to code, allowing them to revert, merge, fork, and clone projects in a way that is traceable and reliable. Version control systems also help developers identify merge conflicts, so that they don't accidentally override each others' work<nelson19>. While today the most popular version control system is Git, there are actually many types. Some are _centralized_, representing one single ground truth of a project's code, usually stored on a server. Commits to centralized repositories become immediately available to everyone else on a project. Other version control systems are _distributed_, such as Git, allowing one copy of a repository on every local machine. Commits to these local copies don't automatically go to everyone else; rather, they are pushed to some central copy, from which others can pull updates.