document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2024-12-26 21:30:55 +08:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #6027 from MonkeyDEcho/master

Browse Source 
MonekyDEcho Submit
This commit is contained in:
Xingyu.Wang 2017-09-03 15:25:31 +08:00 committed by GitHub
commit 56dd6848ff
4 changed files with 348 additions and 349 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

95
sources/talk/20170310 How to use pull requests to improve your code reviews.md
View File

@ -1,95 +0,0 @@
How to use pull requests to improve your code reviews
============================================================
Spend more time building and less time fixing with GitHub Pull Requests for proper code review.
![Measure](https://d3tdunqjn7n0wj.cloudfront.net/360x240/measure-106354_1920-a7f65d82a54323773f847cf572e640a4.jpg)
>Take a look Brent and Peter’s book, [ _Introducing GitHub_ ][5], for more on creating projects, starting pull requests, and getting an overview of your team’s software development process.
If you don’t write code every day, you may not know some of the problems that software developers face on a daily basis:
* Security vulnerabilities in the code
* Code that causes your application to crash
* Code that can be referred to as “technical debt” and needs to be re-written later
* Code that has already been written somewhere that you didn’t know about
Code review helps improve the software we write by allowing other people and/or tools to look it over for us. This review can happen with automated code analysis or test coverage tools — two important pieces of the software development process that can save hours of manual work — or peer review. Peer review is a process where developers review each other's work. When it comes to developing software, speed and urgency are two components that often result in some of the previously mentioned problems. If you don’t release soon enough, your competitor may come out with a new feature first. If you don’t release often enough, your users may doubt whether or not you still care about improvements to your application.
### Weighing the time trade-off: code review vs. bug fixing
If someone is able to bring together multiple types of code review in a way that has minimal friction, then the quality of that software written over time will be improved. It would be naive to think that the introduction of new tools or processes would not at first introduce some amount of delay in time. But what is more expensive: time to fix bugs in production, or improving the software before it makes it into production? Even if new tools introduce some lag time in which a new feature can be released and appreciated by customers, that lag time will shorten as the software developers improve their own skills and the software release cycles will increase back to previous levels while bugs should decrease.
One of the keys for achieving this goal of proactively improving code quality with code review is using a platform that is flexible enough to allow software developers to quickly write code, plug in the tools they are familiar with, and do peer review of each others’ code. [GitHub][9] is a great example of such a platform. However, putting your code on GitHub doesn’t just magically make code review happen; you have to open a pull request to start down this journey.
### Pull requests: a living discussion about code
[Pull requests][10] are a tool on GitHub that allows software developers to discuss and propose changes to the main codebase of a project that later can be deployed for all users to see. They were created back in February of 2008 for the purpose of suggesting a change on to someone’s work before it would be accepted (merged) and later deployed to production for end-users to see that change.
Pull requests started out as a loose way to offer your change to someone’s project, but they have evolved into:
* A living discussion about the code you want merged
* Added functionality of increasing the visibility of what changed
* Integration of your favorite tools
* Explicit pull request reviews that can be required as part of a protected branch workflow
### Considering code: URLs are forever
Looking at the first two bullet points above, pull requests foster an ongoing code discussion that makes code changes very visible, as well as making it easy to pick up where you left off on your review. For both new and experienced developers, being able to refer back to these previous discussions about why a feature was developed the way it was or being linked to another conversation about a related feature should be priceless. Context can be so important when coordinating features across multiple projects and keeping everyone in the loop as close as possible to the code is great too. If those features are still being developed, it’s important to be able to just see what’s changed since you last reviewed. After all, it’s far easier to [review a small change than a large one][11], but that’s not always possible with large features. So, it’s important to be able to pick up where you last reviewed and only view the changes since then.
### Integrating tools: software developers are opinionated
Considering the third point above, GitHub’s pull requests have a lot of functionality but developers will always have a preference on additional tools. Code quality is a whole realm of code review that involves the other component to code reviews that aren’t necessarily human. Detecting code that’s “inefficient” or slow, a potential security vulnerability, or just not up to company standards is a task best left to automated tools. Tools like [SonarQube][12] and [Code Climate][13]can analyse your code, while tools like [Codecov][14] and [Coveralls][15] can tell you if the new code you just wrote is not well tested. The wonder of these tools is that they can plug into GitHub and report their findings right back into the pull request! This means the conversation not only has people reviewing the code, but the tools are reporting there too. Everyone can stay in the loop of exactly how a feature is developing.
Lastly, depending on the preference of your team, you can make the tools and the peer review required by leveraging the required status feature of the [protected branch workflow][16].
Though you may just be getting started on your software development journey, a business stakeholder who wants to know how a project is doing, or a project manager who wants to ensure the timeliness and quality of a project, getting involved in the pull request by setting up an approval workflow and thinking about integration with additional tools to ensure quality is important at any level of software development.
Whether it’s for your personal website, your company’s online store, or the latest combine to harvest this year’s corn with maximum yield, writing good software involves having good code review. Having good code review involves the right tools and platform. To learn more about GitHub and the software development process, take a look at the O’Reilly book, [ _Introducing GitHub_ ][17], where you can understand creating projects, starting pull requests, and getting an overview of your team's’ software development process.
--------------------------------------------------------------------------------
作者简介：
**Brent Beer**
Brent Beer has used Git and GitHub for over 5 years through university classes, contributions to open source projects, and professionally as a web developer. While working as a trainer for GitHub, he also became a published author of “Introducing GitHub” for O’Reilly. He now works as a solutions engineer for GitHub in Amsterdam to help bring Git and GitHub to developers across the world.
**Peter Bell**
Peter Bell is the founder and CTO of Ronin Labs. Training is broken - we're fixing it through technology enhanced training! He is an experienced entrepreneur, technologist, agile coach and CTO specializing in EdTech projects. He wrote "Introducing GitHub" for O'Reilly, created the "Mastering GitHub" course for code school and "Git and GitHub LiveLessons" for Pearson. He has presented regularly at national and international conferences on ruby, nodejs, NoSQL (especially MongoDB and neo4j), cloud computing, software craftsmanship, java, groovy, j...
-------------
via: https://www.oreilly.com/ideas/how-to-use-pull-requests-to-improve-your-code-reviews?imm_mid=0ee8ca&cmp=em-prog-na-na-newsltr_20170311
作者：[Brent Beer][a]，[Peter Bell][b]
译者：[译者ID](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]:https://www.oreilly.com/people/acf937de-cdf4-4b0e-85bd-b559404c580e
[b]:https://www.oreilly.com/people/2256f119-7ea0-440e-99e8-65281919e952
[1]:https://pixabay.com/en/measure-measures-rule-metro-106354/
[2]:http://conferences.oreilly.com/oscon/oscon-tx?intcmp=il-prog-confreg-update-ostx17_new_site_oscon_17_austin_right_rail_cta
[3]:https://www.oreilly.com/people/acf937de-cdf4-4b0e-85bd-b559404c580e
[4]:https://www.oreilly.com/people/2256f119-7ea0-440e-99e8-65281919e952
[5]:https://www.safaribooksonline.com/library/view/introducing-github/9781491949801/?utm_source=newsite&utm_medium=content&utm_campaign=lgen&utm_content=how-to-use-pull-requests-to-improve-your-code-reviews
[6]:http://conferences.oreilly.com/oscon/oscon-tx?intcmp=il-prog-confreg-update-ostx17_new_site_oscon_17_austin_right_rail_cta
[7]:http://conferences.oreilly.com/oscon/oscon-tx?intcmp=il-prog-confreg-update-ostx17_new_site_oscon_17_austin_right_rail_cta
[8]:https://www.oreilly.com/ideas/how-to-use-pull-requests-to-improve-your-code-reviews?imm_mid=0ee8ca&cmp=em-prog-na-na-newsltr_20170311
[9]:https://github.com/about
[10]:https://help.github.com/articles/about-pull-requests/
[11]:https://blog.skyliner.io/ship-small-diffs-741308bec0d1
[12]:https://github.com/integrations/sonarqube
[13]:https://github.com/integrations/code-climate
[14]:https://github.com/integrations/codecov
[15]:https://github.com/integrations/coveralls
[16]:https://help.github.com/articles/about-protected-branches/
[17]:https://www.safaribooksonline.com/library/view/introducing-github/9781491949801/?utm_source=newsite&utm_medium=content&utm_campaign=lgen&utm_content=how-to-use-pull-requests-to-improve-your-code-reviews-lower

254
sources/tech/20170403 Introduction to functional programming.md
View File

@ -1,254 +0,0 @@
MonkeyDEcho translating
Introduction to functional programming
============================================================
> We explain what functional programming is, explore its benefits, and look at resources for learning functional programming.
![Introduction to functional programming ](https://opensource.com/sites/default/files/styles/image-full-size/public/images/life/lightbulb_computer_person_general_.png?itok=ZY3UuQQa "Introduction to functional programming ")
Image by : 
opensource.com
Depending on whom you ask,  _functional programming_  (FP) is either an enlightened approach to programming that should be spread far and wide, or an overly academic approach to programming with few real-world benefits. In this article, I will explain what functional programming is, explore its benefits, and recommend resources for learning functional programming.
### Syntax primer
Code examples in this article are in the [Haskell][40] programming language. All that you need to understand for this article is the basic function syntax:
```
even :: Int -> Bool
even = ... -- implementation goes here
```
This defines a one-argument function named **even**. The first line is the  _type declaration_ , which says that **even** takes an **Int** and returns a **Bool**. The implementation follows and consists of one or more  _equations_ . We'll ignore the implementation (the name and type tell us enough):
```
map :: (a -> b) -> [a] -> [b]
map = ...
```
In this example, **map** is a function that takes two arguments:
1. **(a -> b)**: a functions that turns an **a** into a **b**
2. **[a]**: a list of **a**
and returns a list of **b**. Again, we don't care about the definition—the type is more interesting! **a** and **b** are  _type variables_  that could stand for any type. In the expression below, **a** is **Int** and **b** is **Bool**:
```
  map even [1,2,3]
```
It evaluates to a **[Bool]**:
```
  [False,True,False]
```
If you see other syntax that you do not understand, don't panic; full comprehension of the syntax is not essential.
### Myths about functional programming
Programming and development
* [Our latest JavaScript articles][1]
* [Recent Perl posts][2]
* [New Python content][3]
* [Red Hat Developers Blog][4]
* [Tools for Red Hat Developers][5]
Let's begin by dispelling common misconceptions:
* Functional programming is not the rival or antithesis of imperative or object-oriented programming. This is a false dichotomy.
* Functional programming is not just the domain of academics. It is true that the history of functional programming is steeped in academia, and languages such as like Haskell and OCaml are popular research languages. But today many companies use functional programming for large-scale systems, small specialized programs, and everything in between. There's even an annual conference for [Commercial Users of Functional Programming][33]; past programs give an insight into how functional programming is being used in industry, and by whom.
* Functional programming has nothing to do with [monads][34], nor any other particular abstraction. For all the hand-wringing around this topic, monad is just an abstraction with laws. Some things are monads, others are not.
* Functional programming is not especially hard to learn. Some languages may have different syntax or evaluation semantics from those you already know, but these differences are superficial. There are dense concepts in functional programming, but this is also true of other approaches.
### What is functional programming?
At its core, functional programming is just programming with functions— _pure_  mathematical functions. The result of a function depends only on the arguments, and there are no side effects, such as I/O or mutation of state. Programs are built by combining functions together. One way of combining functions is  _function composition_ :
```
(.) :: (b -> c) -> (a -> b) -> (a -> c)
(g . f) x = g (f x)
```
This  _infix_  function combines two functions into one, applying **g** to the output of **f**. We'll see it used in an upcoming example. For comparison, the same function in Python looks like:
```
def compose(g, f):
return lambda x: g(f(x))
```
The beauty of functional programming is that because functions are deterministic and have no side effects, you can always replace a function application with the result of the application. This substitution of equals for equals enables  _equational reasoning_ . Every programmer has to reason about their code and others', and equational reasoning is a great tool for doing that. Let's look at an example. You encounter the expression:
```
  map even . map (+1)
```
What does this program do? Can it be simplified? Equational reasoning lets you analyze the code through a series of substitutions:
```
map even . map (+1)
map (even . (+1)) -- from definition of 'map'
map (\x -> even (x + 1)) -- lambda abstraction
map odd -- from definition of 'even'
```
We can use equational reasoning to understand programs and optimize for readability. The Haskell compiler uses equational reasoning to perform many kinds of program optimizations. Without pure functions, equational reasoning either isn't possible, or requires an inordinate effort from the programmer.
### Functional programming languages
What do you need from a programming language to be able to do functional programming?
Doing functional programming meaningfully in a language without  _higher-order functions_  (the ability to pass functions as arguments and return functions),  _lambdas_  (anonymous functions), and  _generics_  is difficult. Most modern languages have these, but there are differences in  _how well_  different languages support functional programming. The languages with the best support are called  _functional programming languages_ . These include  _Haskell_ ,  _OCaml_ ,  _F#_ , and  _Scala_ , which are statically typed, and the dynamically typed  _Erlang_  and  _Clojure_ .
Even among functional languages there are big differences in how far you can exploit functional programming. Having a type system helps a lot, especially if it supports  _type inference_  (so you don't always have to type the types). There isn't room in this article to go into detail, but suffice it to say, not all type systems are created equal.
As with all languages, different functional languages emphasize different concepts, techniques, or use cases. When choosing a language, considering how well it supports functional programming and whether it fits your use case is important. If you're stuck using some non-FP language, you will still benefit from applying functional programming to the extent the language supports it.
### Don't open that trap door!
Recall that the result of a function depends only on its inputs. Alas, almost all programming languages have "features" that break this assumption. Null values, type case (**instanceof**), type casting, exceptions, side-effects, and the possibility of infinite recursion are trap doors that break equational reasoning and impair a programmer's ability to reason about the behavior or correctness of a program. ( _Total languages_ , which do not have any trap doors, include Agda, Idris, and Coq.)
Fortunately, as programmers, we can choose to avoid these traps, and if we are disciplined, we can pretend that the trap doors do not exist. This idea is called  _fast and loose reasoning_ . It costs nothing—almost any program can be written without using the trap doors—and by avoiding them you win back equational reasoning, composability and reuse.
Let's discuss exceptions in detail. This trap door breaks equational reasoning because the possibility of abnormal termination is not reflected in the type. (Count yourself lucky if the documentation even mentions the exceptions that could be thrown.) But there is no reason why we can't have a return type that encompasses all the failure modes.
Avoiding trap doors is an area in which language features can make a big difference. For avoiding exceptions,  _algebraic data types_  can be used to model error conditions, like so:
```
-- new data type for results of computations that can fail
--
data Result e a = Error e | Success a
-- new data type for three kinds of arithmetic errors
--
data ArithError = DivByZero | Overflow | Underflow
-- integer division, accounting for divide-by-zero
--
safeDiv :: Int -> Int -> Result ArithError Int
safeDiv x y =
if y == 0
then Error DivByZero
else Success (div x y)
```
The trade-off in this example is that you must now work with values of type **Result ArithError Int** instead of plain old **Int**, but there are abstractions for dealing with this. You no longer need to handle exceptions and can use fast and loose reasoning, so overall it's a win.
### Theorems for free
Most modern statically typed languages have  _generics_  (also called  _parametric polymorphism_ ), where functions are defined over one or more abstract types. For example, consider a function over lists:
```
f :: [a] -> [a]
f = ...
```
The same function in Java looks like:
```
  static <A> List<A> f(List<A> xs) { ... }
```
The compiled program is a proof that this function will work with  _any_  choice for the type **a**. With that in mind, and employing fast and loose reasoning, can you work out what the function does? Does knowing the type help?
In this case, the type doesn't tell us exactly what the function does (it could reverse the list, drop the first element, or many other things), but it does tell us a lot. Just from the type, we can derive theorems about the function:
* **Theorem 1**: Every element in the output appears in the input; it couldn't possibly add an **a** to the list because it has no knowledge of what **a** is or how to construct one.
* **Theorem 2**: If you map any function over the list then apply **f**, the result is the same as applying **f** then mapping.
Theorem 1 helps us understand what the code is doing, and Theorem 2 is useful for program optimization. We learned all this just from the type! This result—the ability to derive useful theorems from types—is called  _parametricity_ . It follows that a type is a partial (sometimes complete) specification of a function's behavior, and a kind of machine-checked documentation.
Now it's your turn to exploit parametricity. What can you conclude from the types of **map** and **(.)**, or the following functions?
* **foo :: a -> (a, a)**
* **bar :: a -> a -> a**
* **baz :: b -> a -> a**
### Resources for learning functional programming
Perhaps you have been convinced that functional programming is a better way to write software, and you are wondering how to get started? There are several approaches to learning functional programming; here are some I recommend (with, I admit, a strong bias toward Haskell):
* UPenn's [CIS 194: Introduction to Haskell][35] is a solid introduction to functional programming concepts and real-world Haskell development. The course material is available, but the lectures are not (you could view Brisbane Functional Programming Group's [series of talks covering CIS 194][36] from a few years ago instead).
* Good introductory books include  _[Functional Programming in Scala][30]_ ,  _[Thinking Functionally with Haskell][31]_ , and  _[Haskell Programming from first principles][32]_ .
* The [Data61 FP course][37] (f.k.a.,  _NICTA_  course) teaches foundational abstractions and data structures through  _type-driven development_ . The payoff is huge, but it is  _difficult by design_ , having its origins in training workshops, so only attempt it if you know a functional programmer who is willing to mentor you.
* Start practicing functional programming in whatever code you're working on. Write pure functions (avoid non-determinism and mutation), use higher-order functions and recursion instead of loops, exploit parametricity for improved readability and reuse. Many people start out in functional programming by experimenting and experiencing the benefits in all kinds of languages.
* Join a functional programming user group or study group in your area—or start one—and look out for functional programming conferences (new ones are popping up all the time).
### Conclusion
In this article, I discussed what functional programming is and is not, and looked at advantages of functional programming, including equational reasoning and parametricity. We learned that you can do  _some_  functional programming in most programming languages, but the choice of language affects how much you can benefit, with  _functional programming languages_ , such as Haskell, having the most to offer. I also recommended resources for learning functional programming.
Functional programming is a rich field and there are many deeper (and denser) topics awaiting exploration. I would be remiss not to mention a few that have practical implications, such as:
* lenses and prisms (first-class, composable getters and setters; great for working with nested data);
* theorem proving (why test your code when you could  _prove it correct_  instead?);
* lazy evaluation (lets you work with potentially infinite data structures);
* and category theory (the origin of many beautiful and practical abstractions in functional programming).
I hope that you have enjoyed this introduction to functional programming and are inspired to dive into this fun and practical approach to software development.
_This article is published under the [CC BY 4.0][38] license._
--------------------------------------------------------------------------------
作者简介：
Software Engineer at Red Hat. Interested in functional programming, category theory and other intersections of math and programming. Crazy about jalapeños.
----------------------
via: https://opensource.com/article/17/4/introduction-functional-programming
作者：[Fraser Tweedale ][a]
译者：[译者ID](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]:https://opensource.com/users/frasertweedale
[1]:https://opensource.com/tags/javascript?src=programming_resource_menu
[2]:https://opensource.com/tags/perl?src=programming_resource_menu
[3]:https://opensource.com/tags/python?src=programming_resource_menu
[4]:https://developers.redhat.com/?intcmp=7016000000127cYAAQ&src=programming_resource_menu
[5]:https://developers.redhat.com/products/#developer_tools?intcmp=7016000000127cYAAQ&src=programming_resource_menu
[6]:http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#t:Int
[7]:http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#t:Int
[8]:http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#t:Int
[9]:http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:div
[10]:http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:even
[11]:http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#t:Int
[12]:http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#t:Bool
[13]:http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:even
[14]:http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:map
[15]:http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:map
[16]:http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:map
[17]:http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:even
[18]:http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:map
[19]:http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:even
[20]:http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:map
[21]:http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:map
[22]:http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:even
[23]:http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:map
[24]:http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:map
[25]:http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:even
[26]:http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:map
[27]:http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:even
[28]:http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:map
[29]:http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:odd
[30]:https://www.manning.com/books/functional-programming-in-scala
[31]:http://www.cambridge.org/gb/academic/subjects/computer-science/programming-languages-and-applied-logic/thinking-functionally-haskell
[32]:http://haskellbook.com/
[33]:http://cufp.org/
[34]:https://www.haskell.org/tutorial/monads.html
[35]:https://www.cis.upenn.edu/~cis194/fall16/
[36]:https://github.com/bfpg/cis194-yorgey-lectures
[37]:https://github.com/data61/fp-course
[38]:https://creativecommons.org/licenses/by/4.0/
[39]:https://opensource.com/article/17/4/introduction-functional-programming?rate=_tO5hNzT4hRKNMJtWwQM-K3Jmxm10iPeqoy3bbS12MQ
[40]:https://wiki.haskell.org/Introduction
[41]:https://opensource.com/user/123116/feed
[42]:https://opensource.com/users/frasertweedale

95
translated/talk/20170310 How to use pull requests to improve your code reviews.md Normal file
View File

@ -0,0 +1,95 @@
如何使用 pull requests 来改善你的代码审查
============================================================
在 Github 上使用 pull requests 来做代码审查，花费更多的时间去构建，而更少的时间去修改。
![Measure](https://d3tdunqjn7n0wj.cloudfront.net/360x240/measure-106354_1920-a7f65d82a54323773f847cf572e640a4.jpg)
>看看 Brent 和 Peter’s 的[ _Introducing GitHub_ ][5]的书, 了解更多有关创建项目，开始 pull requests 和团队软件开发流程的概述。
如果你每天不编写代码，你可能不知道软件开发人员每天面临的一些问题。
* 代码中的安全漏洞
* 导致应用程序崩溃的代码
* 被称作 “技术债务” 和之后需要重写的代码
* 已经重写在你所不知道地方的代码
代码审查可以允许其他人和工具检查来帮助我们改善所编写的软件。这种审查通过自动化代码分析或者测试覆盖工具来进行软件开发过程中重要的二个部分，节省数小时的手工劳动或同行评审。同行的审查是开发人员审查彼此工作的过程。在软件开发的过程中，速度和紧迫性是经常面临的问题中二个重要的部分。如果你没有尽快的发布，你的竞争对手可能会在你之前发布相似的产品。如果你不经常发不新的版本，你的用户可能会怀疑您是否仍然关心你的应用程序的改进优化。
### 衡量时间权衡：代码审查 vs. bug 修复
如果有人能够以最小争议的方式汇集多种类型的代码审查，那么随着时间的推移，该软件的质量将会得到改善。认为引入新的工具或流程在最初不会推迟时间，这是天真的想法。但是更昂贵的是：修复生产中的错误的时候，在还是软件生产之前改进软件，即使新工具延迟了时间，客户可以发布和欣赏新功能，随着软件开发人员提高自己的技能，软件开发周期将会回升到以前的水平，同时应该减少错误。
通过代码审查实现提升代码质量目标的关键之一就是使用一个足够灵活的平台，允许软件开发人员快速编写代码，使用他们熟悉的工具，并行彼此进行同行评审码。 GitHub 就是这样一个平台的。然而，把你的代码放在 [GitHub][9] 上并不只是神奇地使代码审查发生; 你必须使用 pull requests ，来开始这个美妙的旅程。
### Pull requests: 一个代码的生活讨论的工具
[Pull requests][10] 是 Github 上的一个工具，允许软件开发人员讨论并提出对项目的主要代码库的更改，稍后可以让所用用户看到。它们在 2008 年 2 月创建的，目的是在接受（合并）某人之前的建议进行更改，然后在部署到生产中，供最终用户看到这种变化。
Pull requests 开始是一种松散的方式为某人的项目提供改变，但是它已经演变成：
* 关于你想要合并的代码的生活讨论
* 增加功能，这种可见性的修改（更改）
* 整合你最喜爱的工具
* 作为受保护的分支工作流程的一部分可能需要显式提取请求评估
### 考虑带代码: URL 是永久的
看看上面的前两个点，pull requests 促成了一个正在进行的代码讨论，使代码变化非常明显，并且使您很容易在回顾的过程中找到所需的代码。对于新人和有经验的开发人员来说，能够回顾以前的讨论，了解为什么一个功能被开发出来，或者与另一个关于相关功能的讨论这样的联系方式是便捷的。当跨多个项目协调功能并使每个人尽可能接近代码时，前后讨论的内容也非常重要。如果这些功能仍在开发中，重要的是能够看到上次审查以来更改了哪些内容。毕竟，[对小的更改比大的修改要容易得多][11]，但大的功能并不总是可能的。因此，重要的是能够拿起你上次审查，并只看到从那时以来的变化。
### 集成工具: 软件开发人员的建议
考虑到上述第三点，GitHub 上的 pull requests 有很多功能，但开发人员将始终对第三方工具有偏好。代码质量是代码审查的整个领域，涉及到其他组件的代码评审，而这些评审不一定是人的。检测“低效”或缓慢、潜在的安全漏洞或不符合公司标准的代码是留给自动化工具的任务。
[SonarQube][12] 和 [Code Climatecan][13] 分析你的代码的工具，而像 [Codecov][14] 和 [Coveralls][15] 的工具可以告诉你如果你只是写新代码没有得到很好的测试。这些令人惊奇工具最大的特点就是，他们可以插到 GitHub 和 pull requests 报告他们的发现！这意味着不仅让人们检查代码，而且工具也在那里报告情况。每个人都可以停留在一个如何发展循环中的功能。
最后，根据您的团队的偏好，您可以利用[受保护的分支工作流][16]所需的状态特性来进行工具和同行评审。
虽然您可能只是开始您的软件开发之旅，一个希望知道一个项目正在做什么的业务利益相关者，或者是想要确保项目的及时性和质量的项目经理，可以通过设置参与 pull requests 批准工作流程，并考虑与其他工具集成以确保质量，在任何级别的软件开发中都很重要。
无论是为您的个人网站，贵公司的在线商店，还是最新的组合，以最大的收益收获今年的玉米，编写好的软件都需要进行良好的代码审查。良好的代码审查涉及到正确的工具和平台。要了解有关 GitHub 和软件开发过程的更多信息，请参阅 O'Reilly 的 [ _GitHub 简介_ ][17] 一书， 您可以在其中了解创建项目，启动拉取请求以及概述团队的“软件开发流程”。
--------------------------------------------------------------------------------
作者简介：
**Brent Beer**
Brent Beer 使用 Git 和 GitHub 已经超过五年了，通过大学的课程，对开源项目的贡献，以及专业网站开发人员。在担任 GitHub 上的培训师时，他也成为 O’Reilly 的 “GitHub简介” 的出版作者。他现在担任 Amsterdam GitHub 上的解决方案工程师，帮助 Git 和 GitHub 向世界各地的开发人员提供服务。
**Peter Bell**
Peter Bell 是 Ronin 实验室的创始人以及 CTO。Training is broken - we're fixing it through technology enhanced training!他是一位有经验的企业家，技术专家，敏捷教练和CTO，专门从事 EdTech 项目。他为 O'Reilly 撰写了 “ GitHub 简介” ，为代码学校创建了“掌握 GitHub ”课程，为 Pearson 创建了“ Git 和 GitHub LiveLessons ”课程。他经常在国际和国际会议上提供 ruby ， nodejs ， NoSQL （尤其是 MongoDB 和 neo4j ），云计算，软件工艺，java，groovy，j ...
-------------
via: https://www.oreilly.com/ideas/how-to-use-pull-requests-to-improve-your-code-reviews?imm_mid=0ee8ca&cmp=em-prog-na-na-newsltr_20170311
作者：[Brent Beer][a]，[Peter Bell][b]
译者：[MonkeyDEcho](https://github.com/MonkeyDEcho)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]:https://www.oreilly.com/people/acf937de-cdf4-4b0e-85bd-b559404c580e
[b]:https://www.oreilly.com/people/2256f119-7ea0-440e-99e8-65281919e952
[1]:https://pixabay.com/en/measure-measures-rule-metro-106354/
[2]:http://conferences.oreilly.com/oscon/oscon-tx?intcmp=il-prog-confreg-update-ostx17_new_site_oscon_17_austin_right_rail_cta
[3]:https://www.oreilly.com/people/acf937de-cdf4-4b0e-85bd-b559404c580e
[4]:https://www.oreilly.com/people/2256f119-7ea0-440e-99e8-65281919e952
[5]:https://www.safaribooksonline.com/library/view/introducing-github/9781491949801/?utm_source=newsite&utm_medium=content&utm_campaign=lgen&utm_content=how-to-use-pull-requests-to-improve-your-code-reviews
[6]:http://conferences.oreilly.com/oscon/oscon-tx?intcmp=il-prog-confreg-update-ostx17_new_site_oscon_17_austin_right_rail_cta
[7]:http://conferences.oreilly.com/oscon/oscon-tx?intcmp=il-prog-confreg-update-ostx17_new_site_oscon_17_austin_right_rail_cta
[8]:https://www.oreilly.com/ideas/how-to-use-pull-requests-to-improve-your-code-reviews?imm_mid=0ee8ca&cmp=em-prog-na-na-newsltr_20170311
[9]:https://github.com/about
[10]:https://help.github.com/articles/about-pull-requests/
[11]:https://blog.skyliner.io/ship-small-diffs-741308bec0d1
[12]:https://github.com/integrations/sonarqube
[13]:https://github.com/integrations/code-climate
[14]:https://github.com/integrations/codecov
[15]:https://github.com/integrations/coveralls
[16]:https://help.github.com/articles/about-protected-branches/
[17]:https://www.safaribooksonline.com/library/view/introducing-github/9781491949801/?utm_source=newsite&utm_medium=content&utm_campaign=lgen&utm_content=how-to-use-pull-requests-to-improve-your-code-reviews-lower

253
translated/tech/20170403 Introduction to functional programming.md Normal file
View File

@ -0,0 +1,253 @@
函数式编程简介
============================================================
> 我们来解释函数式编程的什么，它的优点是哪些，并且寻找一些函数式编程的学习资源。
![Introduction to functional programming ](https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/lightbulb_computer_person_general_.png?itok=BRGJXU7e" 函数式编程简介 ")
图片来源于: 
opensource.com
根据您的问题来回答,  _函数式编程_  (FP) 是一种开放的程序设计方法，理应广泛传播或者流行于理论学术中，在现实中没有实际的作用。在这篇文章中我来讲解函数式编程，探究其优点，并推荐学习函数式编程的资源。
### 语法入门
本文的代码示例使用的是 [Haskell][40] 编程语言。因而你需要理解这篇文章的基本函数语法：
```
even :: Int -> Bool
even = ... -- implementation goes here
```
示例定义了含有一个参数的函数 **even** ，第一行是 _类型声明_ 具体来说就是 **even** 函数接受一个 int 类型的参数返回一个 bool 类型的值，由一个或多个方法实现，在这里我们将忽略具体实现方法（名称和类型已经足够了）：
```
map :: (a -> b) -> [a] -> [b]
map = ...
```
这个示例, **map** 是一个有两个参数的函数:
1. **(a -> b)** : 将**a** 转换成 **b** 的匿名函数
2. **［a］**: 将匿名函数作用到 **［a］** （List 序列与其它语言的数组对应）的每一个元素上，将每次所得结果放到另一个 **［b］** ,最后返回这个结果 **［b］** 。
同样我们不去关心是要如何实现，我们只感兴趣它的定义类型。
**a** 和 **b** 是任何一种的的 _类型变量_ 。就像上一个示例中， **a** 是 **Int** 类型， **b** 是 **Bool** 类型:
```
  map even [1,2,3]
```
这个是一个bool类型的序列:
```
  [False,True,False]
```
如果你看到你不理解的其他语法，不要惊慌；对语法的充分理解不是必要的。
### 函数式编程的误区
编程与开发
* [我们最新的 JavaScript 文章][1]
* [最近 Perl 的帖子][2]
* [新的 Python 内容][3]
* [红帽开发者博客][4]
* [红帽开发者工具][5]
我们先来解释一下常见的误区：
* 函数式编程不是像命令行编程或者面向对象编程一样对立，这些都是虚假的。
* 函数式编程不仅仅是学术领域在其他领域也有使用。这是真的，在函数式编程的历史中，如像Haskell和OCaml语言是最流行的研究。但是今天许多公司使用函数式编程来处理大型系统，小型专业程序，以及两者之间的一切。甚至还有一个面向函数式编程的商业用户的年度会议；过去的程序让我们了解了函数式编程在工业中的用途，以及由谁来使用它。
* 函数式编程与monads无关 ，也不是任何其他特殊的抽象。对于围绕这个monad只是一个抽象的规定，有些是有些也的不是。
* 函数式编程不是特别难学的。有些语言可能与您已经知道的语法不同，但这些差异是浅显的。函数式编程中有dense的概念，但其他方法也是如此。（这里的dense不懂什么意思，校对者注意一下）
### 什么是函数式编程?
核心是函数式编程是只使用_纯粹_的数学函数编程，函数的结果取决于参数，就像 I/O 或者状态转换这样。程序是通过 _组合函数_ 的方法构建的:
```
(.) :: (b -> c) -> (a -> b) -> (a -> c)
(g . f) x = g (f x)
```
这个_（.）_ 表示的是二个函数组合成一个，将 **g** 作用到 **f** 上。我们将在下一个示例中看到它的使用。这里使用 Python 中的函数:
```
def compose(g, f):
return lambda x: g(f(x))
```
函数式编程的优点在于：由于函数是确定的，所以可以用应用程序的结果替换函数，这种替代等价于使用使 _等式推理_ 。每个程序员都有使用自己代码和别人代码的理由，而等式推理就是解决这样问题不错的工具。来看一个示例。等你遇到这个问题:
```
  map even . map (+1)
```
这段代码是做什么的？可以简化吗？通过等式推理，可以通过一系列替换来分析代码:
```
map even . map (+1)
map (even . (+1)) -- from definition of 'map'
map (\x -> even (x + 1)) -- lambda abstraction
map odd -- from definition of 'even'
```
我们可以使用等式推理来理解程序并优化。Haskell编译器使用等式推理进行多种方案的优化。没有纯粹的函数，等式推理是不可能的，或者需要程序员更多的努力。
### 函数式编程语言
你需要一种编程语言来做函数式编程。
在没有高阶函数（传递函数作为参数和返回函数的能力）的语言中有意义地进行函数式编程， _lambdas_ （匿名函数）和泛型是困难的。 大多数现代语言都有这些，但在不同语言支持函数式编程方面存在差异。 具有最佳支持的语言称为函数式编程语言。 这些包括静态类型的 _Haskell_， _OCaml_ ， _F＃_ 和 _Scala_ ，动态类型的 _Erlang_ 和 _Clojure_。
在函数式语言之间可以在多大程度上利用函数编程有很大差异。有一个类型系统会有很大的帮助，特别是它支持 _类型推断_ （所以你并不总是必须键入类型）。这篇文章中没有详细介绍这部分，但足以说明，并非所有类型的系统都是平等的。
与所有语言一样，不同的函数的语言强调不同的概念，技术或用例。选择语言时，考虑到它支持函数式编程的程度以及是否适合您的用例很重要。如果您使用某些非 FP 语言，会受益于在语言支持的范围内的函数式编程。
### 不要打开表面没什么但却是陷阱的门
回想一下，函数的结果只取决于它的输入。几乎所有的编程语言都有这个。空值，类型case（instanceof），类型转换，异常以及无限递归的可能性都是陷阱，它打破等式推理，并削弱程序员对程序行为正确性的理解能力。（没有任何陷阱的语言包括Agda，Idris和Coq。）
幸运的是，作为程序员，我们可以选择避免这些陷阱，如果我们受到严格的规范，我们可以假装陷阱不存在。 这个方法叫做 _快速推理_ 。它不需要任何条件，几乎任何程序都可以在不使用陷阱的情况下进行编写，并且通过避免这些程序可以进行等式推理，可组合性和可重用性。
让我们详细讨论一下。 这个陷阱打破了等式推理，因为异常终止的可能性没有反映在类型中。（如果文档中提到可能抛出的异常，请自己计算一下）。但是没有理由我们无法包含所有故障模式的返回类型。
避开陷阱是语言特征中产生巨大影响的一个领域。为避免例外， 代数数据类型可用于模型误差的条件下，就像:
```
-- new data type for results of computations that can fail
--
data Result e a = Error e | Success a
-- new data type for three kinds of arithmetic errors
--
data ArithError = DivByZero | Overflow | Underflow
-- integer division, accounting for divide-by-zero
--
safeDiv :: Int -> Int -> Result ArithError Int
safeDiv x y =
if y == 0
then Error DivByZero
else Success (div x y)
```
在这个例子中的权衡你现在必须使用ArithError 或者 Int 类型为结果,而不是旧的 Int 的值，但这也是解决这个问题的一种方式。你不再需要处理异常，使用 _快速推理_ ，总体来说这是一个胜利。
### 免费的定理
大多数现代静态类型语言具有 _范型_（也称为 _参数多态性_ ），其中函数是通过一个或多个抽象类型定义的。 例如，考虑List（序列）上的函数:
```
f :: [a] -> [a]
f = ...
```
Java中的相同函数如下所示:
```
  static <A> List<A> f(List<A> xs) { ... }
```
编译程序的过程是一个证明的过程是将 _a_ 类型做出选择的过程。考虑到这一点，采用快速推理的方法，你能够创造出怎样的函数。
在这种情况下，该类型并不能告诉我们函数的功能（它可以改变序列，删除第一个元素或许多其他的东西），但它确实告诉了我们很多信息。只是从类型，我们可以得出关于函数的定理：
* **Theorem 1**: 输入决定输出；不可能在输入的序列 **a** 中添加值，因为你不知道它的数据结构。
* **Theorem 2**: If you map any function over the list then apply **f**, the result is the same as applying **f** then mapping.
定理1帮助我们了解代码的作用，定理2对于程序优化提供了帮助。我们从类型中学到了这一切！从类型中获取有用的信息称为参数。因此，类型是函数行为的部分（有时是完整的）规范，也是一种检查机制。
现在你可以利用参数话了探寻了。你可以从 **map**  **(.)** 或者下面的这些函数中发现什么呢？
* **foo :: a -> (a, a)**
* **bar :: a -> a -> a**
* **baz :: b -> a -> a**
### 学习功能编程的资源
也许你已经相信函数式编程是编写软件不错的方式，你想知道如何开始？有几种学习功能编程的方法; 这里有一些我推荐（我承认，我对 Haskell 偏爱：
* UPenn's 的 [CIS 194: 介绍 Haskell][35] 是函数式编程概念和 Haskell 开发的不错选择。可以当课程材料使用，讲座（您可以查看几年前 Brisbane 函数式编程小组的 [系列 CIS 194 讲座][36]。
* 不错的入门书籍有 _[ Scala 的函数式编程][30]_ ,  _[ Haskell 对函数的思考][31]_ , 和  _[ Haskell 编程原理][32]_ .
* [Data61 FP 课程][37] (f.k.a.,  _NICTA_  课程) 通过 _类型驱动_ 开发来教授抽象和数据结构的概念。这是十分困难，但收获也是丰富的，如果你有一名愿意引导你函数式编程的程序员，你可以尝试。
* 在你的工作学习中使用函数式编程书写代码，写一些纯粹的函数（避免不确定性和异常的出现），使用高阶函数而不是循环和递归，利用参数化来提高可读性和重用性。许多人从函数式编程开始，体验各种语言的美妙。
* 加入到你区域中的一些函数式编程小组或者学习小组中，也可以是参加一些函数式编程的会议（新的会议总是不断的出现）。
### 总结
在本文中，我讨论了什么是函数式编程，而不是函数式编程的优点，包括等式推理和参数化。我们了解到在大多数编程语言中执行一些函数编程，但是语言的选择会影响受益的程度，而 Haskell 是函数式编程中语言最受欢迎的语言。我也推荐学习函数式编程的资源。
函数式编程是一个丰富的领域，还有许多更深入（更神秘）的主题正在等待探索。我没有提到那些具有实际意义的事情，比如：
* lenses and prisms (是一流的设置值的方式；非常适合使用嵌套数据);
* 定理证明 (当测试你代码的时候你可以你代码的正确性);
* 懒惰评估 (让您处理潜在无数的数据结构);
* 类型理论 (函数式编程中许多美丽实用的抽象的起源).
我希望你喜欢这个函数式编程的介绍，并且启发你使用这个有趣和实用的软件开发方法。
_本文根据 [CC BY 4.0][38] 许可证发布。_
--------------------------------------------------------------------------------
作者简介：
红帽软件工程师。对函数式编程，分类理论，数学感兴趣。Crazy about jalapeños.
----------------------
via: https://opensource.com/article/17/4/introduction-functional-programming
作者：[Fraser Tweedale ][a]
译者：[MonkeyDEcho](https://github.com/MonkeyDEcho)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]:https://opensource.com/users/frasertweedale
[1]:https://opensource.com/tags/javascript?src=programming_resource_menu
[2]:https://opensource.com/tags/perl?src=programming_resource_menu
[3]:https://opensource.com/tags/python?src=programming_resource_menu
[4]:https://developers.redhat.com/?intcmp=7016000000127cYAAQ&src=programming_resource_menu
[5]:https://developers.redhat.com/products/#developer_tools?intcmp=7016000000127cYAAQ&src=programming_resource_menu
[6]:http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#t:Int
[7]:http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#t:Int
[8]:http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#t:Int
[9]:http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:div
[10]:http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:even
[11]:http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#t:Int
[12]:http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#t:Bool
[13]:http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:even
[14]:http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:map
[15]:http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:map
[16]:http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:map
[17]:http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:even
[18]:http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:map
[19]:http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:even
[20]:http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:map
[21]:http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:map
[22]:http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:even
[23]:http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:map
[24]:http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:map
[25]:http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:even
[26]:http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:map
[27]:http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:even
[28]:http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:map
[29]:http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:odd
[30]:https://www.manning.com/books/functional-programming-in-scala
[31]:http://www.cambridge.org/gb/academic/subjects/computer-science/programming-languages-and-applied-logic/thinking-functionally-haskell
[32]:http://haskellbook.com/
[33]:http://cufp.org/
[34]:https://www.haskell.org/tutorial/monads.html
[35]:https://www.cis.upenn.edu/~cis194/fall16/
[36]:https://github.com/bfpg/cis194-yorgey-lectures
[37]:https://github.com/data61/fp-course
[38]:https://creativecommons.org/licenses/by/4.0/
[39]:https://opensource.com/article/17/4/introduction-functional-programming?rate=_tO5hNzT4hRKNMJtWwQM-K3Jmxm10iPeqoy3bbS12MQ
[40]:https://wiki.haskell.org/Introduction
[41]:https://opensource.com/user/123116/feed
[42]:https://opensource.com/users/frasertweedale