From 8d4df103d9880b9d33717f79836f8f2efda80692 Mon Sep 17 00:00:00 2001 From: Oliver Shaw Date: Thu, 18 Oct 2018 09:37:59 +0100 Subject: [PATCH 001/290] Formatting for thing 78 There's a formatting error. This change corrects the markdown --- en/thing_78/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/en/thing_78/README.md b/en/thing_78/README.md index 976687ce..735b373b 100644 --- a/en/thing_78/README.md +++ b/en/thing_78/README.md @@ -14,7 +14,7 @@ Sure, test automation is great, but why stop there? Repetitive tasks abound in a Did you ever have a "But it (checks out|builds|passes tests) on my machine?" argument with your teammates? Modern IDEs have thousands of potential settings, and it is essentially impossible to ensure that all team members have identical configurations. Build automation systems such as Ant or Autotools give you control and repeatability. -##Common misconception #3: I need to learn exotic tools in order to automate. +## Common misconception #3: I need to learn exotic tools in order to automate. You can go a long way with a decent shell language (such as bash or PowerShell) and a build automation system. If you need to interact with web sites, use a tool such as iMacros or Selenium. @@ -26,4 +26,4 @@ If a part of your process requires Word documents, spreadsheets, or images, it m You don't have to learn all of bash or Ant to get started. Learn as you go. When you have a task that you think can and should be automated, learn just enough about your tools to do it. And do it early in a project when time is usually easier to find. Once you have been successful, you (and your boss) will see that it makes sense to invest in automation. -By [Cay Horstmann](http://programmer.97things.oreilly.com/wiki/index.php/Cay_Horstmann) \ No newline at end of file +By [Cay Horstmann](http://programmer.97things.oreilly.com/wiki/index.php/Cay_Horstmann) From 13476937f97e026f53dff5667d9657c4a23ba70e Mon Sep 17 00:00:00 2001 From: Fureigh Date: Fri, 7 Jun 2019 09:21:56 -0700 Subject: [PATCH 002/290] Update README.md * Change the rendering of the CC license to match [the original source](https://creativecommons.org/licenses/by-nc-sa/3.0/) * Add words missing from the final sentence --- en/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/en/README.md b/en/README.md index 710c35c4..03035464 100644 --- a/en/README.md +++ b/en/README.md @@ -6,6 +6,6 @@ This is a [GitBook](https://www.gitbook.io) version of the ['97 Things Every Programmer Should Know' project](http://programmer.97things.oreilly.com/wiki/index.php/97_Things_Every_Programmer_Should_Know). -All content is licensed under the [Creative Commons Attribution Non Commercial Share Alike 3.0 license](http://creativecommons.org/licenses/by-nc-sa/3.0/). Print versions of the book are available on [Amazon.com](http://www.amazon.com/Things-Every-Programmer-Should-Know/dp/0596809484). +All content is licensed under the [Creative Commons Attribution-NonCommercial-ShareAlike 3.0 license](http://creativecommons.org/licenses/by-nc-sa/3.0/). Print versions of the book are available on [Amazon.com](http://www.amazon.com/Things-Every-Programmer-Should-Know/dp/0596809484). -If you find any mistakes or have any suggestions, you can [create issue](https://github.com/97-things/97-things-every-programmer-should-know/issues) or [pull request](https://github.com/97-things/97-things-every-programmer-should-know/pulls) to [repository](https://github.com/97-things/97-things-every-programmer-should-know). +If you find any mistakes or have any suggestions, you can [create an issue](https://github.com/97-things/97-things-every-programmer-should-know/issues) or [file a pull request](https://github.com/97-things/97-things-every-programmer-should-know/pulls) to the [repository](https://github.com/97-things/97-things-every-programmer-should-know). From 1502f2ddd32934e97ba3eb61e7dd715373983247 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Fabian=20Meyert=C3=B6ns?= <26410884+fmeyertoens@users.noreply.github.com> Date: Thu, 26 Sep 2019 13:40:43 +0200 Subject: [PATCH 003/290] use an ordered list instead of an unordered list --- en/SUMMARY.md | 194 +++++++++++++++++++++++++------------------------- 1 file changed, 97 insertions(+), 97 deletions(-) diff --git a/en/SUMMARY.md b/en/SUMMARY.md index 7d286eeb..782cb57d 100644 --- a/en/SUMMARY.md +++ b/en/SUMMARY.md @@ -1,100 +1,100 @@ # Summary * [Introduction](README.md) -* [Act with Prudence](thing_01/README.md) -* [Apply Functional Programming Principles](thing_02/README.md) -* [Ask "What Would the User Do?" (You Are not the User)](thing_03/README.md) -* [Automate Your Coding Standard](thing_04/README.md) -* [Beauty Is in Simplicity](thing_05/README.md) -* [Before You Refactor](thing_06/README.md) -* [Beware the Share](thing_07/README.md) -* [The Boy Scout Rule](thing_08/README.md) -* [Check Your Code First before Looking to Blame Others](thing_09/README.md) -* [Choose Your Tools with Care](thing_10/README.md) -* [Code in the Language of the Domain](thing_11/README.md) -* [Code Is Design](thing_12/README.md) -* [Code Layout Matters](thing_13/README.md) -* [Code Reviews](thing_14/README.md) -* [Coding with Reason](thing_15/README.md) -* [A Comment on Comments](thing_16/README.md) -* [Comment Only What the Code Cannot Say](thing_17/README.md) -* [Continuous Learning](thing_18/README.md) -* [Convenience Is not an -ility](thing_19/README.md) -* [Deploy Early and Often](thing_20/README.md) -* [Distinguish Business Exceptions from Technical](thing_21/README.md) -* [Do Lots of Deliberate Practice](thing_22/README.md) -* [Domain-Specific Languages](thing_23/README.md) -* [Don't Be Afraid to Break Things](thing_24/README.md) -* [Don't Be Cute with Your Test Data](thing_25/README.md) -* [Don't Ignore that Error!](thing_26/README.md) -* [Don't Just Learn the Language, Understand its Culture](thing_27/README.md) -* [Don't Nail Your Program into the Upright Position](thing_28/README.md) -* [Don't Rely on "Magic Happens Here"](thing_29/README.md) -* [Don't Repeat Yourself](thing_30/README.md) -* [Don't Touch that Code!](thing_31/README.md) -* [Encapsulate Behavior, not Just State](thing_32/README.md) -* [Floating-point Numbers Aren't Real](thing_33/README.md) -* [Fulfill Your Ambitions with Open Source](thing_34/README.md) -* [The Golden Rule of API Design](thing_35/README.md) -* [The Guru Myth](thing_36/README.md) -* [Hard Work Does not Pay Off](thing_37/README.md) -* [How to Use a Bug Tracker](thing_38/README.md) -* [Improve Code by Removing It](thing_39/README.md) -* [Install Me](thing_40/README.md) -* [Inter-Process Communication Affects Application Response Time](thing_41/README.md) -* [Keep the Build Clean](thing_42/README.md) -* [Know How to Use Command-line Tools](thing_43/README.md) -* [Know Well More than Two Programming Languages](thing_44/README.md) -* [Know Your IDE](thing_45/README.md) -* [Know Your Limits](thing_46/README.md) -* [Know Your Next Commit](thing_47/README.md) -* [Large Interconnected Data Belongs to a Database](thing_48/README.md) -* [Learn Foreign Languages](thing_49/README.md) -* [Learn to Estimate](thing_50/README.md) -* [Learn to Say "Hello, World"](thing_51/README.md) -* [Let Your Project Speak for Itself](thing_52/README.md) -* [The Linker Is not a Magical Program](thing_53/README.md) -* [The Longevity of Interim Solutions](thing_54/README.md) -* [Make Interfaces Easy to Use Correctly and Hard to Use Incorrectly](thing_55/README.md) -* [Make the Invisible More Visible](thing_56/README.md) -* [Message Passing Leads to Better Scalability in Parallel Systems](thing_57/README.md) -* [A Message to the Future](thing_58/README.md) -* [Missing Opportunities for Polymorphism](thing_59/README.md) -* [News of the Weird: Testers Are Your Friends](thing_60/README.md) -* [One Binary](thing_61/README.md) -* [Only the Code Tells the Truth](thing_62/README.md) -* [Own (and Refactor) the Build](thing_63/README.md) -* [Pair Program and Feel the Flow](thing_64/README.md) -* [Prefer Domain-Specific Types to Primitive Types](thing_65/README.md) -* [Prevent Errors](thing_66/README.md) -* [The Professional Programmer](thing_67/README.md) -* [Put Everything Under Version Control](thing_68/README.md) -* [Put the Mouse Down and Step Away from the Keyboard](thing_69/README.md) -* [Read Code](thing_70/README.md) -* [Read the Humanities](thing_71/README.md) -* [Reinvent the Wheel Often](thing_72/README.md) -* [Resist the Temptation of the Singleton Pattern](thing_73/README.md) -* [The Road to Performance Is Littered with Dirty Code Bombs](thing_74/README.md) -* [Simplicity Comes from Reduction](thing_75/README.md) -* [The Single Responsibility Principle](thing_76/README.md) -* [Start from Yes](thing_77/README.md) -* [Step Back and Automate, Automate, Automate](thing_78/README.md) -* [Take Advantage of Code Analysis Tools](thing_79/README.md) -* [Test for Required Behavior, not Incidental Behavior](thing_80/README.md) -* [Test Precisely and Concretely](thing_81/README.md) -* [Test While You Sleep (and over Weekends)](thing_82/README.md) -* [Testing Is the Engineering Rigor of Software Development](thing_83/README.md) -* [Thinking in States](thing_84/README.md) -* [Two Heads Are Often Better than One](thing_85/README.md) -* [Two Wrongs Can Make a Right (and Are Difficult to Fix)](thing_86/README.md) -* [Ubuntu Coding for Your Friends](thing_87/README.md) -* [The Unix Tools Are Your Friends](thing_88/README.md) -* [Use the Right Algorithm and Data Structure](thing_89/README.md) -* [Verbose Logging Will Disturb Your Sleep](thing_90/README.md) -* [WET Dilutes Performance Bottlenecks](thing_91/README.md) -* [When Programmers and Testers Collaborate](thing_92/README.md) -* [Write Code as If You Had to Support It for the Rest of Your Life](thing_93/README.md) -* [Write Small Functions Using Examples](thing_94/README.md) -* [Write Tests for People](thing_95/README.md) -* [You Gotta Care about the Code](thing_96/README.md) -* [Your Customers Do not Mean What They Say](thing_97/README.md) +1. [Act with Prudence](thing_01/README.md) +1. [Apply Functional Programming Principles](thing_02/README.md) +1. [Ask "What Would the User Do?" (You Are not the User)](thing_03/README.md) +1. [Automate Your Coding Standard](thing_04/README.md) +1. [Beauty Is in Simplicity](thing_05/README.md) +1. [Before You Refactor](thing_06/README.md) +1. [Beware the Share](thing_07/README.md) +1. [The Boy Scout Rule](thing_08/README.md) +1. [Check Your Code First before Looking to Blame Others](thing_09/README.md) +1. [Choose Your Tools with Care](thing_10/README.md) +1. [Code in the Language of the Domain](thing_11/README.md) +1. [Code Is Design](thing_12/README.md) +1. [Code Layout Matters](thing_13/README.md) +1. [Code Reviews](thing_14/README.md) +1. [Coding with Reason](thing_15/README.md) +1. [A Comment on Comments](thing_16/README.md) +1. [Comment Only What the Code Cannot Say](thing_17/README.md) +1. [Continuous Learning](thing_18/README.md) +1. [Convenience Is not an -ility](thing_19/README.md) +1. [Deploy Early and Often](thing_20/README.md) +1. [Distinguish Business Exceptions from Technical](thing_21/README.md) +1. [Do Lots of Deliberate Practice](thing_22/README.md) +1. [Domain-Specific Languages](thing_23/README.md) +1. [Don't Be Afraid to Break Things](thing_24/README.md) +1. [Don't Be Cute with Your Test Data](thing_25/README.md) +1. [Don't Ignore that Error!](thing_26/README.md) +1. [Don't Just Learn the Language, Understand its Culture](thing_27/README.md) +1. [Don't Nail Your Program into the Upright Position](thing_28/README.md) +1. [Don't Rely on "Magic Happens Here"](thing_29/README.md) +1. [Don't Repeat Yourself](thing_30/README.md) +1. [Don't Touch that Code!](thing_31/README.md) +1. [Encapsulate Behavior, not Just State](thing_32/README.md) +1. [Floating-point Numbers Aren't Real](thing_33/README.md) +1. [Fulfill Your Ambitions with Open Source](thing_34/README.md) +1. [The Golden Rule of API Design](thing_35/README.md) +1. [The Guru Myth](thing_36/README.md) +1. [Hard Work Does not Pay Off](thing_37/README.md) +1. [How to Use a Bug Tracker](thing_38/README.md) +1. [Improve Code by Removing It](thing_39/README.md) +1. [Install Me](thing_40/README.md) +1. [Inter-Process Communication Affects Application Response Time](thing_41/README.md) +1. [Keep the Build Clean](thing_42/README.md) +1. [Know How to Use Command-line Tools](thing_43/README.md) +1. [Know Well More than Two Programming Languages](thing_44/README.md) +1. [Know Your IDE](thing_45/README.md) +1. [Know Your Limits](thing_46/README.md) +1. [Know Your Next Commit](thing_47/README.md) +1. [Large Interconnected Data Belongs to a Database](thing_48/README.md) +1. [Learn Foreign Languages](thing_49/README.md) +1. [Learn to Estimate](thing_50/README.md) +1. [Learn to Say "Hello, World"](thing_51/README.md) +1. [Let Your Project Speak for Itself](thing_52/README.md) +1. [The Linker Is not a Magical Program](thing_53/README.md) +1. [The Longevity of Interim Solutions](thing_54/README.md) +1. [Make Interfaces Easy to Use Correctly and Hard to Use Incorrectly](thing_55/README.md) +1. [Make the Invisible More Visible](thing_56/README.md) +1. [Message Passing Leads to Better Scalability in Parallel Systems](thing_57/README.md) +1. [A Message to the Future](thing_58/README.md) +1. [Missing Opportunities for Polymorphism](thing_59/README.md) +1. [News of the Weird: Testers Are Your Friends](thing_60/README.md) +1. [One Binary](thing_61/README.md) +1. [Only the Code Tells the Truth](thing_62/README.md) +1. [Own (and Refactor) the Build](thing_63/README.md) +1. [Pair Program and Feel the Flow](thing_64/README.md) +1. [Prefer Domain-Specific Types to Primitive Types](thing_65/README.md) +1. [Prevent Errors](thing_66/README.md) +1. [The Professional Programmer](thing_67/README.md) +1. [Put Everything Under Version Control](thing_68/README.md) +1. [Put the Mouse Down and Step Away from the Keyboard](thing_69/README.md) +1. [Read Code](thing_70/README.md) +1. [Read the Humanities](thing_71/README.md) +1. [Reinvent the Wheel Often](thing_72/README.md) +1. [Resist the Temptation of the Singleton Pattern](thing_73/README.md) +1. [The Road to Performance Is Littered with Dirty Code Bombs](thing_74/README.md) +1. [Simplicity Comes from Reduction](thing_75/README.md) +1. [The Single Responsibility Principle](thing_76/README.md) +1. [Start from Yes](thing_77/README.md) +1. [Step Back and Automate, Automate, Automate](thing_78/README.md) +1. [Take Advantage of Code Analysis Tools](thing_79/README.md) +1. [Test for Required Behavior, not Incidental Behavior](thing_80/README.md) +1. [Test Precisely and Concretely](thing_81/README.md) +1. [Test While You Sleep (and over Weekends)](thing_82/README.md) +1. [Testing Is the Engineering Rigor of Software Development](thing_83/README.md) +1. [Thinking in States](thing_84/README.md) +1. [Two Heads Are Often Better than One](thing_85/README.md) +1. [Two Wrongs Can Make a Right (and Are Difficult to Fix)](thing_86/README.md) +1. [Ubuntu Coding for Your Friends](thing_87/README.md) +1. [The Unix Tools Are Your Friends](thing_88/README.md) +1. [Use the Right Algorithm and Data Structure](thing_89/README.md) +1. [Verbose Logging Will Disturb Your Sleep](thing_90/README.md) +1. [WET Dilutes Performance Bottlenecks](thing_91/README.md) +1. [When Programmers and Testers Collaborate](thing_92/README.md) +1. [Write Code as If You Had to Support It for the Rest of Your Life](thing_93/README.md) +1. [Write Small Functions Using Examples](thing_94/README.md) +1. [Write Tests for People](thing_95/README.md) +1. [You Gotta Care about the Code](thing_96/README.md) +1. [Your Customers Do not Mean What They Say](thing_97/README.md) From 228f400f68221c029ae3cc14acf814e461a802b1 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Micha=C3=ABl=20Defferrard?= Date: Wed, 15 Jul 2020 22:15:09 +0200 Subject: [PATCH 004/290] typo --- en/thing_13/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/en/thing_13/README.md b/en/thing_13/README.md index 6c3a68f3..7f9d7ca1 100644 --- a/en/thing_13/README.md +++ b/en/thing_13/README.md @@ -2,7 +2,7 @@ An infeasible number of years ago I worked on a Cobol system where staff weren't allowed to change the indentation unless they already had a reason to change the code, because someone once broke something by letting a line slip into one of the special columns at the beginning of a line. This applied even if the layout was misleading, which it sometimes was, so we had to read the code very carefully because we couldn't trust it. The policy must have cost a fortune in programmer drag. -There's research to show the we all spend much more of our programming time navigating and reading code — finding *where* to make the change — than actually typing, so that's what we want to optimize for. +There's research to show that we all spend much more of our programming time navigating and reading code — finding *where* to make the change — than actually typing, so that's what we want to optimize for. - *Easy to scan.* People are really good at visual pattern matching (a leftover from the time when we had to spot lions on the savannah), so I can help myself by making everything that isn't directly relevant to the domain, all the "accidental complexity" that comes with most commercial languages, fade into the background by standardizing it. If code that behaves the same looks the same, then my perceptual system will help me pick out the differences. That's why I also observe conventions about how to lay out the parts of a class within a compilation unit: constants, fields, public methods, private methods. @@ -12,4 +12,4 @@ There's research to show the we all spend much more of our programming time navi A non-programmer friend once remarked that code looks like poetry. I get that feeling from really good code, that everything in the text has a purpose and that it's there to help me understand the idea. Unfortunately, writing code doesn't have the same romantic image as writing poetry. -By [Steve Freeman](http://programmer.97things.oreilly.com/wiki/index.php/Steve_Freeman) \ No newline at end of file +By [Steve Freeman](http://programmer.97things.oreilly.com/wiki/index.php/Steve_Freeman) From 22fc343125d8babc5a0f3b50613f451355f4658a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Micha=C3=ABl=20Defferrard?= Date: Wed, 15 Jul 2020 22:22:56 +0200 Subject: [PATCH 005/290] consistent list --- en/thing_15/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/en/thing_15/README.md b/en/thing_15/README.md index 6f4cd3c6..69af4e71 100644 --- a/en/thing_15/README.md +++ b/en/thing_15/README.md @@ -8,7 +8,7 @@ A section should be chosen so that at each endpoint the *state of the program* ( Many of the coding practices that are well known (although perhaps less well followed) and considered 'good' make reasoning easier. Hence, just by intending to reason about your code, you already start thinking toward a better style and structure. Unsurprisingly, most of these practices can be checked by static code analyzers: -1. Avoid using goto statements, as they make remote sections highly interdependent. +- Avoid using goto statements, as they make remote sections highly interdependent. - Avoid using modifiable global variables, as they make all sections that use them dependent. - Each variable should have the smallest possible scope. For example, a local object can be declared right before its first usage. - Make objects *immutable* whenever relevant. @@ -22,4 +22,4 @@ Many of the coding practices that are well known (although perhaps less well fol As well as reasoning about its correctness, arguing about your code gives you understanding of it. Communicate the insights you gain for everyone's benefit. -By [Yechiel Kimchi](http://programmer.97things.oreilly.com/wiki/index.php/Yechiel_Kimchi) \ No newline at end of file +By [Yechiel Kimchi](http://programmer.97things.oreilly.com/wiki/index.php/Yechiel_Kimchi) From 44a36394049beee90f58be2ffa48febf4dce2cbf Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Micha=C3=ABl=20Defferrard?= Date: Thu, 16 Jul 2020 00:27:48 +0200 Subject: [PATCH 006/290] list consistency --- en/thing_53/README.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/en/thing_53/README.md b/en/thing_53/README.md index ee2136a8..af6960a3 100644 --- a/en/thing_53/README.md +++ b/en/thing_53/README.md @@ -3,13 +3,13 @@ Depressingly often (happened to me again just before I wrote this), the view many programmers have of the process of going from source code to a statically linked executable in a compiled language is: 1. Edit source code -- Compile source code into object files -- Something magical happens -- Run executable +2. Compile source code into object files +3. Something magical happens +4. Run executable Step 3 is, of course, the linking step. Why would I say such an outrageous thing? I've been doing tech support for decades, and I get the following questions again and again: -1. The linker says def is defined more than once. +- The linker says def is defined more than once. - The linker says abc is an unresolved symbol. - Why is my executable so large? @@ -49,4 +49,4 @@ To determine why an executable is the size it is, take a look at the map file th Although it is not always immediately obvious why you get a particular linker message, there is nothing magical about linkers. The mechanics are straightforward; it's the details you have to figure out in each case. -By [Walter Bright](http://creativecommons.org/licenses/by/3.0/us/) \ No newline at end of file +By [Walter Bright](http://creativecommons.org/licenses/by/3.0/us/) From 0e834a13ce4d00e7d426c7cd0a19c538b76e28ae Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Micha=C3=ABl=20Defferrard?= Date: Thu, 16 Jul 2020 00:31:23 +0200 Subject: [PATCH 007/290] list consistency --- en/thing_54/README.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/en/thing_54/README.md b/en/thing_54/README.md index dbc66e05..3a117d54 100644 --- a/en/thing_54/README.md +++ b/en/thing_54/README.md @@ -19,15 +19,15 @@ The answer depends on your project, and on your personal stake in the production So what can we do if we see a problem? 1. Avoid creating an interim solution in the first place. -- Change the forces that influence the decision of the project manager. -- Leave it as is. +2. Change the forces that influence the decision of the project manager. +3. Leave it as is. Let's examine these options more closely: 1. Avoidance does not work in most places. There is an actual problem to solve, and the standards have turned out to be too restrictive. You might spend some energy trying to change the standards. An honorable albeit tedious endeavor... and that change will not be effective in time for your problem at hand. -- The forces are rooted in the project culture, which resists volitional change. It could be successful in very small projects — especially if it's just you — and you just happen to clean the mess without asking in advance. It could also be successful if the project is such a mess that it is visibly stalled and some time for cleaning up is commonly accepted. -- The status quo automatically applies if the previous option does not. +2. The forces are rooted in the project culture, which resists volitional change. It could be successful in very small projects — especially if it's just you — and you just happen to clean the mess without asking in advance. It could also be successful if the project is such a mess that it is visibly stalled and some time for cleaning up is commonly accepted. +3. The status quo automatically applies if the previous option does not. You will create many solutions, some of them will be interim, most of them will be useful. The best way to overcome interim solutions is to make them superfluous, to provide a more elegant and useful solution. May you be granted the [serenity](http://en.wikipedia.org/wiki/Serenity_prayer) to accept the things you cannot change, courage to change the things you can, and wisdom to know the difference. -By [Klaus Marquardt](http://programmer.97things.oreilly.com/wiki/index.php/Klaus_Marquardt) \ No newline at end of file +By [Klaus Marquardt](http://programmer.97things.oreilly.com/wiki/index.php/Klaus_Marquardt) From ecf7ca9d9019ceadf673486258bdc2004ab73bf9 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Micha=C3=ABl=20Defferrard?= Date: Thu, 16 Jul 2020 00:47:45 +0200 Subject: [PATCH 008/290] missing parenthesis --- en/thing_59/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/en/thing_59/README.md b/en/thing_59/README.md index 3972ae7b..3ffbc3e4 100644 --- a/en/thing_59/README.md +++ b/en/thing_59/README.md @@ -16,7 +16,7 @@ Let's say our webshop offers items that can be downloaded and items that need to ``` public class Shipping { public boolean ship(Item item, SurfaceAddress address) { ... } - public boolean ship(Item item, EMailAddress address { ... } + public boolean ship(Item item, EMailAddress address) { ... } } ``` @@ -48,4 +48,4 @@ In this example we've delegated the responsibility of working with `Shipping` to While there are cases where it's much more practical to use *if-then-else* instead of polymorphism, it is more often the case that a more polymorphic coding style will yield a smaller, more readable and less fragile code base. The number of missed opportunities is a simple count of the *if-then-else* statements in our code. -By [Kirk Pepperdine](http://programmer.97things.oreilly.com/wiki/index.php/Kirk_Pepperdine) \ No newline at end of file +By [Kirk Pepperdine](http://programmer.97things.oreilly.com/wiki/index.php/Kirk_Pepperdine) From 7ced899d604c88e722dfa9de07d51d25f2b0e3d4 Mon Sep 17 00:00:00 2001 From: Serhii Mormul Date: Sat, 5 Sep 2020 13:49:09 +0300 Subject: [PATCH 009/290] Fixed blockquotes problem. Reading a chapter noticed a problem with markdown. According to this https://guides.github.com/features/mastering-markdown/ , to have a quoted code block each line should be quoted. --- en/thing_89/README.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/en/thing_89/README.md b/en/thing_89/README.md index 6aa66daa..0b79cbba 100644 --- a/en/thing_89/README.md +++ b/en/thing_89/README.md @@ -5,10 +5,10 @@ > The vendor sent a performance analysis and tuning specialist to determine the cause of the delays. He soon found one specific program running on the terminal consuming almost all the CPU capacity. Using a profiling tool, he zoomed in on the program and he could see the function that was the culprit. The source code read: > ``` -for (i=0; i for (i=0; i if (... s[i] ...) ... +> } +> ``` > And string s was, on average, thousands of characters long. The code (written by the bank) was quickly changed, and the bank tellers lived happily ever after.... @@ -34,4 +34,4 @@ A good programmer should also know when to use an abominable algorithm. For exam So, read some good books — and make sure you understand them. And if you really read Donald Knuth's *the Art of Computer Programming* well, you might even be lucky: Find a mistake by the author and earn one of Don Knuth's hexadecimal dollar ($2.56) checks. -By [JC van Winkel](http://programmer.97things.oreilly.com/wiki/index.php/JC_van_Winkel) \ No newline at end of file +By [JC van Winkel](http://programmer.97things.oreilly.com/wiki/index.php/JC_van_Winkel) From 82942c857c21d72066901f9bcfe7a8544952a4de Mon Sep 17 00:00:00 2001 From: reflektoin <66482139+reflektoin@users.noreply.github.com> Date: Sun, 11 Apr 2021 19:33:02 +0300 Subject: [PATCH 010/290] Typo in thing_76? Hi, Thanks for making this book accessible! I think this is a typo "is one *if* the keys to creating designs". It probably should be "is one *of* the keys to creating designs" --- en/thing_76/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/en/thing_76/README.md b/en/thing_76/README.md index a2d41280..6929cc1b 100644 --- a/en/thing_76/README.md +++ b/en/thing_76/README.md @@ -36,6 +36,6 @@ The simple partitioning shown above resolves the issues. Each of these classes c The astute reader will see that there are still dependencies in the above solution. That `Employee` is still depended upon by the other classes. So if `Employee` is modified, the other classes will likely have to be recompiled and redeployed. Thus, `Employee` cannot be modified and then independently deployed. However, the other classes can be modified and independently deployed. No modification of one of them can force any of the others to be recompiled or redeployed. Even `Employee` could be independently deployed through a careful use of the *Dependency Inversion Principle* (DIP), but that's a topic for a [different book](http://www.amazon.com/dp/0135974445/). -Careful application of the SRP, separating things that change for different reasons, is one if the keys to creating designs that have an independently deployable component structure. +Careful application of the SRP, separating things that change for different reasons, is one of the keys to creating designs that have an independently deployable component structure. -by [Uncle Bob](http://programmer.97things.oreilly.com/wiki/index.php/Uncle_Bob) \ No newline at end of file +by [Uncle Bob](http://programmer.97things.oreilly.com/wiki/index.php/Uncle_Bob) From 1cc0283e29beb6e08e7bc9b7f96664e029a91222 Mon Sep 17 00:00:00 2001 From: Pepelev Date: Wed, 21 Apr 2021 19:08:50 +0500 Subject: [PATCH 011/290] fix typo --- ru/thing_30/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ru/thing_30/README.md b/ru/thing_30/README.md index b4fe915b..9c0cfb09 100644 --- a/ru/thing_30/README.md +++ b/ru/thing_30/README.md @@ -23,7 +23,7 @@ } ``` -Я много раз сталкивался как с пропущенными проверками, так и с избыточными. Этот пример крошечный, но если вы добавите отмену и повторную оплату, все станет гораздо сложнее, и необходимость правильной обработки состояний повысится. В данном случае, аказ может быть лишь в трех состояниях: +Я много раз сталкивался как с пропущенными проверками, так и с избыточными. Этот пример крошечный, но если вы добавите отмену и повторную оплату, все станет гораздо сложнее, и необходимость правильной обработки состояний повысится. В данном случае, заказ может быть лишь в трех состояниях: 1. *Формируется:* можно добавлять или удалять покупки, нельзя доставлять; - *Оплачен:* нельзя добавлять или удалять покупки, можно доставлять; From 5ef89975dcda704d2a54d8c4e31828d4bc9f8f6c Mon Sep 17 00:00:00 2001 From: Pepelev Date: Wed, 21 Apr 2021 19:11:02 +0500 Subject: [PATCH 012/290] Makes list marks homogeneous like in the English version --- ru/thing_30/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ru/thing_30/README.md b/ru/thing_30/README.md index 9c0cfb09..3d3f61fe 100644 --- a/ru/thing_30/README.md +++ b/ru/thing_30/README.md @@ -25,7 +25,7 @@ Я много раз сталкивался как с пропущенными проверками, так и с избыточными. Этот пример крошечный, но если вы добавите отмену и повторную оплату, все станет гораздо сложнее, и необходимость правильной обработки состояний повысится. В данном случае, заказ может быть лишь в трех состояниях: -1. *Формируется:* можно добавлять или удалять покупки, нельзя доставлять; +- *Формируется:* можно добавлять или удалять покупки, нельзя доставлять; - *Оплачен:* нельзя добавлять или удалять покупки, можно доставлять; - *Доставлено:* заключительное состояние, никаких изменений. From 2c1da025d18501a330beeaf573014f1b5669195b Mon Sep 17 00:00:00 2001 From: Pepelev Date: Wed, 28 Apr 2021 00:22:06 +0500 Subject: [PATCH 013/290] typo --- ru/thing_89/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ru/thing_89/README.md b/ru/thing_89/README.md index 0772328b..ea211c29 100644 --- a/ru/thing_89/README.md +++ b/ru/thing_89/README.md @@ -19,7 +19,7 @@ Упс, а что, у вас нет tutorial-a? На том языке, который я понимаю? -И если в toturial-e будут упомянуты мои проблемы, я сдамся. Я начну читать о том, что я могу сделать при помощи вашей программы, и делать это с удовольствием. Я наконец-то выдохну, откинусь на спинку стула и сделаю глоток чая (я ведь сказал, что я из Великобритании?), а потом поиграю с вашими примерами, чтобы понять, как работать с вашим приложением. И если я решу свои проблемы с его помощью, я пошлю вам благодарственный е-мейл. Я отправлю отчет об ошибке, если таковая случится, а также напишу о желаемых дополнениях. И я расскажу всем своим друзьям о том, что ваше ПО лушчее, хотя я даже не попробовал аналогичное ПО ваших конкурентов. И все это лишь потому, что вы потрудились облегчить мои первые шаги. +И если в toturial-e будут упомянуты мои проблемы, я сдамся. Я начну читать о том, что я могу сделать при помощи вашей программы, и делать это с удовольствием. Я наконец-то выдохну, откинусь на спинку стула и сделаю глоток чая (я ведь сказал, что я из Великобритании?), а потом поиграю с вашими примерами, чтобы понять, как работать с вашим приложением. И если я решу свои проблемы с его помощью, я пошлю вам благодарственный е-мейл. Я отправлю отчет об ошибке, если таковая случится, а также напишу о желаемых дополнениях. И я расскажу всем своим друзьям о том, что ваше ПО лучшее, хотя я даже не попробовал аналогичное ПО ваших конкурентов. И все это лишь потому, что вы потрудились облегчить мои первые шаги. Я все еще вас не убедил? From a853d6d63f81f17d22f13b39cf4c5db40f95af04 Mon Sep 17 00:00:00 2001 From: rico-chet Date: Fri, 28 May 2021 14:57:42 +0200 Subject: [PATCH 014/290] en/thing_95: Fix enumeration Change the mixed enumeration to a numbered one. --- en/thing_95/README.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/en/thing_95/README.md b/en/thing_95/README.md index 1a95f56c..7ba49719 100644 --- a/en/thing_95/README.md +++ b/en/thing_95/README.md @@ -5,11 +5,11 @@ You are writing automated tests for some or all of your production code. Congrat Good tests act as documentation for the code they are testing. They describe how the code works. For each usage scenario the test(s): 1. Describe the context, starting point, or preconditions that must be satisfied -- Illustrate how the software is invoked -- Describe the expected results or postconditions to be verified +2. Illustrate how the software is invoked +3. Describe the expected results or postconditions to be verified Different usage scenarios will have slightly different versions of each of these. The person trying to understand your code should be able to look at a few tests and by comparing these three parts of the tests in question, be able to see what causes the software to behave differently. Each test should clearly illustrate the cause and effect relationship between these three parts. This implies that what isn't visible in the test is just as important as what is visible. Too much code in the test distracts the reader with unimportant trivia. Whenever possible hide such trivia behind meaningful method calls — the Extract Method refactoring is your best friend. And make sure you give each test a meaningful name that describes the particular usage scenario so the test reader doesn't have to reverse engineer each test to understand what the various scenarios are. Between them, the names of the test class and class method should include at least the starting point and how the software is being invoked. This allows the test coverage to be verified via a quick scan of the method names. It can also be useful to include the expected results in the test method names as long as this doesn't cause the names to be too long to see or read. It is also a good idea to test your tests. You can verify they detect the errors you think they detect by inserting those errors into the production code (your own private copy that you'll throw away, of course). Make sure they report errors in a helpful and meaningful way. You should also verify that your tests speak clearly to a person trying to understand your code. The only way to do this is to have someone who isn't familiar with your code read your tests and tell you what they learned. Listen carefully to what they say. If they didn't understand something clearly it probably isn't because they aren't very bright. It is more likely that you weren't very clear. (Go ahead and reverse the roles by reading their tests!) -by [Gerard Meszaros](http://programmer.97things.oreilly.com/wiki/index.php/Gerard_Meszaros) \ No newline at end of file +by [Gerard Meszaros](http://programmer.97things.oreilly.com/wiki/index.php/Gerard_Meszaros) From dd0212a3f8c35f0f9f3a66f56185229b23c90f4d Mon Sep 17 00:00:00 2001 From: Dmitri Date: Fri, 3 Sep 2021 16:03:51 +0300 Subject: [PATCH 015/290] =?UTF-8?q?=D0=98=D1=81=D0=BF=D1=80=D0=B0=D0=B2?= =?UTF-8?q?=D0=BB=D0=B5=D0=BD=D0=B0=20=D0=BD=D1=83=D0=BC=D0=B5=D1=80=D0=B0?= =?UTF-8?q?=D1=86=D0=B8=D1=8F=20=D1=81=D0=BF=D0=B8=D1=81=D0=BA=D0=BE=D0=B2?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ru/thing_03/README.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/ru/thing_03/README.md b/ru/thing_03/README.md index 233b597b..197766b9 100644 --- a/ru/thing_03/README.md +++ b/ru/thing_03/README.md @@ -4,13 +4,13 @@ Удручающе часто (в последний раз – буквально перед написанием этой статьи) программисты представляют процесс преобразования исходного кода в исполняемый файл как-то вот так: 1. Написать (или исправить) исходный код -- Скомпилировать исходный код в объектные файлы -- Происходит какое-то чудо -- Появляется исполняемый файл +2. Скомпилировать исходный код в объектные файлы +3. Происходит какое-то чудо +4. Появляется исполняемый файл На шаге 3, конечно же, происходит линковка. Что же меня в этом так раздражает? Я работал в техподдержке десятилетиями, и постоянно получаю вопросы вроде: -1. Линкер сообщает что переменная определена более одного раза +- Линкер сообщает что переменная определена более одного раза - Линкер сообщает что переменная является неразрешимым символом - Почему исполняемый файл такой большой. From 9d7ca9a96fc61747bb940b99e5aa5da9bc911972 Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Tue, 7 Dec 2021 14:13:58 +0300 Subject: [PATCH 016/290] created tr folder for turkish version --- LANGS.md | 1 + 1 file changed, 1 insertion(+) diff --git a/LANGS.md b/LANGS.md index 78db73c4..39848c4c 100644 --- a/LANGS.md +++ b/LANGS.md @@ -1,2 +1,3 @@ * [English](en) * [русский язык](ru) +* [Türkçe](tr) \ No newline at end of file From c4d335fa09599e24cf9697f494acd7d39e328ef8 Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Wed, 8 Dec 2021 09:04:25 +0300 Subject: [PATCH 017/290] added thing_01 --- tr/thing_01/README.md | 15 +++++++++++++++ 1 file changed, 15 insertions(+) create mode 100644 tr/thing_01/README.md diff --git a/tr/thing_01/README.md b/tr/thing_01/README.md new file mode 100644 index 00000000..265120f8 --- /dev/null +++ b/tr/thing_01/README.md @@ -0,0 +1,15 @@ +# Sağduyulu hareket edin + +> *"Ne yaparsan yap, sağduyulu davran ve sonuçlarını düşün" Anonim* + +Bir yinelemenin başlangıcında bir program ne kadar rahat görünürse görünsün, bazen baskı altında olmaktan kaçınamazsınız. Kendinizi "doğru yapmak" ile "hızlı yapmak" arasında seçim yapmak zorunda bulursanız, daha sonra geri dönüp düzelteceğinizi düşünerek "hızlı yapmak" genellikle çekici gelir. Kendinize, ekibinize ve müşterinize bu sözü verdiğinizde, bunu kastediyorsunuz demektir. Ancak çoğu zaman bir sonraki yineleme yeni sorunlar getirir ve siz onlara odaklanırsınız. Bu tür ertelenmiş işler teknik borç olarak bilinir ve sizin arkadaşınız değildir. Martin Fowler, özellikle [teknik borç taksonomisi](http://martinfowler.com/bliki/TechnicalDebtQuadrant.html) bu kasıtlı teknik borcu, yanlışlıkla teknik borçla karıştırılmaması gerektiğini söylüyor. + +Teknik borç bir kredi gibidir: Kısa vadede ondan faydalanırsınız, ancak tamamen ödenene kadar faiz ödemeniz gerekir. Koddaki kısayollar, özellik eklemeyi veya kodunuzu yeniden düzenlemeyi zorlaştırır. Kusurlar ve kırılgan test durumları için üreme alanlarıdır. Ne kadar uzun bırakırsan, o kadar kötü olur. Orijinal düzeltmeyi üstlenmeye başladığınızda, orijinal sorunun üzerine yerleştirilmiş, kodu yeniden düzenlemeyi ve düzeltmeyi çok daha zor hale getiren, pek de doğru olmayan tasarım seçenekleri yığını olabilir. Doğrusu, çoğu zaman sadece işler o kadar kötüye gittiğinde onu düzeltmeniz gerekir, aslında onu düzeltmek için geri dönersiniz. Ve o zamana kadar düzeltmek genellikle o kadar zordur ki, gerçekten zaman veya riski göze alamazsınız. + +Son teslim tarihini karşılamak veya bir özelliğin ince bir dilimini uygulamak için teknik borç ödemeniz gereken zamanlar vardır. Bu durumda olmamaya çalışın, ancak durum kesinlikle bunu gerektiriyorsa, devam edin. Ama (ve bu büyük bir AMA) teknik borcu takip etmeli ve hızlı bir şekilde geri ödemelisin yoksa işler hızla yokuş aşağı gider. Uzlaşmaya karar verir vermez, unutulmaması için bir görev kartı yazın veya sorun takip sisteminize kaydedin. + +Bir sonraki yinelemede borcun geri ödemesini planlarsanız, maliyet minimum olacaktır. Borcun ödenmeden bırakılması faiz tahakkuk ettirir ve maliyetin görünür olması için bu faizin takip edilmesi gerekir. Bu, projenin teknik borcunun işletme değeri üzerindeki etkisini vurgulayacak ve geri ödemenin uygun şekilde önceliklendirilmesini sağlayacaktır. İlginin nasıl hesaplanacağı ve izleneceğine ilişkin seçim, belirli projeye bağlı olacaktır, ancak onu izlemelisiniz. + +Teknik borcu mümkün olan en kısa sürede ödeyin. Aksini yapmak tedbirsizlik olur. + +By [Seb Rose](http://programmer.97things.oreilly.com/wiki/index.php/Seb_Rose) \ No newline at end of file From 08033436bb81a871807356a1c5b3e4e0523bbd20 Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Thu, 9 Dec 2021 09:00:31 +0300 Subject: [PATCH 018/290] added thing_02 --- tr/thing_01/README.md | 2 +- tr/thing_02/README.md | 19 +++++++++++++++++++ 2 files changed, 20 insertions(+), 1 deletion(-) create mode 100644 tr/thing_02/README.md diff --git a/tr/thing_01/README.md b/tr/thing_01/README.md index 265120f8..cfd646aa 100644 --- a/tr/thing_01/README.md +++ b/tr/thing_01/README.md @@ -12,4 +12,4 @@ Bir sonraki yinelemede borcun geri ödemesini planlarsanız, maliyet minimum ola Teknik borcu mümkün olan en kısa sürede ödeyin. Aksini yapmak tedbirsizlik olur. -By [Seb Rose](http://programmer.97things.oreilly.com/wiki/index.php/Seb_Rose) \ No newline at end of file +[Seb Rose](http://programmer.97things.oreilly.com/wiki/index.php/Seb_Rose) Tarafından \ No newline at end of file diff --git a/tr/thing_02/README.md b/tr/thing_02/README.md new file mode 100644 index 00000000..fd8e892f --- /dev/null +++ b/tr/thing_02/README.md @@ -0,0 +1,19 @@ +# Fonksiyonel Programlama İlkelerini Uygulayın + +Fonksiyonel programlama, son zamanlarda ana akım programlama topluluğunun yeniden ilgisini çekti. Bunun bir nedeni, fonksiyonel paradigmanın *ortaya çıkan özelliklerinin*, sektörümüzün çoklu çekirdeğe geçişinin getirdiği zorlukların üstesinden gelmek için iyi bir konumda olmasıdır. Ancak, bu kesinlikle önemli bir uygulama olsa da, bu parçanın size *fonksiyonel programlamanızı bilmenizi* tavsiye etmesinin nedeni bu değildir. + +Fonksiyonel programlama paradigmasına hakim olmak, diğer bağlamlarda yazdığınız kodun kalitesini büyük ölçüde artırabilir. Fonksiyonel paradigmayı derinlemesine anlar ve uygularsanız, tasarımlarınız çok daha yüksek derecede *referans şeffaflığı* sergileyecektir. + +Referans şeffaflığı çok istenen bir özelliktir: Fonksiyonların, nerede ve ne zaman çağrıldıklarına bakılmaksızın, aynı girdi verildiğinde tutarlı bir şekilde aynı sonuçları verdiğini ifade eder. Yani, fonksiyon değerlendirmesi değişken durumun yan etkilerine daha az bağlıdır - ideal olarak, hiç değil. + +Zorunlu koddaki hataların önde gelen bir nedeni de değiştirilebilir değişkenlere bağlanabilir. Bunu okuyan herkes, belirli bir durumda bazı değerlerin neden beklendiği gibi olmadığını araştırmış olacaktır. Görünürlük semantiği, bu sinsi kusurları hafifletmeye veya en azından konumlarını büyük ölçüde daraltmaya yardımcı olabilir, ancak bunların asıl suçlusu aslında aşırı değişkenlik kullanan tasarımların tutumu olabilir. + +Ve bu konuda kesinlikle sektörden pek bir yardım alamıyoruz. Nesne yönelimine girişler, bu tür tasarımı kısmen destekler, çünkü genellikle, birbirleri üzerinde mutlu bir şekilde mutatör yöntemlerini çağıran ve tehlikeli olabilen, nispeten uzun ömürlü nesnelerin grafiklerinden oluşan örnekler gösterirler. Ancak, zekice teste dayalı tasarımla, özellikle de ["Mock Roles, not Objects"](http://www.jmock.org/oopsla2004.pdf) yapıldığından emin olunduğunda, gereksiz değişkenlik ortadan kaldırılabilir. + +Net sonuç, değiştirilebilir üye değişkenlere başvurmak bulunmak yerine, kendilerine iletilen argümanlar üzerinde hareket eden daha çok sayıda, daha küçük işlevlerle tipik olarak daha iyi sorumluluk dağılımına sahip bir tasarımdır. Daha az kusur olacak ve ayrıca hata ayıklamak genellikle daha kolay olacak, çünkü bu tasarımlarda sahte bir değerin nerede ortaya çıktığını bulmak, aksi takdirde hatalı bir atamayla sonuçlanan belirli bağlamı çıkarmaktan daha kolaydır. Bu, çok daha yüksek derecede bir referans şeffaflığı ekler ve pozitif olarak hiçbir şey bu fikirleri, bu hesaplama modelinin norm olduğu fonksiyonel bir programlama dili öğrenmek kadar derine inemez. + +Tabii ki, bu yaklaşım her durumda optimal değildir. Örneğin, nesne yönelimli sistemlerde bu tarz, genellikle etki alanı modeli geliştirmede (yani işbirliklerinin iş kurallarının karmaşıklığını yıkmaya hizmet ettiği yerlerde) kullanıcı arayüzü geliştirmeye göre daha iyi sonuçlar verir. + +Öğrenilen dersleri diğer alanlara mantıklı bir şekilde uygulayabilmek için fonksiyonel programlama paradigmasında ustalaşın. Nesne sistemleriniz (biri için) referans şeffaflığı iyiliği ile yankılanacak ve işlevsel benzerlerine pek çok kişinin inandığından çok daha yakın olacaktır. Hatta bazıları, fonksiyonel programlama ve nesne yöneliminin zirvesinin *yalnızca birbirinin bir yansıması*, bir hesaplamalı yin ve yang biçimi olduğunu bile iddia edebilir. + +[Edward Garson](http://programmer.97things.oreilly.com/wiki/index.php/Edward_Garson) Tarafından \ No newline at end of file From bda5aabe02231951a7c24a070df63c4134c5c3db Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Fri, 10 Dec 2021 09:05:51 +0300 Subject: [PATCH 019/290] added thing_03 --- tr/thing_03/README.md | 15 +++++++++++++++ 1 file changed, 15 insertions(+) create mode 100644 tr/thing_03/README.md diff --git a/tr/thing_03/README.md b/tr/thing_03/README.md new file mode 100644 index 00000000..624f1f78 --- /dev/null +++ b/tr/thing_03/README.md @@ -0,0 +1,15 @@ +# "Kullanıcı Ne Yapar?" (Kullanıcı Siz değilsiniz) + +Hepimiz başkalarının bizim gibi düşündüğünü varsayma eğilimindeyiz ama yapmazlar. Psikologlar buna yanlış fikir birliği yanlılığı diyor. İnsanlar bizden farklı düşündüklerinde veya davrandıklarında, onları (bilinçaltında) bir şekilde kusurlu olarak etiketlememiz oldukça olasıdır. + +Bu önyargı, yazılımcıların kendilerini kullanıcıların yerine koymakta neden bu kadar zorlandıklarını açıklıyor. Kullanıcılar yazılımcılar gibi düşünmezler. Başlangıç olarak, bilgisayarları kullanarak çok daha az zaman harcarlar. Bir bilgisayarın nasıl çalıştığını ne bilirler ne de umursarlar. Bu, yazılımcıların çok aşina olduğu problem çözme tekniklerinden hiçbirinden yararlanamayacakları anlamına gelir. Yazılımcıların bir arayüzle, arayüz üzerinden ve çevresinde çalışmak için kullandıkları kalıpları ve ipuçlarını tanımıyorlar. + +Kullanıcıların nasıl düşündüklerini öğrenmenin en iyi yolu bir tanesini izlemektir. Bir kullanıcıdan, geliştirmekte olduğunuz şeye benzer bir yazılım parçası kullanarak bir görevi tamamlamasını isteyin. Görevin gerçek olduğundan emin olun: "Bir sayı sütunu ekleyin" tamam; "Geçen ay için harcamalarınızı hesaplayın" daha iyidir. "Bu elektronik tablo hücrelerini seçip aşağıya bir *SUM* formülü girebilir misiniz?" gibi çok özel görevlerden kaçının. — bu soruda büyük bir ipucu var. Kullanıcının ilerlemesini konuşmasını sağlayın. Kesmeyin. Yardım etmeye çalışmayın. Kendine "Neden bunu yapıyor?" ve "Neden bunu yapmıyor?" diye sormaya devam et. + +Fark edeceğiniz ilk şey, kullanıcıların temel şeyleri benzer şekilde yaptıklarıdır. Görevleri aynı sırayla tamamlamaya çalışırlar ve aynı yerlerde aynı hataları yaparlar. Bu temel davranış etrafında tasarlamanız gerekir. Bu, insanların "Ya kullanıcı isterse...?" dedikleri için dinlenmeye meyilli olduğu tasarım toplantılarından farklıdır. Bu, ayrıntılı özelliklere ve kullanıcıların ne istediği konusunda kafa karışıklığına yol açar. Kullanıcıları izlemek bu karışıklığı ortadan kaldırır. + +Kullanıcıların takıldığını göreceksiniz. Sıkışınca etrafına bakarsın. Kullanıcılar sıkışıp kaldıklarında odaklarını daraltırlar. Ekranın başka yerlerinde çözümleri görmeleri onlar için zorlaşıyor. Yardım metninin zayıf kullanıcı arayüzü tasarımına zayıf bir çözüm olmasının bir nedeni budur. Talimatlarınız veya yardım metniniz olması gerekiyorsa, onu sorunlu alanlarınızın hemen yanına yerleştirdiğinizden emin olun. Araç ipuçlarının yardım menülerinden daha yararlı olmasının nedeni, kullanıcının dar ilgi odağıdır. + +Kullanıcılar kafa karıştırmaya eğilimlidir. İşe yarayan bir yol bulacaklar ve ne kadar karmaşık olursa olsun ona sadık kalacaklar. İki veya üç kısayoldan ziyade, işleri yapmanın gerçekten bariz bir yolunu sağlamak daha iyidir. Ayrıca, kullanıcıların istediklerini söyledikleri ile gerçekte yaptıkları arasında bir boşluk olduğunu da göreceksiniz. Kullanıcı gereksinimlerini toplamanın normal yolu onlara sormak olduğundan bu endişe verici. Bu nedenle gereksinimleri yakalamanın en iyi yolu kullanıcıları izlemektir. Kullanıcıları izleyerek bir saat harcamak, bir günü ne istediklerini tahmin ederek geçirmekten daha bilgilendiricidir. + +[Giles Colborne](http://programmer.97things.oreilly.com/wiki/index.php/Giles_Colborne) Tarafından \ No newline at end of file From af6b6d731882c20e462cb9a7ecdfcdc3e8aa30b5 Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Mon, 13 Dec 2021 08:58:45 +0300 Subject: [PATCH 020/290] added thing_04 --- tr/thing_04/README.md | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) create mode 100644 tr/thing_04/README.md diff --git a/tr/thing_04/README.md b/tr/thing_04/README.md new file mode 100644 index 00000000..e1104788 --- /dev/null +++ b/tr/thing_04/README.md @@ -0,0 +1,20 @@ +# Kodlama Standardınızı Otomatikleştirin + +Muhtemelen sen de orada bulunmuşsundur. Bir projenin başlangıcında herkesin birçok iyi niyeti vardır - bunlara "yeni projenin kararları" diyebiliriz. Oldukça sık olarak, bu kararların çoğu belgelere yazılır. Kodla ilgili olanlar projenin kodlama standardında yer alır. Başlangıç toplantısında, baş geliştirici belgeyi gözden geçirir ve en iyi durumda, herkes onları takip etmeye çalışacaklarını kabul eder. Ancak proje başladığında, bu iyi niyetler birer birer terk edilir. Proje sonunda teslim edildiğinde, kod bir karmaşa gibi görünüyor ve kimse bu hale nasıl geldiğini bilmiyor. + +İşler ne zaman ters gitti? Muhtemelen başlangıç toplantısında. Bazı proje üyeleri dikkat etmedi. Diğerleri konuyu anlamadı. Daha da kötüsü, bazıları aynı fikirde değildi ve zaten kodlama standart isyanını planlıyorlardı. Sonunda bazıları konuyu anladı ve kabul etti, ancak projedeki baskı çok arttığında bir şeyleri bırakmak zorunda kaldılar. İyi biçimlendirilmiş kod, daha fazla işlevsellik isteyen bir müşteriyle size puan kazandırmaz. Ayrıca, bir kodlama standardını takip etmek, otomatikleştirilmemişse oldukça sıkıcı bir görev olabilir. Kendiniz bulmak için sadece dağınık bir sınıfı elle girintilemeye çalışın. + +Ama eğer böyle bir problemse, neden ilk etapta bir kodlama standardına sahip olmak istiyoruz? Kodu tek tip bir şekilde biçimlendirmenin bir nedeni, hiç kimsenin bir kod parçasına yalnızca kendi özel yöntemiyle biçim vererek "sahip olmaması"dır. Bazı yaygın hatalardan kaçınmak için geliştiricilerin belirli anti-kalıpları kullanmasını önlemek isteyebiliriz. Toplamda, bir kodlama standardı projede çalışmayı kolaylaştırmalı ve baştan sona geliştirme hızını korumalıdır. Bundan sonra herkesin kodlama standardı üzerinde hemfikir olması gerekir - bir geliştiricinin kodu girintilemek için üç boşluk kullanması ve diğerinin dört boşluk kullanması yardımcı olmaz. + +Kod kalitesi raporları oluşturmak ve kodlama standardını belgelemek ve sürdürmek için kullanılabilecek çok sayıda araç vardır, ancak tüm çözüm bu değildir. Mümkünse otomatikleştirilmeli ve uygulanmalıdır. İşte birkaç örnek: + +- Kod biçimlendirmenin derleme sürecinin bir parçası olduğundan emin olun, böylece herkes kodu her derlediğinde bunu otomatik olarak çalıştırır. +- İstenmeyen anti-kalıplara karşı kodu taramak için statik kod analiz araçlarını kullanın. Herhangi biri bulunursa, yapıyı bozun. +- Kendi, projeye özgü anti-kalıplarınızı tarayabilmeniz için bu araçları yapılandırmayı öğrenin. +- Yalnızca test kapsamını ölçmekle kalmayın, sonuçları da otomatik olarak kontrol edin. Yine, test kapsamı çok düşükse yapıyı bozun. + +Bunu önemli olduğunu düşündüğünüz her şey için yapmaya çalışın. Gerçekten önemsediğiniz her şeyi otomatikleştiremezsiniz. Otomatik olarak işaretleyemeyeceğiniz veya düzeltemeyeceğiniz şeylere gelince, bunları otomatikleştirilmiş kodlama standardına tamamlayıcı bir dizi yönerge olarak düşünün, ancak sizin ve iş arkadaşlarınızın bunları özenle takip edemeyeceğinizi kabul edin. + +Son olarak, kodlama standardı statik değil dinamik olmalıdır. Proje geliştikçe, projenin ihtiyaçları değişir ve başlangıçta akıllıca görünen şey, birkaç ay sonra mutlaka akıllı olmak zorunda değildir. + +[Filip van Laenen](http://programmer.97things.oreilly.com/wiki/index.php/Filip_van_Laenen) Tarafından \ No newline at end of file From 584d16503426dfd51971b9f7840f4128b423e3cd Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Tue, 14 Dec 2021 08:46:27 +0300 Subject: [PATCH 021/290] added thing_05 --- tr/thing_05/README.md | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) create mode 100644 tr/thing_05/README.md diff --git a/tr/thing_05/README.md b/tr/thing_05/README.md new file mode 100644 index 00000000..75cf95d2 --- /dev/null +++ b/tr/thing_05/README.md @@ -0,0 +1,28 @@ +# Güzellik Sadelikte + +Tüm yazılım geliştiricilerin bilmesi ve kalplerine yakın tutması için özellikle iyi olduğunu düşündüğüm bir alıntı var: + +> *Tarzın, uyumun, zarafetin ve iyi ritmin güzelliği sadeliğe bağlıdır.* - Platon + +Bence bu, yazılım geliştiriciler olarak bizim talip olmamız gereken değerleri bir cümleyle özetliyor. + +Kodumuzda ulaşmaya çalıştığımız birkaç şey var: + +- Okunabilirlik +- Bakım kolaylığı +- Geliştirme hızı +- Güzelliğin anlaşılması zor kalitesi + +Platon bize, tüm bu nitelikleri sağlayan etkenin basitlik olduğunu söylüyor. + +Güzel kod nedir? Bu potansiyel olarak çok öznel bir sorudur. Güzellik algısı büyük ölçüde bireysel geçmişe bağlıdır, tıpkı herhangi bir şey hakkındaki algımızın çoğunun geçmişimize bağlı olması gibi. Sanatta eğitim almış insanlar, bilimlerde eğitim görmüş insanlardan farklı bir güzellik algısına (veya en azından yaklaşımlarına) sahiptir. Sanat dalları, yazılımı sanat eserleriyle karşılaştırarak yazılımdaki güzelliğe yaklaşma eğilimindeyken, bilim dalları simetri ve altın oran hakkında konuşma ve her şeyi formüle indirmeye çalışma eğilimindedir. Tecrübelerime göre, her iki taraftaki argümanların çoğunun temeli basitliktir. + +Çalıştığınız kaynak kodu düşünün. Başkalarının kodlarını incelemek için zaman harcamadıysanız, şu anda bunu okumayı bırakın ve çalışmak için açık kaynak kodu bulun. Ciddi anlamda! İçtenlikle söyledim! Web'de, tanınmış, tanınmış bir uzman tarafından yazılmış, seçtiğiniz dilde bazı kodlar arayın. + +Geri döndün mü? İyi. Neredeydik? Ah evet... Bana hitap eden ve güzel olduğunu düşündüğüm kodun birçok ortak özelliği olduğunu buldum. Bunların başında sadelik gelir. Toplam uygulama veya sistem ne kadar karmaşık olursa olsun, tek tek parçaların basit tutulması gerektiğini düşünüyorum. Açıklayıcı adlara sahip benzer şekilde basit, odaklanmış yöntemler içeren tek bir sorumluluğa sahip basit nesneler. Bazı insanlar, beş ila on satırlık kısa kod yöntemlerine sahip olma fikrinin aşırı olduğunu düşünüyor ve bazı diller bunu yapmayı çok zorlaştırıyor, ancak böyle bir kısalığın yine de arzu edilen bir hedef olduğunu düşünüyorum. + +Sonuç olarak, güzel kod basit koddur. Her bir parça, basit sorumluluklarla ve sistemin diğer parçalarıyla basit ilişkilerle basit tutulur. Bu şekilde, sistem ömrü boyunca geliştirme hızını yüksek tutarak, temiz, basit, test edilebilir kodla sistemlerimizi zaman içinde bakımlı tutabiliriz. + +Güzellik basitlikten doğar ve sadelikte bulunur. + +Jørn Ølmheim Tarafından \ No newline at end of file From 6e79fd7495c1dff03b37d97df2f938c82370d9b2 Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Tue, 14 Dec 2021 18:56:59 +0300 Subject: [PATCH 022/290] added thing_06 --- tr/thing_06/README.md | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) create mode 100644 tr/thing_06/README.md diff --git a/tr/thing_06/README.md b/tr/thing_06/README.md new file mode 100644 index 00000000..c9ec8755 --- /dev/null +++ b/tr/thing_06/README.md @@ -0,0 +1,19 @@ +# Yeniden Düzenlemeden Önce + +Bir noktada her yazılımcının mevcut kodu yeniden düzenlemesi gerekecek. Ancak bunu yapmadan önce lütfen aşağıdakileri düşünün, çünkü bu sizi ve diğerlerini büyük ölçüde zamandan (ve acıdan) kurtarabilir: + +- *Yeniden yapılandırma için en iyi yaklaşım, mevcut kod tabanını ve bu koda karşı yazılan testleri değerlendirmekle başlar.* Bu, kodun mevcut haliyle güçlü ve zayıf yönlerini anlamanıza yardımcı olacaktır, böylece hatalardan kaçınırken güçlü noktaları korumanızı sağlayabilirsiniz. Hepimiz mevcut sistemden daha iyisini yapabileceğimizi düşünüyoruz... ta ki mevcut sistem hatalarından ders çıkaramadığımız için önceki üründen daha iyi olmayan - hatta daha kötü olmayan - bir şeyle sonuçlanıncaya kadar. + +- *Her şeyi yeniden yazmanın cazibesinden kaçının.* Mümkün olduğu kadar çok kodu yeniden kullanmak en iyisidir. Kod ne kadar çirkin olursa olsun, zaten test edilmiş, gözden geçirilmiş vb. Eski kodu - özellikle de üretimdeyse - atmak, farkında olmadığınız belirli geçici çözümlere ve hata düzeltmelerine sahip olabilecek, aylarca (veya yıllarca) test edilmiş, savaşta sertleştirilmiş kodu attığınız anlamına gelir. Bunu hesaba katmazsanız, yazdığınız yeni kod, eski kodda düzeltilen aynı gizemli hataları gösterebilir. Bu, yıllar içinde kazanılan çok fazla zaman, çaba ve bilgi israfına neden olacaktır. + +- *Birçok artımlı değişiklik, tek bir büyük değişiklikten daha iyidir.* Artımlı değişiklikler, geri bildirim yoluyla sistem üzerindeki etkiyi daha kolay ölçmenizi sağlar, örneğin testlerden. Bir değişiklik yaptıktan sonra yüzlerce test hatası görmek eğlenceli değil. Bu, kötü kararlarla sonuçlanabilecek hayal kırıklığına ve baskıya yol açabilir. Birkaç test hatasının üstesinden gelmek kolaydır ve daha yönetilebilir bir yaklaşım sağlar. + +- *Her yinelemeden sonra mevcut testlerin geçmesini sağlamak önemlidir.* Mevcut testler yaptığınız değişiklikleri karşılamaya yetmiyorsa yeni testler ekleyin. Eski koddaki testleri, gerekli özeni göstermeden atmayın. İlk bakışta, bu testlerden bazıları yeni tasarımınıza uygulanabilir görünmeyebilir, ancak bu özel testin neden eklendiğini derinlemesine araştırmak çabaya değer. + +- *Kişisel tercihler ve ego araya girmemeli.* Bir şey bozuk değilse, neden düzeltelim? Kodun stilinin veya yapısının kişisel tercihinizi karşılamaması, yeniden yapılandırma için geçerli bir neden değildir. Önceki yazılımcıdan daha iyi bir iş yapabileceğinizi düşünmek de geçerli bir sebep değil. + +- *Yeni teknoloji, yeniden düzenleme yapmak için yetersiz bir nedendir.* Yeniden düzenleme yapmanın en kötü nedenlerinden biri, mevcut kodun bugün sahip olduğumuz tüm harika teknolojinin çok gerisinde olması ve yeni bir dil veya çerçevenin işleri çok daha zarif bir şekilde yapabileceğine inanıyoruz. Maliyet-fayda analizi, yeni bir dilin veya çerçevenin işlevsellik, sürdürülebilirlik veya üretkenlikte önemli gelişmelerle sonuçlanacağını göstermediği sürece, onu olduğu gibi bırakmak en iyisidir. + +- *İnsanların hata yaptığını unutmayın.* Yeniden yapılandırma, her zaman yeni kodun daha iyi - hatta önceki deneme kadar iyi - olacağını garanti etmez. Birkaç başarısız yeniden yapılandırma girişimi gördüm ve bir parçası oldum. Güzel değildi ama insandı. + +[Rajith Attapattu](http://programmer.97things.oreilly.com/wiki/index.php/Rajith_Attapattu) Tarafından \ No newline at end of file From 58aa81abd11f32bc87700560b03151bd09b81bc3 Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Wed, 15 Dec 2021 08:51:19 +0300 Subject: [PATCH 023/290] added thing_07 --- tr/thing_07/README.md | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) create mode 100644 tr/thing_07/README.md diff --git a/tr/thing_07/README.md b/tr/thing_07/README.md new file mode 100644 index 00000000..4aacd268 --- /dev/null +++ b/tr/thing_07/README.md @@ -0,0 +1,21 @@ +# Paylaşıma Dikkat Edin + +Şirketteki ilk projemdi. Derecemi yeni bitirmiştim ve her gün geç saatlere kadar mevcut kodu inceleyerek kendimi kanıtlamak için can atıyordum. İlk değişiklik üzerinde çalışırken, öğrendiğim her şeyi - yorum yapmak, günlüğe kaydetmek, mümkünse ortak kodu kütüphanelere çekmek işlerini - uygulamaya koymak için ekstra özen gösterdim. Kendimi çok hazır hissettiğim kod incelemesi kaba bir uyanış olarak geldi - yeniden kullanım hoş karşılanmadı! + +Bu nasıl olabilir? Üniversite boyunca yeniden kullanım, kaliteli yazılım mühendisliğinin özü olarak kabul edildi. Okuduğum tüm makaleler, ders kitapları, bana öğreten deneyimli yazılım uzmanları. Hepsi yanlış mıydı? + +Kritik bir şeyi kaçırdığım ortaya çıktı. + +Bağlam. + +Sistemin çılgınca farklı iki parçasının aynı şekilde bazı mantık yürütmeleri, düşündüğümden daha az şey ifade ediyordu. Bu paylaşılan kod kitaplıklarını çıkarana kadar, bu parçalar birbirine bağımlı değildi. Her biri bağımsız olarak gelişebilir. Her biri, sistemin değişen iş ortamının ihtiyaçlarına göre mantığını değiştirebilir. Bu dört satırlık benzer kod tesadüfiydi - zamansal bir anormallik, bir tesadüf. Yani ben gelene kadar. + +Oluşturduğum ortak kod kitaplıkları her ayağın bağcıklarını birbirine bağladı. Bir iş etki alanına göre adımlar, önce diğeriyle senkronize edilmeden yapılamaz. Bu bağımsız işlevlerdeki bakım maliyetleri ihmal edilebilir düzeydeydi, ancak ortak kitaplık, çok daha fazla test gerektiriyordu. + +Sistemdeki mutlak kod satırı sayısını azaltırken, bağımlılık sayısını artırdım. Bu bağımlılıkların bağlamı kritiktir - yerelleştirilmiş olsalardı, haklı olabilirdi ve bazı olumlu değerlere sahip olabilirdi. Bu bağımlılıklar kontrol altında tutulmadığında, kodun kendisi gayet iyi görünse bile, eğilimleri sistemi daha büyük endişelere bulaştırır. + +Bu hatalar sinsidir, özünde iyi bir fikir gibi görünürler. Doğru bağlamda uygulandığında bu teknikler değerlidir. Yanlış bağlamda, değerden çok maliyeti artırırlar. Çeşitli bölümlerin kullanılacağı bağlam hakkında hiçbir bilgim olmadan mevcut bir kod tabanına geldiğimde, bugünlerde nelerin paylaşıldığı konusunda çok daha dikkatli oluyorum. + +Paylaşıma dikkat edin. Bağlamınızı kontrol edin. Ancak o zaman devam edin. + +[Udi Dahan](http://programmer.97things.oreilly.com/wiki/index.php/Udi_Dahan) Tarafından \ No newline at end of file From 5f58200df2eb2e64df646b8b02b9d922abedcffb Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Wed, 15 Dec 2021 09:08:23 +0300 Subject: [PATCH 024/290] updated readme file --- tr/README.md | 10 +++++ tr/SUMMARY.md | 100 ++++++++++++++++++++++++++++++++++++++++++ tr/thing_03/README.md | 2 +- 3 files changed, 111 insertions(+), 1 deletion(-) create mode 100644 tr/README.md create mode 100644 tr/SUMMARY.md diff --git a/tr/README.md b/tr/README.md new file mode 100644 index 00000000..4b61d05b --- /dev/null +++ b/tr/README.md @@ -0,0 +1,10 @@ +Her Yazılımcının Bilmesi Gereken 97 Şey +====== + +*Önde gelen uygulayıcılardan toplanan yazılımcılar için bilgelik incileri.* + +Bu [GitBook](https://www.gitbook.io) ['Her Yazılımcının Bilmesi Gereken 97 Şey' projesinin versiyondur](http://programmer.97things.oreilly.com/wiki/index.php/97_Things_Every_Programmer_Should_Know). + +Tüm içerik [Creative Commons Attribution-NonCommercial-ShareAlike 3.0 lisansı](http://creativecommons.org/licenses/by-nc-sa/3.0/) kapsamında lisanslanmıştır. Kitabın basılı sürümleri [Amazon.com](http://www.amazon.com/Things-Every-Programmer-Should-Know/dp/0596809484) adresinde mevcuttur. + +Herhangi bir hata bulursanız veya herhangi bir öneriniz varsa, bir [konu oluşturabilir](https://github.com/97-things/97-things-every-programmer-should-know/issues) veya [depoya](https://github.com/97-things/97-things-every-programmer-should-know) bir [çekme isteği](https://github.com/97-things/97-things-every-programmer-should-know/pulls) gönderebilirsiniz. \ No newline at end of file diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md new file mode 100644 index 00000000..b84ef662 --- /dev/null +++ b/tr/SUMMARY.md @@ -0,0 +1,100 @@ +# Summary + +* [Tanıtım](README.md) +1. [Sağduyulu hareket edin](thing_01/README.md) +1. [Fonksiyonel Programlama İlkelerini Uygulayın](thing_02/README.md) +1. ["Kullanıcı Ne Yapar?" Diye Sor (Kullanıcı Siz değilsiniz)](thing_03/README.md) +1. [Kodlama Standardınızı Otomatikleştirin](thing_04/README.md) +1. [Güzellik Sadelikte](thing_05/README.md) +1. [Yeniden Düzenlemeden Önce](thing_06/README.md) +1. [Paylaşıma Dikkat Edin](thing_07/README.md) +1. [The Boy Scout Rule](thing_08/README.md) +1. [Check Your Code First before Looking to Blame Others](thing_09/README.md) +1. [Choose Your Tools with Care](thing_10/README.md) +1. [Code in the Language of the Domain](thing_11/README.md) +1. [Code Is Design](thing_12/README.md) +1. [Code Layout Matters](thing_13/README.md) +1. [Code Reviews](thing_14/README.md) +1. [Coding with Reason](thing_15/README.md) +1. [A Comment on Comments](thing_16/README.md) +1. [Comment Only What the Code Cannot Say](thing_17/README.md) +1. [Continuous Learning](thing_18/README.md) +1. [Convenience Is not an -ility](thing_19/README.md) +1. [Deploy Early and Often](thing_20/README.md) +1. [Distinguish Business Exceptions from Technical](thing_21/README.md) +1. [Do Lots of Deliberate Practice](thing_22/README.md) +1. [Domain-Specific Languages](thing_23/README.md) +1. [Don't Be Afraid to Break Things](thing_24/README.md) +1. [Don't Be Cute with Your Test Data](thing_25/README.md) +1. [Don't Ignore that Error!](thing_26/README.md) +1. [Don't Just Learn the Language, Understand its Culture](thing_27/README.md) +1. [Don't Nail Your Program into the Upright Position](thing_28/README.md) +1. [Don't Rely on "Magic Happens Here"](thing_29/README.md) +1. [Don't Repeat Yourself](thing_30/README.md) +1. [Don't Touch that Code!](thing_31/README.md) +1. [Encapsulate Behavior, not Just State](thing_32/README.md) +1. [Floating-point Numbers Aren't Real](thing_33/README.md) +1. [Fulfill Your Ambitions with Open Source](thing_34/README.md) +1. [The Golden Rule of API Design](thing_35/README.md) +1. [The Guru Myth](thing_36/README.md) +1. [Hard Work Does not Pay Off](thing_37/README.md) +1. [How to Use a Bug Tracker](thing_38/README.md) +1. [Improve Code by Removing It](thing_39/README.md) +1. [Install Me](thing_40/README.md) +1. [Inter-Process Communication Affects Application Response Time](thing_41/README.md) +1. [Keep the Build Clean](thing_42/README.md) +1. [Know How to Use Command-line Tools](thing_43/README.md) +1. [Know Well More than Two Programming Languages](thing_44/README.md) +1. [Know Your IDE](thing_45/README.md) +1. [Know Your Limits](thing_46/README.md) +1. [Know Your Next Commit](thing_47/README.md) +1. [Large Interconnected Data Belongs to a Database](thing_48/README.md) +1. [Learn Foreign Languages](thing_49/README.md) +1. [Learn to Estimate](thing_50/README.md) +1. [Learn to Say "Hello, World"](thing_51/README.md) +1. [Let Your Project Speak for Itself](thing_52/README.md) +1. [The Linker Is not a Magical Program](thing_53/README.md) +1. [The Longevity of Interim Solutions](thing_54/README.md) +1. [Make Interfaces Easy to Use Correctly and Hard to Use Incorrectly](thing_55/README.md) +1. [Make the Invisible More Visible](thing_56/README.md) +1. [Message Passing Leads to Better Scalability in Parallel Systems](thing_57/README.md) +1. [A Message to the Future](thing_58/README.md) +1. [Missing Opportunities for Polymorphism](thing_59/README.md) +1. [News of the Weird: Testers Are Your Friends](thing_60/README.md) +1. [One Binary](thing_61/README.md) +1. [Only the Code Tells the Truth](thing_62/README.md) +1. [Own (and Refactor) the Build](thing_63/README.md) +1. [Pair Program and Feel the Flow](thing_64/README.md) +1. [Prefer Domain-Specific Types to Primitive Types](thing_65/README.md) +1. [Prevent Errors](thing_66/README.md) +1. [The Professional Programmer](thing_67/README.md) +1. [Put Everything Under Version Control](thing_68/README.md) +1. [Put the Mouse Down and Step Away from the Keyboard](thing_69/README.md) +1. [Read Code](thing_70/README.md) +1. [Read the Humanities](thing_71/README.md) +1. [Reinvent the Wheel Often](thing_72/README.md) +1. [Resist the Temptation of the Singleton Pattern](thing_73/README.md) +1. [The Road to Performance Is Littered with Dirty Code Bombs](thing_74/README.md) +1. [Simplicity Comes from Reduction](thing_75/README.md) +1. [The Single Responsibility Principle](thing_76/README.md) +1. [Start from Yes](thing_77/README.md) +1. [Step Back and Automate, Automate, Automate](thing_78/README.md) +1. [Take Advantage of Code Analysis Tools](thing_79/README.md) +1. [Test for Required Behavior, not Incidental Behavior](thing_80/README.md) +1. [Test Precisely and Concretely](thing_81/README.md) +1. [Test While You Sleep (and over Weekends)](thing_82/README.md) +1. [Testing Is the Engineering Rigor of Software Development](thing_83/README.md) +1. [Thinking in States](thing_84/README.md) +1. [Two Heads Are Often Better than One](thing_85/README.md) +1. [Two Wrongs Can Make a Right (and Are Difficult to Fix)](thing_86/README.md) +1. [Ubuntu Coding for Your Friends](thing_87/README.md) +1. [The Unix Tools Are Your Friends](thing_88/README.md) +1. [Use the Right Algorithm and Data Structure](thing_89/README.md) +1. [Verbose Logging Will Disturb Your Sleep](thing_90/README.md) +1. [WET Dilutes Performance Bottlenecks](thing_91/README.md) +1. [When Programmers and Testers Collaborate](thing_92/README.md) +1. [Write Code as If You Had to Support It for the Rest of Your Life](thing_93/README.md) +1. [Write Small Functions Using Examples](thing_94/README.md) +1. [Write Tests for People](thing_95/README.md) +1. [You Gotta Care about the Code](thing_96/README.md) +1. [Your Customers Do not Mean What They Say](thing_97/README.md) diff --git a/tr/thing_03/README.md b/tr/thing_03/README.md index 624f1f78..61c6cd15 100644 --- a/tr/thing_03/README.md +++ b/tr/thing_03/README.md @@ -1,4 +1,4 @@ -# "Kullanıcı Ne Yapar?" (Kullanıcı Siz değilsiniz) +# "Kullanıcı Ne Yapar?" Diye Sor (Kullanıcı Siz değilsiniz) Hepimiz başkalarının bizim gibi düşündüğünü varsayma eğilimindeyiz ama yapmazlar. Psikologlar buna yanlış fikir birliği yanlılığı diyor. İnsanlar bizden farklı düşündüklerinde veya davrandıklarında, onları (bilinçaltında) bir şekilde kusurlu olarak etiketlememiz oldukça olasıdır. From 475c3ca183f0d1d820db37fc432a58665b9cfe9d Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Wed, 15 Dec 2021 18:44:00 +0300 Subject: [PATCH 025/290] added thing_08 --- tr/SUMMARY.md | 2 +- tr/thing_08/README.md | 15 +++++++++++++++ 2 files changed, 16 insertions(+), 1 deletion(-) create mode 100644 tr/thing_08/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index b84ef662..6af0197d 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -8,7 +8,7 @@ 1. [Güzellik Sadelikte](thing_05/README.md) 1. [Yeniden Düzenlemeden Önce](thing_06/README.md) 1. [Paylaşıma Dikkat Edin](thing_07/README.md) -1. [The Boy Scout Rule](thing_08/README.md) +1. [İzci Kuralı](thing_08/README.md) 1. [Check Your Code First before Looking to Blame Others](thing_09/README.md) 1. [Choose Your Tools with Care](thing_10/README.md) 1. [Code in the Language of the Domain](thing_11/README.md) diff --git a/tr/thing_08/README.md b/tr/thing_08/README.md new file mode 100644 index 00000000..775f2538 --- /dev/null +++ b/tr/thing_08/README.md @@ -0,0 +1,15 @@ +# İzci Kuralı + +İzcilerin bir kuralı vardır: "Kamp alanını her zaman bulduğunuzdan daha temiz bırakın." Yerde bir pislik bulursanız, pisliği kimin yapmış olabileceğine bakmaksızın onu temizlersiniz. Bir sonraki kampçı grubu için kasıtlı olarak çevreyi iyileştirirsiniz. Aslında bu kuralın orijinal şekli, izciliğin babası Robert Stephenson Smyth Baden-Powell tarafından yazılmış, "Bu dünyayı bulduğunuzdan biraz daha iyi bir şekilde terk etmeye çalışın" idi. + +Kodumuzdaki benzer bir kuralı izlesek ne olur: "Bir modülü her zaman teslim aldığınızdan daha temiz bir şekilde kontrol edin." Orijinal yazarın kim olduğu önemli değil, ya ne kadar küçük olursa olsun, modülü geliştirmek için her zaman biraz çaba gösterseydik. Sonuç ne olurdu? + +Sanırım hepimiz bu basit kuralı izleseydik, yazılım sistemlerimizdeki amansız bozulmanın sonunu görürdük. Bunun yerine, sistemlerimiz geliştikçe yavaş yavaş daha iyi hale gelecekti. Ayrıca, sadece kendi küçük parçalarıyla ilgilenen bireylerden ziyade, sistemi bir bütün olarak önemseyen *ekipler* görürdük. + +Bu kuralın çok fazla sorulacağını sanmıyorum. Kontrol etmeden önce her modülü mükemmel hale getirmek zorunda değilsiniz. Kontrol ettiğiniz zamandan *biraz daha iyi* hale getirmeniz yeterlidir. Elbette bu, bir modüle *eklediğiniz* herhangi bir kodun temiz olması gerektiği anlamına gelir. Ayrıca, modülü tekrar kontrol etmeden önce en az bir şeyi daha temizlediğiniz anlamına gelir. Basitçe bir değişkenin adını iyileştirebilir veya uzun bir işlevi iki küçük işleve bölebilirsiniz. Döngüsel bir bağımlılığı kırabilir veya ilkeyi ayrıntıdan ayırmak için bir arabirim ekleyebilirsiniz. + +Açıkçası, bu bana sıradan bir nezaket gibi geliyor - tuvaleti kullandıktan sonra ellerinizi yıkamak veya çöpü yere atmak yerine çöp kutusuna atmak gibi. Gerçekten de, kodda bir karışıklık bırakma eylemi, *çöp atmak* kadar sosyal olarak kabul edilemez olmalıdır. *Yapılmamış* bir şey olmalı. + +Ama bundan daha fazlası. Kendi kodumuzu önemsemek bir şeydir. Takımın kodunu önemsemek oldukça başka bir şey. Takımlar birbirlerine yardım eder ve birbirlerini temizlerler. İzci kuralına uyuyorlar çünkü bu sadece kendileri için değil herkes için iyi. + +[Uncle Bob](http://programmer.97things.oreilly.com/wiki/index.php/Uncle_Bob) Tarafından \ No newline at end of file From be816d1b0fa0a6b46fd2f5ed3839366c281fe846 Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Thu, 16 Dec 2021 09:07:07 +0300 Subject: [PATCH 026/290] added thing_09 --- tr/SUMMARY.md | 2 +- tr/thing_09/README.md | 21 +++++++++++++++++++++ 2 files changed, 22 insertions(+), 1 deletion(-) create mode 100644 tr/thing_09/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index 6af0197d..26595cfb 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -9,7 +9,7 @@ 1. [Yeniden Düzenlemeden Önce](thing_06/README.md) 1. [Paylaşıma Dikkat Edin](thing_07/README.md) 1. [İzci Kuralı](thing_08/README.md) -1. [Check Your Code First before Looking to Blame Others](thing_09/README.md) +1. [Başkalarını Suçlamadan Önce Kodunuzu Kontrol Edin](thing_09/README.md) 1. [Choose Your Tools with Care](thing_10/README.md) 1. [Code in the Language of the Domain](thing_11/README.md) 1. [Code Is Design](thing_12/README.md) diff --git a/tr/thing_09/README.md b/tr/thing_09/README.md new file mode 100644 index 00000000..c74727db --- /dev/null +++ b/tr/thing_09/README.md @@ -0,0 +1,21 @@ +# Başkalarını Suçlamadan Önce Kodunuzu Kontrol Edin + +Geliştiriciler — hepimiz! — genellikle kendi kodumuzun bozulduğuna inanmakta güçlük çekeriz. O kadar ihtimal dışı ki, bir kez olsun, bozuk olan derleyici olmalı. + +Ancak gerçekte kodun derleyici, yorumlayıcı, işletim sistemi, uygulama sunucusu, veritabanı, bellek yöneticisi veya başka herhangi bir sistem yazılımı parçasındaki bir hata tarafından kırılması çok (çok) olağandışıdır. Evet, bu hatalar var, ancak inanmak isteyebileceğimizden çok daha az yaygınlar. + +Bir zamanlar bir döngü değişkenini optimize eden bir derleyici hatasıyla ilgili gerçek bir sorunum vardı, ancak derleyicimde veya işletim sistemimde birçok kez bir hata olduğunu hayal ettim. Her seferinde benim hatam olduğu ortaya çıktığında kendimi biraz aptal hissetmek için süreçte çok zamanımı, destek zamanımı ve yönetim zamanımı harcadım. + +Araçların yaygın olarak kullanıldığını, olgunlaştığını ve çeşitli teknoloji yığınlarında kullanıldığını varsayarsak, kaliteden şüphe etmek için çok az neden vardır. Tabii ki, araç erken bir sürümse veya dünya çapında yalnızca birkaç kişi tarafından kullanılıyorsa veya nadiren indirilen bir sürüm (0.1), Açık Kaynaklı Yazılım parçasıysa, yazılımdan şüphelenmek için iyi bir neden olabilir. (Aynı şekilde, ticari yazılımın alfa sürümü de şüpheli olabilir.) + +Derleyici hatalarının ne kadar nadir olduğu göz önüne alındığında, derleyicinin yanlış olduğunu kanıtlamaktansa, zamanınızı ve enerjinizi kodunuzdaki hatayı bulmaya harcamanız çok daha iyidir. Tüm olağan hata ayıklama tavsiyeleri geçerlidir, bu nedenle sorunu yalıtın, aramaları devre dışı bırakın, testlerle çevreleyin; arama kurallarını, paylaşılan kitaplıkları ve sürüm numaralarını kontrol edin; başkasına açıkla; yığın bozulmasına ve değişken tür uyumsuzluklarına dikkat edin; kodu farklı makinelerde ve hata ayıklama ve yayınlama gibi farklı yapı yapılandırmalarında deneyin. + +Kendi varsayımlarınızı ve başkalarının varsayımlarını sorgulayın. Farklı satıcılara ait araçlarda farklı varsayımlar yerleşik olabilir - aynı satıcıdan farklı araçlar da olabilir. Başka biri tekrarlayamayacağınız bir sorunu bildirdiğinde, gidin ve ne yaptıklarına bakın. Belki de hiç düşünmediğiniz bir şeyi yapıyorlar ya da farklı bir sırayla bir şeyler yapıyorlar. + +Kişisel bir kural olarak, sabitleyemediğim bir hatam varsa ve bunun derleyici olduğunu düşünmeye başlıyorum, o zaman yığın bozulması aramanın zamanı geldi. Bu, özellikle izleme kodunun eklenmesi sorunu hareket ettiriyorsa geçerlidir. + +Çok iş parçacıklı sorunlar, saçları griye çeviren ve makinede çığlık atmaya neden olan başka bir hata kaynağıdır. Basit kodu destekleyen tüm öneriler, bir sistem çok iş parçacıklı olduğunda çoğalır. Hata ayıklama ve birim testleri, bu tür hataları herhangi bir tutarlılıkla bulmak için güvenilemez, bu nedenle tasarımın basitliği çok önemlidir. + +Derleyiciyi suçlamak için acele etmeden önce, Sherlock Holmes'un tavsiyesini hatırlayın, "Bir kez imkansızı ortadan kaldırdığınızda, geriye kalan ne kadar imkansız olursa olsun, gerçek olmalı" ve bunu Dirk Gently'nin "Olası olmayanı bir kez ortadan kaldırdığınızda, geriye ne kaldıysa, ne kadar imkansız olursa olsun, gerçek olmalı." + +[Allan Kelly](http://programmer.97things.oreilly.com/wiki/index.php/Allan_Kelly) Tarafından \ No newline at end of file From db68c4e11860c3d8105e0ca714bd2506060ec292 Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Mon, 20 Dec 2021 09:04:20 +0300 Subject: [PATCH 027/290] added thing_10 --- tr/SUMMARY.md | 2 +- tr/thing_10/README.md | 29 +++++++++++++++++++++++++++++ 2 files changed, 30 insertions(+), 1 deletion(-) create mode 100644 tr/thing_10/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index 26595cfb..f23a5bcf 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -10,7 +10,7 @@ 1. [Paylaşıma Dikkat Edin](thing_07/README.md) 1. [İzci Kuralı](thing_08/README.md) 1. [Başkalarını Suçlamadan Önce Kodunuzu Kontrol Edin](thing_09/README.md) -1. [Choose Your Tools with Care](thing_10/README.md) +1. [Araçlarınızı Özenle Seçin](thing_10/README.md) 1. [Code in the Language of the Domain](thing_11/README.md) 1. [Code Is Design](thing_12/README.md) 1. [Code Layout Matters](thing_13/README.md) diff --git a/tr/thing_10/README.md b/tr/thing_10/README.md new file mode 100644 index 00000000..6309e322 --- /dev/null +++ b/tr/thing_10/README.md @@ -0,0 +1,29 @@ +# Araçlarınızı Özenle Seçin + +Modern uygulamalar çok nadiren sıfırdan oluşturulur. Birkaç iyi nedenden dolayı mevcut araçlar (bileşenler, kitaplıklar ve çerçeveler) kullanılarak birleştirilirler: + +- Uygulamaların boyutu, karmaşıklığı ve karmaşıklığı artarken bunları geliştirmek için mevcut süre kısalır. Daha fazla iş alanı kodu ve daha az altyapı kodu yazmaya odaklanabilirlerse, geliştiricilerin zamanını ve zekasını daha iyi kullanır. + +- Yaygın olarak kullanılan bileşenler ve çerçevelerin, şirket içinde geliştirilenlerden daha az hata içermesi muhtemeldir. + +- Web'de ücretsiz olarak sunulan çok sayıda yüksek kaliteli yazılım vardır, bu da daha düşük geliştirme maliyetleri ve gerekli ilgi ve uzmanlığa sahip geliştiricileri bulma olasılığının artması anlamına gelir. + +- Yazılım üretimi ve bakımı yoğun bir iştir, bu nedenle satın almak inşa etmekten daha ucuz olabilir. + +Ancak, uygulamanız için doğru araç karışımını seçmek, biraz düşünmeyi gerektiren zor bir iş olabilir. Aslında bir seçim yaparken aklınızda bulundurmanız gereken birkaç şey var: + +- Farklı araçlar, bağlamları hakkında farklı varsayımlara dayanabilir (ör. çevreleyen altyapı, kontrol modeli, veri modeli, iletişim protokolleri vb.), bu da uygulama ile araçlar arasında mimari uyumsuzluğa yol açabilir. Böyle bir uyumsuzluk, kodu gereğinden fazla karmaşık hale getirecek saldırılara ve geçici çözümlere yol açar. + +- Farklı araçların farklı yaşam döngüleri vardır ve yeni işlevler, tasarım değişiklikleri ve hatta hata düzeltmeleri diğer araçlarla uyumsuzluklara neden olabileceğinden, bunlardan birini yükseltmek son derece zor ve zaman alıcı bir görev haline gelebilir. Araç sayısı arttıkça sorun daha da kötüleşebilir. + +- Bazı araçlar, genellikle çok hızlı bir şekilde kontrolden çıkabilen bir veya daha fazla XML dosyası aracılığıyla oldukça fazla yapılandırma gerektirir. Uygulama, tamamı XML'de ve bazı programlama dillerinde birkaç garip kod satırında yazılmış gibi görünebilir. Konfigürasyonel karmaşıklık, uygulamanın bakımını ve genişletilmesini zorlaştıracaktır. + +- Satıcı kilitlenmesi, büyük ölçüde belirli satıcı ürünlerine bağlı olan kodlar, onlar tarafından birkaç açıdan kısıtlandığında ortaya çıkar: sürdürülebilirlik, performans, gelişme yeteneği, fiyat, vb. + +- Özgür yazılım kullanmayı planlıyorsanız, bunun o kadar da özgür olmadığını keşfedebilirsiniz. Mutlaka ucuz olmayacak olan ticari destek satın almanız gerekebilir. + +- Lisans koşulları, özgür yazılım için bile önemlidir. Örneğin, bazı şirketlerde viral doğası nedeniyle GNU lisans koşulları kapsamında lisanslanan yazılımların kullanılması kabul edilemez - yani, onunla geliştirilen yazılım kaynak koduyla birlikte dağıtılmalıdır. + +Bu sorunları azaltmak için kişisel stratejim, yalnızca kesinlikle gerekli araçları kullanarak küçük bir başlangıç yapmaktır. Genellikle ilk odak noktası, örneğin dağıtılmış uygulamalar için hassas soketler kullanmak yerine bazı ara katman yazılımları kullanarak, düşük seviyeli altyapı programlaması (ve sorunları) ile meşgul olma ihtiyacını ortadan kaldırmaktır. Ve sonra gerekirse daha fazlasını ekleyin. Arayüzler ve katmanlama yoluyla harici araçları iş alanı nesnelerimden ayırma eğilimindeyim, böylece aracımı biraz zahmetle değiştirmem gerekirse değiştirebilirim. Bu yaklaşımın olumlu bir yan etkisi, genellikle başlangıçta tahmin edilenden daha az harici araç kullanan daha küçük bir uygulama ile sonuçlanmasıdır. + +[Giovanni Asproni](http://programmer.97things.oreilly.com/wiki/index.php/Giovanni_Asproni) Tarafından \ No newline at end of file From e44d7fdc0e6643ba49cd88505c356872364ad140 Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Tue, 21 Dec 2021 09:04:29 +0300 Subject: [PATCH 028/290] added thing_11 --- tr/SUMMARY.md | 2 +- tr/thing_11/README.md | 40 ++++++++++++++++++++++++++++++++++++++++ 2 files changed, 41 insertions(+), 1 deletion(-) create mode 100644 tr/thing_11/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index f23a5bcf..23974e8e 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -11,7 +11,7 @@ 1. [İzci Kuralı](thing_08/README.md) 1. [Başkalarını Suçlamadan Önce Kodunuzu Kontrol Edin](thing_09/README.md) 1. [Araçlarınızı Özenle Seçin](thing_10/README.md) -1. [Code in the Language of the Domain](thing_11/README.md) +1. [Domain Dilindeki Kod](thing_11/README.md) 1. [Code Is Design](thing_12/README.md) 1. [Code Layout Matters](thing_13/README.md) 1. [Code Reviews](thing_14/README.md) diff --git a/tr/thing_11/README.md b/tr/thing_11/README.md new file mode 100644 index 00000000..7997ac1a --- /dev/null +++ b/tr/thing_11/README.md @@ -0,0 +1,40 @@ +# Domain Dilindeki Kod + +İki kod tabanını hayal edin. Karşılaştığınız birinde: + +``` +if (portfolioIdsByTraderId.get(trader.getId()) + .containsKey(portfolio.getId())) {...} +``` + +Bu kodun ne işe yaradığını merak ederek kafanı kaşıyorsun. Bir tüccar nesnesinden bir kimlik alıyor gibi görünüyor, bunu görünüşte bir haritadan harita çıkarmak için kullanıyor ve ardından iç haritada bir portföy nesnesinden başka bir kimliğin olup olmadığını görüyor. Kafanı biraz daha kaşıyorsun. portfolioIdsByTraderId tanımına baktığınızda şunu keşfedersiniz: + +``` +Map> portfolioIdsByTraderId; +``` + +Yavaş yavaş, bunun bir tüccarın belirli bir portföye erişimi olup olmadığıyla ilgili olabileceğini anlayacaksınız. Ve elbette, bir yatırımcının belirli bir portföye erişimi olup olmadığını umursayan bir şey olduğunda, aynı arama parçasını veya daha büyük olasılıkla benzer ama çok farklı bir kod parçasını bulacaksınız. + +Diğer kod tabanında bununla karşılaşırsınız: + +``` +if (trader.canView(portfolio)) {...} +``` + +Kafa kaşımak yok. Bir tüccarın nasıl bildiğini bilmenize gerek yok. Belki de bu haritalardan biri içeride bir yere gizlenmiştir. Ama bu tüccarın işi, senin değil. + +Şimdi bu kod tabanlarından hangisinde çalışmayı tercih ederdiniz? + +Bir zamanlar sadece çok temel veri yapılarımız vardı: bitler, baytlar ve karakterler (gerçekten sadece baytlar ama biz bunları harfler ve noktalama işaretleriymiş gibi yapardık). Ondalık sayılar biraz zordu çünkü 10 tabanlı sayılarımız ikili sistemde pek iyi çalışmıyor, bu yüzden birkaç boyutta kayan nokta tipimiz vardı. Ardından diziler ve dizeler geldi (gerçekten sadece farklı diziler). Sonra yığınlar, kuyruklar, karmalar ve bağlantılı listeler, atlama listeleri ve *gerçek dünyada olmayan* pek çok başka heyecan verici veri yapısı vardı. "Bilgisayar bilimi", gerçek dünyayı kısıtlayıcı veri yapılarımızla eşleştirmek için çok çaba harcamakla ilgiliydi. Gerçek gurular bunu nasıl yaptıklarını bile hatırlayabiliyorlardı. + +Sonra kullanıcı tanımlı türlerimiz var! Tamam, bu haber değil ama oyunu biraz değiştiriyor. Alan adınız tüccarlar ve portföyler gibi kavramlar içeriyorsa, bunları örneğin Tüccar ve Portföy adı verilen türlerle modelleyebilirsiniz. Ancak bundan daha da önemlisi, etki alanı terimlerini kullanarak *aralarındaki ilişkileri* modelleyebilirsiniz. + +Etki alanı terimlerini kullanarak kodlama yapmazsanız, buradaki *this* int'nin bir yatırımcıyı tanımlamanın yolu anlamına geldiğini, oysa oradaki *that* int'nin bir portföy tanımlamanın yolu anlamına geldiğini anlayan bir gizli okuma oluşturursunuz. (Karıştırmamak en iyisi!) Ve algoritmik bir snippet ile bir iş konseptini ("Bazı yatırımcıların bazı portföyleri görüntülemesine izin verilmez - bu yasa dışıdır") temsil ediyorsanız, diyelim ki bir anahtar haritasında bir varlık ilişkisi var, denetim ve uyumluluk adamlarına herhangi bir iyilik yapmıyorsunuz demektir. . + +Sıradaki yazılımcı sırrın içinde olmayabilir, o halde neden bunu açıklığa kavuşturmuyorsunuz? Bir anahtarın varlık kontrolü yapan başka bir anahtarı aramak için kullanılması çok açık değildir. Çıkar çatışmasını önleyen iş kurallarının burada uygulandığını birisi nasıl sezebilir? + +Etki alanı kavramlarını kodunuzda açık hale getirmek, diğer yazılımcıların, bir etki alanı hakkında anladıklarına bir algoritmayı güçlendirmeye çalışmaktan çok daha kolay bir şekilde kodun *niyetini* elde edebilecekleri anlamına gelir. Bu aynı zamanda, etki alanı modeli geliştiğinde ki bu, etki alanına ilişkin anlayışınız arttıkça artacaktır, kodu geliştirmek için iyi bir konumdasınız demektir. İyi bir kapsülleme ile birleştiğinde, kuralın yalnızca bir yerde var olma ve bağımlı kodlardan herhangi biri daha akıllıca olmadan değiştirebilme şansınız yüksektir. + +Birkaç ay sonra kod üzerinde çalışmak için gelen yazılımcı size teşekkür edecek. Birkaç ay sonra gelen yazılımcı siz olabilirsiniz. + +[Dan North](http://programmer.97things.oreilly.com/wiki/index.php/Dan_North) Tarafından \ No newline at end of file From 1e4eff222abd407b8412768561ca84ecd7633f23 Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Wed, 22 Dec 2021 09:02:28 +0300 Subject: [PATCH 029/290] added thing_12 --- tr/SUMMARY.md | 2 +- tr/thing_12/README.md | 17 +++++++++++++++++ 2 files changed, 18 insertions(+), 1 deletion(-) create mode 100644 tr/thing_12/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index 23974e8e..a64448e7 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -12,7 +12,7 @@ 1. [Başkalarını Suçlamadan Önce Kodunuzu Kontrol Edin](thing_09/README.md) 1. [Araçlarınızı Özenle Seçin](thing_10/README.md) 1. [Domain Dilindeki Kod](thing_11/README.md) -1. [Code Is Design](thing_12/README.md) +1. [Kod Tasarımdır](thing_12/README.md) 1. [Code Layout Matters](thing_13/README.md) 1. [Code Reviews](thing_14/README.md) 1. [Coding with Reason](thing_15/README.md) diff --git a/tr/thing_12/README.md b/tr/thing_12/README.md new file mode 100644 index 00000000..4c668f2d --- /dev/null +++ b/tr/thing_12/README.md @@ -0,0 +1,17 @@ +# Kod Tasarımdır + +Yarın uyandığınızı ve inşaat sektörünün yüzyılın atılımını yaptığını öğrendiğinizi hayal edin. Milyonlarca ucuz, inanılmaz hızlı robot, malzemeleri hiç yoktan üretebilir, sıfıra yakın bir güç maliyetine sahip olabilir ve kendilerini onarabilir. Ve daha da iyi hale geliyor: Bir inşaat projesi için net bir plan verildiğinde, robotlar onu insan müdahalesi olmadan ihmal edilebilir bir maliyetle inşa edebilirler. + +İnşaat sektörü üzerindeki etkisi tahmin edilebilir, ancak yukarı yönde ne olur? İnşaat maliyetleri ihmal edilebilir olsaydı, mimarların ve tasarımcıların davranışları nasıl değişirdi? Günümüzde fiziksel modeller ve bilgisayar modelleri inşa edilmekte ve inşaata yatırım yapmadan önce titizlikle test edilmektedir. İnşaat aslında ücretsiz olsaydı rahatsız olur muyduk? Başka çıkarımlar da var. Modası geçmiş modellerle birlikte, bitmemiş tasarımlar, nihai hedefe bir yaklaşım üzerine tekrar tekrar inşa edilerek ve geliştirilerek gelişir. Sıradan bir gözlemci, bitmemiş bir tasarımı bitmiş bir üründen ayırt etmekte zorlanabilir. + +Zaman çizgilerini tahmin etme yeteneğimiz kaybolacak. İnşaat maliyetleri, tasarım maliyetlerinden daha kolay hesaplanır, bir kiriş kurmanın yaklaşık maliyetini ve kaç tane kirişe ihtiyacımız olduğunu biliyoruz. Öngörülebilir görevler sıfıra doğru küçüldükçe, daha az öngörülebilir tasarım süresi baskın olmaya başlar. Sonuçlar daha hızlı üretilir, ancak güvenilir zaman çizgileri kayıp gider. + +Tabii ki, rekabetçi bir ekonominin baskıları hala geçerli. İnşaat maliyetleri ortadan kaldırıldığında, bir tasarımı hızla tamamlayabilen bir şirket pazarda avantaj elde eder. Tasarımın hızlı yapılması, mühendislik firmalarının temel itici gücü haline gelir. Kaçınılmaz olarak, tasarıma derinden aşina olmayan biri, doğrulanmamış bir sürüm görecek, erken piyasaya sürmenin pazar avantajını görecek ve "Bu yeterince iyi görünüyor" diyecektir. + +Bazı ölüm kalım projeleri daha gayretli olacak, ancak çoğu durumda tüketiciler eksik tasarım yüzünden acı çekmeyi öğreniyor. Şirketler, sattıkları kırık binaları ve araçları 'düzeltmek' için her zaman sihirli robotlarımızı gönderebilirler. Tüm bunlar, şaşırtıcı bir şekilde mantık dışı bir sonuca işaret ediyor: Tek öncülümüz, inşaat maliyetlerinde önemli bir düşüş oldu ve bunun sonucunda *kalite daha da kötüleşti*. + +Yukarıdaki hikayenin yazılımda ortaya çıkması bizi şaşırtmamalı. Kodun tasarım olduğunu kabul edersek mekanik yerine daha çok yaratıcı bir süreç *yazılım krizi* olarak açıklanır. Artık bir *tasarım krizimiz var*: Kaliteli, onaylanmış tasarımlara olan talep, onları yaratma kapasitemizi aşıyor. Eksik tasarımı kullanma baskısı güçlüdür. + +Neyse ki bu model nasıl daha iyi olabileceğimize dair ipuçları da sunuyor. Fiziksel simülasyonlar otomatik teste eşittir; yazılım tasarımı, acımasız bir dizi testle doğrulanana kadar tamamlanmış sayılmaz. Bu tür testleri daha etkili kılmak için, büyük sistemlerin devasa durum uzayını dizginlemenin yollarını buluyoruz. İyileştirilmiş diller ve tasarım uygulamaları bize umut veriyor. Son olarak, kaçınılmaz bir gerçek var: Harika tasarımlar, kendilerini zanaatlarında ustalaşmaya adayan büyük tasarımcılar tarafından üretilir. Kodun da bundan bir farkı yok. + +[Ryan Brush](http://programmer.97things.oreilly.com/wiki/index.php/Ryan_Brush) Tarafından \ No newline at end of file From 1a30148c9116c56cf76e7f4e99720179bb0bce98 Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Thu, 23 Dec 2021 09:08:37 +0300 Subject: [PATCH 030/290] added thing_13 --- tr/SUMMARY.md | 2 +- tr/thing_13/README.md | 15 +++++++++++++++ 2 files changed, 16 insertions(+), 1 deletion(-) create mode 100644 tr/thing_13/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index a64448e7..4cfc7b1a 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -13,7 +13,7 @@ 1. [Araçlarınızı Özenle Seçin](thing_10/README.md) 1. [Domain Dilindeki Kod](thing_11/README.md) 1. [Kod Tasarımdır](thing_12/README.md) -1. [Code Layout Matters](thing_13/README.md) +1. [Kod Düzeni Önemlidir](thing_13/README.md) 1. [Code Reviews](thing_14/README.md) 1. [Coding with Reason](thing_15/README.md) 1. [A Comment on Comments](thing_16/README.md) diff --git a/tr/thing_13/README.md b/tr/thing_13/README.md new file mode 100644 index 00000000..58ca331a --- /dev/null +++ b/tr/thing_13/README.md @@ -0,0 +1,15 @@ +# Kod Düzeni Önemlidir + +Uzun bir süre önce, personelin zaten kodu değiştirmek için bir nedenleri olmadıkça girintiyi değiştirmesine izin verilmeyen bir Cobol sistemi üzerinde çalıştım, çünkü birisi bir satırın başındaki özel sütunlardan birine bir satırın kaymasına izin vererek bir şeyi bozdu. Bu, düzen yanıltıcı olsa bile uygulandı, ki bazen öyleydi, bu yüzden kodu çok dikkatli okumamız gerekiyordu çünkü ona güvenemedik. Politika, programcı sürüklemesinde bir servete mal olmuş olmalı. + +Hepimizin programlama zamanımızın çoğunu kod okumaya ve gezinmeye harcadığımızı gösteren araştırmalar var, değişikliğin *nerede* yapılacağı bulmak, aslında yazmaktan çok optimize etmek istediğimiz şey bu. + +- *Taraması kolay.* İnsanlar görsel desen eşleştirmede gerçekten iyiler (savanada aslanları tespit etmemiz gerektiğinden kalanlar), bu yüzden doğrudan alanla alakalı olmayan her şeyi yaparak kendime yardımcı olabilirim, çoğu ticari dilde gelen tüm "tesadüfi karmaşıklık", standartlaştırarak arka plana kaybolur. Aynı şekilde davranan kod aynı görünüyorsa, algısal sistemim farklılıkları seçmeme yardımcı olacaktır. Bu nedenle, bir sınıfın bölümlerinin bir derleme birimi içinde nasıl düzenleneceğine ilişkin kuralları da gözlemliyorum: sabitler, alanlar, genel yöntemler, özel yöntemler. + +- *Etkileyici düzen.* Kodumuzun yalnızca adımları listelemek yerine ne yaptığını olabildiğince açık bir şekilde ifade etmesi için doğru adları bulmaya zaman ayırmayı öğrendik, değil mi? Kodun düzeni de bu ifadenin bir parçasıdır. İlk adım, ekibin temel bilgiler için otomatik bir biçimlendirici üzerinde anlaşmasını sağlamaktır, ardından kodlama yaparken elle ayarlamalar yapabilirim. Aktif bir anlaşmazlık olmadıkça, bir ekip hızla ortak bir "el yapımı" stil üzerinde birleşecektir. Bir biçimlendirici niyetimi anlayamaz (bilmem gerekir ki, bir zamanlar bir tane yazmıştım) ve satır sonlarının ve gruplamaların sadece dilin sözdizimini değil, kodun amacını yansıtması benim için daha önemli. (Kevin McGuire beni otomatik kod biçimlendiricilere olan esaretimden kurtardı.) + +- *Kompakt format.* Bir ekrana ne kadar çok girebilirsem, dosyaları kaydırarak veya değiştirerek bağlamı bozmadan o kadar çok görebilirim, bu da kafamda daha az durum tutabileceğim anlamına gelir. Uzun prosedür yorumları ve çok sayıda boşluk, 8 karakterli adlar ve satır yazıcıları için anlamlıydı, ancak şimdi sözdizimi renklendirme ve çapraz bağlama yapan bir IDE'de yaşıyorum. Pikseller benim sınırlayıcı faktörümdür, bu yüzden herkesin kodu anlamama katkıda bulunmasını istiyorum. Düzenin kodu anlamama yardımcı olmasını istiyorum, ancak bundan daha fazlasını değil. + +Yazılımcı olmayan bir arkadaş bir keresinde kodun şiir gibi göründüğünü söylemişti. Gerçekten iyi bir koddan, metindeki her şeyin bir amacı olduğu ve fikri anlamama yardımcı olmak için orada olduğu hissini alıyorum. Ne yazık ki, kod yazmak şiir yazmakla aynı romantik imaja sahip değil. + +[Steve Freeman](http://programmer.97things.oreilly.com/wiki/index.php/Steve_Freeman) Tarafından From fa53d8318c200a773537de5b6a51b5f6cc6b5f3a Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Thu, 23 Dec 2021 18:05:39 +0300 Subject: [PATCH 031/290] added thing_14 --- tr/SUMMARY.md | 2 +- tr/thing_14/README.md | 15 +++++++++++++++ 2 files changed, 16 insertions(+), 1 deletion(-) create mode 100644 tr/thing_14/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index 4cfc7b1a..fe193fea 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -14,7 +14,7 @@ 1. [Domain Dilindeki Kod](thing_11/README.md) 1. [Kod Tasarımdır](thing_12/README.md) 1. [Kod Düzeni Önemlidir](thing_13/README.md) -1. [Code Reviews](thing_14/README.md) +1. [Kod İncelemeleri](thing_14/README.md) 1. [Coding with Reason](thing_15/README.md) 1. [A Comment on Comments](thing_16/README.md) 1. [Comment Only What the Code Cannot Say](thing_17/README.md) diff --git a/tr/thing_14/README.md b/tr/thing_14/README.md new file mode 100644 index 00000000..25ecc057 --- /dev/null +++ b/tr/thing_14/README.md @@ -0,0 +1,15 @@ +# Kod İncelemeleri + +Kod incelemeleri yapmalısınız. Niye? Çünkü bunlar *kod kalitesini* artırır ve *hata oranını azaltır*. Ama mutlaka düşündüğünüz nedenlerden dolayı değil. + +Daha önce incelemelerle ilgili bazı kötü deneyimler yaşamış olabileceğinden, birçok yazılımcı kod incelemelerini sevmeme eğilimindedir. Üretime dağıtılmadan önce tüm kodların resmi bir incelemeden geçmesini gerektiren kuruluşlar gördüm. Bu incelemeyi genellikle mimar veya baş geliştirici yapar, *mimar her şeyi gözden geçirir* olarak da tanımlanabilir. Bu, yazılım geliştirme süreci kılavuzlarında belirtilmiştir, bu nedenle yazılımcılar buna uymak zorundadır. Böyle katı ve resmi bir sürece ihtiyaç duyan bazı kuruluşlar olabilir, ancak çoğu böyle değildir. Çoğu organizasyonda böyle bir yaklaşım ters etki yapar. Gözden geçirenler, şartlı tahliye kurulu tarafından yargılandıklarını hissedebilirler. Gözden geçirenlerin hem kodu okumak için zamana hem de sistemin tüm ayrıntılarını güncel tutmak için zamana ihtiyaçları vardır. Gözden geçirenler bu süreçte hızla tıkanabilir ve süreç kısa sürede dejenere olur. + +Koddaki hataları basitçe düzeltmek yerine, kod incelemelerinin amacı *bilgiyi paylaşmak* ve ortak kodlama yönergeleri oluşturmak olmalıdır. Kodunuzu diğer yazılımcılarla paylaşmak, toplu kod sahipliğini sağlar. Rastgele bir ekip üyesinin, ekibin geri kalanıyla birlikte *kodu incelemesine* izin verin. Hata aramak yerine kodu öğrenmeye ve anlamaya çalışarak gözden geçirmelisiniz. + +Kod incelemeleri sırasında nazik olun. Yorumların *yapıcı, yakıcı değil* olduğundan emin olun. Ekip üyeleri arasında kurumsal kıdemin kod incelemesini etkilemesini önlemek için inceleme toplantısı için farklı *inceleme rolleri* tanıtın. Rol örnekleri arasında, bir gözden geçirenin belgelere, diğerinin istisnalara ve üçüncü bir kişinin de işlevselliğe odaklanması sayılabilir. Bu yaklaşım, inceleme yükünü ekip üyeleri arasında dağıtmaya yardımcı olur. + +Her hafta düzenli bir *kod incelemesi* yapın. Bir inceleme toplantısında birkaç saat geçirin. İncelenen kişiyi her toplantıda basit bir tekrarlı deneme düzeninde döndürün. Her gözden geçirme toplantısında ekip üyeleri arasında rolleri değiştirmeyi de unutmayın. *Yeni başlayanları* kod incelemelerine dahil edin. Deneyimsiz olabilirler, ancak taze üniversite bilgileri farklı bir bakış açısı sağlayabilir. Deneyimleri ve bilgileri için *uzmanları dahil edin*. Hataya açık kodu daha hızlı ve daha doğru bir şekilde tanımlayacaklar. Ekip, araçlar tarafından kontrol edilen *kodlama kuralları* varsa, kod incelemeleri daha kolay akacaktır. Bu şekilde, kod inceleme toplantısında kod biçimlendirme asla tartışılmayacaktır. + +*Kod incelemelerini eğlenceli hale getirmek* belki de başarıya en önemli katkıdır. İncelemeler, inceleme yapan kişilerle ilgilidir. Gözden geçirme toplantısı acı verici veya sıkıcıysa, insanları motive etmek zor olacaktır. Bunu, asıl amacı ekip üyeleri arasında bilgi paylaşımı olan *gayri resmi bir kod incelemesi* yapın. Alaycı yorumları dışarıda bırakın ve bunun yerine bir pasta ya da kahverengi çantalı öğle yemeği getirin. + +[Mattias Karlsson](http://programmer.97things.oreilly.com/wiki/index.php/Mattias_Karlsson) Tarafından \ No newline at end of file From 18550e2e2b82fb13930862b6e2a5f70c57a12ea6 Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Fri, 24 Dec 2021 09:31:22 +0300 Subject: [PATCH 032/290] added thing_15 --- tr/SUMMARY.md | 2 +- tr/thing_15/README.md | 25 +++++++++++++++++++++++++ 2 files changed, 26 insertions(+), 1 deletion(-) create mode 100644 tr/thing_15/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index fe193fea..7e21c38e 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -15,7 +15,7 @@ 1. [Kod Tasarımdır](thing_12/README.md) 1. [Kod Düzeni Önemlidir](thing_13/README.md) 1. [Kod İncelemeleri](thing_14/README.md) -1. [Coding with Reason](thing_15/README.md) +1. [Akıllı Kodlama](thing_15/README.md) 1. [A Comment on Comments](thing_16/README.md) 1. [Comment Only What the Code Cannot Say](thing_17/README.md) 1. [Continuous Learning](thing_18/README.md) diff --git a/tr/thing_15/README.md b/tr/thing_15/README.md new file mode 100644 index 00000000..e761cd62 --- /dev/null +++ b/tr/thing_15/README.md @@ -0,0 +1,25 @@ +# Akıllı Kodlama + +Yazılımın doğruluğu hakkında elle akıl yürütmeye çalışmak, koddan daha uzun ve koddan daha fazla hata içerme olasılığı daha yüksek olan resmi bir kanıtla sonuçlanır. Otomatik araçlar tercih edilir, ancak her zaman mümkün değildir. Aşağıdakiler bir orta yolu tanımlar: doğruluk hakkında yarı resmi olarak akıl yürütme. + +Temel yaklaşım, incelenen tüm kodu kısa bölümlere, örneğin bir fonksiyon çağrısı gibi tek bir satırdan on satırdan daha az bloklara bölmek ve bunların doğruluğunu tartışmaktır. Argümanların yalnızca şeytanın avukatlığını yapan içindeki yazılımcıyı ikna edecek kadar güçlü olması gerekir. + +Her uç noktada *programın durumu*(yani, program sayacı ve tüm "canlı" nesnelerin değerleri) kolayca açıklanan bir özelliği karşılayacak ve o bölümün işlevselliğinin (durum dönüşümü) tek bir görev olarak tanımlanması kolay olacak şekilde bir bölüm seçilmelidir, bunlar akıl yürütmeyi kolaylaştırır. Bu tür uç nokta özellikleri, fonksiyonlar için *önkoşul*, *sonkoşul*, döngüler ve sınıflar için (örneklerine göre) *değişmez* gibi kavramları genelleştirir. Bölümlerin mümkün olduğunca birbirinden bağımsız olması için çabalamak, akıl yürütmeyi kolaylaştırır ve bu bölümler değiştirileceği zaman vazgeçilmezdir. + +İyi bilinen (belki de daha az takip edilen) ve 'iyi' kabul edilen kodlama uygulamalarının çoğu, akıl yürütmeyi kolaylaştırır. Bu nedenle, yalnızca kodunuz hakkında akıl yürütme niyetiyle, daha iyi bir stil ve yapı düşünmeye başlarsınız. Şaşırtıcı olmayan bir şekilde, bu uygulamaların çoğu statik kod analizörleri tarafından kontrol edilebilir: + +- Uzak bölümleri son derece birbirine bağımlı hale getirdikleri için goto deyimlerini kullanmaktan kaçının. +- Değiştirilebilir global değişkenleri kullanmaktan kaçının çünkü bunları kullanan tüm bölümleri bağımlı hale getirir. +- Her değişken mümkün olan en küçük kapsama sahip olmalıdır. Örneğin, yerel bir nesne, ilk kullanımından hemen önce bildirilebilir. +- İlgili olduğunda nesneleri *değişmez(immutable)* yapın. +- Hem yatay hem de dikey boşluk kullanarak kodu okunabilir hale getirin. Örneğin, ilgili yapıları hizalamak ve iki bölümü ayırmak için boş bir çizgi kullanmak. +- Nesneler, türler, fonksiyonlar vb. için açıklayıcı (ancak nispeten kısa) adlar seçerek kodu kendi kendine belgeleyin. +- İç içe bir bölüme ihtiyacınız varsa, onu bir fonksiyon yapın. +- Fonksiyonlarınızı kısa tutun ve tek bir göreve odaklanın. Eski *24 satırlık sınır* hâlâ geçerlidir. Ekran boyutu ve çözünürlüğü değişse de, 1960'lardan bu yana insan bilişinde hiçbir şey değişmedi. +- Fonksiyonların birkaç parametresi olmalıdır (dört iyi bir üst sınırdır). Bu, işlevlere iletilen verileri kısıtlamaz: İlgili parametreleri tek bir nesnede gruplamak, *nesne değişmezlerinden* yararlanır ve tutarlılık ve tutarlılık gibi akıl yürütmeden tasarruf sağlar. +- Daha genel olarak, bir bloktan bir kitaplığa kadar her bir kod birimi *dar bir arayüze* sahip olmalıdır. Daha az iletişim, gerekli muhakemeyi azaltır. Bu, dahili durumu döndüren *alıcıların* bir yükümlülük olduğu anlamına gelir, çalışmak için bir nesneden bilgi istemeyin. Bunun yerine, nesneden zaten sahip olduğu bilgilerle işi yapmasını isteyin. Başka bir deyişle, *kapsülleme* tamamen ve yalnızca *dar arayüzler* ile ilgilidir. +- *değişmezler(invariants)* sınıfını korumak için, *ayarlayıcılar(setters)* bir nesnenin durumunu yöneten değişmezlerin kırılmasına izin verme eğiliminde olduğundan, *ayarlayıcıların* kullanılması önerilmez. + +Doğruluğu hakkında akıl yürütmenin yanı sıra, kodunuz hakkında tartışmak size onu anlamanızı sağlar. Kazandığınız bilgileri herkesin yararına iletin. + +[Yechiel Kimchi](http://programmer.97things.oreilly.com/wiki/index.php/Yechiel_Kimchi) Tarafından From 8c1cdc8ab425f268cf3aa442884c96b12f753dd0 Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Mon, 27 Dec 2021 09:10:31 +0300 Subject: [PATCH 033/290] added thing_16 --- tr/SUMMARY.md | 2 +- tr/thing_16/README.md | 15 +++++++++++++++ 2 files changed, 16 insertions(+), 1 deletion(-) create mode 100644 tr/thing_16/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index 7e21c38e..14d5bb30 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -16,7 +16,7 @@ 1. [Kod Düzeni Önemlidir](thing_13/README.md) 1. [Kod İncelemeleri](thing_14/README.md) 1. [Akıllı Kodlama](thing_15/README.md) -1. [A Comment on Comments](thing_16/README.md) +1. [Yorumlar Üzerine Bir Yorum](thing_16/README.md) 1. [Comment Only What the Code Cannot Say](thing_17/README.md) 1. [Continuous Learning](thing_18/README.md) 1. [Convenience Is not an -ility](thing_19/README.md) diff --git a/tr/thing_16/README.md b/tr/thing_16/README.md new file mode 100644 index 00000000..027ad907 --- /dev/null +++ b/tr/thing_16/README.md @@ -0,0 +1,15 @@ +# Yorumlar Üzerine Bir Yorum + +Üniversitedeki ilk programlama dersimde öğretmenim iki BASIC kodlama sayfası dağıttı. Tahtada, ödevde "Bir program yazın ve ortalama 10 bowling skoru yazın" yazıyordu. Sonra öğretmen odadan çıktı. Bu ne kadar zor olabilir? Son çözümümü hatırlamıyorum ama içinde bir 'FOR/NEXT' döngüsü olduğundan ve toplamda 15 satırdan uzun olamayacağından eminim. Kodlama sayfaları, bunu okuyan çocuklar için, evet, aslında bir bilgisayara girmeden önce uzunlamasına kod yazardık, her biri yaklaşık 70 satırlık koda izin verirdi. Öğretmenin bize neden iki sayfa vereceği konusunda kafam çok karıştı. El yazım her zaman acımasız olduğu için, stil için birkaç ekstra puan almayı umarak ikincisini kodumu çok düzgün bir şekilde yeniden kopyalamak için kullandım. + +Şaşırtıcı bir şekilde, bir sonraki dersin başında ödevi geri aldığımda, zar zor geçen bir not aldım. (Üniversitede geçirdiğim zamanın geri kalanında benim için bir kehanet olacaktı.) Özenle kopyalanmış kodumun üst kısmına karalanmış, "Yorum yok mu?" + +Öğretmenin de benim de programın ne yapması gerektiğini bilmemiz yeterli değildi. Görevin amacının bir kısmı, kodumun arkamdan gelen bir sonraki programcıya kendini açıklaması gerektiğini öğretmekti. Bu unutmadığım bir ders. + +Yorumlar kötü değil. Temel dallanma veya döngü yapıları kadar programlama için gereklidirler. Çoğu modern dilde, otomatik olarak bir API belgesi oluşturmak için uygun şekilde biçimlendirilmiş yorumları ayrıştıracak javadoc'a benzer bir araç bulunur. Bu çok iyi bir başlangıç, ancak neredeyse yeterli değil. Kodunuzun içinde, kodun ne yapması gerektiğine dair açıklamalar olmalıdır. Eski atasözüyle kodlama yapmak, "Yazması zorsa, okuması da zor olur", müşterinize, işvereninize, meslektaşlarınıza ve gelecekteki kendinize zarar verir. + +Öte yandan, yorumunuzda çok ileri gidebilirsiniz. Yorumlarınızın kodunuzu netleştirdiğinden emin olun, ancak onu gizlemeyin. Kodun neyi başarması gerektiğini açıklayan ilgili yorumları kodunuza serpiştirin. Başlık yorumlarınız, herhangi bir programcıya kodunuzu okumak zorunda kalmadan kullanmak için yeterli bilgi verirken, satır içi yorumlarınız bir sonraki geliştiriciye onu düzeltmede veya genişletmede yardımcı olmalıdır. + +Bir işte, üstümdekilerin verdiği bir tasarım kararına katılmadım. Genç programcıların sık sık yaptığı gibi, kendimi oldukça tuhaf hissederek, tasarımlarını kullanmamı söyleyen e-posta metnini dosyanın başlık yorum bloğuna yapıştırdım. Bu mağazadaki yöneticilerin, işlendiğinde kodu gerçekten inceledikleri ortaya çıktı. Bu benim *kariyer sınırlayıcı hareket* terimiyle ilk tanışmamdı. + +[Cal Evans](http://programmer.97things.oreilly.com/wiki/index.php/Cal_Evans) Tarafından \ No newline at end of file From 0f312dd7ad9b7fc5f645823cc133e751dac08927 Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Tue, 28 Dec 2021 09:08:55 +0300 Subject: [PATCH 034/290] added thing_17 --- tr/SUMMARY.md | 2 +- tr/thing_17/README.md | 13 +++++++++++++ 2 files changed, 14 insertions(+), 1 deletion(-) create mode 100644 tr/thing_17/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index 14d5bb30..165dcdf3 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -17,7 +17,7 @@ 1. [Kod İncelemeleri](thing_14/README.md) 1. [Akıllı Kodlama](thing_15/README.md) 1. [Yorumlar Üzerine Bir Yorum](thing_16/README.md) -1. [Comment Only What the Code Cannot Say](thing_17/README.md) +1. [Yalnızca Kodun Söyleyemediklerini Yorumlayın](thing_17/README.md) 1. [Continuous Learning](thing_18/README.md) 1. [Convenience Is not an -ility](thing_19/README.md) 1. [Deploy Early and Often](thing_20/README.md) diff --git a/tr/thing_17/README.md b/tr/thing_17/README.md new file mode 100644 index 00000000..b14140c3 --- /dev/null +++ b/tr/thing_17/README.md @@ -0,0 +1,13 @@ +# Yalnızca Kodun Söyleyemediklerini Yorumlayın + +Teori ve pratik arasındaki fark pratikte teoride olduğundan daha fazladır, kesinlikle yorumlar için geçerli olan bir gözlem. Teoride, kodu yorumlamanın genel fikri kulağa değerli bir fikir gibi geliyor: Okuyucuya neler olup bittiğine dair bir ayrıntı, bir açıklama sunun. Yardımcı olmaktan daha yararlı ne olabilir? Bununla birlikte, pratikte, yorumlar genellikle bir felaket haline gelir. Diğer yazı türlerinde olduğu gibi, iyi yorumlar yazma becerisi vardır. Becerinin çoğu, onları ne zaman yazmayacağınızı bilmektir. + +Kod yanlış oluşturulduğunda, derleyiciler, yorumlayıcılar ve diğer araçlar kesinlikle itiraz edeceklerdir. Kod bir şekilde işlevsel olarak yanlışsa, incelemeler, statik analizler, testler ve üretim ortamındaki günlük kullanım çoğu hatayı giderecektir. Ama ya yorumlar? *Elements of Programming Style*'da Kernighan ve Plauger, "bir yorum yanlışsa, sıfır (veya negatif) değerdedir" demişlerdir. Yine de bu tür yorumlar genellikle kodlama hatalarının asla yapamayacağı şekilde bir kod tabanında çöp olur ve hayatta kalır. Sürekli bir dikkat dağınıklığı ve yanlış bilgi kaynağı, bir programcının düşüncesinde ince ama sürekli bir sürükleme sağlarlar. + +Teknik olarak yanlış olmayan, ancak koda değer katmayan yorumlara ne dersiniz? Bu tür yorumlar gürültüdür. Kodu papağan gibi tekrar eden yorumlar okuyucuya ekstra bir şey sunmaz, bir şeyi kodda ve tekrar doğal dilde belirtmek, onu daha doğru veya daha gerçek yapmaz. Yorumlanan kod yürütülebilir kod değildir, bu nedenle okuyucu veya çalışma zamanı için yararlı bir etkisi yoktur. Ayrıca çok çabuk bayatlar. Sürümle ilgili yorumlar ve yorum yapılan kod, sürüm oluşturma ve geçmişle ilgili soruları ele almaya çalışır. Bu sorular, sürüm kontrol araçları tarafından zaten (çok daha etkili bir şekilde) yanıtlanmıştır. + +Bir kod tabanında gürültülü yorumların ve yanlış yorumların yaygınlığı, programcıları tüm yorumları atlayarak veya onları gizlemek için aktif önlemler alarak görmezden gelmeye teşvik eder. Programcılar beceriklidir ve hasar olarak algılanan her şeyin etrafından dolaşırlar: yorumları yukarı katlamak; yorumların ve arka planın aynı renkte olması için renk şemasını değiştirme; yorumları filtrelemek için komut dosyası. Bir kod tabanını programcı yaratıcılığının bu tür yanlış uygulamalarından kurtarmak ve gerçek değeri olan herhangi bir yorumu gözden kaçırma riskini azaltmak için, yorumlara kodmuş gibi davranılmalıdır. Her yorum okuyucu için bir miktar değer katmalıdır, aksi takdirde kaldırılması veya yeniden yazılması israftır. + +O halde değer olarak nitelenen nedir? Yorumlar, kodun söylemediği ve söyleyemeyeceği bir şey söylemelidir. Bir kod parçasının zaten ne söylemesi gerektiğini açıklayan bir yorum, kodun kendisi için konuşması için kod yapısını veya kodlama kurallarını değiştirmeye yönelik bir davettir. Zayıf yöntem veya sınıf adlarını telafi etmek yerine, bunları yeniden adlandırın. Uzun işlevlerdeki bölümleri yorumlamak yerine, adları önceki bölümlerin amacını yakalayan daha küçük işlevleri çıkarın. Kod aracılığıyla mümkün olduğunca çok ifade etmeye çalışın. Kodda ifade edebileceğiniz ile toplamda ifade etmek istediğiniz şey arasındaki herhangi bir eksiklik, faydalı bir yorum için mantıklı bir aday haline gelir. Kodun söylemediklerini değil, söyleyemediklerini yorumlayın. + +[Kevlin Henney](http://programmer.97things.oreilly.com/wiki/index.php/Kevlin_Henney) Tarafından \ No newline at end of file From 002d3ecea37967c8385ed3ace18c094be275cfae Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Wed, 29 Dec 2021 09:01:54 +0300 Subject: [PATCH 035/290] added thing_18 --- tr/thing_18/README.md | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) create mode 100644 tr/thing_18/README.md diff --git a/tr/thing_18/README.md b/tr/thing_18/README.md new file mode 100644 index 00000000..9c3a57dc --- /dev/null +++ b/tr/thing_18/README.md @@ -0,0 +1,28 @@ +# Devamlı öğrenme + +İlginç zamanlarda yaşıyoruz. Geliştirme dünya geneline yayıldıkça, işinizi yapabilecek birçok insan olduğunu öğrenirsiniz. Pazarlanabilir olmayı öğrenmeye devam etmelisiniz. Aksi takdirde, bir gün size artık ihtiyaç duyulmayıncaya veya işiniz daha ucuz bir kaynağa devredilene kadar aynı işte sıkışıp kalan bir dinozor olursunuz. + +Peki bu konuda ne yaparsın? Bazı işverenler, beceri setinizi genişletmek için eğitim sağlayacak kadar cömerttir. Diğerleri herhangi bir eğitim için zaman veya para ayıramayabilir. Güvenli oynamak için kendi eğitiminizin sorumluluğunu almanız gerekir. + +İşte size öğrenmeye devam etmenin yollarının bir listesi. Bunların çoğu internette ücretsiz olarak bulunabilir: + +- Kitapları, dergileri, blogları, twitter feeds ve web sitelerini okuyun. Bir konuda daha derine inmek istiyorsanız, bir posta listesine veya haber grubuna katılmayı düşünün. +- Bir teknolojiye gerçekten dalmak istiyorsanız, biraz kod yazın. +- Her zaman bir akıl hocası ile çalışmayı deneyin, çünkü en iyi adam olmak eğitiminizi engelleyebilir. Herhangi birinden bir şeyler öğrenebilseniz de, sizden daha akıllı veya daha deneyimli birinden çok daha fazlasını öğrenebilirsiniz. Bir akıl hocası bulamıyorsanız, devam etmeyi düşünün. +- Sanal mentorlar kullanın. Web'de gerçekten sevdiğiniz yazarları ve geliştiricileri bulun ve yazdıkları her şeyi okuyun. Bloglarına abone olun. +- Kullandığınız araçları ve kütüphaneleri tanıyın. Bir şeyin nasıl çalıştığını bilmek, onu nasıl daha iyi kullanacağınızı bilmenizi sağlar. Açık kaynak iseler, gerçekten şanslısınız. Kaputun altında neler olduğunu görmek için kodda adım adım ilerlemek için hata ayıklayıcıyı kullanın. Gerçekten bazı akıllı insanlar tarafından yazılan ve gözden geçirilen kodu göreceksiniz. +- Bir hata yaptığınızda, bir hatayı düzelttiğinizde veya bir sorunla karşılaştığınızda, ne olduğunu gerçekten anlamaya çalışın. Muhtemelen başka biri de aynı sorunla karşılaşmış ve bunu web'de bir yere göndermiştir. Google burada gerçekten yararlıdır. +- Bir şeyi öğrenmenin gerçekten iyi bir yolu, onu öğretmek veya onun hakkında konuşmaktır. İnsanlar sizi dinleyecekleri ve size sorular soracakları zaman, öğrenmek için oldukça motive olacaksınız. İş yerinde, bir kullanıcı grubunda veya yerel bir konferansta bir öğle yemeğinde öğrenmeyi deneyin. +- İlgilendiğiniz bir dil, teknoloji veya disiplin için bir çalışma grubuna (desen topluluğu) veya yerel bir kullanıcı grubuna katılın veya başlayın. +- Konferanslara gidin. Ve gidemezseniz, birçok konferans konuşmalarını ücretsiz olarak çevrimiçi hale getirir. +- Uzun yola çıkmak? Podcast'leri dinleyin. +- Hiç kod tabanı üzerinde bir statik analiz aracı çalıştırdınız mı veya IDE'nizdeki uyarılara baktınız mı? Neyi ve nedenini bildirdiklerini anlayın. +- [Pragmatik Programcıların](http://www.pragprog.com/titles/tpp/the-pragmatic-programmer) tavsiyelerine uyun ve her yıl yeni bir dil öğrenin. En azından yeni bir teknoloji veya araç öğrenin. Dallanma, size mevcut teknoloji yığınınızda kullanabileceğiniz yeni fikirler verir. +- Öğrendiğiniz her şey teknoloji ile ilgili olmak zorunda değil. Gereksinimleri daha iyi anlamak ve iş sorununu çözmeye yardımcı olmak için çalıştığınız alanı öğrenin. Nasıl daha üretken olunacağını – nasıl daha iyi çalışılacağını öğrenmek başka bir iyi seçenektir. +- Okula geri dön. + +Neo'nun Matrix'te sahip olduğu yeteneğe sahip olmak ve sadece ihtiyacımız olan bilgiyi beynimize indirmek güzel olurdu. Ama yapmıyoruz, bu yüzden biraz zaman alacak. Uyandığınız her saati öğrenmek için harcamak zorunda değilsiniz. Her hafta biraz zaman, hiç yoktan iyidir. İş dışında bir hayat var (veya olmalı). + +Teknoloji hızlı değişiyor. Geride kalmayın. + +[Clint Shank](http://programmer.97things.oreilly.com/wiki/index.php/Clint_Shank) Tarafından \ No newline at end of file From e3aaa5d5c7429d788db20804d7c19e5c1c4960fe Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Wed, 29 Dec 2021 18:10:53 +0300 Subject: [PATCH 036/290] added thing_19 --- tr/SUMMARY.md | 4 ++-- tr/thing_19/README.md | 21 +++++++++++++++++++++ 2 files changed, 23 insertions(+), 2 deletions(-) create mode 100644 tr/thing_19/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index 165dcdf3..4a9b28a0 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -18,8 +18,8 @@ 1. [Akıllı Kodlama](thing_15/README.md) 1. [Yorumlar Üzerine Bir Yorum](thing_16/README.md) 1. [Yalnızca Kodun Söyleyemediklerini Yorumlayın](thing_17/README.md) -1. [Continuous Learning](thing_18/README.md) -1. [Convenience Is not an -ility](thing_19/README.md) +1. [Devamlı öğrenme](thing_18/README.md) +1. [Kolaylık bir yetenek değildir](thing_19/README.md) 1. [Deploy Early and Often](thing_20/README.md) 1. [Distinguish Business Exceptions from Technical](thing_21/README.md) 1. [Do Lots of Deliberate Practice](thing_22/README.md) diff --git a/tr/thing_19/README.md b/tr/thing_19/README.md new file mode 100644 index 00000000..f98e5cfc --- /dev/null +++ b/tr/thing_19/README.md @@ -0,0 +1,21 @@ +# Kolaylık bir yetenek değildir + +İyi API'ler tasarlamanın önemi ve zorlukları hakkında çok şey söylendi. İlk seferde doğruyu bulmak zordur ve daha sonra değiştirmek daha da zordur. Çocuk yetiştirmek gibi bir şey. Deneyimli programcıların çoğu, iyi bir API'nin tutarlı bir soyutlama düzeyi izlediğini, tutarlılık ve simetri sergilediğini ve ifade edici bir dil için kelime dağarcığını oluşturduğunu öğrenmiştir. Ne yazık ki, yol gösterici ilkelerin farkında olmak otomatik olarak uygun davranışa dönüşmez. Tatlı yemek zararlıdır. + +Yukarıdan vaaz vermek yerine, defalarca karşılaştığım belirli bir API tasarım 'stratejisini' seçmek istiyorum: uygunluk argümanı. Genellikle aşağıdaki 'anlayışlardan' biriyle başlar: + +- Bu tek şeyi yapmak için diğer sınıfların iki ayrı çağrı yapmasını istemiyorum. +- Bu yöntemle hemen hemen aynıysa neden başka bir yöntem yapayım? Sadece basit bir anahtar ekleyeceğim. +- Bak, çok kolay: İkinci string parametresi ".txt" ile bitiyorsa, metod otomatik olarak ilk parametrenin bir dosya ismi olduğunu varsayar, yani gerçekten iki metoda ihtiyacım yok. + +İyi niyetli olsalar da, bu tür argümanlar API kullanılarak kodun okunabilirliğini azaltmaya eğilimlidir. Gibi bir yöntem çağırma + +``` +parser.processNodes(text, false); +``` + +uygulamayı bilmeden veya en azından belgelere danışmadan neredeyse anlamsızdır. Bu yöntem muhtemelen arayanın rahatlığının aksine uygulayıcının rahatlığı için tasarlanmıştır - "Arayanın iki ayrı arama yapmak zorunda kalmasını istemiyorum", "İki ayrı yöntemi kodlamak istemedim" olarak çevrilmiştir." Sıkıcılığın, hantallığın veya beceriksizliğin panzehiri olması amaçlanıyorsa, temelde yanlış bir şey yoktur. Bununla birlikte, bu konuda biraz daha dikkatli düşünürsek, bu semptomların panzehiri verimlilik, tutarlılık ve zarafettir, rahatlık değil. API'lerin temeldeki karmaşıklığı gizlemesi gerekiyor, bu nedenle gerçekçi bir şekilde iyi API tasarımının biraz çaba gerektirmesini bekleyebiliriz. Tek bir büyük yöntemin yazılması, iyi düşünülmüş bir dizi işlemden kesinlikle daha uygun olabilir, ancak kullanımı daha kolay olur mu? + +Bir dil olarak API metaforu, bu durumlarda bizi daha iyi tasarım kararlarına yönlendirebilir. Bir API, faydalı soruları sormak ve yanıtlamak için yeterli kelime dağarcığının üstündeki sonraki katmanı veren, ifade edici bir dil sağlamalıdır. Bu, sorulmaya değer olabilecek her soru için tam olarak bir yöntem veya fiil sağlaması gerektiği anlamına gelmez. Farklı bir kelime dağarcığı, anlamdaki incelikleri ifade etmemizi sağlar. Örneğin, temelde aynı işlem olarak görülebilse de, sadece farklı hızlarda yürütülmüş olsa da, yürü(doğru) yerine koş demeyi tercih ederiz. Tutarlı ve iyi düşünülmüş bir API sözlüğü, bir sonraki katmanda kodun anlamlı ve anlaşılması kolay olmasını sağlar. Daha da önemlisi, şekillendirilebilir bir sözcük dağarcığı, diğer programcıların API'yi tahmin etmediğiniz şekillerde kullanmasına olanak tanır, API kullanıcıları için gerçekten büyük bir kolaylık! Bir dahaki sefere, birkaç şeyi tek bir API yönteminde toplamaya can attığınızda, bu kadar sık istenen bir işlem için gerçekten uygun görünse de, İngilizce dilinde 'MakeUpYourRoomBeQuietAndDoYourHomeWork' için tek bir kelime olmadığını unutmayın. + +[Gregor Hohpe](http://programmer.97things.oreilly.com/wiki/index.php/Gregor_Hohpe) Tarafından \ No newline at end of file From 1782d887d44664a13a65d04103cdb65a327e3943 Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Wed, 29 Dec 2021 18:17:43 +0300 Subject: [PATCH 037/290] added thing_20 --- tr/SUMMARY.md | 2 +- tr/thing_20/README.md | 15 +++++++++++++++ 2 files changed, 16 insertions(+), 1 deletion(-) create mode 100644 tr/thing_20/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index 4a9b28a0..e62c2164 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -20,7 +20,7 @@ 1. [Yalnızca Kodun Söyleyemediklerini Yorumlayın](thing_17/README.md) 1. [Devamlı öğrenme](thing_18/README.md) 1. [Kolaylık bir yetenek değildir](thing_19/README.md) -1. [Deploy Early and Often](thing_20/README.md) +1. [Erken ve Sıkça Dağıtın](thing_20/README.md) 1. [Distinguish Business Exceptions from Technical](thing_21/README.md) 1. [Do Lots of Deliberate Practice](thing_22/README.md) 1. [Domain-Specific Languages](thing_23/README.md) diff --git a/tr/thing_20/README.md b/tr/thing_20/README.md new file mode 100644 index 00000000..63b0101f --- /dev/null +++ b/tr/thing_20/README.md @@ -0,0 +1,15 @@ +# Erken ve Sıkça Dağıtın + +Dağıtım ve kurulum süreçlerinde hata ayıklama, genellikle bir projenin sonuna kadar ertelenir. Bazı projelerde, kurulum araçları yazmak, görevi "gerekli bir kötülük" olarak üstlenen bir yayın mühendisine devredilir. Her şeyin çalıştığından emin olmak için el yapımı bir ortamda incelemeler ve gösteriler yapılır. Sonuç olarak ekip, değişiklik yapmak için çok geç olana kadar dağıtım süreci veya dağıtılan ortamla ilgili hiçbir deneyim elde edemez. + +Kurulum/dağıtım süreci, müşterinin gördüğü ilk şeydir ve basit bir kurulum/dağıtım süreci, güvenilir (veya en azından hata ayıklaması kolay) bir üretim ortamına sahip olmanın ilk adımıdır. Dağıtılan yazılım, müşterinin kullanacağı şeydir. Dağıtımın uygulamayı doğru bir şekilde kurmasını sağlamazsanız, müşteriniz yazılımınızı tam olarak kullanmaya başlamadan önce onlara sorular yönelteceksiniz. + +Projenize bir kurulum süreci ile başlamak, siz ürün geliştirme döngüsü boyunca ilerlerken süreci geliştirmeniz için size zaman ve kurulumu kolaylaştırmak için uygulama kodunda değişiklik yapma şansı verecektir. Kurulum sürecini düzenli aralıklarla temiz bir ortamda çalıştırmak ve test etmek, geliştirme veya test ortamlarına dayanan kodda varsayımlarda bulunmadığınızı da kontrol eder. + +Dağıtımı en sona koymak, koddaki varsayımları çözmek için dağıtım sürecinin daha karmaşık olması gerekebileceği anlamına gelir. Bir ortam üzerinde tam kontrole sahip olduğunuz bir IDE'de harika bir fikir gibi görünen şey, çok daha karmaşık bir dağıtım süreci sağlayabilir. Tüm takasları bir an önce bilmek daha iyidir. + +Bir geliştiricinin dizüstü bilgisayarında çalışan bir uygulama görmekle karşılaştırıldığında, "dağıtabilmenin" erken dönemde çok fazla iş değeri yok gibi görünse de, basit gerçek şu ki, uygulamanızı hedef ortamda gösterene kadar, iş değeri sunmadan önce yapılacak çok iş var. Bir dağıtım sürecini erteleme gerekçeniz bunun önemsiz olmasıysa, düşük maliyetli olduğu için yine de yapın. Çok karmaşıksa veya çok fazla belirsizlik varsa, uygulama koduyla yapacağınızı yapın: ilerledikçe dağıtım sürecini deneyin, değerlendirin ve yeniden düzenleyin. + +Kurulum/dağıtım süreci, müşterilerinizin veya profesyonel hizmet ekibinizin üretkenliği için çok önemlidir; bu nedenle, devam ederken bu süreci test ediyor ve yeniden düzenlemelisiniz. Bir proje boyunca kaynak kodunu test eder ve yeniden düzenleriz. Dağıtım daha azını hak etmiyor. + +[Steve Berczuk](http://programmer.97things.oreilly.com/wiki/index.php/Steve_Berczuk) Tarafından \ No newline at end of file From 6083d3e31bf04975a5b2db759570dfb6812745fd Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Wed, 29 Dec 2021 18:39:42 +0300 Subject: [PATCH 038/290] added thing_21 --- tr/SUMMARY.md | 2 +- tr/thing_21/README.md | 17 +++++++++++++++++ 2 files changed, 18 insertions(+), 1 deletion(-) create mode 100644 tr/thing_21/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index e62c2164..8a183d73 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -21,7 +21,7 @@ 1. [Devamlı öğrenme](thing_18/README.md) 1. [Kolaylık bir yetenek değildir](thing_19/README.md) 1. [Erken ve Sıkça Dağıtın](thing_20/README.md) -1. [Distinguish Business Exceptions from Technical](thing_21/README.md) +1. [İş İstisnalarını Tekniklerden Ayırın](thing_21/README.md) 1. [Do Lots of Deliberate Practice](thing_22/README.md) 1. [Domain-Specific Languages](thing_23/README.md) 1. [Don't Be Afraid to Break Things](thing_24/README.md) diff --git a/tr/thing_21/README.md b/tr/thing_21/README.md new file mode 100644 index 00000000..75d8af87 --- /dev/null +++ b/tr/thing_21/README.md @@ -0,0 +1,17 @@ +# İş İstisnalarını Tekniklerden Ayırın + +Çalışma zamanında işlerin ters gitmesinin temelde iki nedeni vardır: uygulamayı kullanmamızı engelleyen teknik sorunlar ve uygulamayı yanlış kullanmamızı engelleyen iş mantığı. LISP, Java, Smalltalk ve C# gibi çoğu modern dil, bu iki durumu belirtmek için istisnalar kullanır. Bununla birlikte, iki durum o kadar farklıdır ki, dikkatlice ayrı tutulmaları gerekir. Her ikisini de aynı istisna hiyerarşisini kullanarak temsil etmek, aynı istisna sınıfından bahsetmemek, olası bir karışıklık kaynağıdır. + +Bir programlama hatası olduğunda çözülemeyen bir teknik sorun ortaya çıkabilir. Örneğin, 17 boyutundaki bir diziden 83 numaralı öğeye erişmeye çalışırsanız, program açıkça yoldan çıkar ve bazı istisnalar ortaya çıkmalıdır. Daha ince sürüm, uygun olmayan argümanlarla bazı kütüphane kodlarını çağırıyor ve aynı duruma kütüphanenin içinde neden oluyor. + +Kendi başınıza sebep olduğunuz bu durumları çözmeye çalışmak hata olur. Bunun yerine, istisnanın en yüksek mimari düzeye çıkmasına izin veriyoruz ve bir işlemi geri alma, günlüğe kaydetme ve yönetimi uyarma ve geri raporlama gibi sistemin güvenli bir durumda olmasını sağlamak için bazı genel istisna işleme mekanizmalarının elinden geleni yapmasına izin veriyoruz ( kibarca) kullanıcıya. + +Bu durumun bir çeşidi, "kütüphane durumunda" olduğunuzda ve bir arayan, örneğin tamamen tuhaf bir argüman ileterek veya bağımlı bir nesneyi düzgün bir şekilde ayarlayamayarak, yönteminizin sözleşmesini bozduğunda ortaya çıkar. Bu, 17'den 83. öğeye erişimle aynı düzeydedir: arayan kişinin kontrol etmesi gerekirdi; bunu yapmamak, istemci tarafında bir programcı hatasıdır. Uygun yanıt, teknik bir istisna oluşturmaktır. + +Yanıt vermeyen bir veritabanı gibi yürütme ortamındaki bir sorun nedeniyle programın devam edememesi farklı ancak yine de teknik bir durumdur. Bu durumda, altyapının durumu çözmek için elinden geleni yaptığını, bağlantıları onararak ve makul sayıda yeniden deneme yaptığını ve başarısız olduğunu varsaymalısınız. Sebep farklı olsa bile, çağıran kodun durumu benzerdir: bu konuda yapabileceği çok az şey vardır. Bu nedenle, genel istisna işleme mekanizmasına kadar artmasına izin verdiğimiz bir istisna aracılığıyla durumu işaret ederiz. + +Bunların aksine, etki alanı mantıksal bir nedenle aramayı tamamlayamayacağınız bir durumumuz var. Bu durumda, bir istisna olan, yani olağandışı ve istenmeyen, ancak tuhaf olmayan veya programatik olarak hatalı olmayan bir durumla karşılaştık. Örneğin, yeterli bakiyesi olmayan bir hesaptan para çekmeye çalışırsam. Başka bir deyişle, bu tür bir durum sözleşmenin bir parçasıdır ve bir istisna atmak, yalnızca modelin bir parçası olan ve müşterinin bilmesi ve işlemeye hazır olması gereken *alternatif bir dönüş yolu*dur. Bu durumlar için, müşterinin durumu kendi şartlarında ele alabilmesi için belirli bir istisna veya ayrı bir istisna hiyerarşisi oluşturmak uygundur. + +Teknik istisnaları ve iş istisnalarını aynı hiyerarşide karıştırmak, ayrımı bulanıklaştırır ve arayanın yöntem sözleşmesinin ne olduğu, çağrıdan önce hangi koşulların sağlanması gerektiği ve hangi durumları ele alması gerektiği konusunda kafasını karıştırır. Vakaları ayırmak netlik sağlar ve teknik istisnaların bazı uygulama çerçeveleri tarafından ele alınma şansını artırırken, iş alanı istisnaları aslında müşteri kodu tarafından değerlendirilir ve işlenir. + +[Dan Bergh Johnsson](http://programmer.97things.oreilly.com/wiki/index.php/Dan_Bergh_Johnsson) Tarafından \ No newline at end of file From a3448d156f29d9f66a9307fd5d7ac1809dda6be0 Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Thu, 30 Dec 2021 08:56:46 +0300 Subject: [PATCH 039/290] added thing_22 --- tr/SUMMARY.md | 2 +- tr/thing_22/README.md | 25 +++++++++++++++++++++++++ 2 files changed, 26 insertions(+), 1 deletion(-) create mode 100644 tr/thing_22/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index 8a183d73..d63bfd35 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -22,7 +22,7 @@ 1. [Kolaylık bir yetenek değildir](thing_19/README.md) 1. [Erken ve Sıkça Dağıtın](thing_20/README.md) 1. [İş İstisnalarını Tekniklerden Ayırın](thing_21/README.md) -1. [Do Lots of Deliberate Practice](thing_22/README.md) +1. [Bol Bol Kasıtlı Uygulama Yapın](thing_22/README.md) 1. [Domain-Specific Languages](thing_23/README.md) 1. [Don't Be Afraid to Break Things](thing_24/README.md) 1. [Don't Be Cute with Your Test Data](thing_25/README.md) diff --git a/tr/thing_22/README.md b/tr/thing_22/README.md new file mode 100644 index 00000000..ab47b0a3 --- /dev/null +++ b/tr/thing_22/README.md @@ -0,0 +1,25 @@ +# Bol Bol Kasıtlı Uygulama Yapın + +Kasıtlı uygulama sadece bir görevi yerine getirmek değildir. Kendinize "Bu görevi neden yapıyorum?" diye sorarsanız. ve cevabınız "Görevi tamamlamak için" ise, o zaman kasıtlı bir uygulama yapmıyorsunuz demektir. + +Bir görevi yerine getirme yeteneğinizi geliştirmek için kasıtlı olarak pratik yaparsınız. Beceri ve teknikle ilgili. Kasıtlı uygulama tekrar anlamına gelir. Görevin bir veya daha fazla yönüne ilişkin uzmanlığınızı artırmak amacıyla görevi gerçekleştirmek anlamına gelir. Tekrarı tekrar etmek demektir. Yavaşça, tekrar tekrar. İstediğiniz ustalık seviyesine ulaşana kadar. Görevi tamamlamak için değil, görevde ustalaşmak için kasıtlı olarak pratik yaparsınız. + +Ücretli geliştirmenin temel amacı bir ürünü bitirmek iken, kasıtlı uygulamanın temel amacı performansınızı iyileştirmektir. Onlar aynı değil. Kendinize sorun, başka birinin ürününü geliştirmek için ne kadar zaman harcıyorsunuz? Kendini ne kadar geliştiriyorsun? + +Uzmanlık kazanmak için ne kadar bilinçli bir uygulama gerekiyor? + +- Peter Norvig "Bu 10.000 saat [...] sihirli sayı olabilir" diye [yazıyor](http://norvig.com/21-days.html). +- *Yalın Yazılım Geliştirmede Öncü* Mary Poppendieck, "Elit sanatçıların uzman olmaları için en az 10.000 saat kasıtlı odaklı uygulama gerektiğini" belirtiyor. + +Uzmanlık zaman içinde kademeli olarak gelir, hepsi 10.000'inci saatte bir kerede değil! Yine de 10.000 saat çok fazla: 10 yıl boyunca haftada yaklaşık 20 saat. Bu düzeyde bağlılık göz önüne alındığında, yalnızca uzman malzeme olmadığınızdan endişe ediyor olabilirsiniz. Sen. Yücelik büyük ölçüde bilinçli bir seçim meselesidir. *Seçim sizin.* Son yirmi yılda yapılan araştırmalar, uzmanlık edinmedeki ana faktörün kasıtlı uygulama yapmak için harcanan zaman olduğunu göstermiştir. Doğuştan gelen yetenek ana faktör *değildir*. + +- Mary: "Uzman performans araştırmacıları arasında, doğuştan gelen yeteneğin bir eşikten çok daha fazlasını hesaba katmadığı konusunda geniş bir fikir birliği var; bir spora veya mesleğe başlamak için minimum miktarda doğal yeteneğe sahip olmanız gerekir. Bundan sonra insanlar, üstün olanlar, en çok çalışanlardır." + +Halihazırda uzman olduğunuz bir şeyi kasıtlı olarak uygulamanın pek bir anlamı yok. Kasıtlı uygulama, iyi olmadığınız bir şeyi uygulamak anlamına gelir. + +- Peter: "[Uzmanlığı geliştirmenin] anahtarı * müzakereci* uygulamadır: sadece tekrar tekrar yapmak değil, aynı zamanda mevcut yeteneğinizin hemen ötesinde bir görevle kendinize meydan okumak, denemek, bunu yaparken ve yaptıktan sonra performansınızı analiz etmek , ve herhangi bir hatayı düzeltmek." +- Mary: "Kasıtlı uygulama, iyi olduğunuz şeyi yapmak anlamına gelmez; kendinize meydan okumak, iyi olmadığınız şeyi yapmak anlamına gelir. Bu yüzden mutlaka eğlenceli değil." + +Kasıtlı uygulama öğrenme ile ilgilidir. Sizi değiştiren öğrenme hakkında; davranışınızı değiştiren öğrenme. İyi şanlar. + +[Jon Jagger](http://programmer.97things.oreilly.com/wiki/index.php/Jon_Jagger) Tarafından \ No newline at end of file From 37ae7701919040ff56ddfdd6982b2b2689a6eeca Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Thu, 30 Dec 2021 09:20:36 +0300 Subject: [PATCH 040/290] added thing_23 --- tr/SUMMARY.md | 2 +- tr/thing_23/README.md | 17 +++++++++++++++++ 2 files changed, 18 insertions(+), 1 deletion(-) create mode 100644 tr/thing_23/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index d63bfd35..1da02bd5 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -23,7 +23,7 @@ 1. [Erken ve Sıkça Dağıtın](thing_20/README.md) 1. [İş İstisnalarını Tekniklerden Ayırın](thing_21/README.md) 1. [Bol Bol Kasıtlı Uygulama Yapın](thing_22/README.md) -1. [Domain-Specific Languages](thing_23/README.md) +1. [Etki Alanına Özgü Diller](thing_23/README.md) 1. [Don't Be Afraid to Break Things](thing_24/README.md) 1. [Don't Be Cute with Your Test Data](thing_25/README.md) 1. [Don't Ignore that Error!](thing_26/README.md) diff --git a/tr/thing_23/README.md b/tr/thing_23/README.md new file mode 100644 index 00000000..3224c602 --- /dev/null +++ b/tr/thing_23/README.md @@ -0,0 +1,17 @@ +# Etki Alanına Özgü Diller + +Satranç oyuncuları, anaokulu öğretmenleri veya sigorta acenteleri gibi herhangi bir alandaki uzmanların bir tartışmasını her dinlediğinizde, kelime dağarcığının günlük dilden oldukça farklı olduğunu fark edeceksiniz. Bu, alana özgü dillerin (DSL'ler) neyle ilgili olduğunun bir parçasıdır: Belirli bir alan, o alana özgü şeyleri tanımlamak için özel bir kelime dağarcığına sahiptir. + +Yazılım dünyasında, DSL'ler, sınırlı kelime dağarcığına ve dilbilgisine sahip bir alana özgü bir dilde, okunabilir, anlaşılabilir ve umarım etki alanı uzmanları tarafından yazılabilir, yürütülebilir ifadelerle ilgilidir. Yazılım geliştiricileri veya bilim adamlarını hedef alan DSL'ler uzun süredir ortalıkta dolaşmaktadır. + +Örneğin, yapılandırma dosyalarında bulunan Unix 'küçük diller' ve LISP makrolarının gücüyle oluşturulan diller daha eski örneklerden bazılarıdır. + +DSL'ler genellikle *dahili* veya *harici* olarak sınıflandırılır: + +- **Dahili DSL'ler**, sözdizimi daha çok doğal dile benzeyecek şekilde bükülmüş genel amaçlı bir programlama dilinde yazılmıştır. Bu, daha fazla sözdizimsel şeker ve biçimlendirme olanakları (örn., Ruby ve Scala) sunan diller için, sunmayan diğer dillere (örn. Java) göre daha kolaydır. Çoğu dahili DSL, mevcut API'leri, kitaplıkları veya iş kodunu sarar ve işlevselliğe daha az akıl almaz erişim için bir sarmalayıcı sağlar. Sadece çalıştırılarak doğrudan çalıştırılabilirler. Uygulamaya ve etki alanına bağlı olarak, veri yapıları oluşturmak, bağımlılıkları tanımlamak, süreçleri veya görevleri çalıştırmak, diğer sistemlerle iletişim kurmak veya kullanıcı girdisini doğrulamak için kullanılırlar. Dahili bir DSL'nin sözdizimi, ana bilgisayar dili tarafından sınırlandırılmıştır. Ana bilgisayar dilini DSL'nize uyarlamanıza yardımcı olabilecek birçok kalıp (örneğin, ifade oluşturucu, yöntem zincirleme ve açıklama ekleme) vardır. Ana bilgisayar dili yeniden derleme gerektirmiyorsa, bir etki alanı uzmanıyla yan yana çalışarak oldukça hızlı bir şekilde dahili bir DSL geliştirilebilir. + +- **Harici DSL'ler** dilin metinsel veya grafiksel ifadeleridir, metinsel DSL'ler grafiksel olanlardan daha yaygın olma eğiliminde olsa da. Metinsel ifadeler, sözlük, ayrıştırıcı, model dönüştürücü, oluşturucular ve diğer herhangi bir son işleme türünü içeren bir araç zinciri tarafından işlenebilir. Harici DSL'ler çoğunlukla daha sonraki işlemler için temel oluşturan dahili modellere okunur. Bir dilbilgisi tanımlamak yararlıdır (örneğin, EBNF'de). Bir dilbilgisi, araç zincirinin parçalarını (ör. düzenleyici, görselleştirici, ayrıştırıcı oluşturucu) oluşturmak için başlangıç noktası sağlar. Basit DSL'ler için, örneğin normal ifadeler kullanarak el yapımı bir ayrıştırıcı yeterli olabilir. Kendilerinden çok fazla şey istenirse özel ayrıştırıcılar hantal hale gelebilir, bu nedenle özellikle dil gramerleri ve DSL'lerle çalışmak için tasarlanmış araçlara bakmak mantıklıdır, örneğin, openArchitectureWare, ANTlr, SableCC, AndroMDA. Harici DSL'leri XML lehçeleri olarak tanımlamak da oldukça yaygındır, ancak okunabilirlik genellikle bir sorundur, özellikle teknik olmayan okuyucular için. + +DSL'nizin hedef kitlesini her zaman hesaba katmalısınız. Geliştiriciler, yöneticiler, ticari müşteriler veya son kullanıcılar mı? Dilin teknik düzeyini, mevcut araçları, sözdizimi yardımını, erken doğrulamayı, görselleştirmeyi ve temsili hedef kitleye uyarlamanız gerekir. DSL'ler, teknik ayrıntıları gizleyerek kullanıcıları, geliştiricilerin yardımına ihtiyaç duymadan sistemleri ihtiyaçlarına göre uyarlama yeteneği vererek güçlendirilebilir. Ayrıca, ilk dil çerçevesi uygulandıktan sonra işin potansiyel dağılımı nedeniyle geliştirmeyi hızlandırabilir. Dil yavaş yavaş geliştirilebilir. Mevcut ifadeler ve gramerler için farklı geçiş yolları da mevcuttur. + +[Michael Hunger](http://programmer.97things.oreilly.com/wiki/index.php/Michael_Hunger) Tarafından \ No newline at end of file From 6ee551e326f2a919daa4589bd26f035cd7c47788 Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Fri, 31 Dec 2021 09:00:11 +0300 Subject: [PATCH 041/290] added thing_24 --- tr/SUMMARY.md | 2 +- tr/thing_24/README.md | 13 +++++++++++++ 2 files changed, 14 insertions(+), 1 deletion(-) create mode 100644 tr/thing_24/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index 1da02bd5..9d2cdca8 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -24,7 +24,7 @@ 1. [İş İstisnalarını Tekniklerden Ayırın](thing_21/README.md) 1. [Bol Bol Kasıtlı Uygulama Yapın](thing_22/README.md) 1. [Etki Alanına Özgü Diller](thing_23/README.md) -1. [Don't Be Afraid to Break Things](thing_24/README.md) +1. [Bir Şeyleri Kırmaktan Korkma](thing_24/README.md) 1. [Don't Be Cute with Your Test Data](thing_25/README.md) 1. [Don't Ignore that Error!](thing_26/README.md) 1. [Don't Just Learn the Language, Understand its Culture](thing_27/README.md) diff --git a/tr/thing_24/README.md b/tr/thing_24/README.md new file mode 100644 index 00000000..24d9094d --- /dev/null +++ b/tr/thing_24/README.md @@ -0,0 +1,13 @@ +# Bir Şeyleri Kırmaktan Korkma + +Sektör deneyimi olan herkes, kod tabanının en iyi ihtimalle güvencesiz olduğu bir projede yüksek bir ihtimalle çalışmıştır. Sistem zayıf bir şekilde çarpanlara ayrılmıştır ve bir şeyi değiştirmek her zaman başka bir alakasız özelliği bozmayı başarır. Bir modül eklendiğinde, kodlayıcının amacı mümkün olduğunca az değişiklik yapmak ve her sürümde nefesini tutmaktır. Bu, bir gökdelendeki kirişlerle Jenga oynamaya eşdeğer yazılımdır ve felakete mahkumdur. + +Değişiklik yapmanın bu kadar sinir bozucu olmasının nedeni, sistemin hasta olmasıdır. Bir doktora ihtiyacı var, aksi takdirde durumu daha da kötüleşecek. Sisteminizde neyin yanlış olduğunu zaten biliyorsunuz ama omletinizi yapmak için yumurtaları kırmaktan korkuyorsunuz. Yetenekli bir cerrah ameliyat için kesi yapılması gerektiğini bilir, ancak yetenekli cerrah kesilerin geçici olduğunu ve iyileşeceğini de bilir. Ameliyatın sonucu ilk acıya değer ve hasta ameliyattan önceki halinden daha iyi bir duruma gelmelidir. + +Kodunuzdan korkmayın. Bir şeyleri hareket ettirirken bir şeylerin geçici olarak kırılması kimin umurunda? Başlangıçta projenizi bu duruma getiren şey, felç edici bir değişim korkusudur. Yeniden düzenlemeye zaman ayırmak, projenizin yaşam döngüsü boyunca birkaç kez kendini amorti etmesine yetecektir. Ek bir fayda da, ekibinizin hastalıklı sistemle ilgili deneyiminin sizi sistemin nasıl *çalışması* gerektiği konusunda uzman yapmasıdır. Bu bilgiyi ona kızmak yerine uygulayın. Nefret ettiğiniz bir sistem üzerinde çalışmak, kimsenin zamanını harcaması gerektiği gibi değil. + +Dahili arayüzleri yeniden tanımlayın, modülleri yeniden yapılandırın, kopyala-yapıştır kodu yeniden yapılandırın ve bağımlılıkları azaltarak tasarımınızı basitleştirin. Genellikle yanlış bağlanmış özelliklerden kaynaklanan köşe durumlarını ortadan kaldırarak kod karmaşıklığını önemli ölçüde azaltabilirsiniz. Yol boyunca test ederek eski yapıyı yavaşça yenisine geçirin. "Bir büyük sorun" içinde büyük bir yeniden düzenleme yapmaya çalışmak, tüm çabayı yarıda bırakmayı düşünmenizi sağlayacak kadar soruna neden olacaktır. + +İyileşmeye yer açmak için hastalıklı parçaları kesmekten korkmayan cerrah olun. Bu tavır bulaşıcıdır ve başkalarına erteledikleri temizlik projeleri üzerinde çalışmaya başlamaları için ilham verecektir. Projenin genel iyiliği için ekibin değerli olduğunu düşündüğü görevlerin bir "hijyen" listesini tutun. Yönetimi, bu görevlerin görünür sonuçlar vermese bile, masrafları azaltacağına ve gelecekteki sürümleri hızlandıracağına ikna edin. Kodun genel "sağlığını" önemsemeyi asla bırakmayın. + +[Mike Lewis](http://programmer.97things.oreilly.com/wiki/index.php/Mike_Lewis) Tarafından \ No newline at end of file From 09a3113c716b03b936260195251e0b98262fe87e Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Fri, 31 Dec 2021 09:26:29 +0300 Subject: [PATCH 042/290] added thing_25 --- tr/SUMMARY.md | 2 +- tr/thing_25/README.md | 25 +++++++++++++++++++++++++ 2 files changed, 26 insertions(+), 1 deletion(-) create mode 100644 tr/thing_25/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index 9d2cdca8..02ce86b4 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -25,7 +25,7 @@ 1. [Bol Bol Kasıtlı Uygulama Yapın](thing_22/README.md) 1. [Etki Alanına Özgü Diller](thing_23/README.md) 1. [Bir Şeyleri Kırmaktan Korkma](thing_24/README.md) -1. [Don't Be Cute with Your Test Data](thing_25/README.md) +1. [Test Verilerinizle Sevimli Olmayın](thing_25/README.md) 1. [Don't Ignore that Error!](thing_26/README.md) 1. [Don't Just Learn the Language, Understand its Culture](thing_27/README.md) 1. [Don't Nail Your Program into the Upright Position](thing_28/README.md) diff --git a/tr/thing_25/README.md b/tr/thing_25/README.md new file mode 100644 index 00000000..ef6afb21 --- /dev/null +++ b/tr/thing_25/README.md @@ -0,0 +1,25 @@ +# Test Verilerinizle Sevimli Olmayın + +> *Geç oluyordu. Üzerinde çalıştığım sayfa düzenini test etmek için bazı yer tutucu verileri gönderiyordum.* + +> *Kullanıcıların isimlerini The Clash üyelerine tahsis ettim. Şirket isimleri? Sex Pistols'un şarkı isimleri de işe yarardı. Şimdi birkaç hisse senedi sembolüne ihtiyacım vardı, sadece büyük harflerle birkaç harfli kelime.* + +> ***bu** birkaç harfli kelimeleri kullandım.* + +> *Zararsız görünüyordu. Gerçek veri kaynağını bağlamadan önceki gün kendimi ve belki diğer geliştiricileri eğlendirecek bir şey.* + +> *Ertesi sabah, bir proje yöneticisi sunum için bazı ekran görüntüleri aldı.** + +Programlama tarihi bu tür savaş hikayeleriyle dolu. Geliştiricilerin ve tasarımcıların "kimsenin göremeyeceği" şeyler beklenmedik bir şekilde görünür hale geldi. Sızıntı türü değişebilir, ancak gerçekleştiğinde sorumlu kişi, ekip veya şirket için ölümcül olabilir. Örnekler şunları içerir: + +- Bir durum toplantısı sırasında, müşteri henüz uygulanmamış bir düğmeye tıklar. Onlara "Bir daha tıklama, seni moron" deniyor. +- Eski bir sistemi koruyan bir yazılımcıya bir hata iletişim kutusu eklemesi söylendi ve onu güçlendirmek için mevcut sahne arkası günlük kaydının çıktısını kullanmaya karar verdi. Kullanıcılar birdenbire "Kutsal veritabanı işleme hatası Batman!" gibi mesajlarla karşı karşıya kalıyor herhangi bir hata alındığında. +- Birisi test ve canlı yönetim arayüzlerini karıştırıyor ve bazı "komik" veri girişleri yapıyor. Müşteriler, çevrimiçi mağazanızda 1 milyon dolarlık "Bill Gates şeklindeki kişisel masaj aletini" indirimde görüyor. + +"Gerçek ayakkabılarını giyerken, yalan dünyanın yarısını dolaşır" şeklindeki eski deyişi benimsemek için, Bu çağda, geliştiricinin saat dilimindeki herhangi biri bu konuda bir şey yapmak için uyanık olmadan önce Dugg, Twittered ve Flibflarbed olabilir. + +Kaynak kodunuz bile mutlaka incelemeden muaf değildir. 2004'te, Windows 2000 kaynak kodunun bir tarball'ı dosya paylaşım ağlarına girdiğinde, bazı insanlar neşeyle küfür, hakaret ve [diğer komik içerik](http://www.kuro5hin.org/story/2004/2/15/71552/7795) için bu dosyaya girdiler. (`// KORKUNÇ KORKUNÇ YOK İYİ ÇOK KÖTÜ HACK` yorumu, kabul ediyorum, o zamandan beri zaman zaman benim tarafımdan benimsendi!) + +Özetle, kodunuza herhangi bir metin yazarken (yorumlar, günlük kaydı, diyaloglar veya test verileri) her zaman kendinize, genel hale gelirse nasıl görüneceğini sorun. Her yönden bazı kırmızı yüzleri kurtaracak. + +[Rod Begbie](http://programmer.97things.oreilly.com/wiki/index.php/Rod_Begbie) Tarafından \ No newline at end of file From d950e9be839afb53a08e0f2ba5f7640963bb1843 Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Mon, 3 Jan 2022 09:06:01 +0300 Subject: [PATCH 043/290] added thing_26 --- tr/SUMMARY.md | 2 +- tr/thing_26/README.md | 47 +++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 48 insertions(+), 1 deletion(-) create mode 100644 tr/thing_26/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index 02ce86b4..ff068787 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -26,7 +26,7 @@ 1. [Etki Alanına Özgü Diller](thing_23/README.md) 1. [Bir Şeyleri Kırmaktan Korkma](thing_24/README.md) 1. [Test Verilerinizle Sevimli Olmayın](thing_25/README.md) -1. [Don't Ignore that Error!](thing_26/README.md) +1. [Hatayı Görmezden Gelmeyin!](thing_26/README.md) 1. [Don't Just Learn the Language, Understand its Culture](thing_27/README.md) 1. [Don't Nail Your Program into the Upright Position](thing_28/README.md) 1. [Don't Rely on "Magic Happens Here"](thing_29/README.md) diff --git a/tr/thing_26/README.md b/tr/thing_26/README.md new file mode 100644 index 00000000..55b781e9 --- /dev/null +++ b/tr/thing_26/README.md @@ -0,0 +1,47 @@ +# Hatayı Görmezden Gelmeyin! + +> *Bir akşam barda arkadaşlarla buluşmak için sokakta yürüyordum. Bir süredir bira içmemiştik ve onları tekrar görmeyi dört gözle bekliyordum. Acele içinde nereye gittiğime bakmıyordum. Bir kaldırımın kenarına takıldım ve yüz üstü kaldım. Eh, sanırım dikkat etmemem de bana hizmet ediyor.* + +> *Bacağımı acıttı ama arkadaşlarımla buluşmak için acelem vardı. Bu yüzden kendimi toparladım ve devam ettim. Yürüdükçe ağrım artıyordu. Başta bunu şok olarak görmeme rağmen, bir şeylerin ters gittiğini çabucak fark ettim.* + +> *Ama ne olursa olsun bara koştum. Geldiğimde acı içindeydim. Dışarıda harika bir gece geçirmedim çünkü dikkatim çok dağınıktı. Sabah doktora gittim ve kaval kemiğimin kırıldığını öğrendim. Acıyı hissettiğimde durmuş olsaydım, üzerinde yürüdüğüm bir çok ekstra hasarı önlemiş olurdum. Muhtemelen hayatımın en kötü ertesi sabahı.* + +Çok fazla yazılımcı benim felaket gecem gibi kod yazıyor. + +*Hata, ne hatası? Ciddi olmayacak. Açıkçası. Bunu görmezden gelebilirim.* Bu, katı kod için kazanan bir strateji değildir. Aslında, bu sadece basit tembellik. (Yanlış sıralama.) Kodunuzda bir hata olma ihtimali ne kadar düşük olursa olsun, her zaman onu kontrol etmeli ve her zaman onunla ilgilenmelisiniz. Her zaman. Bunu yapmazsanız zaman kazanmıyorsunuz: Gelecek için olası sorunları biriktiriyorsunuz. + +Kodumuzdaki hataları aşağıdakiler dahil olmak üzere çeşitli şekillerde rapor ederiz: + +- **Dönüş kodları**, "işe yaramadı" anlamına gelen bir işlevin sonuç değeri olarak kullanılabilir. Hata dönüş kodlarını görmezden gelmek çok kolaydır. Sorunu vurgulamak için kodda hiçbir şey görmezsiniz. Gerçekten de, bazı standart C işlevlerinin dönüş değerlerini yok saymak standart bir uygulama haline geldi. printf'ten dönüş değerini ne sıklıkla kontrol ediyorsunuz? + +- **errno** tuhaf bir C sapmasıdır, hatayı bildirmek için ayrı bir global değişkendir. Yok saymak kolaydır, kullanması zordur ve her türlü kötü soruna yol açar - örneğin, aynı işlevi çağıran birden fazla iş parçacığınız olduğunda ne olur? Bazı platformlar sizi burada acıdan yalıtır; diğerleri yapmaz. + +- **İstisnalar**, daha yapılandırılmış, dil destekli bir sinyal verme ve hataları işleme yöntemidir. Ve muhtemelen onları görmezden gelemezsiniz. Yoksa yapabilir misin? Bunun gibi birçok kod gördüm: + +``` +try { + // ...do something... +} +catch (...) {} // ignore errors +``` + +Bu korkunç yapının kurtarıcı zarafeti, ahlaki olarak şüpheli bir şey yaptığınız gerçeğini vurgulamasıdır. + +Bir hatayı görmezden gelirseniz, görmezden gelir ve hiçbir şey yolunda gitmemiş gibi davranırsanız, büyük riskler alırsınız. Bacağımın üzerinde yürümeyi bıraktığımdan daha kötü bir duruma gelmesi gibi, sürmeye devam etmek de çok karmaşık arızalara yol açabilir. Sorunlarla ilk fırsatta ilgilenin. Kısa bir hesap tutun. + +Hataları ele almamak şunlara yol açar: + +- **Kırılgan kod.** Heyecan verici, bulunması zor hatalarla dolu kod. +- **Güvensiz kod.** Çatlaklar, yazılım sistemlerine girmek için genellikle zayıf hata işlemeden yararlanır. +- **Kötü yapı.** Kodunuzda sürekli olarak uğraşılması sıkıcı hatalar varsa, muhtemelen kötü bir arayüze sahipsiniz demektir. Hatalar daha az müdahaleci olacak ve bunların ele alınması daha az zahmetli olacak şekilde ifade edin. + +Kodunuzdaki tüm olası hataları kontrol etmeniz gerektiği gibi, arayüzlerinizdeki tüm olası hatalı koşulları ortaya çıkarmanız gerekir. Hizmetlerinizin her zaman işe yarayacağını iddia ederek onları saklamayın. + +Neden hataları kontrol etmiyoruz? Bir dizi yaygın mazeret var. Bunlardan hangisine katılıyorsunuz? Her birine nasıl karşı koyarsınız? + +- Hata işleme, kodun akışını karıştırır, okumayı zorlaştırır ve "normal" yürütme akışını tespit etmeyi zorlaştırır. +- Fazladan bir iş ve yaklaşan bir teslim tarihim var. +- Bu işlev çağrısının *asla* bir hata döndürmeyeceğini biliyorum (printf her zaman çalışır, malloc her zaman yeni bellek döndürür - başarısız olursa daha büyük sorunlarımız olur...). +- Bu sadece bir oyuncak programıdır ve prodüksiyona uygun bir seviyede yazılması gerekmez. + +[Pete Goodliffe](http://programmer.97things.oreilly.com/wiki/index.php/Pete_Goodliffe) Tarafından \ No newline at end of file From 89aa713365e732a2c91c53a73583330dd9a118e4 Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Wed, 12 Jan 2022 14:20:59 +0300 Subject: [PATCH 044/290] added thing_27 --- tr/SUMMARY.md | 2 +- tr/thing_27/README.md | 13 +++++++++++++ 2 files changed, 14 insertions(+), 1 deletion(-) create mode 100644 tr/thing_27/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index ff068787..093c8831 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -27,7 +27,7 @@ 1. [Bir Şeyleri Kırmaktan Korkma](thing_24/README.md) 1. [Test Verilerinizle Sevimli Olmayın](thing_25/README.md) 1. [Hatayı Görmezden Gelmeyin!](thing_26/README.md) -1. [Don't Just Learn the Language, Understand its Culture](thing_27/README.md) +1. [Sadece Dili Öğrenmeyin, Kültürünü Anlayın](thing_27/README.md) 1. [Don't Nail Your Program into the Upright Position](thing_28/README.md) 1. [Don't Rely on "Magic Happens Here"](thing_29/README.md) 1. [Don't Repeat Yourself](thing_30/README.md) diff --git a/tr/thing_27/README.md b/tr/thing_27/README.md new file mode 100644 index 00000000..4d4bff75 --- /dev/null +++ b/tr/thing_27/README.md @@ -0,0 +1,13 @@ +# Sadece Dili Öğrenmeyin, Kültürünü Anlayın + +Lisede yabancı dil öğrenmek zorunda kaldım. O zamanlar iyi bir İngilizceyle iyileşeceğimi düşündüm, bu yüzden üç yıllık Fransızca dersinde uyumayı seçtim. Birkaç yıl sonra tatil için Tunus'a gittim. Arapça oradaki resmi dildir ve eski bir Fransız kolonisi olduğu için Fransızca da yaygın olarak kullanılmaktadır. İngilizce sadece turistik bölgelerde konuşulur. Dil konusundaki bilgisizliğim yüzünden, kendimi havuz başında James Joyce'un biçim ve dildeki güç gösterisi olan *Finnegans Wake*'i okurken buldum. Joyce'un kırktan fazla dili eğlenceli bir şekilde harmanlaması, yorucu olsa da şaşırtıcı bir deneyimdi. Yabancı kelimelerin ve cümlelerin nasıl iç içe geçtiğini anlamak, yazara kendini ifade etmenin yeni yollarını verdiğini anlamak, programlama kariyerimde yanımda taşıdığım bir şeydi. + +Andy Hunt ve Dave Thomas, çığır açıcı kitaplarında *The Pragmatic Programmer*, her yıl yeni bir programlama dili öğrenmemizi teşvik ediyor. Onların tavsiyelerine göre yaşamaya çalıştım ve yıllar boyunca birçok dilde programlama deneyimim oldu. Çok dilli maceralarımdan aldığım en önemli ders, bir dili öğrenmek için söz dizimini öğrenmekten fazlasının gerektiğidir: Kültürünü anlamanız gerekir. Fortran'ı herhangi bir dilde yazabilirsiniz, ancak bir dili gerçekten öğrenmek için o dili benimsemeniz gerekir. C# kodunuz çoğunlukla statik yardımcı yöntemler içeren uzun bir Main yöntemiyse mazeret üretmeyin, ancak sınıfların neden anlamlı olduğunu öğrenin. + +Yeni bir dilin iplerini öğrendikten sonra, zaten bildiğiniz dilleri yeni şekillerde kullanmaya nasıl başlayacağınıza şaşıracaksınız. C#'ta delegeleri etkili bir şekilde kullanmayı Ruby'yi programlayarak öğrendim, .NET jeneriklerinin tüm potansiyelini ortaya çıkarmak bana Java jeneriklerini nasıl daha kullanışlı hale getirebileceğim konusunda fikirler verdi ve LINQ kendime Scala'yı öğretmeyi bir esinti haline getirdi. + +Ayrıca farklı diller arasında geçiş yaparak tasarım kalıplarını daha iyi anlayacaksınız. C yazılımcıları, C# ve Java'nın yineleyici kalıbı metalaştırdığını bulur. Ruby ve diğer dinamik dillerde yine de bir ziyaretçi kullanabilirsiniz, ancak uygulamanız Gang of Four kitabındaki örneğe benzemeyecektir. + +Bazıları *Finnegans Wake*'in okunamaz olduğunu iddia edebilir, bazıları ise onu stilistik güzelliği için alkışlayabilir. Kitabı daha az ürkütücü bir okuma yapmak için, tek dilli çeviriler mevcuttur. İronik olarak, bunlardan ilki Fransızcaydı. Kod birçok yönden benzerdir. Biraz Python, biraz Java ve biraz Erlang ile *Wakese* kodu yazarsanız, projeleriniz karmakarışık olur. Bunun yerine zihninizi genişletmek için yeni diller keşfederseniz ve işleri farklı şekillerde nasıl çözebileceğiniz konusunda yeni fikirler edinirseniz, eski güvenilir dilinizde yazdığınız kodun öğrendiğiniz her yeni dil için daha güzel olduğunu göreceksiniz. + +Anders Norås Tarafından \ No newline at end of file From 63371c12f2aef3225e8caefe5541cc8d245cf8a7 Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Wed, 12 Jan 2022 18:55:04 +0300 Subject: [PATCH 045/290] added thing_28 --- tr/SUMMARY.md | 2 +- tr/thing_28/README.md | 19 +++++++++++++++++++ 2 files changed, 20 insertions(+), 1 deletion(-) create mode 100644 tr/thing_28/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index 093c8831..a606dc1b 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -28,7 +28,7 @@ 1. [Test Verilerinizle Sevimli Olmayın](thing_25/README.md) 1. [Hatayı Görmezden Gelmeyin!](thing_26/README.md) 1. [Sadece Dili Öğrenmeyin, Kültürünü Anlayın](thing_27/README.md) -1. [Don't Nail Your Program into the Upright Position](thing_28/README.md) +1. [Programınızı Dik Konumda Çivilemeyin](thing_28/README.md) 1. [Don't Rely on "Magic Happens Here"](thing_29/README.md) 1. [Don't Repeat Yourself](thing_30/README.md) 1. [Don't Touch that Code!](thing_31/README.md) diff --git a/tr/thing_28/README.md b/tr/thing_28/README.md new file mode 100644 index 00000000..f84d9b02 --- /dev/null +++ b/tr/thing_28/README.md @@ -0,0 +1,19 @@ +# Programınızı Dik Konumda Çivilemeyin + +Bir keresinde, istisna işleme için aşağıdaki stratejiyi hicivli bir şekilde önerdiğim bir sahte C++ sınavı yazdım: + +> Kod tabanımızdaki çok sayıda `try...catch` yapısı sayesinde, bazen uygulamalarımızın iptal edilmesini önleyebiliriz. Ortaya çıkan durumu "cesedi dik pozisyonda çivilemek" olarak düşünürüz. + +Alaysızlığıma rağmen, aslında Dame Bitter Experience'ın dizinin dibinde aldığım bir dersi özetledim. + +Kendi ev yapımı C++ kitaplığımızda temel bir uygulama sınıfıydı. Yıllar boyunca pek çok yazılımcının parmaklarını dürttü: Kimsenin eli temiz değildi. Diğer her şeyden kaçan istisnalarla başa çıkmak için kod içeriyordu. Catch-22'de Yossarian'dan yola çıkarak, bu sınıfın bir örneğinin sonsuza kadar yaşaması veya bu girişimde ölmesi gerektiğine karar verdik veya daha doğrusu hissettik (*karar verdi* bu canavarın inşasına girmekten daha fazla düşünce anlamına gelir). + +Bu amaçla, birden çok istisna işleyicisini iç içe geçirdik. Windows'un yapılandırılmış özel durum işlemesini yerel türle karıştırdık (C++'da '__try...__except'i hatırla? Ben de yokum). Beklenmedik bir şekilde işler ters gittiğinde, parametrelere daha sert basarak onları tekrar çağırmayı denedik. Geriye dönüp baktığımda, bir başkasının catch cümlesi içinde içsel bir 'try...catch' işleyicisi yazarken, iyi uygulama otoyolundan kazara bir kayma yolu seçmiş olabileceğime dair bir tür farkındalığın üzerime çöktüğünü düşünmek hoşuma gidiyor, aromatik ama sağlığa zararlı delilik şeridi. Ancak, bu muhtemelen geriye dönük bir bilgeliktir. + +Söylemeye gerek yok, ne zaman bu sınıfa dayalı uygulamalarda bir şeyler ters gitse, rıhtımdaki Mafya kurbanları gibi ortadan kayboldular ve felaketi kaydetmek için çağrıldığı varsayılan çöplük rutinlerine rağmen, arkalarında ne olduğunu gösteren hiçbir yararlı kabarcık izi bırakmadılar. Sonunda, uzun bir süre sonra yaptıklarımızın hesabını yaptık ve utanç duyduk. Tüm karmaşayı minimal ve sağlam bir raporlama mekanizmasıyla değiştirdik. Ancak bu, çizgide birçok kaza oldu. + +Seni bununla rahatsız etmem, kesinlikle başka kimse bizim kadar aptal olamaz ama geçenlerde, akademik iş unvanı daha iyi bilmesi gerektiğini söyleyen bir adamla çevrimiçi bir tartışma yaptım. Uzak bir işlemde Java kodunu tartışıyorduk. Kodun başarısız olması durumunda, *in situ* istisnasını yakalaması ve engellemesi gerektiğini savundu. ("Peki onunla *ne* yapacaksın?" diye sordum. "Akşam yemeği için pişirelim mi?") + +UI tasarımcılarının kuralından alıntı yaptı: KULLANICININ ASLA İSTİSNA RAPORU GÖRMESİNE İZİN VERMEYİN, sanki bu meseleyi çözmüş gibi, ne büyük harflerle ve her şeyle. Fotoğrafları daha zayıf blogları süsleyen mavi ekranlı ATM'lerden birindeki koddan sorumlu olup olmadığını ve kalıcı olarak travmatize olup olmadığını merak ediyorum. Her neyse, eğer onunla karşılaşırsan, başını salla ve gülümse ve kapıya doğru yan yan dönerken aldırma. + +[Verity Stob](http://programmer.97things.oreilly.com/wiki/index.php/Verity_Stob) Tarafından \ No newline at end of file From db9104371fd30cdf776b41f30b6d80481b638711 Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Thu, 13 Jan 2022 08:59:03 +0300 Subject: [PATCH 046/290] added thing_29 --- tr/SUMMARY.md | 2 +- tr/thing_29/README.md | 21 +++++++++++++++++++++ 2 files changed, 22 insertions(+), 1 deletion(-) create mode 100644 tr/thing_29/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index a606dc1b..5451a737 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -29,7 +29,7 @@ 1. [Hatayı Görmezden Gelmeyin!](thing_26/README.md) 1. [Sadece Dili Öğrenmeyin, Kültürünü Anlayın](thing_27/README.md) 1. [Programınızı Dik Konumda Çivilemeyin](thing_28/README.md) -1. [Don't Rely on "Magic Happens Here"](thing_29/README.md) +1. ["Burada Sihir Olur"a Güvenmeyin](thing_29/README.md) 1. [Don't Repeat Yourself](thing_30/README.md) 1. [Don't Touch that Code!](thing_31/README.md) 1. [Encapsulate Behavior, not Just State](thing_32/README.md) diff --git a/tr/thing_29/README.md b/tr/thing_29/README.md new file mode 100644 index 00000000..719d59da --- /dev/null +++ b/tr/thing_29/README.md @@ -0,0 +1,21 @@ +# "Burada Sihir Olur"a Güvenmeyin + +Herhangi bir faaliyete, sürece veya disipline yeterince uzaktan bakarsanız basit görünür. Geliştirme deneyimi olmayan yöneticiler, yazılımcıların yaptıklarının basit olduğunu düşünürler ve yönetim deneyimi olmayan yazılımcılar, yöneticilerin yaptıklarıyla aynı şeyi düşünür. + +Programlama, bazı insanların yaptığı bir şeydir. Ve zor kısım düşünmedir, deneyimsizler tarafından en az görülen ve en az takdir edilen kısımdır. Onlarca yıldır bu yetenekli düşünceye olan ihtiyacı ortadan kaldırmak için birçok girişimde bulunuldu. En eski ve en akılda kalıcı olanlardan biri, Grace Hopper'ın programlama dillerini daha az şifreli hale getirme çabasıdır, bazı hesapların tahminlerine göre uzman yazılımcılara olan ihtiyacı ortadan kaldıracaktır. Sonuç (COBOL), sonraki on yıllarda birçok uzman yazılımcının gelirine katkıda bulunmuştur. + +Yazılım geliştirmenin programlamayı kaldırarak basitleştirilebileceği konusundaki ısrarlı vizyon, neyin dahil olduğunu anlayan yazılımcı için açıkça naiftir. Ancak bu hataya yol açan zihinsel süreç insan doğasının bir parçasıdır ve yazılımcılar da herkes gibi bunu yapmaya meyillidir. + +Herhangi bir projede muhtemelen bireysel bir yazılımcının aktif olarak dahil olmadığı pek çok şey vardır: kullanıcılardan gereksinimleri ortaya çıkarmak, bütçelerin onaylanmasını sağlamak, yapı sunucusunu kurmak, uygulamayı QA ve üretim ortamlarına dağıtmak, işi eskisinden taşımak süreçler veya programlar, vb. + +Bir şeylere aktif olarak dahil olmadığınızda, bunların basit olduğunu ve "sihirle" gerçekleştiğini varsaymak için bilinçsiz bir eğilim vardır. Sihir gerçekleşmeye devam ederken, her şey yolunda. Ama genellikle "ne zaman" ve "eğer" olmadığı zamanlar, sihir durduğunda projenin başı belada. + +Projelerin haftalarca geliştirici zamanı kaybettiğini biliyorum çünkü kimse yüklenen bir DLL'nin "doğru" sürümüne nasıl güvendiklerini anlamadı. İşler aralıklı olarak başarısız olmaya başladığında, birileri DLL'nin "yanlış" bir sürümünün yüklendiğini fark etmeden önce ekip üyeleri başka her yere baktı. + +Başka bir departman sorunsuz çalışıyordu, projeler zamanında teslim edildi, gece geç saatlerde hata ayıklama oturumları yok, acil durum düzeltmeleri yok. Aslında o kadar sorunsuz ki, üst yönetim işlerin "kendi kendine yürüdüğüne" ve proje yöneticisi olmadan da yapabileceklerine karar verdi. Altı ay içinde departmandaki projeler tıpkı organizasyonun geri kalanına benziyordu geç, sorunlu ve sürekli olarak yamalanıyor. + +Projenizin çalışmasını sağlayan tüm sihri anlamak zorunda değilsiniz, ancak bazılarını anlamaktan ya da anlamadığınız kısımları anlayan birini takdir etmekten zarar gelmez. + +En önemlisi, sihir durduğunda yeniden başlatılabileceğinden emin olun. + +[AlanGriffiths](http://programmer.97things.oreilly.com/wiki/index.php/AlanGriffiths) Tarafından \ No newline at end of file From 352d80e53d1e80b9d10871dc2bee99bf1fc224d4 Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Fri, 14 Jan 2022 09:04:59 +0300 Subject: [PATCH 047/290] added thing_30 --- tr/SUMMARY.md | 2 +- tr/thing_30/README.md | 27 +++++++++++++++++++++++++++ 2 files changed, 28 insertions(+), 1 deletion(-) create mode 100644 tr/thing_30/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index 5451a737..9bafe70f 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -30,7 +30,7 @@ 1. [Sadece Dili Öğrenmeyin, Kültürünü Anlayın](thing_27/README.md) 1. [Programınızı Dik Konumda Çivilemeyin](thing_28/README.md) 1. ["Burada Sihir Olur"a Güvenmeyin](thing_29/README.md) -1. [Don't Repeat Yourself](thing_30/README.md) +1. [Kendinizi Tekrar Etmeyin (Don't Repeat Yourself - DRY)](thing_30/README.md) 1. [Don't Touch that Code!](thing_31/README.md) 1. [Encapsulate Behavior, not Just State](thing_32/README.md) 1. [Floating-point Numbers Aren't Real](thing_33/README.md) diff --git a/tr/thing_30/README.md b/tr/thing_30/README.md new file mode 100644 index 00000000..72ff77e3 --- /dev/null +++ b/tr/thing_30/README.md @@ -0,0 +1,27 @@ +# Kendinizi Tekrar Etmeyin (Don't Repeat Yourself - DRY) + +Programlamanın tüm ilkeleri arasında, Kendini Tekrar Etme (DRY) belki de en temellerinden biridir. İlke, Andy Hunt ve Dave Thomas tarafından *The Pragmatic Programmer*'da formüle edilmiştir ve diğer birçok iyi bilinen yazılım geliştirme en iyi uygulamalarının ve tasarım modellerinin temelini oluşturur. Tekrarlamayı tanımayı öğrenen ve uygun uygulama ve doğru soyutlama yoluyla bunu nasıl ortadan kaldıracağını anlayan geliştirici, uygulamayı sürekli olarak gereksiz tekrarlarla bulaştıran birinden çok daha temiz kod üretebilir. + +Tekrarlamak israftır +--- + +Bir uygulamaya giren her kod satırı korunmalıdır ve gelecekteki hataların potansiyel bir kaynağıdır. Tekrarlama, kod tabanını gereksiz yere şişirir, bu da hatalar için daha fazla fırsat sağlar ve sisteme kazara karmaşıklık ekler. Tekrarlamanın sisteme eklediği şişkinlik, sistemle çalışan geliştiricilerin tüm sistemi tam olarak anlamasını veya bir yerde yapılan değişikliklerin mantığı kopyalayan başka yerlerde yapılması gerekmediğinden emin olmasını da zorlaştırır. DRY, "her bilgi parçasının bir sistem içinde tek, açık ve yetkili bir temsile sahip olmasını" gerektirir. + +Süreçte tekrar, otomasyon gerektirir +--- + +Yazılım geliştirmedeki birçok süreç tekrarlanır ve kolayca otomatikleştirilir. DRY ilkesi, bu bağlamlarda ve uygulamanın kaynak kodunda geçerlidir. Manuel test yavaştır, hataya açıktır ve tekrarlanması zordur, bu nedenle mümkünse otomatik test paketleri kullanılmalıdır. Yazılımı entegre etmek, manuel olarak yapıldığında zaman alıcı ve hataya açık olabilir, bu nedenle bir oluşturma işlemi, ideal olarak her check-in ile mümkün olduğunca sık çalıştırılmalıdır. Otomatikleştirilebilen zahmetli manuel süreçler nerede olursa olsun, bunlar otomatikleştirilmeli ve standartlaştırılmalıdır. Amaç, görevi tamamlamanın tek bir yolu olduğundan ve mümkün olduğu kadar acısız olduğundan emin olmaktır. + +Mantıkta tekrar, soyutlamayı gerektirir. +--- + +Mantıkta tekrar birçok biçim alabilir. Kopyala-yapıştır *if-then* veya *switch-case* mantığı, tespit edilmesi ve düzeltilmesi en kolay olanlardan biridir. Birçok tasarım deseni, bir uygulama içinde mantıkta tekrarlamayı azaltmak veya ortadan kaldırmak gibi açık bir amaca sahiptir. Bir nesne, kullanılmadan önce tipik olarak birkaç şeyin olmasını gerektiriyorsa, bu bir Abstract Factory veya Factory Yöntemi ile gerçekleştirilebilir. Bir nesnenin davranışında birçok olası varyasyon varsa, bu davranışlar büyük *if-then* yapıları yerine Strategy kalıbı kullanılarak enjekte edilebilir. Aslında, tasarım kalıplarının formülasyonu, ortak sorunları çözmek ve bu çözümleri tartışmak için gereken çabanın tekrarını azaltma girişimidir. Ek olarak, veritabanı şeması gibi yapılara DRY uygulanarak normalizasyon sağlanır. + +Prensip meselesi +--- + +Diğer yazılım ilkeleri de DRY ile ilgilidir. Yalnızca kodun işlevsel davranışı için geçerli olan Bir Kez ve Yalnızca Bir Kez ilkesi, DRY'nin bir alt kümesi olarak düşünülebilir. "Yazılım varlıklarının genişletilmeye açık, ancak değiştirilmeye kapalı olması gerektiğini" belirten Açık/Kapalı(Open/Closed) İlkesi, pratikte yalnızca DRY'ye uyulduğunda çalışır. Benzer şekilde, iyi bilinen Tek Sorumluluk(Single Responsibility) İlkesi, bir sınıfın "değişmek için tek bir nedeni" olmasını gerektirir, DRY'ye dayanır. + +Yapı, mantık, süreç ve işlev açısından izlendiğinde, DRY ilkesi yazılım geliştiricilere temel rehberlik sağlar ve daha basit, daha sürdürülebilir, daha yüksek kaliteli uygulamaların oluşturulmasına yardımcı olur. Performansı veya diğer gereksinimleri karşılamak için tekrarlamanın gerekli olabileceği senaryolar olsa da (örneğin, bir veritabanında veri denormalizasyonu), yalnızca hayali bir sorundan ziyade gerçek bir sorunu doğrudan ele aldığı durumlarda kullanılmalıdır. + +[Steve Smith](http://programmer.97things.oreilly.com/wiki/index.php/Steve_Smith) Tarafından \ No newline at end of file From 9f3c514001e0474620823590ee3ff11aea7c2f5f Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Fri, 14 Jan 2022 18:54:57 +0300 Subject: [PATCH 048/290] added thing_31 --- tr/SUMMARY.md | 2 +- tr/thing_31/README.md | 22 ++++++++++++++++++++++ 2 files changed, 23 insertions(+), 1 deletion(-) create mode 100644 tr/thing_31/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index 9bafe70f..da2e14b0 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -31,7 +31,7 @@ 1. [Programınızı Dik Konumda Çivilemeyin](thing_28/README.md) 1. ["Burada Sihir Olur"a Güvenmeyin](thing_29/README.md) 1. [Kendinizi Tekrar Etmeyin (Don't Repeat Yourself - DRY)](thing_30/README.md) -1. [Don't Touch that Code!](thing_31/README.md) +1. [O Koda Dokunma!](thing_31/README.md) 1. [Encapsulate Behavior, not Just State](thing_32/README.md) 1. [Floating-point Numbers Aren't Real](thing_33/README.md) 1. [Fulfill Your Ambitions with Open Source](thing_34/README.md) diff --git a/tr/thing_31/README.md b/tr/thing_31/README.md new file mode 100644 index 00000000..0022d212 --- /dev/null +++ b/tr/thing_31/README.md @@ -0,0 +1,22 @@ +# O Koda Dokunma! + +Hepimizin başına bir noktada gelmiştir. Kodunuz, sistem testi için hazırlama sunucusuna alındı ve test yöneticisi bir sorunla karşılaştığını yazar. İlk tepkiniz "Çabuk, bunu düzeltmeme izin verin neyin yanlış olduğunu biliyorum." + +Daha geniş anlamda, yanlış olan şey, bir geliştirici olarak hazırlama sunucusuna erişiminizin olması gerektiğini düşünmenizdir. + +Çoğu web tabanlı geliştirme ortamında, mimari şu şekilde bölünebilir: + +- Geliştiricinin makinesinde yerel geliştirme ve birim testi +- Manuel veya otomatik entegrasyon testinin yapıldığı geliştirme sunucusu +- QA ekibinin ve kullanıcıların kabul testi yaptığı aşamalandırma sunucusu +- Üretim sunucusu + +Evet, kaynak kodu kontrolü ve biletleme gibi oraya serpiştirilmiş başka sunucular ve hizmetler var, ancak siz anladınız. Bu modeli kullanan bir geliştirici hatta kıdemli bir geliştirici bile geliştirme sunucusunun ötesine asla erişememelidir. Çoğu geliştirme, bir geliştiricinin yerel makinesinde, en sevdikleri IDE'ler, sanal makineler ve iyi şanslar için üzerine serpilmiş uygun miktarda kara büyü karışımı kullanılarak yapılır. + +Otomatik veya manuel olarak SCC'ye kontrol edildikten sonra, her şeyin birlikte çalıştığından emin olmak için test edilebileceği ve gerekirse ince ayar yapılabileceği geliştirme sunucusuna aktarılmalıdır. Ancak bu noktadan itibaren, geliştirici sürecin bir izleyicisidir. + +Hazırlama yöneticisi, kodu QA ekibi için hazırlama sunucusuna paketlemeli ve yuvarlamalıdır. Tıpkı geliştiricilerin geliştirme sunucusunun ötesinde herhangi bir şeye erişmesine gerek olmaması gerektiği gibi, QA ekibinin ve kullanıcıların geliştirme sunucusunda herhangi bir şeye dokunmasına gerek yoktur. Kabul testi için hazırsa, bir yayın kes ve yuvarla, kullanıcıdan geliştirme sunucusunda "Gerçekten hızlı bir şeye bak" deme. Unutmayın, projeyi kendiniz kodlamıyorsanız, diğer insanların orada kodu vardır ve kullanıcının görmesi için hazır olmayabilirler. Sürüm yöneticisi, her ikisine de erişimi olması gereken tek kişidir. + +Hiçbir koşulda, hiçbir zaman bir geliştiricinin bir üretim sunucusuna erişimi olmamalıdır. Bir sorun varsa, destek personeliniz sorunu çözmeli veya sizden düzeltmenizi istemelidir. SCC'de kontrol edildikten sonra oradan bir yama yayınlayacaklar. Parçası olduğum en büyük programlama felaketlerinden bazıları, birinin \**öksürük*\*ben\**öksürük\** bu son kuralı ihlal etmesiyle gerçekleşti. Bozulursa, onu tamir etmenin yeri üretim değildir. + +[Cal Evans](http://programmer.97things.oreilly.com/wiki/index.php/Cal_Evans) Tarafından \ No newline at end of file From daebec6253304329a2d298d09ff39a91142816a6 Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Tue, 18 Jan 2022 18:37:08 +0300 Subject: [PATCH 049/290] added thing_32 --- tr/SUMMARY.md | 2 +- tr/thing_32/README.md | 15 +++++++++++++++ 2 files changed, 16 insertions(+), 1 deletion(-) create mode 100644 tr/thing_32/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index da2e14b0..00ebdd96 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -32,7 +32,7 @@ 1. ["Burada Sihir Olur"a Güvenmeyin](thing_29/README.md) 1. [Kendinizi Tekrar Etmeyin (Don't Repeat Yourself - DRY)](thing_30/README.md) 1. [O Koda Dokunma!](thing_31/README.md) -1. [Encapsulate Behavior, not Just State](thing_32/README.md) +1. [Sadece Durumu Değil, Davranışı Kapsülleyin](thing_32/README.md) 1. [Floating-point Numbers Aren't Real](thing_33/README.md) 1. [Fulfill Your Ambitions with Open Source](thing_34/README.md) 1. [The Golden Rule of API Design](thing_35/README.md) diff --git a/tr/thing_32/README.md b/tr/thing_32/README.md new file mode 100644 index 00000000..9dc33718 --- /dev/null +++ b/tr/thing_32/README.md @@ -0,0 +1,15 @@ +# Sadece Durumu Değil, Davranışı Kapsülleyin + +Sistem teorisinde, büyük ve karmaşık sistem yapılarıyla uğraşırken, kapsama en yararlı yapılardan biridir. Yazılım endüstrisinde, kapsama veya kapsüllemenin değeri iyi anlaşılmıştır. Kapsama, alt rutinler ve işlevler, modüller ve paketler, sınıflar vb. gibi programlama dili yapıları tarafından desteklenir. + +Modüller ve paketler, kapsülleme için daha büyük ölçekli ihtiyaçları ele alırken, sınıflar, alt rutinler ve işlevler konunun daha incelikli yönlerini ele alır. Yıllar geçtikçe, sınıfların, geliştiricilerin doğru yapması en zor kapsülleme yapılarından biri gibi göründüğünü keşfettim. 3000 satırlık tek bir ana yönteme sahip bir sınıf veya ilkel nitelikleri için yalnızca *set* ve *get* yöntemlerine sahip bir sınıf bulmak nadir değildir. Bu örnekler, dahil olan geliştiricilerin, modelleme yapıları olarak nesnelerin gücünden yararlanmada başarısız olduklarından, nesne yönelimli düşünceyi tam olarak anlamadıklarını göstermektedir. POJO (Düz Eski Java Nesnesi) ve POCO (Düz Eski C# Nesnesi veya Düz Eski CLR Nesnesi) terimlerine aşina olan geliştiriciler için, bir modelleme paradigması olarak OO'nun temellerine geri dönme niyeti buydu, nesneler sade ve basittir, ama aptal değil. + +Bir nesne, davranışın gerçek durum tarafından tanımlandığı hem durumu hem de davranışı kapsar. Bir kapı nesnesi düşünün. Dört durumu vardır: kapalı, açık, kapanıyor, açılıyor. İki işlem sağlar: aç ve kapat. Duruma bağlı olarak, açma ve kapama işlemleri farklı davranacaktır. Bir nesnenin bu doğal özelliği, tasarım sürecini kavramsal olarak basitleştirir. İki basit göreve indirgenir: nesneler arası etkileşim protokolleri de dahil olmak üzere farklı nesnelere sorumluluk tahsisi ve delegasyonu. + +Bunun pratikte nasıl çalıştığı en iyi bir örnekle gösterilmiştir. Diyelim ki üç sınıfımız var: Customer, Order ve Item. Customer nesnesi, kredi limiti ve kredi doğrulama kuralları için doğal yer tutucudur. Bir Order nesnesi, ilişkili Customer hakkında bilgi sahibidir ve addItem işlemi, "customer.validateCredit(item.price())" item ini çağırarak gerçek kredi kontrolünü devreder. Yöntemin son koşulu başarısız olursa, bir istisna atılabilir ve satın alma iptal edilebilir. + +Daha az deneyimli nesne yönelimli geliştiriciler, tüm iş kurallarını, genellikle "OrderManager" veya "OrderService" olarak adlandırılan bir nesneye sarmaya karar verebilir. Bu tasarımlarda, `Order`, `Customer` ve `Item`, kayıt türlerinden biraz daha fazlası olarak ele alınır. Tüm mantık, sınıflardan ayrılır ve çok sayıda dahili *if-then-else* yapısıyla büyük, prosedürel bir yöntemle birbirine bağlanır. Bu yöntemler kolayca bozulur ve bakımı neredeyse imkansızdır. Sebep? Kapsülleme bozuldu. + +Sonuç olarak, kapsüllemeyi bozmayın ve onu korumak için programlama dilinizin gücünü kullanın. + +[Einar Landre](http://programmer.97things.oreilly.com/wiki/index.php/Einar_Landre) Tarafından \ No newline at end of file From ee7a83a19d3e225d3c18c8c2617feb826619a1d1 Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Wed, 19 Jan 2022 09:10:10 +0300 Subject: [PATCH 050/290] added thing_33 --- tr/SUMMARY.md | 2 +- tr/thing_33/README.md | 17 +++++++++++++++++ 2 files changed, 18 insertions(+), 1 deletion(-) create mode 100644 tr/thing_33/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index 00ebdd96..9b912aed 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -33,7 +33,7 @@ 1. [Kendinizi Tekrar Etmeyin (Don't Repeat Yourself - DRY)](thing_30/README.md) 1. [O Koda Dokunma!](thing_31/README.md) 1. [Sadece Durumu Değil, Davranışı Kapsülleyin](thing_32/README.md) -1. [Floating-point Numbers Aren't Real](thing_33/README.md) +1. [Kayan Noktalı Sayılar Gerçek Değil](thing_33/README.md) 1. [Fulfill Your Ambitions with Open Source](thing_34/README.md) 1. [The Golden Rule of API Design](thing_35/README.md) 1. [The Guru Myth](thing_36/README.md) diff --git a/tr/thing_33/README.md b/tr/thing_33/README.md new file mode 100644 index 00000000..91185b49 --- /dev/null +++ b/tr/thing_33/README.md @@ -0,0 +1,17 @@ +# Kayan Noktalı Sayılar Gerçek Değil + +Kayan noktalı sayıları, Pascal ve Fortran gibi bazı programlama dillerinde *gerçek* olarak adlandırılsalar da, matematiksel anlamda "gerçek sayılar" değildir. Gerçek sayılar sonsuz kesinliğe sahiptir ve bu nedenle süreklidir ve kayıpsızdır; kayan noktalı sayıların kesinliği sınırlıdır, bu nedenle sonludurlar ve "kötü davranışlı" tam sayılara benzerler çünkü aralıkları boyunca eşit aralıklarla dağılmazlar. + +Örneklemek için, 32 bitlik bir kayan değişkene (x, diyelim) 2147483647 (en büyük işaretli 32 bit tam sayı) atayın ve yazdırın. 2147483648'i göreceksiniz. Şimdi `x - 64` yazdırın. Hala 2147483648. Şimdi `x - 65` yazdırın ve 2147483520 elde edeceksiniz! Niye ya? Çünkü bu aralıktaki bitişik kayan noktalar arasındaki boşluk 128'dir ve kayan nokta işlemleri en yakın kayan nokta sayısına yuvarlanır. + +IEEE kayan nokta sayıları, iki tabanlı bilimsel gösterime dayalı sabit kesinlikli sayılardır: 1.d1d2...dp-1 × 2e, burada *p* kesinliktir (float için 24, double için 53). Ardışık iki sayı arasındaki boşluk 21-p+e'tır, bu da ε|x| ile güvenli bir şekilde tahmin edilebilir; burada ε *makine epsilonudur* (21-p). + +Bir kayan noktalı sayının çevresindeki boşluğu bilmek, klasik sayısal hatalardan kaçınmanıza yardımcı olabilir. Örneğin, bir denklemin kökünü aramak gibi yinelemeli bir hesaplama yapıyorsanız, cevabın komşuluğunda sayı sisteminin verebileceğinden daha fazla kesinlik istemenin bir anlamı yoktur. İstediğiniz toleransın buradaki boşluktan daha küçük olmadığından emin olun; yoksa sonsuza kadar döngü yaparsın. + +Kayan noktalı sayıları, gerçek sayıların yaklaşık değerleri olduğundan, kaçınılmaz olarak küçük bir hata vardır. *Yuvarlama* adı verilen bu hata şaşırtıcı sonuçlara yol açabilir. Örneğin, neredeyse eşit sayıları çıkardığınızda, en anlamlı rakamlar birbirini yok eder, bu nedenle en az anlamlı olan rakam (yuvarlama hatasının bulunduğu yer) kayan nokta sonucunda en önemli konuma yükseltilir ve esasen herhangi birini kirletir. diğer ilgili hesaplamalar (*bulaşma* olarak bilinen bir olgu). Böyle bir *felaket iptalini* önlemek için algoritmalarınıza yakından bakmanız gerekir. Örneklemek için, *x2 - 100000x + 1 = 0* denklemini ikinci dereceden formülle çözmeyi düşünün. *-b + sqrt(b2 - 4)* ifadesindeki işlenenlerin büyüklükleri hemen hemen eşit olduğundan, bunun yerine *r1 = -b + sqrt(b2 - 4)* kökünü hesaplayabilir ve ardından *r2 = 1/r1* elde edebilirsiniz, çünkü herhangi bir ikinci dereceden ax2 + bx + c = 0 denklemi için kökler *r1r2 = c/a*'ı sağlar. + +Bulaşma daha da ince şekillerde ortaya çıkabilir. Bir kitaplığın *ex*'ü *1 + x + x2/2 + x3/3! + ...* formülüyle basitçe hesapladığını varsayalım. Bu, pozitif *x* için iyi çalışır, ancak *x* büyük bir negatif sayı olduğunda ne olduğunu düşünün. Çift güçlü terimler büyük pozitif sayılarla sonuçlanır ve tek güçlü büyüklüklerin çıkarılması sonucu bile etkilemez. Buradaki sorun, büyük, pozitif terimlerdeki yuvarlamanın, gerçek cevaptan çok daha önemli bir rakam konumunda olmasıdır. Cevap pozitif sonsuzluğa doğru sapıyor! Buradaki çözüm de basittir: negatif *x* için *ex = 1/e|x|*'u hesaplayın. + +Finansal uygulamalar için kayan noktalı sayıları kullanmamanız gerektiğini söylemeye gerek yok, Python ve C# gibi dillerdeki ondalık sınıflar bunun içindir. Kayan noktalı sayıları verimli bilimsel hesaplama için tasarlanmıştır. Ancak doğruluk olmadan verimlilik değersizdir, bu nedenle yuvarlama hatalarının kaynağını unutmayın ve buna göre kodlayın! + +[Chuck Allison](http://programmer.97things.oreilly.com/wiki/index.php/Chuck_Allison) Tarafından \ No newline at end of file From 2cc37005b55fa741b6849bd9e2e3f5efb042f7ff Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Wed, 19 Jan 2022 18:45:42 +0300 Subject: [PATCH 051/290] thing_34 --- tr/SUMMARY.md | 2 +- tr/thing_34/README.md | 13 +++++++++++++ 2 files changed, 14 insertions(+), 1 deletion(-) create mode 100644 tr/thing_34/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index 9b912aed..21679a9e 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -34,7 +34,7 @@ 1. [O Koda Dokunma!](thing_31/README.md) 1. [Sadece Durumu Değil, Davranışı Kapsülleyin](thing_32/README.md) 1. [Kayan Noktalı Sayılar Gerçek Değil](thing_33/README.md) -1. [Fulfill Your Ambitions with Open Source](thing_34/README.md) +1. [Açık Kaynak ile Hedeflerinizi Gerçekleştirin](thing_34/README.md) 1. [The Golden Rule of API Design](thing_35/README.md) 1. [The Guru Myth](thing_36/README.md) 1. [Hard Work Does not Pay Off](thing_37/README.md) diff --git a/tr/thing_34/README.md b/tr/thing_34/README.md new file mode 100644 index 00000000..f1ed4b57 --- /dev/null +++ b/tr/thing_34/README.md @@ -0,0 +1,13 @@ +# Açık Kaynak ile Hedeflerinizi Gerçekleştirin + +En hırslı yazılım geliştirme hayallerinizi gerçekleştiren iş yerinde yazılım geliştirmiyor olma ihtimaliniz oldukça yüksek. Belki de Google, Apple, Microsoft'ta veya bir sonraki büyük şeyi geliştirmek için kendi girişiminizde çalışmayı tercih ederken büyük bir sigorta şirketi için yazılım geliştiriyorsunuzdur. Önemsemediğiniz sistemler için yazılım geliştirdikçe istediğiniz yere asla varamayacaksınız. + +Neyse ki sorununuzun bir cevabı var: açık kaynak. Dışarıda, birçoğu oldukça aktif olan ve size isteyebileceğiniz her türlü yazılım geliştirme deneyimini sunan binlerce açık kaynak projesi var. İşletim sistemleri geliştirme fikrini seviyorsanız, bir düzine işletim sistemi projesinden birine yardım edin. Müzik yazılımı, animasyon yazılımı, kriptografi, robotik, PC oyunları, devasa çevrimiçi oyuncu oyunları, cep telefonları veya herhangi bir şey üzerinde çalışmak istiyorsanız, neredeyse kesinlikle bu ilgi alanına adanmış en az bir açık kaynaklı proje bulacaksınız. + +Tabii ki bedava öğle yemeği yok. Günlük işinizde muhtemelen açık kaynaklı bir video oyunu üzerinde çalışamayacağınız için boş zamanınızdan vazgeçmeye istekli olmalısınız, yine de işvereninize karşı bir sorumluluğunuz var. Ek olarak, çok az insan açık kaynak projelerine katkıda bulunarak para kazanıyor, bazıları yapıyor ama çoğu yapmıyor. Boş zamanınızın bir kısmından vazgeçmeye istekli olmalısınız (daha az video oyunları oynamak ve TV izlemek sizi öldürmez). Açık kaynaklı bir proje üzerinde ne kadar çok çalışırsanız, bir programcı olarak gerçek hedeflerinizi o kadar hızlı gerçekleştirirsiniz. Çalışan sözleşmenizi dikkate almak da önemlidir - bazı işverenler, kendi zamanınızda bile katkıda bulunabileceğiniz şeyleri kısıtlayabilir. Ayrıca, telif hakkı, patentler, ticari markalar ve ticari sırlarla ilgili fikri mülkiyet yasalarını ihlal etme konusunda dikkatli olmanız gerekir. + +Açık kaynak, motive olmuş programcılar için muazzam fırsatlar sunar. İlk olarak, bir başkasının sizi ilgilendiren bir çözümü nasıl uygulayacağını görürsünüz, diğer insanların kaynak kodunu okuyarak çok şey öğrenebilirsiniz. İkinci olarak, projeye kendi kodunuz ve fikirlerinizle katkıda bulunacaksınız, sahip olduğunuz her parlak fikir kabul edilmeyecek, ancak bazıları olabilir ve sadece çözümler üzerinde çalışarak ve koda katkıda bulunarak yeni bir şeyler öğreneceksiniz. Üçüncüsü, sahip olduğunuz yazılım türü için aynı tutkuya sahip harika insanlarla tanışacaksınız, bu açık kaynaklı arkadaşlıklar bir ömür boyu sürebilir. Dördüncüsü, yetkin bir katkıda bulunduğunuzu varsayarsak, sizi gerçekten ilgilendiren teknolojiye gerçek dünya deneyimini ekleyebileceksiniz. + +Açık kaynak kullanmaya başlamak oldukça kolaydır. İhtiyaç duyacağınız araçlarla ilgili (örneğin, kaynak kodu yönetimi, editörler, programlama dilleri, yapı sistemleri vb.) çok sayıda belge bulunmaktadır. Önce üzerinde çalışmak istediğiniz projeyi bulun ve projenin kullandığı araçlar hakkında bilgi edinin. Projelerle ilgili belgeler çoğu durumda hafif olacaktır, ancak bu belki daha az önemlidir çünkü öğrenmenin en iyi yolu kodu kendiniz araştırmaktır. Katılmak istiyorsanız, belgelere yardım etmeyi teklif edebilirsiniz. Veya test kodu yazmaya gönüllü olarak başlayabilirsiniz. Bu kulağa heyecan verici gelmese de, gerçek şu ki, diğer insanların yazılımı için test kodu yazarak, yazılımdaki hemen hemen tüm diğer etkinliklerden çok daha hızlı öğrenirsiniz. Test kodu yazın, gerçekten iyi test kodu. Hataları bulun, düzeltmeler önerin, arkadaşlar edinin, sevdiğiniz yazılımlar üzerinde çalışın ve yazılım geliştirme hedeflerinizi gerçekleştirin. + +[Richard Monson-Haefel](http://programmer.97things.oreilly.com/wiki/index.php/Richard_Monson-Haefel) Tarafından \ No newline at end of file From 793a151abbf5e5316664f3d7caf6dc99289d95fe Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Thu, 20 Jan 2022 18:01:04 +0300 Subject: [PATCH 052/290] added thing_35 --- tr/SUMMARY.md | 2 +- tr/thing_35/README.md | 13 +++++++++++++ 2 files changed, 14 insertions(+), 1 deletion(-) create mode 100644 tr/thing_35/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index 21679a9e..1be78a37 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -35,7 +35,7 @@ 1. [Sadece Durumu Değil, Davranışı Kapsülleyin](thing_32/README.md) 1. [Kayan Noktalı Sayılar Gerçek Değil](thing_33/README.md) 1. [Açık Kaynak ile Hedeflerinizi Gerçekleştirin](thing_34/README.md) -1. [The Golden Rule of API Design](thing_35/README.md) +1. [API Tasarımının Altın Kuralı](thing_35/README.md) 1. [The Guru Myth](thing_36/README.md) 1. [Hard Work Does not Pay Off](thing_37/README.md) 1. [How to Use a Bug Tracker](thing_38/README.md) diff --git a/tr/thing_35/README.md b/tr/thing_35/README.md new file mode 100644 index 00000000..3ca5a211 --- /dev/null +++ b/tr/thing_35/README.md @@ -0,0 +1,13 @@ +# API Tasarımının Altın Kuralı + +API tasarımı, özellikle büyük ölçekte zordur. Yüzlerce veya binlerce kullanıcıya sahip olacak bir API tasarlıyorsanız, gelecekte bunu nasıl değiştirebileceğinizi ve değişikliklerinizin istemci kodunu bozup bozamayacağını düşünmelisiniz. Bunun ötesinde, API'nizin kullanıcılarının sizi nasıl etkilediğini düşünmelisiniz. API sınıflarınızdan biri dahili olarak kendi yöntemlerinden birini kullanıyorsa, bir kullanıcının sınıfınızı alt sınıflara ayırıp onu geçersiz kılabileceğini ve bunun felaketle sonuçlanabileceğini hatırlamanız gerekir. Bazı kullanıcılarınız ona farklı bir anlam verdiği için bu yöntemi değiştiremezsiniz. Gelecekteki dahili uygulama seçenekleriniz, kullanıcılarınızın insafına kalmıştır. + +API geliştiricileri bu sorunu çeşitli şekillerde çözer, ancak en kolay yol API'yi kilitlemektir. Java'da çalışıyorsanız, sınıflarınızın ve yöntemlerinizin çoğunu final yapmak isteyebilirsiniz. C#'da sınıflarınızı ve yöntemlerinizi sealed hale getirebilirsiniz. Kullanmakta olduğunuz dil ne olursa olsun, API'nizi bir singleton aracılığıyla sunmaya veya statik fabrika yöntemlerini kullanmaya cazip gelebilirsiniz, böylece onu davranışı geçersiz kılabilecek ve kodunuzu daha sonra seçimlerinizi kısıtlayabilecek şekillerde kullanabilecek kişilerden koruyabilirsiniz. Bütün bunlar makul görünüyor, ama gerçekten öyle mi? + +Son on yılda, birim testinin uygulamanın son derece önemli bir parçası olduğunu yavaş yavaş fark ettik, ancak bu ders endüstriye tam olarak nüfuz etmedi. Kanıtlar etrafımızda. Üçüncü taraf API kullanan rastgele denenmemiş bir sınıf alın ve bunun için birim testleri yazmaya çalışın. Çoğu zaman başın belaya girecek. API'yi kullanan kodun ona yapıştırıcı gibi yapıştığını göreceksiniz. Kodunuzun bunlarla olan etkileşimlerini hissedebilmeniz veya test için dönüş değerleri sağlayabilmeniz için API sınıflarının kimliğine bürünmenin bir yolu yoktur. + +Zamanla, bu daha iyi olacak, ancak yalnızca API'leri tasarlarken testi gerçek bir kullanım durumu olarak görmeye başlarsak. Ne yazık ki, kodumuzu test etmekten biraz daha fazla ilgili. **API Tasarımının Altın Kuralı** tam da bu noktada devreye girer: *Geliştirdiğiniz bir API için testler yazmak yeterli değildir; API'nizi kullanan kod için birim testleri yazmanız gerekir. Bunu yaptığınızda, kullanıcılarınızın kodlarını bağımsız olarak test etmeye çalıştıklarında üstesinden gelmek zorunda kalacakları engelleri ilk elden öğrenirsiniz.* + +Geliştiricilerin API'nizi kullanan kodu test etmesini kolaylaştırmanın tek bir yolu yoktur. `static`, `final` ve `sealed` doğal olarak kötü yapılar değildir. Zaman zaman faydalı olabilirler. Ancak test konusunun farkında olmak önemlidir ve bunu yapmak için bunu kendiniz deneyimlemelisiniz. Bir kez sahip olduğunuzda, diğer herhangi bir tasarım zorluğunda olduğu gibi ona da yaklaşabilirsiniz. + +[Michael Feathers](http://programmer.97things.oreilly.com/wiki/index.php/Michael_Feathers) Tarafından \ No newline at end of file From 7915f384ae8b8051026dc17361b82a59f6a18415 Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Mon, 24 Jan 2022 19:10:31 +0300 Subject: [PATCH 053/290] added thing_36 --- tr/SUMMARY.md | 2 +- tr/thing_36/README.md | 17 +++++++++++++++++ 2 files changed, 18 insertions(+), 1 deletion(-) create mode 100644 tr/thing_36/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index 1be78a37..e1328283 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -36,7 +36,7 @@ 1. [Kayan Noktalı Sayılar Gerçek Değil](thing_33/README.md) 1. [Açık Kaynak ile Hedeflerinizi Gerçekleştirin](thing_34/README.md) 1. [API Tasarımının Altın Kuralı](thing_35/README.md) -1. [The Guru Myth](thing_36/README.md) +1. [Guru Efsanesi](thing_36/README.md) 1. [Hard Work Does not Pay Off](thing_37/README.md) 1. [How to Use a Bug Tracker](thing_38/README.md) 1. [Improve Code by Removing It](thing_39/README.md) diff --git a/tr/thing_36/README.md b/tr/thing_36/README.md new file mode 100644 index 00000000..775af7f4 --- /dev/null +++ b/tr/thing_36/README.md @@ -0,0 +1,17 @@ +# Guru Efsanesi + +Yazılımda yeterince uzun süre çalışmış olan herkes şuna benzer sorular duymuştur: + +> *XYZ istisnası alıyorum. Sorunun ne olduğunu biliyor musun?* + +Soruyu soran kişiler nadiren yığın izlerini, hata günlüklerini veya soruna yol açan herhangi bir bağlamı dahil etmekle uğraşmazlar. Sizin farklı bir düzlemde çalıştığınızı, çözümlerin size kanıta dayalı analizler olmadan göründüğünü düşünüyorlar. Senin bir guru olduğunu düşünüyorlar. + +Yazılıma aşina olmayanlardan böyle sorular bekliyoruz: Onlara sistemler neredeyse sihirli görünebilir. Beni endişelendiren, bunu yazılım camiasında görmek. Program tasarımında "Envanter yönetimi yapıyorum" gibi benzer sorular ortaya çıkıyor. İyimser kilitleme kullanmalı mıyım?" İronik olarak, soruyu soran insanlar genellikle soruyu yanıtlamak için soruyu alan kişiden daha donanımlıdır. Sorgulayıcılar muhtemelen bağlamı biliyor, gereksinimleri biliyor ve farklı stratejilerin avantaj ve dezavantajlarını okuyabiliyor. Yine de, bağlam olmadan akıllıca bir cevap vermenizi beklerler. Büyü beklerler. + +Yazılım endüstrisinin bu guru efsanesini ortadan kaldırmasının zamanı geldi. "Gurular" insandır. Mantık uygularlar ve geri kalanımız gibi sorunları sistematik olarak analiz ederler. Zihinsel kısayollardan ve sezgiden yararlanırlar. Tanıştığınız en iyi programcıyı düşünün: Bir noktada o kişi yazılım hakkında sizin şimdi olduğundan daha az şey biliyordu. Birisi bir guru gibi görünüyorsa, bunun nedeni düşünce süreçlerini öğrenmeye ve iyileştirmeye adanmış yılların olmasıdır. Bir "guru", sadece amansız bir meraka sahip akıllı bir kişidir. + +Tabii ki, doğal yetenekte büyük bir farklılık var. Dışarıdaki birçok bilgisayar korsanı benim olabileceğimden daha akıllı, daha bilgili ve daha üretken. Öyle olsa bile, guru efsanesini çürütmek olumlu bir etkiye sahiptir. Örneğin, benden daha zeki biriyle çalışırken, kişinin becerilerini verimli bir şekilde uygulayabilmesi için yeterli bağlam sağlamak için ayak işlerini yapacağımdan eminim. Guru mitini ortadan kaldırmak, aynı zamanda gelişmeye karşı algılanan bir engeli ortadan kaldırmak anlamına gelir. Sihirli bir engel yerine üzerinde ilerleyebileceğim bir süreklilik görüyorum. + +Son olarak, yazılımın en büyük engellerinden biri, guru efsanesini bilerek yayan akıllı insanlardır. Bu, egodan veya bir müşteri veya işveren tarafından algılanan kişinin değerini artırma stratejisi olarak yapılabilir. İronik olarak, bu tutum, akranlarının gelişimine katkıda bulunmadıkları için akıllı insanları daha az değerli hale getirebilir. Gurulara ihtiyacımız yok. Kendi alanlarında başka uzmanlar geliştirmeye istekli uzmanlara ihtiyacımız var. Hepimize yer var. + +[Ryan Brush](http://programmer.97things.oreilly.com/wiki/index.php/Ryan_Brush) Tarafından \ No newline at end of file From 3ebff6e325d15688e0306ef3a04b53bfcb36b41d Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Tue, 25 Jan 2022 19:07:19 +0300 Subject: [PATCH 054/290] added thing_37 --- tr/SUMMARY.md | 2 +- tr/thing_37/README.md | 13 +++++++++++++ 2 files changed, 14 insertions(+), 1 deletion(-) create mode 100644 tr/thing_37/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index e1328283..8b066d69 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -37,7 +37,7 @@ 1. [Açık Kaynak ile Hedeflerinizi Gerçekleştirin](thing_34/README.md) 1. [API Tasarımının Altın Kuralı](thing_35/README.md) 1. [Guru Efsanesi](thing_36/README.md) -1. [Hard Work Does not Pay Off](thing_37/README.md) +1. [Sıkı Çalışmanın Getirisi Yok](thing_37/README.md) 1. [How to Use a Bug Tracker](thing_38/README.md) 1. [Improve Code by Removing It](thing_39/README.md) 1. [Install Me](thing_40/README.md) diff --git a/tr/thing_37/README.md b/tr/thing_37/README.md new file mode 100644 index 00000000..412de26d --- /dev/null +++ b/tr/thing_37/README.md @@ -0,0 +1,13 @@ +# Sıkı Çalışmanın Getirisi Yok + +Bir yazılımcı olarak, çok çalışmak çoğu zaman işe yaramaz. Ofiste uzun saatler geçirerek kendinizi ve birkaç iş arkadaşınızı bir projeye çok şey kattığınıza inandırabilirsiniz. Ancak gerçek şu ki, daha az çalışarak daha fazlasını elde edebilirsiniz bazen çok daha fazlasını. Haftada 30 saatten fazla odaklanmış ve 'verimli' olmaya çalışıyorsanız, muhtemelen çok çalışıyorsunuzdur. Daha etkili olmak ve daha fazlasını yapmak için iş yükünü azaltmayı düşünmelisiniz. + +Bu ifade mantıksız ve hatta tartışmalı görünebilir, ancak programlama ve yazılım geliştirmenin bir bütün olarak sürekli bir öğrenme sürecini içerdiği gerçeğinin doğrudan bir sonucudur. Bir proje üzerinde çalışırken, problem alanını daha fazla anlayacaksınız ve umarım hedefe ulaşmanın daha etkili yollarını bulacaksınız. Boşa harcanan işlerden kaçınmak için, yaptıklarınızın etkilerini gözlemlemek, gördükleriniz üzerinde düşünmek ve buna göre davranışlarınızı değiştirmek için zaman tanımalısınız. + +Profesyonel programlama, genellikle, asfalt bir yolun sonunda hedefin görülebildiği birkaç kilometre için çok koşmak gibi değildir. Çoğu yazılım projesi daha çok uzun bir oryantiring maratonu gibidir. Karanlıkta. Kılavuz olarak sadece kabataslak bir harita ile. Olabildiğince hızlı koşarak tek bir yöne doğru yola çıkarsanız, bazılarını etkileyebilirsiniz, ancak muhtemelen başarılı olamazsınız. Sürdürülebilir bir tempo tutmanız ve nerede olduğunuz ve nereye gittiğinizle ilgili daha fazla bilgi edindiğinizde rotayı ayarlamanız gerekir. + +Ayrıca, genel olarak yazılım geliştirme ve özel olarak programlama teknikleri hakkında her zaman daha fazla bilgi edinmeniz gerekir. Muhtemelen kitap okumanız, konferanslara gitmeniz, diğer profesyonellerle iletişim kurmanız, yeni uygulama tekniklerini denemeniz ve işinizi basitleştiren güçlü araçlar hakkında bilgi edinmeniz gerekiyor. Profesyonel bir yazılımcı olarak, kendinizi uzmanlık alanınızda güncel tutmalısınız, tıpkı beyin cerrahlarının ve pilotların kendi uzmanlık alanlarında kendilerini güncel tutmaları beklendiği gibi. Akşamları, hafta sonlarını ve tatilleri kendinizi eğitmek için harcamanız gerekiyor, bu nedenle akşamları, hafta sonlarını ve tatillerinizi mevcut projenizde fazla mesai yaparak geçiremezsiniz. Beyin cerrahlarının haftada 60 saat ameliyat yapmasını mı yoksa pilotların haftada 60 saat uçmasını mı bekliyorsunuz? Tabii ki hayır, hazırlık ve eğitim mesleklerinin önemli bir parçasıdır. + +Projeye odaklanın, akıllı çözümler bularak elinizden geldiğince katkıda bulunun, becerilerinizi geliştirin, yaptığınız işe odaklanın ve davranışlarınızı uyarlayın. Çarkı çeviren kafesteki bir hamster gibi davranarak kendinizi ve mesleğimizi utandırmaktan kaçının. Profesyonel bir yazılımcı olarak haftada 60 saat odaklanmaya ve 'üretken' olmaya çalışmanın mantıklı bir şey olmadığını bilmelisiniz. Bir profesyonel gibi davranın: hazırlanın, etkileyin, gözlemleyin, yansıtın ve değiştirin. + +[Olve Maudal](http://programmer.97things.oreilly.com/wiki/index.php/Olve_Maudal) Tarafından \ No newline at end of file From b7ca16f8826f2bd223dac18dcdd10bc402ca9607 Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Thu, 27 Jan 2022 18:34:34 +0300 Subject: [PATCH 055/290] added thing_38 --- tr/SUMMARY.md | 2 +- tr/thing_38/README.md | 23 +++++++++++++++++++++++ 2 files changed, 24 insertions(+), 1 deletion(-) create mode 100644 tr/thing_38/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index 8b066d69..c0c8e449 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -38,7 +38,7 @@ 1. [API Tasarımının Altın Kuralı](thing_35/README.md) 1. [Guru Efsanesi](thing_36/README.md) 1. [Sıkı Çalışmanın Getirisi Yok](thing_37/README.md) -1. [How to Use a Bug Tracker](thing_38/README.md) +1. [Hata İzleyici Nasıl Kullanılır](thing_38/README.md) 1. [Improve Code by Removing It](thing_39/README.md) 1. [Install Me](thing_40/README.md) 1. [Inter-Process Communication Affects Application Response Time](thing_41/README.md) diff --git a/tr/thing_38/README.md b/tr/thing_38/README.md new file mode 100644 index 00000000..0a3db875 --- /dev/null +++ b/tr/thing_38/README.md @@ -0,0 +1,23 @@ +# Hata İzleyici Nasıl Kullanılır + +Bunlara *hata*, *kusur*, hatta *tasarım yan etkileri* deseniz de, onlardan kaçış yoktur. İyi bir hata raporunun nasıl gönderileceğini ve ayrıca bir tanesinde nelerin aranacağını bilmek, bir projenin güzel bir şekilde ilerlemesini sağlamak için temel becerilerdir. + +İyi bir hata raporunun üç şeye ihtiyacı vardır: + +- Hatanın mümkün olduğunca kesin olarak nasıl yeniden oluşturulacağı ve bunun ne sıklıkla hatanın ortaya çıkmasına neden olacağı. +- En azından sana göre ne olması gerekirdi. +- Gerçekte ne olduğu veya en azından kaydettiğiniz kadar bilgi. + +Bir hatada bildirilen bilgilerin miktarı ve kalitesi, hata hakkında olduğu kadar rapor eden hakkında da çok şey söyler. Kızgın, kısa hatalar ("Bu işlev berbat!"), geliştiricilere kötü zaman geçirdiğinizi söyler, ancak başka bir şey değil. Çoğaltmayı kolaylaştırmak için bol miktarda içeriğe sahip bir hata, bir sürümü durdursa bile herkesin saygısını kazanır. + +Hatalar, herkesin önünde tüm geçmişi olan bir sohbet gibidir. Başkalarını suçlamayın veya hatanın varlığını inkar etmeyin. Bunun yerine daha fazla bilgi isteyin veya neleri kaçırmış olabileceğinizi düşünün. + +Bir hatanın durumunu, örneğin *Açık*'ı *Kapalı* olarak değiştirmek, hata hakkında ne düşündüğünüzün genel bir ifadesidir. Hatanın neden kapatılması gerektiğini düşündüğünüzü açıklamak için zaman ayırmak, hayal kırıklığına uğramış yöneticilere ve müşterilere haklı çıkarmanın ardından sıkıcı saatler kazandıracaktır. Bir hatanın önceliğini değiştirmek benzer bir genel açıklamadır ve sizin için önemsiz olması, başka birinin ürünü kullanmasını engellemediği anlamına gelmez. + +Kendi amaçlarınız için bir böceğin alanlarını aşırı yüklemeyin. Bir hatanın konu alanına "VITAL:" eklemek, bazı raporların sonuçlarını sıralamanızı kolaylaştırabilir, ancak sonunda başkaları tarafından kopyalanacak ve kaçınılmaz olarak yanlış yazılacak veya başka bir raporda kullanılmak üzere kaldırılması gerekecektir. Bunun yerine yeni bir değer veya yeni bir alan kullanın ve diğer kişilerin kendilerini tekrar etmesine gerek kalmaması için alanın nasıl kullanılması gerektiğini belgeleyin. + +Herkesin, ekibin üzerinde çalışması gereken hataları nasıl bulacağını bildiğinden emin olun. Bu genellikle açık bir ada sahip genel bir sorgu kullanılarak yapılabilir. Herkesin aynı sorguyu kullandığından emin olun ve herkesin üzerinde çalıştığı şeyi değiştirdiğinizi ekibe bildirmeden bu sorguyu güncellemeyin. + +Son olarak, bir hatanın standart bir iş birimi olmadığını, bir kod satırının kesin bir çaba ölçümü olmadığını unutmayın. + +[Matt Doar](http://programmer.97things.oreilly.com/wiki/index.php/Matt_Doar) Tarafından \ No newline at end of file From 73c3826bbdcd0400920ba113ead91a4fef56026c Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Wed, 2 Feb 2022 18:23:57 +0300 Subject: [PATCH 056/290] added thing_39 --- tr/SUMMARY.md | 2 +- tr/thing_39/README.md | 24 ++++++++++++++++++++++++ 2 files changed, 25 insertions(+), 1 deletion(-) create mode 100644 tr/thing_39/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index c0c8e449..eea1048f 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -39,7 +39,7 @@ 1. [Guru Efsanesi](thing_36/README.md) 1. [Sıkı Çalışmanın Getirisi Yok](thing_37/README.md) 1. [Hata İzleyici Nasıl Kullanılır](thing_38/README.md) -1. [Improve Code by Removing It](thing_39/README.md) +1. [Kodu Kaldırarak İyileştirin](thing_39/README.md) 1. [Install Me](thing_40/README.md) 1. [Inter-Process Communication Affects Application Response Time](thing_41/README.md) 1. [Keep the Build Clean](thing_42/README.md) diff --git a/tr/thing_39/README.md b/tr/thing_39/README.md new file mode 100644 index 00000000..068842ea --- /dev/null +++ b/tr/thing_39/README.md @@ -0,0 +1,24 @@ +# Kodu Kaldırarak İyileştirin + +*Az* ama öz. Bu oldukça basmakalıp küçük bir özdeyiş, ama bazen gerçekten de doğru. + +Son birkaç hafta içinde kod tabanımızda yaptığım iyileştirmelerden biri, onun parçalarını kaldırmak. + +Yazılımı, YAGNI (yani, İhtiyacınız Olmayacak(You Aren't Gonna Need It)) dahil olmak üzere XP ilkelerini izleyerek yazdık. İnsan doğası ne ise, kaçınılmaz olarak birkaç yerde yetersiz kaldık. + +Ürünün belirli görevleri yerine getirmesinin çok uzun sürdüğünü gözlemledim, neredeyse anında olması gereken basit görevlerdi. Bunun nedeni, aşırı uygulanmış olmalarıydı; Gerekmeyen ekstra çan ve ıslıklarla süslenmişti, ama o zamanlar iyi bir fikir gibi görünüyordu. + +Bu nedenle, kodu basitleştirdim, ürün performansını iyileştirdim ve yalnızca rahatsız edici özellikleri kod tabanından kaldırarak global kod entropisi seviyesini düşürdüm. Yararlı bir şekilde, birim testlerim bana operasyon sırasında başka hiçbir şeyi kırmadığımı söylüyor. + +Basit ve tamamen tatmin edici bir deneyim. + +Öyleyse neden gereksiz kod ilk etapta orada kaldı? Neden bir yazılımcı fazladan kod yazma ihtiyacı hissetti ve bu, gözden geçirme veya eşleştirme sürecini nasıl geçti? Neredeyse kesinlikle şöyle bir şey: + +- Eğlenceli ekstra bir şeydi ve yazılımcı bunu yazmak istedi. *(İpucu: Kod yazın, sizi eğlendirdiği için değil değer kattığı için yazın.)* +- Birisi gelecekte gerekli olabileceğini düşündü, bu yüzden şimdi kodlamanın en iyisi olduğunu düşündü. *(İpucu: Bu YAGNI değil. Şu anda ihtiyacınız yoksa hemen yazmayın.)* +- O kadar büyük bir "ekstra" gibi görünmüyordu, bu yüzden gerçekten gerekli olup olmadığını görmek için müşteriye geri dönmek yerine uygulamak daha kolaydı. *(İpucu: Fazladan kod yazmak ve korumak her zaman daha uzun sürer. Ve müşteriye aslında oldukça ulaşılabilir. Fazladan küçük bir kod parçası zamanla kartopu yaparak bakım gerektiren büyük bir iş parçasına dönüşür.)* +- Yazılımcı, ek özelliği haklı çıkaran ne belgelenmiş ne de tartışılmış ek gereksinimler icat etti. Gereksinim aslında sahteydi. *(İpucu: Sistem gereksinimlerini yazılımcılar belirlemez; müşteri yapar.)* + +Şu an ne üzerinde çalışıyorsunuz? Hepsi gerekli mi? + +[Pete Goodliffe](http://programmer.97things.oreilly.com/wiki/index.php/Pete_Goodliffe) Tarafından From 888c986464312fde1094aa19c587924d7fc44696 Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Wed, 2 Feb 2022 18:35:06 +0300 Subject: [PATCH 057/290] added thing_40 --- tr/thing_40/README.md | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) create mode 100644 tr/thing_40/README.md diff --git a/tr/thing_40/README.md b/tr/thing_40/README.md new file mode 100644 index 00000000..9d6d6d65 --- /dev/null +++ b/tr/thing_40/README.md @@ -0,0 +1,24 @@ +# Beni Kur + +Programınızla zerre kadar ilgilenmiyorum. + +Etrafım sorunlarla çevrili ve kolum kadar uzun bir yapılacaklar listem var. Şu anda web sitenizde bulunmamın tek nedeni, her sorunumun yazılımınız tarafından ortadan kaldırılacağına dair olası olmayan bir söylenti duymamdır. Eğer şüpheciysem beni affedeceksiniz. + +Göz küresi izleme çalışmaları doğruysa, başlığı zaten okudum ve *şimdi indir* olarak işaretlenmiş mavi altı çizili metni tarıyorum. Bir kenara, eğer bu sayfaya Birleşik Krallık IP'sinden bir Linux tarayıcısıyla geldiysem, muhtemelen bir Avrupa aynasından gelen Linux sürümünü isterim, bu yüzden lütfen sormayın. Dosya iletişim kutusunun hemen açıldığını varsayarsak, dosyayı indirme klasörüme gönderiyorum ve okumaya devam ediyorum. + +Hepimiz sürekli olarak yaptığımız her şeyin maliyet-fayda analizini yaparız. Projeniz eşiğimin bir saniye bile altına düşerse, onu bırakıp başka bir şeye geçeceğim. Anında memnuniyet en iyisidir. + +İlk engel *kurulum*. Bunun büyük bir sorun olduğunu düşünmüyor musun? Şimdi indirme klasörünüze gidin ve etrafa bir göz atın. *tar* ve *zip* dosyalarıyla dolu değil mi? Bunların yüzde kaçını açtınız? Kaç tane kurdunuz? Benim gibiyseniz, yalnızca üçte biri sabit disk dolgusu görevi yapmaktan biraz daha fazlasını yapıyor. + +Kapı eşiğinde rahatlık isteyebilirim ama evime davetsiz girmeni istemiyorum. Kurulumu yazmadan önce, tam olarak nereye bir şeyler koyduğunuzu bilmek istiyorum. Bu benim bilgisayarım ve elimden geldiğince düzenli tutmayı seviyorum. Ayrıca, büyüm bozulduğu anda programınızı kaldırabilmek istiyorum. Bunun imkansız olduğundan şüphelenirsem, ilk etapta kurmayacağım. Makinem şu anda kararlı ve bu şekilde kalmasını istiyorum. + +Programınız GUI tabanlıysa, basit bir şey yapmak ve bir sonuç görmek istiyorum. Sihirbazlar yardımcı olmuyor çünkü anlamadığım şeyler yapıyorlar. Muhtemelen bir dosya okumak veya bir tane yazmak istiyorum. Projeler oluşturmak, dizinleri içe aktarmak veya size e-posta adresimi söylemek istemiyorum. Her şey çalışıyorsa, eğitime geçin. + +Yazılımınız bir kitaplık ise, o zaman bir *hızlı başlangıç kılavuzu* arayarak web sayfanızı okumaya devam ediyorum. Tam olarak web siteniz tarafından açıklanan çıktıyla beş satırlık bir beyinsizde "Merhaba dünya" eşdeğerini istiyorum. Doldurulması gereken büyük XML dosyaları veya şablonları yok, yalnızca tek bir komut dosyası. Unutmayın, rakibinizin çerçevesini de indirdim. Bilirsin, forumlarda her zaman seninkinden çok daha iyi olduğunu iddia eden kişi? Her şey çalışıyorsa, eğiticiye. + +Bir eğitim var değil mi? Benimle anlayacağım dilde konuşan biri mi? + +Ve öğretici benim sorunumdan bahsederse, neşeleneceğim. Şimdi yapabileceğim şeyleri okuyorum, ilginç, hatta eğlenceli olmaya başlıyor. Arkama yaslanıp çayımı yudumlayacağım. İngiltere'den geldiğimi söylemiş miydim? ve örneklerinizle oynayacağım ve yaratıcılığınızı kullanmayı öğreneceğim. Eğer sorunumu çözerse, sana bir teşekkür e-postası göndereceğim. Çöktüğünde size hata raporları ve özellikler için öneriler göndereceğim. Rakibinizin yazılımını hiç denememiş olmama rağmen, tüm arkadaşlarıma yazılımınızın nasıl en iyi olduğunu söyleyeceğim. Ve hepsi, ilk geçici adımlarıma bu kadar özen gösterdiğin için. +Senden nasıl şüphelendim? + +[Marcus Baker](http://programmer.97things.oreilly.com/wiki/index.php/Marcus_Baker) Tarafından \ No newline at end of file From a01d8ae896a3e469639c068e5a41287eac632d2b Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Tue, 8 Feb 2022 18:06:56 +0300 Subject: [PATCH 058/290] added thing_41 --- tr/SUMMARY.md | 2 +- tr/thing_41/README.html | 1079 +++++++++++++++++++++++++++++++++++++++ tr/thing_41/README.md | 13 + 3 files changed, 1093 insertions(+), 1 deletion(-) create mode 100644 tr/thing_41/README.html create mode 100644 tr/thing_41/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index eea1048f..1c648883 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -41,7 +41,7 @@ 1. [Hata İzleyici Nasıl Kullanılır](thing_38/README.md) 1. [Kodu Kaldırarak İyileştirin](thing_39/README.md) 1. [Install Me](thing_40/README.md) -1. [Inter-Process Communication Affects Application Response Time](thing_41/README.md) +1. [Süreçler Arası İletişim Uygulama Yanıt Süresini Etkiler](thing_41/README.md) 1. [Keep the Build Clean](thing_42/README.md) 1. [Know How to Use Command-line Tools](thing_43/README.md) 1. [Know Well More than Two Programming Languages](thing_44/README.md) diff --git a/tr/thing_41/README.html b/tr/thing_41/README.html new file mode 100644 index 00000000..b9375c16 --- /dev/null +++ b/tr/thing_41/README.html @@ -0,0 +1,1079 @@ +README

Süreçler Arası İletişim Uygulama Yanıt Süresini Etkiler

+

Yanıt süresi, yazılımın kullanılabilirliği için kritik öneme sahiptir. Bazı yazılım sistemlerinin yanıt vermesini beklemek kadar sinir bozucu çok az şey vardır, özellikle de yazılımla etkileşimimiz tekrarlanan uyaran ve tepki döngülerini içerdiğinde. Yazılımın zamanımızı boşa harcadığını ve verimliliğimizi etkilediğini hissediyoruz. Performans yönetimi literatürünün çoğu, bazı durumlarda fark yaratabilecek, ancak modern çok katmanlı kurumsal uygulamalarda performansa hükmetme olasılığı çok daha düşük olan veri yapıları ve algoritmalara hala odaklanmaktadır.

+

Bu tür uygulamalarda performans bir sorun olduğunda, benim deneyimim, veri yapılarını ve algoritmaları incelemenin iyileştirme aramak için doğru yer olmadığı yönündeydi. Tepki süresi, en çok, bir uyarana yanıt olarak yürütülen uzak süreçler arası iletişimlerin (IPC’ler) sayısına bağlıdır. Başka yerel darboğazlar olsa da, süreçler arası uzak iletişimlerin sayısı genellikle baskındır. Her bir uzak süreçler arası iletişim, genel yanıt süresine ihmal edilemeyecek bir gecikme süresine katkıda bulunur ve bu bireysel katkılar, özellikle sırayla gerçekleştiklerinde toplanır.

+

En iyi örnek, nesne-ilişkisel eşleme kullanan bir uygulamada dalgalanma yüklemesidir(ripple loading).

+

Inter-Process Communication Affects Application Response Time

+

A prime example is ripple loading in an application using object–relational mapping. +Ripple loading describes the sequential execution of many database calls to select the data needed for building a graph of objects (see Lazy Load in Martin Fowler’s Patterns of Enterprise Application Architecture). +When the database client is a middle-tier application server rendering a web page, these database calls are usually executed sequentially in a single thread. +Their individual latencies accumulate, contributing to the overall response time. +Even if each database call takes only 10ms, a page requiring 1000 calls (which is not uncommon) will exhibit at least a 10-second response time. Other examples include web-service invocation, HTTP requests from a web browser, distributed object invocation, request–reply messaging, and data-grid interaction over custom network protocols. +The more remote IPCs needed to respond to a stimulus, the greater the response time will be.

+

There are a few relatively obvious and well-known strategies for reducing the number of remote inter-process communications per stimulus. One strategy is to apply the principle of parsimony, optimizing the interface between processes so that exactly the right data for the purpose at hand is exchanged with the minimum amount of interaction. Another strategy is to parallelize the inter-process communications where possible, so that the overall response time becomes driven mainly by the longest-latency IPC. A third strategy is to cache the results of previous IPCs, so that future IPCs may be avoided by hitting local cache instead.

+

When you’re designing an application, be mindful of the number of inter-process communications in response to each stimulus. When analyzing applications that suffer from poor performance, I have often found IPC-to-stimulus ratios of thousands-to-one. Reducing this ratio, whether by caching or parallelizing or some other technique, will pay off much more than changing data structure choice or tweaking a sorting algorithm.

+

Randy Stafford Tarafından

\ No newline at end of file diff --git a/tr/thing_41/README.md b/tr/thing_41/README.md new file mode 100644 index 00000000..ceb34fb5 --- /dev/null +++ b/tr/thing_41/README.md @@ -0,0 +1,13 @@ +# Süreçler Arası İletişim Uygulama Yanıt Süresini Etkiler + +Yanıt süresi, yazılımın kullanılabilirliği için kritik öneme sahiptir. Bazı yazılım sistemlerinin yanıt vermesini beklemek kadar sinir bozucu çok az şey vardır, özellikle de yazılımla etkileşimimiz tekrarlanan uyaran ve tepki döngülerini içerdiğinde. Yazılımın zamanımızı boşa harcadığını ve verimliliğimizi etkilediğini hissediyoruz. Performans yönetimi literatürünün çoğu, bazı durumlarda fark yaratabilecek, ancak modern çok katmanlı kurumsal uygulamalarda performansa hükmetme olasılığı çok daha düşük olan veri yapıları ve algoritmalara hala odaklanmaktadır. + +Bu tür uygulamalarda performans bir sorun olduğunda, benim deneyimim, veri yapılarını ve algoritmaları incelemenin iyileştirme aramak için doğru yer olmadığı yönündeydi. Tepki süresi, en çok, bir uyarana yanıt olarak yürütülen uzak süreçler arası iletişimlerin (IPC'ler) sayısına bağlıdır. Başka yerel darboğazlar olsa da, süreçler arası uzak iletişimlerin sayısı genellikle baskındır. Her bir uzak süreçler arası iletişim, genel yanıt süresine ihmal edilemeyecek bir gecikme süresine katkıda bulunur ve bu bireysel katkılar, özellikle sırayla gerçekleştiklerinde toplanır. + +En iyi örnek, nesne-ilişkisel eşleme kullanan bir uygulamada *dalgalanma yüklemesidir(ripple loading)*. Dalgalı yükleme, nesnelerin grafiğini oluşturmak için gereken verileri seçmek için birçok veritabanı çağrısının sıralı yürütülmesini açıklar (Martin Fowler'ın *Patterns of Enterprise Application Architecture* içindeki [Lazy Load](http://martinfowler.com/eaaCatalog/lazyLoad.html) bölümüne bakın). Veritabanı istemcisi bir web sayfası oluşturan orta düzey bir uygulama sunucusu olduğunda, bu veritabanı çağrıları genellikle tek bir iş parçacığında sırayla yürütülür. Bireysel gecikme süreleri birikerek genel yanıt süresine katkıda bulunur. Her veritabanı araması yalnızca 10 ms sürse bile, 1000 arama gerektiren bir sayfa (ki bu nadir değildir) en az 10 saniyelik bir yanıt süresi sergileyecektir. Diğer örnekler arasında web hizmeti çağırma, bir web tarayıcısından HTTP istekleri, dağıtılmış nesne çağırma, istek-yanıt mesajlaşma ve özel ağ protokolleri üzerinden veri sistemi etkileşimi sayılabilir. Bir uyarana yanıt vermek için ne kadar uzak IPC'ye ihtiyaç duyulursa, yanıt süresi o kadar uzun olacaktır. + +Uyaran başına uzak süreçler arası iletişimlerin sayısını azaltmak için nispeten açık ve iyi bilinen birkaç strateji vardır. Bir strateji, eldeki amaç için tam olarak doğru verilerin minimum miktarda etkileşimle değiş tokuş edilmesi için süreçler arasındaki arayüzü optimize ederek tutumluluk ilkesini uygulamaktır. Diğer bir strateji, mümkün olduğunda süreçler arası iletişimi paralel hale getirmektir, böylece genel yanıt süresi esas olarak en uzun gecikmeli IPC tarafından yönlendirilir. Üçüncü bir strateji, önceki IPC'lerin sonuçlarını önbelleğe almaktır, böylece bunun yerine yerel önbelleğe basarak gelecekteki IPC'lerden kaçınılabilir. + +Bir uygulama tasarlarken, her bir uyarana yanıt olarak süreçler arası iletişimlerin sayısına dikkat edin. Düşük performanstan muzdarip uygulamaları analiz ederken, genellikle IPC-uyarıcı oranlarının binlere bir olduğunu gördüm. İster önbelleğe alma, ister paralelleştirme veya başka bir teknikle bu oranı azaltmak, veri yapısı seçimini değiştirmekten veya bir sıralama algoritmasında ince ayar yapmaktan çok daha fazlasını kazandıracaktır. + +[Randy Stafford](http://programmer.97things.oreilly.com/wiki/index.php/Randy_Stafford) Tarafından \ No newline at end of file From f4a9429cb94cabd53535507f781b7bfa8ea9f8ff Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Tue, 8 Feb 2022 18:19:01 +0300 Subject: [PATCH 059/290] added thing_42 --- tr/SUMMARY.md | 2 +- tr/thing_42/README.html | 1074 +++++++++++++++++++++++++++++++++++++++ tr/thing_42/README.md | 15 + 3 files changed, 1090 insertions(+), 1 deletion(-) create mode 100644 tr/thing_42/README.html create mode 100644 tr/thing_42/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index 1c648883..a31782f7 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -42,7 +42,7 @@ 1. [Kodu Kaldırarak İyileştirin](thing_39/README.md) 1. [Install Me](thing_40/README.md) 1. [Süreçler Arası İletişim Uygulama Yanıt Süresini Etkiler](thing_41/README.md) -1. [Keep the Build Clean](thing_42/README.md) +1. [Yapıyı Temiz Tutun](thing_42/README.md) 1. [Know How to Use Command-line Tools](thing_43/README.md) 1. [Know Well More than Two Programming Languages](thing_44/README.md) 1. [Know Your IDE](thing_45/README.md) diff --git a/tr/thing_42/README.html b/tr/thing_42/README.html new file mode 100644 index 00000000..a356a426 --- /dev/null +++ b/tr/thing_42/README.html @@ -0,0 +1,1074 @@ +README

Yapıyı Temiz Tutun

+

Hiç kötü kodlama üzerine bir makalenin uzunluğu hakkında bir derleyici uyarısı listesine bakıp ve kendi kendinize düşündünüz mü: “Biliyorsunuz, bu konuda gerçekten bir şeyler yapmalıyım… ama şu anda zamanım yok?” Öte yandan, bir derlemede yeni ortaya çıkan ve onu düzelten yalnız bir uyarıya hiç baktınız mı?

+

Sıfırdan yeni bir projeye başladığımda hiçbir uyarı, dağınıklık, sorun yok. Ancak kod tabanı büyüdükçe, dikkat etmezsem, dağınıklık, boşluk, uyarılar ve sorunlar birikmeye başlayabilir. Çok fazla gürültü olduğunda, umursamadığım yüzlerce uyarı arasında gerçekten okumak istediğim uyarıyı bulmak çok daha zor.

+

Uyarıları tekrar kullanışlı hale getirmek için yapıdan gelen uyarılar için sıfır tolerans politikası kullanmaya çalışıyorum. Uyarı önemli olmasa bile, onunla ilgilenirim. Kritik değilse, ancak yine de alakalıysa, düzeltirim. Derleyici potansiyel bir boş gösterici istisnası hakkında uyarırsa, nedeni düzeltirim, sorunun üretimde asla ortaya çıkmayacağını “bilsem” bile. Gömülü belgeler (Javadoc veya benzeri), kaldırılmış veya yeniden adlandırılmış parametrelere atıfta bulunuyorsa, belgeleri temizlerim.

+

Gerçekten umurumda olmayan bir şeyse ve bu gerçekten önemli değilse, ekibe uyarı politikamızı değiştirip değiştiremeyeceğimizi soruyorum. Örneğin, birçok durumda bir yöntemin parametrelerini ve dönüş değerini belgelemenin herhangi bir değer eklemediğini görüyorum, bu nedenle eksiklerse bir uyarı olmamalıdır. Veya, programlama dilinin yeni bir sürümüne yükseltmek, daha önce uygun olan kodun şimdi uyarı vermesine neden olabilir. Örneğin, Java 5 generic leri tanıttığında, generic tür parametresini belirtmeyen tüm eski kodlar bir uyarı verirdi. Bu, hakkında rahatsız edilmek istemediğim bir tür uyarı (en azından henüz değil).

+

Keep the Build Clean

+

By making sure that the build is always clean, I will not have to decide that a warning is irrelevant every time I encounter it. Ignoring things is mental work, and I need to get rid of all the unnecessary mental work I can. Having a clean build also makes it easier for someone else to take over my work. If I leave the warnings, someone else will have to wade through what is relevant and what is not. Or more likely, just ignore all the warnings, including the significant ones.

+

Warnings from your build are useful. You just need to get rid of the noise to start noticing them. Don’t wait for a big clean-up. When something appears that you don’t want to see, deal with it right away. Either fix the source of the warning, suppress this warning or fix the warning policies of your tool. Keeping the build clean is not just about keeping it free of compilation errors or test failures: Warnings are also an important and critical part of code hygiene.

+

Johannes Brodwall Tarafından

\ No newline at end of file diff --git a/tr/thing_42/README.md b/tr/thing_42/README.md new file mode 100644 index 00000000..b161cee3 --- /dev/null +++ b/tr/thing_42/README.md @@ -0,0 +1,15 @@ +# Yapıyı Temiz Tutun + +Hiç kötü kodlama üzerine bir makalenin uzunluğu hakkında bir derleyici uyarısı listesine bakıp ve kendi kendinize düşündünüz mü: "Biliyorsunuz, bu konuda gerçekten bir şeyler yapmalıyım... ama şu anda zamanım yok?" Öte yandan, bir derlemede yeni ortaya çıkan ve onu düzelten yalnız bir uyarıya hiç baktınız mı? + +Sıfırdan yeni bir projeye başladığımda hiçbir uyarı, dağınıklık, sorun yok. Ancak kod tabanı büyüdükçe, dikkat etmezsem, dağınıklık, boşluk, uyarılar ve sorunlar birikmeye başlayabilir. Çok fazla gürültü olduğunda, umursamadığım yüzlerce uyarı arasında gerçekten okumak istediğim uyarıyı bulmak çok daha zor. + +Uyarıları tekrar kullanışlı hale getirmek için yapıdan gelen uyarılar için sıfır tolerans politikası kullanmaya çalışıyorum. Uyarı önemli olmasa bile, onunla ilgilenirim. Kritik değilse, ancak yine de alakalıysa, düzeltirim. Derleyici potansiyel bir boş gösterici istisnası hakkında uyarırsa, nedeni düzeltirim, sorunun üretimde asla ortaya çıkmayacağını "bilsem" bile. Gömülü belgeler (Javadoc veya benzeri), kaldırılmış veya yeniden adlandırılmış parametrelere atıfta bulunuyorsa, belgeleri temizlerim. + +Gerçekten umurumda olmayan bir şeyse ve bu gerçekten önemli değilse, ekibe uyarı politikamızı değiştirip değiştiremeyeceğimizi soruyorum. Örneğin, birçok durumda bir yöntemin parametrelerini ve dönüş değerini belgelemenin herhangi bir değer eklemediğini görüyorum, bu nedenle eksiklerse bir uyarı olmamalıdır. Veya, programlama dilinin yeni bir sürümüne yükseltmek, daha önce uygun olan kodun şimdi uyarı vermesine neden olabilir. Örneğin, Java 5 generic leri tanıttığında, generic tür parametresini belirtmeyen tüm eski kodlar bir uyarı verirdi. Bu, hakkında rahatsız edilmek istemediğim bir tür uyarı (en azından henüz değil). Gerçeğe uymayan bir dizi uyarıya sahip olmak kimseye fayda sağlamaz. + +Yapının her zaman temiz olduğundan emin olarak, her karşılaştığımda bir uyarının alakasız olduğuna karar vermek zorunda kalmayacağım. Bir şeyleri görmezden gelmek zihinsel iş ve yapabileceğim tüm gereksiz zihinsel çalışmalardan kurtulmam gerekiyor. Temiz bir yapıya sahip olmak, bir başkasının işimi devralmasını da kolaylaştırıyor. Uyarıları bırakırsam, bir başkasının neyin alakalı olup neyin olmadığını gözden geçirmesi gerekecek. Veya daha büyük olasılıkla, önemli olanlar da dahil olmak üzere tüm uyarıları görmezden gelin. + +Yapınızdan gelen uyarılar faydalıdır. Onları fark etmeye başlamak için sadece gürültüden kurtulmanız gerekir. Büyük bir temizlik için beklemeyin. Görmek istemediğiniz bir şey göründüğünde, hemen onunla ilgilenin. Ya uyarının kaynağını düzeltin, bu uyarıyı bastırın ya da aracınızın uyarı ilkelerini düzeltin. Derlemeyi temiz tutmak yalnızca derleme hatalarından veya test hatalarından uzak tutmakla ilgili değildir: Uyarılar da kod hijyeninin önemli ve kritik bir parçasıdır. + +[Johannes Brodwall](http://programmer.97things.oreilly.com/wiki/index.php/Johannes_Brodwall) Tarafından \ No newline at end of file From 91fd5849101964e40adf8acee26db1f59867f49f Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Tue, 8 Feb 2022 18:24:57 +0300 Subject: [PATCH 060/290] added thing_43 --- tr/SUMMARY.md | 2 +- tr/thing_43/README.md | 13 +++++++++++++ 2 files changed, 14 insertions(+), 1 deletion(-) create mode 100644 tr/thing_43/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index a31782f7..19f38b6b 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -43,7 +43,7 @@ 1. [Install Me](thing_40/README.md) 1. [Süreçler Arası İletişim Uygulama Yanıt Süresini Etkiler](thing_41/README.md) 1. [Yapıyı Temiz Tutun](thing_42/README.md) -1. [Know How to Use Command-line Tools](thing_43/README.md) +1. [Komut Satırı Araçlarını Nasıl Kullanacağınızı Bilin](thing_43/README.md) 1. [Know Well More than Two Programming Languages](thing_44/README.md) 1. [Know Your IDE](thing_45/README.md) 1. [Know Your Limits](thing_46/README.md) diff --git a/tr/thing_43/README.md b/tr/thing_43/README.md new file mode 100644 index 00000000..ce6ee220 --- /dev/null +++ b/tr/thing_43/README.md @@ -0,0 +1,13 @@ +# Komut Satırı Araçlarını Nasıl Kullanacağınızı Bilin + +Günümüzde birçok yazılım geliştirme aracı, Entegre Geliştirme Ortamları (IDE'ler) biçiminde paketlenmiştir. Microsoft'un Visual Studio'su ve açık kaynaklı Eclipse, daha birçokları olmasına rağmen iki popüler örnektir. IDE'ler hakkında sevilecek çok şey var. Sadece kullanımları kolay olmakla kalmaz, aynı zamanda programcıyı yapım süreciyle ilgili birçok küçük ayrıntıyı düşünmekten kurtarır. + +Ancak kullanım kolaylığının dezavantajı vardır. Tipik olarak, bir aracın kullanımı kolay olduğunda, bunun nedeni aracın sizin adınıza kararlar vermesi ve sahne arkasında birçok şeyi otomatik olarak yapmasıdır. Bu nedenle, bir IDE şimdiye kadar kullandığınız tek programlama ortamıysa, araçlarınızın gerçekte ne yaptığını asla tam olarak anlayamayabilirsiniz. Bir düğmeye tıklarsınız, biraz sihir oluşur ve proje klasöründe yürütülebilir bir dosya belirir. + +Komut satırı oluşturma araçlarıyla çalışarak, projeniz oluşturulurken araçların ne yaptığı hakkında çok daha fazla şey öğreneceksiniz. Kendi make dosyalarınızı yazmak, yürütülebilir bir dosya oluşturmaya giden tüm adımları (derleme, birleştirme, bağlama, vb.) anlamanıza yardımcı olacaktır. Bu araçlar için birçok komut satırı seçeneğiyle denemeler yapmak da değerli bir eğitim deneyimidir. Komut satırı oluşturma araçlarını kullanmaya başlamak için GCC gibi açık kaynaklı komut satırı araçlarını kullanabilir veya tescilli IDE'nizle sağlananları kullanabilirsiniz. Sonuçta, iyi tasarlanmış bir IDE, bir dizi komut satırı aracının yalnızca grafiksel bir ön yüzüdür. + +Oluşturma sürecini anlamanızı geliştirmenin yanı sıra, komut satırı araçlarıyla bir IDE'den daha kolay veya daha verimli bir şekilde gerçekleştirilebilecek bazı görevler vardır. Örneğin, *grep* ve *sed* yardımcı programları tarafından sağlanan arama ve değiştirme yetenekleri, genellikle IDE'lerde bulunanlardan daha güçlüdür. Komut satırı araçları, programlanmış günlük derlemeler oluşturma, bir projenin birden çok sürümünü oluşturma ve test takımlarını çalıştırma gibi görevlerin otomasyonuna olanak tanıyan komut dosyası oluşturmayı doğal olarak destekler. Bir IDE'de, inşa seçenekleri genellikle GUI iletişim kutuları kullanılarak belirlendiğinden ve oluşturma işlemi bir fare tıklamasıyla başlatıldığından, bu tür bir otomasyonun yapılması (imkansız değilse) daha zor olabilir. IDE'nin dışına hiç çıkmadıysanız, bu tür otomatik görevlerin mümkün olduğunu bile fark etmeyebilirsiniz. + +Fakat bekle. IDE, geliştirmeyi kolaylaştırmak ve programcının üretkenliğini artırmak için mevcut değil mi? İyi evet. Burada sunulan öneri, IDE'leri kullanmayı bırakmanız gerektiği değildir. Öneri, "başlığın altına bakmanız" ve IDE'nizin sizin için ne yaptığını anlamanızdır. Bunu yapmanın en iyi yolu komut satırı araçlarını kullanmayı öğrenmektir. Ardından, IDE'nizi kullanmaya geri döndüğünüzde, sizin için ne yaptığını ve oluşturma sürecini nasıl kontrol edebileceğinizi çok daha iyi anlayacaksınız. Öte yandan, komut satırı araçlarının kullanımında ustalaştıktan ve sundukları güç ve esnekliği deneyimledikten sonra, IDE yerine komut satırını tercih ettiğinizi görebilirsiniz. + +[Carroll Robinson](http://programmer.97things.oreilly.com/wiki/index.php/Carroll_Robinson) Tarafından \ No newline at end of file From 6b3a5fdc3a758776bd282e69746e890604c5bf05 Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Tue, 8 Feb 2022 18:32:01 +0300 Subject: [PATCH 061/290] added thing_44 --- tr/SUMMARY.md | 2 +- tr/thing_44/README.md | 19 +++++++++++++++++++ 2 files changed, 20 insertions(+), 1 deletion(-) create mode 100644 tr/thing_44/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index 19f38b6b..f43a4e92 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -44,7 +44,7 @@ 1. [Süreçler Arası İletişim Uygulama Yanıt Süresini Etkiler](thing_41/README.md) 1. [Yapıyı Temiz Tutun](thing_42/README.md) 1. [Komut Satırı Araçlarını Nasıl Kullanacağınızı Bilin](thing_43/README.md) -1. [Know Well More than Two Programming Languages](thing_44/README.md) +1. [İkiden Fazla Programlama Dilini İyi Bilin](thing_44/README.md) 1. [Know Your IDE](thing_45/README.md) 1. [Know Your Limits](thing_46/README.md) 1. [Know Your Next Commit](thing_47/README.md) diff --git a/tr/thing_44/README.md b/tr/thing_44/README.md new file mode 100644 index 00000000..a39ba028 --- /dev/null +++ b/tr/thing_44/README.md @@ -0,0 +1,19 @@ +# İkiden Fazla Programlama Dilini İyi Bilin + +Programlama psikolojisi, programlama uzmanlığının, bir programcının rahat olduğu farklı programlama paradigmalarının sayısıyla doğrudan ilişkili olduğunu uzun zamandır biliyor. Bu sadece hakkında bilmek veya biraz bilmek değil, aynı zamanda gerçekten programlayabilir. + +Her programcı bir programlama dili ile başlar. Bu dil, programcının yazılım hakkında düşünme biçimi üzerinde baskın bir etkiye sahiptir. Programcı o dili kullanmak için kaç yıllık deneyime sahip olursa olsun, o dilde kalırsa sadece o dili bilecektir. *Tek dil* bir programcı, düşüncelerinde o dil tarafından kısıtlanır. + +İkinci bir dil öğrenen bir programcı, özellikle o dilin ilkinden farklı bir hesaplama modeline sahipse, zorlanacaktır. C, Pascal, Fortran, hepsi aynı temel hesaplama modeline sahiptir. Fortran'dan C'ye geçiş, pek çok olmasa da birkaç zorluk getirir. C veya Fortran'dan C++ veya Ada'ya geçiş, programların davranış biçiminde temel zorlukları beraberinde getirir. C++'dan Haskell'e geçiş önemli bir değişiklik ve dolayısıyla önemli bir zorluktur. C'den Prolog'a geçmek çok kesin bir zorluktur. + +Bir dizi hesaplama paradigmasını sıralayabiliriz: prosedürel, nesne yönelimli, işlevsel, mantık, veri akışı, vb. Bu paradigmalar arasında hareket etmek en büyük zorlukları yaratır. + +Bu zorluklar neden iyi? Algoritmaların uygulanması hakkında düşünme şeklimiz ve geçerli olan uygulama deyimleri ve kalıpları ile ilgilidir. Özellikle çapraz gübreleme, uzmanlığın merkezinde yer alır. Bir dilde geçerli olan problem çözümleri için deyimler başka bir dilde mümkün olmayabilir. Deyimleri bir dilden diğerine aktarmaya çalışmak bize her iki dili ve çözülmekte olan sorunu öğretir. + +Programlama dillerinin kullanımında çapraz gübrelemenin büyük etkileri vardır. Belki de en belirgin olanı, zorunlu dillerde uygulanan sistemlerde bildirimsel ifade biçimlerinin artan ve artan kullanımıdır. İşlevsel programlama konusunda bilgili herkes, C gibi bir dil kullanırken bile bildirimsel bir yaklaşımı kolaylıkla uygulayabilir. Bildirimsel yaklaşımları kullanmak genellikle daha kısa ve daha anlaşılır programlara yol açar. Örneğin, C++, neredeyse bildirimsel bir ifade kipini gerektiren genel programlamaya yönelik yürekten desteğiyle bunu kesinlikle kabul ediyor. + +Tüm bunların sonucu, her programcının en az iki farklı paradigmada ve ideal olarak en az yukarıda belirtilen beş paradigmada programlama konusunda iyi becerilere sahip olması gerektiğidir. Programcılar her zaman, tercihen yabancı bir paradigmadan yeni diller öğrenmekle ilgilenmelidir. Günlük iş her zaman aynı programlama dilini kullansa bile, bir kişi diğer paradigmalardan çapraz gübreleme yapabildiğinde bu dilin kullanımının artan karmaşıklığı hafife alınmamalıdır. İşverenler bunu dikkate almalı ve eğitim bütçelerinde çalışanların, kullanılan dillerin kullanımının karmaşıklığını artırmanın bir yolu olarak şu anda kullanılmayan dilleri öğrenmelerine izin vermelidir. + +Her ne kadar bir başlangıç olsa da, bir haftalık eğitim kursu yeni bir dil öğrenmek için yeterli değildir: Bir dil hakkında uygun bir çalışma bilgisi kazanmak için genellikle birkaç ay, yarı zamanlı bile olsa, kullanım yeterlidir. Önemli faktörler sadece sözdizimi ve hesaplama modeli değil, kullanım deyimleridir. + +[Russel Winder](http://programmer.97things.oreilly.com/wiki/index.php/Russel_Winder) Tarafından \ No newline at end of file From 942089924504f21b1ec5429c746c046428310838 Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Tue, 8 Feb 2022 18:39:05 +0300 Subject: [PATCH 062/290] added thing_45 --- tr/SUMMARY.md | 2 +- tr/thing_45/README.md | 23 +++++++++++++++++++++++ 2 files changed, 24 insertions(+), 1 deletion(-) create mode 100644 tr/thing_45/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index f43a4e92..1bf247e3 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -45,7 +45,7 @@ 1. [Yapıyı Temiz Tutun](thing_42/README.md) 1. [Komut Satırı Araçlarını Nasıl Kullanacağınızı Bilin](thing_43/README.md) 1. [İkiden Fazla Programlama Dilini İyi Bilin](thing_44/README.md) -1. [Know Your IDE](thing_45/README.md) +1. [IDE'nizi Bilin](thing_45/README.md) 1. [Know Your Limits](thing_46/README.md) 1. [Know Your Next Commit](thing_47/README.md) 1. [Large Interconnected Data Belongs to a Database](thing_48/README.md) diff --git a/tr/thing_45/README.md b/tr/thing_45/README.md new file mode 100644 index 00000000..214025d8 --- /dev/null +++ b/tr/thing_45/README.md @@ -0,0 +1,23 @@ +# IDE'nizi Bilin + +1980'lerde programlama ortamlarımız tipik olarak yüceltilmiş metin editörlerinden daha iyi değildi... eğer şanslıysak. Bugünlerde hafife aldığımız sözdizimi vurgulama, kesinlikle herkesin erişemeyeceği bir lükstü. Kodumuzu güzel bir şekilde biçimlendirmek için güzel yazıcılar, genellikle boşluklarımızı düzeltmek için çalıştırılması gereken harici araçlardı. Hata ayıklayıcılar aynı zamanda kodumuzda adım adım ilerleyen, ancak çok sayıda şifreli tuş vuruşuyla çalışan ayrı programlardı. + +1990'larda şirketler, programcıları daha iyi ve daha kullanışlı araçlarla donatmaktan elde edebilecekleri potansiyel geliri fark etmeye başladılar. Entegre Geliştirme Ortamı (IDE), önceki düzenleme özelliklerini bir derleyici, hata ayıklayıcı, güzel yazıcı ve diğer araçlarla birleştirdi. Bu süre zarfında menüler ve fare de popüler hale geldi, bu da geliştiricilerin editörlerini kullanmak için artık şifreli tuş kombinasyonlarını öğrenmeleri gerekmediği anlamına geliyordu. Menüden komutlarını kolayca seçebilirler. + +21. yüzyılda IDE'ler o kadar yaygın hale geldi ki, diğer alanlarda pazar payı kazanmak isteyen şirketler tarafından ücretsiz olarak dağıtılıyor. Modern IDE, inanılmaz bir dizi özellikle donatılmıştır. En sevdiğim, otomatik yeniden düzenleme, özellikle bir kod yığınını seçip bir yönteme dönüştürebildiğim *Çıkarma Yöntemi*. Yeniden düzenleme aracı, yönteme geçirilmesi gereken tüm parametreleri alır ve bu da kodu değiştirmeyi son derece kolaylaştırır. IDE'm, bu yöntemle değiştirilebilecek diğer kod parçalarını bile algılayacak ve onları da değiştirmek isteyip istemediğimi soracak. + +Modern IDE'lerin bir başka şaşırtıcı özelliği de bir şirket içinde stil kurallarını uygulama yeteneğidir. Örneğin, Java'da bazı programcılar tüm parametreleri nihai hale getirmeye başladılar (bence bu bir zaman kaybıdır). Ancak, böyle bir stil kuralına sahip oldukları için, bunu takip etmek için tek yapmam gereken, onu IDE'mde ayarlamak: Son olmayan herhangi bir parametre için bir uyarı alırdım. Stil kuralları, örneğin, referans nesnelere otomatik kutulanmış ilkel değerler üzerinde `==` kullanmak gibi, otomatik kutulanmış nesneleri referans eşitliği için karşılaştırmak gibi olası hataları bulmak için de kullanılabilir. + +Ne yazık ki modern IDE'ler, onları nasıl kullanacağımızı öğrenmek için çaba harcamamızı gerektirmiyor. Unix'te C'yi ilk programladığımda, dik öğrenme eğrisi nedeniyle vi editörünün nasıl çalıştığını öğrenmek için biraz zaman harcamak zorunda kaldım. Önceden harcanan bu süre, yıllar içinde cömertçe karşılığını verdi. Hatta bu yazının taslağını *vi* ile yazıyorum. Modern IDE'lerin çok kademeli bir öğrenme eğrisi vardır ve bu, aracın en temel kullanımının ötesine asla geçemeyeceğimiz etkisine sahip olabilir. + +Bir IDE öğrenmede ilk adımım klavye kısayollarını ezberlemektir. Kodumu yazarken parmaklarım klavyede olduğundan, bir değişkeni satır içi yapmak için *Ctrl+Shift+I* tuşlarına basmak akışı bozmaktan tasarruf sağlarken, faremle bir menüde gezinmeye geçmek akışı keser. Bu kesintiler gereksiz bağlam geçişlerine yol açıyor ve her şeyi tembel bir şekilde yapmaya çalışırsam beni çok daha az üretken yapıyor. Aynı kural klavye becerileri için de geçerlidir: Yazıya dokunmayı öğrenin, önceden harcadığınız zamana pişman olmayacaksınız. + +Son olarak, programcılar olarak, kodumuzu değiştirmemize yardımcı olabilecek, zamanı kanıtlanmış Unix akış araçlarına sahibiz. Örneğin, bir kod incelemesi sırasında, programcıların birçok sınıfı aynı adlandırdığını fark edersem, *find*, *sed*, *sort*, *uniq* ve *grep* araçlarını kullanarak bunları çok kolay bulabilirim, bunun gibi: + +``` +find . -name "*.java" | sed 's/.*\///' | sort | uniq -c | grep -v "^ *1 " | sort -r +``` + +Evimize gelen bir tesisatçının el fenerini kullanabilmesini bekliyoruz. IDE'mizle nasıl daha etkili olabileceğimizi incelemek için biraz zaman harcayalım. + +[Heinz Kabutz](http://programmer.97things.oreilly.com/wiki/index.php/Heinz_Kabutz) Tarafından \ No newline at end of file From 54c72663a79ff918230ea54e2a4ab9b5884a3187 Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Tue, 8 Feb 2022 18:47:17 +0300 Subject: [PATCH 063/290] added thing_46 --- tr/SUMMARY.md | 2 +- tr/thing_46/README.md | 49 +++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 50 insertions(+), 1 deletion(-) create mode 100644 tr/thing_46/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index 1bf247e3..e40cc0dc 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -46,7 +46,7 @@ 1. [Komut Satırı Araçlarını Nasıl Kullanacağınızı Bilin](thing_43/README.md) 1. [İkiden Fazla Programlama Dilini İyi Bilin](thing_44/README.md) 1. [IDE'nizi Bilin](thing_45/README.md) -1. [Know Your Limits](thing_46/README.md) +1. [Sınırlarınızı Bilin](thing_46/README.md) 1. [Know Your Next Commit](thing_47/README.md) 1. [Large Interconnected Data Belongs to a Database](thing_48/README.md) 1. [Learn Foreign Languages](thing_49/README.md) diff --git a/tr/thing_46/README.md b/tr/thing_46/README.md new file mode 100644 index 00000000..1cfaed52 --- /dev/null +++ b/tr/thing_46/README.md @@ -0,0 +1,49 @@ +# Sınırlarınızı Bilin + +> *"İnsan sınırlarını bilmeli." — Dirty Harry* + +Kaynaklarınız sınırlı. Bilginizi, becerilerinizi ve araçlarınızı güncel tutmak için gereken zaman ve para dahil, işinizi yapmak için yalnızca çok fazla zamanınız ve paranız var. Sadece çok sıkı, çok hızlı, çok akıllı ve çok uzun süre çalışabilirsin. Araçlarınız sadece çok güçlü. Hedef makineleriniz sadece çok güçlü. Bu yüzden kaynaklarınızın sınırlarına saygı göstermelisiniz. + +Bu sınırlara nasıl saygı duyulur? Kendinizi tanıyın, çalışanlarınızı tanıyın, bütçelerinizi bilin ve eşyalarınızı bilin. Özellikle bir yazılım mühendisi olarak, veri yapılarınızın ve algoritmalarınızın uzay ve zaman karmaşıklığını, sistemlerinizin mimarisini ve performans özelliklerini bilin. İşiniz, yazılım ve sistemlerin optimal bir evliliğini yaratmaktır. + +Uzay ve zaman karmaşıklığı, *O(f(n))* işlevi olarak verilir; bu, n için girdinin boyutuna eşit, asimptotik uzay veya n sonsuza kadar büyürken gereken zamandır. *f(n)* için önemli karmaşıklık sınıfları arasında *ln(n)*, *n*, *n ln(n)*, *ne* ve *en< bulunur /sup>*. Bu fonksiyonların grafiğinin açıkça gösterdiği gibi, *n* büyüdükçe *O(ln(n))*, *O(n)* ve *O(n ln(n))*'den çok daha küçüktür, ki bunlar hep böyledir *O(ne)* ve *O(en)*'dan çok daha küçüktür. Sean Parent'in belirttiği gibi, ulaşılabilir n için tüm karmaşıklık sınıfları sabite yakın, doğrusala yakın veya sonsuza yakındır. + +![](http://programmer.97things.oreilly.com/wiki/images/c/c0/Clearly.jpeg) + +| | access time | capacity | +|--------------|-----------------:| ----------:| +| register | < 1 ns | 64b | +| cache line | | 64B | +| L1 cache | 1 ns | 64 KB | +| L2 cache | 4 ns | 8 MB | +| RAM | 20 ns | 32 GB | +| disk | 10 ms | 10 TB | +| LAN | 20 ms | > 1 PB | +| internet | 100 ms | > 1 ZB | + +Karmaşıklık analizi, soyut bir makine açısından yapılır, ancak yazılım gerçek makinelerde çalışır. Modern bilgisayar sistemleri, dil çalışma zamanları, işletim sistemleri, CPU'lar, önbellek belleği, rastgele erişimli bellek, disk sürücüleri ve ağlar dahil olmak üzere fiziksel ve sanal makinelerin hiyerarşileri olarak düzenlenir. İlk tablo, tipik bir ağ bağlantılı sunucu için rasgele erişim süresi ve depolama kapasitesi üzerindeki sınırları gösterir. + +Kapasite ve hızın birkaç büyüklük derecesine göre değiştiğini unutmayın. Önbelleğe alma ve ileriye dönük, bu varyasyonu gizlemek için sistemlerimizin her düzeyinde yoğun olarak kullanılır, ancak bunlar yalnızca erişim öngörülebilir olduğunda çalışır. Önbellek kayıpları sık olduğunda sistem çöker. Örneğin, bir sabit sürücüdeki her baytı rastgele incelemek 32 yıl sürebilir. RAM'deki her baytı rastgele incelemek bile 11 dakika sürebilir. Rastgele erişim tahmin edilemez. Nedir? Bu, sisteme bağlıdır, ancak son kullanılan öğelere yeniden erişmek ve öğelere sırayla erişmek genellikle bir kazançtır. + +Algoritmalar ve veri yapıları, önbellekleri ne kadar etkili kullandıklarına göre değişir. Örneğin: +- Doğrusal arama, ileriye bakmayı iyi bir şekilde kullanır, ancak *O(n)* karşılaştırmaları gerektirir. +- Sıralanmış bir dizinin ikili araması yalnızca *O(log(n))* karşılaştırmalarını gerektirir. +- Bir van Emde Boas ağacının aranması *O(log(n))* ve önbellekten habersiz. + + +|Elements | Search time (ns)| | | +|:--------|-----------:|-----------:|--------:| +| | **linear** | **binary** | **vEB** | +| 8 | 50 | 90 | 40 | +| 64 | 180 | 150 | 70 | +| 512 | 1200 | 230 | 100 | +| 4096 | 17000 | 320 | 160 | + + +Nasıl seçilir? Son tahlilde, ölçerek. İkinci tablo, bu üç yöntemle 64 bit tamsayı dizilerini aramak için gereken süreyi gösterir. Bilgisayarımda: +- Doğrusal arama, küçük diziler için rekabetçidir, ancak daha büyük diziler için katlanarak kaybeder. +- Van Emde Boas, tahmin edilebilir erişim modeli sayesinde kesinlikle kazanıyor. + +> *"Paranı ödüyorsun ve seçimini yapıyorsun." — [Punch](http://www.nytimes.com/1988/02/28/magazine/on-language-you-pays-yer-money.html?pagewanted=all)* + +[Greg Colvin](http://programmer.97things.oreilly.com/wiki/index.php/Greg_Colvin) Tarafından From 0f928ab5393de04c0ef50fb72737ea223cd2c296 Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Wed, 9 Feb 2022 18:26:50 +0300 Subject: [PATCH 064/290] added thing_47 --- tr/SUMMARY.md | 2 +- tr/thing_47/README.md | 19 +++++++++++++++++++ 2 files changed, 20 insertions(+), 1 deletion(-) create mode 100644 tr/thing_47/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index e40cc0dc..163bb5f0 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -47,7 +47,7 @@ 1. [İkiden Fazla Programlama Dilini İyi Bilin](thing_44/README.md) 1. [IDE'nizi Bilin](thing_45/README.md) 1. [Sınırlarınızı Bilin](thing_46/README.md) -1. [Know Your Next Commit](thing_47/README.md) +1. [Bir Sonraki İşleminizi(Commit) Bilin](thing_47/README.md) 1. [Large Interconnected Data Belongs to a Database](thing_48/README.md) 1. [Learn Foreign Languages](thing_49/README.md) 1. [Learn to Estimate](thing_50/README.md) diff --git a/tr/thing_47/README.md b/tr/thing_47/README.md new file mode 100644 index 00000000..d8e58c18 --- /dev/null +++ b/tr/thing_47/README.md @@ -0,0 +1,19 @@ +# Bir Sonraki İşleminizi(Commit) Bilin + +Üç programcının omuzlarına dokundum ve ne yaptıklarını sordum. "Bu yöntemleri yeniden gözden geçiriyorum," diye yanıtladı ilki. İkincisi, "Bu web işlemine bazı parametreler ekliyorum" diye yanıtladı. Üçüncüsü, "Bu kullanıcı hikayesi üzerinde çalışıyorum" yanıtını verdi. + +İlk ikisi işlerinin ayrıntılarına dalmış gibi görünebilirken, yalnızca üçüncüsü büyük resmi görebiliyordu ve ikincisi daha iyi odaklanmıştı. Ancak, ne zaman ve ne işlemi yapacaklarını sorduğumda, resim çarpıcı bir şekilde değişti. İlk ikisi, hangi dosyaların dahil olacağı konusunda oldukça netti ve bir saat içinde bitecekti. Üçüncü programcı, "Ah, sanırım birkaç gün içinde hazır olacağım. Muhtemelen birkaç sınıf ekleyeceğim ve bu hizmetleri bir şekilde değiştirebilirim." + +İlk ikisi, genel hedefe yönelik bir vizyondan yoksun değildi. Verimli bir yöne gittiğini düşündükleri görevleri seçmişlerdi ve birkaç saat içinde bitirilebiliyorlardı. Bu görevleri bitirdikten sonra, üzerinde çalışmak için yeni bir özellik veya yeniden düzenleme seçeceklerdi. Böylece yazılan tüm kodlar net bir amaç ve sınırlı, ulaşılabilir bir hedef göz önünde bulundurularak yapıldı. + +Üçüncü programcı sorunu ayrıştırmayı başaramamıştı ve aynı anda tüm yönler üzerinde çalışıyordu. Temelde spekülatif programlama yaparak, işlem yapabileceği bir noktaya gelmeyi umarak, bunun ne gerektirdiği hakkında hiçbir fikri yoktu. Büyük olasılıkla bu uzun oturumun başında yazılan kod, sonunda ortaya çıkan çözüm için yetersizdi. + +İlk iki programcı, görevleri iki saatten fazla sürseydi ne yapardı? Çok fazla üstlendiklerini fark ettikten sonra, büyük olasılıkla değişiklikleri bir kenara atacak, daha küçük görevler tanımlayacak ve baştan başlayacaklardı. Çalışmaya devam etmek, odaktan yoksun olurdu ve depoya spekülatif kodun girmesine yol açardı. Bunun yerine, değişiklikler çöpe atılır, ancak içgörüler korunur. + +Üçüncü programcı tahmin etmeye devam edebilir ve umutsuzca değişikliklerini taahhüt edilebilecek bir şeye dönüştürmeye çalışabilir. Sonuçta, yaptığınız kod değişikliklerini çöpe atamazsınız - bu boşa giden bir iş olur, değil mi? Ne yazık ki, kodu çöpe atmamak, depoya girmek için net bir amacı olmayan biraz garip koda yol açar. + +Bir noktada, işlem odaklı programcılar bile iki saat içinde tamamlanabileceğini düşündükleri yararlı bir şey bulamayabilir. Ardından, doğrudan spekülatif moda geçerler, kodla oynarlar ve elbette, ne zaman bir içgörü onları tekrar rayına oturtsa değişiklikleri bir kenara atarlardı. Bu görünüşte yapılandırılmamış bilgisayar korsanlığı oturumlarının bile amacı vardır: verimli bir adım oluşturacak bir görevi tanımlayabilmek için kod hakkında bilgi edinmek. + +Bir sonraki işleminizi bilin. Bitiremezseniz, değişikliklerinizi atın ve kazandığınız içgörülerle inandığınız yeni bir görev tanımlayın. Gerektiğinde spekülatif deneyler yapın, ancak fark etmeden spekülatif moda kaymanıza izin vermeyin. Deponuza tahminde bulunmayın. + +[Dan Bergh Johnsson](http://programmer.97things.oreilly.com/wiki/index.php/Dan_Bergh_Johnsson) Tarafından \ No newline at end of file From 222fbe2f11c0564b771c7a27262555003e0bac90 Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Wed, 9 Feb 2022 18:35:39 +0300 Subject: [PATCH 065/290] added thing_48 --- tr/SUMMARY.md | 2 +- tr/thing_48/README.md | 15 +++++++++++++++ 2 files changed, 16 insertions(+), 1 deletion(-) create mode 100644 tr/thing_48/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index 163bb5f0..0d7d005d 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -48,7 +48,7 @@ 1. [IDE'nizi Bilin](thing_45/README.md) 1. [Sınırlarınızı Bilin](thing_46/README.md) 1. [Bir Sonraki İşleminizi(Commit) Bilin](thing_47/README.md) -1. [Large Interconnected Data Belongs to a Database](thing_48/README.md) +1. [Büyük Birbirine Bağlı Veriler Bir Veritabanına Aittir](thing_48/README.md) 1. [Learn Foreign Languages](thing_49/README.md) 1. [Learn to Estimate](thing_50/README.md) 1. [Learn to Say "Hello, World"](thing_51/README.md) diff --git a/tr/thing_48/README.md b/tr/thing_48/README.md new file mode 100644 index 00000000..8a7ef9ac --- /dev/null +++ b/tr/thing_48/README.md @@ -0,0 +1,15 @@ +# Büyük Birbirine Bağlı Veriler Bir Veritabanına Aittir + +Uygulamanız büyük, kalıcı, birbirine bağlı bir veri öğeleri kümesini işleyecekse, onu ilişkisel bir veritabanında depolamaktan çekinmeyin. Geçmişte RDBMS'ler pahalı, kıt, karmaşık ve hantal hayvanlardı. Bu artık geçerli değil. Günümüzde RDBMS sistemlerini bulmak kolaydır - kullandığınız sistemde zaten bir veya iki tane kurulu olması muhtemeldir. MySQL ve PostgreSQL gibi bazı çok yetenekli RDBMS'ler açık kaynaklı yazılım olarak mevcuttur, bu nedenle satın alma maliyeti artık bir sorun değildir. Daha da iyisi, sözde gömülü veritabanı sistemleri, neredeyse hiçbir kurulum veya yönetim gerektirmeden doğrudan uygulamanıza kitaplıklar olarak bağlanabilir - iki dikkate değer açık kaynak, SQLite ve HSQLDB'dir. Bu sistemler son derece verimlidir. + +Uygulamanızın verileri sistemin RAM'inden daha büyükse, dizine alınmış bir RDBMS tablosu, sanal bellek sayfalarını bozacak olan kitaplığınızın harita toplama türünden çok daha hızlı işlem yapacaktır. Modern veritabanı teklifleri, ihtiyaçlarınızla kolayca büyüyebilir. Uygun bakımla, gerektiğinde gömülü bir veritabanını daha büyük bir veritabanı sistemine yükseltebilirsiniz. Daha sonra ücretsiz, açık kaynaklı bir tekliften daha iyi desteklenen veya daha güçlü bir tescilli sisteme geçebilirsiniz. + +SQL'e alıştıktan sonra, veritabanı merkezli uygulamalar yazmak bir zevktir. Veri tabanında düzgün bir şekilde normalize edilmiş verilerinizi depoladıktan sonra, okunabilir bir SQL sorgusu ile gerçekleri verimli bir şekilde çıkarmak kolaydır; herhangi bir karmaşık kod yazmaya gerek yoktur. Benzer şekilde, tek bir SQL komutu karmaşık veri değişiklikleri gerçekleştirebilir. Tek seferlik değişiklikler için, kalıcı verilerinizi düzenleme şeklinizde bir değişiklik olduğunu söyleyin, kod yazmanıza bile gerek yok: Veritabanının doğrudan SQL arayüzünü çalıştırmanız yeterli. Bu aynı arayüz aynı zamanda, normal bir programlama dilinin derleme-düzenleme döngüsünden kaçınarak sorgularla denemeler yapmanıza da olanak tanır. + +Kodunuzu bir RDBMS'ye dayandırmanın bir başka avantajı, veri öğeleriniz arasındaki ilişkilerin ele alınmasını içerir. Verilerinizi bir uç durumda güncellemeyi unutursanız, aldığınız işaretçilerin sarkan riskinden kaçınarak, verileriniz üzerindeki tutarlılık kısıtlamalarını bildirimsel bir şekilde tanımlayabilirsiniz. Örneğin, bir kullanıcı silinirse, o kullanıcı tarafından gönderilen mesajların da kaldırılması gerektiğini belirtebilirsiniz. + +Ayrıca, sadece bir dizin oluşturarak, istediğiniz zaman veritabanında depolanan varlıklar arasında verimli bağlantılar oluşturabilirsiniz. Sınıf alanlarının pahalı ve kapsamlı yeniden düzenlemelerini gerçekleştirmeye gerek yoktur. Ek olarak, bir veritabanı etrafında kodlama yapmak, birden çok uygulamanın verilerinize güvenli bir şekilde erişmesine olanak tanır. Bu, uygulamanızı eşzamanlı kullanım için yükseltmeyi ve ayrıca uygulamanızın her bir bölümünü en uygun dil ve platformu kullanarak kodlamayı kolaylaştırır. Örneğin, web tabanlı bir uygulamanın XML arka ucunu Java'da, bazı denetleme komut dosyalarını Ruby'de ve bir görselleştirme arayüzünü [İşleme](http://www.processing.org/)'de yazabilirsiniz. + +Son olarak, RDBMS'nin SQL komutlarınızı optimize etmek için çok terleyeceğini ve algoritmik ayar yerine uygulamanızın işlevselliğine konsantre olmanızı sağlayacağını unutmayın. Gelişmiş veritabanı sistemleri, arkanızdaki çok çekirdekli işlemcilerden bile faydalanacaktır. Ve teknoloji geliştikçe uygulamanızın performansı da artacaktır. + +[Diomidis Spinellis](http://programmer.97things.oreilly.com/wiki/index.php/Diomidis_Spinellis) Tarafından \ No newline at end of file From 2fd2a5f5b75fd79fd3870acb8ada84f5700d22b0 Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Wed, 9 Feb 2022 18:46:39 +0300 Subject: [PATCH 066/290] added thing_49 --- tr/SUMMARY.md | 2 +- tr/thing_49/README.md | 19 +++++++++++++++++++ 2 files changed, 20 insertions(+), 1 deletion(-) create mode 100644 tr/thing_49/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index 0d7d005d..06690db4 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -49,7 +49,7 @@ 1. [Sınırlarınızı Bilin](thing_46/README.md) 1. [Bir Sonraki İşleminizi(Commit) Bilin](thing_47/README.md) 1. [Büyük Birbirine Bağlı Veriler Bir Veritabanına Aittir](thing_48/README.md) -1. [Learn Foreign Languages](thing_49/README.md) +1. [Yabancı Diller Öğrenin](thing_49/README.md) 1. [Learn to Estimate](thing_50/README.md) 1. [Learn to Say "Hello, World"](thing_51/README.md) 1. [Let Your Project Speak for Itself](thing_52/README.md) diff --git a/tr/thing_49/README.md b/tr/thing_49/README.md new file mode 100644 index 00000000..edcd7db8 --- /dev/null +++ b/tr/thing_49/README.md @@ -0,0 +1,19 @@ +# Yabancı Diller Öğrenin + +Yazılımcıların iletişim kurması gerekir. Hem de çok fazla. + +Bir yazılımcının hayatında, çoğu iletişimin bilgisayarla gerçekleştiği dönemler vardır. Daha doğrusu, o bilgisayarda çalışan programlarla. Bu iletişim, fikirleri makine tarafından okunabilir bir şekilde ifade etmekle ilgilidir. Heyecan verici bir olasılık olmaya devam ediyor: Programlar, neredeyse hiçbir fiziksel madde içermeyen, gerçeğe dönüştürülmüş fikirlerdir. + +Yazılımcıların, gerçek veya sanal olsun, makinenin dilinde ve geliştirme araçları aracılığıyla o dille ilişkilendirilebilecek soyutlamalarda akıcı olması gerekir. Birçok farklı soyutlama öğrenmek önemlidir, aksi takdirde bazı fikirleri ifade etmek inanılmaz derecede zorlaşır. İyi yazılımcıların günlük rutinlerinin dışında durabilmeleri, başka amaçlar için anlamlı olan diğer dillerin farkında olmaları gerekir. Bunun karşılığını alacağı zaman her zaman gelir. + +Makinelerle iletişimin ötesinde, yazılımcıların akranlarıyla iletişim kurması gerekir. Günümüzün büyük projeleri, programlama sanatının basit bir uygulamasından daha çok sosyal çabalardır. Makine tarafından okunabilen soyutlamaların yapabileceğinden daha fazlasını anlamak ve ifade etmek önemlidir. Tanıdığım en iyi yazılımcıların çoğu, ana dillerinde ve tipik olarak diğer dillerde de çok akıcıdır. Bu sadece başkalarıyla iletişim kurmakla ilgili değildir: Bir dili iyi konuşmak aynı zamanda bir sorunu soyutlarken vazgeçilmez olan bir düşünce netliğine de yol açar. Ve programlama da bununla ilgilidir. + +Bir projenin makineyle, kendiyle ve akranlarla iletişimin ötesinde, çoğu farklı teknik geçmişi olan veya hiç olmayan birçok paydaşı vardır. Test, kalite ve dağıtımda, pazarlama ve satışta yaşarlar, bir ofiste (veya mağazada veya evde) son kullanıcılardır. Onları ve endişelerini anlamalısınız. Eğer onların dilini konuşamıyorsanız bu neredeyse imkansızdır. onların dünyasının dilini, onların etki alanını. Onlarla bir konuşmanın iyi gittiğini düşünebilirsiniz, ancak muhtemelen gitmezler. + +Muhasebecilerle konuşursanız, maliyet merkezi muhasebesi, bağlı sermaye, kullanılan sermaye vb. hakkında temel bilgilere ihtiyacınız vardır. Pazarlama veya avukatlarla konuşursanız, onların bazı jargonları ve dilleri (ve dolayısıyla zihinleri) size aşina olmalıdır. Tüm bu alana özgü dillerin projedeki biri tarafından ideal olarak yazılımcılar tarafından öğrenilmesi gerekir. Yazılımcılar, fikirleri bir bilgisayar aracılığıyla hayata geçirmekten nihai olarak sorumludur. + +Ve elbette hayat, yazılım projelerinden daha fazlasıdır. [Charlemagne](http://en.wikipedia.org/wiki/Charlemagne) tarafından belirtildiği gibi, başka bir dil bilmek, başka bir ruha sahip olmaktır. Yazılım endüstrisinin ötesindeki bağlantılarınız için yabancı dil bilmekten memnun kalacaksınız. Konuşmak yerine ne zaman dinleyeceğini bilmek. Çoğu dilin kelimeler olmadan olduğunu bilmek. + +> *Hakkında konuşulamayan şey, hakkında susmak gerekir.* - Ludwig Wittgenstein + +[Klaus Marquardt](http://programmer.97things.oreilly.com/wiki/index.php/Klaus_Marquardt) Tarafından \ No newline at end of file From 573bcbe50a7a61eeb27681d393d46de8ac8a06a5 Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Fri, 11 Feb 2022 18:30:01 +0300 Subject: [PATCH 067/290] added thing_50 --- tr/SUMMARY.md | 4 ++-- tr/thing_50/README.md | 31 +++++++++++++++++++++++++++++++ 2 files changed, 33 insertions(+), 2 deletions(-) create mode 100644 tr/thing_50/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index 06690db4..fc171ac3 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -40,7 +40,7 @@ 1. [Sıkı Çalışmanın Getirisi Yok](thing_37/README.md) 1. [Hata İzleyici Nasıl Kullanılır](thing_38/README.md) 1. [Kodu Kaldırarak İyileştirin](thing_39/README.md) -1. [Install Me](thing_40/README.md) +1. [Beni Kur](thing_40/README.md) 1. [Süreçler Arası İletişim Uygulama Yanıt Süresini Etkiler](thing_41/README.md) 1. [Yapıyı Temiz Tutun](thing_42/README.md) 1. [Komut Satırı Araçlarını Nasıl Kullanacağınızı Bilin](thing_43/README.md) @@ -50,7 +50,7 @@ 1. [Bir Sonraki İşleminizi(Commit) Bilin](thing_47/README.md) 1. [Büyük Birbirine Bağlı Veriler Bir Veritabanına Aittir](thing_48/README.md) 1. [Yabancı Diller Öğrenin](thing_49/README.md) -1. [Learn to Estimate](thing_50/README.md) +1. [Tahmin Etmeyi Öğrenin](thing_50/README.md) 1. [Learn to Say "Hello, World"](thing_51/README.md) 1. [Let Your Project Speak for Itself](thing_52/README.md) 1. [The Linker Is not a Magical Program](thing_53/README.md) diff --git a/tr/thing_50/README.md b/tr/thing_50/README.md new file mode 100644 index 00000000..036d7101 --- /dev/null +++ b/tr/thing_50/README.md @@ -0,0 +1,31 @@ +# Tahmin Etmeyi Öğrenin + +Bir yazılımcı olarak yöneticilerinize, meslektaşlarınıza ve kullanıcılarınıza gerçekleştirmeniz gereken görevler için tahminler sunabilmeniz gerekir, böylece onlar hedefleri başarmak için gereken zaman, maliyetler, teknoloji ve diğer kaynaklar hakkında makul derecede doğru bir fikre sahip olurlar. + +İyi tahmin yapabilmek için bazı tahmin tekniklerini öğrenmek elbette önemlidir. Bununla birlikte, her şeyden önce, tahminlerin ne olduğunu ve ne için kullanılmaları gerektiğini öğrenmek esastır. Ne kadar garip görünse de, birçok geliştirici ve yönetici bunu gerçekten bilmiyor. + +Bir proje yöneticisi ve bir yazılımcı arasındaki aşağıdaki alışveriş alışılmışın dışında değildir: + +> *Proje Yöneticisi:* *xyz* özelliğini geliştirmek için gereken süreyi tahmin edebilir misin? + +> *Yazılımcı:* Bir ay. + +> *Proje Yöneticisi:* Bu çok uzun! Sadece bir haftamız var. + +> *Yazılımcı:* En az üç haftaya ihtiyacım var. + +> *Proje Yöneticisi:* Sana en fazla iki hafta verebilirim. + +> *Yazılımcı:* Anlaştık! + +Yazılımcı, sonunda yönetici için kabul edilebilir olanla eşleşen bir "tahmin" ile gelir. Ancak yazılımcının tahmini olduğu görüldüğünden, yönetici yazılımcıyı buna karşı sorumlu tutacaktır. Bu konuşmada neyin yanlış olduğunu anlamak için üç tanıma ihtiyacımız var - tahmin, hedef ve taahhüt: + +- Bir *tahmin*, bir şeyin değeri, sayısı, miktarı veya kapsamına ilişkin yaklaşık bir hesaplama veya yargıdır. Bu tanım, bir tahminin somut verilere ve önceki deneyimlere dayanan olgusal bir ölçü olduğunu ima eder - hesaplanırken umutlar ve istekler göz ardı edilmelidir. Tanım ayrıca, yaklaşık olarak bir tahminin kesin olamayacağını, örneğin bir geliştirme görevinin 234,14 gün süreceğini tahmin edemeyeceğini ima eder. +- *hedef*, arzu edilen bir iş hedefinin ifadesidir, örneğin, "Sistem en az 400 eşzamanlı kullanıcıyı desteklemelidir." +- *taahhüt*, belirli bir tarihe veya olaya kadar belirli bir kalitede belirli bir işlevsellik sağlama taahhüdüdür. Bir örnek, "Arama işlevi, ürünün sonraki sürümünde kullanıma sunulacaktır" olabilir. + +Tahminler, hedefler ve taahhütler birbirinden bağımsızdır, ancak hedefler ve taahhütler sağlam tahminlere dayanmalıdır. Steve McConnell'in belirttiği gibi, "Yazılım tahmininin birincil amacı, bir projenin sonucunu tahmin etmek değil; bir projenin hedeflerinin, projenin bunları karşılamak için kontrol edilmesine izin verecek kadar gerçekçi olup olmadığını belirlemektir." Bu nedenle, tahminin amacı, proje paydaşlarının gerçekçi hedeflere dayalı taahhütlerde bulunmalarına izin vererek uygun proje yönetimi ve planlamasını mümkün kılmaktır. + +Yukarıdaki konuşmada yöneticinin yazılımcıdan gerçekten istediği şey, bir tahminde bulunmak değil, yöneticinin aklındaki belirtilmemiş bir hedefe dayalı bir taahhütte bulunmasıydı. Bir dahaki sefere bir tahmin sağlamanız istendiğinde, katılan herkesin ne hakkında konuştuğunu bildiğinden emin olun ve projelerinizin başarılı olma şansı daha yüksek olacaktır. Şimdi bazı teknikleri öğrenmenin zamanı geldi.... + +[Giovanni Asproni](http://programmer.97things.oreilly.com/wiki/index.php/Giovanni_Asproni) Tarafından \ No newline at end of file From d674dff0e64837edae072ac2fc11b00ba83b2ffd Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Fri, 11 Feb 2022 18:57:52 +0300 Subject: [PATCH 068/290] added thing_51 --- tr/SUMMARY.md | 2 +- tr/thing_51/README.md | 39 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 40 insertions(+), 1 deletion(-) create mode 100644 tr/thing_51/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index fc171ac3..9912a1ef 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -51,7 +51,7 @@ 1. [Büyük Birbirine Bağlı Veriler Bir Veritabanına Aittir](thing_48/README.md) 1. [Yabancı Diller Öğrenin](thing_49/README.md) 1. [Tahmin Etmeyi Öğrenin](thing_50/README.md) -1. [Learn to Say "Hello, World"](thing_51/README.md) +1. ["Merhaba Dünya" Demeyi Öğrenin](thing_51/README.md) 1. [Let Your Project Speak for Itself](thing_52/README.md) 1. [The Linker Is not a Magical Program](thing_53/README.md) 1. [The Longevity of Interim Solutions](thing_54/README.md) diff --git a/tr/thing_51/README.md b/tr/thing_51/README.md new file mode 100644 index 00000000..d000d7bc --- /dev/null +++ b/tr/thing_51/README.md @@ -0,0 +1,39 @@ +# "Merhaba Dünya" Demeyi Öğrenin + +Daha yaygın olarak Hoppy olarak bilinen kullanıcı adı leep olan Paul Lee, programlama konularında yerel uzman olarak ün yapmıştır. Yardıma ihtiyacım vardı. Hoppy'nin masasına doğru yürüdüm ve benim için bir koda bakabilir mi? diye sordum. + +Tabii, dedi Hoppy, bir sandalye çek. Arkasında piramit şeklinde yığılmış boş kola kutularını devirmemeye özen gösterdim. + +Ne kodu? + +Bir dosyadaki bir fonksiyonda, dedim. + +Öyleyse bu fonksiyona bir göz atalım. Hoppy K&R'ın bir kopyasını kenara çekti ve klavyesini önüme kaydırdı. + +IDE nerede? Görünüşe göre Hoppy'nin çalışan IDE'si yoktu, sadece çalıştıramadığım bir editör. Klavyeyi geri aldı. Birkaç tuşa bastıktan sonra dosyayı açtık, oldukça büyük bir dosyaydı ve işleve bakıyorduk, oldukça büyük bir işlevdi. Sormak istediğim koşullu bloğa çağrı yaptı. + +'x' negatifse bu cümle gerçekte ne yapar? diye sordum. Elbette yanlış. + +Bütün sabah "x"i negatif olmaya zorlamanın bir yolunu bulmaya çalışıyordum, ancak büyük dosyadaki büyük işlev büyük bir projenin parçasıydı ve deneylerimi yeniden derleme *sonra* yeniden çalıştırma döngüsü beni yıpratıyordu. Hoppy gibi bir uzman bana cevabı söyleyemez mi? + +Hoppy emin olmadığını itiraf etti. Sürprizime göre, K&R'ye ulaşmadı. Bunun yerine, kod bloğunu yeni bir düzenleyici arabelleğine kopyaladı, yeniden girinti yaptı, bir işleve sardı. Kısa bir süre sonra, sonsuza kadar döngüye giren, kullanıcıdan giriş değerlerini isteyen, bunları işleve ileten ve sonucu yazdıran bir ana işlevi kodlamıştı. Tamponu yeni bir dosya olarak, tryit.c olarak kaydetti. Bütün bunları kendim için yapabilirdim, belki de o kadar çabuk olmasa da. Ancak bir sonraki adımı son derece basitti ve o zamanlar benim çalışma şeklime oldukça yabancıydı: + +``` +$ cc tryit.c && ./a.out +``` + +Bakmak! Sadece birkaç dakika önce tasarlanan asıl programı şimdi çalışır durumdaydı. Birkaç değer denedik ve şüphelerimi doğruladık (yani bir konuda haklıydım!) ve ardından K&R'nin ilgili bölümünü kontrol etti. Hoppy'ye teşekkür ettim ve yine kola piramidini bozmamaya özen göstererek ayrıldım. + +Kendi masama döndüğümde IDE'mi kapattım. Büyük bir ürün içinde büyük bir proje üzerinde çalışmaya o kadar alışmıştım ki, yapmam gerekenin bu olduğunu düşünmeye başlamıştım. Genel amaçlı bir bilgisayar da küçük işler yapabilir. Bir metin düzenleyici açtım ve yazmaya başladım. + +``` +#include + +int main() +{ + printf("Hello, World\n"); + return 0; +} +``` + +[Thomas Guest](http://programmer.97things.oreilly.com/wiki/index.php/Thomas_Guest) Tarafından \ No newline at end of file From eedb30c9e2d62ac79cf5b6fe1a4e8ddc5f8d35c7 Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Mon, 21 Feb 2022 18:13:33 +0300 Subject: [PATCH 069/290] added thing_52 --- tr/SUMMARY.md | 2 +- tr/thing_52/README.md | 17 +++++++++++++++++ 2 files changed, 18 insertions(+), 1 deletion(-) create mode 100644 tr/thing_52/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index 9912a1ef..58c8bc13 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -52,7 +52,7 @@ 1. [Yabancı Diller Öğrenin](thing_49/README.md) 1. [Tahmin Etmeyi Öğrenin](thing_50/README.md) 1. ["Merhaba Dünya" Demeyi Öğrenin](thing_51/README.md) -1. [Let Your Project Speak for Itself](thing_52/README.md) +1. [Bırakın Projeniz Kendi Adına Konuşsun](thing_52/README.md) 1. [The Linker Is not a Magical Program](thing_53/README.md) 1. [The Longevity of Interim Solutions](thing_54/README.md) 1. [Make Interfaces Easy to Use Correctly and Hard to Use Incorrectly](thing_55/README.md) diff --git a/tr/thing_52/README.md b/tr/thing_52/README.md new file mode 100644 index 00000000..933e9acf --- /dev/null +++ b/tr/thing_52/README.md @@ -0,0 +1,17 @@ +# Bırakın Projeniz Kendi Adına Konuşsun + +Projenizde muhtemelen bir sürüm kontrol sistemi vardır. Belki de otomatik testlerle doğruluğunu doğrulayan sürekli bir entegrasyon sunucusuna bağlıdır. Bu harika. + +Kod ölçümlerini toplamak için sürekli tümleştirme sunucunuza statik kod analizi araçları dahil edebilirsiniz. Bu metrikler, kodunuzun belirli yönleri ve bunların zaman içindeki gelişimi hakkında geri bildirim sağlar. Kod metriklerini yüklediğinizde, her zaman geçmek istemediğiniz kırmızı bir çizgi olacaktır. %20 test kapsamıyla başladığınızı ve asla %15'in altına düşmek istemediğinizi varsayalım. Sürekli entegrasyon, tüm bu sayıları takip etmenize yardımcı olur, ancak yine de düzenli olarak kontrol etmeniz gerekir. Bu görevi projenin kendisine devredebileceğinizi ve işler daha da kötüye gittiğinde rapor vermek için ona güvenebileceğinizi hayal edin. + +Projenize ses vermelisiniz. Bu, e-posta veya anlık mesajlaşma yoluyla yapılabilir ve geliştiricilere sayılardaki en son düşüş veya iyileşme hakkında bilgi verilir. Ancak projeyi ofisinizde bir aşırı geri bildirim cihazı (XFD - extreme feedback device) kullanarak somutlaştırmak daha da etkilidir. + +XFD'lerin fikri, otomatik analiz sonuçlarına dayalı olarak bir lamba, taşınabilir bir çeşme, bir oyuncak robot ve hatta bir USB roketatar gibi fiziksel bir cihazı sürmektir. Limitleriniz aşıldığında, cihaz durumunu değiştirir. Bir lamba olması durumunda, yanacak, parlak ve belirgin olacaktır. Eve gitmek için kapıdan aceleyle çıksanız bile mesajı kaçıramazsınız. + +Aşırı geri bildirim cihazının türüne bağlı olarak, yapı kesintisini duyabilir, kodunuzdaki kırmızı uyarı sinyallerini görebilir ve hatta kodunuzun kokusunu bile alabilirsiniz. Dağıtılmış bir ekip üzerinde çalışıyorsanız, cihazlar farklı konumlarda çoğaltılabilir. Proje yöneticinizin ofisine, genel proje sağlık durumunu gösteren bir trafik ışığı yerleştirebilirsiniz. Proje yöneticiniz bunu takdir edecektir. + +Uygun bir cihaz seçerken yaratıcılığınızın size rehberlik etmesine izin verin. Kültürünüz biraz geekse, takım maskotunuzu radyo kontrollü oyuncaklarla donatmanın yollarını arayabilirsiniz. Daha profesyonel bir görünüm istiyorsanız, şık tasarımlı lambalara yatırım yapın. Daha fazla ilham almak için İnternet'te arama yapın. Elektrik fişi veya uzaktan kumandası olan her şey, aşırı geri bildirim cihazı olarak kullanılma potansiyeline sahiptir. + +Aşırı geri bildirim cihazı, projenizin ses kutusu görevi görür. Proje şimdi fiziksel olarak geliştiricilerle birlikte, ekibin seçtiği kurallara göre onları şikayet ediyor veya övüyor. Konuşma sentez yazılımı ve bir çift hoparlör uygulayarak bu kişileştirmeyi daha da ileri götürebilirsiniz. Şimdi projeniz gerçekten kendisi için konuşuyor. + +[Daniel Lindner](http://programmer.97things.oreilly.com/wiki/index.php/Daniel_Lindner) Tarafından \ No newline at end of file From f57eee14f2f31b6f97bc6385b23a14c9060d5219 Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Mon, 21 Feb 2022 18:23:09 +0300 Subject: [PATCH 070/290] added thing_53 --- tr/SUMMARY.md | 2 +- tr/thing_53/README.md | 52 +++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 53 insertions(+), 1 deletion(-) create mode 100644 tr/thing_53/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index 58c8bc13..1d8147f2 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -53,7 +53,7 @@ 1. [Tahmin Etmeyi Öğrenin](thing_50/README.md) 1. ["Merhaba Dünya" Demeyi Öğrenin](thing_51/README.md) 1. [Bırakın Projeniz Kendi Adına Konuşsun](thing_52/README.md) -1. [The Linker Is not a Magical Program](thing_53/README.md) +1. [Bağlayıcı Sihirli Bir Program Değildir](thing_53/README.md) 1. [The Longevity of Interim Solutions](thing_54/README.md) 1. [Make Interfaces Easy to Use Correctly and Hard to Use Incorrectly](thing_55/README.md) 1. [Make the Invisible More Visible](thing_56/README.md) diff --git a/tr/thing_53/README.md b/tr/thing_53/README.md new file mode 100644 index 00000000..d14f0c68 --- /dev/null +++ b/tr/thing_53/README.md @@ -0,0 +1,52 @@ +# Bağlayıcı Sihirli Bir Program Değildir + +Sık sık (bunu yazmadan hemen önce başıma geldi), birçok programcının kaynak koddan derlenmiş bir dilde statik olarak bağlantılı bir yürütülebilir dosyaya geçme süreciyle ilgili görüşü şudur: + +1. Kaynak kodunu düzenleyin +2. Kaynak kodunu nesne dosyalarına derleyin +3. Sihirli bir şey olur +4. Yürütülebilir dosyayı çalıştırın + +Adım 3, elbette, bağlama adımıdır. Neden böyle çirkin bir şey söyleyeyim ki? Onlarca yıldır teknik destek yapıyorum ve aşağıdaki soruları tekrar tekrar alıyorum: + +- Bağlayıcı, def'in birden fazla kez tanımlandığını söylüyor. +- Bağlayıcı, abc'nin çözülmemiş bir sembol olduğunu söylüyor. +- Yürütülebilir dosyam neden bu kadar büyük? + +Ardından "Şimdi ne yapacağım?" genellikle "görünüyor" ve "bir şekilde" ifadeleri birbirine karışmış ve tam bir şaşkınlık havası ile. Bağlama sürecinin büyülü bir süreç olarak görüldüğünü gösteren "görünüyor" ve "bir şekilde", muhtemelen yalnızca sihirbazlar ve büyücüler tarafından anlaşılabilir. Derleme süreci bu tür ifadeleri ortaya çıkarmaz, bu da programcıların genellikle derleyicilerin nasıl çalıştığını veya en azından ne yaptıklarını anladığını ima eder. + +Bir bağlayıcı çok aptal, yaya, basit bir programdır. Tek yaptığı, nesne dosyalarının kod ve veri bölümlerini bir araya getirmek, sembollere referansları tanımlarıyla bağlamak, çözülmemiş sembolleri kitaplıktan çıkarmak ve bir yürütülebilir dosya yazmaktır. Bu kadar. Büyü yok! Sihir yok! Bir bağlayıcı yazmanın sıkıcılığı genellikle tamamen gülünç derecede karmaşık dosya biçimlerinin kodunu çözmek ve oluşturmakla ilgilidir, ancak bu bir bağlayıcının temel yapısını değiştirmez. + +Diyelim ki bağlayıcı, def'in bir kereden fazla tanımlandığını söylüyor. C, C++ ve D gibi birçok programlama dilinin hem bildirimleri hem de tanımları vardır. Bildirimler normalde aşağıdaki gibi başlık dosyalarına girer: + +``` +extern int iii; +``` + +bu da `iii` sembolüne harici bir referans oluşturur. Öte yandan, bir tanım aslında sembol için depolamayı bir kenara bırakır, genellikle uygulama dosyasında görünür ve şöyle görünür: + +``` +int iii = 3; +``` + +Her bir sembol için kaç tanım olabilir? *Highlander* filminde olduğu gibi, sadece bir tane olabilir. Peki ya birden fazla uygulama dosyasında bir iii tanımı görünüyorsa? + +``` +// File a.c +int iii = 3; +``` + +``` +// File b.c +double iii(int x) { return 3.7; } +``` + +Bağlayıcı, `iii`ün birden çok tanımlı olduğundan şikayet edecektir. + +Sadece bir tane olamaz, bir tane olmalı. iii yalnızca bir bildirim olarak görünüyorsa, ancak asla bir tanım değilse, bağlayıcı, iii'ün çözülmemiş bir sembol olduğundan şikayet edecektir. + +Bir yürütülebilir dosyanın neden bu boyutta olduğunu belirlemek için, bağlayıcıların isteğe bağlı olarak oluşturduğu harita dosyasına bakın. Bir harita dosyası, yürütülebilir dosyadaki tüm sembollerin adresleriyle birlikte bir listesinden başka bir şey değildir. Bu size kitaplıktan hangi modüllerin bağlandığını ve her modülün boyutunu söyler. Artık şişkinliğin nereden geldiğini görebilirsiniz. Genellikle, neden bağlantılı oldukları hakkında hiçbir fikriniz olmayan kitaplık modülleri olacaktır. Bunu anlamak için, şüpheli modülü kitaplıktan geçici olarak kaldırın ve yeniden bağlayın. Daha sonra oluşturulan tanımsız sembol hatası, o modüle kimin başvurduğunu gösterecektir. + +Belirli bir bağlayıcı mesajını neden aldığınız her zaman hemen açık olmasa da, bağlayıcılarla ilgili sihirli bir şey yoktur. Mekanikler basittir; her durumda çözmeniz gereken ayrıntılardır. + +[Walter Bright](http://creativecommons.org/licenses/by/3.0/us/) Tarafından \ No newline at end of file From 200fcc4d8e34a1e06975f7fdb7a5922f81f3ecf7 Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Mon, 21 Feb 2022 18:32:45 +0300 Subject: [PATCH 071/290] added thing_54 --- tr/SUMMARY.md | 2 +- tr/thing_54/README.md | 33 +++++++++++++++++++++++++++++++++ 2 files changed, 34 insertions(+), 1 deletion(-) create mode 100644 tr/thing_54/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index 1d8147f2..3797c214 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -54,7 +54,7 @@ 1. ["Merhaba Dünya" Demeyi Öğrenin](thing_51/README.md) 1. [Bırakın Projeniz Kendi Adına Konuşsun](thing_52/README.md) 1. [Bağlayıcı Sihirli Bir Program Değildir](thing_53/README.md) -1. [The Longevity of Interim Solutions](thing_54/README.md) +1. [Geçici Çözümlerin Uzun Ömrü](thing_54/README.md) 1. [Make Interfaces Easy to Use Correctly and Hard to Use Incorrectly](thing_55/README.md) 1. [Make the Invisible More Visible](thing_56/README.md) 1. [Message Passing Leads to Better Scalability in Parallel Systems](thing_57/README.md) diff --git a/tr/thing_54/README.md b/tr/thing_54/README.md new file mode 100644 index 00000000..9ff7ce12 --- /dev/null +++ b/tr/thing_54/README.md @@ -0,0 +1,33 @@ +# Geçici Çözümlerin Uzun Ömrü + +Neden geçici çözümler üretiyoruz? + +Tipik olarak, çözülmesi gereken acil bir sorun vardır. Takım zincirindeki bir boşluğu dolduran bazı takımlar, geliştirme ekibinin içinde olabilir. Eksik işlevleri gideren bir geçici çözüm gibi harici olabilir, son kullanıcılar tarafından görülebilir. + +Çoğu sistemde ve ekipte, sistemden bir şekilde ayrılmış, bazen değiştirilecek bir taslak olarak kabul edilen, kodun geri kalanını şekillendiren standartları ve yönergeleri takip etmeyen bazı yazılımlar bulacaksınız. Kaçınılmaz olarak geliştiricilerin bunlardan şikayet ettiğini duyacaksınız. Oluşturulmalarının nedenleri çok ve çeşitlidir, ancak geçici bir çözümün başarısının anahtarı basittir: Yararlıdır. + +Bununla birlikte, ara çözümler atalet (veya bakış açınıza bağlı olarak momentum) kazanır. Orada olduklarından, nihayetinde yararlı olduklarından ve geniş çapta kabul edildiğinden, başka bir şey yapmaya hemen gerek yoktur. Bir paydaş hangi eylemin en fazla değeri katacağına karar vermek zorunda kaldığında, bir ara çözümün uygun entegrasyonundan daha yüksek sıralarda yer alan pek çok kişi olacaktır. Niye? Çünkü oradadır, çalışır ve kabul edilir. Algılanan tek dezavantajı, seçilen standartları ve yönergeleri takip etmemesidir, birkaç niş pazar dışında, bu önemli bir güç olarak kabul edilmez. + +Böylece geçici çözüm yerinde kalır. Sonsuza kadar. + +Ve bu geçici çözümle ilgili sorunlar ortaya çıkarsa, onu kabul edilen üretim kalitesiyle uyumlu hale getirecek bir güncelleme sağlanması olası değildir. Ne yapalım? Bu geçici çözümde hızlı bir geçici güncelleme genellikle işi yapar. Ve büyük olasılıkla iyi karşılanacaktır. İlk ara çözümle aynı güçlü yönleri sergiliyor... sadece daha güncel. + +Bu bir sorun mu? + +Cevap, projenize ve üretim kodu standartlarındaki kişisel payınıza bağlıdır. Sistemler çok fazla ara çözüm içerdiğinde, entropisi veya dahili karmaşıklığı artar ve sürdürülebilirliği azalır. Ancak, bu muhtemelen ilk önce sorulacak yanlış sorudur. Bir çözümden bahsettiğimizi unutmayın. Tercih ettiğiniz çözüm olmayabilir, herhangi birinin tercih ettiği bir çözüm olmayabilir, ancak bu çözümü yeniden işleme motivasyonu zayıftır. + +Peki bir sorun görürsek ne yapabiliriz? + +1. Her şeyden önce geçici bir çözüm yaratmaktan kaçının. +2. Proje yöneticisinin kararını etkileyen güçleri değiştirin. +3. Olduğu gibi bırakın. + +Bu seçenekleri daha yakından inceleyelim: + +1. Kaçınma çoğu yerde işe yaramaz. Çözülmesi gereken gerçek bir sorun var ve standartların çok kısıtlayıcı olduğu ortaya çıktı. Standartları değiştirmek için biraz enerji harcayabilirsiniz. Onurlu olsa da sıkıcı bir çaba... ve bu değişiklik, elinizdeki problem için zamanında etkili olmayacak. +2. Güçler, gönüllü değişime direnen proje kültüründe kök salmıştır. Çok küçük projelerde başarılı olabilir, özellikle de sadece sizseniz ve önceden sormadan pisliği temizleyebilirsiniz. Proje, gözle görülür bir şekilde durdurulacak ve temizlik için biraz zaman tanınacak kadar dağınıksa da başarılı olabilir. +3. Önceki seçenek geçerli değilse, statüko otomatik olarak uygulanır. + +Birçok çözüm üreteceksiniz, bazıları geçici olacak, çoğu faydalı olacak. Ara çözümleri aşmanın en iyi yolu onları gereksiz kılmak, daha şık ve kullanışlı bir çözüm sunmaktır. Değiştiremeyeceğiniz şeyleri kabul etmek için [huzur](http://en.wikipedia.org/wiki/Serenity_prayer), değiştirebileceğiniz şeyleri değiştirmek için cesaret ve aradaki farkı bilmek için bilgelik bahşedilsin. + +[Klaus Marquardt](http://programmer.97things.oreilly.com/wiki/index.php/Klaus_Marquardt) Tarafından From 51bdcffa4cdafa6f263cf082d181d8ddf35afa20 Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Mon, 21 Feb 2022 18:36:04 +0300 Subject: [PATCH 072/290] added thing_55 --- tr/SUMMARY.md | 2 +- tr/thing_55/README.md | 16 ++++++++++++++++ 2 files changed, 17 insertions(+), 1 deletion(-) create mode 100644 tr/thing_55/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index 3797c214..4913f6db 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -55,7 +55,7 @@ 1. [Bırakın Projeniz Kendi Adına Konuşsun](thing_52/README.md) 1. [Bağlayıcı Sihirli Bir Program Değildir](thing_53/README.md) 1. [Geçici Çözümlerin Uzun Ömrü](thing_54/README.md) -1. [Make Interfaces Easy to Use Correctly and Hard to Use Incorrectly](thing_55/README.md) +1. [Arayüzlerin Doğru Kullanımını Kolay ve Yanlış Kullanımını Zorlaştırın](thing_55/README.md) 1. [Make the Invisible More Visible](thing_56/README.md) 1. [Message Passing Leads to Better Scalability in Parallel Systems](thing_57/README.md) 1. [A Message to the Future](thing_58/README.md) diff --git a/tr/thing_55/README.md b/tr/thing_55/README.md new file mode 100644 index 00000000..9446c823 --- /dev/null +++ b/tr/thing_55/README.md @@ -0,0 +1,16 @@ +# Arayüzlerin Doğru Kullanımını Kolay ve Yanlış Kullanımını Zorlaştırın + +Yazılım geliştirmede en yaygın görevlerden biri arayüz belirtimidir. Arayüzler en yüksek soyutlama seviyesinde (kullanıcı arayüzleri), en düşük seviyede (fonksiyon arayüzleri) ve aradaki seviyelerde (sınıf arayüzleri, kütüphane arayüzleri vb.) oluşur. Bir sistemle nasıl etkileşime gireceklerini belirlemek için son kullanıcılarla birlikte çalışın, bir API belirtmek için geliştiricilerle işbirliği yapın veya bir sınıfa özel işlevler bildirin, arayüz tasarımı işinizin önemli bir parçasıdır. Bunu iyi yaparsanız, arayüzlerinizi kullanmak bir zevk olacak ve başkalarının üretkenliğini artıracaktır. Kötü yaparsanız, arayüzleriniz bir hayal kırıklığı ve hata kaynağı olacaktır. + +İyi arayüzler şunlardır: + +- **Doğru kullanımı kolay.** İyi tasarlanmış bir arayüz kullanan kişiler, hemen hemen her zaman arayüzü doğru kullanır, çünkü bu en az dirençli yoldur. Bir GUI'de, hemen hemen her zaman doğru simgeye, düğmeye veya menü girişine tıklarlar, çünkü bu yapılması açık ve kolay olan şeydir. Bir API'de, neredeyse her zaman doğru parametreleri doğru değerlerle iletirler, çünkü en doğal olan budur. Doğru kullanımı kolay arayüzler sayesinde *işler yoluna girer.* +- **Yanlış kullanımı zor.** İyi arayüzler, insanların yapabileceği hataları tahmin eder ve bunları gerçekleştirmeyi zor, ideal olarak imkansız hale getirir. Bir GUI, örneğin mevcut bağlamda hiçbir anlam ifade etmeyen komutları devre dışı bırakabilir veya kaldırabilir veya bir API, parametrelerin herhangi bir sırayla iletilmesine izin vererek argüman sıralama sorunlarını ortadan kaldırabilir. + +Doğru kullanımı kolay arayüzler tasarlamanın iyi bir yolu, onları var olmadan önce kullanmaktır. Bir GUI'yi (muhtemelen bir beyaz tahta üzerinde veya bir masadaki dizin kartlarını kullanarak) oluşturun ve herhangi bir temel kod oluşturulmadan önce onunla oynayın. İşlevler bildirilmeden önce çağrıları bir API'ye yazın. Genel kullanım durumlarını gözden geçirin ve arayüzün nasıl davranmasını *istediğinizi* belirtin. Neye tıklayabilmek *istemek* istiyorsunuz? Neyi geçebilmek *istiyorsun*? Kullanımı kolay arayüzler doğal görünüyor çünkü yapmak istediğinizi yapmanıza izin veriyorlar. Bunları bir kullanıcının bakış açısından geliştirirseniz, bu tür arayüzleri bulmanız daha olasıdır. (Bu bakış açısı, önce test programlamanın güçlü yönlerinden biridir.) + +Arayüzlerin yanlış kullanımını zorlaştırmak iki şeyi gerektirir. İlk olarak, kullanıcıların yapabileceği hataları tahmin etmeli ve bunları önlemenin yollarını bulmalısınız. İkinci olarak, erken sürüm sırasında bir arayüzün nasıl kötüye kullanıldığını gözlemlemeli ve arayüzü değiştirmelisiniz. Evet, arayüzü değiştirin! Bu tür hataları önlemek için. Yanlış kullanımı önlemenin en iyi yolu, bu tür bir kullanımı imkansız kılmaktır. Kullanıcılar geri alınamaz bir eylemi geri almak istemeye devam ederse, eylemi geri alınabilir hale getirmeye çalışın. Bir API'ye yanlış değeri aktarmaya devam ederlerse, API'yi, kullanıcıların geçmek istediği değerleri alacak şekilde değiştirmek için elinizden gelenin en iyisini yapın. + +Her şeyden önce, arayüzlerin uygulayıcılarının değil, kullanıcılarının rahatlığı için var olduğunu unutmayın. + +[Scott Meyers](http://programmer.97things.oreilly.com/wiki/index.php/Scott_Meyers) Tarafından \ No newline at end of file From 508e74b074f4506093c3d0a14b7896cece12be4b Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Tue, 22 Feb 2022 18:03:51 +0300 Subject: [PATCH 073/290] added thing_56 --- tr/SUMMARY.md | 2 +- tr/thing_56/README.md | 19 +++++++++++++++++++ 2 files changed, 20 insertions(+), 1 deletion(-) create mode 100644 tr/thing_56/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index 4913f6db..0b94706c 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -56,7 +56,7 @@ 1. [Bağlayıcı Sihirli Bir Program Değildir](thing_53/README.md) 1. [Geçici Çözümlerin Uzun Ömrü](thing_54/README.md) 1. [Arayüzlerin Doğru Kullanımını Kolay ve Yanlış Kullanımını Zorlaştırın](thing_55/README.md) -1. [Make the Invisible More Visible](thing_56/README.md) +1. [Görünmezi Daha Görünür Hale Getirin](thing_56/README.md) 1. [Message Passing Leads to Better Scalability in Parallel Systems](thing_57/README.md) 1. [A Message to the Future](thing_58/README.md) 1. [Missing Opportunities for Polymorphism](thing_59/README.md) diff --git a/tr/thing_56/README.md b/tr/thing_56/README.md new file mode 100644 index 00000000..dd06e891 --- /dev/null +++ b/tr/thing_56/README.md @@ -0,0 +1,19 @@ +# Görünmezi Daha Görünür Hale Getirin + +Görünmezliğin birçok yönü, desteklenmesi gereken yazılım ilkeleri olarak haklı olarak övülür. Terminolojimiz, görünmezlik metaforları bakımından zengindir. Mekanizma şeffaflığı ve bilgi gizleme, bunlardan ikisi. Douglas Adams'ın deyişiyle, yazılım ve onu geliştirme süreci *çoğunlukla görünmez* olabilir: + +- Kaynak kodun doğuştan gelen bir varlığı, doğuştan gelen bir davranışı yoktur ve fizik yasalarına uymaz. Bir düzenleyiciye yüklediğinizde görünür, ancak düzenleyiciyi kapattığınızda kaybolur. Bunu çok uzun süre düşünün ve kimsenin duymadığı bir ağacın devrilmesi gibi, gerçekten var mı diye merak etmeye başlıyorsunuz. +- Çalışan bir uygulamanın varlığı ve davranışı vardır, ancak oluşturulduğu kaynak koddan hiçbir şey göstermez. Google'ın ana sayfası hoş bir şekilde minimaldir; arkasında olup bitenler kesinlikle önemli. +- %90'ını bitirdiysen ve son %10'da hata ayıklamaya çalışırken durmadan takılıp kaldıysan, %90'ını bitirmedin, değil mi? Hataları düzeltmek ilerleme kaydetmiyor. Hata ayıklamak için size ödeme yapılmaz. Hata ayıklama israftır. Atığı daha görünür kılmak iyidir, böylece ne olduğunu görebilir ve ilk etapta onu yaratmamaya çalışmayı düşünmeye başlayabilirsiniz. +- Eğer projeniz yolunda gidiyorsa ve bir hafta sonra altı ay geciktiyse sorunlarınız var, bunların en büyüğü muhtemelen altı ay gecikmiş olması değil, ancak görünmezlik güç alanları altı aylık gecikmeyi gizleyecek kadar güçlü! Görünür ilerleme eksikliği, ilerleme eksikliği ile eş anlamlıdır. + +Görünmezlik tehlikeli olabilir. Düşüncelerinizi bağlayacak somut bir şeyiniz olduğunda daha net düşünürsünüz. Onları gördüğünüzde ve sürekli değiştiğini gördüğünüzde işleri daha iyi yönetirsiniz: + +- Birim testleri yazmak, kod biriminin birim testi için ne kadar kolay olduğuna dair kanıt sağlar. Kodun sergilemesini istediğiniz gelişimsel niteliklerin varlığını (veya yokluğunu) ortaya çıkarmaya yardımcı olur; düşük bağlantı ve yüksek kohezyon gibi nitelikler. +- Çalışan birim testleri, kodun davranışı hakkında kanıt sağlar. Uygulamanın sergilemesini istediğiniz niteliklerin çalışma zamanının varlığını (veya yokluğunu) ortaya çıkarmaya yardımcı olur; sağlamlık ve doğruluk gibi nitelikler. +- Bülten tahtaları ve kartları kullanmak ilerlemeyi görünür ve somut hale getirir. Görevler, gizli bir proje yönetim aracına başvurmadan ve kurgusal durum raporları için programcıları kovalamak zorunda kalmadan *Başlamadı*, *Devam Ediyor* veya *Bitti* olarak görülebilir. +- Kademeli geliştirme yapmak, geliştirme kanıtlarının sıklığını artırarak geliştirme ilerlemesinin (veya eksikliğinin) görünürlüğünü artırır. Serbest bırakılabilir yazılımın tamamlanması gerçeği ortaya çıkarır; tahminler öyle değil. + +Bol miktarda düzenli görünür kanıt içeren bir yazılım geliştirmek en iyisidir. Görünürlük, ilerlemenin gerçek olduğuna ve bir yanılsama olmadığına, kasıtlı ve kasıtsız olmadığına, tekrarlanabilir olduğuna ve tesadüfi olmadığına dair güven verir. + +[Jon Jagger](http://programmer.97things.oreilly.com/wiki/index.php/Jon_Jagger) Tarafından \ No newline at end of file From 940a301747472e60582b585639e7ba5e64226e2d Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Wed, 23 Feb 2022 18:08:33 +0300 Subject: [PATCH 074/290] added thing_57 --- tr/SUMMARY.md | 2 +- tr/thing_57/README.md | 19 +++++++++++++++++++ 2 files changed, 20 insertions(+), 1 deletion(-) create mode 100644 tr/thing_57/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index 0b94706c..f8816699 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -57,7 +57,7 @@ 1. [Geçici Çözümlerin Uzun Ömrü](thing_54/README.md) 1. [Arayüzlerin Doğru Kullanımını Kolay ve Yanlış Kullanımını Zorlaştırın](thing_55/README.md) 1. [Görünmezi Daha Görünür Hale Getirin](thing_56/README.md) -1. [Message Passing Leads to Better Scalability in Parallel Systems](thing_57/README.md) +1. [Mesaj Geçişi, Paralel Sistemlerde Daha İyi Ölçeklenebilirlik Sağlar](thing_57/README.md) 1. [A Message to the Future](thing_58/README.md) 1. [Missing Opportunities for Polymorphism](thing_59/README.md) 1. [News of the Weird: Testers Are Your Friends](thing_60/README.md) diff --git a/tr/thing_57/README.md b/tr/thing_57/README.md new file mode 100644 index 00000000..8176d8dd --- /dev/null +++ b/tr/thing_57/README.md @@ -0,0 +1,19 @@ +# Mesaj Geçişi, Paralel Sistemlerde Daha İyi Ölçeklenebilirlik Sağlar + +Yazılımcılara, hesaplama çalışmalarının en başından itibaren, eşzamanlılığın ve özellikle eşzamanlılığın özel bir alt kümesi olan paralelliğin zor olduğu, yalnızca en iyilerin onu doğru yapmayı umabileceği ve hatta yanlış anlayabileceği öğretilir. İplikler, semaforlar, monitörler ve iş parçacığı açısından güvenli olmak için değişkenlere eşzamanlı erişim sağlamanın ne kadar zor olduğu konusunda her zaman büyük bir odak vardır. + +Doğru, birçok zor problem var ve çözülmesi çok zor olabilir. Ama sorunun kökü nedir? Paylaşılan hafıza. İnsanların üzerinde durup durduğu hemen hemen tüm eşzamanlılık sorunları, paylaşılan değişebilir belleğin kullanımıyla ilgilidir: yarış koşulları, kilitlenme, canlı kilit, vb. Cevap açık görünüyor: Ya eşzamanlılıktan vazgeç ya da paylaşılan bellekten kaçın! + +Devam eden eşzamanlılık neredeyse kesinlikle bir seçenek değildir. Bilgisayarlar neredeyse üç ayda bir giderek daha fazla çekirdeğe sahip olduğundan, gerçek paralellikten yararlanmak giderek daha önemli hale geliyor. Uygulama performansını iyileştirmek için artık artan işlemci saat hızlarına güvenemeyiz. Yalnızca paralellikten yararlanarak uygulamaların performansı iyileşir. Açıkçası, performansı iyileştirmemek bir seçenektir, ancak kullanıcılar tarafından kabul edilmesi pek olası değildir. + +Öyleyse paylaşılan hafızadan kaçınabilir miyiz? Kesinlikle. + +Programlama modelimiz olarak iş parçacıklarını ve paylaşılan belleği kullanmak yerine, süreçleri ve mesaj geçişini kullanabiliriz. Buradaki işlem, mutlaka bir işletim sistemi işlemi değil, yalnızca yürütme koduyla korunan bağımsız bir durum anlamına gelir. Erlang (ve ondan önceki occam) gibi diller, süreçlerin eşzamanlı ve paralel sistemleri programlamak için çok başarılı bir mekanizma olduğunu göstermiştir. Bu tür sistemler, paylaşılan bellek, çok iş parçacıklı sistemlerin sahip olduğu tüm senkronizasyon streslerine sahip değildir. Ayrıca, bu tür sistemlerin mühendisliğinin bir parçası olarak uygulanabilecek resmi bir model Haberleşme Sıralı Süreçler (CSP - Communicating Sequential Processes) vardır. + +Daha ileri gidebilir ve bir bilgi işlem yolu olarak veri akışı sistemlerini tanıtabiliriz. Bir veri akışı sisteminde, açıkça programlanmış bir kontrol akışı yoktur. Bunun yerine, veri yolları ile bağlanan operatörlerin yönlendirilmiş bir grafiği kurulur ve ardından sisteme veri beslenir. Değerlendirme, sistem içindeki verilerin hazır olup olmadığı ile kontrol edilir. Senkronizasyon sorunu kesinlikle yoktur. + +Tüm bunları söyledikten sonra, C, C++, Java, Python ve Groovy gibi diller sistem geliştirmenin başlıca dilleridir ve bunların hepsi programcılara paylaşımlı bellek, çok kanallı sistemler geliştirme dilleri olarak sunulur. Peki ne yapılabilir? Cevap, paylaşılan değiştirilebilir belleğin tüm kullanımından kaçınarak süreç modelleri ve mesaj geçişi sağlayan kitaplıklar ve çerçeveler kullanmak veya yoksa, oluşturmaktır. + +Sonuç olarak, paylaşılan bellekle programlama değil, bunun yerine mesaj iletimini kullanmak, bilgisayar donanımında yaygın olan paralellikten yararlanan sistemleri uygulamanın en başarılı yolu olabilir. Tuhaf bir şekilde, süreçler bir eşzamanlılık birimi olarak iş parçacıklarından önce gelse de, gelecek süreçleri uygulamak için iş parçacıklarını kullanmak gibi görünüyor. + +[Russel Winder](http://programmer.97things.oreilly.com/wiki/index.php/Russel_Winder) Tarafından \ No newline at end of file From b6369953cfbca7a5d550d33640c820714a4598fe Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Fri, 25 Feb 2022 18:00:58 +0300 Subject: [PATCH 075/290] added thing_58 --- tr/SUMMARY.md | 2 +- tr/thing_58/README.md | 23 +++++++++++++++++++++++ 2 files changed, 24 insertions(+), 1 deletion(-) create mode 100644 tr/thing_58/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index f8816699..3eb4ea9d 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -58,7 +58,7 @@ 1. [Arayüzlerin Doğru Kullanımını Kolay ve Yanlış Kullanımını Zorlaştırın](thing_55/README.md) 1. [Görünmezi Daha Görünür Hale Getirin](thing_56/README.md) 1. [Mesaj Geçişi, Paralel Sistemlerde Daha İyi Ölçeklenebilirlik Sağlar](thing_57/README.md) -1. [A Message to the Future](thing_58/README.md) +1. [Geleceğe Mesaj](thing_58/README.md) 1. [Missing Opportunities for Polymorphism](thing_59/README.md) 1. [News of the Weird: Testers Are Your Friends](thing_60/README.md) 1. [One Binary](thing_61/README.md) diff --git a/tr/thing_58/README.md b/tr/thing_58/README.md new file mode 100644 index 00000000..8688d452 --- /dev/null +++ b/tr/thing_58/README.md @@ -0,0 +1,23 @@ +# Geleceğe Mesaj + +Belki de çoğu zeki insanlar olduğu içindir, ancak programcılarla yan yana ders verdiğim ve çalıştığım tüm yıllar boyunca, görünüşe göre çoğu, mücadele ettikleri problemler zor olduğu için çözümlerin olması gerektiğini düşündüler, herkesin (kod yazıldıktan birkaç ay sonra bile) anlaması ve sürdürmesi aynı derecede zor olabilir. + +Veri yapıları sınıfımdaki bir öğrenci olan ve bana ne yazdığını göstermek için içeri girmek zorunda kalan Joe ile ilgili bir olayı hatırlıyorum. "Betcha ne yaptığını tahmin edemez!" diye öttü. + +"Haklısın," diye kabul ettim örneğine çok fazla zaman harcamadan ve önemli bir mesajı nasıl ileteceğimi merak etmeden. "Eminim bunun üzerinde çok çalışıyorsun. Acaba önemli bir şeyi unutmadıysan merak ediyorum. Söylesene Joe, senin küçük bir erkek kardeşin yok mu?" + +"Evet. Elbette! Phil! O sizin Giriş sınıfınızda. O da programlama öğreniyor!" Joe gururla duyurdu. + +"Bu harika," diye yanıtladım. "Acaba bu kodu okuyabiliyor mu?" + +"Mümkün değil!" dedi Joe. "Bu zor bir şey!" + +"Diyelim ki, bunun gerçek çalışma kodu olduğunu ve birkaç yıl içinde Phil'in bir bakım güncellemesi yapması için tutulduğunu. Onun için ne yaptınız?" diye önerdim. Joe gözlerini kırpıştırarak bana baktı. "Phil'in gerçekten zeki olduğunu biliyoruz, değil mi?" Joe başını salladı. "Bunu söylemekten nefret ediyorum ama ben de oldukça zekiyim!" Joe gülümsedi. "Yani, burada ne yaptığınızı kolayca anlayamazsam ve çok zeki küçük kardeşiniz muhtemelen bunun üzerine kafa yorarsa, bu yazdıklarınız ne anlama geliyor?" Joe koduna bana göründüğünden biraz farklı baktı. "Buna ne dersin, Ben senin arkadaş canlısı akıl hocanım" dedim en iyi sesimle, "Yazdığın her kod satırını gelecekte biri için bir mesaj olarak düşün senin küçük kardeşin olabilecek biri. Bu akıllı kişiye bu zor problemin nasıl çözüleceğini yeniden açıklıyoruz. + +"Hayal etmek istediğiniz bu mu? Gelecekteki akıllı programcının kodunuzu görüp 'Vay! Bu harika! Burada ne yapıldığını çok iyi anlayabiliyorum ve ne kadar zarif bir şey olduğuna hayret ediyorum - hayır, bekle - bu ne güzel bir kod parçası. Ekibimdeki diğer insanlara göstereceğim. Bu bir başyapıt!' + +"Joe, bu zor sorunu çözen ama şarkı söyleyecek kadar güzel olacak bir kod yazabileceğini mi sanıyorsun? Evet, tıpkı akıldan çıkmayan bir melodi gibi. Sanırım senin çok zor çözümünü bulabilen herkes burada da yazabilir. güzel bir şey yaz. Hmm... Acaba güzellik üzerine derecelendirmeye başlamalı mıyım? Ne düşünüyorsun, Joe?" + +Joe işini aldı ve bana baktı, yüzünde küçük bir gülümseme belirdi. "Anladım, prof, dünyayı Phil için daha iyi hale getirmeye gidiyorum. Teşekkürler." + +[Linda Rising](http://programmer.97things.oreilly.com/wiki/index.php/Linda_Rising) Tarafından \ No newline at end of file From a2d8d02185359a7bec429db7a561392768c7a6c0 Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Mon, 28 Feb 2022 18:23:17 +0300 Subject: [PATCH 076/290] added thing_59 --- en/thing_47/README.md | 19 ---------------- tr/SUMMARY.md | 2 +- tr/thing_59/README.md | 51 +++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 52 insertions(+), 20 deletions(-) delete mode 100644 en/thing_47/README.md create mode 100644 tr/thing_59/README.md diff --git a/en/thing_47/README.md b/en/thing_47/README.md deleted file mode 100644 index f62c5d6c..00000000 --- a/en/thing_47/README.md +++ /dev/null @@ -1,19 +0,0 @@ -# Know Your Next Commit - -I tapped three programmers on their shoulders and asked what they were doing. "I am refactoring these methods," the first answered. "I am adding some parameters to this web action," the second answered. The third answered, "I am working on this user story." - -It might seem that the first two were engrossed in the details of their work while only the third could see the bigger picture, and that the latter had the better focus. However, when I asked when and what they would commit, the picture changed dramatically. The first two where pretty clear over what files would be involved and would be finished within an hour or so. The third programmer answered, "Oh, I guess I will be ready within a few days. I will probably add a few classes and might change those services in some way." - -The first two did not lack a vision of the overall goal. They had selected tasks they thought led in a productive direction, and could be finished within a couple of hours. Once they had finished those tasks, they would select a new feature or refactoring to work on. All the code written was thus done with a clear purpose and a limited, achievable goal in mind. - -The third programmer had not been able to decompose the problem and was working on all aspects at once. He had no idea of what it would take, basically doing speculative programming, hoping to arrive at some point where he would be able to commit. Most probably the code written at the start of this long session was poorly matched for the solution that came out in the end. - -What would the first two programmers do if their tasks took more than two hours? After realizing they had taken on too much, they would most likely throw away their changes, define smaller tasks, and start over. To keep working would have lacked focus and led to speculative code entering the repository. Instead, changes would be thrown away, but the insights kept. - -The third programmer might keep on guessing and desperately try to patch together his changes into something that could be committed. After all, you cannot throw away code changes you have done — that would be wasted work, wouldn't it? Unfortunately, not throwing the code away leads to slightly odd code that lacks a clear purpose entering the repository. - -At some point even the commit-focused programmers might fail to find something useful they thought could be finished in two hours. Then, they would go directly into speculative mode, playing around with the code and, of course, throwing away the changes whenever some insight led them back on track. Even these seemingly unstructured hacking sessions have purpose: to learn about the code to be able to define a task that would constitute a productive step. - -Know your next commit. If you cannot finish, throw away your changes, then define a new task you believe in with the insights you have gained. Do speculative experimentation whenever needed, but do not let yourself slip into speculative mode without noticing. Do not commit guesswork into your repository. - -By [Dan Bergh Johnsson](http://programmer.97things.oreilly.com/wiki/index.php/Dan_Bergh_Johnsson) \ No newline at end of file diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index 3eb4ea9d..7d8d2b45 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -59,7 +59,7 @@ 1. [Görünmezi Daha Görünür Hale Getirin](thing_56/README.md) 1. [Mesaj Geçişi, Paralel Sistemlerde Daha İyi Ölçeklenebilirlik Sağlar](thing_57/README.md) 1. [Geleceğe Mesaj](thing_58/README.md) -1. [Missing Opportunities for Polymorphism](thing_59/README.md) +1. [Polimorfizm için Kaçırılan Fırsatlar](thing_59/README.md) 1. [News of the Weird: Testers Are Your Friends](thing_60/README.md) 1. [One Binary](thing_61/README.md) 1. [Only the Code Tells the Truth](thing_62/README.md) diff --git a/tr/thing_59/README.md b/tr/thing_59/README.md new file mode 100644 index 00000000..e53443b5 --- /dev/null +++ b/tr/thing_59/README.md @@ -0,0 +1,51 @@ +# Polimorfizm için Kaçırılan Fırsatlar + +Polimorfizm, OO(Object Oriented) için temel olan büyük fikirlerden biridir. Yunancadan gelen sözcük, birçok (*poli*) biçim (*morf*) anlamına gelir. Programlama polimorfizmi bağlamında, belirli bir nesne veya yöntem sınıfının birçok biçimine atıfta bulunur. Ancak polimorfizm sadece alternatif uygulamalarla ilgili değildir. Dikkatli kullanıldığında, polimorfizm, ayrıntılı *if-then-else* bloklarına ihtiyaç duymadan çalışmamıza izin veren küçük yerelleştirilmiş yürütme bağlamları oluşturur. Bir bağlamda olmak, doğru şeyi doğrudan yapmamızı sağlarken, o bağlamın dışında olmak bizi onu yeniden inşa etmeye zorlar, böylece doğru şeyi yapabiliriz. Alternatif uygulamaların dikkatli kullanımıyla, daha okunaklı daha az kod üretmemize yardımcı olabilecek bağlamı yakalayabiliriz. Bu, aşağıdaki (gerçekçi olmayan) basit alışveriş sepeti gibi bazı kodlarla en iyi şekilde gösterilir: + +``` +public class ShoppingCart { + private ArrayList cart = new ArrayList(); + public void add(Item item) { cart.add(item); } + public Item takeNext() { return cart.remove(0); } + public boolean isEmpty() { return cart.isEmpty(); } +} +``` + +Diyelim ki web mağazamız indirilebilecek ürünler ve gönderilmesi gereken ürünler sunuyor. Bu işlemleri destekleyen başka bir nesne oluşturalım: + +``` +public class Shipping { + public boolean ship(Item item, SurfaceAddress address) { ... } + public boolean ship(Item item, EMailAddress address) { ... } +} +``` + +Bir müşteri ödemeyi tamamladığında malları göndermemiz gerekir: + +``` +while (!cart.isEmpty()) { + shipping.ship(cart.takeNext(), ???); +} +``` + +*???* parametresi yeni bir fantezi elvis operatörü değil, öğeyi e-postayla mı göndermeliyim yoksa salyangozla postalamalı mıyım? Bu soruyu cevaplamak için gereken bağlam artık mevcut değil. Sevkiyat yöntemini bir boolean veya enumda yakalayabilir ve ardından eksik parametreyi doldurmak için bir *if-then-else* kullanabilirdik. Başka bir çözüm, her ikisi de Öğeyi genişleten iki sınıf oluşturmak olacaktır. Bunları DownloadableItem ve SurfaceItem olarak adlandıralım. Şimdi biraz kod yazalım. Öğeyi tek bir yöntemi destekleyen bir arayüz olarak tanıtacağım, ship. Sepetin içeriğini göndermek için 'item.ship(shipper)' adını vereceğiz. "DownloadableItem" ve "SurfaceItem" sınıflarının her ikisi de ship'i uygulayacaktır. + +``` +public class DownloadableItem implements Item { + public boolean ship(Shipping shipper) { + shipper.ship(this, customer.getEmailAddress()); + } +} + +public class SurfaceItem implements Item { + public boolean ship(Shipping shipper) { + shipper.ship(this, customer.getSurfaceAddress()); + } +} +``` + +Bu örnekte, `Shipping` ile çalışma sorumluluğunu her bir Öğeye devrettik. Her ürün, en iyi nasıl gönderileceğini bildiğinden, bu düzenleme, bir *if-then-else*'e ihtiyaç duymadan ürünle devam etmemizi sağlar. Kod ayrıca, genellikle birlikte iyi çalışan iki kalıbın kullanımını da gösterir: Komut ve Çift Gönderim. Bu kalıpların etkin kullanımı, polimorfizmin dikkatli kullanımına bağlıdır. Bu olduğunda, kodumuzdaki *if-then-else* bloklarının sayısında bir azalma olacaktır. + +Polimorfizm yerine *if-then-else* kullanmanın çok daha pratik olduğu durumlar olsa da, daha çok polimorfik bir kodlama stilinin daha küçük, daha okunabilir ve daha az kırılgan bir kod tabanı sağlaması daha sık görülür. Kaçırılan fırsatların sayısı, kodumuzdaki *if-then-else* ifadelerinin basit bir sayımıdır. + +[Kirk Pepperdine](http://programmer.97things.oreilly.com/wiki/index.php/Kirk_Pepperdine) Tarafından From f2c35dc4452fde71e04a1ea91f8e39a4d81cead6 Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Mon, 28 Feb 2022 18:28:23 +0300 Subject: [PATCH 077/290] added thing_60 --- tr/SUMMARY.md | 2 +- tr/thing_60/README.md | 17 +++++++++++++++++ 2 files changed, 18 insertions(+), 1 deletion(-) create mode 100644 tr/thing_60/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index 7d8d2b45..656bfb96 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -60,7 +60,7 @@ 1. [Mesaj Geçişi, Paralel Sistemlerde Daha İyi Ölçeklenebilirlik Sağlar](thing_57/README.md) 1. [Geleceğe Mesaj](thing_58/README.md) 1. [Polimorfizm için Kaçırılan Fırsatlar](thing_59/README.md) -1. [News of the Weird: Testers Are Your Friends](thing_60/README.md) +1. [Tuhaf Haber: Testçiler Arkadaşlarınızdır](thing_60/README.md) 1. [One Binary](thing_61/README.md) 1. [Only the Code Tells the Truth](thing_62/README.md) 1. [Own (and Refactor) the Build](thing_63/README.md) diff --git a/tr/thing_60/README.md b/tr/thing_60/README.md new file mode 100644 index 00000000..d3a9132c --- /dev/null +++ b/tr/thing_60/README.md @@ -0,0 +1,17 @@ +# Tuhaf Haber: Testçiler Arkadaşlarınızdır + +Kendilerine *Kalite Güvencesi* veya *Kalite Kontrol* desinler, birçok programcı onlara *Sorun* der. Tecrübelerime göre, yazılımcılar genellikle yazılımlarını test eden insanlarla düşmanca bir ilişki içindedir. "Çok seçicidirler" ve "Her şeyin mükemmel olmasını isterler" yaygın şikayetlerdir. Tanıdık geliyor mu? + +Neden olduğundan emin değilim, ama her zaman testçiler hakkında farklı bir görüşüm oldu. Belki de ilk işimdeki "testçi" şirket sekreteri olduğu içindir. Margaret, ofisi çalışır durumda tutan ve birkaç genç yazılımcıya müşterilerin önünde nasıl profesyonelce davranmaları gerektiğini öğretmeye çalışan çok hoş bir kadındı. Ayrıca, ne kadar belirsiz olursa olsun, herhangi bir hatayı sadece anlarda bulma yeteneği vardı. + +O zamanlar kendisini programcı sanan bir muhasebecinin yazdığı bir program üzerinde çalışıyordum. Söylemeye gerek yok, bazı ciddi sorunları vardı. Bir parçamı düzelttiğimi düşündüğümde, Margaret onu kullanmaya çalışırdı ve çoğu zaman birkaç tuşa bastıktan sonra yeni bir şekilde başarısız olurdu. Bazen sinir bozucu ve utanç vericiydi, ama o kadar hoş bir insandı ki, beni kötü gösterdiği için onu suçlamayı hiç düşünmedim. Sonunda Margaret'in programı temiz bir şekilde başlatabildiği, bir fatura girebildiği, yazdırabildiği ve kapatabildiği gün geldi. Heyecanlıydım. Daha da iyisi, müşterimizin makinesine kurduğumuzda her şey işe yaradı. Hiçbir sorun görmediler çünkü Margaret önce onları bulup düzeltmeme yardım etmişti. + +Bu yüzden testçiler sizin arkadaşınızdır diyorum. Testçilerin önemsiz sorunları bildirerek sizi kötü gösterdiğini düşünebilirsiniz. Ancak müşteriler QC'nin düzeltmenizi sağladığı tüm bu "küçük şeyler" tarafından rahatsız edilmedikleri için heyecanlandıklarında harika görünürsünüz. Neyi kastettiğimi anla? + +Şunu hayal edin: Eşzamanlılık sorunlarını bulmak ve düzeltmek için "çığır açan yapay zeka algoritmaları" kullanan bir yardımcı programı test ediyorsunuz. Ateşlersiniz ve açılış ekranında "zeka"yı yanlış yazdıklarını hemen fark edersiniz. Biraz uğursuz, ama bu sadece bir yazım hatası, değil mi? Ardından, yapılandırma ekranının radyo düğmelerinin olması gereken yerlerde onay kutuları kullandığını ve bazı klavye kısayollarının çalışmadığını fark ettiniz. Şimdi, bunların hiçbiri önemli değil, ancak hatalar arttıkça programcıları merak etmeye başlıyorsunuz. Basit şeyleri doğru yapamıyorlarsa, AI'larının eşzamanlılık sorunları gibi zor bir şeyi gerçekten bulma ve düzeltme olasılığı nedir? + +Yapay zekayı delicesine harika yapmaya o kadar odaklanmış dahiler olabilirler ki, bu önemsiz şeyleri fark etmediler. Ve "seçkin testçiler" sorunları belirtmeden, onları bulmaya başladınız. Ve şimdi programcıların yetkinliğini sorguluyorsunuz. + +Kulağa ne kadar garip gelse de, kodunuzdaki her küçük hatayı ortaya çıkarmaya kararlı görünen bu testçiler gerçekten sizin arkadaşlarınızdır. + +[Burk Hufnagel](http://programmer.97things.oreilly.com/wiki/index.php/BurkHufnagel) Tarafından \ No newline at end of file From 6a6081ac820527ad4c0febb2bb08f2e2445b18d0 Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Mon, 28 Feb 2022 18:34:26 +0300 Subject: [PATCH 078/290] added thing_61 --- tr/SUMMARY.md | 2 +- tr/thing_61/README.md | 15 +++++++++++++++ 2 files changed, 16 insertions(+), 1 deletion(-) create mode 100644 tr/thing_61/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index 656bfb96..3229acbe 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -61,7 +61,7 @@ 1. [Geleceğe Mesaj](thing_58/README.md) 1. [Polimorfizm için Kaçırılan Fırsatlar](thing_59/README.md) 1. [Tuhaf Haber: Testçiler Arkadaşlarınızdır](thing_60/README.md) -1. [One Binary](thing_61/README.md) +1. [Tek İkili](thing_61/README.md) 1. [Only the Code Tells the Truth](thing_62/README.md) 1. [Own (and Refactor) the Build](thing_63/README.md) 1. [Pair Program and Feel the Flow](thing_64/README.md) diff --git a/tr/thing_61/README.md b/tr/thing_61/README.md new file mode 100644 index 00000000..159659cd --- /dev/null +++ b/tr/thing_61/README.md @@ -0,0 +1,15 @@ +# Tek İkili + +Yapının, her hedef ortam için özel bir ikili dosya oluşturmak üzere kodun bir bölümünü yeniden yazdığı birkaç proje gördüm. Bu her zaman işleri olması gerekenden daha karmaşık hale getirir ve ekibin her kurulumda tutarlı sürümlere sahip olmama riskini beraberinde getirir. Asgari olarak, her biri daha sonra doğru yere dağıtılması gereken, yazılımın birden çok, neredeyse aynı kopyasının oluşturulmasını içerir. Gerekenden daha fazla hareketli parça anlamına gelir, bu da hata yapmak için daha fazla fırsat anlamına gelir. + +Bir keresinde, her özellik değişikliğinin tam bir inşa döngüsü için kontrol edilmesi gereken bir ekipte çalıştım, bu yüzden testçiler küçük bir ayarlamaya ihtiyaç duyduklarında beklemeye bırakıldılar (inşa etmenin de çok uzun sürdüğünü söylemiş miydim?). Ayrıca sistem yöneticilerinin üretim için sıfırdan yeniden oluşturma konusunda ısrar ettiği bir ekipte de çalıştım (bizimle aynı komut dosyalarını kullanarak), bu da üretimdeki sürümün testten geçen sürüm olduğuna dair hiçbir kanıtımız olmadığı anlamına geliyordu. Ve bunun gibi. + +Kural basittir: *Yayın ardışık düzenindeki tüm aşamalarda tanımlayabileceğiniz ve tanıtabileceğiniz tek bir ikili dosya oluşturun.* Ortama özgü ayrıntıları ortamda tutun. Bu, örneğin bunları bileşen kapsayıcısında, bilinen bir dosyada veya yolda tutmak anlamına gelebilir. + +Ekibiniz bir kod yönetme yapısına sahipse veya tüm hedef ayarları kodla birlikte depoluyorsa, bu, hiç kimsenin tasarımı, uygulamanın özü olan ve platforma özgü özellikleri ayırmak için yeterince dikkatli düşünmediğini gösterir. Ya da daha kötüsü olabilir: Ekip ne yapacağını biliyor ama değişikliği yapma çabasına öncelik veremiyor. + +Elbette istisnalar vardır: Önemli ölçüde farklı kaynak kısıtlamalarına sahip hedefler için inşa ediyor olabilirsiniz, ancak bu, "veritabanını ekrana ve tekrar ekrana" yazan çoğumuz için geçerli değildir. Alternatif olarak, şu anda düzeltmesi çok zor olan bazı eski karışıklıklarla yaşıyor olabilirsiniz. Bu gibi durumlarda, kademeli olarak hareket etmeniz gerekir, ancak mümkün olan en kısa sürede başlayın. + +Ve bir şey daha: Ortam bilgilerini de sürümlü tutun. Bir ortam yapılandırmasını bozmak ve neyin değiştiğini bulamamak kadar kötü bir şey yoktur. Çevresel bilgiler, farklı oranlarda ve farklı nedenlerle değişeceğinden, koddan ayrı olarak versiyonlanmalıdır. Bazı ekipler bunun için dağıtılmış sürüm kontrol sistemleri kullanır (pazar ve git gibi), çünkü üretim ortamlarında yapılan değişiklikleri - kaçınılmaz olarak olduğu gibi - depoya geri göndermeyi kolaylaştırır. + +[Steve Freeman](http://programmer.97things.oreilly.com/wiki/index.php/Steve_Freeman) Tarafından \ No newline at end of file From e770b23e622dc0a4ba9ba3e8ed0224ba824a96cc Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Mon, 28 Feb 2022 18:39:36 +0300 Subject: [PATCH 079/290] added thing_62 --- tr/SUMMARY.md | 2 +- tr/thing_62/README.md | 13 +++++++++++++ 2 files changed, 14 insertions(+), 1 deletion(-) create mode 100644 tr/thing_62/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index 3229acbe..842e6e80 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -62,7 +62,7 @@ 1. [Polimorfizm için Kaçırılan Fırsatlar](thing_59/README.md) 1. [Tuhaf Haber: Testçiler Arkadaşlarınızdır](thing_60/README.md) 1. [Tek İkili](thing_61/README.md) -1. [Only the Code Tells the Truth](thing_62/README.md) +1. [Sadece Kod Gerçeği Söyler](thing_62/README.md) 1. [Own (and Refactor) the Build](thing_63/README.md) 1. [Pair Program and Feel the Flow](thing_64/README.md) 1. [Prefer Domain-Specific Types to Primitive Types](thing_65/README.md) diff --git a/tr/thing_62/README.md b/tr/thing_62/README.md new file mode 100644 index 00000000..d384f60d --- /dev/null +++ b/tr/thing_62/README.md @@ -0,0 +1,13 @@ +# Sadece Kod Gerçeği Söyler + +Bir programın nihai anlamı, çalışan kod tarafından verilir. Bu yalnızca ikili biçimdeyse, okunması zor olacaktır! Bununla birlikte, kaynak kodu sizin programınız, herhangi bir tipik ticari yazılım geliştirme, bir açık kaynak projesi veya dinamik olarak yorumlanan bir dilde kod ise mevcut olmalıdır. Kaynak koduna bakıldığında, programın anlamı açık olmalıdır. Bir programın ne yaptığını bilmek için, baktığınızdan emin olabileceğiniz tek şey kaynaktır. En doğru gereksinimler belgesi bile tüm gerçeği söylemez: Programın gerçekte ne yaptığının ayrıntılı öyküsünü içermez, yalnızca gereksinim analistinin üst düzey niyetlerini içerir. Bir tasarım belgesi, planlanmış bir tasarımı kapsayabilir, ancak uygulamanın gerekli ayrıntılarından yoksun olacaktır. Bu belgeler mevcut uygulama ile senkronizasyonu kaybedilmiş olabilir... veya basitçe kaybolmuş olabilir. Ya da hiç yazılmamış. Kaynak kodu kalan tek şey olabilir. + +Bunu akılda tutarak, kodunuz size veya başka bir programcıya ne yaptığını ne kadar net bir şekilde söylediğini kendinize sorun? + +"Ah, yorumlarım size bilmeniz gereken her şeyi anlatacak" diyebilirsiniz. Ancak yorumların kod çalıştırmadığını unutmayın. Diğer belgeleme biçimleri kadar yanlış olabilirler. Yorumların koşulsuz olarak iyi bir şey olduğunu söyleyen bir gelenek vardır, bu yüzden şüphesiz bazı programcılar daha fazla yorum yazar, hatta kodda zaten açık olan önemsiz şeyleri yeniden ifade edip açıklar. Bu, kodunuzu netleştirmenin yanlış yolu. Kodunuzun yoruma ihtiyacı varsa, olmaması için yeniden düzenlemeyi düşünün. Uzun yorumlar ekran alanını karıştırabilir ve hatta IDE'niz tarafından otomatik olarak gizlenebilir. Bir değişikliği açıklamanız gerekiyorsa, bunu kodda değil sürüm kontrol sistemi giriş mesajında yapın. + +Kodunuzun gerçeği olabildiğince açık bir şekilde söylemesini sağlamak için ne yapabilirsiniz? İyi isimler için çabalayın. Kodunuzu, adlandırmayı da kolaylaştıran uyumlu işlevselliğe göre yapılandırın. Ortogonallik elde etmek için kodunuzu ayırın. Amaçlanan davranışı açıklayan otomatik testler yazın ve arayüzleri kontrol edin. Daha basit ve daha iyi bir çözümü nasıl kodlayacağınızı öğrendiğinizde acımasızca yeniden düzenleme yapın. Kodunuzu okunması ve anlaşılması için mümkün olduğunca basit hale getirin. + +Kodunuza şiir, deneme, herkese açık bir blog veya önemli bir e-posta gibi diğer kompozisyonlar gibi davranın. İfade ettiğiniz şeyi dikkatli bir şekilde oluşturun, böylece yapması gerekeni yapsın ve ne yaptığını mümkün olduğunca doğrudan iletsin, böylece artık etrafta olmadığınızda niyetinizi iletmeye devam etsin. Kullanışlı kodun her zamankinden çok daha uzun süre kullanıldığını unutmayın. Bakım programcıları size teşekkür edecek. Ve bir bakım programcısıysanız ve üzerinde çalıştığınız kod doğruyu kolayca söylemiyorsa, yukarıdaki yönergeleri proaktif bir şekilde uygulayın. Kodda biraz akıl sağlığı oluşturun ve kendi akıl sağlığınızı koruyun. + +[Peter Sommerlad](http://programmer.97things.oreilly.com/wiki/index.php/Peter_Sommerlad) Tarafından \ No newline at end of file From d72f55d7bb13e13625b114c655972b290dd1bd65 Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Mon, 28 Feb 2022 18:52:31 +0300 Subject: [PATCH 080/290] added thing_63 --- tr/SUMMARY.md | 2 +- tr/thing_63/README.md | 15 +++++++++++++++ 2 files changed, 16 insertions(+), 1 deletion(-) create mode 100644 tr/thing_63/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index 842e6e80..e4f134ca 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -63,7 +63,7 @@ 1. [Tuhaf Haber: Testçiler Arkadaşlarınızdır](thing_60/README.md) 1. [Tek İkili](thing_61/README.md) 1. [Sadece Kod Gerçeği Söyler](thing_62/README.md) -1. [Own (and Refactor) the Build](thing_63/README.md) +1. [# Yapıya Sahip Olun (ve Yeniden Düzenleyin)](thing_63/README.md) 1. [Pair Program and Feel the Flow](thing_64/README.md) 1. [Prefer Domain-Specific Types to Primitive Types](thing_65/README.md) 1. [Prevent Errors](thing_66/README.md) diff --git a/tr/thing_63/README.md b/tr/thing_63/README.md new file mode 100644 index 00000000..a57a4a81 --- /dev/null +++ b/tr/thing_63/README.md @@ -0,0 +1,15 @@ +# Yapıya Sahip Olun (ve Yeniden Düzenleyin) + +It is not uncommon for teams that are otherwise highly disciplined about coding practices to neglect build scripts, either out of a belief that they are merely an unimportant detail or from a fear that they are complex and need to be tended to by the cult of release engineering. Unmaintainable build scripts with duplication and errors cause problems of the same magnitude as those in poorly factored code. + +Kodlama uygulamaları konusunda son derece disiplinli olan ekiplerin, bunların yalnızca önemsiz bir ayrıntı oldukları inancıyla veya karmaşık oldukları ve serbest bırakma mühendislik kültü tarafından yönlendirilmeleri gerektiği korkusuyla komut dosyalarını oluşturmayı ihmal etmeleri nadir görülen bir durum değildir. Yinelenen ve hatalar içeren sürdürülemez yapı komut dosyaları, kötü çarpanlara ayrılmış koddakilerle aynı büyüklükte sorunlara neden olur. + +Yanlış deyimler kullanılarak yazılmış derleme komut dosyalarının bakımı ve daha da önemlisi iyileştirmesi zordur. Bir değişiklik yapmanın doğru yolunu anlamak için biraz zaman ayırmaya değer. Bir uygulama bir bağımlılığın yanlış sürümüyle oluşturulduğunda veya derleme zamanı yapılandırması yanlış olduğunda hatalar görünebilir. + +Geleneksel olarak test etme, her zaman "Kalite Güvencesi" ekibine bırakılan bir şey olmuştur. Artık, kod yazarken test etmenin, değeri tahmin edilebilir bir şekilde sunabilmek için gerekli olduğunun farkındayız. Aynı şekilde, oluşturma sürecinin geliştirme ekibine ait olması gerekir. + +Yapıyı anlamak, tüm geliştirme yaşam döngüsünü basitleştirebilir ve maliyetleri azaltabilir. Yürütülmesi kolay bir yapı, yeni bir geliştiricinin hızlı ve kolay bir şekilde başlamasına olanak tanır. Yapıdaki yapılandırmayı otomatikleştirmek, birden fazla kişi bir proje üzerinde çalışırken tutarlı sonuçlar elde etmenizi sağlayabilir ve "benim için çalışıyor" konuşmasından kaçınabilir. Birçok derleme aracı, kod kalitesiyle ilgili raporlar çalıştırmanıza izin vererek olası sorunları erkenden algılamanıza olanak tanır. Yapıyı nasıl kendinize ait yapacağınızı anlamak için zaman harcayarak kendinize ve ekibinizdeki diğer herkese yardımcı olabilirsiniz. Kodlama özelliklerine odaklanabilir, paydaşlarınıza fayda sağlayabilir ve çalışmayı daha keyifli hale getirebilirsiniz. + +Ne zaman ve nasıl değişiklik yapacağınızı bilmek için oluşturma sürecinizi yeterince öğrenin. Derleme komut dosyaları koddur. Uygulama inşa edilene kadar tamamlanmadığı için başka bir nedenden dolayı başka birine bırakılamayacak kadar önemlidirler. Çalışan yazılımı teslim edene kadar programlama işi tamamlanmış sayılmaz. + +[Steve Berczuk](http://programmer.97things.oreilly.com/wiki/index.php/Steve_Berczuk) Tarafından \ No newline at end of file From e95b778002e6cd0134f83c5feab1faedcefebca7 Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Thu, 3 Mar 2022 18:31:45 +0300 Subject: [PATCH 081/290] added thing_64 --- tr/SUMMARY.md | 4 ++-- tr/thing_64/README.md | 25 +++++++++++++++++++++++++ 2 files changed, 27 insertions(+), 2 deletions(-) create mode 100644 tr/thing_64/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index e4f134ca..24a2da73 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -63,8 +63,8 @@ 1. [Tuhaf Haber: Testçiler Arkadaşlarınızdır](thing_60/README.md) 1. [Tek İkili](thing_61/README.md) 1. [Sadece Kod Gerçeği Söyler](thing_62/README.md) -1. [# Yapıya Sahip Olun (ve Yeniden Düzenleyin)](thing_63/README.md) -1. [Pair Program and Feel the Flow](thing_64/README.md) +1. [Yapıya Sahip Olun (ve Yeniden Düzenleyin)](thing_63/README.md) +1. [Programı Eşleştirin ve Akışı Hissedin](thing_64/README.md) 1. [Prefer Domain-Specific Types to Primitive Types](thing_65/README.md) 1. [Prevent Errors](thing_66/README.md) 1. [The Professional Programmer](thing_67/README.md) diff --git a/tr/thing_64/README.md b/tr/thing_64/README.md new file mode 100644 index 00000000..0131d9f5 --- /dev/null +++ b/tr/thing_64/README.md @@ -0,0 +1,25 @@ +# Programı Eşleştirin ve Akışı Hissedin + +Yaptığınız şeye tamamen odaklandığınızı, adanmış olduğunuzu ve dahil olduğunuzu hayal edin. Zaman kavramını kaybetmiş olabilirsiniz. Muhtemelen mutlu hissediyorsun. Akış yaşıyorsun. Kolayca bozabilecek çok sayıda kesinti, etkileşim ve diğer dikkat dağıtıcı unsurlar olduğundan, tüm bir geliştirici ekibi için hem akışı sağlamak hem de sürdürmek zordur. + +Eşli programlamayı zaten uyguladıysanız, eşleştirmenin akışa nasıl katkıda bulunduğunu muhtemelen biliyorsunuzdur. Eğer yapmadıysanız, hemen şimdi başlamanız için sizi motive etmek için deneyimlerimizi kullanmak istiyoruz! Eşli programlamada başarılı olmak için hem bireysel ekip üyeleri hem de bir bütün olarak ekip biraz çaba sarf etmelidir. + +Bir ekip üyesi olarak, sizden daha az deneyimli geliştiricilere karşı sabırlı olun. Daha yetenekli geliştiriciler tarafından sindirilme konusundaki korkularınızla yüzleşin. İnsanların farklı olduğunu anlayın ve buna değer verin. Kendi güçlü ve zayıf yönlerinizin yanı sıra diğer ekip üyelerinin de farkında olun. Meslektaşlarınızdan ne kadar öğrenebileceğinize şaşırabilirsiniz. + +Ekip olarak, proje boyunca beceri ve bilginin dağıtımını teşvik etmek için ikili programlamayı tanıtın. Görevlerinizi çiftler halinde çözmeli, ikili ve görevleri sık sık değiştirmelisiniz. Bir rotasyon kuralı üzerinde anlaşın. Kuralı bir kenara koyun veya gerektiğinde ayarlayın. Deneyimlerimiz, bir görevi başka bir çifte döndürmeden önce tamamlamanız gerekmediğidir. Bir görevi başka bir çifte iletmek için kesintiye uğratmak mantıksız gelebilir, ancak işe yaradığını gördük. + +Akışın kesintiye uğrayabileceği, ancak ikili programlamanın akışı korumanıza yardımcı olduğu çok sayıda durum vardır: + +- **"Kamyon faktörünü" azaltın:** Bu biraz hastalıklı bir düşünce deneyi, ancak ekip nihai teslimatı tamamlayamaz hale gelmeden önce kaç ekip üyenize bir kamyon çarpması gerekir? Başka bir deyişle, teslimatınız belirli ekip üyelerine ne kadar bağımlı? Bilgi ayrıcalıklı mıdır yoksa paylaşılır mı? Görevleri çiftler arasında döndürüyorsanız, her zaman bilgiye sahip ve işi tamamlayabilecek başka biri vardır. Takımınızın akışı "kamyon faktöründen" etkilenmez. + +- **Sorunları etkili bir şekilde çözün:** Eşli programlama yapıyorsanız ve zorlu bir sorunla karşılaşırsanız, her zaman tartışabileceğiniz birileri vardır. Bu tür bir diyalog, kendi başınıza sıkışıp kalmanıza kıyasla olasılıkları açma olasılığı daha yüksektir. İş değiştikçe, çözümünüz bir sonraki çift tarafından yeniden gözden geçirilecek ve yeniden değerlendirilecektir, bu nedenle başlangıçta en uygun çözümü seçmemiş olmanız önemli değildir. + +- **Sorunsuz bir şekilde entegre edin:** Mevcut göreviniz başka bir kod parçasını çağırmayı içeriyorsa, yöntemlerin, belgelerin ve testlerin adlarının size ne yaptığına dair bir fikir verecek kadar açıklayıcı olmasını umarsınız. Değilse, o kodu yazmaya dahil olmuş bir geliştiriciyle eşleştirmek size daha iyi bir genel bakış ve kendi kodunuzla daha hızlı entegrasyon sağlayacaktır. Ek olarak, tartışmayı adlandırmayı, belgeleri ve testleri geliştirmek için bir fırsat olarak kullanabilirsiniz. + +- **Kesintileri azaltın:** Biri size bir soru sormak için gelirse veya telefonunuz çalarsa veya acil bir e-postayı yanıtlamanız veya bir toplantıya katılmanız gerekiyorsa, eşli programlama ortağınız kodlamaya devam edebilir. Döndüğünüzde partneriniz hala akıştadır ve çabucak yetişip onlara tekrar katılacaksınız. + +- **Yeni ekip üyelerini hızlı bir şekilde hızlandırın:** Çift programlama ve eşlerin ve görevlerin uygun rotasyonu ile yeni gelenler hem kodu hem de diğer ekip üyelerini hızla tanır. + +Akış sizi inanılmaz derecede üretken kılar. Ama aynı zamanda savunmasızdır. Onu elde etmek için elinizden geleni yapın ve onu elde ettiğinizde ona tutunun! + +[Gudny Hauknes](http://programmer.97things.oreilly.com/wiki/index.php/Gudny_Hauknes), [Ann Katrin Gagnat](http://programmer.97things.oreilly.com/wiki/index.php/Ann_Katrin_Gagnat) ve Kari Røssland Tarafından \ No newline at end of file From 5c182096bfce3a06a94432e3cfaae1e32891aa70 Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Thu, 3 Mar 2022 18:36:45 +0300 Subject: [PATCH 082/290] added thing_65 --- tr/SUMMARY.md | 2 +- tr/thing_65/README.md | 31 +++++++++++++++++++++++++++++++ 2 files changed, 32 insertions(+), 1 deletion(-) create mode 100644 tr/thing_65/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index 24a2da73..796d9531 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -65,7 +65,7 @@ 1. [Sadece Kod Gerçeği Söyler](thing_62/README.md) 1. [Yapıya Sahip Olun (ve Yeniden Düzenleyin)](thing_63/README.md) 1. [Programı Eşleştirin ve Akışı Hissedin](thing_64/README.md) -1. [Prefer Domain-Specific Types to Primitive Types](thing_65/README.md) +1. [Domain Alanına Özgü Türleri İlkel Türlere Tercih Edin](thing_65/README.md) 1. [Prevent Errors](thing_66/README.md) 1. [The Professional Programmer](thing_67/README.md) 1. [Put Everything Under Version Control](thing_68/README.md) diff --git a/tr/thing_65/README.md b/tr/thing_65/README.md new file mode 100644 index 00000000..dfadba62 --- /dev/null +++ b/tr/thing_65/README.md @@ -0,0 +1,31 @@ +# Domain Alanına Özgü Türleri İlkel Türlere Tercih Edin + +23 Eylül 1999'da 327,6 milyon dolarlık Mars Climate Orbiter, Dünya'daki bir yazılım hatası nedeniyle Mars'ın yörüngesine girerken kayboldu. Hata daha sonra *metrik karışıklık* olarak adlandırıldı. Uzay aracı Newton'u beklerken yer istasyonu yazılımı pound cinsinden çalışıyordu ve yer istasyonunun uzay aracının iticilerinin gücünü 4,45 kat hafife almasına yol açtı. + +Bu, daha güçlü ve alana özgü yazma uygulanmış olsaydı önlenebilecek birçok yazılım hatası örneğinden biridir. Aynı zamanda, birincil tasarım hedeflerinden biri gömülü güvenlik açısından kritik yazılımı uygulamak olan Ada dilindeki birçok özelliğin ardındaki mantığın bir örneğidir. Ada, hem ilkel türler hem de kullanıcı tanımlı türler için statik denetime sahip güçlü yazmaya sahiptir: + +``` +type Velocity_In_Knots is new Float range 0.0 .. 500.00; + +type Distance_In_Nautical_Miles is new Float range 0.0 .. 3000.00; + +Velocity: Velocity_In_Knots; + +Distance: Distance_In_Nautical_Miles; + +Some_Number: Float; + +Some_Number:= Distance + Velocity; -- Will be caught by the compiler as a type error. +``` + +Daha az talepkar etki alanlarındaki geliştiriciler, aksi takdirde dil tarafından sunulan ilkel veri türlerini ve dizeler ve kayan noktalar gibi kitaplıklarını kullanmaya devam edebilecekleri daha fazla alana özgü yazma uygulamasından da yararlanabilir. Java, C++, Python ve diğer modern dillerde soyut veri türü sınıf olarak bilinir. `Velocity_In_Knots` ve `Distance_In_Nautical_Miles` gibi sınıfların kullanılması, kod kalitesine göre çok fazla değer katar: + +1. Kod, yalnızca Float veya String değil, bir etki alanı kavramlarını ifade ettiği için daha okunabilir hale gelir. +- Kod, kolayca test edilebilir davranışı içine aldığından, kod daha test edilebilir hale gelir. +- Kod, uygulamalar ve sistemler arasında yeniden kullanımı kolaylaştırır. + +Yaklaşım, hem statik hem de dinamik olarak yazılan dillerin kullanıcıları için eşit derecede geçerlidir. Tek fark, statik olarak yazılan dilleri kullanan geliştiricilerin derleyiciden biraz yardım alırken, dinamik olarak yazılan dilleri benimseyenlerin birim testlerine güvenme olasılıklarının daha yüksek olmasıdır. Kontrol tarzı farklı olabilir, ancak motivasyon ve ifade tarzı değildir. + +Buradaki ahlak, kaliteli yazılım geliştirmek amacıyla alana özgü türleri keşfetmeye başlamaktır. + +[Einar Landre](http://programmer.97things.oreilly.com/wiki/index.php/Einar_Landre) Tarafından \ No newline at end of file From bb18169dd1effdafcaf8a99b4ac5eb262ee71c0d Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Thu, 3 Mar 2022 18:40:37 +0300 Subject: [PATCH 083/290] added thing_66 --- tr/SUMMARY.md | 2 +- tr/thing_66/README.md | 27 +++++++++++++++++++++++++++ 2 files changed, 28 insertions(+), 1 deletion(-) create mode 100644 tr/thing_66/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index 796d9531..2a05c861 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -66,7 +66,7 @@ 1. [Yapıya Sahip Olun (ve Yeniden Düzenleyin)](thing_63/README.md) 1. [Programı Eşleştirin ve Akışı Hissedin](thing_64/README.md) 1. [Domain Alanına Özgü Türleri İlkel Türlere Tercih Edin](thing_65/README.md) -1. [Prevent Errors](thing_66/README.md) +1. [Hataları Önle](thing_66/README.md) 1. [The Professional Programmer](thing_67/README.md) 1. [Put Everything Under Version Control](thing_68/README.md) 1. [Put the Mouse Down and Step Away from the Keyboard](thing_69/README.md) diff --git a/tr/thing_66/README.md b/tr/thing_66/README.md new file mode 100644 index 00000000..6100ba57 --- /dev/null +++ b/tr/thing_66/README.md @@ -0,0 +1,27 @@ +# Hataları Önle + +Hata mesajları, kullanıcı ile sistemin geri kalanı arasındaki en kritik etkileşimlerdir. Kullanıcı ve sistem arasındaki iletişim kopma noktasına yaklaştığında meydana gelirler. + +Bir hatanın kullanıcıdan gelen yanlış bir girdiden kaynaklandığını düşünmek kolaydır. Ancak insanlar tahmin edilebilir, sistematik yollarla hata yaparlar. Böylece, tıpkı diğer sistem bileşenleri arasında yaptığınız gibi, kullanıcı ile sistemin geri kalanı arasındaki iletişimi 'hata ayıklamak' mümkündür. + +Örneğin, kullanıcının izin verilen bir aralık içinde bir tarih girmesini istediğinizi varsayalım. Kullanıcının herhangi bir tarih girmesine izin vermek yerine, yalnızca izin verilen tarihleri ​​gösteren liste veya takvim gibi bir cihaz sunmak daha iyidir. Bu, kullanıcının aralığın dışında bir tarih girme olasılığını ortadan kaldırır. + +Biçimlendirme hataları başka bir yaygın sorundur. Örneğin, bir kullanıcıya bir Tarih metin alanı sunulur ve "29 Temmuz 2012" gibi açık bir tarih girerse, tercih edilen bir biçimde olmadığı için ("GG/AA/YYYY" gibi) reddetmesi mantıksızdır. "). Fazladan boşluklar içerdiğinden "29 / 07 / 2012"yi reddetmek daha da kötüdür. Bu tür bir sorunu, tarih istenen biçimde göründüğü için özellikle kullanıcıların anlaması zordur. + +Bu hata, tarihi reddetmenin en yaygın üç veya dört tarih biçimini ayrıştırmaktan daha kolay olması nedeniyle oluşur. Bu tür küçük hatalar kullanıcının hayal kırıklığına uğramasına neden olur ve bu da kullanıcı konsantrasyonunu kaybettiği için ek hatalara yol açar. Bunun yerine, kullanıcıların veri değil bilgi girme tercihine saygı gösterin. + +Biçimlendirme hatalarından kaçınmanın bir başka yolu da ipuçları sunmaktır - örneğin, alan içinde istenen biçimi ("GG/AA/YYYY") gösteren bir etiketle. Başka bir ipucu, alanı iki, iki ve dört karakterden oluşan üç metin kutusuna bölmek olabilir. + +İpuçları talimatlardan farklıdır: İpuçları ipucu olma eğilimindedir; talimatlar ayrıntılıdır. Etkileşim noktasında ipuçları oluşur; talimatlar etkileşim noktasından önce görünür. İpuçları bağlam sağlar; talimatlar kullanımı belirler. + +Genel olarak, talimatlar hatayı önlemede etkisizdir. Kullanıcılar, arayüzlerin geçmiş deneyimlerine göre çalışacağını varsayma eğilimindedir ("29 Temmuz 2012"nin ne anlama geldiğini elbette herkes biliyor mu?"). Böylece talimatlar okunmaz. İpuçları, kullanıcıları hatalardan uzaklaştırır. + +Hatalardan kaçınmanın başka bir yolu da varsayılanlar sunmaktır. Örneğin, kullanıcılar genellikle *bugün*, *yarın*, *doğum günüm*, *son teslim tarihim* veya *bu formu en son kullandığımda girdiğim tarihe* karşılık gelen değerleri girerler. Bağlama bağlı olarak, bunlardan birinin akıllı varsayılan olarak iyi bir seçim olması muhtemeldir. + +Sebep ne olursa olsun, sistemler hatalara karşı toleranslı olmalıdır. Bunu, tüm eylemlere ve özellikle de kullanıcıların verilerini yok etme veya değiştirme potansiyeline sahip eylemlere birden fazla *geri alma* düzeyi sağlayarak yapabilirsiniz. + +*Geri al* eylemlerinin günlüğe kaydedilmesi ve analiz edilmesi, arayüzün kullanıcıları sürekli olarak 'yanlış' düğmeye tıklamak gibi bilinçsiz hatalara çektiği yerleri de vurgulayabilir. Bu hatalara genellikle, daha fazla hatayı önlemek için yeniden tasarlayabileceğiniz yanıltıcı ipuçları veya etkileşim dizileri neden olur. + +Hangi yaklaşımı seçerseniz seçin, hataların çoğu sistematiktir - kullanıcı ile yazılım arasındaki yanlış anlamaların sonucudur. Kullanıcıların nasıl düşündüğünü, bilgiyi nasıl yorumladığını, karar verdiğini ve veri girdisini anlamak, yazılımınız ve kullanıcılarınız arasındaki etkileşimlerde hata ayıklamanıza yardımcı olacaktır. + +[Giles Colborne](http://programmer.97things.oreilly.com/wiki/index.php/Giles_Colborne) Tarafından \ No newline at end of file From 6e0d69b789cb98f4648fac33b13286e88639e450 Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Mon, 7 Mar 2022 18:12:27 +0300 Subject: [PATCH 084/290] added thing_67 --- tr/SUMMARY.md | 2 +- tr/thing_67/README.md | 19 +++++++++++++++++++ 2 files changed, 20 insertions(+), 1 deletion(-) create mode 100644 tr/thing_67/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index 2a05c861..9b61da03 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -67,7 +67,7 @@ 1. [Programı Eşleştirin ve Akışı Hissedin](thing_64/README.md) 1. [Domain Alanına Özgü Türleri İlkel Türlere Tercih Edin](thing_65/README.md) 1. [Hataları Önle](thing_66/README.md) -1. [The Professional Programmer](thing_67/README.md) +1. [Profesyonel Yazılımcı](thing_67/README.md) 1. [Put Everything Under Version Control](thing_68/README.md) 1. [Put the Mouse Down and Step Away from the Keyboard](thing_69/README.md) 1. [Read Code](thing_70/README.md) diff --git a/tr/thing_67/README.md b/tr/thing_67/README.md new file mode 100644 index 00000000..819c6c44 --- /dev/null +++ b/tr/thing_67/README.md @@ -0,0 +1,19 @@ +# Profesyonel Yazılımcı + +Profesyonel yazılımcı nedir? + +Profesyonel bir yazılımcının en önemli özelliği *kişisel sorumluluktur*. Profesyonel yazılımcılar kariyerleri, tahminleri, program taahhütleri, hataları ve işçilikleri için sorumluluk alırlar. Profesyonel bir yazılımcı bu sorumluluğu başkalarına devretmez. + +- Eğer bir profesyonelseniz, o zaman kendi kariyerinizden *siz* sorumlusunuz. *Siz* okumaktan ve öğrenmekten sorumlusunuz. Sektör ve teknoloji ile güncel kalmaktan siz sorumlusunuz. Çok fazla yazılımcı, onları eğitmenin işverenlerinin işi olduğunu düşünüyor. Üzgünüm, bu tamamen yanlış. Sizce doktorlar böyle mi davranıyor? Sizce avukatlar böyle mi davranır? Hayır, kendilerini kendi zamanlarına ve kendi nikellerine göre eğitirler. Mesai dışındaki zamanlarının çoğunu günlükleri ve kararları okuyarak geçirirler. Kendilerini güncel tutuyorlar. Biz de öyle yapmalıyız. Sizinle işvereniniz arasındaki ilişki, iş sözleşmenizde güzel bir şekilde belirtilmiştir. Kısacası: Size ödeme yapacaklarına söz veriyorlar ve siz de iyi bir iş çıkaracağınıza söz veriyorsunuz. + +- Profesyoneller yazdıkları kodun sorumluluğunu alırlar. Çalıştığını bilmedikleri sürece kod yayınlamazlar. Bunu bir dakikalığına düşün. Emin olmadığınız bir kodu yayınlamaya istekliyseniz, kendinizi nasıl bir profesyonel olarak kabul edebilirsiniz? Profesyonel yazılımcılar QA'nın *hiçbir şey* bulmasını beklerler çünkü *kodlarını tamamen test edene kadar yayınlamazlar*. Elbette QA bazı problemler bulacaktır çünkü kimse mükemmel değildir. Ancak profesyoneller olarak tavrımız, QA'nın bulması için hiçbir şey bırakmamak olmalıdır. + +- Profesyoneller takım oyuncularıdır. Sadece kendi çalışmalarının değil, tüm ekibin çıktısının sorumluluğunu alırlar. Birbirlerine yardım ederler, birbirlerine öğretirler, birbirlerinden öğrenirler ve hatta gerektiğinde birbirlerini korurlar. Bir takım arkadaşı düştüğünde, diğerleri bir gün korunmaya ihtiyaç duyacaklarını bilerek devreye girer. + +- Profesyoneller büyük hata listelerine tolerans göstermezler. Büyük bir hata listesi özensiz. Sorun izleme veritabanında binlerce sorunu olan sistemler dikkatsizliğin trajedileridir. Gerçekten de, çoğu projede bir sorun takip sistemine duyulan ihtiyaç, dikkatsizliğin bir belirtisidir. Yalnızca en büyük sistemlerin hata listeleri o kadar uzun olmalıdır ki, bunları yönetmek için otomasyon gerekir. + +- Profesyoneller ortalığı karıştırmazlar. İşçiliklerinden gurur duyarlar. Kodlarını temiz, iyi yapılandırılmış ve okunması kolay tutarlar. Üzerinde anlaşmaya varılan standartları ve en iyi uygulamaları takip ederler. Asla, *asla* acele etmezler. Bir doktorun *sizin* üzerinde açık kalp ameliyatı yapmasını izlerken beden dışı bir deneyim yaşadığınızı hayal edin. Bu doktorun bir *son tarihi* var (gerçek anlamda). Kalp-akciğer baypas makinesi kan hücrelerinden çok fazlasına zarar vermeden işini bitirmeli. Nasıl davranmasını istiyorsun? Tipik bir yazılım geliştiricisi gibi davranmasını, acele etmesini ve ortalığı karıştırmasını mı istiyorsunuz? "Geri dönüp bunu daha sonra düzelteceğim" demesini mi istiyorsunuz? Yoksa disiplinlerine dikkatle bağlı kalmasını, zamanını ayırmasını, yaklaşımının makul olarak alabileceği en iyi yaklaşım olduğundan emin olmasını mı istiyorsunuz? Karışıklık mı istiyorsunuz yoksa profesyonellik mi? + +Profesyoneller sorumludur. Kendi kariyerleri için sorumluluk alırlar. Kodlarının düzgün çalıştığından emin olmak için sorumluluk alırlar. İşçiliklerinin kalitesi için sorumluluk alırlar. Son teslim tarihleri yaklaştığında ilkelerinden vazgeçmezler. Gerçekten de, baskı arttığında, profesyoneller doğru olduğunu bildikleri disiplinlere daha da sıkı sarılırlar. + +[Uncle Bob](http://programmer.97things.oreilly.com/wiki/index.php/Uncle_Bob) Tarafından \ No newline at end of file From f21ee03ebb073509db21cc28e8861f939d0209b5 Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Mon, 7 Mar 2022 18:22:40 +0300 Subject: [PATCH 085/290] added thing_68 --- tr/SUMMARY.md | 2 +- tr/thing_68/README.md | 17 +++++++++++++++++ 2 files changed, 18 insertions(+), 1 deletion(-) create mode 100644 tr/thing_68/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index 9b61da03..e86829b4 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -68,7 +68,7 @@ 1. [Domain Alanına Özgü Türleri İlkel Türlere Tercih Edin](thing_65/README.md) 1. [Hataları Önle](thing_66/README.md) 1. [Profesyonel Yazılımcı](thing_67/README.md) -1. [Put Everything Under Version Control](thing_68/README.md) +1. [Her Şeyi Sürüm Kontrolü Altına Alın](thing_68/README.md) 1. [Put the Mouse Down and Step Away from the Keyboard](thing_69/README.md) 1. [Read Code](thing_70/README.md) 1. [Read the Humanities](thing_71/README.md) diff --git a/tr/thing_68/README.md b/tr/thing_68/README.md new file mode 100644 index 00000000..263a240f --- /dev/null +++ b/tr/thing_68/README.md @@ -0,0 +1,17 @@ +# Her Şeyi Sürüm Kontrolü Altına Alın + +Tüm projelerinizdeki her şeyi sürüm kontrolü altına alın. İhtiyacınız olan kaynaklar burada: Subversion, Git, Mercurial ve CVS gibi ücretsiz araçlar; bol disk alanı; ucuz ve güçlü sunucular; her yerde ağ; ve hatta proje barındırma hizmetleri. Sürüm kontrol yazılımını kurduktan sonra, çalışmanızı onun deposuna koymak için ihtiyacınız olan tek şey, kodunuzu içeren temiz bir dizinde uygun komutu vermektir. Ve öğrenilecek yalnızca iki yeni temel işlem var: kod değişikliklerinizi depoya *commit* ve projenin çalışma sürümünü deponun sürümüyle güncelliyorsunuz. + +Projeniz sürüm kontrolü altında olduğunda, geçmişini açıkça takip edebilir, kimin hangi kodu yazdığını görebilir ve benzersiz bir tanımlayıcı aracılığıyla bir dosyaya veya proje sürümüne başvurabilirsiniz. Daha da önemlisi, korkmadan cesur kod değişiklikleri yapabilirsiniz. Eski sürüm depoda güvenli bir şekilde bulunduğundan, gelecekte ihtiyaç duymanız durumunda artık yorumlanmış kod yok. Gelecekte müşterinizin çalıştırdığı yazılımın tam sürümünü kolayca yeniden ziyaret edebilmeniz için bir yazılım sürümünü sembolik bir adla etiketleyebilirsiniz (ve gerekir). Paralel geliştirme dalları oluşturabilirsiniz: Çoğu projede etkin bir geliştirme dalı ve yayınlanmış sürümler için aktif olarak desteklenen bir veya daha fazla bakım dalı bulunur. + +Sürüm kontrol sistemi, geliştiriciler arasındaki sürtüşmeyi en aza indirir. Programcılar bağımsız yazılım parçaları üzerinde çalıştıklarında, bunlar neredeyse sihirle bütünleşir. Birbirlerinin ayağına bastıklarında sistem bunu fark eder ve çatışmaları çözmelerine izin verir. Bazı ek kurulumlarla sistem, projenin ilerleyişi hakkında ortak bir anlayış oluşturarak, taahhüt edilen her değişiklik için tüm geliştiricileri bilgilendirebilir. + +Projenizi kurarken cimri olmayın: projenin *tüm* varlıklarını sürüm kontrolü altına alın. Kaynak kodun yanı sıra belgeleri, araçları, derleme komut dosyalarını, test senaryolarını, çizimleri ve hatta kitaplıkları dahil edin. Projenin tamamı (düzenli olarak yedeklenen) depoya güvenli bir şekilde yerleştirildiğinde, disk veya verilerinizi kaybetmenin zararı en aza indirilir. Geliştirme için yeni bir makine kurmak, projeyi depodan kontrol etmeyi içerir. Bu, kodun farklı platformlarda dağıtılmasını, oluşturulmasını ve test edilmesini kolaylaştırır: Her makinede tek bir güncelleme komutu, yazılımın güncel sürüm olmasını sağlar. + +Bir sürüm kontrol sistemiyle çalışmanın güzelliğini gördükten sonra, birkaç kuralı takip etmek sizi ve ekibinizi daha da etkili hale getirecektir: + +- Her mantıksal değişikliği ayrı bir işlemde gerçekleştirin. Birçok değişikliği tek bir işlemde bir araya getirmek, gelecekte bunları çözmeyi zorlaştıracaktır. Bu, diğer değişiklikleri kolayca gizleyebilecek proje çapında yeniden düzenleme veya stil değişiklikleri yaptığınızda özellikle önemlidir. +- Her işleme açıklayıcı bir mesajla eşlik edin. En azından neyi değiştirdiğinizi kısaca açıklayın, ancak değişikliğin mantığını da kaydetmek istiyorsanız, onu saklamak için en iyi yer burasıdır. +- Son olarak, bir projenin yapısını bozacak kodlar kullanmaktan kaçının, aksi takdirde projenin diğer geliştiricileri arasında popüler olmazsınız. + +[Diomidis Spinellis](http://programmer.97things.oreilly.com/wiki/index.php/Diomidis_Spinellis) Tarafından \ No newline at end of file From caca7bd27e90c1854bbf84cea851d7ae2e5bc830 Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Mon, 7 Mar 2022 18:34:49 +0300 Subject: [PATCH 086/290] added thing_69 --- tr/SUMMARY.md | 2 +- tr/thing_69/README.md | 50 +++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 51 insertions(+), 1 deletion(-) create mode 100644 tr/thing_69/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index e86829b4..b2daa163 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -69,7 +69,7 @@ 1. [Hataları Önle](thing_66/README.md) 1. [Profesyonel Yazılımcı](thing_67/README.md) 1. [Her Şeyi Sürüm Kontrolü Altına Alın](thing_68/README.md) -1. [Put the Mouse Down and Step Away from the Keyboard](thing_69/README.md) +1. [Fareyi Yere Bırakın ve Klavyeden Uzaklaşın](thing_69/README.md) 1. [Read Code](thing_70/README.md) 1. [Read the Humanities](thing_71/README.md) 1. [Reinvent the Wheel Often](thing_72/README.md) diff --git a/tr/thing_69/README.md b/tr/thing_69/README.md new file mode 100644 index 00000000..a65e5cea --- /dev/null +++ b/tr/thing_69/README.md @@ -0,0 +1,50 @@ +# Fareyi Yere Bırakın ve Klavyeden Uzaklaşın + +Saatlerdir amansız bir soruna odaklandınız ve görünürde bir çözüm yok. Bacaklarınızı uzatmak veya otomatlara çarpmak için ayağa kalkıyorsunuz ve dönüş yolunda cevap aniden ortaya çıkıyor. + +Bu senaryo tanıdık geliyor mu? Neden olduğunu hiç merak ettiniz mi? İşin püf noktası şu ki, kod yazarken beyninizin mantıksal kısmı aktiftir ve yaratıcı taraf kapalıdır. Mantıksal taraf bir mola verene kadar size hiçbir şey sunamaz. + +İşte gerçek hayattan bir örnek: Bazı eski kodları temizliyordum ve 'ilginç' bir yöntemle karşılaştım. *ss:dd:ss xx* biçimini kullanarak bir dizenin geçerli bir zaman içerdiğini doğrulamak için tasarlanmıştır; burada *hh* saati, *mm* dakikayı, *ss* saniyeyi ve *xx* bunlardan birini temsil eder *ÖÖ(AM)* veya *ÖS(PM)*. + +Yöntem, iki karakteri (saati temsil eden) bir sayıya dönüştürmek ve uygun aralıkta olduğunu doğrulamak için aşağıdaki kodu kullandı: + +``` +try { + Integer.parseInt(time.substring(0, 2)); +} catch (Exception x) { + return false; +} + +if (Integer.parseInt(time.substring(0, 2)) > 12) { + return false; +} +``` + +Dakikaları ve saniyeleri test etmek için karakter ofsetinde ve üst limitte uygun değişikliklerle aynı kod iki kez daha ortaya çıktı. Yöntem, AM ve PM'yi kontrol etmek için şu satırlarla sona erdi: + +``` +if (!time.substring(9, 11).equals("AM") & + !time.substring(9, 11).equals("PM")) { + return false; +} +``` + +Bu karşılaştırma dizilerinin hiçbiri başarısız olursa, false döndürülürse, yöntem true değerini döndürür. + +Yukarıdaki kod endişeli ve takip edilmesi zor görünüyorsa, endişelenmeyin. Ben de öyle düşündüm, bu da temizlemeye değer bir şey bulduğum anlamına geliyordu. Yeniden düzenledim ve hala çalıştığından emin olmak için birkaç birim testi yazdım. + +Bitirdiğimde, sonuçlardan memnun hissettim. Orijinal kod saat, dakika ve saniye için yalnızca üst sınırı test ettiğinden, yeni sürümün okunması kolay, yarı boyutunda ve daha doğruydu. + +Ertesi gün işe hazırlanırken kafamda bir fikir belirdi: Neden dizeyi normal bir ifade kullanarak doğrulamıyorsunuz? Birkaç dakika yazdıktan sonra, yalnızca bir kod satırında çalışan bir uygulamam oldu. İşte burada: + +``` +public static boolean validateTime(String time) { + return time.matches("(0[1-9]|1[0-2]):[0-5][0-9]:[0-5][0-9] ([AP]M)"); +} +``` + +Bu hikayenin amacı, sonunda otuzdan fazla kod satırını tek bir kodla değiştirmiş olmam değil. Mesele şu ki, bilgisayardan uzaklaşana kadar ilk denememin soruna en iyi çözüm olduğunu düşündüm. + +Bu yüzden bir daha kötü bir problemle karşılaştığınızda kendinize bir iyilik yapın. Sorunu gerçekten anladığınızda, beyninizin yaratıcı tarafını içeren bir şey yapın - sorunu çizin, biraz müzik dinleyin ya da sadece dışarıda yürüyüşe çıkın. Bazen bir sorunu çözmek için yapabileceğiniz en iyi şey, fareyi bırakıp klavyeden uzaklaşmaktır. + +[BurkHufnagel](http://programmer.97things.oreilly.com/wiki/index.php/BurkHufnagel) Tarafından \ No newline at end of file From b01bfdc7cc27b334f1f7a8774cd65a4e3cb23254 Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Mon, 7 Mar 2022 18:39:22 +0300 Subject: [PATCH 087/290] added thing_70 --- tr/SUMMARY.md | 2 +- tr/thing_70/README.md | 13 +++++++++++++ 2 files changed, 14 insertions(+), 1 deletion(-) create mode 100644 tr/thing_70/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index b2daa163..c6787242 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -70,7 +70,7 @@ 1. [Profesyonel Yazılımcı](thing_67/README.md) 1. [Her Şeyi Sürüm Kontrolü Altına Alın](thing_68/README.md) 1. [Fareyi Yere Bırakın ve Klavyeden Uzaklaşın](thing_69/README.md) -1. [Read Code](thing_70/README.md) +1. [Kodu Okuyun](thing_70/README.md) 1. [Read the Humanities](thing_71/README.md) 1. [Reinvent the Wheel Often](thing_72/README.md) 1. [Resist the Temptation of the Singleton Pattern](thing_73/README.md) diff --git a/tr/thing_70/README.md b/tr/thing_70/README.md new file mode 100644 index 00000000..cb7fb8bc --- /dev/null +++ b/tr/thing_70/README.md @@ -0,0 +1,13 @@ +# Kodu Okuyun + +Biz yazılımcılar tuhaf yaratıklarız. Kod yazmayı seviyoruz. Ama iş okumaya gelince genellikle çekiniriz. Sonuçta, kod yazmak çok daha eğlenceli ve kod okumak zor, bazen neredeyse imkansız. Başkalarının kodunu okumak özellikle zordur. Mutlaka diğer insanların kodu kötü olduğu için değil, muhtemelen sorunları sizden farklı şekilde düşündükleri ve çözdükleri için. Ancak başka birinin kodunu okumanın kendinizinkini geliştirebileceğini hiç düşündünüz mü? + +Bir dahaki sefere kod okuduğunuzda, durun ve bir an için düşünün. Kodun okunması kolay mı yoksa zor mu? Okumak zorsa, neden bu? Biçimlendirme kötü mü? Adlandırma tutarsız mı yoksa mantıksız mı? Aynı kod parçasında birkaç endişe birbirine karışmış mı? Belki de dil seçimi kodun okunabilir olmasını engelliyor? Başkalarının hatalarından ders almaya çalışın ki kodunuz aynı hataları içermesin. Birkaç sürprizle karşılaşabilirsiniz. Örneğin, bağımlılık kırma teknikleri düşük bağlantı için iyi olabilir, ancak bazen kodun okunmasını zorlaştırabilir. Ve bazılarının *zarif kod* dediğine, diğerleri *okunamaz* der. + +Kodun okunması kolaysa, ondan öğrenebileceğiniz yararlı bir şey olup olmadığını görmek için durun. Belki de bilmediğiniz veya daha önce uygulamakta zorlandığınız bir tasarım kalıbı kullanılıyor. Belki yöntemler daha kısadır ve isimleri sizinkinden daha anlamlıdır. Bazı açık kaynak projeleri, mükemmel, okunabilir kodun nasıl yazılacağına dair iyi örneklerle doludur - diğerleri ise tam tersi örnekler olarak hizmet eder! Kodlarından bazılarına göz atın ve bir göz atın. + +Şu anda üzerinde çalışmadığınız bir projeden kendi eski kodunuzu okumak da aydınlatıcı bir deneyim olabilir. En eski kodlarınızdan bazılarıyla başlayın ve bugüne kadar ilerleyin. Muhtemelen, okumanın, yazdığınız zamanki kadar kolay olmadığını göreceksiniz. Erken kodunuzun aynı zamanda belirli bir utanç verici eğlence değeri olabilir, tıpkı dün gece barda içki içerken söylediğiniz her şeyin size hatırlatılması gibi. Becerilerinizi yıllar içinde nasıl geliştirdiğinize bir bakın, gerçekten motive edici olabilir. Kodun hangi alanlarının okunmasının zor olduğunu gözlemleyin ve bugün hala aynı şekilde kod yazıp yazmadığınızı düşünün. + +Bu nedenle, bir daha programlama becerilerinizi geliştirme ihtiyacı hissettiğinizde, başka bir kitap okumayın. Kodu okuyun. + +[Karianne Berg](http://programmer.97things.oreilly.com/wiki/index.php/Karianne_Berg) Tarafından \ No newline at end of file From 70e1173ab2fe1ca2f0fc3cdcb6a85ca4a867cf6d Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Mon, 7 Mar 2022 18:47:15 +0300 Subject: [PATCH 088/290] added thing_71 --- tr/SUMMARY.md | 2 +- tr/thing_71/README.md | 13 +++++++++++++ 2 files changed, 14 insertions(+), 1 deletion(-) create mode 100644 tr/thing_71/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index c6787242..a459c9c8 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -71,7 +71,7 @@ 1. [Her Şeyi Sürüm Kontrolü Altına Alın](thing_68/README.md) 1. [Fareyi Yere Bırakın ve Klavyeden Uzaklaşın](thing_69/README.md) 1. [Kodu Okuyun](thing_70/README.md) -1. [Read the Humanities](thing_71/README.md) +1. [Beşeri Bilimleri Okuyun](thing_71/README.md) 1. [Reinvent the Wheel Often](thing_72/README.md) 1. [Resist the Temptation of the Singleton Pattern](thing_73/README.md) 1. [The Road to Performance Is Littered with Dirty Code Bombs](thing_74/README.md) diff --git a/tr/thing_71/README.md b/tr/thing_71/README.md new file mode 100644 index 00000000..9a0be408 --- /dev/null +++ b/tr/thing_71/README.md @@ -0,0 +1,13 @@ +# Beşeri Bilimleri Okuyun + +En küçük kalkınma projesinde insanlar insanlarla birlikte çalışır. En soyutlanmış araştırma alanı dışında tüm alanlarda insanlar, belirli bir amaç için onları desteklemek için yazılım yazarlar. İnsanlar insanlar için insanlarla yazılım yazarlar. Bu bir insan işi. Ne yazık ki yazılımcılara çok sık öğretilenler, onları birlikte ve birlikte çalıştıkları insanlarla başa çıkmak için çok zayıf bir şekilde donatıyor. Neyse ki, yardımcı olabilecek bütün bir çalışma alanı var. + +Örneğin, Ludwig Wittgenstein *Felsefi Soruşturmalar*'da (ve başka yerlerde) birbirimizle konuşmak için kullandığımız herhangi bir dilin bir düşünce, fikir veya resim elde etmek için bir serileştirme formatı olmadığını, olamayacağını kişinin kafasına ve bir başkasının kafasına çok iyi bir şekilde ortaya koymaktadır. "Gereksinimleri topladığımızda" yanlış anlaşılmalara karşı şimdiden tetikte olmalıyız. Wittgenstein ayrıca birbirimizi anlama yeteneğimizin paylaşılan tanımlardan kaynaklanmadığını, paylaşılan bir deneyimden, bir yaşam biçiminden kaynaklandığını da gösterir. Bu, sorun alanlarına batmış yazılımcıların, ondan ayrı duranlardan daha iyisini yapma eğiliminde olmasının bir nedeni olabilir. + +Lakoff ve Johnson bize, dilin büyük ölçüde metaforik olduğunu ve bu metaforların dünyayı nasıl anladığımıza dair bir fikir sunduğunu öne süren bir *Yaşadığımız Metaforlar* kataloğunu sunuyor. Bir finansal sistemden bahsederken karşılaşabileceğimiz nakit akışı gibi somut görünen terimler bile mecazi olarak görülebilir: "para bir akışkandır." Bu metafor, parayı idare eden sistemler hakkındaki düşüncelerimizi nasıl etkiler? Veya bir protokol yığınındaki katmanlar hakkında konuşabiliriz, bazıları yüksek seviyeli bazıları düşük seviyeli. Bu güçlü bir metafordur: kullanıcı "yukarı" ve teknoloji "aşağı"dır. Bu, inşa ettiğimiz sistemlerin yapısı hakkındaki düşüncelerimizi ortaya çıkarır. Ayrıca, zaman zaman kırılmaktan fayda sağlayabileceğimiz tembel bir düşünce alışkanlığına da işaret edebilir. + +Martin Heidegger, insanların araçları deneyimleme biçimlerini yakından inceledi. Yazılımcılar araçları inşa eder ve kullanır, biz de araçları düşünür, yaratır, değiştirir ve yeniden yaratırız. Araçlar bizi ilgilendiren nesnelerdir. Ancak Heiddeger'in *Varlık ve Zaman*'da gösterdiği gibi, kullanıcıları için bir araç, yalnızca kullanımda anlaşılan görünmez bir şey haline gelir. Kullanıcılar için araçlar, yalnızca çalışmadıklarında ilgilenilen nesneler haline gelir. Vurgudaki bu farklılık, kullanılabilirlik tartışılırken akılda tutulmaya değerdir. + +Eleanor Rosch, dünya anlayışımızı organize ettiğimiz Aristotelesçi kategori modelini devirdi. Yazılımcılar kullanıcılara bir sistemle ilgili isteklerini sorduğunda, yüklemlerden oluşturulmuş tanımları isteme eğilimindeyiz. Bu bizim için çok uygun. Yüklemlerdeki terimler, bir sınıftaki nitelikler veya bir tablodaki sütunlar haline gelebilir. Bu tür kategoriler net, ayrık ve düzenlidir. Ne yazık ki, Rosch'un "Doğal Kategoriler"de ve sonraki çalışmalarında gösterdiği gibi, insanların genel olarak dünyayı anlama şekli bu değildir. Örneklere dayalı yollarla anlıyorlar. Prototip olarak adlandırılan bazı örnekler diğerlerinden daha iyidir ve bu nedenle ortaya çıkan kategoriler bulanıktır, örtüşürler, zengin iç yapıya sahip olabilirler. Aristotelesçi yanıtlarda ısrar ettiğimiz sürece, kullanıcılara kullanıcının dünyası hakkında doğru soruları soramayız ve ihtiyacımız olan ortak anlayışa ulaşmak için mücadele edeceğiz. + +[Keith Braithwaite](http://programmer.97things.oreilly.com/wiki/index.php/Keith_Braithwaite) Tarafından \ No newline at end of file From dce59b19d54baaa88593905fe37ff81540a426c6 Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Tue, 8 Mar 2022 16:33:32 +0300 Subject: [PATCH 089/290] added thing_72 --- tr/SUMMARY.md | 2 +- tr/thing_72/README.md | 15 +++++++++++++++ 2 files changed, 16 insertions(+), 1 deletion(-) create mode 100644 tr/thing_72/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index a459c9c8..af681b15 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -72,7 +72,7 @@ 1. [Fareyi Yere Bırakın ve Klavyeden Uzaklaşın](thing_69/README.md) 1. [Kodu Okuyun](thing_70/README.md) 1. [Beşeri Bilimleri Okuyun](thing_71/README.md) -1. [Reinvent the Wheel Often](thing_72/README.md) +1. [Tekerleği Sıklıkla Yeniden İcat Edin](thing_72/README.md) 1. [Resist the Temptation of the Singleton Pattern](thing_73/README.md) 1. [The Road to Performance Is Littered with Dirty Code Bombs](thing_74/README.md) 1. [Simplicity Comes from Reduction](thing_75/README.md) diff --git a/tr/thing_72/README.md b/tr/thing_72/README.md new file mode 100644 index 00000000..679ce073 --- /dev/null +++ b/tr/thing_72/README.md @@ -0,0 +1,15 @@ +# Tekerleği Sıklıkla Yeniden İcat Edin + +"Var olan bir şeyi kullanın - tekerleği yeniden icat etmek aptalca..." + +Bunu hiç duydunuz mu ya da bunun bir varyasyonunu? Elbette duymuşsunuzdur! Her geliştirici ve öğrenci muhtemelen bu tür yorumları sık sık duyar. Neden? Tekerleği yeniden icat etmek neden bu kadar hoş karşılanmaz? Çünkü çoğu zaman mevcut kod çalışan koddur. Halihazırda bir çeşit kalite kontrolünden, titiz testlerden geçmiştir ve başarıyla kullanılmaktadır. Ek olarak, yeniden icat etmeye harcanan zaman ve çabanın, mevcut bir ürün veya kod tabanını kullanmanın yanı sıra karşılığını vermesi de olası değildir. Tekerleği yeniden icat etmeye zahmet etmeli misiniz? Niye ya? Ne zaman? + +Belki yazılım geliştirmedeki kalıplar hakkında yayınlar veya yazılım tasarımı üzerine kitaplar görmüşsünüzdür. Bu kitaplar, içerdiği bilgiler ne kadar harika olursa olsun, uyuyabilir. Aynı şekilde yelkencilikle ilgili bir film izlemek de yelken açmaktan çok farklıdır, bu yüzden kendi yazılımınızı sıfırdan tasarlamak, test etmek, kırmak, onarmak ve yol boyunca geliştirmek yerine mevcut kodu kullanmak da öyle. + +Tekerleği yeniden icat etmek, yalnızca kod yapılarının nereye yerleştirileceğine dair bir alıştırma değildir: Bu, halihazırda var olan çeşitli bileşenlerin iç işleyişine ilişkin kapsamlı bir bilginin nasıl elde edileceğidir. Bellek yöneticilerinin nasıl çalıştığını biliyor musunuz? Sanal sayfalama? Bunları kendiniz uygulayabilir misiniz? Çift bağlantılı listelere ne dersiniz? Dinamik dizi sınıfları? ODBC istemcileri? Bildiğiniz ve beğendiğiniz popüler bir arayüz gibi çalışan bir grafik kullanıcı arayüzü yazabilir misiniz? Kendi web tarayıcı widget'larınızı oluşturabilir misiniz? Çok iş parçacıklı bir sisteme karşı çoğullamalı bir sistemi ne zaman yazacağınızı biliyor musunuz? Dosya veya bellek tabanlı bir veritabanı arasında nasıl karar verilir? Çoğu geliştirici, bu tür temel yazılım uygulamalarını hiçbir zaman kendileri oluşturmamıştır ve bu nedenle nasıl çalıştıkları konusunda derin bir bilgiye sahip değildir. Sonuç olarak, tüm bu tür yazılımlar, sadece çalışan gizemli kara kutular olarak görülüyor. Suyun sadece yüzeyini anlamak, altındaki gizli tehlikeleri ortaya çıkarmak için yeterli değildir. Yazılım geliştirmedeki daha derin şeyleri bilmemek, mükemmel işler yaratma yeteneğinizi sınırlayacaktır. + +Tekerleği yeniden icat etmek ve yanlış yapmak, onu ilk kez çivilemekten daha değerlidir. Deneme yanılma yoluyla öğrenilen, duygusal bir bileşeni olan ve tek başına teknik bir kitap okumanın sağlayamayacağı dersler vardır! + +Öğrenilmiş gerçekler ve kitap zekası çok önemlidir, ancak harika bir yazılımcı olmak, gerçekleri toplamakla ilgili olduğu kadar deneyim kazanmakla da ilgilidir. Bir vücut geliştiricisi için ağırlık kaldırma ne kadar önemliyse, tekerleği yeniden icat etmek de bir geliştiricinin eğitimi ve becerisi için o kadar önemlidir. + +[Jason P Sage](http://programmer.97things.oreilly.com/wiki/index.php/Jason_P_Sage) Tarafından \ No newline at end of file From 5c1d3af2ef8488d9fe4f5e06a76af5524fc1104f Mon Sep 17 00:00:00 2001 From: Baran Kaya Date: Tue, 8 Mar 2022 16:50:33 +0300 Subject: [PATCH 090/290] added thing_73 --- tr/SUMMARY.md | 2 +- tr/thing_73/README.md | 25 +++++++++++++++++++++++++ 2 files changed, 26 insertions(+), 1 deletion(-) create mode 100644 tr/thing_73/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index af681b15..12c399e5 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -73,7 +73,7 @@ 1. [Kodu Okuyun](thing_70/README.md) 1. [Beşeri Bilimleri Okuyun](thing_71/README.md) 1. [Tekerleği Sıklıkla Yeniden İcat Edin](thing_72/README.md) -1. [Resist the Temptation of the Singleton Pattern](thing_73/README.md) +1. [Singleton Modelin Cazibesine Kapılma](thing_73/README.md) 1. [The Road to Performance Is Littered with Dirty Code Bombs](thing_74/README.md) 1. [Simplicity Comes from Reduction](thing_75/README.md) 1. [The Single Responsibility Principle](thing_76/README.md) diff --git a/tr/thing_73/README.md b/tr/thing_73/README.md new file mode 100644 index 00000000..6c42192c --- /dev/null +++ b/tr/thing_73/README.md @@ -0,0 +1,25 @@ +# Singleton Modelin Cazibesine Kapılma + +Singleton modeli, sorunlarınızın çoğunu çözer. Sadece tek bir örneğe ihtiyacınız olduğunu biliyorsunuz. Bu örneğin kullanılmadan önce başlatılacağına dair bir garantiniz var. Küresel bir erişim noktasına sahip olarak tasarımınızı basit tutar. Hepsi iyi. Bu klasik tasarım deseninde sevilmeyen şey nedir? + +Oldukça fazla, ortaya çıkıyor. Cazip olabilirler, ancak deneyimler çoğu singleton'ın gerçekten yarardan çok zarar verdiğini gösteriyor. Test edilebilirliği engeller ve sürdürülebilirliğe zarar verirler. Ne yazık ki, bu ek bilgelik olması gerektiği kadar yaygın değildir ve singleton'lar birçok programcı için karşı konulmaz olmaya devam etmektedir. Ama direnmeye değer: + +- Tek örnek gereksinimi çoğu zaman hayal edilir. Çoğu durumda, gelecekte ek bir örneğe gerek olmayacağı tamamen spekülasyondur. Bir uygulamanın tasarımı boyunca bu tür spekülatif özelliklerin yayınlanması, bir noktada acıya neden olacaktır. Gereksinimler değişecek. İyi tasarım bunu benimser. Singleton'lar yapmaz. + +- Singleton'lar, kavramsal olarak bağımsız kod birimleri arasında örtük bağımlılıklara neden olur. Bu, hem gizli oldukları için hem de birimler arasında gereksiz bağlantı oluşturdukları için sorunludur. Bu kod kokusu, gevşek bağlantıya ve sahte bir uygulamayı gerçek bir uygulamayla seçici olarak değiştirme yeteneğine bağlı olan birim testleri yazmaya çalıştığınızda keskinleşir. Singletons, bu tür basit alaycılığı önler. + +- Singleton'lar ayrıca, birim testini yine engelleyen örtük kalıcı durum taşır. Birim testi, testlerin birbirinden bağımsız olmasına bağlıdır, bu nedenle testler herhangi bir sırada çalıştırılabilir ve program, her birim testinin yürütülmesinden önce bilinen bir duruma ayarlanabilir. Değişken duruma sahip tekilleri tanıttıktan sonra, bunu başarmak zor olabilir. Ek olarak, bu tür küresel olarak erişilebilir kalıcı durum, özellikle çok iş parçacıklı bir ortamda kod hakkında akıl yürütmeyi zorlaştırır. + +- Çoklu iş parçacığı, singleton desene başka tuzaklar getirir. Erişimi doğrudan kilitleme çok verimli olmadığı için, sözde çift kontrol kilitleme modeli (DCLP) popülerlik kazanmıştır. Ne yazık ki, bu ölümcül çekiciliğin başka bir şekli olabilir. DCLP'nin birçok dilde iş parçacığı için güvenli olmadığı ve olduğu yerde bile, onu kurnazca yanlış anlama fırsatları olduğu ortaya çıktı. + +Singletonların temizlenmesi son bir zorluk sunabilir: + +- Bazı bağlamlarda ciddi bir sorun olabilen, Singleton'ları açıkça öldürmek için destek yoktur. Örneğin, bir eklentinin yalnızca tüm nesneleri temizlendikten sonra güvenli bir şekilde kaldırılabileceği bir eklenti mimarisinde. + +- Program çıkışında singleton'ların örtülü temizliğine yönelik bir düzen yoktur. Bu, karşılıklı bağımlılıkları olan tekiller içeren uygulamalar için zahmetli olabilir. Bu tür uygulamaları kapatırken, bir singleton, zaten yok edilmiş olan diğerine erişebilir. + +- Bu eksikliklerin bir kısmı, ek mekanizmalar getirilerek aşılabilir. Ancak bu, alternatif bir tasarım seçerek önlenebilecek ek kod karmaşıklığı pahasına gelir. + +Bu nedenle, Singleton deseni kullanımınızı, gerçekten hiçbir zaman birden çok kez somutlaştırılmaması gereken sınıflarla sınırlayın. Bir singleton'ın global erişim noktasını rastgele koddan kullanmayın. Bunun yerine, singleton'a doğrudan erişim, arayüzü aracılığıyla diğer koda geçirilebileceği yalnızca birkaç iyi tanımlanmış yerden olmalıdır. Bu diğer kod habersizdir ve bu nedenle, bir singleton'un veya başka bir sınıfın arabirimi uygulayıp uygulamadığına bağlı değildir. Bu, birim testini engelleyen bağımlılıkları kırar ve sürdürülebilirliği iyileştirir. Bu nedenle, bir dahaki sefere bir singleton uygulamayı veya ona erişmeyi düşündüğünüzde, umarım durup tekrar düşünürsünüz. + +[Sam Saariste](http://programmer.97things.oreilly.com/wiki/index.php/Sam_Saariste) Tarafından \ No newline at end of file From 6c95cdd8ef121dabc5e5b485e3a09486eb82dfa4 Mon Sep 17 00:00:00 2001 From: Baran Kaya <0barankaya@gmail.com> Date: Thu, 24 Mar 2022 19:00:37 +0300 Subject: [PATCH 091/290] added thing_74 --- tr/SUMMARY.md | 2 +- tr/thing_74/README.md | 13 +++++++++++++ 2 files changed, 14 insertions(+), 1 deletion(-) create mode 100644 tr/thing_74/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index 12c399e5..43481180 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -74,7 +74,7 @@ 1. [Beşeri Bilimleri Okuyun](thing_71/README.md) 1. [Tekerleği Sıklıkla Yeniden İcat Edin](thing_72/README.md) 1. [Singleton Modelin Cazibesine Kapılma](thing_73/README.md) -1. [The Road to Performance Is Littered with Dirty Code Bombs](thing_74/README.md) +1. [Performansa Giden Yol Kirli Kod Bombalarıyla Dolu](thing_74/README.md) 1. [Simplicity Comes from Reduction](thing_75/README.md) 1. [The Single Responsibility Principle](thing_76/README.md) 1. [Start from Yes](thing_77/README.md) diff --git a/tr/thing_74/README.md b/tr/thing_74/README.md new file mode 100644 index 00000000..d4da7453 --- /dev/null +++ b/tr/thing_74/README.md @@ -0,0 +1,13 @@ +# Performansa Giden Yol Kirli Kod Bombalarıyla Dolu + +Çoğu zaman, bir sistemin performans ayarı, kodu değiştirmenizi gerektirir. Kodu değiştirmemiz gerektiğinde, aşırı karmaşık veya yüksek düzeyde bağlı olan her parça, çabayı raydan çıkarmak için bekleyen kirli bir kod bombasıdır. Kirli kodun ilk zayiatı programınız olacaktır. İleriye giden yol düzgünse, ne zaman bitireceğinizi tahmin etmek kolay olacaktır. Kirli kodla beklenmedik karşılaşmalar, aklı başında bir tahminde bulunmayı çok zorlaştıracaktır. + +Bir yürütme etkin noktası bulduğunuz durumu düşünün. Normal hareket tarzı, temel alınan algoritmanın gücünü azaltmaktır. Diyelim ki yöneticinizin tahmin talebine 3-4 saatlik bir cevapla cevap verdiniz. Düzeltmeyi uygularken, bağımlı bir parçayı kırdığınızı hemen anlarsınız. Yakından ilgili şeyler genellikle zorunlu olarak birleştiğinden, bu kırılma büyük olasılıkla beklenir ve açıklanır. Ancak bu bağımlılığı düzeltmek, diğer bağımlı parçaların kırılmasına neden olursa ne olur? Ayrıca, bağımlılık kökenden ne kadar uzaksa, onu bu şekilde tanımanız ve tahmininizde hesaba katmanız o kadar az olasıdır. 3-4 saatlik tahmininiz birdenbire 3-4 haftaya kolayca uzayabilir. Genellikle programdaki bu beklenmedik şişkinlik, bir seferde 1 veya 2 gün olur. Sonunda tamamlanması birkaç ay süren "hızlı" yeniden düzenlemeleri görmek nadir değildir. Bu durumlarda, sorumlu ekibin güvenilirliğine ve siyasi sermayesine verilen zarar, şiddetli ile ölümcül arasında değişecektir. Keşke bu riski belirlememize ve ölçmemize yardımcı olacak bir aracımız olsaydı. + +Aslında, kodumuzun karmaşıklığını ve bağlantının derecesini ve derinliğini ölçmenin ve kontrol etmenin birçok yolu var. Yazılım ölçümleri, kodumuzdaki belirli özelliklerin oluşumlarını saymak için kullanılabilir. Bu sayıların değerleri kod kalitesiyle ilişkilidir. Bağlantıyı ölçen bir dizi metrikten ikisi, fan-in(bir mantık hücresinin giriş denklemlerini besleyen maksimum giriş sinyali sayısını ifade eder) ve fan-out(bir mantık hücresinin çıkış denklemleri tarafından beslenen maksimum çıkış sinyali sayısını ifade eder). Sınıflar için dağıtmayı düşünün: Bir ilgi sınıfından doğrudan veya dolaylı olarak başvurulan sınıfların sayısı olarak tanımlanır. Bunu, sınıfınız derlenmeden önce derlenmesi gereken tüm sınıfların bir sayısı olarak düşünebilirsiniz. Fan-in ise, ilgilenilen sınıfa bağlı olan tüm sınıfların bir sayısıdır. Fan-out ve fan-in'leri bilerek *I = fo / (fi + fo)* kullanarak bir istikrarsızlık faktörünü hesaplayabiliriz. . *I* 0'a yaklaştıkça paket daha kararlı hale gelir. *I* 1'e yaklaştıkça paket kararsız hale gelir. Kararlı paketler, yeniden kodlama için düşük riskli hedeflerken, kararsız paketlerin kirli kod bombalarıyla doldurulması daha olasıdır. Yeniden düzenlemedeki amaç *I*'yi 0'a yaklaştırmaktır. + +Metrikleri kullanırken, bunların yalnızca temel kurallar olduğu unutulmamalıdır. Tamamen matematikte, fo'yu değiştirmeden *fi* artırmanın *I*'yi 0'a yaklaştıracağını görebiliriz. Ancak, bu sınıfta çok büyük bir fan-in değerinin dezavantajı vardır. bağımlıları kırmadan değiştirmek daha zor olacaktır. Ayrıca, fan-out'u ele almadan risklerinizi gerçekten azaltmıyorsunuz, bu nedenle bir miktar denge uygulanmalıdır. + +Yazılım metriklerinin bir dezavantajı, metrik araçlarının ürettiği çok sayıda sayının tecrübesiz kişiler için göz korkutucu olabilmesidir. Bununla birlikte, yazılım metrikleri temiz kod mücadelemizde güçlü bir araç olabilir. Performans ayarlama alıştırması için ciddi bir risk oluşturmadan önce kirli kod bombalarını belirlememize ve ortadan kaldırmamıza yardımcı olabilirler. + +[Kirk Pepperdine](http://programmer.97things.oreilly.com/wiki/index.php/Kirk_Pepperdine) Tarafından \ No newline at end of file From f5d6e3fddfee4c246d520f02b2e2c76431f99565 Mon Sep 17 00:00:00 2001 From: Baran Kaya <0barankaya@gmail.com> Date: Mon, 28 Mar 2022 14:30:03 +0300 Subject: [PATCH 092/290] added en/thing_47 --- en/thing_47/README.md | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) create mode 100644 en/thing_47/README.md diff --git a/en/thing_47/README.md b/en/thing_47/README.md new file mode 100644 index 00000000..f62c5d6c --- /dev/null +++ b/en/thing_47/README.md @@ -0,0 +1,19 @@ +# Know Your Next Commit + +I tapped three programmers on their shoulders and asked what they were doing. "I am refactoring these methods," the first answered. "I am adding some parameters to this web action," the second answered. The third answered, "I am working on this user story." + +It might seem that the first two were engrossed in the details of their work while only the third could see the bigger picture, and that the latter had the better focus. However, when I asked when and what they would commit, the picture changed dramatically. The first two where pretty clear over what files would be involved and would be finished within an hour or so. The third programmer answered, "Oh, I guess I will be ready within a few days. I will probably add a few classes and might change those services in some way." + +The first two did not lack a vision of the overall goal. They had selected tasks they thought led in a productive direction, and could be finished within a couple of hours. Once they had finished those tasks, they would select a new feature or refactoring to work on. All the code written was thus done with a clear purpose and a limited, achievable goal in mind. + +The third programmer had not been able to decompose the problem and was working on all aspects at once. He had no idea of what it would take, basically doing speculative programming, hoping to arrive at some point where he would be able to commit. Most probably the code written at the start of this long session was poorly matched for the solution that came out in the end. + +What would the first two programmers do if their tasks took more than two hours? After realizing they had taken on too much, they would most likely throw away their changes, define smaller tasks, and start over. To keep working would have lacked focus and led to speculative code entering the repository. Instead, changes would be thrown away, but the insights kept. + +The third programmer might keep on guessing and desperately try to patch together his changes into something that could be committed. After all, you cannot throw away code changes you have done — that would be wasted work, wouldn't it? Unfortunately, not throwing the code away leads to slightly odd code that lacks a clear purpose entering the repository. + +At some point even the commit-focused programmers might fail to find something useful they thought could be finished in two hours. Then, they would go directly into speculative mode, playing around with the code and, of course, throwing away the changes whenever some insight led them back on track. Even these seemingly unstructured hacking sessions have purpose: to learn about the code to be able to define a task that would constitute a productive step. + +Know your next commit. If you cannot finish, throw away your changes, then define a new task you believe in with the insights you have gained. Do speculative experimentation whenever needed, but do not let yourself slip into speculative mode without noticing. Do not commit guesswork into your repository. + +By [Dan Bergh Johnsson](http://programmer.97things.oreilly.com/wiki/index.php/Dan_Bergh_Johnsson) \ No newline at end of file From 0f51c60717c84617f2e328331edd1f8c8799fb18 Mon Sep 17 00:00:00 2001 From: Baran Kaya <0barankaya@gmail.com> Date: Mon, 4 Apr 2022 18:05:26 +0300 Subject: [PATCH 093/290] added thing_75 --- tr/SUMMARY.md | 2 +- tr/thing_75/README.md | 19 +++++++++++++++++++ 2 files changed, 20 insertions(+), 1 deletion(-) create mode 100644 tr/thing_75/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index 43481180..b194fec9 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -75,7 +75,7 @@ 1. [Tekerleği Sıklıkla Yeniden İcat Edin](thing_72/README.md) 1. [Singleton Modelin Cazibesine Kapılma](thing_73/README.md) 1. [Performansa Giden Yol Kirli Kod Bombalarıyla Dolu](thing_74/README.md) -1. [Simplicity Comes from Reduction](thing_75/README.md) +1. [Sadelik Azaltmadan Gelir](thing_75/README.md) 1. [The Single Responsibility Principle](thing_76/README.md) 1. [Start from Yes](thing_77/README.md) 1. [Step Back and Automate, Automate, Automate](thing_78/README.md) diff --git a/tr/thing_75/README.md b/tr/thing_75/README.md new file mode 100644 index 00000000..ba22ae67 --- /dev/null +++ b/tr/thing_75/README.md @@ -0,0 +1,19 @@ +# Sadelik Azaltmadan Gelir + +"Tekrar yap..." dedi patronum, parmağıyla silme tuşuna sertçe basarken. Kodum satır satır unutulup giderken, bilgisayar ekranını çok tanıdık bir batan duyguyla izledim. + +Patronum Stefan, her zaman insanların arasında en çok ses çıkaran kişi değildi, ama kötü kodu gördüğünde biliyordu. Ve onunla ne yapması gerektiğini çok iyi biliyordu. + +Öğrenci programcı olarak şu anki pozisyonuma bol enerji, bol hevesle gelmiştim ama kodlama hakkında kesinlikle hiçbir fikrim yoktu. Her sorunun çözümünün bir yere başka bir değişken eklemek olduğunu düşünmek gibi korkunç bir eğilimim vardı. Veya başka bir satıra atın. Kötü bir günde, mantığım her revizyonda daha iyi hale gelmek yerine, kodum yavaş yavaş daha büyük, daha karmaşık ve tutarlı bir şekilde çalışmaktan uzaklaştı. + +Özellikle acele ederken, korkunç olsa bile mevcut bir kod bloğunda en az değişiklikleri yapmak istemek doğaldır. Çoğu programcı, yeniden başlamanın, başa dönmekten çok daha fazla çaba gerektireceğinden korkarak hatalı kodu koruyacaktır. Bu, çalışmaya yakın kodlar için doğru olabilir, ancak tüm yardımların ötesinde olan bazı kodlar var. + +Kötü işleri kurtarmaya çalışırken olması gerekenden daha fazla zaman harcanır. Bir şey kaynak havuzuna dönüştüğünde, hızlıca atılması gerekir. + +Tüm bu yazma, adlandırma ve biçimlendirme işlemlerini kolayca bir kenara atmanız gerekmez. Patronumun tepkisi aşırıydı, ancak ikinci (veya bazen üçüncü) denemede beni kodu yeniden düşünmeye zorladı. Yine de, hatalı kodu düzeltmenin en iyi yaklaşımı, kodun acımasızca yeniden yapılandırıldığı, değiştirildiği veya silindiği bir moda geçmektir. + +Kod basit olmalıdır. Minimum sayıda değişken, işlev, bildirim ve diğer sözdizimsel dil gereksinimleri olmalıdır. Fazladan satırlar, fazladan değişkenler... fazladan *herhangi bir şey*, gerçekten temizlenmelidir. Hemen kaldırıldı. Orada ne var, ne kaldı, sadece işi bitirmek, algoritmayı tamamlamak veya hesaplamaları yapmak için yeterli olmalıdır. Diğer her şey, kazayla ortaya çıkan ve akışı engelleyen fazladan istenmeyen gürültüdür. Önemli şeyleri gizlemek. + +Tabii ki, bu işe yaramazsa, hepsini silin ve tekrar yazın. Birinin hafızasından bu şekilde çizim yapmak çoğu zaman gereksiz yere dağınıklığın üstesinden gelmeye yardımcı olabilir. + +[Paul W. Homer](http://programmer.97things.oreilly.com/wiki/index.php/Paul_W._Homer) Tarafından \ No newline at end of file From fa3dedd7066a4208c3b9443a305e65cad3b08ae1 Mon Sep 17 00:00:00 2001 From: Baran Kaya <0barankaya@gmail.com> Date: Tue, 5 Apr 2022 09:11:19 +0300 Subject: [PATCH 094/290] added thing_76 --- tr/SUMMARY.md | 2 +- tr/thing_76/README.md | 41 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 42 insertions(+), 1 deletion(-) create mode 100644 tr/thing_76/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index b194fec9..d489c68f 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -76,7 +76,7 @@ 1. [Singleton Modelin Cazibesine Kapılma](thing_73/README.md) 1. [Performansa Giden Yol Kirli Kod Bombalarıyla Dolu](thing_74/README.md) 1. [Sadelik Azaltmadan Gelir](thing_75/README.md) -1. [The Single Responsibility Principle](thing_76/README.md) +1. [Tek Sorumluluk İlkesi(The Single Responsibility)](thing_76/README.md) 1. [Start from Yes](thing_77/README.md) 1. [Step Back and Automate, Automate, Automate](thing_78/README.md) 1. [Take Advantage of Code Analysis Tools](thing_79/README.md) diff --git a/tr/thing_76/README.md b/tr/thing_76/README.md new file mode 100644 index 00000000..5162ec30 --- /dev/null +++ b/tr/thing_76/README.md @@ -0,0 +1,41 @@ +# Tek Sorumluluk İlkesi(The Single Responsibility) + +İyi tasarımın en temel ilkelerinden biri: + +> Aynı nedenle değişenleri bir araya toplayın ve farklı nedenlerle değişenleri ayırın. + +Bu ilke genellikle *Tek Sorumluluk İlkesi* veya SRP olarak bilinir. Kısacası, bir alt sistemin, modülün, sınıfın ve hatta bir fonksiyonun değişmesi için birden fazla nedeni olmaması gerektiğini söylüyor. Klasik örnek, iş kuralları, raporlar ve veritabanıyla ilgilenen yöntemlere sahip bir sınıftır: + +``` +public class Employee { + public Money calculatePay() ... + public String reportHours() ... + public void save() ... +} +``` + +Bazı programcılar, bu üç işlevi aynı sınıfta bir araya getirmenin tamamen uygun olduğunu düşünebilir. Sonuçta, sınıfların ortak değişkenler üzerinde çalışan fonksiyonların koleksiyonları olması gerekiyordu. Ancak sorun, üç işlevin tamamen farklı nedenlerle değişmesidir. `calculatePay` işlevi, ödeme değişikliğini hesaplamak için iş kuralları her değiştiğinde değişecektir. Birisi rapor için farklı bir format istediğinde `reportHours` işlevi değişecektir. DBA'lar veritabanı şemasını her değiştirdiğinde kaydetme işlevi değişecektir. Değişimin bu üç nedeni, `Employee`i çok değişken hale getirmek için birleşir. Bu nedenlerden herhangi biri için değişecektir. Daha da önemlisi, `Employee`ye bağlı tüm sınıflar bu değişikliklerden etkilenecektir. + +İyi sistem tasarımı, sistemi bağımsız olarak dağıtılabilen bileşenlere ayırmamız anlamına gelir. Bağımsız dağıtım, bir bileşeni değiştirirsek diğerlerini yeniden dağıtmamız gerekmediği anlamına gelir. Ancak, `Employee` diğer bileşenlerdeki diğer birçok sınıf tarafından yoğun bir şekilde kullanılıyorsa, o zaman `Employee`de yapılan her değişikliğin diğer bileşenlerin yeniden konuşlandırılmasına neden olması muhtemeldir; böylece bileşen tasarımının (veya daha popüler bir adı tercih ederseniz SOA) büyük bir faydasını reddeder. + +``` +public class Employee { + public Money calculatePay() ... +} + +public class EmployeeReporter { + public String reportHours(Employee e) ... +} + +public class EmployeeRepository { + public void save(Employee e) ... +} +``` + +Yukarıda gösterilen basit bölümleme, sorunları çözer. Bu sınıfların her biri kendi bileşenine yerleştirilebilir. Daha doğrusu, tüm raporlama sınıfları raporlama bileşenine girebilir. Veritabanıyla ilgili tüm sınıflar depo bileşenine girebilir. Ve tüm iş kuralları, iş kuralı bileşenine girebilir. + +Zeki okuyucu, yukarıdaki çözümde hala bağımlılıklar olduğunu görecektir. Bu `Employee` hala diğer sınıflar tarafından bağımlıdır. Dolayısıyla, `Employee` değiştirilirse, diğer sınıfların büyük olasılıkla yeniden derlenmesi ve yeniden konuşlandırılması gerekecektir. Bu nedenle, `Employee` değiştirilemez ve ardından bağımsız olarak konuşlandırılamaz. Ancak, diğer sınıflar değiştirilebilir ve bağımsız olarak dağıtılabilir. Bunlardan birinde yapılacak hiçbir değişiklik, diğerlerini yeniden derlenmeye veya yeniden dağıtılmaya zorlayamaz. `Employee` bile *Bağımlılığı Tersine Çevirme İlkesi(Dependency Inversion Principle)* (DIP) dikkatli bir şekilde kullanılarak bağımsız olarak konuşlandırılabilir, ancak bu [farklı bir kitabın](http://www.amazon.com/dp/0135974445/) konusu. + +Farklı nedenlerle değişen şeyleri ayıran SRP'nin dikkatli bir şekilde uygulanması, bağımsız olarak konuşlandırılabilir bir bileşen yapısına sahip tasarımlar oluşturmanın anahtarlarından biridir. + +[Uncle Bob](http://programmer.97things.oreilly.com/wiki/index.php/Uncle_Bob) Tarafından \ No newline at end of file From a942e002d202daf5d33bbfc5c37cf48e2a70ba6b Mon Sep 17 00:00:00 2001 From: Baran Kaya <0barankaya@gmail.com> Date: Tue, 5 Apr 2022 18:07:40 +0300 Subject: [PATCH 095/290] added thing_77 --- tr/SUMMARY.md | 2 +- tr/thing_77/README.md | 23 +++++++++++++++++++++++ 2 files changed, 24 insertions(+), 1 deletion(-) create mode 100644 tr/thing_77/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index d489c68f..41984236 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -77,7 +77,7 @@ 1. [Performansa Giden Yol Kirli Kod Bombalarıyla Dolu](thing_74/README.md) 1. [Sadelik Azaltmadan Gelir](thing_75/README.md) 1. [Tek Sorumluluk İlkesi(The Single Responsibility)](thing_76/README.md) -1. [Start from Yes](thing_77/README.md) +1. [Evet'ten Başlayın](thing_77/README.md) 1. [Step Back and Automate, Automate, Automate](thing_78/README.md) 1. [Take Advantage of Code Analysis Tools](thing_79/README.md) 1. [Test for Required Behavior, not Incidental Behavior](thing_80/README.md) diff --git a/tr/thing_77/README.md b/tr/thing_77/README.md new file mode 100644 index 00000000..8dc873f4 --- /dev/null +++ b/tr/thing_77/README.md @@ -0,0 +1,23 @@ +# Evet'ten Başlayın + +Geçenlerde bir bakkaldaydım ve "edamame" için yüksek ve düşük arama yapıyordum (bir tür sebze olduğunu sadece belli belirsiz biliyordum). Bunun sebze bölümünde mi, donmuş bölümde mi yoksa konservede mi bulacağımdan emin değildim. Vazgeçtim ve bana yardım etmesi için bir çalışanın izini sürdüm. O da bilmiyordu! + +Çalışan birçok farklı şekilde yanıt verebilirdi. Nereye bakacağımı bilmediğim için beni cahil hissettirebilirdi, ya da bana belirsiz olasılıklar verebilirdi, hatta bana eşyanın onlarda olmadığını söyleyebilirdi. Ancak bunun yerine talebi bir çözüm bulma ve müşteriye yardım etme fırsatı olarak değerlendirdi. Diğer çalışanları aradı ve dakikalar içinde beni donmuş bölümde bulunan tam öğeye yönlendirdi. + +Bu durumda çalışan bir talebe baktı ve sorunu çözeceğimiz ve talebi karşılayacağımız öncülünden yola çıktı. Hayırdan başlamak yerine *evet* ile başladı. + +Teknik bir liderlik rolüne ilk yerleştirildiğimde, işimin güzel yazılımımı ürün yöneticilerinden ve iş analistlerinden gelen gülünç talep akışından korumak olduğunu hissettim. Çoğu sohbete, bir talebi kabul edilecek bir şey değil, yenilecek bir şey olarak görmeye başladım. + +Bir noktada, belki de bakış açımı hayırdan başlayıp *evet* ile başlamayı içeren farklı bir çalışma yolu olduğuna dair bir aydınlanma yaşadım. Aslında, *evet* ile başlamanın aslında teknik bir lider olmanın önemli bir parçası olduğuna inanmaya başladım. + +Bu basit değişiklik, işime nasıl yaklaştığımı kökten değiştirdi. Görünen o ki, *evet* demenin birçok yolu var. Biri size "Hey, tüm pencereleri yuvarlak ve yarı saydam yapsaydık, bu uygulama gerçekten arıların dizleri olurdu!" dediğinde. bunu saçma bularak reddedebilirsin. Ancak genellikle "Neden?" ile başlamak daha iyidir. Bunun yerine. Çoğu zaman, o kişinin ilk etapta yuvarlak yarı saydam pencereler istemesinin bazı gerçek ve zorlayıcı nedenleri vardır. Örneğin, yuvarlak yarı saydam pencereleri zorunlu kılan bir standartlar komitesiyle yeni ve büyük bir müşteriyle anlaşmak üzere olabilirsiniz. + +Genellikle, talebin içeriğini bildiğinizde yeni olasılıkların açıldığını göreceksiniz. İsteğin, mevcut ürünle başka bir şekilde gerçekleştirilmesi, hiç çalışmadan *evet* demenize olanak tanıyan yaygın bir durumdur: "Aslında, kullanıcı tercihlerinde yuvarlak yarı saydam pencere kaplamasını indirebilir ve açabilirsiniz." + +Bazen diğer kişi, ürüne bakışınızla uyumsuz bulduğunuz bir fikre sahip olacaktır. Bunu "Neden?" diye çevirmenin kendinde genellikle yararlı olduğunu düşünüyorum. Bazen sebebi dile getirme eylemi, ilk tepkinizin mantıklı olmadığını açıkça ortaya koyacaktır. Değilse, bir çentik atmanız ve diğer önemli karar vericileri getirmeniz gerekebilir. Unutmayın, tüm bunların amacı karşınızdaki kişiye *evet* demek ve bunu sadece onun için değil sizin ve ekibiniz için de çalıştırmaya çalışmaktır. + +Özellik isteğinin neden mevcut ürünle uyumsuz olduğuna dair ikna edici bir açıklama yapabiliyorsanız, doğru ürünü oluşturup oluşturmadığınız konusunda verimli bir konuşma yapmanız olasıdır. Bu konuşmanın nasıl sonuçlandığına bakılmaksızın, herkes ürünün ne olduğuna ve ne olmadığına daha keskin bir şekilde odaklanacaktır. + +*Evet*'ten başlamak, iş arkadaşlarınızla birlikte çalışmak anlamına gelir, onlara karşı değil. + +By [Alex Miller](http://programmer.97things.oreilly.com/wiki/index.php/Alex_Miller) \ No newline at end of file From d34d05410492edd1d864e27d3101a424fca20c19 Mon Sep 17 00:00:00 2001 From: Baran Kaya <0barankaya@gmail.com> Date: Wed, 6 Apr 2022 18:09:54 +0300 Subject: [PATCH 096/290] added thinf_78 --- tr/SUMMARY.md | 2 +- tr/thing_78/README.md | 29 +++++++++++++++++++++++++++++ 2 files changed, 30 insertions(+), 1 deletion(-) create mode 100644 tr/thing_78/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index 41984236..17571b5e 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -78,7 +78,7 @@ 1. [Sadelik Azaltmadan Gelir](thing_75/README.md) 1. [Tek Sorumluluk İlkesi(The Single Responsibility)](thing_76/README.md) 1. [Evet'ten Başlayın](thing_77/README.md) -1. [Step Back and Automate, Automate, Automate](thing_78/README.md) +1. [Geri Adım Atın ve Otomatikleştirin, Otomatikleştirin, Otomatikleştirin](thing_78/README.md) 1. [Take Advantage of Code Analysis Tools](thing_79/README.md) 1. [Test for Required Behavior, not Incidental Behavior](thing_80/README.md) 1. [Test Precisely and Concretely](thing_81/README.md) diff --git a/tr/thing_78/README.md b/tr/thing_78/README.md new file mode 100644 index 00000000..1e371184 --- /dev/null +++ b/tr/thing_78/README.md @@ -0,0 +1,29 @@ +# Geri Adım Atın ve Otomatikleştirin, Otomatikleştirin, Otomatikleştirin + +Bir modülde kod satırlarının sayısını üretmesi istendiğinde, dosyaları bir kelime işlemciye yapıştıran ve onun "satır sayısı" özelliğini kullanan programcılarla çalıştım. Ve haftaya tekrar yaptılar. Ve sonraki hafta. Kötüydü. + +Kod imzalamayı ve sonucu bir sunucuya taşımayı içeren, çok sayıda fare tıklaması gerektiren, hantal bir dağıtım süreci olan bir proje üzerinde çalıştım. Birisi bunu otomatikleştirdi ve komut dosyası, son test sırasında, beklenenden çok daha sık olarak yüzlerce kez çalıştı. İyiydi. + +Öyleyse, neden insanlar geri adım atmak ve otomatikleştirmek için zaman ayırmak yerine aynı görevi tekrar tekrar yapıyorlar? + +## Yaygın yanlış anlama #1: Otomasyon yalnızca test amaçlıdır. + +Elbette, test otomasyonu harika, ama neden orada dursun? Herhangi bir projede tekrarlanan görevler bol miktarda bulunur: sürüm kontrolü, derleme, JAR dosyaları oluşturma, belge oluşturma, dağıtım ve raporlama. Bu görevlerin çoğu için komut dosyası fareden daha güçlüdür. Sıkıcı görevleri yürütmek daha hızlı ve daha güvenilir hale gelir. + +## Yaygın yanlış anlama #2: Bir IDE'm var, bu yüzden otomatikleştirmem gerekmiyor. + +Makinemde hiç "Ama bu (kontrol eder|derlenir|testleri geçer)" oldu mu? takım arkadaşlarınızla tartışır mısınız? Modern IDE'lerin binlerce potansiyel ayarı vardır ve tüm ekip üyelerinin aynı konfigürasyonlara sahip olmasını sağlamak esasen imkansızdır. Ant veya Autotools gibi otomasyon sistemleri oluşturun, size kontrol ve tekrarlanabilirlik sağlar. + +## Yaygın yanlış anlama #3: Otomatikleştirmek için egzotik araçlar öğrenmem gerekiyor. + +İyi bir shell dili (bash veya PowerShell gibi) ve bir yapı otomasyon sistemi ile uzun bir yol kat edebilirsiniz. Web siteleriyle etkileşim kurmanız gerekiyorsa, iMacros veya Selenium gibi bir araç kullanın. + +## Yaygın yanlış anlama #4: Bu dosya formatlarıyla baş edemediğim için bu görevi otomatikleştiremiyorum. + +Sürecinizin bir kısmı Word belgeleri, elektronik tablolar veya resimler gerektiriyorsa, bunu otomatikleştirmek gerçekten zor olabilir. Ama bu gerçekten gerekli mi? Düz metin kullanabilir misiniz? Virgülle ayrılmış değerler? XML? Bir metin dosyasından çizim oluşturan bir araç mı? Çoğu zaman, süreçteki hafif bir ince ayar, sıkıcılıkta önemli bir azalma ile iyi sonuçlar verebilir. + +## Yaygın yanlış anlama #5: Bunu çözecek zamanım yok. + +Başlamak için tüm bash veya Ant'ı öğrenmeniz gerekmez. Gittikçe öğren. Otomatikleştirilebileceğini ve otomatikleştirilmesi gerektiğini düşündüğünüz bir göreviniz olduğunda, bunu yapmak için araçlarınız hakkında yeterince bilgi edinin. Ve bunu, zaman bulmanın genellikle daha kolay olduğu bir projede erken yapın. Başarılı olduğunuzda, siz (ve patronunuz) otomasyona yatırım yapmanın mantıklı olduğunu göreceksiniz. + +[Cay Horstmann](http://programmer.97things.oreilly.com/wiki/index.php/Cay_Horstmann) Tarafından From 116b586628e04d6dbbe2c8f44a639b56dddb721b Mon Sep 17 00:00:00 2001 From: Baran Kaya <0barankaya@gmail.com> Date: Thu, 7 Apr 2022 18:03:58 +0300 Subject: [PATCH 097/290] added thing_79 --- tr/SUMMARY.md | 2 +- tr/thing_79/README.md | 13 +++++++++++++ 2 files changed, 14 insertions(+), 1 deletion(-) create mode 100644 tr/thing_79/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index 17571b5e..d283b002 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -79,7 +79,7 @@ 1. [Tek Sorumluluk İlkesi(The Single Responsibility)](thing_76/README.md) 1. [Evet'ten Başlayın](thing_77/README.md) 1. [Geri Adım Atın ve Otomatikleştirin, Otomatikleştirin, Otomatikleştirin](thing_78/README.md) -1. [Take Advantage of Code Analysis Tools](thing_79/README.md) +1. [Kod Analiz Araçlarından Yararlanın](thing_79/README.md) 1. [Test for Required Behavior, not Incidental Behavior](thing_80/README.md) 1. [Test Precisely and Concretely](thing_81/README.md) 1. [Test While You Sleep (and over Weekends)](thing_82/README.md) diff --git a/tr/thing_79/README.md b/tr/thing_79/README.md new file mode 100644 index 00000000..5679a495 --- /dev/null +++ b/tr/thing_79/README.md @@ -0,0 +1,13 @@ +# Kod Analiz Araçlarından Yararlanın + +Testin değeri, yazılım geliştiricilere programlama yolculuklarının ilk aşamalarından itibaren dahil edilen bir şeydir. Son yıllarda birim testinin, teste dayalı geliştirmenin ve çevik yöntemlerin yükselişi, geliştirme döngüsünün tüm aşamalarında testten en iyi şekilde yararlanmaya olan ilgide bir artış gördü. Ancak test etme, kodun kalitesini artırmak için kullanabileceğiniz birçok araçtan yalnızca biridir. + +Zamanın sisli zamanlarında, C'nin henüz yeni bir fenomen olduğu zamanlarda, CPU zamanı ve her türlü depolama çok değerliydi. İlk C derleyicileri bunun farkındaydı ve bu nedenle bazı anlamsal analizleri kaldırarak yaptıkları koddan geçiş sayısını azalttı. Bu, derleyicinin, derleme zamanında tespit edilebilecek hataların yalnızca küçük bir alt kümesini kontrol ettiği anlamına geliyordu. Bunu telafi etmek için Stephen Johnson, *lint* adlı, kodunuzdaki tüyleri kaldıran bir araç yazdı ve bu araç, kardeş C derleyicisinden kaldırılan bazı statik analizleri uyguladı. Bununla birlikte, statik analiz araçları, her zaman takip edilmesi gerekmeyen üslup kuralları hakkında çok sayıda yanlış pozitif uyarı ve uyarı vermesiyle ün kazandı. + +Mevcut diller, derleyiciler ve statik analiz araçları manzarası çok farklıdır. Bellek ve CPU zamanı artık nispeten ucuzdur, bu nedenle derleyiciler daha fazla hata olup olmadığını kontrol edebilir. Hemen hemen her dilde, stil kılavuzlarının ihlallerini, yaygın yakalamaları ve bazen potansiyel boş gösterici referansları gibi yakalanması zor olabilecek kurnaz hataları kontrol eden en az bir araç bulunur. Splint for C veya Pylint for Python gibi daha karmaşık araçlar yapılandırılabilir, yani aracın bir yapılandırma dosyasıyla, komut satırı anahtarları aracılığıyla veya IDE'nizde hangi hataları ve uyarıları yayınlayacağını seçebilirsiniz. Splint, programınızın nasıl çalıştığı hakkında daha iyi ipuçları vermek için yorumlarda kodunuza açıklama eklemenize bile izin verir. + +Her şey başarısız olursa ve kendinizi derleyiciniz, IDE veya tiftik araçlarınız tarafından yakalanmayan basit hatalar veya standart ihlalleri ararken bulursanız, o zaman her zaman kendi statik denetleyicinizi çalıştırabilirsiniz. Bu kulağa geldiği kadar zor değil. Çoğu dil, özellikle *dinamik* markalı olanlar, standart kitaplıklarının bir parçası olarak soyut sözdizimi ağaçlarını ve derleyici araçlarını sunar. Kullanmakta olduğunuz dilin geliştirme ekibi tarafından kullanılan standart kitaplıkların tozlu köşelerini tanımaya değer, çünkü bunlar genellikle statik analiz ve dinamik testler için yararlı olan gizli mücevherler içerir. Örneğin, Python standart kitaplığı, derlenmiş bir kod veya kod nesnesi oluşturmak için kullanılan bayt kodunu size söyleyen bir ayrıştırıcı içerir. Bu, python-dev ekibindeki derleyici yazarları için belirsiz bir araç gibi görünüyor, ancak aslında günlük durumlarda şaşırtıcı derecede faydalıdır. Bu kitaplığın parçalarına ayırabileceği bir şey, son yığın izlemenizdir ve tam olarak hangi bayt kodu talimatının yakalanmamış son istisnayı attığı konusunda size geri bildirim verir. + +Bu nedenle, testin kalite güvencenizin sonu olmasına izin vermeyin - analiz araçlarından yararlanın ve kendinizinkini kullanmaktan korkmayın. + +[Sarah Mount](http://programmer.97things.oreilly.com/wiki/index.php/Sarah_Mount) Tarafından \ No newline at end of file From e71d2c1d021f6fec3e84d38cfdf4ac9e60a0caa6 Mon Sep 17 00:00:00 2001 From: Baran Kaya <0barankaya@gmail.com> Date: Fri, 8 Apr 2022 14:14:10 +0300 Subject: [PATCH 098/290] added thing_80 --- tr/SUMMARY.md | 2 +- tr/thing_80/README.md | 15 +++++++++++++++ 2 files changed, 16 insertions(+), 1 deletion(-) create mode 100644 tr/thing_80/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index d283b002..5eef15f7 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -80,7 +80,7 @@ 1. [Evet'ten Başlayın](thing_77/README.md) 1. [Geri Adım Atın ve Otomatikleştirin, Otomatikleştirin, Otomatikleştirin](thing_78/README.md) 1. [Kod Analiz Araçlarından Yararlanın](thing_79/README.md) -1. [Test for Required Behavior, not Incidental Behavior](thing_80/README.md) +1. [Tesadüfi Davranış Değil, Gerekli Davranış Testi](thing_80/README.md) 1. [Test Precisely and Concretely](thing_81/README.md) 1. [Test While You Sleep (and over Weekends)](thing_82/README.md) 1. [Testing Is the Engineering Rigor of Software Development](thing_83/README.md) diff --git a/tr/thing_80/README.md b/tr/thing_80/README.md new file mode 100644 index 00000000..358fc93f --- /dev/null +++ b/tr/thing_80/README.md @@ -0,0 +1,15 @@ +# Tesadüfi Davranış Değil, Gerekli Davranış Testi + +Test etmedeki yaygın bir tuzak, bir uygulamanın tam olarak ne yaptığını tam olarak test etmek istediğiniz şey olduğunu varsaymaktır. İlk bakışta bu bir tuzaktan çok bir erdem gibi geliyor. Bununla birlikte, başka bir şekilde ifade edilirse, sorun daha açık hale gelir: Testlerdeki yaygın bir tuzak, testleri bir uygulamanın özelliklerine bağlamaktır, burada bu özellikler tesadüfidir ve istenen işlevsellik üzerinde hiçbir etkisi yoktur. + +Testler, uygulama tesadüflerine bağlı olduğunda, gerekli davranışla gerçekten uyumlu olan uygulamada yapılan değişiklikler, testlerin başarısız olmasına ve yanlış pozitiflere yol açmasına neden olabilir. Programcılar genellikle ya testi yeniden yazarak ya da kodu yeniden yazarak yanıt verirler. Yanlış bir pozitifin aslında gerçek bir pozitif olduğunu varsaymak genellikle korku, belirsizlik veya şüphenin bir sonucudur. Tesadüfi davranışın statüsünü istenen davranışa yükseltme etkisine sahiptir. Bir testi yeniden yazarken, programcılar ya testi gerekli davranışa yeniden odaklarlar (iyi) ya da basitçe yeni uygulamaya (iyi değil) bağlarlar. Testlerin yeterince kesin olması gerekir, ancak aynı zamanda doğru olmaları gerekir. + +Örneğin, C'nin `strcmp` veya Java'nın `String.compareTo` gibi üç yönlü bir karşılaştırmada, sonuçtaki gereksinimler, sol taraf sağdan küçükse negatif, sol taraf sağdan büyükse pozitif ve eşit olarak kabul edilirse sıfır olmasıdır. Bu karşılaştırma stili, C'nin `qsort` işlevi için karşılaştırıcı ve Java'nın `Karşılaştırılabilir` arabirimindeki `compareTo` dahil olmak üzere birçok API'de kullanılır. Belirli `-1` ve `+1` değerleri, uygulamalarda sırasıyla *küçüktür* ve *büyüktür* belirtmek için yaygın olarak kullanılsa da, programcılar sıklıkla yanlışlıkla bu değerlerin gerçek gereksinimi temsil ettiğini varsaymakta ve sonuç olarak bunu sağlayan testler yazmaktadır. + +Benzer bir sorun, boşluk, kesin ifadeler ve metinsel biçimlendirme ve sunumun tesadüfi olan diğer yönlerini öne süren testlerde ortaya çıkar. Örneğin, yapılandırılabilir biçimlendirme sunan bir XML oluşturucu yazmıyorsanız, sonuç için boşluk önemli olmamalıdır. Benzer şekilde, düğmelerin ve etiketlerin UI kontrollerine donanım bağlantısıyla yerleştirilmesi, gelecekte bu olası durumları değiştirme ve iyileştirme seçeneğini azaltır. Uygulamadaki küçük değişiklikler ve biçimlendirmedeki önemsiz değişiklikler aniden yapı kesiciler haline gelir. + +Aşırı belirtilmiş testler, genellikle birim testine yönelik beyaz kutu yaklaşımlarıyla ilgili bir sorundur. Beyaz kutu testleri, gereken test senaryolarını belirlemek için kodun yapısını kullanır. Beyaz kutu testinin tipik başarısızlık modu, testlerin sonunda kodun, kodun yaptığını yaptığını iddia etmesidir. Basitçe, koddan zaten bariz olanı yeniden yazmak hiçbir değer katmaz ve yanlış bir ilerleme ve güvenlik duygusuna yol açar. + +Etkili olması için, testlerin papağan uygulamalarından ziyade sözleşme yükümlülüklerini belirtmesi gerekir. Arayüz sözleşmelerini yürütülebilir biçimde çizerek, test edilen birimlerin kara kutu görünümünü almaları gerekir. Bu nedenle, test edilen davranışı gerekli davranışla hizalayın. + +[Kevlin Henney](http://programmer.97things.oreilly.com/wiki/index.php/Kevlin_Henney) Tarafından \ No newline at end of file From 899da20e623f206de0eb6879a12f78728cd7829a Mon Sep 17 00:00:00 2001 From: Baran Kaya <0barankaya@gmail.com> Date: Tue, 19 Apr 2022 18:22:04 +0300 Subject: [PATCH 099/290] added thing_81 --- tr/thing_81/README.md | 45 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 45 insertions(+) create mode 100644 tr/thing_81/README.md diff --git a/tr/thing_81/README.md b/tr/thing_81/README.md new file mode 100644 index 00000000..60604e47 --- /dev/null +++ b/tr/thing_81/README.md @@ -0,0 +1,45 @@ +# Kesin ve Somut Test Edin + +Belirli bir uygulamanın tesadüfi davranışını test etmek yerine, bir kod biriminin istenen, temel davranışını test etmek önemlidir. Ancak bu, belirsiz testler için bir bahane olarak alınmamalı veya yanlış anlaşılmamalıdır. Testlerin doğru *ve* kesin olması gerekir. + +Denenmiş, test edilmiş ve test edilmiş klasik sıralama rutinlerinden bir şey açıklayıcı bir örnek sunar. Sıralama algoritması uygulamak, bir programcı için mutlaka günlük bir görev değildir, ancak sıralama o kadar tanıdık bir fikirdir ki, çoğu insan ondan ne bekleyeceğini bildiğine inanır. Ancak bu sıradan aşinalık, geçmiş belirli varsayımları görmeyi zorlaştırabilir. + +Programcılara "Neyi test edersiniz?" diye sorulduğunda açık ara en yaygın yanıt "Sıralamanın sonucu, sıralanmış bir öğe dizisidir." Bu doğru olsa da, gerçeğin tamamı bu değildir. Daha kesin bir koşul istendiğinde, birçok programcı, ortaya çıkan dizinin orijinaliyle aynı uzunlukta olması gerektiğini ekler. Doğru olmasına rağmen, bu hala yeterli değil. Örneğin, aşağıdaki sıra verilir: + +``` +3 1 4 1 5 9 +``` + +Aşağıdaki dizi, azalan düzende sıralanmama ve orijinal diziyle aynı uzunluğa sahip olma son koşulunu karşılar: + +``` +3 3 3 3 3 3 +``` + +Spesifikasyonu karşılasa da, kastedilen kesinlikle bu değil! Bu örnek, gerçek üretim kodundan alınan bir hataya dayanmaktadır (neyse ki yayınlanmadan önce yakalanmıştır), burada verilen dizi basit bir tuş vuruşu kayması veya anlık bir mantık hatası, tüm sonucun ilk öğeyle doldurulması için ayrıntılı bir mekanizmaya yol açmıştır. + +Tam son koşul, sonucun sıralanması ve orijinal değerlerin bir permütasyonuna sahip olmasıdır. Bu, gerekli davranışı uygun şekilde kısıtlar. Sonuç uzunluğunun, yıkamada çıkan giriş uzunluğu ile aynı olması ve yeniden ayarlanmasına gerek olmaması. + +Son koşulu tarif edilen şekilde belirtmek bile size iyi bir test vermek için yeterli değildir. İyi bir test okunabilir olmalıdır. Doğru (ya da değil) olduğunu kolayca görebileceğiniz kadar anlaşılır ve basit olmalıdır. Bir dizinin sıralandığını ve bir dizinin diğerinde bir değer permütasyonu içerdiğini kontrol etmek için halihazırda bir kodunuz yoksa, test kodunun test edilen koddan daha karmaşık olması muhtemeldir. Tony Hoare'nin gözlemlediği gibi: + +> Bir yazılım tasarımı oluşturmanın iki yolu vardır: Bir yol, onu *açıkça* hiçbir eksiklik olmayacak kadar basit hale getirmek, diğeri ise onu bariz eksiklikler olmayacak kadar karmaşık hale getirmektir. + +Somut örnekler kullanmak, bu tesadüfi karmaşıklığı ve kaza olasılığını ortadan kaldırır. Örneğin, aşağıdaki sıra verilir: + +``` +3 1 4 1 5 9 +``` + +Sıralamanın sonucu aşağıdaki gibidir: + +``` +1 1 3 4 5 9 +``` + +Başka hiçbir cevap işe yaramayacak. Yedek kabul etmeyin. + +Somut örnekler, genel davranışı erişilebilir ve açık bir şekilde göstermeye yardımcı olur. Boş bir koleksiyona öğe eklemenin sonucu, yalnızca boş olmaması değildir: Koleksiyonun artık tek bir öğeye sahip olmasıdır. Ve tutulan tek öğe, eklenen öğedir. İki veya daha fazla öğe boş değil olarak nitelendirilir. Ve ayrıca yanlış olurdu. Farklı bir değere sahip tek bir öğe de yanlış olur. Bir tabloya bir satır eklemenin sonucu sadece tablonun bir satır daha büyük olması değildir. Ayrıca, eklenen satırı kurtarmak için satırın anahtarının kullanılabileceğini de gerektirir. Ve benzeri. + +Davranışı belirlerken testler basitçe doğru olmamalıdır: Ayrıca kesin olmalıdırlar. + +[Kevlin Henney](http://programmer.97things.oreilly.com/wiki/index.php/Kevlin_Henney) Tarafından \ No newline at end of file From 7ec792bced4bc0c40fd70406e83bf69a0aa3e458 Mon Sep 17 00:00:00 2001 From: Baran Kaya <0barankaya@gmail.com> Date: Tue, 19 Apr 2022 18:27:31 +0300 Subject: [PATCH 100/290] added thing_82 --- tr/SUMMARY.md | 4 ++-- tr/thing_82/README.md | 15 +++++++++++++++ 2 files changed, 17 insertions(+), 2 deletions(-) create mode 100644 tr/thing_82/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index 5eef15f7..cc63801d 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -81,8 +81,8 @@ 1. [Geri Adım Atın ve Otomatikleştirin, Otomatikleştirin, Otomatikleştirin](thing_78/README.md) 1. [Kod Analiz Araçlarından Yararlanın](thing_79/README.md) 1. [Tesadüfi Davranış Değil, Gerekli Davranış Testi](thing_80/README.md) -1. [Test Precisely and Concretely](thing_81/README.md) -1. [Test While You Sleep (and over Weekends)](thing_82/README.md) +1. [Kesin ve Somut Test Edin](thing_81/README.md) +1. [Uyurken (ve Hafta Sonları) Test Edin](thing_82/README.md) 1. [Testing Is the Engineering Rigor of Software Development](thing_83/README.md) 1. [Thinking in States](thing_84/README.md) 1. [Two Heads Are Often Better than One](thing_85/README.md) diff --git a/tr/thing_82/README.md b/tr/thing_82/README.md new file mode 100644 index 00000000..0b91e6c6 --- /dev/null +++ b/tr/thing_82/README.md @@ -0,0 +1,15 @@ +# Uyurken (ve Hafta Sonları) Test Edin + +Rahatlayın. Açık deniz geliştirme merkezlerinden, hafta sonları fazla mesaiden veya gece vardiyasında çalışmaktan bahsetmiyorum. Bunun yerine, dikkatinizi elimizde ne kadar bilgi işlem gücüne sahip olduğumuza çekmek istiyorum. Spesifik olarak, programcılar olarak hayatımızı biraz daha kolaylaştırmak için ne kadarını kullanmadığımız. İş günü boyunca yeterli bilgi işlem gücü elde etmekte sürekli olarak zorlanıyor musunuz? Öyleyse, test sunucularınız normal çalışma saatleri dışında ne yapıyor? Çoğu zaman, test sunucuları gece boyunca ve hafta sonu boşta kalıyor. Bunu kendi avantajınıza kullanabilirsiniz. + +- *Tüm testleri çalıştırmadan bir değişiklik yaptığınız için suçlu mu oldunuz?* Programcıların kod işlemeden önce test takımlarını çalıştırmamalarının ana nedenlerinden biri, uzun zaman alabilecekleridir. Son teslim tarihleri yaklaştığında ve zorlama geldiğinde, insanlar doğal olarak köşeleri kesmeye başlar. Bunu çözmenin bir yolu, büyük test takımınızı iki veya daha fazla profile bölmektir. Hızlı çalıştırılabilen daha küçük, zorunlu bir test profili, testlerin her taahhütten önce çalıştırılmasını sağlamaya yardımcı olacaktır. Tüm test profilleri (zorunlu profil dahil - emin olmak için), gece boyunca çalışacak ve sabah sonuçlarını rapor etmeye hazır olacak şekilde otomatikleştirilebilir. + +- *Ürününüzün kararlılığını test etmek için yeterli fırsatınız oldu mu?* Daha uzun süren testler, bellek sızıntılarını ve diğer kararlılık sorunlarını belirlemek için hayati önem taşır. Zaman ve kaynakları bağlayacağı için nadiren gün içinde çalıştırılırlar. Gece boyunca ve hafta sonu boyunca biraz daha uzun süre çalıştırılacak bir ıslatma testini otomatikleştirebilirsiniz. Cuma günü 18:00'den bir sonraki Pazartesi günü saat 18:00'e kadar 60 saatlik potansiyel test süresi vardır. + +- *Performans testi ortamınızda kaliteli zaman alıyor musunuz?* Performans testi ortamında zaman kazanmak için birbirleriyle çekişen takımlar gördüm. Çoğu durumda, her iki takım da gün içinde yeterince kaliteli zaman geçiremezken, ortam saatler sonra neredeyse boşta kalır. Sunucular ve ağ, gece veya hafta sonu o kadar meşgul değil. Bazı kalite performans testleri yapmak için ideal bir zaman. + +- *Manuel olarak test etmek için çok fazla permütasyon var mı?* Çoğu durumda ürününüzün çeşitli platformlarda çalışması hedeflenir. Örneğin, hem 32 bit hem de 64 bit, Linux, Solaris ve Windows'ta veya yalnızca aynı işletim sisteminin farklı sürümlerinde. Daha da kötüsü, birçok modern uygulama kendilerini çok sayıda taşıma mekanizmasına ve protokolüne (HTTP, AMQP, SOAP, CORBA, vb.) Tüm bu permütasyonların manuel olarak test edilmesi çok zaman alıcıdır ve büyük olasılıkla kaynak baskısı nedeniyle bir sürüme yakın bir zamanda yapılır. Ne yazık ki, bazı hataları yakalamak için döngüde çok geç olabilir. + +Geceleri veya hafta sonları yapılan otomatik testler, tüm bu permütasyonların daha sık test edilmesini sağlayacaktır. Biraz düşünme ve biraz komut dosyası bilgisi ile, geceleri ve hafta sonu bazı testleri başlatmak için birkaç *cron* işi planlayabilirsiniz. Ayrıca yardımcı olabilecek birçok test aracı vardır. Hatta bazı kuruluşlar, kaynakların verimli bir şekilde kullanılmasını sağlamak için sunucuları farklı departmanlar ve ekipler arasında bir araya getiren sunucu ızgaralarına bile sahiptir. Bu, kuruluşunuzda mevcutsa, geceleri veya hafta sonları çalıştırılmak üzere testler gönderebilirsiniz. + +[Rajith Attapattu](http://programmer.97things.oreilly.com/wiki/index.php/Rajith_Attapattu) Tarafından \ No newline at end of file From 65aeab59116ccc06bd23c82e38bf41c7213b89b4 Mon Sep 17 00:00:00 2001 From: Baran Kaya <0barankaya@gmail.com> Date: Tue, 19 Apr 2022 18:35:41 +0300 Subject: [PATCH 101/290] added thing_83 --- tr/SUMMARY.md | 2 +- tr/thing_83/README.md | 11 +++++++++++ 2 files changed, 12 insertions(+), 1 deletion(-) create mode 100644 tr/thing_83/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index cc63801d..1a2921e3 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -83,7 +83,7 @@ 1. [Tesadüfi Davranış Değil, Gerekli Davranış Testi](thing_80/README.md) 1. [Kesin ve Somut Test Edin](thing_81/README.md) 1. [Uyurken (ve Hafta Sonları) Test Edin](thing_82/README.md) -1. [Testing Is the Engineering Rigor of Software Development](thing_83/README.md) +1. [Test, Yazılım Geliştirmenin Mühendislik Zorluğudur](thing_83/README.md) 1. [Thinking in States](thing_84/README.md) 1. [Two Heads Are Often Better than One](thing_85/README.md) 1. [Two Wrongs Can Make a Right (and Are Difficult to Fix)](thing_86/README.md) diff --git a/tr/thing_83/README.md b/tr/thing_83/README.md new file mode 100644 index 00000000..7004bcfa --- /dev/null +++ b/tr/thing_83/README.md @@ -0,0 +1,11 @@ +# Test, Yazılım Geliştirmenin Mühendislik Zorluğudur + +Geliştiriciler, aile üyelerine, eşlere ve diğer teknik olmayanlara ne yaptıklarını açıklamaya çalışırken işkence görmüş metaforları kullanmayı severler. Sıklıkla köprü inşasına ve diğer "zor" mühendislik disiplinlerine başvururuz. Tüm bu metaforlar, onları çok fazla zorlamaya başladığınızda hızla düşüyor. Yazılım geliştirmenin birçok önemli yönden "zor" mühendislik disiplinlerinin çoğu gibi *olmadığı* ortaya çıktı. + +"Zor" mühendislikle karşılaştırıldığında, yazılım geliştirme dünyası, ortak stratejinin bir köprü inşa etmek ve ardından üzerinde ağır bir şey yuvarlamak olduğu zamanki köprü inşaatçılarının bulunduğu yerdedir. Kalırsa, iyi bir köprüydü. Değilse, çizim tahtasına geri dönme zamanı. Son birkaç bin yılda mühendisler, ne yaptığını görmek için inşa etmek zorunda kalmadan yapısal bir çözüm için kullanabilecekleri matematik ve fizik geliştirdiler. Yazılımda böyle bir şeye sahip değiliz ve belki de asla olmayacak çünkü yazılım aslında çok farklı. Yazılım "mühendisliği" ile normal mühendislik arasındaki karşılaştırmanın derinlemesine bir incelemesi için, ["Yazılım Tasarımı Nedir?"](http://www.developerdotstar.com/mag/articles/reeves_design.html), Jack tarafından yazılmıştır. 1992'de *C++ Journal*'da yayınlanan Reeves, bir klasiktir. Neredeyse yirmi yıl önce yazılmış olmasına rağmen, yine de dikkate değer ölçüde doğrudur. Bu karşılaştırmada kasvetli bir tablo çizdi, ancak 1992'de eksik olan şey, yazılım için güçlü bir test etme anlayışıydı. + +"Zor" şeyleri test etmek zordur çünkü onları test etmek için inşa etmeniz gerekir, bu da sadece ne olacağını görmek için spekülatif yapıyı caydırır. Ancak yazılımdaki yapım süreci gülünç derecede ucuzdur. Bunu yapmayı kolaylaştıran eksiksiz bir araçlar ekosistemi geliştirdik: birim testi, sahte nesneler, test koşum takımları ve daha birçok şey. Diğer mühendisler, bir şeyler inşa etmeyi ve gerçekçi koşullar altında test etmeyi çok isterdi. Yazılım geliştiricileri olarak, yazılımın birincil (ancak tek değil) doğrulama mekanizması olarak testi benimsememiz gerekir. Yazılım için bir tür hesap beklemek yerine, iyi mühendislik uygulamalarını sağlamak için zaten elimizde araçlar var. Bu açıdan bakıldığında, "Test için zamanımız yok" diyen yöneticilere karşı artık mühimmatımız var. Bir köprü inşaatçısı patronundan asla "O bina üzerinde yapısal analiz yapmakla uğraşmayın - son teslim tarihimiz kısıtlı" diye bir şey duymaz. Testin gerçekten de yazılımda tekrarlanabilirlik ve kaliteye giden yol olduğunun kabul edilmesi, geliştiriciler olarak bize, profesyonel olarak sorumsuz olduğu için buna karşı çıkan argümanları geri itmemize izin veriyor. + +Yapısal analizin zaman alması gibi, test etme de zaman alır. Her iki faaliyet de nihai ürünün kalitesini garanti eder. Yazılım geliştiricilerin ürettikleri şeyin sorumluluğunu üstlenmelerinin zamanı geldi. Tek başına test etmek yeterli değildir, ancak gereklidir. * **Test etme** * yazılım geliştirmenin mühendislik titizliğidir. + +[Neal Ford](http://programmer.97things.oreilly.com/wiki/index.php/Neal_Ford) Tarafından \ No newline at end of file From 8fe5f17ea773b40e151140fd74b4b6036c71519f Mon Sep 17 00:00:00 2001 From: Baran Kaya <0barankaya@gmail.com> Date: Wed, 20 Apr 2022 18:20:50 +0300 Subject: [PATCH 102/290] added thing_84 --- tr/SUMMARY.md | 2 +- tr/thing_84/README.md | 39 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 40 insertions(+), 1 deletion(-) create mode 100644 tr/thing_84/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index 1a2921e3..b6ce4eda 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -84,7 +84,7 @@ 1. [Kesin ve Somut Test Edin](thing_81/README.md) 1. [Uyurken (ve Hafta Sonları) Test Edin](thing_82/README.md) 1. [Test, Yazılım Geliştirmenin Mühendislik Zorluğudur](thing_83/README.md) -1. [Thinking in States](thing_84/README.md) +1. [Durumlarda Düşünmek](thing_84/README.md) 1. [Two Heads Are Often Better than One](thing_85/README.md) 1. [Two Wrongs Can Make a Right (and Are Difficult to Fix)](thing_86/README.md) 1. [Ubuntu Coding for Your Friends](thing_87/README.md) diff --git a/tr/thing_84/README.md b/tr/thing_84/README.md new file mode 100644 index 00000000..6e925682 --- /dev/null +++ b/tr/thing_84/README.md @@ -0,0 +1,39 @@ +# Durumlarda Düşünmek + +Gerçek dünyadaki insanların durumla tuhaf bir ilişkisi var. Bu sabah kafeini koda dönüştürmek için başka bir güne hazırlanmak için yerel mağazaya uğradım. Bunu yapmanın en sevdiğim yolu latte içmek olduğundan ve hiç süt bulamadığım için görevliye sordum. + +"Üzgünüm, süper kandırıldık, sütüm bitti." + +Bir programcı için bu garip bir ifade. Ya sütünüz bitmiştir ya da bitmemiştir. Sütün bitmesi söz konusu olduğunda ölçek yoktur. Belki de bana bir hafta sütlerinin biteceğini söylemeye çalışıyordu ama sonuç benim için aynıydı, espresso günü. + +Çoğu gerçek dünya durumunda, insanların duruma karşı rahat tavırları bir sorun değildir. Ne yazık ki, birçok programcı durum konusunda da oldukça belirsizdir ve bu bir problemdir. + +Bu yöntemi içeren bir `Order` sınıfıyla, yalnızca kredi kartlarını kabul eden ve müşterilere fatura kesmeyen basit bir web mağazasını düşünün: + +``` + public boolean isComplete() { + return isPaid() && hasShipped(); + } +``` + +Makul, değil mi? Eh, ifade her yere kopyala yapıştır yerine güzel bir şekilde bir yönteme ayıklansa bile, ifade hiç var olmamalıdır. Gerçek şu ki, bir sorunu vurgular. Niye? Çünkü bir sipariş, ödemesi yapılmadan kargoya verilemez. Bu nedenle, `isPaid` doğru olmadığı sürece `hasShipped` doğru olamaz, bu da ifadenin bir kısmını gereksiz kılar. Yine de kodda netlik için `isComplete` isteyebilirsiniz, ancak o zaman şöyle görünmelidir: + +``` + public boolean isComplete() { + return hasShipped(); + } +``` + +İşimde her zaman hem eksik hem de gereksiz çek görüyorum. Bu örnek küçük, ancak iptal ve geri ödemeyi eklediğinizde, daha karmaşık hale gelecek ve iyi durum işleme ihtiyacı artar. Bu durumda, bir sipariş yalnızca üç farklı durumdan birinde olabilir: + +- *Devam ediyor(In progress):* Öğe ekleyebilir veya kaldırabilir. Gönderilemiyor. +- *Ücretli(Paid):* Öğe eklenemez veya kaldırılamaz. Sevk edilebilir. +- *Gönderildi(Shipped):* Bitti. Daha fazla değişiklik kabul edilmedi. + +Bu durumlar önemlidir ve işlem yapmadan önce beklenen durumda olduğunuzu ve bulunduğunuz yerden sadece yasal bir duruma geçtiğinizi kontrol etmeniz gerekir. Kısacası eşyalarınızı dikkatli bir şekilde, doğru yerlerde korumalısınız. + +Ama durumlarda düşünmeye nasıl başlarsınız? İfadeleri anlamlı yöntemlere çıkarmak çok iyi bir başlangıç, ancak bu sadece bir başlangıç. Temel, durum makinelerini anlamaktır. CS sınıfından kötü anıların olabileceğini biliyorum ama onları geride bırak. Durum makineleri özellikle zor değildir. Kolay anlaşılır ve konuşulması kolay hale getirmek için onları görselleştirin. Geçerli ve geçersiz durumları ve geçişleri ortaya çıkarmak ve bunları doğru tutmak için kodunuzu test edin. Durum modelini inceleyin. Kendinizi rahat hissettiğinizde, Sözleşmeye Göre Tasarım'ı okuyun. Her genel yöntemin giriş ve çıkışında gelen verileri ve nesnenin kendisini doğrulayarak geçerli bir durum sağlamanıza yardımcı olur. + +Durumunuz yanlışsa, bir hata vardır ve iptal etmezseniz verileri çöpe atma riskiniz vardır. Durum kontrollerini parazit olarak bulursanız, bunları gizlemek için bir aracın, kod oluşturmanın, dokumanın veya yönlerin nasıl kullanılacağını öğrenin. Hangi yaklaşımı seçerseniz seçin, durumlar halinde düşünmek kodunuzu daha basit ve daha sağlam hale getirecektir. + +[Niclas Nilsson](http://programmer.97things.oreilly.com/wiki/index.php/Niclas_Nilsson) Tarafından \ No newline at end of file From faaba8aa0bb4fd4cd191a1adc23805a14afa6d49 Mon Sep 17 00:00:00 2001 From: Baran Kaya <0barankaya@gmail.com> Date: Fri, 22 Apr 2022 17:25:39 +0300 Subject: [PATCH 103/290] added thing_85 --- tr/SUMMARY.md | 2 +- tr/thing_85/README.md | 23 +++++++++++++++++++++++ 2 files changed, 24 insertions(+), 1 deletion(-) create mode 100644 tr/thing_85/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index b6ce4eda..f99b441f 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -85,7 +85,7 @@ 1. [Uyurken (ve Hafta Sonları) Test Edin](thing_82/README.md) 1. [Test, Yazılım Geliştirmenin Mühendislik Zorluğudur](thing_83/README.md) 1. [Durumlarda Düşünmek](thing_84/README.md) -1. [Two Heads Are Often Better than One](thing_85/README.md) +1. [İki Kafa Çoğu Zaman Bir Kafadan Daha İyidir](thing_85/README.md) 1. [Two Wrongs Can Make a Right (and Are Difficult to Fix)](thing_86/README.md) 1. [Ubuntu Coding for Your Friends](thing_87/README.md) 1. [The Unix Tools Are Your Friends](thing_88/README.md) diff --git a/tr/thing_85/README.md b/tr/thing_85/README.md new file mode 100644 index 00000000..4803b7c9 --- /dev/null +++ b/tr/thing_85/README.md @@ -0,0 +1,23 @@ +# İki Kafa Çoğu Zaman Bir Kafadan Daha İyidir + +Programlama derin düşünce gerektirir ve derin düşünce yalnızlık gerektirir. Programcı klişesi de öyle. + +Programlamaya yönelik bu "yalnız kurt" yaklaşımı, yerini daha işbirlikçi bir yaklaşıma bırakıyor ve bunun da programcılar için kaliteyi, üretkenliği ve iş tatminini iyileştirdiğini iddia ediyorum. Bu yaklaşım, geliştiricilerin birbirleriyle ve ayrıca geliştirici olmayanlarla (iş ve sistem analistleri, kalite güvence uzmanları ve kullanıcılar) daha yakın çalışmasına sahiptir. + +Bu geliştiriciler için ne anlama geliyor? Uzman teknoloji uzmanı olmak artık yeterli değil. Başkalarıyla çalışmak konusunda etkili olmalısınız. + +İşbirliği, soru sorup cevaplamak veya toplantılarda oturmakla ilgili değildir. İşe ortaklaşa saldırmak için başka biriyle kolları sıvamakla ilgili. + +Çift programlamanın(pair programming) büyük bir hayranıyım. Buna "aşırı işbirliği" diyebilirsiniz. Bir geliştirici olarak, eşleştirme yaptığımda becerilerim artıyor. Alanda veya teknolojide, partnerimden daha zayıfsam, onun deneyimlerinden açıkça öğrenirim. Bir yönden daha güçlü olduğumda, kendimi açıklamak zorunda kalarak bildiklerim ve bilmediklerim hakkında daha fazla şey öğreniyorum. Her zaman ikimiz de masaya bir şeyler getiriyoruz ve birbirimizden öğreniyoruz. + +Eşleştirirken, her birimiz ortak programlama deneyimlerimizi teknik olduğu kadar etki alanı da eldeki soruna getiriyoruz ve etkin ve verimli bir şekilde yazılım yazmak için benzersiz bir anlayış ve deneyim getirebiliriz. Alan veya teknik bilgide aşırı dengesizlik durumlarında bile, daha deneyimli katılımcı her zaman diğerinden bir şeyler öğrenir, belki yeni bir klavye kısayolu veya yeni bir araç veya kitaplığa maruz kalma. Çiftin daha az deneyimli üyesi için bu, hız kazanmanın harika bir yoludur. + +Eşli programlama, çevik yazılım geliştirme savunucularına özel olmasa da popülerdir. Eşleştirmeye itiraz edenler, "Neden bir programcının işini yapması için iki programcıya para ödeyeyim?" diye soruyor. Benim yanıtım, aslında, yapmamalısın. Eşleştirmenin kaliteyi, etki alanı ve teknolojiyi, teknikleri (IDE hileleri gibi) artırdığını ve piyango riskinin etkisini azalttığını (uzman geliştiricilerinizden biri piyangoyu kazanır ve ertesi gün bırakır) savunuyorum. + +Yeni bir klavye kısayolu öğrenmenin uzun vadeli değeri nedir? Eşleştirmeden kaynaklanan üründeki genel kalite iyileştirmesini nasıl ölçeriz? Ortağınızın zor bir sorunu çözmek için çıkmaz bir yaklaşım izlemenize izin vermemesinin etkisini nasıl ölçeriz? Bir çalışma, etkinlik ve hızda %40'lık bir artış olduğunu belirtiyor (J T Nosek, "The Case for Collaborative Programming", *Communications of the ACM*, Mart 1998). "Piyango riskinizi" azaltmanın değeri nedir? Bu kazanımların çoğunu ölçmek zordur. + +Kim kiminle eşleşmeli? Ekipte yeniyseniz, bilgili bir ekip üyesi bulmak önemlidir. Kişilerarası ve koçluk becerileri iyi olan birini bulmak da aynı derecede önemlidir. Çok fazla alan deneyiminiz yoksa, alan adında uzman bir ekip üyesiyle eşleştirin. + +İkna değilseniz, deneyin: iş arkadaşlarınızla işbirliği yapın. İlginç bir problem üzerinde eşleştirin. Nasıl hissettirdiğini görün. Birkaç kez deneyin. + +[Adrian Wible](http://programmer.97things.oreilly.com/wiki/index.php/Adrian_Wible) Tarafından \ No newline at end of file From 548284fb4ca2b6549c6b8ab51a098636d05471ef Mon Sep 17 00:00:00 2001 From: Baran Kaya <0barankaya@gmail.com> Date: Fri, 22 Apr 2022 17:35:09 +0300 Subject: [PATCH 104/290] added thing_86 --- tr/SUMMARY.md | 2 +- tr/thing_86/README.md | 23 +++++++++++++++++++++++ 2 files changed, 24 insertions(+), 1 deletion(-) create mode 100644 tr/thing_86/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index f99b441f..a5569b3e 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -86,7 +86,7 @@ 1. [Test, Yazılım Geliştirmenin Mühendislik Zorluğudur](thing_83/README.md) 1. [Durumlarda Düşünmek](thing_84/README.md) 1. [İki Kafa Çoğu Zaman Bir Kafadan Daha İyidir](thing_85/README.md) -1. [Two Wrongs Can Make a Right (and Are Difficult to Fix)](thing_86/README.md) +1. [İki Yanlış Bir Doğru Yapabilir (ve Düzeltilmesi Zordur)](thing_86/README.md) 1. [Ubuntu Coding for Your Friends](thing_87/README.md) 1. [The Unix Tools Are Your Friends](thing_88/README.md) 1. [Use the Right Algorithm and Data Structure](thing_89/README.md) diff --git a/tr/thing_86/README.md b/tr/thing_86/README.md new file mode 100644 index 00000000..3012c4a0 --- /dev/null +++ b/tr/thing_86/README.md @@ -0,0 +1,23 @@ +# İki Yanlış Bir Doğru Yapabilir (ve Düzeltilmesi Zordur) + +Kod asla yalan söylemez ama kendi kendisiyle çelişebilir. Bazı çelişkiler "Bu nasıl olabilir?" sorusuna yol açar. anlar. + +Bir [röportajda](http://www.netjeff.com/humor/item.cgi?file=ApolloComputer), Apollo 11 Ay Modülü yazılımının baş tasarımcısı Allan Klumpp, motorları kontrol eden yazılımın, iniş aracını kararsız hale getirmesi gereken bir hata içerdiğini açıkladı. Ancak, başka bir hata ilkini telafi etti ve yazılım, hata bulunmadan veya düzeltilmeden önce hem Apollo 11 hem de 12 Ay inişleri için kullanıldı. + +Bir tamamlanma durumu döndüren bir işlev düşünün. true döndürmesi gerektiğinde false döndürdüğünü hayal edin. Şimdi(now) çağıran fonksiyonun dönüş değerini kontrol etmeyi ihmal ettiğini hayal edin. Bir gün biri eksik çeki fark edip onu yerleştirene kadar her şey yolunda gider. + +Veya durumu bir XML belgesi olarak depolayan bir uygulamayı düşünün. Düğümlerden birinin, belgelerin olması gerektiği gibi, `TimeToDie` yerine `TimeToLive` olarak yanlış yazıldığını hayal edin. Hem yazar kodu hem de okuyucu kodu aynı hatayı içeriyorken her şey yolunda görünüyor. Ancak birini düzeltin veya aynı belgeyi okuyan yeni bir uygulama ekleyin ve simetri ve kod bozulur. + +Koddaki iki kusur, tek bir görünür hata oluşturduğunda, hataları düzeltmeye yönelik metodik yaklaşım kendi kendine çökebilir. Geliştirici bir hata raporu alır, hatayı bulur, düzeltir ve yeniden test eder. Bildirilen hata yine de ortaya çıkıyor, çünkü ikinci bir hata çalışıyor. Böylece ilk düzeltme kaldırılır, ikinci temel kusur bulunana kadar kod incelenir ve bunun için bir düzeltme uygulanır. Ancak ilk hata geri döndü, bildirilen hata hala görülüyor ve bu nedenle ikinci düzeltme geri alındı. Süreç tekrar ediyor, ancak şimdi geliştirici iki olası düzeltmeyi reddetti ve asla işe yaramayacak bir üçüncüsü yapmak istiyor. + +Görünür bir hata olarak görünen iki kod hatası arasındaki etkileşim, yalnızca sorunu çözmeyi zorlaştırmakla kalmaz, aynı zamanda geliştiricileri çıkmaz sokaklara sürükler, yalnızca doğru yanıtları erkenden denediklerini bulmak için. + +Bu sadece kodda olmaz: Sorun yazılı gereksinim belgelerinde de mevcuttur. Ve viral olarak bir yerden diğerine yayılabilir. Koddaki bir hata, yazılı açıklamadaki bir hatayı telafi eder. + +İnsanlara da yayılabilir: Kullanıcılar, uygulama Sol dediğinde Sağ anlamına geldiğini öğrenir ve davranışlarını buna göre ayarlar. Hatta bunu yeni kullanıcılara iletiyorlar: "Unutmayın, uygulamalar sol düğmeyi tıklayın diyorsa, bu gerçekten sağdaki düğme anlamına gelir." Hatayı düzeltin ve aniden kullanıcıların yeniden eğitilmesi gerekir. + +Tek bir yanlışın fark edilmesi ve düzeltilmesi kolay olabilir. Çözülmesi daha zor olan, birden çok nedeni olan, birden çok değişikliğe ihtiyaç duyan sorunlardır. Kısmen, kolay problemler o kadar kolay çözülür ki, insanlar onları nispeten hızlı bir şekilde düzeltmeye ve daha zor problemleri daha sonraki bir tarihe saklamaya eğilimlidir. + +Sempatik kusurlardan kaynaklanan arızaların nasıl ele alınacağı konusunda verilecek basit bir tavsiye yoktur. Olasılığın farkında olmak, açık bir kafa ve tüm olasılıkları değerlendirmeye istekli olmak gereklidir. + +[Allan Kelly](http://programmer.97things.oreilly.com/wiki/index.php/Allan_Kelly) Tarafından \ No newline at end of file From 3c3c1515cf26b0ffc9a609e3d9fe9b757af51271 Mon Sep 17 00:00:00 2001 From: Baran Kaya <0barankaya@gmail.com> Date: Fri, 22 Apr 2022 17:41:29 +0300 Subject: [PATCH 105/290] added thing_87 --- tr/SUMMARY.md | 2 +- tr/thing_87/README.md | 15 +++++++++++++++ 2 files changed, 16 insertions(+), 1 deletion(-) create mode 100644 tr/thing_87/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index a5569b3e..97d3df97 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -87,7 +87,7 @@ 1. [Durumlarda Düşünmek](thing_84/README.md) 1. [İki Kafa Çoğu Zaman Bir Kafadan Daha İyidir](thing_85/README.md) 1. [İki Yanlış Bir Doğru Yapabilir (ve Düzeltilmesi Zordur)](thing_86/README.md) -1. [Ubuntu Coding for Your Friends](thing_87/README.md) +1. [Arkadaşlarınız İçin Ubuntu Kodlama](thing_87/README.md) 1. [The Unix Tools Are Your Friends](thing_88/README.md) 1. [Use the Right Algorithm and Data Structure](thing_89/README.md) 1. [Verbose Logging Will Disturb Your Sleep](thing_90/README.md) diff --git a/tr/thing_87/README.md b/tr/thing_87/README.md new file mode 100644 index 00000000..36bc3f44 --- /dev/null +++ b/tr/thing_87/README.md @@ -0,0 +1,15 @@ +# Arkadaşlarınız İçin Ubuntu Kodlama + +Sıklıkla kodu ayrı ayrı yazarız ve kod, çok kişiselleştirilmiş bir çözümün yanı sıra bir soruna ilişkin kişisel yorumumuzu da yansıtır. Ekibin bir parçası olabiliriz, ancak ekip olarak izole edilmiş durumdayız. Ayrı ayrı oluşturulan bu kodun başkaları tarafından yürütüleceğini, kullanılacağını, genişletileceğini ve güvenileceğini çok kolay unutuyoruz. Yazılım oluşturmanın sosyal yönünü gözden kaçırmak kolaydır. Yazılım oluşturmak, sosyal bir alıştırmayla karıştırılmış teknik bir alıştırmadır. Tek başına çalışmadığımızı anlamak için başımızı daha sık kaldırmamız gerekiyor ve sadece geliştirme ekibi için değil herkes için başarı olasılığını artırma konusunda ortak sorumluluğumuz var. + +Kendi içinde kaybolurken, izolasyonda kaliteli kod yazabilirsiniz. Bir perspektiften, bu benmerkezci bir yaklaşımdır (kibirli olduğu gibi *ego* değil, kişisel olduğu gibi *ego*). Aynı zamanda bir Zen görünümüdür ve kod oluşturma anında sizinle ilgilidir. Her zaman anı yaşamaya çalışıyorum çünkü bu benim iyi kaliteye yaklaşmama yardımcı oluyor ama sonra *benim* anımda yaşıyorum. Peki ya ekibimin anı? Benim anım takımın anıyla aynı mı? + +Zulu'da Ubuntu felsefesi, kabaca "Bir kişi (diğer) kişiler aracılığıyla bir kişidir" anlamına gelen "Umuntu ngumuntu ngabantu" olarak özetlenir. İyileşiyorum çünkü beni iyi davranışlarınla iyileştiriyorsun. Diğer tarafı, yaptığım şeyde kötü olduğumda yaptığın şeyde daha da kötüleşiyorsun. Geliştiriciler arasında, bunu "Bir geliştirici (diğer) geliştiriciler aracılığıyla bir geliştiricidir" şeklinde daraltabiliriz. Metale indirirsek, "Kod (diğer) kod aracılığıyla koddur." + +Yazdığım kodun kalitesi yazdığınız kodun kalitesini etkiler. Ya kodum kalitesiz ise? Çok temiz kod yazsanız bile, kodumu kullandığınız noktalar, kod kalitenizin benim kodumun kalitesine yakın düşecektir. Hasarı sınırlamak için birçok desen ve teknik uygulayabilirsiniz, ancak hasar zaten yapılmıştır. Sırf anımı yaşarken seni düşünmediğim için yapman gerekenden fazlasını yapmana sebep oldum. + +Kodumun temiz olduğunu düşünebilirim, ancak yine de sadece Ubuntu kodlamasıyla daha iyi hale getirebilirim. Ubuntu kodu neye benziyor? Sadece iyi temiz kod gibi görünüyor. Bu kodla, yapaylıkla ilgili değil. Bu, o eseri yaratma eylemiyle ilgilidir. Ubuntu ile arkadaşlarınız için kodlama yapmak, ekibinizin değerlerinizi yaşamasına ve ilkelerinizi pekiştirmesine yardımcı olacaktır. Her ne şekilde olursa olsun kodunuza dokunan bir sonraki kişi daha iyi bir insan ve daha iyi bir geliştirici olacaktır. + +Zen bireyle ilgilidir. Ubuntu, bir grup insan için Zen ile ilgilidir. Çok, çok nadiren sadece kendimiz için kod oluşturuyoruz. + +[Aslam Khan](http://programmer.97things.oreilly.com/wiki/index.php/Aslam_Khan) Tarafından \ No newline at end of file From 9f3920e1454985a49f3ea68ad17d641f8345252a Mon Sep 17 00:00:00 2001 From: romanenko-ivan <82770629+romanenko-ivan@users.noreply.github.com> Date: Mon, 25 Apr 2022 15:46:08 +0300 Subject: [PATCH 106/290] Remove grammar error from Russian localization --- ru/thing_30/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ru/thing_30/README.md b/ru/thing_30/README.md index 3d3f61fe..6e91fa04 100644 --- a/ru/thing_30/README.md +++ b/ru/thing_30/README.md @@ -15,7 +15,7 @@ } ``` -Выглядит логично, не так ли? Однако если даже выражение красиво завернуто в метод вмето того, чтобы быть множество раз скопипасченым по всему коду, этого выражения не должно было вообще быть. То, что оно существует, показывает наличие проблемы. Почему? Потому что заказ не может быть доставлен, пока он не будет оплачен. Поэтому `hasShipped` не может стать true до того, как `isPaid` станет true, что делает выражение избыточным. Возможно, вы все равно захотите оставить метод `isComplete` для ясности кода, но он должен при этом выглядеть вот так: +Выглядит логично, не так ли? Однако если даже выражение красиво завернуто в метод вмеcто того, чтобы быть множество раз скопипасченым по всему коду, этого выражения не должно было вообще быть. То, что оно существует, показывает наличие проблемы. Почему? Потому что заказ не может быть доставлен, пока он не будет оплачен. Поэтому `hasShipped` не может стать true до того, как `isPaid` станет true, что делает выражение избыточным. Возможно, вы все равно захотите оставить метод `isComplete` для ясности кода, но он должен при этом выглядеть вот так: ``` public boolean isComplete() { @@ -35,4 +35,4 @@ Если вы обнаружили, что находитесь в неразрешенном состоянии, значит, произошла ошибка и вы рискуете потерять все данные, если не остановите выполнение. Если постоянные проверки состояния будет вносить слишком много шума, изучите возможность использования автоматической генерации кода или аспектного программирования (weaving), чтобы скрыть их. И независимо от того, какой механизм вы выберете, мышление категориями состояний поможет вам сделать ваш код более простым и надежным. -Автор оригинала - [Niclas Nilsson](http://programmer.97things.oreilly.com/wiki/index.php/Niclas_Nilsson) \ No newline at end of file +Автор оригинала - [Niclas Nilsson](http://programmer.97things.oreilly.com/wiki/index.php/Niclas_Nilsson) From a3a2fe7d87d38e3cd5465afe7300750fcc31434d Mon Sep 17 00:00:00 2001 From: romanenko-ivan <82770629+romanenko-ivan@users.noreply.github.com> Date: Mon, 25 Apr 2022 16:53:40 +0300 Subject: [PATCH 107/290] Update Russian localization for thing 31 I think the old version has a confusing meaning. My version is more clear. --- ru/thing_31/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ru/thing_31/README.md b/ru/thing_31/README.md index 4fd8ddf1..30447f97 100644 --- a/ru/thing_31/README.md +++ b/ru/thing_31/README.md @@ -7,7 +7,7 @@ Лучший способ выяснить, как именно действуют пользователи, это понаблюдать за одним из них. Попросите пользователя выполнить какую-нибудь задачу при помощи ПО, похожего на разрабатываемое вами. Задача должна быть реальной. «Добавьте колонку с цифрами» - нормально. «Посчитайте свои расходы за прошлый месяц» - гораздо лучше. Избегайте слишком конкретных задач вроде «Вы можете выделить эти ячейки в ввести формулу суммы внизу?». Пусть пользователь говорит во время выполнения, не прерывайте его и не пытайтесь помочь. Спрашивайте себя «почему он делает так» и «почему он не делает так». -Первая вещь, которую вы заметите – это то, что пользователи делают большинство вещей одинаково. Они пробуют выполнить различные задачи одним и тем же способом, при этом делая одни и те же ошибки в одних и тех же местах. И вы должны проектировать вокруг их этого основного поведения. Это отличается от совещаний, на которых люди обсуждают вопросы из серии «А что если пользователь захочет сделать вот так?», и которые приводят к решениям, вызывающим замешательство пользователей. Наблюдение за пользователями устраняет это замешательство. +Первая вещь, которую вы заметите – это то, что пользователи делают большинство вещей одинаково. Они пробуют выполнить различные задачи одним и тем же способом, при этом делая одни и те же ошибки в одних и тех же местах. Вы должны проектировать ПО с учетом этого основного поведения. Это отличается от совещаний, на которых люди обсуждают вопросы из серии «А что если пользователь захочет сделать вот так?», и которые приводят к решениям, вызывающим замешательство пользователей. Наблюдение за пользователями устраняет это замешательство. Вы можете увидеть, как пользователь зайдет в тупик. Когда вы в тупике, вы смотрите по сторонам. Когда пользователь в тупике, их фокус внимания сужается. Для них становится сложным найти решение где-то на экране. И это одна из причин, почему стандартный хелп – не самое лучшее решение. Если вам необходима текстовая помощь или инструкции, постарайтесь разместить их непосредственно вблизи зоны концентрации вашей задачи. Сужение фокуса внимания пользователя – одна из причин, почему всплывающие подсказки намного лучше, чем помощь в меню. @@ -15,4 +15,4 @@ Вы также обнаружите, что между тем, что пользователи говорят и тем, что они на самом деле делают, есть разница. И это проблема, поскольку обычно пользовательские требования формируются путем опроса. Поэтому лучший способ составить требования – это понаблюдать за пользователями. Потратить час на наблюдения будет гораздо более информативно, чем потратить день на распросы. -Автор оригинала - [Giles Colborne](http://programmer.97things.oreilly.com/wiki/index.php/Giles_Colborne) \ No newline at end of file +Автор оригинала - [Giles Colborne](http://programmer.97things.oreilly.com/wiki/index.php/Giles_Colborne) From 839caf294a5b4867750bd7dab33a8067b88b4ce6 Mon Sep 17 00:00:00 2001 From: romanenko-ivan <82770629+romanenko-ivan@users.noreply.github.com> Date: Mon, 25 Apr 2022 17:25:18 +0300 Subject: [PATCH 108/290] ru/thing_71: update formatting --- ru/thing_71/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ru/thing_71/README.md b/ru/thing_71/README.md index c34f9f57..075be5ba 100644 --- a/ru/thing_71/README.md +++ b/ru/thing_71/README.md @@ -9,7 +9,7 @@ Большинство широко известных «хороших» практик программирования (хотя им не так часто следуют) облегчают построение аргументации. Уже даже от того, что вы задумаетесь об аргументации правильности вашего кода, вы начнете думать в направлении лучшего стиля и структуры кода. И конечно же, соблюдение большинства этих практик можно проверить при помощи статических анализаторов кода: -1. Избегайте операторов goto, поскольку они делают удаленные друг от друга секции сильно связанными. +- Избегайте операторов goto, поскольку они делают удаленные друг от друга секции сильно связанными. - Избегайте изменяемых глобальных переменных, поскольку они делают секции, их использующие, зависимыми. - Каждая переменная должна иметь минимально возможную область видимости. Например, локальный объект может создаваться непосредственно перед его использованием. - Делайте объекты неизменяемыми там, где только это возможно. @@ -23,4 +23,4 @@ Кроме доказательства правильности кода, его обсуждение даст вам лучшее его понимание. Развитие проницательности выгодно для всех. -Автор оригинала - [Yechiel Kimchi](http://programmer.97things.oreilly.com/wiki/index.php/Yechiel_Kimchi) \ No newline at end of file +Автор оригинала - [Yechiel Kimchi](http://programmer.97things.oreilly.com/wiki/index.php/Yechiel_Kimchi) From 132cd39864639fbef231fe226d5696eacf157df2 Mon Sep 17 00:00:00 2001 From: Baran Kaya <0barankaya@gmail.com> Date: Tue, 24 May 2022 18:42:24 +0300 Subject: [PATCH 109/290] added thing_88 --- tr/SUMMARY.md | 2 +- tr/thing_88/README.md | 31 +++++++++++++++++++++++++++++++ 2 files changed, 32 insertions(+), 1 deletion(-) create mode 100644 tr/thing_88/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index 97d3df97..6e588e74 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -88,7 +88,7 @@ 1. [İki Kafa Çoğu Zaman Bir Kafadan Daha İyidir](thing_85/README.md) 1. [İki Yanlış Bir Doğru Yapabilir (ve Düzeltilmesi Zordur)](thing_86/README.md) 1. [Arkadaşlarınız İçin Ubuntu Kodlama](thing_87/README.md) -1. [The Unix Tools Are Your Friends](thing_88/README.md) +1. [Unix Araçları Arkadaşlarınızdır](thing_88/README.md) 1. [Use the Right Algorithm and Data Structure](thing_89/README.md) 1. [Verbose Logging Will Disturb Your Sleep](thing_90/README.md) 1. [WET Dilutes Performance Bottlenecks](thing_91/README.md) diff --git a/tr/thing_88/README.md b/tr/thing_88/README.md new file mode 100644 index 00000000..3af987a0 --- /dev/null +++ b/tr/thing_88/README.md @@ -0,0 +1,31 @@ +# Unix Araçları Arkadaşlarınızdır + +Issız bir adaya sürgüne giderken bir IDE ile Unix araç kutusu arasında seçim yapmak zorunda kalsaydım, hiç düşünmeden Unix araçlarını seçerdim. İşte Unix araçları konusunda uzman olmanız için nedenler. + +Birincisi, IDE'ler belirli dilleri hedeflerken, Unix araçları metin biçiminde görünen her şeyle çalışabilir. Her yıl yeni dillerin ve notasyonların ortaya çıktığı günümüzün geliştirme ortamında, Unix tarzında çalışmayı öğrenmek, her zaman karşılığını verecek bir yatırımdır. + +Ayrıca, IDE'ler yalnızca geliştiricilerinin tasarladığı komutları sunarken, Unix araçlarıyla hayal edebileceğiniz her görevi gerçekleştirebilirsiniz. Bunları (klasik Pre-Bionicle) Lego blokları olarak düşünün: Küçük ama çok yönlü Unix araçlarını birleştirerek kendi komutlarınızı yaratırsınız. Örneğin, aşağıdaki sıra, Cunningham'ın imza analizinin metin tabanlı bir uygulamasıdır, dosyanın içeriği hakkında çok şey ortaya çıkarabilen her dosyanın noktalı virgül, parantez ve tırnaklardan oluşan bir dizi. + +``` +for i in *.java; do + echo -n "$i: " + sed 's/[^"{};]//g' $i | tr -d '\n' + echo +done +``` + +Ayrıca öğrendiğiniz her IDE işlemi o göreve özeldir; örneğin, bir projenin hata ayıklama derleme yapılandırmasına yeni bir adım eklemek. Buna karşılık, Unix araç becerilerinizi geliştirmek sizi her görevde daha etkili kılar. Örnek olarak, birden çok işlemci mimarisinde çapraz derleme için bir projenin yapısını değiştirmek için önceki komut dizisinde kullanılan sed aracını kullandım. + +Unix araçları, çok kullanıcılı bir bilgisayarın 128 kB RAM'e sahip olduğu bir çağda geliştirildi. Tasarımlarındaki ustalık, günümüzde devasa veri kümelerini son derece verimli bir şekilde işleyebilecekleri anlamına geliyor. Çoğu araç, filtreler gibi çalışır ve aynı anda yalnızca tek bir satırı işleyerek işleyebilecekleri veri miktarında bir üst sınır olmadığı anlamına gelir. Yarım terabaytlık İngilizce Wikipedia dökümünde saklanan düzenleme sayısını mı aramak istiyorsunuz? Basit bir çağırma + +``` +grep '' | wc –l +``` + +cevabı ter dökmeden verecektir. Bir komut dizisini genel olarak yararlı bulursanız, verileri döngülere ve koşullara aktarma gibi bazı benzersiz güçlü programlama yapılarını kullanarak onu kolayca bir shell komut dosyasında paketleyebilirsiniz. Daha da etkileyici bir şekilde, önceki gibi ardışık düzen olarak yürütülen Unix komutları, yüklerini modern çok çekirdekli CPU'ların birçok işlem birimi arasında doğal olarak dağıtacaktır. + +Unix araçlarının küçük güzeldir kaynağı ve açık kaynak uygulamaları, set üstü medya oynatıcım veya DSL yönlendiricim gibi kaynakları kısıtlı platformlarda bile onları her yerde kullanılabilir hale getirir. Bu tür cihazların güçlü bir grafik kullanıcı arabirimi sunmaları pek olası değildir, ancak genellikle en yaygın kullanılan araçları sağlayan BusyBox uygulamasını içerirler. Ve Windows üzerinde geliştirme yapıyorsanız, Cygwin ortamı size hem yürütülebilir dosyalar olarak hem de kaynak kodu biçiminde akla gelebilecek tüm Unix araçlarını sunar. + +Son olarak, mevcut araçlardan hiçbiri ihtiyaçlarınızı karşılamıyorsa, Unix araçlarının dünyasını genişletmek çok kolaydır. Sadece birkaç basit kurala göre oynayan bir program yazın (istediğiniz herhangi bir dilde): Programınız sadece tek bir görevi yerine getirmelidir; verileri standart girdisinden metin satırları olarak okumalıdır; ve sonuçlarını standart çıktısında başlıklar ve diğer gürültüler tarafından süslenmeden göstermelidir. Aracın çalışmasını etkileyen parametreler komut satırında verilmiştir. Bu kuralları takip edin ve "Dünya ve içindeki her şey sizindir". + +[Diomidis Spinellis](http://programmer.97things.oreilly.com/wiki/index.php/Diomidis_Spinellis) Tarafından \ No newline at end of file From 6353dedcd1c67faea7748fdebb20d105f9bbe240 Mon Sep 17 00:00:00 2001 From: Baran Kaya <0barankaya@gmail.com> Date: Tue, 24 May 2022 18:54:21 +0300 Subject: [PATCH 110/290] added thing_89 --- tr/SUMMARY.md | 2 +- tr/thing_89/README.md | 37 +++++++++++++++++++++++++++++++++++++ 2 files changed, 38 insertions(+), 1 deletion(-) create mode 100644 tr/thing_89/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index 6e588e74..0bc2bd2a 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -89,7 +89,7 @@ 1. [İki Yanlış Bir Doğru Yapabilir (ve Düzeltilmesi Zordur)](thing_86/README.md) 1. [Arkadaşlarınız İçin Ubuntu Kodlama](thing_87/README.md) 1. [Unix Araçları Arkadaşlarınızdır](thing_88/README.md) -1. [Use the Right Algorithm and Data Structure](thing_89/README.md) +1. [Doğru Algoritmayı ve Veri Yapısını Kullanın](thing_89/README.md) 1. [Verbose Logging Will Disturb Your Sleep](thing_90/README.md) 1. [WET Dilutes Performance Bottlenecks](thing_91/README.md) 1. [When Programmers and Testers Collaborate](thing_92/README.md) diff --git a/tr/thing_89/README.md b/tr/thing_89/README.md new file mode 100644 index 00000000..067d4243 --- /dev/null +++ b/tr/thing_89/README.md @@ -0,0 +1,37 @@ +# Doğru Algoritmayı ve Veri Yapısını Kullanın + +> Çok sayıda şubesi olan büyük bir banka, veznedarlar için aldığı yeni bilgisayarların çok yavaş olduğundan şikayet etti. Bu, herkesin elektronik bankacılık kullandığı ve ATM'lerin şimdiki kadar yaygın olmadığı zamanlardaydı. İnsanlar bankayı çok daha sık ziyaret ediyorlardı ve yavaş bilgisayarlar insanları sıraya sokuyordu. Sonuç olarak, banka satıcıyla olan sözleşmesini bozmakla tehdit etti. + +> Satıcı, gecikmelerin nedenini belirlemek için bir performans analizi ve ayar uzmanı gönderdi. Kısa süre sonra, terminalde çalışan ve neredeyse tüm CPU kapasitesini tüketen belirli bir program buldu. Bir profil oluşturma aracı kullanarak programı yakınlaştırdı ve suçlu olan işlevi görebildi. Kaynak kodu okuyun: + +> ``` +> for (i=0; i if (... s[i] ...) ... +> } +> ``` + +> Ve string s ortalama olarak binlerce karakter uzunluğundaydı. (Banka tarafından yazılan) kod çabucak değiştirildi ve banka veznedarları sonsuza dek mutlu yaşadılar.... + +Programcının gereksiz yere ikinci dereceden ölçeklenen kodu kullanmaktan daha iyisini yapması gerekmez miydi? +strlen'e yapılan her çağrı, sonlandırıcı boş karakterini bulmak için dizgedeki binlerce karakterin her birini geçti. Ancak dizi hiç değişmedi. Programcı, uzunluğunu önceden belirleyerek, strlen'e binlerce çağrıyı (ve milyonlarca döngü yürütmesini) kaydedebilirdi: + +``` +n=strlen(s); +for (i=0; i Date: Tue, 14 Jun 2022 19:45:06 -0400 Subject: [PATCH 111/290] =?UTF-8?q?=E2=9C=8F=EF=B8=8F=20[thing=5F09]=20Fix?= =?UTF-8?q?=20grammar?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit In English, "maybe" is an adverb and "may be" is a verb --- en/thing_09/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/en/thing_09/README.md b/en/thing_09/README.md index 01195778..112231cb 100644 --- a/en/thing_09/README.md +++ b/en/thing_09/README.md @@ -11,7 +11,7 @@ Assuming the tools are widely used, mature, and employed in various technology s Given how rare compiler bugs are, you are far better putting your time and energy into finding the error in your code than proving the compiler is wrong. All the usual debugging advice applies, so isolate the problem, stub out calls, surround it with tests; check calling conventions, shared libraries, and version numbers; explain it to someone else; look out for stack corruption and variable type mismatches; try the code on different machines and different build configurations, such as debug and release. Question your own assumptions and the assumptions of others. Tools from different vendors might have different assumptions built into them — so too might different tools from the same vendor. -When someone else is reporting a problem you cannot duplicate, go and see what they are doing. They maybe doing something you never thought of or are doing something in a different order. +When someone else is reporting a problem you cannot duplicate, go and see what they are doing. They may be doing something you never thought of or are doing something in a different order. As a personal rule if I have a bug I can't pin down, and I'm starting to think it's the compiler, then it's time to look for stack corruption. This is especially true if adding trace code makes the problem move around. @@ -19,4 +19,4 @@ Multi-threaded problems are another source of bugs to turn hair gray and induce So before you rush to blame the compiler, remember Sherlock Holmes' advice, "Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth," and prefer it to Dirk Gently's, "Once you eliminate the improbable, whatever remains, no matter how impossible, must be the truth." -By [Allan Kelly](http://programmer.97things.oreilly.com/wiki/index.php/Allan_Kelly) \ No newline at end of file +By [Allan Kelly](http://programmer.97things.oreilly.com/wiki/index.php/Allan_Kelly) From e5b7cf82ef597859d65b84f751fcd6bb99333553 Mon Sep 17 00:00:00 2001 From: Shintaro Mukai Date: Tue, 28 Jun 2022 10:58:54 +0900 Subject: [PATCH 112/290] en/thing_65: update formatting --- en/thing_65/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/en/thing_65/README.md b/en/thing_65/README.md index 75575b39..0bb9df7d 100644 --- a/en/thing_65/README.md +++ b/en/thing_65/README.md @@ -20,7 +20,7 @@ Some_Number:= Distance + Velocity; -- Will be caught by the compiler as a type e Developers in less demanding domains might also benefit from applying more domain-specific typing, where they might otherwise continue to use the primitive data types offered by the language and its libraries, such as strings and floats. In Java, C++, Python, and other modern languages the abstract data type is known as class. Using classes such as `Velocity_In_Knots` and `Distance_In_Nautical_Miles` adds a lot of value with respect to code quality: -1. The code becomes more readable as it expresses concepts of a domain, not just Float or String. +- The code becomes more readable as it expresses concepts of a domain, not just Float or String. - The code becomes more testable as the code encapsulates behavior that is easily testable. - The code facilitates reuse across applications and systems. @@ -28,4 +28,4 @@ The approach is equally valid for users of both statically and dynamically typed The moral is to start exploring domain-specific types for the purpose of developing quality software. -By [Einar Landre](http://programmer.97things.oreilly.com/wiki/index.php/Einar_Landre) \ No newline at end of file +By [Einar Landre](http://programmer.97things.oreilly.com/wiki/index.php/Einar_Landre) From d2eab8379b52ab03f60c2ab0e48d74c8ea1d6b9c Mon Sep 17 00:00:00 2001 From: Baran Kaya <0barankaya@gmail.com> Date: Tue, 28 Jun 2022 17:59:23 +0300 Subject: [PATCH 113/290] added thing_90 --- tr/SUMMARY.md | 2 +- tr/thing_90/README.md | 17 +++++++++++++++++ 2 files changed, 18 insertions(+), 1 deletion(-) create mode 100644 tr/thing_90/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index 0bc2bd2a..aca77f2a 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -90,7 +90,7 @@ 1. [Arkadaşlarınız İçin Ubuntu Kodlama](thing_87/README.md) 1. [Unix Araçları Arkadaşlarınızdır](thing_88/README.md) 1. [Doğru Algoritmayı ve Veri Yapısını Kullanın](thing_89/README.md) -1. [Verbose Logging Will Disturb Your Sleep](thing_90/README.md) +1. [Ayrıntılı Log Kaydı Uykunuzu Bozacak](thing_90/README.md) 1. [WET Dilutes Performance Bottlenecks](thing_91/README.md) 1. [When Programmers and Testers Collaborate](thing_92/README.md) 1. [Write Code as If You Had to Support It for the Rest of Your Life](thing_93/README.md) diff --git a/tr/thing_90/README.md b/tr/thing_90/README.md new file mode 100644 index 00000000..913071b2 --- /dev/null +++ b/tr/thing_90/README.md @@ -0,0 +1,17 @@ +# Ayrıntılı Log Kaydı Uykunuzu Bozacak + +Bir süredir geliştirme veya üretimde olan bir sistemle karşılaştığımda, gerçek sorunun ilk işareti her zaman kirli bir logdur. Ne hakkında konuştuğumu biliyorsun. Bir web sayfasındaki normal bir akışta tek bir bağlantıya tıklandığında, sistemin sağladığı logda bir mesaj akışına neden olur. Çok fazla log kaydı hiç olmadığı kadar işe yaramaz olabilir. + +Sistemleriniz benimki gibiyse sizin işiniz bittiğinde başkasının işi yeni başlıyor demektir. Sistem geliştirildikten sonra, umarım müşterilere hizmet veren uzun ve müreffeh bir yaşam sürecektir tabi şanslıysan. Sistem üretimdeyken bir şeylerin ters gittiğini nasıl anlayacaksınız ve bununla nasıl başa çıkacaksınız? + +Belki biri sizin yerinize sisteminizi izliyordur ya da belki siz kendiniz izleyeceksiniz. Her iki durumda da, loglar muhtemelen izlemenin bir parçası olacaktır. Bir şey ortaya çıkarsa ve bununla başa çıkmak için uyanmanız gerekiyorsa, bunun iyi bir nedeni olduğundan emin olmak istersiniz. Sistemim ölüyorsa, bilmek istiyorum. Ama sadece bir hıçkırık varsa, güzellik uykumun tadını çıkarmayı tercih ederim. + +Birçok sistem için, bir şeylerin yanlış olduğunun ilk göstergesi, bir loga yazılan bir log mesajıdır. Çoğunlukla, bu hata logları olacaktır. Kendinize bir iyilik yapın: İlk günden itibaren, hata loglarına bir şey kaydedilirse, birisinin gecenin bir yarısında sizi bu konuda aramasını ve uyandırmasını istediğinizden emin olun. Sistem testi sırasında sisteminizdeki yükü simüle edebiliyorsanız, gürültüsüz bir hata günlüğüne bakmak da sisteminizin makul ölçüde sağlam olduğunun iyi bir ilk göstergesidir. Ya da değilse bir erken uyarı. + +Dağıtılmış sistemler başka bir karmaşıklık düzeyi ekler. Başarısız bir dış bağımlılıkla nasıl başa çıkacağınıza karar vermelisiniz. Sisteminiz çok dağıtılmışsa, bu yaygın bir durum olabilir. Loga kaydetme politikanızın bunu dikkate aldığından emin olun. + +Genel olarak, her şeyin yolunda olduğunun en iyi göstergesi, daha düşük öncelikli mesajların mutlu bir şekilde ilerliyor olmasıdır. Her önemli uygulama olayı için yaklaşık bir INFO düzeyinde günlük log istiyorum. + +Dağınık bir kütük, üretime ulaştığında sistemin kontrol edilmesinin zor olacağının bir göstergesidir. Log kayıtlarında hiçbir şeyin görünmesini beklemiyorsanız, bir şey göründüğünde ne yapacağınızı bilmek çok daha kolay olacaktır. + +[Johannes Brodwall](http://programmer.97things.oreilly.com/wiki/index.php/Johannes_Brodwall) Tarafından \ No newline at end of file From dd850f5b54a82e7f71ea129d0c6f9a34ebe4e68e Mon Sep 17 00:00:00 2001 From: Baran Kaya <0barankaya@gmail.com> Date: Tue, 28 Jun 2022 18:08:20 +0300 Subject: [PATCH 114/290] added thing_91 --- tr/SUMMARY.md | 2 +- tr/thing_91/README.md | 50 +++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 51 insertions(+), 1 deletion(-) create mode 100644 tr/thing_91/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index aca77f2a..b8e6916f 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -91,7 +91,7 @@ 1. [Unix Araçları Arkadaşlarınızdır](thing_88/README.md) 1. [Doğru Algoritmayı ve Veri Yapısını Kullanın](thing_89/README.md) 1. [Ayrıntılı Log Kaydı Uykunuzu Bozacak](thing_90/README.md) -1. [WET Dilutes Performance Bottlenecks](thing_91/README.md) +1. [WET Performans Darboğazlarını Azaltıyor](thing_91/README.md) 1. [When Programmers and Testers Collaborate](thing_92/README.md) 1. [Write Code as If You Had to Support It for the Rest of Your Life](thing_93/README.md) 1. [Write Small Functions Using Examples](thing_94/README.md) diff --git a/tr/thing_91/README.md b/tr/thing_91/README.md new file mode 100644 index 00000000..bf3202c4 --- /dev/null +++ b/tr/thing_91/README.md @@ -0,0 +1,50 @@ +# WET Performans Darboğazlarını Azaltıyor + +DRY ilkesinin (Don't Repeat Yourself - Kendini Tekrar Etme) önemi, bir sistemdeki her bilgi parçasının tekil bir temsile sahip olması gerektiği fikrini kodlamasıdır. Başka bir deyişle, bilgi tek bir uygulamada yer almalıdır. DRY'nin antitezi WET'tir (Write Every Time - Her Zaman Yaz). Bilgi birkaç farklı uygulamada kodlandığında kodumuz WET olur. Bir performans profili üzerindeki sayısız etkilerini göz önünde bulundurduğunuzda, DRY ve WET'in performans etkileri çok netleşir. + +Sistemimizin bir özelliğini, örneğin *X*, yani CPU darboğazını ele alarak başlayalım. Diyelim ki *X* özelliği CPU'nun %30'unu tüketiyor. Diyelim ki *X* özelliğinin on farklı uygulaması var. Ortalama olarak, her uygulama CPU'nun %3'ünü tüketecektir. Hızlı bir kazanç arıyorsak bu CPU kullanımı seviyesi endişelenmeye değmeyeceğinden, bu özelliğin bizim darboğazımız olduğunu gözden kaçırmamız muhtemeldir. Ancak, bir şekilde *X* özelliğini bir darboğaz olarak gördüğümüzü varsayalım. Artık her bir uygulamayı bulma ve düzeltme sorunuyla karşı karşıyayız. WET ile bulmamız ve düzeltmemiz gereken on farklı uygulamamız var. DRY ile %30 CPU kullanımını açıkça görürdük ve kodun onda birini düzeltmemiz gerekirdi. Ve her uygulamayı aramak için zaman harcamak zorunda olmadığımızdan bahsetmiş miydim? + +Genellikle DRY'yi ihlal etmekten suçlu olduğumuz bir kullanım durumu vardır: koleksiyon kullanımımız. Bir sorguyu uygulamak için yaygın bir teknik, koleksiyon üzerinde yineleme yapmak ve ardından sorguyu sırayla her bir öğeye uygulamaktır: + +``` +public class UsageExample { + private ArrayList allCustomers = new ArrayList(); + // ... + public ArrayList findCustomersThatSpendAtLeast(Money amount) { + ArrayList customersOfInterest = new ArrayList(); + for (Customer customer: allCustomers) { + if (customer.spendsAtLeast(amount)) + customersOfInterest.add(customer); + } + return customersOfInterest; + } +} +``` + +Bu ham koleksiyonu client'lara göstererek, kapsüllemeyi ihlal ettik. Bu, yalnızca yeniden düzenleme yeteneğimizi sınırlamakla kalmaz, kodumuzu kullananların her birinin potansiyel olarak aynı sorguyu yeniden uygulamasını sağlayarak DRY'yi ihlal etmeye zorlar. Bu durum, açıkta kalan ham koleksiyonları API'den kaldırarak kolayca önlenebilir. Bu örnekte, `CustomerList` adlı yeni, alana özgü bir toplu tür tanıtabiliriz. Bu yeni sınıf, alanımızla daha semantik olarak uyumludur. Tüm sorularımız için doğal bir yuva görevi görecek. + +Bu yeni koleksiyon türüne sahip olmak, bu sorguların performans darboğazı olup olmadığını kolayca görmemizi sağlayacaktır. Sorguları sınıfa dahil ederek, `ArrayList` gibi temsil seçeneklerini müşterilerimize gösterme ihtiyacını ortadan kaldırıyoruz. Bu bize, client sözleşmelerini ihlal etme korkusu olmadan bu uygulamaları değiştirme özgürlüğü verir: + +``` +public class CustomerList { + private ArrayList customers = new ArrayList(); + private SortedList customersSortedBySpendingLevel = new SortedList(); + // ... + public CustomerList findCustomersThatSpendAtLeast(Money amount) { + return new CustomerList(customersSortedBySpendingLevel.elementsLargerThan(amount)); + } +} + +public class UsageExample { + public static void main(String[] args) { + CustomerList customers = new CustomerList(); + // ... + CustomerList customersOfInterest = customers.findCustomersThatSpendAtLeast(someMinimalAmount); + // ... + } +} +``` + +Bu örnekte, DRY'ye bağlılık, client'larımıızın harcama düzeyine göre ayarlanmış SortedList ile alternatif bir indeksleme şeması sunmamıza izin verdi. Bu özel örneğin belirli ayrıntılarından daha önemli olan, DRY'yi takip etmek, kodun WET olması durumunda bulunması daha zor olacak bir performans darboğazı bulmamıza ve onarmamıza yardımcı oldu. + +[Kirk Pepperdine](http://programmer.97things.oreilly.com/wiki/index.php/Kirk_Pepperdine) Tarafından \ No newline at end of file From 37b15f28dcd26413fed79a2b91391fdc925d1a5d Mon Sep 17 00:00:00 2001 From: Baran Kaya <0barankaya@gmail.com> Date: Tue, 28 Jun 2022 18:17:21 +0300 Subject: [PATCH 115/290] added thing_92 --- tr/SUMMARY.md | 2 +- tr/thing_92/README.md | 13 +++++++++++++ 2 files changed, 14 insertions(+), 1 deletion(-) create mode 100644 tr/thing_92/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index b8e6916f..8cc24735 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -92,7 +92,7 @@ 1. [Doğru Algoritmayı ve Veri Yapısını Kullanın](thing_89/README.md) 1. [Ayrıntılı Log Kaydı Uykunuzu Bozacak](thing_90/README.md) 1. [WET Performans Darboğazlarını Azaltıyor](thing_91/README.md) -1. [When Programmers and Testers Collaborate](thing_92/README.md) +1. [Programcılar ve Test Uzmanları İşbirliği Yaptığında](thing_92/README.md) 1. [Write Code as If You Had to Support It for the Rest of Your Life](thing_93/README.md) 1. [Write Small Functions Using Examples](thing_94/README.md) 1. [Write Tests for People](thing_95/README.md) diff --git a/tr/thing_92/README.md b/tr/thing_92/README.md new file mode 100644 index 00000000..6a254d2a --- /dev/null +++ b/tr/thing_92/README.md @@ -0,0 +1,13 @@ +# Programcılar ve Test Uzmanları İşbirliği Yaptığında + +Testçiler ve programcılar işbirliği yapmaya başladığında sihirli bir şey olur. Hata izleme sistemi aracılığıyla hataları ileri geri göndermek için daha az zaman harcanır. Bir şeyin gerçekten bir hata mı yoksa yeni bir özellik mi olduğunu anlamaya çalışmak için daha az zaman harcanır ve müşteri beklentilerini karşılamak için iyi bir yazılım geliştirmek için daha fazla zaman harcanır. Kodlama başlamadan önce işbirliğine başlamak için birçok fırsat vardır. + +Test kullanıcıları, Fit (Framework for Integrated Test - Entegre Test için Çerçeve) gibi araçlarla müşterilerin kendi alanlarının dilini kullanarak kabul testleri yazmasına ve otomatikleştirmesine yardımcı olabilir. Bu testler programcılara kodlama başlamadan önce verildiğinde, ekip Kabul Testine Dayalı Geliştirme (Acceptance Test Driven Development - ATDD) uyguluyor. Programcılar testleri çalıştırmak için fikstürleri yazar ve ardından testleri geçmek için kod yazar. Bu testler daha sonra regresyon paketinin bir parçası haline gelir. Bu işbirliği gerçekleştiğinde, işlevsel testler erken tamamlanır ve uç koşullarda veya daha büyük resmin iş akışları aracılığıyla keşif testleri için zaman tanır. + +Bir adım daha ileri götürebiliriz. Bir testçi olarak, test fikirlerimin çoğunu programcılar yeni bir özelliği kodlamaya başlamadan önce sağlayabilirim. Programcılara herhangi bir önerileri olup olmadığını sorduğumda, neredeyse her zaman bana daha iyi test kapsamı konusunda yardımcı olan veya gereksiz testlere çok fazla zaman harcamaktan kaçınmama yardımcı olan bilgileri sağlıyorlar. Testler ilk fikirlerin çoğunu netleştirdiği için genellikle kusurları önledik. Örneğin, üzerinde çalıştığım bir projede, programcılara verdiğim Uyum testleri, bir joker karakter aramasına yanıt vermek için bir sorgunun beklenen sonuçlarını gösteriyordu. Programcı tamamen yalnızca tam kelime aramalarını kodlamayı amaçlamıştı. Kodlamaya başlamadan önce müşteri ile konuşup doğru yorumu tespit edebildik. İşbirliği yaparak, ikimizi de çok fazla zaman kaybından kurtaran kusuru önledik. + +Programcılar, başarılı otomasyon oluşturmak için test uzmanlarıyla da işbirliği yapabilir. İyi kodlama uygulamalarını anlarlar ve test uzmanlarının tüm ekip için çalışan sağlam bir test otomasyon paketi oluşturmasına yardımcı olabilirler. Testler kötü tasarlanmış olduğu için test otomasyon projelerinin başarısız olduğunu sık sık gördüm. Testler çok fazla test etmeye çalışıyor veya testçiler, testleri bağımsız tutabilmek için teknoloji hakkında yeterince bilgi sahibi değiller. Test cihazları genellikle darboğazdır, bu nedenle programcıların otomasyon gibi görevlerde onlarla çalışması mantıklıdır. Neyin erkenden test edilebileceğini anlamak için testçilerle birlikte çalışmak, belki de basit bir araç sağlayarak, programcılara uzun vadede daha iyi kod sunmalarına yardımcı olacak başka bir geri bildirim döngüsü sağlayacaktır. + +Testçiler, tek görevlerinin yazılımı kırmak ve programcıların kodunda hatalar bulmak olduğunu düşünmeyi bıraktığında, programcılar, testçilerin `onları elde etmeye hazır` olduklarını düşünmeyi bırakırlar ve işbirliğine daha açık olurlar. Programcılar, kodlarında kalite oluşturmaktan sorumlu olduklarını fark etmeye başladıklarında, kodun test edilebilirliği doğal bir yan üründür ve ekip birlikte daha fazla regresyon testini otomatikleştirebilir. Başarılı ekip çalışmasının büyüsü başlar. + +[Janet Gregory](http://programmer.97things.oreilly.com/wiki/index.php/Janet_Gregory) Tarafından \ No newline at end of file From 14940da4b3aa5e8cf18536eb0e0dc1a2ab1df6b3 Mon Sep 17 00:00:00 2001 From: Baran Kaya <0barankaya@gmail.com> Date: Tue, 28 Jun 2022 18:27:53 +0300 Subject: [PATCH 116/290] added thing_93 --- tr/SUMMARY.md | 2 +- tr/thing_93/README.md | 13 +++++++++++++ 2 files changed, 14 insertions(+), 1 deletion(-) create mode 100644 tr/thing_93/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index 8cc24735..57ec85c2 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -93,7 +93,7 @@ 1. [Ayrıntılı Log Kaydı Uykunuzu Bozacak](thing_90/README.md) 1. [WET Performans Darboğazlarını Azaltıyor](thing_91/README.md) 1. [Programcılar ve Test Uzmanları İşbirliği Yaptığında](thing_92/README.md) -1. [Write Code as If You Had to Support It for the Rest of Your Life](thing_93/README.md) +1. [Hayatınız Boyunca Desteklemek Zorundaymışsınız Gibi Kod Yazın](thing_93/README.md) 1. [Write Small Functions Using Examples](thing_94/README.md) 1. [Write Tests for People](thing_95/README.md) 1. [You Gotta Care about the Code](thing_96/README.md) diff --git a/tr/thing_93/README.md b/tr/thing_93/README.md new file mode 100644 index 00000000..c765b6f0 --- /dev/null +++ b/tr/thing_93/README.md @@ -0,0 +1,13 @@ +# Hayatınız Boyunca Desteklemek Zorundaymışsınız Gibi Kod Yazın + +97 kişiye her programcının ne bilmesi ve yapması gerektiğini sorabilir ve 97 farklı cevap duyabilirsiniz. Bu aynı anda hem ezici hem de korkutucu olabilir. Tüm tavsiyeler iyidir, tüm ilkeler sağlamdır ve tüm hikayeler ikna edicidir, ancak nereden başlamalı? Daha da önemlisi, bir kez başladığınızda, öğrendiğiniz tüm en iyi uygulamalara nasıl ayak uydurursunuz ve bunları programlama uygulamanızın ayrılmaz bir parçası haline nasıl getirirsiniz? + +Bence cevap sizin düşünce yapınızda ya da daha açık bir ifadeyle tavrınızda yatıyor. Diğer geliştiricilerinizi, test uzmanlarınızı, yöneticilerinizi, satış ve pazarlama görevlilerinizi ve son kullanıcıları umursamıyorsanız, örneğin, Test Odaklı Geliştirme kullanmaya veya kodunuza net yorumlar yazmaya yönlendirilmezsiniz. Tutumunuzu ayarlamanın ve her zaman en kaliteli ürünleri sunmaya yönelmenin basit bir yolu olduğunu düşünüyorum: + +> *Hayatınız Boyunca Desteklemek Zorundaymışsınız Gibi Kod Yazın.* + +Bu kadar. Bu fikri kabul ederseniz, birçok harika şey olacak. Önceki veya mevcut işverenlerinizden herhangi birinin gecenin bir yarısı sizi arayıp fooBar yöntemini yazarken yaptığınız seçimleri açıklamanızı isteme hakkına sahip olduğunu kabul etseydiniz, yavaş yavaş uzman bir programcı olma yolunda ilerlersiniz. Doğal olarak daha iyi değişken ve yöntem adları bulmak istersiniz. Yüzlerce satırdan oluşan kod bloklarından uzak durursunuz. Tasarım kalıplarını arar, öğrenir ve kullanırsınız. Sürekli olarak yorum yazar, kodunuzu test eder ve yeniden düzenlersiniz. Hayatınızın geri kalanında yazdığınız tüm kodları desteklemek de ölçeklenebilir bir çaba olmalıdır. Bu nedenle daha iyi, daha akıllı ve daha verimli olmaktan başka seçeneğiniz kalmaz. + +Üzerinde düşünürseniz, yıllar önce yazdığınız kod, beğenseniz de beğenmeseniz de kariyerinizi etkiler. Tasarladığınız ve yazdığınız her yöntem ve sınıf ve modül ile bilginizin, tavrınızın, aziminizin, profesyonelliğinizin, bağlılık seviyenizin ve keyif derecenizin izini bırakıyorsunuz. İnsanlar gördükleri koda göre sizin hakkınızda fikir oluşturacaklar. Bu görüşler sürekli olumsuz ise, kariyerinizden umduğunuzdan daha az şey elde edeceksiniz. Her kod satırıyla kariyerinize, müşterilerinize ve kullanıcılarınıza iyi bakın ve Hayatınız Boyunca Desteklemek Zorundaymışsınız Gibi Kod Yazın. + +[Yuriy Zubarev](http://programmer.97things.oreilly.com/wiki/index.php/Yuriy_Zubarev) Tarafından \ No newline at end of file From bd6783b2825a2857b977311e351b3b387368a34d Mon Sep 17 00:00:00 2001 From: Baran Kaya <0barankaya@gmail.com> Date: Tue, 28 Jun 2022 18:34:58 +0300 Subject: [PATCH 117/290] added thing_94 --- tr/SUMMARY.md | 2 +- tr/thing_94/README.md | 26 ++++++++++++++++++++++++++ 2 files changed, 27 insertions(+), 1 deletion(-) create mode 100644 tr/thing_94/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index 57ec85c2..f2003234 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -94,7 +94,7 @@ 1. [WET Performans Darboğazlarını Azaltıyor](thing_91/README.md) 1. [Programcılar ve Test Uzmanları İşbirliği Yaptığında](thing_92/README.md) 1. [Hayatınız Boyunca Desteklemek Zorundaymışsınız Gibi Kod Yazın](thing_93/README.md) -1. [Write Small Functions Using Examples](thing_94/README.md) +1. [Örnekleri Kullanarak Küçük Fonksiyonlar Yazın](thing_94/README.md) 1. [Write Tests for People](thing_95/README.md) 1. [You Gotta Care about the Code](thing_96/README.md) 1. [Your Customers Do not Mean What They Say](thing_97/README.md) diff --git a/tr/thing_94/README.md b/tr/thing_94/README.md new file mode 100644 index 00000000..d6592e27 --- /dev/null +++ b/tr/thing_94/README.md @@ -0,0 +1,26 @@ +# Örnekleri Kullanarak Küçük Fonksiyonlar Yazın + +Doğru olan bir kod yazmak istiyoruz ve bunun doğru olduğuna dair elimizde kanıt var. Bir fonksiyonun "boyutu" hakkında düşünmek her iki konuda da yardımcı olabilir. Bir işlevi uygulayan kod miktarı anlamında değil bu ilginç olsa da daha çok kodumuzun gösterdiği matematiksel işlevin boyutu anlamında. + +Örneğin, Go oyununda *atari* adı verilen ve oyuncunun taşlarının rakibi tarafından ele geçirilebileceği bir koşul vardır: Yanında iki veya daha fazla boş alan bulunan bir taş (*liberties* olarak adlandırılır) ataride değildir. Bir taşın ne kadar özgürlüğe sahip olduğunu saymak zor olabilir, ancak bu biliniyorsa atariyi belirlemek kolaydır. Bunun gibi bir fonksiyon yazarak başlayabiliriz: + +``` +boolean atari(int libertyCount) + libertyCount < 2 +``` + +Bu göründüğünden daha büyüktür. Matematiksel bir fonksiyon, bir küme, etki alanı (burada `int`) ve aralık (burada `boolean`) olan kümelerin Kartezyen çarpımının bir alt kümesi olarak anlaşılabilir. Bu değer kümeleri Java'dakiyle aynı boyutta olsaydı, `int×boolean` kümesinde `2L*(Integer.MAX_VALUE+(-1L*Integer.MIN_VALUE)+1L)` veya 8.589.934.592 üye olurdu. Bunların yarısı, işlevimiz olan alt kümenin üyeleridir, bu nedenle işlevimizin doğru olduğuna dair tam kanıt sağlamak için yaklaşık 4,3×109 örneği kontrol etmemiz gerekir. + +Testlerin hataların yokluğunu kanıtlayamayacağı iddiasının özü budur. Yine de testler, özelliklerin varlığını gösterebilir. Ama yine de bu boyut sorunumuz var. + +Sorun alanı bize yardımcı olur. Go'nun doğası, bir taşın özgürlük sayısının herhangi bir int değil, tam olarak {1,2,3,4}'den biri olduğu anlamına gelir. Yani alternatif olarak şunu yazabiliriz: + +``` +LibertyCount = {1,2,3,4} +boolean atari(LibertyCount libertyCount) + libertyCount == 1 +``` + +Bu çok daha izlenebilir: Hesaplanan fonksiyon artık en fazla sekiz üyeden oluşan bir kümedir. Aslında, kontrol edilen dört örnek, işlevin doğru olduğuna dair tam bir kesinlik kanıtı teşkil edecektir. Program yazmak için yerel türler yerine sorun alanıyla yakından ilgili türleri kullanmanın iyi bir fikir olmasının bir nedeni budur. Etki alanından ilham alan türleri kullanmak genellikle işlevlerimizi çok daha küçük hale getirebilir. Bu türlerin ne olması gerektiğini bulmanın bir yolu, işlevi yazmadan önce sorunlu etki alanı terimlerini kontrol etmek için örnekler bulmaktır. + +[Keith Braithwaite](http://programmer.97things.oreilly.com/wiki/index.php/Keith_Braithwaite) Tarafından \ No newline at end of file From bcb04461c66b8a9bf5d20a096eccbad6e286b914 Mon Sep 17 00:00:00 2001 From: Baran Kaya <0barankaya@gmail.com> Date: Tue, 28 Jun 2022 18:41:54 +0300 Subject: [PATCH 118/290] added thing_95 --- tr/SUMMARY.md | 2 +- tr/thing_95/README.md | 15 +++++++++++++++ 2 files changed, 16 insertions(+), 1 deletion(-) create mode 100644 tr/thing_95/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index f2003234..fa333adb 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -95,6 +95,6 @@ 1. [Programcılar ve Test Uzmanları İşbirliği Yaptığında](thing_92/README.md) 1. [Hayatınız Boyunca Desteklemek Zorundaymışsınız Gibi Kod Yazın](thing_93/README.md) 1. [Örnekleri Kullanarak Küçük Fonksiyonlar Yazın](thing_94/README.md) -1. [Write Tests for People](thing_95/README.md) +1. [İnsanlar için Testler Yaz](thing_95/README.md) 1. [You Gotta Care about the Code](thing_96/README.md) 1. [Your Customers Do not Mean What They Say](thing_97/README.md) diff --git a/tr/thing_95/README.md b/tr/thing_95/README.md new file mode 100644 index 00000000..3699d758 --- /dev/null +++ b/tr/thing_95/README.md @@ -0,0 +1,15 @@ +# İnsanlar için Testler Yaz + +Üretim kodunuzun bir kısmı veya tamamı için otomatik testler yazıyorsunuz. Tebrikler! Testlerinizi kodu yazmadan önce mi yazıyorsunuz? Daha iyi!! Bunu yapmak bile sizi yazılım mühendisliği uygulamalarının öncülerinden ilk benimseyenlerden biri yapar. Ama iyi testler mi yazıyorsun? Nasıl söyleyebilirsin? Bunun bir yolu "Testleri kimin için yazıyorum?" diye sormaktır. Cevap "Benim için, hataları düzeltme zahmetinden kurtarmak için" veya "Derleyici için, böylece çalıştırılabilmeleri için" ise, o zaman olası en iyi testleri yazmıyorsunuzdur. Peki testleri *kimin* için yazmalısınız? Kodunuzu anlamaya çalışan kişi için. + +İyi testler, test ettikleri kod için belge görevi görür. Kodun nasıl çalıştığını açıklarlar. Her kullanım senaryosu için test(ler): + +1. Karşılanması gereken bağlamı, başlangıç noktasını veya ön koşulları tanımlayın +2. Yazılımın nasıl çağrıldığını gösterin +3. Beklenen sonuçları veya doğrulanacak son koşulları tanımlayın + +Farklı kullanım senaryoları, bunların her birinin biraz farklı versiyonlarına sahip olacaktır. Kodunuzu anlamaya çalışan kişinin birkaç teste bakabilmesi ve söz konusu testlerin bu üç bölümünü karşılaştırarak yazılımın farklı davranmasına neyin sebep olduğunu görebilmesi gerekir. Her test, bu üç kısım arasındaki neden-sonuç ilişkisini açıkça göstermelidir. Bu, testte görünmeyenlerin görünenler kadar önemli olduğu anlamına gelir. Testte çok fazla kod, okuyucunun önemsiz önemsiz şeylerle dikkatini dağıtır. Mümkün olduğunda, bu tür önemsiz şeyleri anlamlı yöntem çağrılarının arkasına saklayın - Extract Method yeniden düzenleme en iyi arkadaşınızdır. Ve her teste, belirli kullanım senaryosunu açıklayan anlamlı bir ad verdiğinizden emin olun, böylece test okuyucusu, çeşitli senaryoların ne olduğunu anlamak için her testi tersine mühendislik yapmak zorunda kalmaz. Bunların arasında, test sınıfının ve sınıf yönteminin adları, en azından başlangıç ​​noktasını ve yazılımın nasıl çağrıldığını içermelidir. Bu, yöntem adlarının hızlı bir şekilde taranması yoluyla test kapsamının doğrulanmasını sağlar. Ayrıca, isimlerin görülmesi veya okunması çok uzun sürmediği sürece, beklenen sonuçların test yöntemi adlarına dahil edilmesi faydalı olabilir. + +Testlerinizi test etmek de iyi bir fikirdir. Tespit ettiklerini düşündüğünüz hataları, bu hataları üretim koduna ekleyerek doğrulayabilirsiniz (elbette atacağınız kendi özel kopyanız). Hataları yararlı ve anlamlı bir şekilde bildirdiklerinden emin olun. Ayrıca testlerinizin kodunuzu anlamaya çalışan bir kişiyle net bir şekilde konuştuğunu doğrulamanız gerekir. Bunu yapmanın tek yolu, kodunuza aşina olmayan birinin testlerinizi okumasını ve ne öğrendiğini size söylemesini sağlamaktır. Ne dediklerini dikkatlice dinleyin. Bir şeyi net bir şekilde anlamadılarsa, muhtemelen çok parlak olmadıkları için değildir. Çok net olmamanız daha olasıdır. (Devam edin ve testlerini okuyarak rolleri tersine çevirin!) + +by [Gerard Meszaros](http://programmer.97things.oreilly.com/wiki/index.php/Gerard_Meszaros) From f62e979c9fe21cfa6207a70e8c6ed71bb7d8bb0b Mon Sep 17 00:00:00 2001 From: Baran Kaya <0barankaya@gmail.com> Date: Tue, 28 Jun 2022 18:48:38 +0300 Subject: [PATCH 119/290] added thing_96 --- tr/SUMMARY.md | 2 +- tr/thing_96/README.md | 23 +++++++++++++++++++++++ 2 files changed, 24 insertions(+), 1 deletion(-) create mode 100644 tr/thing_96/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index fa333adb..ee3919c0 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -96,5 +96,5 @@ 1. [Hayatınız Boyunca Desteklemek Zorundaymışsınız Gibi Kod Yazın](thing_93/README.md) 1. [Örnekleri Kullanarak Küçük Fonksiyonlar Yazın](thing_94/README.md) 1. [İnsanlar için Testler Yaz](thing_95/README.md) -1. [You Gotta Care about the Code](thing_96/README.md) +1. [Kodu Önemsemelisiniz](thing_96/README.md) 1. [Your Customers Do not Mean What They Say](thing_97/README.md) diff --git a/tr/thing_96/README.md b/tr/thing_96/README.md new file mode 100644 index 00000000..de464009 --- /dev/null +++ b/tr/thing_96/README.md @@ -0,0 +1,23 @@ +# Kodu Önemsemelisiniz + +İyi programcıların iyi kod yazdığını anlamak için Sherlock Holmes'a gerek yok. Kötü programcılar... yapma. Geri kalanımızın temizlemesi gereken canavarlıklar üretiyorlar. İyi şeyler yazmak istiyorsun, değil mi? İyi bir programcı olmak istiyorsun. + +İyi kod birdenbire ortaya çıkmaz. Gezegenler hizalandığında şans eseri olan bir şey değil. İyi kod almak için üzerinde çalışmanız gerekir. Zordur ve yalnızca iyi kodu gerçekten önemsiyorsanız iyi kod alırsınız. + +İyi programlama sadece teknik yeterlilikten doğmaz. Yoğun ve etkileyici algoritmalar üretebilen, dil standartlarını ezbere bilen, ancak en korkunç kodu yazan son derece entelektüel programcılar gördüm. Okuması acı verici, kullanması acı verici ve değiştirmesi acı verici. Çok basit kodlara bağlı kalan, ancak birlikte çalışmaktan zevk alan zarif ve etkileyici programlar yazan daha mütevazı programcılar gördüm. + +Yazılım fabrikasında uzun yıllara dayanan deneyimime dayanarak, yeterli programcılar ile harika programcılar arasındaki gerçek farkın şu olduğu sonucuna vardım: *tutum*. İyi programlama, profesyonel bir yaklaşım benimsemekte ve yazılım fabrikasının Gerçek Dünya kısıtlamaları ve baskıları dahilinde yapabileceğiniz en iyi yazılımı yazmayı istemekte yatar. + +*Cehennemin şifresi iyi niyetlerle döşenmiştir.* Mükemmel bir programcı olmak için iyi niyetlerin üzerine çıkmanız ve aslında kodu *önemsemeniz* gerekir, olumlu bakış açıları geliştirmeniz ve sağlıklı tutumlar geliştirmeniz gerekir. Büyük kod, usta zanaatkarlar tarafından özenle hazırlanır, özensiz programcılar tarafından düşüncesizce hacklenmez veya kendi kendini kanıtlamış kodlama guruları tarafından gizemli bir şekilde dikilmez. + +İyi kod yazmak istiyorsunuz. İyi bir programcı olmak istiyorsun. Yani, kodu önemsiyorsun: + +- Herhangi bir kodlama durumunda, yalnızca işe yarıyor gibi görünen bir şeyi hacklemeyi reddediyorsunuz. Açıkça doğru olan (ve bunun doğru olduğunu gösteren iyi testleri olan) zarif bir kod oluşturmaya çalışıyorsunuz. +- *Keşfedilebilir* (diğer programcıların kolayca alıp anlayabileceği), yani *sürdürülebilir* (sizin veya diğer programcıların gelecekte kolayca değiştirebilecekleri) kod yazarsınız ve bu doğrudur ( sorunu çözdüğünü belirlemek için mümkün olan tüm adımları atarsın, sadece programın çalışıyor gibi görünmesini sağlamakla kalmazsın). +- Diğer programcılarla birlikte iyi çalışıyorsunuz. Hiçbir programcı bir ada değildir. Birkaç programcı tek başına çalışır; çoğu şirket ortamında veya açık kaynaklı bir projede programcılardan oluşan bir ekipte çalışır. Diğer programcıları düşünür ve başkalarının okuyabileceği kodlar oluşturursunuz. Kendinizi zeki göstermek yerine ekibin mümkün olan en iyi yazılımı yazmasını istiyorsunuz. +- Bir kod parçasına her dokunduğunuzda, onu bulduğunuzdan daha iyi bırakmaya çalışırsınız (ya daha iyi yapılandırılmış, daha iyi test edilmiş, daha anlaşılır...). +- Kodlamaya ve programlamaya önem veriyorsunuz, dolayısıyla sürekli yeni diller, deyimler ve teknikler öğreniyorsunuz. Ancak bunları yalnızca uygun olduğunda uygularsınız. + +Neyse ki, bu tavsiye koleksiyonunu okuyorsunuz çünkü koda önem veriyorsunuz. Seni ilgilendiriyor. Bu senin tutkun. İyi programlamalar. Zor problemleri çözmek için kod kesmenin tadını çıkarın. Sizi gururlandıran yazılımlar üretin. + +[Pete Goodliffe](http://programmer.97things.oreilly.com/wiki/index.php/Pete_Goodliffe) Tarafından \ No newline at end of file From d3ef5c1105c9302dcec55cd88dce2ffdd71364fd Mon Sep 17 00:00:00 2001 From: Baran Kaya <0barankaya@gmail.com> Date: Tue, 28 Jun 2022 18:52:50 +0300 Subject: [PATCH 120/290] added thing_97 --- tr/SUMMARY.md | 2 +- tr/thing_97/README.md | 13 +++++++++++++ 2 files changed, 14 insertions(+), 1 deletion(-) create mode 100644 tr/thing_97/README.md diff --git a/tr/SUMMARY.md b/tr/SUMMARY.md index ee3919c0..6c83319c 100644 --- a/tr/SUMMARY.md +++ b/tr/SUMMARY.md @@ -97,4 +97,4 @@ 1. [Örnekleri Kullanarak Küçük Fonksiyonlar Yazın](thing_94/README.md) 1. [İnsanlar için Testler Yaz](thing_95/README.md) 1. [Kodu Önemsemelisiniz](thing_96/README.md) -1. [Your Customers Do not Mean What They Say](thing_97/README.md) +1. [Müşterileriniz Ne Dediklerini Kastetmez](thing_97/README.md) diff --git a/tr/thing_97/README.md b/tr/thing_97/README.md new file mode 100644 index 00000000..7d5d55d8 --- /dev/null +++ b/tr/thing_97/README.md @@ -0,0 +1,13 @@ +# Müşterileriniz Ne Dediklerini Kastetmez + +Henüz bana ne istediğini söylemekten pek memnun olmayan bir müşteriyle hiç tanışmadım, genellikle çok ayrıntılı. Sorun şu ki, müşteriler size her zaman tüm gerçeği söylemezler. Genellikle yalan söylemezler, ancak geliştirici konuşmasında değil, müşteri konuşmasında konuşurlar. Terimlerini ve bağlamlarını kullanırlar. Önemli detayları atlıyorlar. Tıpkı onlar gibi, 20 yıldır şirketlerinde olduğunuzu varsayıyorlar. Bu, birçok müşterinin en başta ne istediğini bilmemesi gerçeğiyle birleşiyor! Bazıları "büyük resmi" kavrayabilir, ancak vizyonlarının ayrıntılarını nadiren etkili bir şekilde iletebilirler. Diğerleri tam vizyon konusunda biraz daha hafif olabilir, ancak ne istemediklerini biliyorlar. Peki, ne istedikleri hakkında size tüm gerçeği söylemeyen birine bir yazılım projesini nasıl teslim edebilirsiniz? Oldukça basit. Sadece onlarla daha fazla etkileşime geçin. + +Müşterilerinize erken ve sık sık meydan okuyun. Size istediklerini söylediklerini kendi sözleriyle yeniden ifade etmeyin. Unutmayın: Size söylediklerini kastetmediler. Bunu genellikle onlarla konuşurken kelimeleri değiştirerek ve tepkilerini değerlendirerek yaparım. *Müşteri* teriminin kaç kez *müşteri* teriminden tamamen farklı bir anlama sahip olduğuna şaşıracaksınız. Yine de size yazılım projesinde ne istediğini söyleyen adam, terimleri birbirinin yerine kullanacak ve hangisinden bahsettiğini takip etmenizi bekleyecektir. Kafanız karışacak ve yazdığınız yazılım zarar görecek. + +Neye ihtiyaç duyduklarını anladığınıza karar vermeden önce, müşterilerinizle konuları defalarca tartışın. Sorunu onlarla iki veya üç kez yeniden ifade etmeyi deneyin. Daha iyi bir bağlam elde etmek için konuştuğunuz konudan hemen önce veya hemen sonra olan şeyler hakkında onlarla konuşun. Mümkünse, birden fazla kişinin size aynı konuyu ayrı konuşmalarda anlatmasını sağlayın. Neredeyse her zaman size farklı ama birbiriyle ilişkili gerçekleri ortaya çıkaracak farklı hikayeler anlatacaklar. Size aynı konuyu anlatan iki kişi genellikle birbiriyle çelişir. Başarı için en iyi şansınız, ultra karmaşık yazılım oluşturmaya başlamadan önce farklılıkları ortaya çıkarmaktır. + +Görüşmelerinizde görsel araçlar kullanın. Bu, bir toplantıda beyaz tahta kullanmak kadar basit, tasarım aşamasında görsel bir maket oluşturmak kadar kolay veya işlevsel bir prototip hazırlamak kadar karmaşık olabilir. Bir konuşma sırasında görsel yardımcıların kullanılmasının dikkat süremizi uzatmaya yardımcı olduğu ve bilgilerin akılda kalma oranını artırdığı genel olarak bilinmektedir. Bu gerçeği kullanın ve projenizi başarıya hazırlayın. + +Geçmiş hayatımda, gösterişli projeler üreten bir ekipte "multimedya programcısı"ydım. Bir müşterimiz, projenin görünümü ve hissiyatı hakkındaki düşüncelerini çok detaylı bir şekilde anlattı. Tasarım toplantılarında tartışılan genel renk şeması, sunum için siyah bir arka plan gösterdi. Çivilediğimizi sanmıştık. Grafik tasarımcılarından oluşan ekipler, yüzlerce katmanlı grafik dosyasını dağıtmaya başladı. Nihai ürünü kalıplamak için çok zaman harcandı. Müşteriye emeğimizin meyvelerini gösterdiğimiz gün şaşırtıcı bir açıklama yapıldı. Ürünü gördüğünde, arka plan rengiyle ilgili sözleri tam olarak "Siyah derken beyazı kastetmiştim" idi. Yani, görüyorsun, asla siyah ve beyaz kadar net değil. + +[Nate Jackson](http://programmer.97things.oreilly.com/wiki/index.php/Icnatejackson) Tarafından \ No newline at end of file From c2650bda79372f37835a38d25ec38a801949c22b Mon Sep 17 00:00:00 2001 From: Max Coplan Date: Tue, 5 Jul 2022 16:47:31 -0700 Subject: [PATCH 121/290] =?UTF-8?q?=E2=9C=8F=EF=B8=8F=20[thing=5F20]=20fix?= =?UTF-8?q?=20typo?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- en/thing_20/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/en/thing_20/README.md b/en/thing_20/README.md index cdbe5c30..e9596868 100644 --- a/en/thing_20/README.md +++ b/en/thing_20/README.md @@ -8,8 +8,8 @@ Starting your project with an installation process will give you time to evolve Putting deployment last means that the deployment process may need to be more complicated to work around assumptions in the code. What seemed a great idea in an IDE, where you have full control over an environment, might make for a much more complicated deployment process. It is better to know all the trade-offs sooner rather than later. -While "being able to deploy" doesn't seem to have a lot of business value early on as compared to seeing an application run on a developer's laptop, the simple truth is that until you can demonstrate you application on the target environment, there is a lot of work to do before you can deliver business value. If your rationale for putting off a deployment process is that it is trivial, then do it anyway since it is low cost. If it's too complicated, or if there are too many uncertainties, do what you would do with application code: experiment, evaluate, and refactor the deployment process as you go. +While "being able to deploy" doesn't seem to have a lot of business value early on as compared to seeing an application run on a developer's laptop, the simple truth is that until you can demonstrate your application on the target environment, there is a lot of work to do before you can deliver business value. If your rationale for putting off a deployment process is that it is trivial, then do it anyway since it is low cost. If it's too complicated, or if there are too many uncertainties, do what you would do with application code: experiment, evaluate, and refactor the deployment process as you go. The installation/deployment process is essential to the productivity of your customers or your professional services team, so you should be testing and refactoring this process as you go. We test and refactor the source code throughout a project. The deployment deserves no less. -By [Steve Berczuk](http://programmer.97things.oreilly.com/wiki/index.php/Steve_Berczuk) \ No newline at end of file +By [Steve Berczuk](http://programmer.97things.oreilly.com/wiki/index.php/Steve_Berczuk) From fef5d3e611699999a405348412d761e4a9b93e75 Mon Sep 17 00:00:00 2001 From: Baran Kaya <0barankaya@gmail.com> Date: Fri, 22 Jul 2022 10:15:24 +0300 Subject: [PATCH 122/290] Update README.md --- tr/thing_97/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tr/thing_97/README.md b/tr/thing_97/README.md index 7d5d55d8..ec9a32b5 100644 --- a/tr/thing_97/README.md +++ b/tr/thing_97/README.md @@ -8,6 +8,6 @@ Neye ihtiyaç duyduklarını anladığınıza karar vermeden önce, müşteriler Görüşmelerinizde görsel araçlar kullanın. Bu, bir toplantıda beyaz tahta kullanmak kadar basit, tasarım aşamasında görsel bir maket oluşturmak kadar kolay veya işlevsel bir prototip hazırlamak kadar karmaşık olabilir. Bir konuşma sırasında görsel yardımcıların kullanılmasının dikkat süremizi uzatmaya yardımcı olduğu ve bilgilerin akılda kalma oranını artırdığı genel olarak bilinmektedir. Bu gerçeği kullanın ve projenizi başarıya hazırlayın. -Geçmiş hayatımda, gösterişli projeler üreten bir ekipte "multimedya programcısı"ydım. Bir müşterimiz, projenin görünümü ve hissiyatı hakkındaki düşüncelerini çok detaylı bir şekilde anlattı. Tasarım toplantılarında tartışılan genel renk şeması, sunum için siyah bir arka plan gösterdi. Çivilediğimizi sanmıştık. Grafik tasarımcılarından oluşan ekipler, yüzlerce katmanlı grafik dosyasını dağıtmaya başladı. Nihai ürünü kalıplamak için çok zaman harcandı. Müşteriye emeğimizin meyvelerini gösterdiğimiz gün şaşırtıcı bir açıklama yapıldı. Ürünü gördüğünde, arka plan rengiyle ilgili sözleri tam olarak "Siyah derken beyazı kastetmiştim" idi. Yani, görüyorsun, asla siyah ve beyaz kadar net değil. +Geçmiş hayatımda, gösterişli projeler üreten bir ekipte "multimedya programcısı"ydım. Bir müşterimiz, projenin görünümü ve hissiyatı hakkındaki düşüncelerini çok detaylı bir şekilde anlattı. Tasarım toplantılarında tartışılan genel renk şeması, sunum için siyah bir arka plan gösterdi. Çivilediğimizi sanmıştık. Grafik tasarımcılarından oluşan ekipler, yüzlerce katmanlı grafik dosyasını dağıtmaya başladı. Nihai ürünü kalıplamak için çok zaman harcandı. Müşteriye emeğimizin meyvelerini gösterdiğimiz gün şaşırtıcı bir açıklama yapıldı. Ürünü gördüğünde, arka plan rengiyle ilgili sözleri tam olarak "Siyah derken beyazı kastetmiştim" idi. Yani görüyorsun, asla siyah ve beyaz kadar net değil. -[Nate Jackson](http://programmer.97things.oreilly.com/wiki/index.php/Icnatejackson) Tarafından \ No newline at end of file +[Nate Jackson](http://programmer.97things.oreilly.com/wiki/index.php/Icnatejackson) Tarafından From 6368dcf7f1cbe3093b13ee3446f1d77dcff18e3f Mon Sep 17 00:00:00 2001 From: Dmitry Semigradsky Date: Fri, 22 Jul 2022 10:56:32 +0300 Subject: [PATCH 123/290] Update ru/thing_25 Fix #31 --- ru/thing_25/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ru/thing_25/README.md b/ru/thing_25/README.md index cc03ae41..52334569 100644 --- a/ru/thing_25/README.md +++ b/ru/thing_25/README.md @@ -1,7 +1,7 @@ # Комментируйте лишь то, что не ясно из кода (В оригинале - Comment Only What the Code Cannot Say) -Различий между теорией и практикой гораздо больше на практике, чем в терории – это как нельзя более актуально применительно к комментариям. В теории идея комментариев заключается в том, чтобы «объяснить то, что происходит, дать больше деталей». Чем же желание объяснить может быть плохим? Однако на практике комментарии часто начинают приносить вред, а не пользу. Как и в любом другом деле, написание хороших комментариев – это умение. И значительная часть умения состоит в том, чтобы знать, когда их вообще писать не надо. +Различий между теорией и практикой гораздо больше на практике, чем в теории – это как нельзя более актуально применительно к комментариям. В теории идея комментариев заключается в том, чтобы «объяснить то, что происходит, дать больше деталей». Чем же желание объяснить может быть плохим? Однако на практике комментарии часто начинают приносить вред, а не пользу. Как и в любом другом деле, написание хороших комментариев – это умение. И значительная часть умения состоит в том, чтобы знать, когда их вообще писать не надо. Если в коде есть ошибки, то компилятор, интерпретатор или другой подобный инструмент это сразу же обнаружат. Если ошибки есть на функциональном уровне, то ревью, статический анализ, тестирование и эксплуатация рано или поздно будут приводить к их обнаружению и устранению. А комментарии? В книге *“The Elements of Programming Style”* Kernighan и Plauger заметили, что «комментарий имеет нулевую или отрицательную ценность, если он неправильный». И такие комментарии часто сильно засоряют исходный код, оставаясь там долгое время, в отличие от ошибок в самом коде. При этом такие комментарии постоянно приводят к отвлечению внимания или даже к дезориентации того, кто этот код сопровождает. @@ -13,4 +13,4 @@ Комментируйте лишь то, что код не может сообщить в принципе, а не то, что он не сообщает сейчас. -Автор оригинала - [Kevlin Henney](http://programmer.97things.oreilly.com/wiki/index.php/Kevlin_Henney) \ No newline at end of file +Автор оригинала - [Kevlin Henney](http://programmer.97things.oreilly.com/wiki/index.php/Kevlin_Henney) From 9a4ad05353d0c77dd76839d4276222be220befb4 Mon Sep 17 00:00:00 2001 From: Max Coplan Date: Tue, 26 Jul 2022 19:54:10 -0400 Subject: [PATCH 124/290] Update README.md --- en/thing_26/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/en/thing_26/README.md b/en/thing_26/README.md index aa1ee494..0cecf78d 100644 --- a/en/thing_26/README.md +++ b/en/thing_26/README.md @@ -33,7 +33,7 @@ Not handling errors leads to: - **Brittle code.** Code that's filled with exciting, hard-to-find bugs. - **Insecure code.** Crackers often exploit poor error handling to break into software systems. -- **Poor structure.** If there are errors from your code that are tedious to deal with continually, you have probably have a poor interface. Express it so that the errors are less intrusive and the their handling is less onerous. +- **Poor structure.** If there are errors from your code that are tedious to deal with continually, you probably have a poor interface. Express it so that the errors are less intrusive and the their handling is less onerous. Just as you should check all potential errors in your code, you need to expose all potentially erroneous conditions in your interfaces. Do not hide them, pretending that your services will always work. @@ -44,4 +44,4 @@ Why don't we check for errors? There are a number of common excuses. Which of th - I know that this function call will *never* return an error (printf always works, malloc always returns new memory — if it fails we have bigger problems...). - It's only a toy program, and needn't be written to a production-worthy level. -By [Pete Goodliffe](http://programmer.97things.oreilly.com/wiki/index.php/Pete_Goodliffe) \ No newline at end of file +By [Pete Goodliffe](http://programmer.97things.oreilly.com/wiki/index.php/Pete_Goodliffe) From 674e5cc87f750bea72ba381d4f1c48cd5659eb9e Mon Sep 17 00:00:00 2001 From: ksyusha123 <72920390+ksyusha123@users.noreply.github.com> Date: Thu, 1 Sep 2022 15:10:38 +0500 Subject: [PATCH 125/290] Create README.md --- ru/thing_38/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ru/thing_38/README.md b/ru/thing_38/README.md index d8a9bdea..d1765fc8 100644 --- a/ru/thing_38/README.md +++ b/ru/thing_38/README.md @@ -3,7 +3,7 @@ Если посмотреть на любую активность, процесс или дисциплину с достаточного расстояния, то все будет выглядеть просто. Менеджеры без опыта программирования считают программирование простой задачей, а программисты без опыта руководства думают то же самое о работе менеджеров. -Самая сложная часть процесса программирования – мышление – одновременно и самая незаметная часть, а также наименее ценимая непосвященными. В течении десятилетий было много попыток устранить из процесса необходимость наличия мышления. Одна из самых ранних и наиболее запомнившихся попыток – это усилия Грейс Хоппер по созданию более понятного языка программирования, что по мнению некоторых должно было вообще снять потребность в специальности «Программист». Результат (язык COBOL) внес существенный вклад в привлечение в отрасль новых программистов в последующие десятилетия. +Самая сложная часть процесса программирования – мышление – одновременно и самая незаметная часть, а также наименее ценимая непосвященными. В течение десятилетий было много попыток устранить из процесса необходимость наличия мышления. Одна из самых ранних и наиболее запомнившихся попыток – это усилия Грейс Хоппер по созданию более понятного языка программирования, что по мнению некоторых должно было вообще снять потребность в специальности «Программист». Результат (язык COBOL) внес существенный вклад в привлечение в отрасль новых программистов в последующие десятилетия. Настойчивые попытки упростить разработку ПО так, чтобы вообще сделать программистов ненужными, для тех программистов, кто понимает, что из себя представляет процесс на самом деле, кажутся весьма наивными. Однако ментальный процесс, ведущий к такой ошибке, является частью человеческой натуры, и программисты столь же склонны к нему, как и все остальные. From 95c88af892ad8ab62fccdf850c8cca7547a9d6c6 Mon Sep 17 00:00:00 2001 From: AliDehban Date: Mon, 23 Jan 2023 14:41:01 +0300 Subject: [PATCH 126/290] Initial commit.(copy from English version) --- fr-IR/README.md | 11 +++++ fr-IR/SUMMARY.md | 100 +++++++++++++++++++++++++++++++++++++++ fr-IR/thing_01/README.md | 15 ++++++ fr-IR/thing_02/README.md | 19 ++++++++ fr-IR/thing_03/README.md | 16 +++++++ fr-IR/thing_04/README.md | 20 ++++++++ fr-IR/thing_05/README.md | 27 +++++++++++ fr-IR/thing_06/README.md | 19 ++++++++ fr-IR/thing_07/README.md | 21 ++++++++ fr-IR/thing_08/README.md | 15 ++++++ fr-IR/thing_09/README.md | 22 +++++++++ fr-IR/thing_10/README.md | 29 ++++++++++++ fr-IR/thing_11/README.md | 40 ++++++++++++++++ fr-IR/thing_12/README.md | 17 +++++++ fr-IR/thing_13/README.md | 15 ++++++ fr-IR/thing_14/README.md | 15 ++++++ fr-IR/thing_15/README.md | 25 ++++++++++ fr-IR/thing_16/README.md | 15 ++++++ fr-IR/thing_17/README.md | 13 +++++ fr-IR/thing_18/README.md | 28 +++++++++++ fr-IR/thing_19/README.md | 21 ++++++++ fr-IR/thing_20/README.md | 15 ++++++ fr-IR/thing_21/README.md | 17 +++++++ fr-IR/thing_22/README.md | 25 ++++++++++ fr-IR/thing_23/README.md | 15 ++++++ fr-IR/thing_24/README.md | 13 +++++ fr-IR/thing_25/README.md | 26 ++++++++++ fr-IR/thing_26/README.md | 47 ++++++++++++++++++ fr-IR/thing_27/README.md | 13 +++++ fr-IR/thing_28/README.md | 20 ++++++++ fr-IR/thing_29/README.md | 21 ++++++++ fr-IR/thing_30/README.md | 27 +++++++++++ fr-IR/thing_31/README.md | 23 +++++++++ fr-IR/thing_32/README.md | 15 ++++++ fr-IR/thing_33/README.md | 17 +++++++ fr-IR/thing_34/README.md | 13 +++++ fr-IR/thing_35/README.md | 13 +++++ fr-IR/thing_36/README.md | 17 +++++++ fr-IR/thing_37/README.md | 13 +++++ fr-IR/thing_38/README.md | 23 +++++++++ fr-IR/thing_39/README.md | 24 ++++++++++ fr-IR/thing_40/README.md | 24 ++++++++++ fr-IR/thing_41/README.md | 13 +++++ fr-IR/thing_42/README.md | 15 ++++++ fr-IR/thing_43/README.md | 13 +++++ fr-IR/thing_44/README.md | 19 ++++++++ fr-IR/thing_45/README.md | 23 +++++++++ fr-IR/thing_46/README.md | 49 +++++++++++++++++++ fr-IR/thing_47/README.md | 19 ++++++++ fr-IR/thing_48/README.md | 15 ++++++ fr-IR/thing_49/README.md | 19 ++++++++ fr-IR/thing_50/README.md | 31 ++++++++++++ fr-IR/thing_51/README.md | 39 +++++++++++++++ fr-IR/thing_52/README.md | 17 +++++++ fr-IR/thing_53/README.md | 52 ++++++++++++++++++++ fr-IR/thing_54/README.md | 33 +++++++++++++ fr-IR/thing_55/README.md | 16 +++++++ fr-IR/thing_56/README.md | 19 ++++++++ fr-IR/thing_57/README.md | 19 ++++++++ fr-IR/thing_58/README.md | 23 +++++++++ fr-IR/thing_59/README.md | 51 ++++++++++++++++++++ fr-IR/thing_60/README.md | 17 +++++++ fr-IR/thing_61/README.md | 15 ++++++ fr-IR/thing_62/README.md | 13 +++++ fr-IR/thing_63/README.md | 15 ++++++ fr-IR/thing_64/README.md | 25 ++++++++++ fr-IR/thing_65/README.md | 31 ++++++++++++ fr-IR/thing_66/README.md | 27 +++++++++++ fr-IR/thing_67/README.md | 19 ++++++++ fr-IR/thing_68/README.md | 19 ++++++++ fr-IR/thing_69/README.md | 50 ++++++++++++++++++++ fr-IR/thing_70/README.md | 13 +++++ fr-IR/thing_71/README.md | 13 +++++ fr-IR/thing_72/README.md | 15 ++++++ fr-IR/thing_73/README.md | 25 ++++++++++ fr-IR/thing_74/README.md | 13 +++++ fr-IR/thing_75/README.md | 19 ++++++++ fr-IR/thing_76/README.md | 41 ++++++++++++++++ fr-IR/thing_77/README.md | 23 +++++++++ fr-IR/thing_78/README.md | 29 ++++++++++++ fr-IR/thing_79/README.md | 13 +++++ fr-IR/thing_80/README.md | 15 ++++++ fr-IR/thing_81/README.md | 45 ++++++++++++++++++ fr-IR/thing_82/README.md | 15 ++++++ fr-IR/thing_83/README.md | 11 +++++ fr-IR/thing_84/README.md | 39 +++++++++++++++ fr-IR/thing_85/README.md | 23 +++++++++ fr-IR/thing_86/README.md | 23 +++++++++ fr-IR/thing_87/README.md | 15 ++++++ fr-IR/thing_88/README.md | 31 ++++++++++++ fr-IR/thing_89/README.md | 37 +++++++++++++++ fr-IR/thing_90/README.md | 17 +++++++ fr-IR/thing_91/README.md | 50 ++++++++++++++++++++ fr-IR/thing_92/README.md | 13 +++++ fr-IR/thing_93/README.md | 13 +++++ fr-IR/thing_94/README.md | 26 ++++++++++ fr-IR/thing_95/README.md | 15 ++++++ fr-IR/thing_96/README.md | 23 +++++++++ fr-IR/thing_97/README.md | 13 +++++ 99 files changed, 2268 insertions(+) create mode 100644 fr-IR/README.md create mode 100644 fr-IR/SUMMARY.md create mode 100644 fr-IR/thing_01/README.md create mode 100644 fr-IR/thing_02/README.md create mode 100644 fr-IR/thing_03/README.md create mode 100644 fr-IR/thing_04/README.md create mode 100644 fr-IR/thing_05/README.md create mode 100644 fr-IR/thing_06/README.md create mode 100644 fr-IR/thing_07/README.md create mode 100644 fr-IR/thing_08/README.md create mode 100644 fr-IR/thing_09/README.md create mode 100644 fr-IR/thing_10/README.md create mode 100644 fr-IR/thing_11/README.md create mode 100644 fr-IR/thing_12/README.md create mode 100644 fr-IR/thing_13/README.md create mode 100644 fr-IR/thing_14/README.md create mode 100644 fr-IR/thing_15/README.md create mode 100644 fr-IR/thing_16/README.md create mode 100644 fr-IR/thing_17/README.md create mode 100644 fr-IR/thing_18/README.md create mode 100644 fr-IR/thing_19/README.md create mode 100644 fr-IR/thing_20/README.md create mode 100644 fr-IR/thing_21/README.md create mode 100644 fr-IR/thing_22/README.md create mode 100644 fr-IR/thing_23/README.md create mode 100644 fr-IR/thing_24/README.md create mode 100644 fr-IR/thing_25/README.md create mode 100644 fr-IR/thing_26/README.md create mode 100644 fr-IR/thing_27/README.md create mode 100644 fr-IR/thing_28/README.md create mode 100644 fr-IR/thing_29/README.md create mode 100644 fr-IR/thing_30/README.md create mode 100644 fr-IR/thing_31/README.md create mode 100644 fr-IR/thing_32/README.md create mode 100644 fr-IR/thing_33/README.md create mode 100644 fr-IR/thing_34/README.md create mode 100644 fr-IR/thing_35/README.md create mode 100644 fr-IR/thing_36/README.md create mode 100644 fr-IR/thing_37/README.md create mode 100644 fr-IR/thing_38/README.md create mode 100644 fr-IR/thing_39/README.md create mode 100644 fr-IR/thing_40/README.md create mode 100644 fr-IR/thing_41/README.md create mode 100644 fr-IR/thing_42/README.md create mode 100644 fr-IR/thing_43/README.md create mode 100644 fr-IR/thing_44/README.md create mode 100644 fr-IR/thing_45/README.md create mode 100644 fr-IR/thing_46/README.md create mode 100644 fr-IR/thing_47/README.md create mode 100644 fr-IR/thing_48/README.md create mode 100644 fr-IR/thing_49/README.md create mode 100644 fr-IR/thing_50/README.md create mode 100644 fr-IR/thing_51/README.md create mode 100644 fr-IR/thing_52/README.md create mode 100644 fr-IR/thing_53/README.md create mode 100644 fr-IR/thing_54/README.md create mode 100644 fr-IR/thing_55/README.md create mode 100644 fr-IR/thing_56/README.md create mode 100644 fr-IR/thing_57/README.md create mode 100644 fr-IR/thing_58/README.md create mode 100644 fr-IR/thing_59/README.md create mode 100644 fr-IR/thing_60/README.md create mode 100644 fr-IR/thing_61/README.md create mode 100644 fr-IR/thing_62/README.md create mode 100644 fr-IR/thing_63/README.md create mode 100644 fr-IR/thing_64/README.md create mode 100644 fr-IR/thing_65/README.md create mode 100644 fr-IR/thing_66/README.md create mode 100644 fr-IR/thing_67/README.md create mode 100644 fr-IR/thing_68/README.md create mode 100644 fr-IR/thing_69/README.md create mode 100644 fr-IR/thing_70/README.md create mode 100644 fr-IR/thing_71/README.md create mode 100644 fr-IR/thing_72/README.md create mode 100644 fr-IR/thing_73/README.md create mode 100644 fr-IR/thing_74/README.md create mode 100644 fr-IR/thing_75/README.md create mode 100644 fr-IR/thing_76/README.md create mode 100644 fr-IR/thing_77/README.md create mode 100644 fr-IR/thing_78/README.md create mode 100644 fr-IR/thing_79/README.md create mode 100644 fr-IR/thing_80/README.md create mode 100644 fr-IR/thing_81/README.md create mode 100644 fr-IR/thing_82/README.md create mode 100644 fr-IR/thing_83/README.md create mode 100644 fr-IR/thing_84/README.md create mode 100644 fr-IR/thing_85/README.md create mode 100644 fr-IR/thing_86/README.md create mode 100644 fr-IR/thing_87/README.md create mode 100644 fr-IR/thing_88/README.md create mode 100644 fr-IR/thing_89/README.md create mode 100644 fr-IR/thing_90/README.md create mode 100644 fr-IR/thing_91/README.md create mode 100644 fr-IR/thing_92/README.md create mode 100644 fr-IR/thing_93/README.md create mode 100644 fr-IR/thing_94/README.md create mode 100644 fr-IR/thing_95/README.md create mode 100644 fr-IR/thing_96/README.md create mode 100644 fr-IR/thing_97/README.md diff --git a/fr-IR/README.md b/fr-IR/README.md new file mode 100644 index 00000000..aa344994 --- /dev/null +++ b/fr-IR/README.md @@ -0,0 +1,11 @@ +97 چیزی که هر برنامه نویس باید بداند +====== + +*Pearls of wisdom for programmers collected from leading practitioners.* + + +This is a [GitBook](https://www.gitbook.io) version of the ['97 Things Every Programmer Should Know' project](http://programmer.97things.oreilly.com/wiki/index.php/97_Things_Every_Programmer_Should_Know). + +All content is licensed under the [Creative Commons Attribution-NonCommercial-ShareAlike 3.0 license](http://creativecommons.org/licenses/by-nc-sa/3.0/). Print versions of the book are available on [Amazon.com](http://www.amazon.com/Things-Every-Programmer-Should-Know/dp/0596809484). + +If you find any mistakes or have any suggestions, you can [create an issue](https://github.com/97-things/97-things-every-programmer-should-know/issues) or [file a pull request](https://github.com/97-things/97-things-every-programmer-should-know/pulls) to the [repository](https://github.com/97-things/97-things-every-programmer-should-know). diff --git a/fr-IR/SUMMARY.md b/fr-IR/SUMMARY.md new file mode 100644 index 00000000..782cb57d --- /dev/null +++ b/fr-IR/SUMMARY.md @@ -0,0 +1,100 @@ +# Summary + +* [Introduction](README.md) +1. [Act with Prudence](thing_01/README.md) +1. [Apply Functional Programming Principles](thing_02/README.md) +1. [Ask "What Would the User Do?" (You Are not the User)](thing_03/README.md) +1. [Automate Your Coding Standard](thing_04/README.md) +1. [Beauty Is in Simplicity](thing_05/README.md) +1. [Before You Refactor](thing_06/README.md) +1. [Beware the Share](thing_07/README.md) +1. [The Boy Scout Rule](thing_08/README.md) +1. [Check Your Code First before Looking to Blame Others](thing_09/README.md) +1. [Choose Your Tools with Care](thing_10/README.md) +1. [Code in the Language of the Domain](thing_11/README.md) +1. [Code Is Design](thing_12/README.md) +1. [Code Layout Matters](thing_13/README.md) +1. [Code Reviews](thing_14/README.md) +1. [Coding with Reason](thing_15/README.md) +1. [A Comment on Comments](thing_16/README.md) +1. [Comment Only What the Code Cannot Say](thing_17/README.md) +1. [Continuous Learning](thing_18/README.md) +1. [Convenience Is not an -ility](thing_19/README.md) +1. [Deploy Early and Often](thing_20/README.md) +1. [Distinguish Business Exceptions from Technical](thing_21/README.md) +1. [Do Lots of Deliberate Practice](thing_22/README.md) +1. [Domain-Specific Languages](thing_23/README.md) +1. [Don't Be Afraid to Break Things](thing_24/README.md) +1. [Don't Be Cute with Your Test Data](thing_25/README.md) +1. [Don't Ignore that Error!](thing_26/README.md) +1. [Don't Just Learn the Language, Understand its Culture](thing_27/README.md) +1. [Don't Nail Your Program into the Upright Position](thing_28/README.md) +1. [Don't Rely on "Magic Happens Here"](thing_29/README.md) +1. [Don't Repeat Yourself](thing_30/README.md) +1. [Don't Touch that Code!](thing_31/README.md) +1. [Encapsulate Behavior, not Just State](thing_32/README.md) +1. [Floating-point Numbers Aren't Real](thing_33/README.md) +1. [Fulfill Your Ambitions with Open Source](thing_34/README.md) +1. [The Golden Rule of API Design](thing_35/README.md) +1. [The Guru Myth](thing_36/README.md) +1. [Hard Work Does not Pay Off](thing_37/README.md) +1. [How to Use a Bug Tracker](thing_38/README.md) +1. [Improve Code by Removing It](thing_39/README.md) +1. [Install Me](thing_40/README.md) +1. [Inter-Process Communication Affects Application Response Time](thing_41/README.md) +1. [Keep the Build Clean](thing_42/README.md) +1. [Know How to Use Command-line Tools](thing_43/README.md) +1. [Know Well More than Two Programming Languages](thing_44/README.md) +1. [Know Your IDE](thing_45/README.md) +1. [Know Your Limits](thing_46/README.md) +1. [Know Your Next Commit](thing_47/README.md) +1. [Large Interconnected Data Belongs to a Database](thing_48/README.md) +1. [Learn Foreign Languages](thing_49/README.md) +1. [Learn to Estimate](thing_50/README.md) +1. [Learn to Say "Hello, World"](thing_51/README.md) +1. [Let Your Project Speak for Itself](thing_52/README.md) +1. [The Linker Is not a Magical Program](thing_53/README.md) +1. [The Longevity of Interim Solutions](thing_54/README.md) +1. [Make Interfaces Easy to Use Correctly and Hard to Use Incorrectly](thing_55/README.md) +1. [Make the Invisible More Visible](thing_56/README.md) +1. [Message Passing Leads to Better Scalability in Parallel Systems](thing_57/README.md) +1. [A Message to the Future](thing_58/README.md) +1. [Missing Opportunities for Polymorphism](thing_59/README.md) +1. [News of the Weird: Testers Are Your Friends](thing_60/README.md) +1. [One Binary](thing_61/README.md) +1. [Only the Code Tells the Truth](thing_62/README.md) +1. [Own (and Refactor) the Build](thing_63/README.md) +1. [Pair Program and Feel the Flow](thing_64/README.md) +1. [Prefer Domain-Specific Types to Primitive Types](thing_65/README.md) +1. [Prevent Errors](thing_66/README.md) +1. [The Professional Programmer](thing_67/README.md) +1. [Put Everything Under Version Control](thing_68/README.md) +1. [Put the Mouse Down and Step Away from the Keyboard](thing_69/README.md) +1. [Read Code](thing_70/README.md) +1. [Read the Humanities](thing_71/README.md) +1. [Reinvent the Wheel Often](thing_72/README.md) +1. [Resist the Temptation of the Singleton Pattern](thing_73/README.md) +1. [The Road to Performance Is Littered with Dirty Code Bombs](thing_74/README.md) +1. [Simplicity Comes from Reduction](thing_75/README.md) +1. [The Single Responsibility Principle](thing_76/README.md) +1. [Start from Yes](thing_77/README.md) +1. [Step Back and Automate, Automate, Automate](thing_78/README.md) +1. [Take Advantage of Code Analysis Tools](thing_79/README.md) +1. [Test for Required Behavior, not Incidental Behavior](thing_80/README.md) +1. [Test Precisely and Concretely](thing_81/README.md) +1. [Test While You Sleep (and over Weekends)](thing_82/README.md) +1. [Testing Is the Engineering Rigor of Software Development](thing_83/README.md) +1. [Thinking in States](thing_84/README.md) +1. [Two Heads Are Often Better than One](thing_85/README.md) +1. [Two Wrongs Can Make a Right (and Are Difficult to Fix)](thing_86/README.md) +1. [Ubuntu Coding for Your Friends](thing_87/README.md) +1. [The Unix Tools Are Your Friends](thing_88/README.md) +1. [Use the Right Algorithm and Data Structure](thing_89/README.md) +1. [Verbose Logging Will Disturb Your Sleep](thing_90/README.md) +1. [WET Dilutes Performance Bottlenecks](thing_91/README.md) +1. [When Programmers and Testers Collaborate](thing_92/README.md) +1. [Write Code as If You Had to Support It for the Rest of Your Life](thing_93/README.md) +1. [Write Small Functions Using Examples](thing_94/README.md) +1. [Write Tests for People](thing_95/README.md) +1. [You Gotta Care about the Code](thing_96/README.md) +1. [Your Customers Do not Mean What They Say](thing_97/README.md) diff --git a/fr-IR/thing_01/README.md b/fr-IR/thing_01/README.md new file mode 100644 index 00000000..3604026b --- /dev/null +++ b/fr-IR/thing_01/README.md @@ -0,0 +1,15 @@ +# Act with Prudence + +> *"Whatever you undertake, act with prudence and consider the consequences" Anon* + +No matter how comfortable a schedule looks at the beginning of an iteration, you can't avoid being under pressure some of the time. If you find yourself having to choose between "doing it right" and "doing it quick" it is often appealing to "do it quick" on the understanding that you'll come back and fix it later. When you make this promise to yourself, your team, and your customer, you mean it. But all too often the next iteration brings new problems and you become focused on them. This sort of deferred work is known as technical debt and it is not your friend. Specifically, Martin Fowler calls this deliberate technical debt in his [taxonomy of technical debt](http://martinfowler.com/bliki/TechnicalDebtQuadrant.html), which should not be confused with inadvertent technical debt. + +Technical debt is like a loan: You benefit from it in the short-term, but you have to pay interest on it until it is fully paid off. Shortcuts in the code make it harder to add features or refactor your code. They are breeding grounds for defects and brittle test cases. The longer you leave it, the worse it gets. By the time you get around to undertaking the original fix there may be a whole stack of not-quite-right design choices layered on top of the original problem making the code much harder to refactor and correct. In fact, it is often only when things have got so bad that you must fix it, that you actually do go back to fix it. And by then it is often so hard to fix that you really can't afford the time or the risk. + +There are times when you must incur technical debt to meet a deadline or implement a thin slice of a feature. Try not to be in this position, but if the situation absolutely demands it, then go ahead. But (and this is a big BUT) you must track technical debt and pay it back quickly or things go rapidly downhill. As soon as you make the decision to compromise, write a task card or log it in your issue tracking system to ensure that it does not get forgotten. + +If you schedule repayment of the debt in the next iteration, the cost will be minimal. Leaving the debt unpaid will accrue interest and that interest should be tracked to make the cost visible. This will emphasize the effect on business value of the project's technical debt and enables appropriate prioritization of the repayment. The choice of how to calculate and track the interest will depend on the particular project, but track it you must. + +Pay off technical debt as soon as possible. It would be imprudent to do otherwise. + +By [Seb Rose](http://programmer.97things.oreilly.com/wiki/index.php/Seb_Rose) \ No newline at end of file diff --git a/fr-IR/thing_02/README.md b/fr-IR/thing_02/README.md new file mode 100644 index 00000000..bf229069 --- /dev/null +++ b/fr-IR/thing_02/README.md @@ -0,0 +1,19 @@ +# Apply Functional Programming Principles + +Functional programming has recently enjoyed renewed interest from the mainstream programming community. Part of the reason is because *emergent properties* of the functional paradigm are well positioned to address the challenges posed by our industry's shift toward multi-core. However, while that is certainly an important application, it is not the reason this piece admonishes you to *know thy functional programming*. + +Mastery of the functional programming paradigm can greatly improve the quality of the code you write in other contexts. If you deeply understand and apply the functional paradigm, your designs will exhibit a much higher degree of *referential transparency*. + +Referential transparency is a very desirable property: It implies that functions consistently yield the same results given the same input, irrespective of where and when they are invoked. That is, function evaluation depends less — ideally, not at all — on the side effects of mutable state. + +A leading cause of defects in imperative code is attributable to mutable variables. Everyone reading this will have investigated why some value is not as expected in a particular situation. Visibility semantics can help to mitigate these insidious defects, or at least to drastically narrow down their location, but their true culprit may in fact be the providence of designs that employ inordinate mutability. + +And we certainly don't get much help from industry in this regard. Introductions to object orientation tacitly promote such design, because they often show examples composed of graphs of relatively long-lived objects that happily call mutator methods on each other, which can be dangerous. However, with astute test-driven design, particularly when being sure to ["Mock Roles, not Objects"](http://www.jmock.org/oopsla2004.pdf), unnecessary mutability can be designed away. + +The net result is a design that typically has better responsibility allocation with more numerous, smaller functions that act on arguments passed into them, rather than referencing mutable member variables. There will be fewer defects, and furthermore they will often be simpler to debug, because it is easier to locate where a rogue value is introduced in these designs than to otherwise deduce the particular context that results in an erroneous assignment. This adds up to a much higher degree of referential transparency, and positively nothing will get these ideas as deeply into your bones as learning a functional programming language, where this model of computation is the norm. + +Of course, this approach is not optimal in all situations. For example, in object-oriented systems this style often yields better results with domain model development (i.e., where collaborations serve to break down the complexity of business rules) than with user-interface development. + +Master the functional programming paradigm so you are able to judiciously apply the lessons learned to other domains. Your object systems (for one) will resonate with referential transparency goodness and be much closer to their functional counterparts than many would have you believe. In fact, some would even assert that the apex of functional programming and object orientation are *merely a reflection of each other*, a form of computational yin and yang. + +By [Edward Garson](http://programmer.97things.oreilly.com/wiki/index.php/Edward_Garson) \ No newline at end of file diff --git a/fr-IR/thing_03/README.md b/fr-IR/thing_03/README.md new file mode 100644 index 00000000..f101d7ad --- /dev/null +++ b/fr-IR/thing_03/README.md @@ -0,0 +1,16 @@ +# Ask "What Would the User Do?" (You Are not the User) + +We all tend to assume that other people think like us. But they don't. Psychologists call this the false consensus bias. When people think or act differently to us, we're quite likely to label them (subconsciously) as defective in some way. + +This bias explains why programmers have such a hard time putting themselves in the users' position. Users don't think like programmers. For a start, they spend much less time using computers. They neither know nor care how a computer works. This means they can't draw on any of the battery of problem-solving techniques so familiar to programmers. They don't recognize the patterns and cues programmers use to work with, through, and around an interface. + +The best way to find out how users think is to watch one. Ask a user to complete a task using a similar piece of software to what you're developing. Make sure the task is a real one: "Add up a column of numbers" is OK; "Calculate your expenses for the last month" is better. Avoid tasks that are too specific, such as "Can you select these spreadsheet cells and enter a *SUM* formula below?" — there's a big clue in that question. Get the user to talk through his or her progress. Don't interrupt. Don't try to help. Keep asking yourself "Why is he doing that?" and "Why is she not doing that?" + +The first thing you'll notice is that users do a core of things similarly. They try to complete tasks in the same order — and they make the same mistakes in the same places. You should design around that core behavior. This is different from design meetings, where people tend to be listened to for saying "What if the user wants to...?" This leads to elaborate features and confusion over what users want. Watching users eliminates this confusion. + +You'll see users getting stuck. When you get stuck, you look around. When users get stuck, they narrow their focus. It becomes harder for them to see solutions elsewhere on the screen. It's one reason why help text is a poor solution to poor user interface design. If you must have instructions or help text, make sure to locate it right next to your problem areas. A user's narrow focus of attention is why tool tips are more useful than help menus. + +Users tend to muddle through. They'll find a way that works and stick with it no matter how convoluted. It's better to provide one really obvious way of doing things than two or three shortcuts. +You'll also find that there's a gap between what users say they want and what they actually do. That's worrying as the normal way of gathering user requirements is to ask them. It's why the best way to capture requirements is to watch users. Spending an hour watching users is more informative than spending a day guessing what they want. + +by [Giles Colborne](http://programmer.97things.oreilly.com/wiki/index.php/Giles_Colborne) \ No newline at end of file diff --git a/fr-IR/thing_04/README.md b/fr-IR/thing_04/README.md new file mode 100644 index 00000000..7bc02205 --- /dev/null +++ b/fr-IR/thing_04/README.md @@ -0,0 +1,20 @@ +# Automate Your Coding Standard + +You've probably been there too. At the beginning of a project, everybody has lots of good intentions — call them "new project's resolutions." Quite often, many of these resolutions are written down in documents. The ones about code end up in the project's coding standard. During the kick-off meeting, the lead developer goes through the document and, in the best case, everybody agrees that they will try to follow them. Once the project gets underway, though, these good intentions are abandoned, one at a time. When the project is finally delivered the code looks like a mess, and nobody seems to know how it came to be this way. + +When did things go wrong? Probably already at the kick-off meeting. Some of the project members didn't pay attention. Others didn't understand the point. Worse, some disagreed and were already planning their coding standard rebellion. Finally, some got the point and agreed but, when the pressure in the project got too high, they had to let something go. Well-formatted code doesn't earn you points with a customer that wants more functionality. Furthermore, following a coding standard can be quite a boring task if it isn't automated. Just try to indent a messy class by hand to find out for yourself. + +But if it's such a problem, why is that we want to have a coding standard in the first place? One reason to format the code in a uniform way is so that nobody can "own" a piece of code just by formatting it in his or her private way. We may want to prevent developers using certain anti-patterns, in order to avoid some common bugs. In all, a coding standard should make it easier to work in the project, and maintain development speed from the beginning to the end. It follows then that everybody should agree on the coding standard too — it does not help if one developer uses three spaces to indent code, and another one four. + +There exists a wealth of tools that can be used to produce code quality reports and to document and maintain the coding standard, but that isn't the whole solution. It should be automated and enforced where possible. Here are a few examples: + +- Make sure code formatting is part of the build process, so that everybody runs it automatically every time they compile the code. +- Use static code analysis tools to scan the code for unwanted anti-patterns. If any are found, break the build. +- Learn to configure those tools so that you can scan for your own, project-specific anti-patterns. +- Do not only measure test coverage, but automatically check the results too. Again, break the build if test coverage is too low. + +Try to do this for everything that you consider important. You won't be able to automate everything you really care about. As for the things that you can't automatically flag or fix, consider them to be a set of guidelines supplementary to the coding standard that is automated, but accept that you and your colleagues may not follow them as diligently. + +Finally, the coding standard should be dynamic rather than static. As the project evolves, the needs of the project change, and what may have seemed smart in the beginning, isn't necessarily smart a few months later. + +By [Filip van Laenen](http://programmer.97things.oreilly.com/wiki/index.php/Filip_van_Laenen) \ No newline at end of file diff --git a/fr-IR/thing_05/README.md b/fr-IR/thing_05/README.md new file mode 100644 index 00000000..b25e7757 --- /dev/null +++ b/fr-IR/thing_05/README.md @@ -0,0 +1,27 @@ +# Beauty Is in Simplicity + +There is one quote that I think is particularly good for all software developers to know and keep close to their hearts: + +> *Beauty of style and harmony and grace and good rhythm depends on simplicity.* — Plato + +In one sentence I think this sums up the values that we as software developers should aspire to. + +There are a number of things we strive for in our code: + +- Readability +- Maintainability +- Speed of development +- The elusive quality of beauty + +Plato is telling us that the enabling factor for all of these qualities is simplicity. + +What is beautiful code? This is potentially a very subjective question. Perception of beauty depends heavily on individual background, just as much of our perception of anything depends on our background. People educated in the arts have a different perception of (or at least approach to) beauty than people educated in the sciences. Arts majors tend to approach beauty in software by comparing software to works of art, while science majors tend to talk about symmetry and the golden ratio, trying to reduce things to formulae. In my experience, simplicity is the foundation of most of the arguments from both sides. + +Think about source code that you have studied. If you haven't spent time studying other people's code, stop reading this right now and find some open source code to study. Seriously! I mean it! Go search the web for some code in your language of choice, written by some well-known, acknowledged expert. + +You're back? Good. Where were we? Ah yes... I have found that code that resonates with me and that I consider beautiful has a number of properties in common. Chief among these is simplicity. I find that no matter how complex the total application or system is, the individual parts have to be kept simple. Simple objects with a single responsibility containing similarly simple, focused methods with descriptive names. Some people think the idea of having short methods of five to ten lines of code is extreme, and some languages make it very hard to do this, but I think that such brevity is a desirable goal nonetheless. + +The bottom line is that beautiful code is simple code. Each individual part is kept simple with simple responsibilities and simple relationships with the other parts of the system. This is the way we can keep our systems maintainable over time, with clean, simple, testable code, keeping the speed of development high throughout the lifetime of the system. +Beauty is born of and found in simplicity. + +By Jørn Ølmheim \ No newline at end of file diff --git a/fr-IR/thing_06/README.md b/fr-IR/thing_06/README.md new file mode 100644 index 00000000..a1c73ce3 --- /dev/null +++ b/fr-IR/thing_06/README.md @@ -0,0 +1,19 @@ +# Before You Refactor + +At some point every programmer will need to refactor existing code. But before you do so please think about the following, as this could save you and others a great deal of time (and pain): + +- *The best approach for restructuring starts by taking stock of the existing codebase and the tests written against that code.* This will help you understand the strengths and weaknesses of the code as it currently stands, so you can ensure that you retain the strong points while avoiding the mistakes. We all think we can do better than the existing system... until we end up with something no better — or even worse — than the previous incarnation because we failed to learn from the existing system's mistakes. + +- *Avoid the temptation to rewrite everything.* It is best to reuse as much code as possible. No matter how ugly the code is, it has already been tested, reviewed, etc. Throwing away the old code — especially if it was in production — means that you are throwing away months (or years) of tested, battle-hardened code that may have had certain workarounds and bug fixes you aren't aware of. If you don't take this into account, the new code you write may end up showing the same mysterious bugs that were fixed in the old code. This will waste a lot of time, effort, and knowledge gained over the years. + +- *Many incremental changes are better than one massive change.* Incremental changes allows you to gauge the impact on the system more easily through feedback, such as from tests. It is no fun to see a hundred test failures after you make a change. This can lead to frustration and pressure that can in turn result in bad decisions. A couple of test failures is easy to deal with and provides a more manageable approach. + +- *After each iteration, it is important to ensure that the existing tests pass.* Add new tests if the existing tests are not sufficient to cover the changes you made. Do not throw away the tests from the old code without due consideration. On the surface some of these tests may not appear to be applicable to your new design, but it would be well worth the effort to dig deep down into the reasons why this particular test was added. + +- *Personal preferences and ego shouldn't get in the way.* If something isn't broken, why fix it? That the style or the structure of the code does not meet your personal preference is not a valid reason for restructuring. Thinking you could do a better job than the previous programmer is not a valid reason either. + +- *New technology is insufficient reason to refactor.* One of the worst reasons to refactor is because the current code is way behind all the cool technology we have today, and we believe that a new language or framework can do things a lot more elegantly. Unless a cost–benefit analysis shows that a new language or framework will result in significant improvements in functionality, maintainability, or productivity, it is best to leave it as it is. + +- *Remember that humans make mistakes.* Restructuring will not always guarantee that the new code will be better — or even as good as — the previous attempt. I have seen and been a part of several failed restructuring attempts. It wasn't pretty, but it was human. + +by [Rajith Attapattu](http://programmer.97things.oreilly.com/wiki/index.php/Rajith_Attapattu) \ No newline at end of file diff --git a/fr-IR/thing_07/README.md b/fr-IR/thing_07/README.md new file mode 100644 index 00000000..e0fc4dcf --- /dev/null +++ b/fr-IR/thing_07/README.md @@ -0,0 +1,21 @@ +# Beware the Share + +It was my first project at the company. I'd just finished my degree and was anxious to prove myself, staying late every day going through the existing code. As I worked through my first feature I took extra care to put in place everything I had learned — commenting, logging, pulling out shared code into libraries where possible, the works. The code review that I had felt so ready for came as a rude awakening — reuse was frowned upon! + +How could this be? All through college reuse was held up as the epitome of quality software engineering. All the articles I had read, the textbooks, the seasoned software professionals who taught me. Was it all wrong? + +It turns out that I was missing something critical. + +Context. + +The fact that two wildly different parts of the system performed some logic in the same way meant less than I thought. Up until I had pulled out those libraries of shared code, these parts were not dependent on each other. Each could evolve independently. Each could change its logic to suit the needs of the system's changing business environment. Those four lines of similar code were accidental — a temporal anomaly, a coincidence. That is, until I came along. + +The libraries of shared code I created tied the shoelaces of each foot to each other. Steps by one business domain could not be made without first synchronizing with the other. Maintenance costs in those independent functions used to be negligible, but the common library required an order of magnitude more testing. + +While I'd decreased the absolute number of lines of code in the system, I had increased the number of dependencies. The context of these dependencies is critical — had they been localized, it may have been justified and had some positive value. When these dependencies aren't held in check, their tendrils entangle the larger concerns of the system even though the code itself looks just fine. + +These mistakes are insidious in that, at their core, they sound like a good idea. When applied in the right context, these techniques are valuable. In the wrong context, they increase cost rather than value. When coming into an existing code base with no knowledge of the context where the various parts will be used, I'm much more careful these days about what is shared. + +Beware the share. Check your context. Only then, proceed. + +By [Udi Dahan](http://programmer.97things.oreilly.com/wiki/index.php/Udi_Dahan) \ No newline at end of file diff --git a/fr-IR/thing_08/README.md b/fr-IR/thing_08/README.md new file mode 100644 index 00000000..b14af7dd --- /dev/null +++ b/fr-IR/thing_08/README.md @@ -0,0 +1,15 @@ +# The Boy Scout Rule + +The Boy Scouts have a rule: "Always leave the campground cleaner than you found it." If you find a mess on the ground, you clean it up regardless of who might have made the mess. You intentionally improve the environment for the next group of campers. Actually the original form of that rule, written by Robert Stephenson Smyth Baden-Powell, the father of scouting, was "Try and leave this world a little better than you found it." + +What if we followed a similar rule in our code: "Always check a module in cleaner than when you checked it out." No matter who the original author was, what if we always made some effort, no matter how small, to improve the module. What would be the result? + +I think if we all followed that simple rule, we'd see the end of the relentless deterioration of our software systems. Instead, our systems would gradually get better and better as they evolved. We'd also see *teams* caring for the system as a whole, rather than just individuals caring for their own small little part. + +I don't think this rule is too much to ask. You don't have to make every module perfect before you check it in. You simply have to make it a *little bit better* than when you checked it out. Of course, this means that any code you *add* to a module must be clean. It also means that you clean up at least one other thing before you check the module back in. You might simply improve the name of one variable, or split one long function into two smaller functions. You might break a circular dependency, or add an interface to decouple policy from detail. + +Frankly, this just sounds like common decency to me — like washing your hands after you use the restroom, or putting your trash in the bin instead of dropping it on the floor. Indeed the act of leaving a mess in the code should be as socially unacceptable as *littering*. It should be something that *just isn't done*. + +But it's more than that. Caring for our own code is one thing. Caring for the team's code is quite another. Teams help each other, and clean up after each other. They follow the Boy Scout rule because it's good for everyone, not just good for themselves. + +by [Uncle Bob](http://programmer.97things.oreilly.com/wiki/index.php/Uncle_Bob) \ No newline at end of file diff --git a/fr-IR/thing_09/README.md b/fr-IR/thing_09/README.md new file mode 100644 index 00000000..112231cb --- /dev/null +++ b/fr-IR/thing_09/README.md @@ -0,0 +1,22 @@ +# Check Your Code First before Looking to Blame Others + +Developers — all of us! — often have trouble believing our own code is broken. It is just so improbable that, for once, it must be the compiler that's broken. + +Yet in truth it is very (very) unusual that code is broken by a bug in the compiler, interpreter, OS, app server, database, memory manager, or any other piece of system software. Yes, these bugs exist, but they are far less common than we might like to believe. + +I once had a genuine problem with a compiler bug optimizing away a loop variable, but I have imagined my compiler or OS had a bug many more times. I have wasted a lot of my time, support time, and management time in the process only to feel a little foolish each time it turned out to be my mistake after all. + +Assuming the tools are widely used, mature, and employed in various technology stacks, there is little reason to doubt the quality. Of course, if the tool is an early release, or used by only a few people worldwide, or a piece of seldom downloaded, version 0.1, Open Source Software, there may be good reason to suspect the software. (Equally, an alpha version of commercial software might be suspect.) + +Given how rare compiler bugs are, you are far better putting your time and energy into finding the error in your code than proving the compiler is wrong. All the usual debugging advice applies, so isolate the problem, stub out calls, surround it with tests; check calling conventions, shared libraries, and version numbers; explain it to someone else; look out for stack corruption and variable type mismatches; try the code on different machines and different build configurations, such as debug and release. + +Question your own assumptions and the assumptions of others. Tools from different vendors might have different assumptions built into them — so too might different tools from the same vendor. +When someone else is reporting a problem you cannot duplicate, go and see what they are doing. They may be doing something you never thought of or are doing something in a different order. + +As a personal rule if I have a bug I can't pin down, and I'm starting to think it's the compiler, then it's time to look for stack corruption. This is especially true if adding trace code makes the problem move around. + +Multi-threaded problems are another source of bugs to turn hair gray and induce screaming at the machine. All the recommendations to favor simple code are multiplied when a system is multi-threaded. Debugging and unit tests cannot be relied on to find such bugs with any consistency, so simplicity of design is paramount. + +So before you rush to blame the compiler, remember Sherlock Holmes' advice, "Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth," and prefer it to Dirk Gently's, "Once you eliminate the improbable, whatever remains, no matter how impossible, must be the truth." + +By [Allan Kelly](http://programmer.97things.oreilly.com/wiki/index.php/Allan_Kelly) diff --git a/fr-IR/thing_10/README.md b/fr-IR/thing_10/README.md new file mode 100644 index 00000000..8d08c3bc --- /dev/null +++ b/fr-IR/thing_10/README.md @@ -0,0 +1,29 @@ +# Choose Your Tools with Care + +Modern applications are very rarely built from scratch. They are assembled using existing tools — components, libraries, and frameworks — for a number of good reasons: + +- Applications grow in size, complexity, and sophistication, while the time available to develop them grows shorter. It makes better use of developers' time and intelligence if they can concentrate on writing more business-domain code and less infrastructure code. + +- Widely used components and frameworks are likely to have fewer bugs than the ones developed in-house. + +- There is a lot of high-quality software available on the web for free, which means lower development costs and greater likelihood of finding developers with the necessary interest and expertise. + +- Software production and maintenance is human-intensive work, so buying may be cheaper than building. + +However, choosing the right mix of tools for your application can be a tricky business requiring some thought. In fact when making a choice, there are a few things you should keep in mind: + +- Different tools may rely on different assumptions about their context — e.g., surrounding infrastructure, control model, data model, communication protocols, etc. — which can lead to an architectural mismatch between the application and the tools. Such a mismatch leads to hacks and workarounds that will make the code more complex than necessary. + +- Different tools have different lifecycles, and upgrading one of them may become an extremely difficult and time-consuming task since the new functionality, design changes, or even bug fixes may cause incompatibilities with the other tools. The greater the number tools the worse the problem can become. + +- Some tools require quite a bit of configuration, often by means of one or more XML files, which can grow out of control very quickly. The application may end up looking as if it was all written in XML plus a few odd lines of code in some programming language. The configurational complexity will make the application difficult to maintain and to extend. + +- Vendor lock-in occurs when code that depends heavily on specific vendor products ends up being constrained by them on several counts: maintainability, performances, ability to evolve, price, etc. + +- If you plan to use free software, you may discover that it's not so free after all. You may need to buy commercial support, which is not necessarily going to be cheap. + +- Licensing terms matter, even for free software. For example, in some companies it is not acceptable to use software licensed under the GNU license terms because of its viral nature — i.e., software developed with it must be distributed along with its source code. + +My personal strategy to mitigate these problems is to start small by using only the tools that are absolutely necessary. Usually the initial focus is on removing the need to engage in low-level infrastructure programming (and problems), e.g., by using some middleware instead of using raw sockets for distributed applications. And then add more if needed. I also tend to isolate the external tools from my business domain objects by means of interfaces and layering, so that I can change the tool if I have to with just a small amount of pain. A positive side effect of this approach is that I generally end up with a smaller application that uses fewer external tools than originally forecast. + +By [Giovanni Asproni](http://programmer.97things.oreilly.com/wiki/index.php/Giovanni_Asproni) \ No newline at end of file diff --git a/fr-IR/thing_11/README.md b/fr-IR/thing_11/README.md new file mode 100644 index 00000000..6cf4dd8f --- /dev/null +++ b/fr-IR/thing_11/README.md @@ -0,0 +1,40 @@ +# Code in the Language of the Domain + +Picture two codebases. In one you come across: + +``` +if (portfolioIdsByTraderId.get(trader.getId()) + .containsKey(portfolio.getId())) {...} +``` + +You scratch your head, wondering what this code might be for. It seems to be getting an ID from a trader object, using that to get a map out of a, well, map-of-maps apparently, and then seeing if another ID from a portfolio object exists in the inner map. You scratch your head some more. You look for the declaration of portfolioIdsByTraderId and discover this: + +``` +Map> portfolioIdsByTraderId; +``` + +Gradually you realise it might be something to do with whether a trader has access to a particular portfolio. And of course you will find the same lookup fragment — or more likely a similar-but-subtly-different code fragment — whenever something cares whether a trader has access to a particular portfolio. + +In the other codebase you come across this: + +``` +if (trader.canView(portfolio)) {...} +``` + +No head scratching. You don't need to know how a trader knows. Perhaps there is one of these maps-of-maps tucked away somewhere inside. But that's the trader's business, not yours. + +Now which of those codebases would you rather be working in? + +Once upon a time we only had very basic data structures: bits and bytes and characters (really just bytes but we would pretend they were letters and punctuation). Decimals were a bit tricky because our base 10 numbers don't work very well in binary, so we had several sizes of floating-point types. Then came arrays and strings (really just different arrays). Then we had stacks and queues and hashes and linked lists and skip lists and lots of other exciting data structures *that don't exist in the real world*. "Computer science" was about spending lots of effort mapping the real world into our restrictive data structures. The real gurus could even remember how they had done it. + +Then we got user-defined types! OK, this isn't news, but it does change the game somewhat. If your domain contains concepts like traders and portfolios, you can model them with types called, say, Trader and Portfolio. But, more importantly than this, you can model *relationships between them* using domain terms too. + +If you don't code using domain terms you are creating a tacit (read: secret) understanding that *this* int over here means the way to identify a trader, whereas *that* int over there means the way to identify a portfolio. (Best not to get them mixed up!) And if you represent a business concept ("Some traders are not allowed to view some portfolios — it's illegal") with an algorithmic snippet, say an existence relationship in a map of keys, you aren't doing the audit and compliance guys any favors. + +The next programmer along might not be in on the secret, so why not make it explicit? Using a key as a lookup to another key that performs an existence check is not terribly obvious. How is someone supposed to intuit that's where the business rules preventing conflict of interest are implemented? + +Making domain concepts explicit in your code means other programmers can gather the *intent* of the code much more easily than by trying to retrofit an algorithm into what they understand about a domain. It also means that when the domain model evolves — which it will as your understanding of the domain grows — you are in a good position to evolve the code. Coupled with good encapsulation, the chances are good that the rule will exist in only one place, and that you can change it without any of the dependent code being any the wiser. + +The programmer who comes along a few months later to work on the code will thank you. The programmer who comes along a few months later might be you. + +By [Dan North](http://programmer.97things.oreilly.com/wiki/index.php/Dan_North) \ No newline at end of file diff --git a/fr-IR/thing_12/README.md b/fr-IR/thing_12/README.md new file mode 100644 index 00000000..31439994 --- /dev/null +++ b/fr-IR/thing_12/README.md @@ -0,0 +1,17 @@ +# Code Is Design + +Imagine waking up tomorrow and learning the construction industry has made the breakthrough of the century. Millions of cheap, incredibly fast robots can fabricate materials out of thin air, have a near-zero power cost, and can repair themselves. And it gets better: Given an unambiguous blueprint for a construction project, the robots can build it without human intervention, all at negligible cost. + +One can imagine the impact on the construction industry, but what would happen upstream? How would the behavior of architects and designers change if construction costs were negligible? Today, physical and computer models are built and rigorously tested before investing in construction. Would we bother if the construction was essentially free? If a design collapses, no big deal — just find out what went wrong and have our magical robots build another one. There are further implications. With models obsolete, unfinished designs evolve by repeatedly building and improving upon an approximation of the end goal. A casual observer may have trouble distinguishing an unfinished design from a finished product. + +Our ability to predict time lines will fade away. Construction costs are more easily calculated than design costs — we know the approximate cost of installing a girder, and how many girders we need. As predictable tasks shrink toward zero, the less predictable design time starts to dominate. Results are produced more quickly, but reliable time lines slip away. + +Of course, the pressures of a competitive economy still apply. With construction costs eliminated, a company that can quickly complete a design gains an edge in the market. Getting design done fast becomes the central push of engineering firms. Inevitably, someone not deeply familiar with the design will see an unvalidated version, see the market advantage of releasing early, and say "This looks good enough." + +Some life-or-death projects will be more diligent, but in many cases consumers learn to suffer through the incomplete design. Companies can always send out our magic robots to 'patch' the broken buildings and vehicles they sell. All of this points to a startlingly counterintuitive conclusion: Our sole premise was a dramatic reduction in construction costs, with the result that *quality got worse*. + +It shouldn't surprise us the above story has played out in software. If we accept that code is design — a creative process rather than a mechanical one — the *software crisis* is explained. We now have a *design crisis*: The demand for quality, validated designs exceeds our capacity to create them. The pressure to use incomplete design is strong. + +Fortunately, this model also offers clues on how we can get better. Physical simulations equate to automated testing; software design isn't complete until it is validated with a brutal battery of tests. To make such tests more effective we are finding ways to rein in the huge state space of large systems. Improved languages and design practices give us hope. Finally, there is one inescapable fact: Great designs are produced by great designers dedicating themselves to the mastery of their craft. Code is no different. + +By [Ryan Brush](http://programmer.97things.oreilly.com/wiki/index.php/Ryan_Brush) \ No newline at end of file diff --git a/fr-IR/thing_13/README.md b/fr-IR/thing_13/README.md new file mode 100644 index 00000000..7f9d7ca1 --- /dev/null +++ b/fr-IR/thing_13/README.md @@ -0,0 +1,15 @@ +# Code Layout Matters + +An infeasible number of years ago I worked on a Cobol system where staff weren't allowed to change the indentation unless they already had a reason to change the code, because someone once broke something by letting a line slip into one of the special columns at the beginning of a line. This applied even if the layout was misleading, which it sometimes was, so we had to read the code very carefully because we couldn't trust it. The policy must have cost a fortune in programmer drag. + +There's research to show that we all spend much more of our programming time navigating and reading code — finding *where* to make the change — than actually typing, so that's what we want to optimize for. + +- *Easy to scan.* People are really good at visual pattern matching (a leftover from the time when we had to spot lions on the savannah), so I can help myself by making everything that isn't directly relevant to the domain, all the "accidental complexity" that comes with most commercial languages, fade into the background by standardizing it. If code that behaves the same looks the same, then my perceptual system will help me pick out the differences. That's why I also observe conventions about how to lay out the parts of a class within a compilation unit: constants, fields, public methods, private methods. + +- *Expressive layout.* We've all learned to take the time to find the right names so that our code expresses as clearly as possible what it does, rather than just listing the steps — right? The code's layout is part of this expressiveness too. A first cut is to have the team agree on an automatic formatter for the basics, then I might make adjustments by hand while I'm coding. Unless there's active dissension, a team will quickly converge on a common "hand-finished" style. A formatter cannot understand my intentions (I should know, I once wrote one), and it's more important to me that the line breaks and groupings reflect the intention of the code, not just the syntax of the language. (Kevin McGuire freed me from my bondage to automatic code formatters.) + +- *Compact format.* The more I can get on a screen, the more I can see without breaking context by scrolling or switching files, which means I can keep less state in my head. Long procedure comments and lots of whitespace made sense for 8-character names and line printers, but now I live in an IDE that does syntax coloring and cross linking. Pixels are my limiting factor so I want every one to contribute towards my understanding of the code. I want the layout to help me understand the code, but no more than that. + +A non-programmer friend once remarked that code looks like poetry. I get that feeling from really good code, that everything in the text has a purpose and that it's there to help me understand the idea. Unfortunately, writing code doesn't have the same romantic image as writing poetry. + +By [Steve Freeman](http://programmer.97things.oreilly.com/wiki/index.php/Steve_Freeman) diff --git a/fr-IR/thing_14/README.md b/fr-IR/thing_14/README.md new file mode 100644 index 00000000..e96190c3 --- /dev/null +++ b/fr-IR/thing_14/README.md @@ -0,0 +1,15 @@ +# Code Reviews + +You should do code reviews. Why? Because they *increase code quality* and *reduce defect rate*. But not necessarily for the reasons you might think. + +Because they may previously have had some bad experiences with reviews, many programmers tend to dislike code reviews. I have seen organizations that require that all code pass a formal review before being deployed to production. Often it is the architect or a lead developer doing this review, a practice that can be described as *architect reviews everything*. This is stated in their software development process manual, so therefore the programmers must comply. There may be some organizations that need such a rigid and formal process, but most do not. In most organizations such an approach is counterproductive. Reviewees can feel like they are being judged by a parole board. Reviewers need both the time to read the code and the time to keep up to date with all the details of the system. The reviewers can rapidly become the bottleneck in this process, and the process soon degenerates. + +Instead of simply correcting mistakes in code, the purpose of code reviews should be to *share knowledge* and establish common coding guidelines. Sharing your code with other programmers enables collective code ownership. Let a random team member *walk through the code* with the rest of the team. Instead of looking for errors you should review the code by trying to learn it and understand it. + +Be gentle during code reviews. Ensure that comments are *constructive, not caustic*. Introduce different *review roles* for the review meeting, to avoid having organizational seniority among team members affect the code review. Examples of roles could include having one reviewer focus on documentation, another on exceptions, and a third to look at the functionality. This approach helps to spread the review burden across the team members. + +Have a regular *code review* day each week. Spend a couple of hours in a review meeting. Rotate the reviewee every meeting in a simple round-robin pattern. Remember to switch roles among team members every review meeting too. *Involve newbies* in code reviews. They may be inexperienced, but their fresh university knowledge can provide a different perspective. *Involve experts* for their experience and knowledge. They will identify error-prone code faster and with more accuracy. Code reviews will flow more easily if the team has *coding conventions* that are checked by tools. That way, code formatting will never be discussed during the code review meeting. + +*Making code reviews fun* is perhaps the most important contributor to success. Reviews are about the people reviewing. If the review meeting is painful or dull it will be hard to motivate anyone. Make it an *informal code review* whose prime purpose is sharing knowledge between team members. Leave sarcastic comments outside and bring a cake or brown bag lunch instead. + +by [Mattias Karlsson](http://programmer.97things.oreilly.com/wiki/index.php/Mattias_Karlsson) \ No newline at end of file diff --git a/fr-IR/thing_15/README.md b/fr-IR/thing_15/README.md new file mode 100644 index 00000000..69af4e71 --- /dev/null +++ b/fr-IR/thing_15/README.md @@ -0,0 +1,25 @@ +# Coding with Reason + +Trying to reason about software correctness by hand results in a formal proof that is longer than the code and is more likely to contain errors than the code. Automated tools are preferable, but not always possible. What follows describes a middle path: reasoning semi-formally about correctness. + +The underlying approach is to divide all the code under consideration into short sections — from a single line, such as a function call, to blocks of less than ten lines — and arguing about their correctness. The arguments need only be strong enough to convince your devil's advocate peer programmer. + +A section should be chosen so that at each endpoint the *state of the program* (namely, the program counter and the values of all "living" objects) satisfies an easily described property, and that the functionality of that section (state transformation) is easy to describe as a single task — these will make reasoning simpler. Such endpoint properties generalize concepts like *precondition* and *postcondition* for functions, and *invariant* for loops and classes (with respect to their instances). Striving for sections to be as independent of one another as possible simplifies reasoning and is indispensable when these sections are to be modified. + +Many of the coding practices that are well known (although perhaps less well followed) and considered 'good' make reasoning easier. Hence, just by intending to reason about your code, you already start thinking toward a better style and structure. Unsurprisingly, most of these practices can be checked by static code analyzers: + +- Avoid using goto statements, as they make remote sections highly interdependent. +- Avoid using modifiable global variables, as they make all sections that use them dependent. +- Each variable should have the smallest possible scope. For example, a local object can be declared right before its first usage. +- Make objects *immutable* whenever relevant. +- Make the code readable by using spacing, both horizontal and vertical. For example, aligning related structures and using an empty line to separate two sections. +- Make the code self-documenting by choosing descriptive (but relatively short) names for objects, types, functions, etc. +- If you need a nested section, make it a function. +- Make your functions short and focused on a single task. The old *24-line limit* still applies. Although screen size and resolution have changed, nothing has changed in human cognition since the 1960s. +- Functions should have few parameters (four is a good upper bound). This does not restrict the data communicated to functions: Grouping related parameters into a single object benefits from *object invariants* and saves reasoning, such as their coherence and consistency. +- More generally, each unit of code, from a block to a library, should have a *narrow interface*. Less communication reduces the reasoning required. This means that *getters* that return internal state are a liability — don't ask an object for information to work with. Instead, ask the object to do the work with the information it already has. In other words, *encapsulation* is all — and only — about *narrow interfaces*. +- In order to preserve class *invariants*, usage of *setters* should be discouraged, as *setters* tend to allow invariants that govern an object's state to be broken. + +As well as reasoning about its correctness, arguing about your code gives you understanding of it. Communicate the insights you gain for everyone's benefit. + +By [Yechiel Kimchi](http://programmer.97things.oreilly.com/wiki/index.php/Yechiel_Kimchi) diff --git a/fr-IR/thing_16/README.md b/fr-IR/thing_16/README.md new file mode 100644 index 00000000..be7c2e36 --- /dev/null +++ b/fr-IR/thing_16/README.md @@ -0,0 +1,15 @@ +# A Comment on Comments + +In my first programming class in college, my teacher handed out two BASIC coding sheets. On the board, the assignment read "Write a program to input and average 10 bowling scores." Then the teacher left the room. How hard could this be? I don't remember my final solution but I'm sure it had a `FOR/NEXT` loop in it and couldn't have been more than 15 lines long in total. Coding sheets — for you kids reading this, yes, we used to write code out longhand before actually entering it into a computer — allowed for around 70 lines of code each. I was very confused as to why the teacher would have given us two sheets. Since my handwriting has always been atrocious, I used the second one to recopy my code very neatly, hoping to get a couple extra points for style. + +Much to my surprise, when I received the assignment back at the start of the next class, I received a barely passing grade. (It was to be an omen to me for the rest of my time in college.) Scrawled across the top of my neatly copied code, "No comments?" + +It was not enough that the teacher and I both knew what the program was supposed to do. Part of the point of the assignment was to teach me that my code should explain itself to the next programmer coming behind me. It's a lesson I've not forgotten. + +Comments are not evil. They are as necessary to programming as basic branching or looping constructs. Most modern languages have a tool akin to javadoc that will parse properly formatted comments to automatically build an API document. This is a very good start, but not nearly enough. Inside your code should be explanations about what the code is supposed to be doing. Coding by the old adage, "If it was hard to write, it should be hard to read," does a disservice to your client, your employer, your colleagues, and your future self. + +On the other hand, you can go too far in your commenting. Make sure that your comments clarify your code but do not obscure it. Sprinkle your code with relevant comments explaining what the code is supposed to accomplish. Your header comments should give any programmer enough information to use your code without having to read it, while your in-line comments should assist the next developer in fixing or extending it. + +At one job, I disagreed with a design decision made by those above me. Feeling rather snarky, as young programmers often do, I pasted the text of the email instructing me to use their design into the header comment block of the file. It turns out that managers at this particular shop actually reviewed the code when it was committed. It was my first introduction to the term *career-limiting move*. + +by [Cal Evans](http://programmer.97things.oreilly.com/wiki/index.php/Cal_Evans) \ No newline at end of file diff --git a/fr-IR/thing_17/README.md b/fr-IR/thing_17/README.md new file mode 100644 index 00000000..eb887df6 --- /dev/null +++ b/fr-IR/thing_17/README.md @@ -0,0 +1,13 @@ +# Comment Only What the Code Cannot Say + +The difference between theory and practice is greater in practice than it is in theory — an observation that certainly applies to comments. In theory, the general idea of commenting code sounds like a worthy one: Offer the reader detail, an explanation of what's going on. What could be more helpful than being helpful? In practice, however, comments often become a blight. As with any other form of writing, there is a skill to writing good comments. Much of the skill is in knowing when not to write them. + +When code is ill-formed, compilers, interpreters, and other tools will be sure to object. If the code is in some way functionally incorrect, reviews, static analysis, tests, and day-to-day use in a production environment will flush most bugs out. But what about comments? In The *Elements of Programming Style* Kernighan and Plauger noted that "a comment is of zero (or negative) value if it is wrong." And yet such comments often litter and survive in a code base in a way that coding errors never could. They provide a constant source of distraction and misinformation, a subtle but constant drag on a programmer's thinking. + +What of comments that are not technically wrong, but add no value to the code? Such comments are noise. Comments that parrot the code offer nothing extra to the reader — stating something once in code and again in natural language does not make it any truer or more real. Commented-out code is not executable code, so it has no useful effect for either reader or runtime. It also becomes stale very quickly. Version-related comments and commented-out code try to address questions of versioning and history. These questions have already been answered (far more effectively) by version control tools. + +A prevalence of noisy comments and incorrect comments in a code base encourage programmers to ignore all comments, either by skipping past them or by taking active measures to hide them. Programmers are resourceful and will route around anything perceived to be damage: folding comments up; switching coloring scheme so that comments and the background are the same color; scripting to filter out comments. To save a code base from such misapplications of programmer ingenuity, and to reduce the risk of overlooking any comments of genuine value, comments should be treated as if they were code. Each comment should add some value for the reader, otherwise it is waste that should be removed or rewritten. + +What then qualifies as value? Comments should say something code does not and cannot say. A comment explaining what a piece of code should already say is an invitation to change code structure or coding conventions so the code speaks for itself. Instead of compensating for poor method or class names, rename them. Instead of commenting sections in long functions, extract smaller functions whose names capture the former sections' intent. Try to express as much as possible through code. Any shortfall between what you can express in code and what you would like to express in total becomes a plausible candidate for a useful comment. Comment what the code cannot say, not simply what it does not say. + +By [Kevlin Henney](http://programmer.97things.oreilly.com/wiki/index.php/Kevlin_Henney) \ No newline at end of file diff --git a/fr-IR/thing_18/README.md b/fr-IR/thing_18/README.md new file mode 100644 index 00000000..335da53b --- /dev/null +++ b/fr-IR/thing_18/README.md @@ -0,0 +1,28 @@ +# Continuous Learning + +We live in interesting times. As development gets distributed across the globe, you learn there are lots of people capable of doing your job. You need to keep learning to stay marketable. Otherwise, you'll become a dinosaur, stuck in the same job until, one day, you'll no longer be needed or your job gets outsourced to some cheaper resource. + +So what do you do about it? Some employers are generous enough to provide training to broaden your skill set. Others may not be able to spare the time or money for any training at all. To play it safe, you need to take responsibility for your own education. + +Here's a list of ways to keep you learning. Many of these can be found on the Internet for free: + +- Read books, magazines, blogs, twitter feeds, and web sites. If you want to go deeper into a subject, consider joining a mailing list or newsgroup. +- If you really want to get immersed in a technology, get hands on — write some code. +- Always try to work with a mentor, as being the top guy can hinder your education. Although you can learn something from anybody, you can learn a whole lot more from someone smarter or more experienced than you. If you can't find a mentor, consider moving on. +- Use virtual mentors. Find authors and developers on the web who you really like and read everything they write. Subscribe to their blogs. +- Get to know the frameworks and libraries you use. Knowing how something works makes you know how to use it better. If they're open source, you're really in luck. Use the debugger to step through the code to see what's going on under the hood. You'll get to see code written and reviewed by some really smart people. +- Whenever you make a mistake, fix a bug, or run into a problem, try to really understand what happened. It's likely that somebody else ran into the same problem and posted it somewhere on the web. Google is really useful here. +- A really good way to learn something is to teach or speak about it. When people are going to listen to you and ask you questions, you'll be highly motivated to learn. Try a lunch-n-learn at work, a user group, or a local conference. +- Join or start a study group (à la patterns community) or a local user group for a language, technology, or discipline you are interested in. +- Go to conferences. And if you can't go, many conferences put their talks online for free. +- Long commute? Listen to podcasts. +- Ever run a static analysis tool over the code base or look at the warnings in your IDE? Understand what they're reporting and why. +- Follow the advice of [The Pragmatic Programmers](http://www.pragprog.com/titles/tpp/the-pragmatic-programmer) and learn a new language every year. At least learn a new technology or tool. Branching out gives you new ideas you can use in your current technology stack. +- Not everything you learn has to be about technology. Learn the domain you're working in so you can better understand the requirements and help solve the business problem. Learning how to be more productive — how to work better — is another good option. +- Go back to school. + +It would be nice to have the capability that Neo had in The Matrix, and simply download the information we needed into our brains. But we don't, so it will take a time commitment. You don't have to spend every waking hour learning. A little time, say each week, is better than nothing. There is (or should be) a life outside of work. + +Technology changes fast. Don't get left behind. + +by [Clint Shank](http://programmer.97things.oreilly.com/wiki/index.php/Clint_Shank) \ No newline at end of file diff --git a/fr-IR/thing_19/README.md b/fr-IR/thing_19/README.md new file mode 100644 index 00000000..00c42feb --- /dev/null +++ b/fr-IR/thing_19/README.md @@ -0,0 +1,21 @@ +# Convenience Is not an -ility + +Much has been said about the importance and challenges of designing good API's. It's difficult to get right the first time and it's even more difficult to change later. Sort of like raising children. Most experienced programmers have learned that a good API follows a consistent level of abstraction, exhibits consistency and symmetry, and forms the vocabulary for an expressive language. Alas, being aware of the guiding principles does not automatically translate into appropriate behavior. Eating sweets is bad for you. + +Instead of preaching from on high, I want to pick on a particular API design 'strategy,' one that I encounter time and again: the argument of convenience. It typically begins with one of the following 'insights:' + +- I don't want other classes to have to make two separate calls to do this one thing. +- Why should I make another method if it's almost the same as this method? I'll just add a simple switch. +- See, it's very easy: If the second string parameter ends with ".txt", the method automatically assumes that the first parameter is a file name, so I really don't need two methods. + +While well intended, such arguments are prone to decrease the readability of code using the API. A method invocation like + +``` +parser.processNodes(text, false); +``` + +is virtually meaningless without knowing the implementation or at least consulting the documentation. This method was likely designed for the convenience of the implementer as opposed to the convenience of the caller — "I don't want the caller to have to make two separate calls" translated into "I didn't want to code up two separate methods." There's nothing fundamentally wrong with convenience if it's intended to be the antidote to tediousness, clunkiness, or awkwardness. However, if we think a bit more carefully about it, the antidote to those symptoms is efficiency, consistency, and elegance, not necessarily convenience. APIs are supposed to hide underlying complexity, so we can realistically expect good API design to require some effort. A single large method could certainly be more convenient to write than a well thought-out set of operations, but would it be easier to use? + +The metaphor of API as a language can guide us towards better design decisions in these situations. An API should provide an expressive language, which gives the next layer above sufficient vocabulary to ask and answer useful questions. This does not imply it should provide exactly one method, or verb, for each question that may be worth asking. A diverse vocabulary allows us to express subtleties in meaning. For example, we prefer to say run instead of walk(true), even though it could be viewed as essentially the same operation, just executed at different speeds. A consistent and well thought out API vocabulary makes for expressive and easy to understand code in the next layer up. More importantly, a composable vocabulary allows other programmers to use the API in ways you may not have anticipated — a great convenience indeed for the users of the API! Next time you are tempted to lump a few things together into one API method, remember that the English language does not have one word for `MakeUpYourRoomBeQuietAndDoYourHomeWork`, even though it would seem really convenient for such a frequently requested operation. + +By [Gregor Hohpe](http://programmer.97things.oreilly.com/wiki/index.php/Gregor_Hohpe) \ No newline at end of file diff --git a/fr-IR/thing_20/README.md b/fr-IR/thing_20/README.md new file mode 100644 index 00000000..e9596868 --- /dev/null +++ b/fr-IR/thing_20/README.md @@ -0,0 +1,15 @@ +# Deploy Early and Often + +Debugging the deployment and installation processes is often put off until close to the end of a project. In some projects writing installation tools is delegated to a release engineer who take on the task as a "necessary evil." Reviews and demonstrations are done from a hand-crafted environment to ensure that everything works. The result is that the team gets no experience with the deployment process or the deployed environment until it may be too late to make changes. + +The installation/deployment process is the first thing that the customer sees, and a simple installation/deployment process is the first step to having a reliable (or, at least, easy to debug) production environment. The deployed software is what the customer will use. By not ensuring that the deployment sets up the application correctly, you'll raise questions with your customer before they get to use your software thoroughly. + +Starting your project with an installation process will give you time to evolve the process as you move through the product development cycle, and the chance to make changes to the application code to make the installation easier. Running and testing the installation process on a clean environment periodically also provides a check that you have not made assumptions in the code that rely on the development or test environments. + +Putting deployment last means that the deployment process may need to be more complicated to work around assumptions in the code. What seemed a great idea in an IDE, where you have full control over an environment, might make for a much more complicated deployment process. It is better to know all the trade-offs sooner rather than later. + +While "being able to deploy" doesn't seem to have a lot of business value early on as compared to seeing an application run on a developer's laptop, the simple truth is that until you can demonstrate your application on the target environment, there is a lot of work to do before you can deliver business value. If your rationale for putting off a deployment process is that it is trivial, then do it anyway since it is low cost. If it's too complicated, or if there are too many uncertainties, do what you would do with application code: experiment, evaluate, and refactor the deployment process as you go. + +The installation/deployment process is essential to the productivity of your customers or your professional services team, so you should be testing and refactoring this process as you go. We test and refactor the source code throughout a project. The deployment deserves no less. + +By [Steve Berczuk](http://programmer.97things.oreilly.com/wiki/index.php/Steve_Berczuk) diff --git a/fr-IR/thing_21/README.md b/fr-IR/thing_21/README.md new file mode 100644 index 00000000..591e1136 --- /dev/null +++ b/fr-IR/thing_21/README.md @@ -0,0 +1,17 @@ +# Distinguish Business Exceptions from Technical + +There are basically two reasons that things go wrong at runtime: technical problems that prevent us from using the application and business logic that prevents us from misusing the application. Most modern languages, such as LISP, Java, Smalltalk, and C#, use exceptions to signal both these situations. However, the two situations are so different that they should be carefully held apart. It is a potential source of confusion to represent them both using the same exception hierarchy, not to mention the same exception class. + +An unresolvable technical problem can occur when there is a programming error. For example, if you try to access element 83 from an array of size 17, then the program is clearly off track, and some exception should result. The subtler version is calling some library code with inappropriate arguments, causing the same situation on the inside of the library. + +It would be a mistake to attempt to resolve these situations you caused yourself. Instead we let the exception bubble up to the highest architectural level and let some general exception-handling mechanism do what it can to ensure the system is in a safe state, such as rolling back a transaction, logging and alerting administration, and reporting back (politely) to the user. + +A variant of this situation is when you are in the "library situation" and a caller has broken the contract of your method, e.g., passing a totally bizarre argument or not having a dependent object set up properly. This is on a par with accessing 83rd element from 17: the caller should have checked; not doing so is a programmer error on the client side. The proper response is to throw a technical exception. + +A different, but still technical, situation is when the program cannot proceed because of a problem in the execution environment, such as an unresponsive database. In this situation you must assume that the infrastructure did what it could to resolve the situation — repairing connections and retrying a reasonable number of times — and failed. Even if the cause is different, the situation for the calling code is similar: there is little it can do about it. So, we signal the situation through an exception that we let bubble up to the general exception handling mechanism. + +In contrast to these, we have the situation where you cannot complete the call for a domain-logical reason. In this case we have encountered a situation that is an exception, i.e., unusual and undesirable, but not bizarre or programmatically in error. For example, if I try to withdraw money from an account with insufficient funds. In other words, this kind of situation is a part of the contract, and throwing an exception is just an *alternative return path* that is part of the model and that the client should be aware of and be prepared to handle. For these situations it is appropriate to create a specific exception or a separate exception hierarchy so that the client can handle the situation on its own terms. + +Mixing technical exceptions and business exceptions in the same hierarchy blurs the distinction and confuses the caller about what the method contract is, what conditions it is required to ensure before calling, and what situations it is supposed to handle. Separating the cases gives clarity and increases the chances that technical exceptions will be handled by some application framework, while the business domain exceptions actually are considered and handled by the client code. + +By [Dan Bergh Johnsson](http://programmer.97things.oreilly.com/wiki/index.php/Dan_Bergh_Johnsson) \ No newline at end of file diff --git a/fr-IR/thing_22/README.md b/fr-IR/thing_22/README.md new file mode 100644 index 00000000..866ce294 --- /dev/null +++ b/fr-IR/thing_22/README.md @@ -0,0 +1,25 @@ +# Do Lots of Deliberate Practice + +Deliberate practice is not simply performing a task. If you ask yourself "Why am I performing this task?" and your answer is "To complete the task," then you're not doing deliberate practice. + +You do deliberate practice to improve your ability to perform a task. It's about skill and technique. Deliberate practice means repetition. It means performing the task with the aim of increasing your mastery of one or more aspects of the task. It means repeating the repetition. Slowly, over and over again. Until you achieve your desired level of mastery. You do deliberate practice to master the task not to complete the task. + +The principal aim of paid development is to finish a product whereas the principal aim of deliberate practice is to improve your performance. They are not the same. Ask yourself, how much of your time do you spend developing someone else's product? How much developing yourself? + +How much deliberate practice does it take to acquire expertise? + +- Peter Norvig [writes](http://norvig.com/21-days.html) that "It may be that 10,000 hours [...] is the magic number." +- In *Leading Lean Software Development* Mary Poppendieck notes that "It takes elite performers a minimum of 10,000 hours of deliberate focused practice to become experts." + +The expertise arrives gradually over time — not all at once in the 10,000th hour! Nevertheless, 10,000 hours is a lot: about 20 hours per week for 10 years. Given this level of commitment you might be worrying that you're just not expert material. You are. Greatness is largely a matter of conscious choice. *Your choice.* Research over the last two decades has shown the main factor in acquiring expertise is time spent doing deliberate practice. Innate ability is *not* the main factor. + +- Mary: "There is broad consensus among researchers of expert performance that inborn talent does not account for much more than a threshold; you have to have a minimum amount of natural ability to get started in a sport or profession. After that, the people who excel are the ones who work the hardest." + +There is little point deliberately practicing something you are already an expert at. Deliberate practice means practicing something you are not good at. + +- Peter: "The key [to developing expertise] is *deliberative* practice: not just doing it again and again, but challenging yourself with a task that is just beyond your current ability, trying it, analyzing your performance while and after doing it, and correcting any mistakes." +- Mary: "Deliberate practice does not mean doing what you are good at; it means challenging yourself, doing what you are not good at. So it's not necessarily fun." + +Deliberate practice is about learning. About learning that changes you; learning that changes your behavior. Good luck. + +By [Jon Jagger](http://programmer.97things.oreilly.com/wiki/index.php/Jon_Jagger) \ No newline at end of file diff --git a/fr-IR/thing_23/README.md b/fr-IR/thing_23/README.md new file mode 100644 index 00000000..66ad8e0e --- /dev/null +++ b/fr-IR/thing_23/README.md @@ -0,0 +1,15 @@ +# Domain-Specific Languages + +Whenever you listen to a discussion by experts in any domain, be it chess players, kindergarten teachers, or insurance agents, you'll notice that their vocabulary is quite different from everyday language. That's part of what domain-specific languages (DSLs) are about: A specific domain has a specialized vocabulary to describe the things that are particular to that domain. + +In the world of software, DSLs are about executable expressions in a language specific to a domain with limited vocabulary and grammar that is readable, understandable, and — hopefully — writable by domain experts. DSLs targeted at software developers or scientists have been around for a long time. For example, the Unix 'little languages' found in configuration files and the languages created with the power of LISP macros are some of the older examples. + +DSLs are commonly classified as either *internal* or *external*: + +- **Internal DSLs** are written in a general purpose programming language whose syntax has been bent to look much more like natural language. This is easier for languages that offer more syntactic sugar and formatting possibilities (e.g., Ruby and Scala) than it is for others that do not (e.g., Java). Most internal DSLs wrap existing APIs, libraries, or business code and provide a wrapper for less mind-bending access to the functionality. They are directly executable by just running them. Depending on the implementation and the domain, they are used to build data structures, define dependencies, run processes or tasks, communicate with other systems, or validate user input. The syntax of an internal DSL is constrained by the host language. There are many patterns — e.g., expression builder, method chaining, and annotation — that can help you to bend the host language to your DSL. If the host language doesn't require recompilation, an internal DSL can be developed quite quickly working side by side with a domain expert. + +- **External DSLs** are textual or graphical expressions of the language — although textual DSLs tend to be more common than graphical ones. Textual expressions can be processed by a tool chain that includes lexer, parser, model transformer, generators, and any other type of post-processing. External DSLs are mostly read into internal models which form the basis for further processing. It is helpful to define a grammar (e.g., in EBNF). A grammar provides the starting point for generating parts of the tool chain (e.g., editor, visualizer, parser generator). For simple DSLs, a handmade parser may be sufficient — using, for instance, regular expressions. Custom parsers can become unwieldy if too much is asked of them, so it makes sense to look at tools designed specifically for working with language grammars and DSLs — e.g., openArchitectureWare, ANTlr, SableCC, AndroMDA. Defining external DSLs as XML dialects is also quite common, although readability is often an issue — especially for non-technical readers. + +You must always take the target audience of your DSL into account. Are they developers, managers, business customers, or end users? You have to adapt the technical level of the language, the available tools, syntax help (e.g., intellisense), early validation, visualization, and representation to the intended audience. By hiding technical details, DSLs can empower users by giving them the ability to adapt systems to their needs without requiring the help of developers. It can also speed up development because of the potential distribution of work after the initial language framework is in place. The language can be evolved gradually. There are also different migration paths for existing expressions and grammars available. + +By [Michael Hunger](http://programmer.97things.oreilly.com/wiki/index.php/Michael_Hunger) \ No newline at end of file diff --git a/fr-IR/thing_24/README.md b/fr-IR/thing_24/README.md new file mode 100644 index 00000000..8649ba8a --- /dev/null +++ b/fr-IR/thing_24/README.md @@ -0,0 +1,13 @@ +# Don't Be Afraid to Break Things + +Everyone with industry experience has undoubtedly worked on a project where the codebase was precarious at best. The system is poorly factored, and changing one thing always manages to break another unrelated feature. Whenever a module is added, the coder's goal is to change as little as possible, and hold their breath during every release. This is the software equivalent of playing Jenga with I-beams in a skyscraper, and is bound for disaster. + +The reason that making changes is so nerve wracking is because the system is sick. It needs a doctor, otherwise its condition will only worsen. You already know what is wrong with your system, but you are afraid of breaking the eggs to make your omelet. A skilled surgeon knows that cuts have to be made in order to operate, but the skilled surgeon also knows that the cuts are temporary and will heal. The end result of the operation is worth the initial pain, and the patient should heal to a better state than they were in before the surgery. + +Don't be afraid of your code. Who cares if something gets temporarily broken while you move things around? A paralyzing fear of change is what got your project into this state to begin with. Investing the time to refactor will pay for itself several times over the life cycle of your project. An added benefit is that your team's experience dealing with the sick system makes you all experts in knowing how it *should* work. Apply this knowledge rather than resent it. Working on a system you hate is not how anybody should have to spend their time. + +Redefine internal interfaces, restructure modules, refactor copy–pasted code, and simplify your design by reducing dependencies. You can significantly reduce code complexity by eliminating corner cases, which often result from improperly coupled features. Slowly transition the old structure into the new one, testing along the way. Trying to accomplish a large refactor in "one big shebang" will cause enough problems to make you consider abandoning the whole effort midway through. + +Be the surgeon who isn't afraid to cut out the sick parts to make room for healing. The attitude is contagious and will inspire others to start working on those cleanup projects they've been putting off. Keep a "hygiene" list of tasks that the team feels are worthwhile for the general good of the project. Convince management that even though these tasks may not produce visible results, they will reduce expenses and expedite future releases. Never stop caring about the general "health" of the code. + +By [Mike Lewis](http://programmer.97things.oreilly.com/wiki/index.php/Mike_Lewis) \ No newline at end of file diff --git a/fr-IR/thing_25/README.md b/fr-IR/thing_25/README.md new file mode 100644 index 00000000..66cbd942 --- /dev/null +++ b/fr-IR/thing_25/README.md @@ -0,0 +1,26 @@ +# Don't Be Cute with Your Test Data + +> *It was getting late. I was throwing in some placeholder data to test the page layout I'd been working on.* + +> *I appropriated the members of The Clash for the names of users. Company names? Song titles by the Sex Pistols would do. Now I needed some stock ticker symbols — just some four letter words in capital letters.* + +> *I used **those** four letter words.* + +> *It seemed harmless. Just something to amuse myself, and maybe the other developers the next day before I wired up the real data source.* + +> *The following morning, a project manager took some screenshots for a presentation.** + +Programming history is littered with these kinds of war stories. Things that developers and designers did "that no one else would see" which unexpectedly became visible. +The leak type can vary but, when it happens, it can be deadly to the person, team, or company responsible. Examples include: + +- During a status meeting, a client clicks on an button which is as yet unimplemented. They are told: "Don't click that again, you moron." +- A programmer maintaining a legacy system has been told to add an error dialog, and decides to use the output of existing behind-the-scenes logging to power it. Users are suddenly faced with messages such as "Holy database commit failure, Batman!" when something breaks. +- Someone mixes up the test and live administration interfaces, and does some "funny" data entry. Customers spot a $1m "Bill Gates-shaped personal massager" on sale in your online store. + +To appropriate the old saying that "a lie can travel halfway around the world while the truth is putting on its shoes," in this day and age a screw-up can be Dugg, Twittered, and Flibflarbed before anyone in the developer's timezone is awake to do anything about it. + +Even your source code isn't necessarily free of scrutiny. In 2004, when a tarball of the Windows 2000 source code made its way onto file sharing networks, some folks merrily grepped through it for profanity, insults, and [other funny content](http://www.kuro5hin.org/story/2004/2/15/71552/7795). (The comment `// TERRIBLE HORRIBLE NO GOOD VERY BAD HACK` has, I will admit, become appropriated by me from time to time since!) + +In summary, when writing any text in your code — whether comments, logging, dialogs, or test data — always ask yourself how it will look if it becomes public. It will save some red faces all round. + +By [Rod Begbie](http://programmer.97things.oreilly.com/wiki/index.php/Rod_Begbie) \ No newline at end of file diff --git a/fr-IR/thing_26/README.md b/fr-IR/thing_26/README.md new file mode 100644 index 00000000..0cecf78d --- /dev/null +++ b/fr-IR/thing_26/README.md @@ -0,0 +1,47 @@ +# Don't Ignore that Error! + +> *I was walking down the street one evening to meet some friends in a bar. We hadn't shared a beer in some time and I was looking forward to seeing them again. In my haste, I wasn't looking where I was going. I tripped over the edge of a curb and ended up flat on my face. Well, it serves me right for not paying attention, I guess.* + +> *It hurt my leg, but I was in a hurry to meet my friends. So I pulled myself up and carried on. As I walked further the pain was getting worse. Although I'd initially dismissed it as shock, I rapidly realized there was something wrong.* + +> *But I hurried on to the bar regardless. I was in agony by the time I arrived. I didn't have a great night out, because I was terribly distracted. In the morning I went to the doctor and found out I'd fractured my shin bone. Had I stopped when I felt the pain, I'd've prevented a lot of extra damage that I caused by walking on it. Probably the worst morning after of my life.* + +Too many programmers write code like my disastrous night out. + +*Error, what error? It won't be serious. Honestly. I can ignore it.* This is not a winning strategy for solid code. In fact, it's just plain laziness. (The wrong sort.) No matter how unlikely you think an error is in your code, you should always check for it, and always handle it. Every time. You're not saving time if you don't: You're storing up potential problems for the future. + +We report errors in our code in a number of ways, including: + +- **Return codes** can be used as the resulting value of a function to mean "it didn't work." Error return codes are far too easy to ignore. You won't see anything in the code to highlight the problem. Indeed, it's become standard practice to ignore some standard C functions' return values. How often do you check the return value from printf? + +- **errno** is a curious C aberration, a separate global variable set to signal error. It's easy to ignore, hard to use, and leads to all sorts of nasty problems — for example, what happens when you have multiple threads calling the same function? Some platforms insulate you from pain here; others do not. + +- **Exceptions** are a more structured language-supported way of signaling and handling errors. And you can't possibly ignore them. Or can you? I've seen lots of code like this: + +``` +try { + // ...do something... +} +catch (...) {} // ignore errors +``` + +The saving grace of this awful construct is that it highlights the fact you're doing something morally dubious. + +If you ignore an error, turn a blind eye, and pretend that nothing has gone wrong, you run great risks. Just as my leg ended up in a worse state than if I'd stopped walking on it immediately, plowing on regardless can lead to very complex failures. Deal with problems at the earliest opportunity. Keep a short account. + +Not handling errors leads to: + +- **Brittle code.** Code that's filled with exciting, hard-to-find bugs. +- **Insecure code.** Crackers often exploit poor error handling to break into software systems. +- **Poor structure.** If there are errors from your code that are tedious to deal with continually, you probably have a poor interface. Express it so that the errors are less intrusive and the their handling is less onerous. + +Just as you should check all potential errors in your code, you need to expose all potentially erroneous conditions in your interfaces. Do not hide them, pretending that your services will always work. + +Why don't we check for errors? There are a number of common excuses. Which of these do you agree with? How would you counter each one? + +- Error handling clutters up the flow of the code, making it harder to read, and harder to spot the "normal" flow of execution. +- It's extra work and I have a deadline looming. +- I know that this function call will *never* return an error (printf always works, malloc always returns new memory — if it fails we have bigger problems...). +- It's only a toy program, and needn't be written to a production-worthy level. + +By [Pete Goodliffe](http://programmer.97things.oreilly.com/wiki/index.php/Pete_Goodliffe) diff --git a/fr-IR/thing_27/README.md b/fr-IR/thing_27/README.md new file mode 100644 index 00000000..0ddeef10 --- /dev/null +++ b/fr-IR/thing_27/README.md @@ -0,0 +1,13 @@ +# Don't Just Learn the Language, Understand its Culture + +In high school, I had to learn a foreign language. At the time I thought that I'd get by nicely being good at English so I chose to sleep through three years of French class. A few years later I went to Tunisia on vacation. Arabic is the official language there and, being a former French colony, French is also commonly used. English is only spoken in the touristy areas. Because of my linguistic ignorance, I found myself confined at the poolside reading *Finnegans Wake*, James Joyce's tour de force in form and language. Joyce's playful blend of more than forty languages was a surprising albeit exhausting experience. Realizing how interwoven foreign words and phrases gave the author new ways of expressing himself is something I've kept with me in my programming career. + +In their seminal book, *The Pragmatic Programmer*, Andy Hunt and Dave Thomas encourage us to learn a new programming language every year. I've tried to live by their advice and throughout the years I've had the experience of programming in many languages. My most important lesson from my polyglot adventures is that it takes more than just learning the syntax to learn a language: You need to understand its culture. You can write Fortran in any language, but to truly learn a language you have to embrace the language. Don't make excuses if your C# code is a long Main method with mostly static helper methods, but learn why classes make sense. Don't shy away if you have a hard time understanding the lambda expressions used in functional languages, force yourself to use them. + +Once you've learned the ropes of a new language, you'll be surprised how you'll start using languages you already know in new ways. I learned how to use delegates effectively in C# from programming Ruby, releasing the full potential of .NETs generics gave me ideas on how I could make Java generics more useful, and LINQ made it a breeze to teach myself Scala. + +You'll also get a better understanding of design patterns by moving between different languages. C programmers find that C# and Java have commoditized the iterator pattern. In Ruby and other dynamic languages you might still use a visitor, but your implementation won't look like the example from the Gang of Four book. + +Some might argue that *Finnegans Wake* is unreadable, while others applaud it for its stylistic beauty. To make the book a less daunting read, single language translations are available. Ironically, the first of these was in French. Code is in many ways similar. If you write *Wakese* code with a little Python, some Java, and a hint of Erlang, your projects will be a mess. If you instead explore new languages to expand your mind and get fresh ideas on how you can solve things in different ways, you will find that the code you write in your trusty old language gets more beautiful for every new language you've learned. + +By Anders Norås \ No newline at end of file diff --git a/fr-IR/thing_28/README.md b/fr-IR/thing_28/README.md new file mode 100644 index 00000000..190805f9 --- /dev/null +++ b/fr-IR/thing_28/README.md @@ -0,0 +1,20 @@ +# Don't Nail Your Program into the Upright Position + +I once wrote a spoof C++ quiz, in which I satirically suggested the following strategy for exception handling: + +> By dint of plentiful `try...catch` constructs throughout our code base, we are sometimes able to prevent our applications from aborting. We think of the resultant state as "nailing the corpse in the upright position." + +Despite my levity, I was actually summarizing a lesson I received at the knee of Dame Bitter Experience herself. + +It was a base application class in our own, homemade C++ library. It had suffered the pokings of many programmers' fingers over the years: Nobody's hands were clean. It contained code to deal with all escaped exceptions from everything else. Taking our lead from Yossarian in Catch-22, we decided, or rather felt (*decided* implies more thought than went into the construction of this monster) that an instance of this class should live forever or die in the attempt. + +To this end, we intertwined multiple exception handlers. We mixed in Windows' structured exception handling with the native kind (remember `__try...__except` in C++? Me neither). When things threw unexpectedly, we tried calling them again, pressing the parameters harder. Looking back, I like to think that when writing an inner `try...catch` handler within the catch clause of another, some sort of awareness crept over me that I might have accidentally taken a slip road from the motorway of good practice into the aromatic but insalubrious lane of lunacy. However, this is probably retrospective wisdom. + +Needless to say, whenever something went wrong in applications based on this class, they vanished like Mafia victims at the dockside, leaving behind no useful trail of bubbles to indicate what the hell happened, notwithstanding the dump routines that were supposedly called to record the disaster. Eventually — a long eventually — we took stock of what we had done, and experienced shame. We replaced the whole mess with a minimal and robust reporting mechanism. But this was many crashes down the line. + +I wouldn't bother you with this — for surely nobody else could ever be as stupid as we were — but for an online argument I had recently with a bloke whose academic job title declared he should know better. We were discussing Java code in a remote transaction. If the code failed, he argued, it should catch and block the exception *in situ*. ("And then do *what* with it?" I asked. "Cook it for supper?") + +He quoted the UI designers' rule: NEVER LET THE USER SEE AN EXCEPTION REPORT, rather as though this settled the matter, what with it being in caps and everything. I wonder if he was responsible for the code in one of those blue-screened ATMs whose photos decorate the feebler blogs, and had been permanently traumatized. +Anyway, if you should meet him, nod and smile and take no notice, as you sidle towards the door. + +By [Verity Stob](http://programmer.97things.oreilly.com/wiki/index.php/Verity_Stob) \ No newline at end of file diff --git a/fr-IR/thing_29/README.md b/fr-IR/thing_29/README.md new file mode 100644 index 00000000..7db46819 --- /dev/null +++ b/fr-IR/thing_29/README.md @@ -0,0 +1,21 @@ +# Don't Rely on "Magic Happens Here" + +If you look at any activity, process, or discipline from far enough away it looks simple. Managers with no experience of development think what programmers do is simple and programmers with no experience of management think the same of what managers do. + +Programming is something some people do — some of the time. And the hard part — the thinking — is the least visible and least appreciated by the uninitiated. There have been many attempts to remove the need for this skilled thinking over the decades. One of the earliest and most memorable is the effort by Grace Hopper to make programming languages less cryptic — which some accounts predicted would remove the need for specialist programmers. The result (COBOL) has contributed to the income of many specialist programmers over subsequent decades. + +The persistent vision that software development can be simplified by removing programming is, to the programmer who understands what is involved, obviously naïve. But the mental process that leads to this mistake is part of human nature and programmers are just as prone to making it as everyone else. + +On any project there are likely many things that an individual programmer doesn't get actively involved in: eliciting requirements from users, getting budgets approved, setting up the build server, deploying the application to QA and production environments, migrating the business from the old processes or programs, etc. + +When you aren't actively involved in things there is an unconscious tendency to assume that they are simple and happen "by magic." While the magic continues to happen all is well. But when — it is usually "when" and not "if" — the magic stops the project is in trouble. + +I've known projects lose weeks of developer time because no one understood how they relied on "the right" version of a DLL being loaded. When things started failing intermittently team members looked everywhere else before someone noticed that "a wrong" version of the DLL was being loaded. + +Another department was running smoothly — projects delivered on time, no late night debugging sessions, no emergency fixes. So smoothly, in fact, that senior management decided that things "ran themselves" and they could do without the project manager. Inside six months the projects in the department looked just like the rest of the organization — late, buggy and continually being patched. + +You don't have to understand all the magic that makes your project work, but it doesn't hurt to understand some of it — or to appreciate someone who understands the bits you don't. + +Most importantly, make sure that when the magic stops it can be started again. + +By [AlanGriffiths](http://programmer.97things.oreilly.com/wiki/index.php/AlanGriffiths) \ No newline at end of file diff --git a/fr-IR/thing_30/README.md b/fr-IR/thing_30/README.md new file mode 100644 index 00000000..45f99d2f --- /dev/null +++ b/fr-IR/thing_30/README.md @@ -0,0 +1,27 @@ +# Don't Repeat Yourself + +Of all the principles of programming, Don't Repeat Yourself (DRY) is perhaps one of the most fundamental. The principle was formulated by Andy Hunt and Dave Thomas in *The Pragmatic Programmer*, and underlies many other well-known software development best practices and design patterns. The developer who learns to recognize duplication, and understands how to eliminate it through appropriate practice and proper abstraction, can produce much cleaner code than one who continuously infects the application with unnecessary repetition. + +Duplication is waste +--- + +Every line of code that goes into an application must be maintained, and is a potential source of future bugs. Duplication needlessly bloats the codebase, resulting in more opportunities for bugs and adding accidental complexity to the system. The bloat that duplication adds to the system also makes it more difficult for developers working with the system to fully understand the entire system, or to be certain that changes made in one location do not also need to be made in other places that duplicate the logic they are working on. DRY requires that "every piece of knowledge must have a single, unambiguous, authoritative representation within a system." + +Repetition in process calls for automation +--- + +Many processes in software development are repetitive and easily automated. The DRY principle applies in these contexts as well as in the source code of the application. Manual testing is slow, error-prone, and difficult to repeat, so automated test suites should be used, if possible. Integrating software can be time consuming and error-prone if done manually, so a build process should be run as frequently as possible, ideally with every check-in. Wherever painful manual processes exist that can be automated, they should be automated and standardized. The goal is to ensure there is only one way of accomplishing the task, and it is as painless as possible. + +Repetition in logic calls for abstraction +--- + +Repetition in logic can take many forms. Copy-and-paste *if-then* or *switch-case* logic is among the easiest to detect and correct. Many design patterns have the explicit goal of reducing or eliminating duplication in logic within an application. If an object typically requires several things to happen before it can be used, this can be accomplished with an Abstract Factory or a Factory Method. If an object has many possible variations in its behavior, these behaviors can be injected using the Strategy pattern rather than large *if-then* structures. In fact, the formulation of design patterns themselves is an attempt to reduce the duplication of effort required to solve common problems and discuss such solutions. In addition, DRY can be applied to structures, such as database schema, resulting in normalization. + +A Matter of principle +--- + +Other software principles are also related to DRY. The Once and Only Once principle, which applies only to the functional behavior of code, can be thought of as a subset of DRY. The Open/Closed Principle, which states that "software entities should be open for extension, but closed for modification," only works in practice when DRY is followed. Likewise, the well-known Single Responsibility Principle requires that a class have "only one reason to change," relies on DRY. + +When followed with regard to structure, logic, process, and function, the DRY principle provides fundamental guidance to software developers and aids the creation of simpler, more maintainable, higher-quality applications. While there are scenarios where repetition can be necessary to meet performance or other requirements (e.g., data denormalization in a database), it should be used only where it directly addresses an actual rather than an imagined problem. + +By [Steve Smith](http://programmer.97things.oreilly.com/wiki/index.php/Steve_Smith) \ No newline at end of file diff --git a/fr-IR/thing_31/README.md b/fr-IR/thing_31/README.md new file mode 100644 index 00000000..22ed6e5c --- /dev/null +++ b/fr-IR/thing_31/README.md @@ -0,0 +1,23 @@ +# Don't Touch that Code! + +It has happened to everyone of us at some point. Your code was rolled on to the staging server for system testing and the testing manager writes back that she has hit a problem. Your first reaction is "Quick, let me fix that — I know what's wrong." + +In the bigger sense, though, what is wrong is that as a developer you think you should have access to the staging server. + +In most web-based development environments the architecture can be broken down like this: + +- Local development and unit testing on the developer's machine +- Development server where manual or automated integration testing is done +- Staging server where the QA team and the users do acceptance testing +- Production server + +Yes, there are other servers and services sprinkled in there, like source code control and ticketing, but you get the idea. Using this model, a developer — even a senior developer — should never have access beyond the development server. Most development is done on a developer's local machine using their favorite blend of IDEs, virtual machines, and an appropriate amount of black magic sprinkled over it for good luck. + +Once checked into SCC, whether automatically or manually, it should be rolled over to the development server where it can be tested and tweaked if necessary to make sure everything works together. From this point on, though, the developer is a spectator to the process. + +The staging manager should package and roll the code to the staging server for the QA team. Just like developers should have no need to access anything beyond the development server, the QA team and the users have no need to touch anything on the development server. If it's ready for acceptance testing, cut a release and roll, don't ask the user to "Just look at something real quick" on the development server. Remember, unless you are coding the project by yourself, other people have code there and they may not be ready for the user to see it. The release manager is the only person who should have access to both. + +Under no circumstances — ever, at all — should a developer have access to a production server. If there is a problem, your support staff should either fix it or request that you fix it. After it's +checked into SCC they will roll a patch from there. Some of the biggest programming disasters I've been a part of have taken place because someone \**cough*\*me\**cough\** violated this last rule. If it's broke, production is not the place to fix it. + +by [Cal Evans](http://programmer.97things.oreilly.com/wiki/index.php/Cal_Evans) \ No newline at end of file diff --git a/fr-IR/thing_32/README.md b/fr-IR/thing_32/README.md new file mode 100644 index 00000000..867a9891 --- /dev/null +++ b/fr-IR/thing_32/README.md @@ -0,0 +1,15 @@ +# Encapsulate Behavior, not Just State + +In systems theory, containment is one of the most useful constructs when dealing with large and complex system structures. In the software industry the value of containment or encapsulation is well understood. Containment is supported by programming language constructs such as subroutines and functions, modules and packages, classes, and so on. + +Modules and packages address the larger scale needs for encapsulation, while classes, subroutines, and functions address the more fine-grained aspects of the matter. Over the years I have discovered that classes seem to be one of the hardest encapsulation constructs for developers to get right. It's not uncommon to find a class with a single 3000-line main method, or a class with only *set* and *get* methods for its primitive attributes. These examples demonstrate that the developers involved have not fully understood object-oriented thinking, having failed to take advantage of the power of objects as modeling constructs. For developers familiar with the terms POJO (Plain Old Java Object) and POCO (Plain Old C# Object or Plain Old CLR Object), this was the intent in going back to the basics of OO as a modeling paradigm — the objects are plain and simple, but not dumb. + +An object encapsulates both state and behavior, where the behavior is defined by the actual state. Consider a door object. It has four states: closed, open, closing, opening. It provides two operations: open and close. Depending on the state, the open and close operations will behave differently. This inherent property of an object makes the design process conceptually simple. It boils down to two simple tasks: allocation and delegation of responsibility to the different objects including the inter-object interaction protocols. + +How this works in practice is best illustrated with an example. Let's say we have three classes: Customer, Order, and Item. A Customer object is the natural placeholder for the credit limit and credit validation rules. An Order object knows about its associated Customer, and its addItem operation delegates the actual credit check by calling `customer.validateCredit(item.price())`. If the postcondition for the method fails, an exception can be thrown and the purchase aborted. + +Less experienced object oriented developers might decide to wrap all the business rules into an object very often referred to as `OrderManager` or `OrderService`. In these designs, `Order`, `Customer`, and `Item` are treated as little more than record types. All logic is factored out of the classes and tied together in one large, procedural method with a lot of internal *if-then-else* constructs. These methods are easily broken and are almost impossible to maintain. The reason? The encapsulation is broken. + +So in the end, don't break the encapsulation, and use the power of your programming language to maintain it. + +By [Einar Landre](http://programmer.97things.oreilly.com/wiki/index.php/Einar_Landre) \ No newline at end of file diff --git a/fr-IR/thing_33/README.md b/fr-IR/thing_33/README.md new file mode 100644 index 00000000..0df4f299 --- /dev/null +++ b/fr-IR/thing_33/README.md @@ -0,0 +1,17 @@ +# Floating-point Numbers Aren't Real + +Floating-point numbers are not "real numbers" in the mathematical sense, even though they are called *real* in some programming languages, such as Pascal and Fortran. Real numbers have infinite precision and are therefore continuous and non-lossy; floating-point numbers have limited precision, so they are finite, and they resemble "badly-behaved" integers, because they're not evenly spaced throughout their range. + +To illustrate, assign 2147483647 (the largest signed 32-bit integer) to a 32-bit float variable (x, say), and print it. You'll see 2147483648. Now print `x - 64`. Still 2147483648. Now print `x - 65` and you'll get 2147483520! Why? Because the spacing between adjacent floats in that range is 128, and floating-point operations round to the nearest floating-point number. + +IEEE floating-point numbers are fixed-precision numbers based on base-two scientific notation: 1.d1d2...dp-1 × 2e, where *p* is the precision (24 for float, 53 for double). The spacing between two consecutive numbers is 21-p+e, which can be safely approximated by ε|x|, where ε is the *machine epsilon* (21-p). + +Knowing the spacing in the neighborhood of a floating-point number can help you avoid classic numerical blunders. For example, if you're performing an iterative calculation, such as searching for the root of an equation, there's no sense in asking for greater precision than the number system can give in the neighborhood of the answer. Make sure that the tolerance you request is no smaller than the spacing there; otherwise you'll loop forever. + +Since floating-point numbers are approximations of real numbers, there is inevitably a little error present. This error, called *roundoff*, can lead to surprising results. When you subtract nearly equal numbers, for example, the most significant digits cancel each other out, so what was the least significant digit (where the roundoff error resides) gets promoted to the most significant position in the floating-point result, essentially contaminating any further related computations (a phenomenon known as *smearing*). You need to look closely at your algorithms to prevent such *catastrophic cancellation*. To illustrate, consider solving the equation *x2 - 100000x + 1 = 0* with the quadratic formula. Since the operands in the expression *-b + sqrt(b2 - 4)* are nearly equal in magnitude, you can instead compute the root *r1 = -b + sqrt(b2 - 4)*, and then obtain *r2 = 1/r1*, since for any quadratic equation, ax2 + bx + c = 0, the roots satisfy *r1r2 = c/a*. + +Smearing can occur in even more subtle ways. Suppose a library naively computes *ex* by the formula *1 + x + x2/2 + x3/3! + ...*. This works fine for positive *x*, but consider what happens when *x* is a large negative number. The even-powered terms result in large positive numbers, and subtracting the odd-powered magnitudes will not even affect the result. The problem here is that the roundoff in the large, positive terms is in a digit position of much greater significance than the true answer. The answer diverges toward positive infinity! The solution here is also simple: for negative *x*, compute *ex = 1/e|x|*. + +It should go without saying that you shouldn't use floating-point numbers for financial applications — that's what decimal classes in languages like Python and C# are for. Floating-point numbers are intended for efficient scientific computation. But efficiency is worthless without accuracy, so remember the source of rounding errors and code accordingly! + +By [Chuck Allison](http://programmer.97things.oreilly.com/wiki/index.php/Chuck_Allison) \ No newline at end of file diff --git a/fr-IR/thing_34/README.md b/fr-IR/thing_34/README.md new file mode 100644 index 00000000..c5ebfea0 --- /dev/null +++ b/fr-IR/thing_34/README.md @@ -0,0 +1,13 @@ +# Fulfill Your Ambitions with Open Source + +Chances are pretty good that you are not developing software at work that fulfills your most ambitious software development daydreams. Perhaps you are developing software for a huge insurance company when you would rather be working at Google, Apple, Microsoft, or your own start-up developing the next big thing. You'll never get where you want to go developing software for systems you don't care about. + +Fortunately, there is an answer to your problem: open source. There are thousands of open source projects out there, many of them quite active, which offer you any kind of software development experience you could want. If you love the idea of developing operating systems, go help with one of the dozen operating system projects. If you want to work on music software, animation software, cryptography, robotics, PC games, massive online player games, mobile phones, or whatever, you'll almost certainly find at least one open source project dedicated to that interest. + +Of course there is no free lunch. You have to be willing to give up your free time because you probably cannot work on an open source video game at your day job — you still have a responsibility to your employer. In addition, very few people make money contributing to open source projects — some do but most don't. You should be willing to give up some of your free time (less time playing video games and watching TV won't kill you). The harder you work on an open source project the faster you'll realize your true ambitions as a programmer. It's also important to consider your employee contract — some employers may restrict what you can contribute, even on your own time. In addition, you need to be careful about violating intellectual property laws having to do with copyright, patents, trade marks, and trade secrets. + +Open source provides enormous opportunities for the motivated programmer. First, you get to see how someone else would implement a solution that interests you — you can learn a lot by reading other people's source code. Second, you get to contribute your own code and ideas to the project — not every brilliant idea you have will be accepted but some might and you'll learn something new just by working on solutions and contributing code. Third, you'll meet great people with the same passion for the type of software that you have — these open source friendships can last a lifetime. Fourth, assuming you are a competent contributor, you'll be able to add real-world experience in the technology that actually interests you. + +Getting started with open source is pretty easy. There is a wealth of documentation out there on the tools you'll need (e.g., source code management, editors, programming languages, build systems, etc.). Find the project you want to work on first and learn about the tools that project uses. The documentation on projects themselves will be light in most cases, but this perhaps matters less because the best way to learn is to investigate the code yourself. If you want to get involved, you could offer to help out with the documentation. Or you could start by volunteering to write test code. While that may not sound exciting, the truth is you learn much faster by writing test code for other people's software than almost any other activity in software. Write test code, really good test code. Find bugs, suggest fixes, make friends, work on software you like, and fulfill your software development ambitions. + +by [Richard Monson-Haefel](http://programmer.97things.oreilly.com/wiki/index.php/Richard_Monson-Haefel) \ No newline at end of file diff --git a/fr-IR/thing_35/README.md b/fr-IR/thing_35/README.md new file mode 100644 index 00000000..5dc245b0 --- /dev/null +++ b/fr-IR/thing_35/README.md @@ -0,0 +1,13 @@ +# The Golden Rule of API Design + +API design is tough, particularly in the large. If you are designing an API that is going to have hundreds or thousands of users, you have to think about how you might change it in the future and whether your changes might break client code. Beyond that, you have to think about how users of your API affect you. If one of your API classes uses one of its own methods internally, you have to remember that a user could subclass your class and override it, and that could be disastrous. You wouldn't be able to change that method because some of your users have given it a different meaning. Your future internal implementation choices are at the mercy of your users. + +API developers solve this problem in various ways, but the easiest way is to lock down the API. If you are working in Java you might be tempted to make most of your classes and methods final. In C#, you might make your classes and methods sealed. Regardless of the language you are using, you might be tempted to present your API through a singleton or use static factory methods so that you can guard it from people who might override behavior and use your code in ways which may constrain your choices later. This all seems reasonable, but is it really? + +Over the past decade, we've gradually realized that unit testing is an extremely important part of practice, but that lesson has not completely permeated the industry. The evidence is all around us. Take an arbitrary untested class that uses a third-party API and try to write unit tests for it. Most of the time, you'll run into trouble. You'll find that the code using the API is stuck to it like glue. There's no way to impersonate the API classes so that you can sense your code's interactions with them, or supply return values for testing. + +Over time, this will get better, but only if we start to see testing as a real use case when we design APIs. Unfortunately, it's a little bit more involved than just testing our code. That's where the **Golden Rule of API Design** fits in: *It's not enough to write tests for an API you develop; you have to write unit tests for code that uses your API. When you do, you learn first-hand the hurdles that your users will have to overcome when they try to test their code independently.* + +There is no one way to make it easy for developers to test code which uses your API. `static`, `final`, and `sealed` are not inherently bad constructs. They can be useful at times. But it is important to be aware of the testing issue and, to do that, you have to experience it yourself. Once you have, you can approach it as you would any other design challenge. + +By [Michael Feathers](http://programmer.97things.oreilly.com/wiki/index.php/Michael_Feathers) \ No newline at end of file diff --git a/fr-IR/thing_36/README.md b/fr-IR/thing_36/README.md new file mode 100644 index 00000000..dfc8b65e --- /dev/null +++ b/fr-IR/thing_36/README.md @@ -0,0 +1,17 @@ +# The Guru Myth + +Anyone who has worked in software long enough has heard questions like this: + +> *I'm getting exception XYZ. Do you know what the problem is?* + +Those asking the question rarely bother to include stack traces, error logs, or any context leading to the problem. They seem to think you operate on a different plane, that solutions appear to you without analysis based on evidence. They think you are a guru. + +We expect such questions from those unfamiliar with software: To them systems can seem almost magical. What worries me is seeing this in the software community. Similar questions arise in program design, such as "I'm building inventory management. Should I use optimistic locking?" Ironically, people asking the question are often better equipped to answer it than the question's recipient. The questioners presumably know the context, know the requirements, and can read about the advantages and disadvantages of different strategies. Yet they expect you to give an intelligent answer without context. They expect magic. + +It's time for the software industry to dispel this guru myth. "Gurus" are human. They apply logic and systematically analyze problems like the rest of us. They tap into mental shortcuts and intuition. Consider the best programmer you've ever met: At one point that person knew less about software than you do now. If someone seems like a guru, it's because of years dedicated to learning and refining thought processes. A "guru" is simply a smart person with relentless curiosity. + +Of course, there remains a huge variance in natural aptitude. Many hackers out there are smarter, more knowledgeable, and more productive than I may ever be. Even so, debunking the guru myth has a positive impact. For instance, when working with someone smarter than me I am sure to do the legwork, to provide enough context so that person can efficiently apply his or her skills. Removing the guru myth also means removing a perceived barrier to improvement. Instead of a magical barrier, I see a continuum on which I can advance. + +Finally, one of software's biggest obstacles is smart people who purposefully propagate the guru myth. This might be done out of ego, or as a strategy to increase one's value as perceived by a client or employer. Ironically, this attitude can make smart people less valuable, since they don't contribute to the growth of their peers. We don't need gurus. We need experts willing to develop other experts in their field. There is room for all of us. + +By [Ryan Brush](http://programmer.97things.oreilly.com/wiki/index.php/Ryan_Brush) \ No newline at end of file diff --git a/fr-IR/thing_37/README.md b/fr-IR/thing_37/README.md new file mode 100644 index 00000000..807c85a5 --- /dev/null +++ b/fr-IR/thing_37/README.md @@ -0,0 +1,13 @@ +# Hard Work Does not Pay Off + +As a programmer, working hard often does not pay off. You might fool yourself and a few colleagues into believing that you are contributing a lot to a project by spending long hours at the office. But the truth is that by working less you might achieve more — sometimes much more. If you are trying to be focused and 'productive' for more than 30 hours a week you are probably working too hard. You should consider reducing the workload to become more effective and get more done. + +This statement may seem counterintuitive and even controversial, but it is a direct consequence of the fact that programming and software development as a whole involve a continuous learning process. As you work on a project you will understand more of the problem domain and, hopefully, find more effective ways of reaching the goal. To avoid wasted work, you must allow time to observe the effects of what you are doing, reflect over the things that you see, and change your behavior accordingly. + +Professional programming is usually not like running hard for a few kilometers, where the goal can be seen at the end of a paved road. Most software projects are more like a long orienteering marathon. In the dark. With only a sketchy map as guidance. If you just set off in one direction, running as fast as you can, you might impress some, but you are not likely to succeed. You need to keep a sustainable pace and you need to adjust the course when you learn more about where you are and where you are heading. + +In addition, you always need to learn more about software development in general and programming techniques in particular. You probably need to read books, go to conferences, communicate with other professionals, experiment with new implementation techniques, and learn about powerful tools that simplify your job. As a professional programmer you must keep yourself updated in your field of expertise — just as brain surgeons and pilots are expected to keep themselves up to date in their own fields of expertise. You need to spend evenings, weekends, and holidays educating yourself, therefore you cannot spend your evenings, weekends, and holidays working overtime on your current project. Do you really expect brain surgeons to perform surgery 60 hours a week, or pilots to fly 60 hours a week? Of course not, preparation and education is an essential part of their profession. + +Be focused on the project, contribute as much as you can by finding smart solutions, improve your skills, reflect on what you are doing, and adapt your behavior. Avoid embarrassing yourself, and our profession, by behaving like a hamster in a cage spinning the wheel. As a professional programmer you should know that trying to be focused and 'productive' 60 hours a week is not a sensible thing to do. Act like a professional: prepare, effect, observe, reflect, and change. + +By [Olve Maudal](http://programmer.97things.oreilly.com/wiki/index.php/Olve_Maudal) \ No newline at end of file diff --git a/fr-IR/thing_38/README.md b/fr-IR/thing_38/README.md new file mode 100644 index 00000000..9fc14259 --- /dev/null +++ b/fr-IR/thing_38/README.md @@ -0,0 +1,23 @@ +# How to Use a Bug Tracker + +Whether you call them *bugs*, *defects*, or even *design side effects*, there is no getting away from them. Knowing how to submit a good bug report and also what to look for in one are key skills for keeping a project moving along nicely. + +A good bug report needs three things: + +- How to reproduce the bug, as precisely as possible, and how often this will make the bug appear. +- What should have happened, at least in your opinion. +- What actually happened, or at least as much information as you have recorded. + +The amount and quality of information reported in a bug says as much about the reporter as it does about the bug. Angry, terse bugs ("This function sucks!") tell the developers that you were having a bad time, but not much else. A bug with plenty of context to make it easier to reproduce earns the respect of everyone, even if it stops a release. + +Bugs are like a conversation, with all the history right there in front of everyone. Don't blame others or deny the bug's very existence. Instead ask for more information or consider what you could have missed. + +Changing the status of a bug, e.g., *Open* to *Closed*, is a public statement of what you think of the bug. Taking the time to explain why you think the bug should be closed will save tedious hours later on justifying it to frustrated managers and customers. Changing the priority of a bug is a similar public statement, and just because it's trivial to you doesn't mean it isn't stopping someone else from using the product. + +Don't overload a bug's fields for your own purposes. Adding "VITAL:" to a bug's subject field may make it easier for you to sort the results of some report, but it will eventually be copied by others and inevitably mistyped, or will need to be removed for use in some other report. Use a new value or a new field instead, and document how the field is supposed to be used so other people don't have to repeat themselves. + +Make sure that everyone knows how to find the bugs that the team is supposed to be working on. This can usually be done using a public query with an obvious name. Make sure everyone is using the same query, and don't update this query without first informing the team that you're changing what everyone is working on. + +Finally, remember that a bug is not a standard unit of work any more than a line of code is a precise measurement of effort. + +By [Matt Doar](http://programmer.97things.oreilly.com/wiki/index.php/Matt_Doar) \ No newline at end of file diff --git a/fr-IR/thing_39/README.md b/fr-IR/thing_39/README.md new file mode 100644 index 00000000..49052b81 --- /dev/null +++ b/fr-IR/thing_39/README.md @@ -0,0 +1,24 @@ +# Improve Code by Removing It + +*Less* is more. It's a quite trite little maxim, but sometimes it really is true. + +One of the improvements I've made to our codebase over the last few weeks is to remove chunks of it. + +We'd written the software following XP tenets, including YAGNI (that is, You Aren't Gonna Need It). Human nature being what it is, we inevitably fell short in a few places. + +I observed that the product was taking too long to execute certain tasks — simple tasks that should have been near instantaneous. This was because they were overimplemented; festooned with extra bells and whistles that were not required, but at the time had seemed like a good idea. + +So I've simplified the code, improved the product performance, and reduced the level of global code entropy simply by removing the offending features from the codebase. Helpfully, my unit tests tell me that I haven't broken anything else during the operation. + +A simple and thoroughly satisfying experience. + +So why did the unnecessary code end up there in the first place? Why did one programmer feel the need to write extra code, and how did it get past review or the pairing process? Almost certainly something like: + +- It was a fun bit of extra stuff, and the programmer wanted to write it. *(Hint: Write code because it adds value, not because it amuses you.)* +- Someone thought that it might be needed in the future, so felt it was best to code it now. *(Hint: That isn't YAGNI. If you don't need it right now, don't write it right now.)* +- It didn't appear to be that big an "extra," so it was easier to implement it rather than go back to the customer to see whether it was really required. *(Hint: It always takes longer to write and to maintain extra code. And the customer is actually quite approachable. A small extra bit of code snowballs over time into a large piece of work that needs maintenance.)* +- The programmer invented extra requirements that were neither documented nor discussed that justified the extra feature. The requirement was actually bogus. *(Hint: Programmers do not set system requirements; the customer does.)* + +What are you working on right now? Is it all needed? + +By [Pete Goodliffe](http://programmer.97things.oreilly.com/wiki/index.php/Pete_Goodliffe) diff --git a/fr-IR/thing_40/README.md b/fr-IR/thing_40/README.md new file mode 100644 index 00000000..a2ebdc01 --- /dev/null +++ b/fr-IR/thing_40/README.md @@ -0,0 +1,24 @@ +# Install Me + +I am not the slightest bit interested in your program. + +I am surrounded by problems and have a to-do list as long as my arm. The only reason I am at your website right now is because I have heard an unlikely rumor that every one my problems will be eliminated by your software. You'll forgive me if I'm skeptical. + +If eyeball tracking studies are correct, I've already read the title and I'm scanning for blue underlined text marked *download now*. As an aside, if I arrived at this page with a Linux browser from a UK IP, chances are I would like the Linux version from a European mirror, so please don't ask. Assuming the file dialog opens straight away, I consign the thing to my download folder and carry on reading. + +We all constantly perform cost-benefit analysis of everything we do. If your project drops below my threshold for even a second, I will ditch it and go onto something else. Instant gratification is best. + +The first hurdle is *install*. Don't think that's much of a problem? Go to your download folder now and have a look around. Full of *tar* and *zip* files right? What percentage of those have you unpacked? How many have you installed? If you are like me, only a third are doing little more than acting as hard drive filler. + +I may want doorstep convenience, but I don't want you entering my house uninvited. Before typing install I would like to know exactly where you are putting stuff. It's my computer and I like to keep it tidy when I can. I also want to be able to remove your program the instant I am disenchanted with it. If I suspect that's impossible I won't install it in the first place. My machine is stable right now and I want to keep it that way. + +If your program is GUI based then I want to do something simple and see a result. Wizards don't help, because they do stuff that I don't understand. Chances are I want to read a file, or write one. I don't want to create projects, import directories, or tell you my email address. If all is working, on to the tutorial. + +If your software is a library, then I carry on reading your web page looking for a *quick start guide*. I want the equivalent of "Hello world" in a five-line no-brainer with exactly the output described by your website. No big XML files or templates to fill out, just a single script. Remember, I have also downloaded your rival's framework. You know, the one who always claims to be so much better than yours in the forums? If all is working, onto the tutorial. + +There is a tutorial isn't there? One that talks to me in language I can understand? + +And if the tutorial mentions my problem, I'll cheer up. Now I'm reading about the things I can do it starts to get interesting, fun even. I'll lean back and sip my tea — did I mention I was from the UK? — and I'll play with your examples and learn to use your creation. If it solves my problem, I'll send you a thank-you email. I'll send you bug reports when it crashes, and suggestions for features too. I'll even tell all my friends how your software is the best, even though I never did try your rival's. And all because you took such care over my first tentative steps. +How could I ever have doubted you? + +By [Marcus Baker](http://programmer.97things.oreilly.com/wiki/index.php/Marcus_Baker) \ No newline at end of file diff --git a/fr-IR/thing_41/README.md b/fr-IR/thing_41/README.md new file mode 100644 index 00000000..66879100 --- /dev/null +++ b/fr-IR/thing_41/README.md @@ -0,0 +1,13 @@ +# Inter-Process Communication Affects Application Response Time + +Response time is critical to software usability. Few things are as frustrating as waiting for some software system to respond, especially when our interaction with the software involves repeated cycles of stimulus and response. We feel as if the software is wasting our time and affecting our productivity. However, the causes of poor response time are less well appreciated, especially in modern applications. Much performance management literature still focuses on data structures and algorithms, issues that can make a difference in some cases but are far less likely to dominate performance in modern multi-tier enterprise applications. + +When performance is a problem in such applications, my experience has been that examining data structures and algorithms isn't the right place to look for improvements. Response time depends most strongly on the number of remote inter-process communications (IPCs) conducted in response to a stimulus. While there can be other local bottlenecks, the number of remote inter-process communications usually dominates. Each remote inter-process communication contributes some non-negligible latency to the overall response time, and these individual contributions add up, especially when they are incurred in sequence. + +A prime example is *ripple loading* in an application using object–relational mapping. Ripple loading describes the sequential execution of many database calls to select the data needed for building a graph of objects (see [Lazy Load](http://martinfowler.com/eaaCatalog/lazyLoad.html) in Martin Fowler's *Patterns of Enterprise Application Architecture*). When the database client is a middle-tier application server rendering a web page, these database calls are usually executed sequentially in a single thread. Their individual latencies accumulate, contributing to the overall response time. Even if each database call takes only 10ms, a page requiring 1000 calls (which is not uncommon) will exhibit at least a 10-second response time. Other examples include web-service invocation, HTTP requests from a web browser, distributed object invocation, request–reply messaging, and data-grid interaction over custom network protocols. The more remote IPCs needed to respond to a stimulus, the greater the response time will be. + +There are a few relatively obvious and well-known strategies for reducing the number of remote inter-process communications per stimulus. One strategy is to apply the principle of parsimony, optimizing the interface between processes so that exactly the right data for the purpose at hand is exchanged with the minimum amount of interaction. Another strategy is to parallelize the inter-process communications where possible, so that the overall response time becomes driven mainly by the longest-latency IPC. A third strategy is to cache the results of previous IPCs, so that future IPCs may be avoided by hitting local cache instead. + +When you're designing an application, be mindful of the number of inter-process communications in response to each stimulus. When analyzing applications that suffer from poor performance, I have often found IPC-to-stimulus ratios of thousands-to-one. Reducing this ratio, whether by caching or parallelizing or some other technique, will pay off much more than changing data structure choice or tweaking a sorting algorithm. + +By [Randy Stafford](http://programmer.97things.oreilly.com/wiki/index.php/Randy_Stafford) \ No newline at end of file diff --git a/fr-IR/thing_42/README.md b/fr-IR/thing_42/README.md new file mode 100644 index 00000000..7e535b4d --- /dev/null +++ b/fr-IR/thing_42/README.md @@ -0,0 +1,15 @@ +# Keep the Build Clean + +Have you ever looked at a list of compiler warnings the length of an essay on bad coding and thought to yourself: "You know, I really should do something about that... but I don't have time just now?" On the other hand, have you ever looked at a lone warning that just appeared in a compilation and just fixed it? + +When I start a new project from scratch, there are no warnings, no clutter, no problems. But as the code base grows, if I don't pay attention, the clutter, the cruft, the warnings, and the problems can start piling up. When there's a lot of noise, it's much harder to find the warning that I really want to read among the hundreds of warnings I don't care about. + +To make warnings useful again, I try to use a zero-tolerance policy for warnings from the build. Even if the warning isn't important, I deal with it. If not critical, but still relevant, I fix it. If the compiler warns about a potential null-pointer exception, I fix the cause — even if I "know" the problem will never show up in production. If the embedded documentation (Javadoc or similar) refers to parameters that have been removed or renamed, I clean up the documentation. + +If it's something I really don't care about and that really doesn't matter, I ask the team if we can change our warning policy. For example, I find that documenting the parameters and return value of a method in many cases doesn't add any value, so it shouldn't be a warning if they are missing. Or, upgrading to a new version of the programming language may make code that was previously OK now emit warnings. For example, when Java 5 introduced generics, all the old code that didn't specify the generic type parameter would give a warning. This is a sort of warning I don't want to be nagged about (at least, not yet). Having a set of warnings that are out of step with reality does not serve anyone. + +By making sure that the build is always clean, I will not have to decide that a warning is irrelevant every time I encounter it. Ignoring things is mental work, and I need to get rid of all the unnecessary mental work I can. Having a clean build also makes it easier for someone else to take over my work. If I leave the warnings, someone else will have to wade through what is relevant and what is not. Or more likely, just ignore all the warnings, including the significant ones. + +Warnings from your build are useful. You just need to get rid of the noise to start noticing them. Don't wait for a big clean-up. When something appears that you don't want to see, deal with it right away. Either fix the source of the warning, suppress this warning or fix the warning policies of your tool. Keeping the build clean is not just about keeping it free of compilation errors or test failures: Warnings are also an important and critical part of code hygiene. + +By [Johannes Brodwall](http://programmer.97things.oreilly.com/wiki/index.php/Johannes_Brodwall) \ No newline at end of file diff --git a/fr-IR/thing_43/README.md b/fr-IR/thing_43/README.md new file mode 100644 index 00000000..8abd0245 --- /dev/null +++ b/fr-IR/thing_43/README.md @@ -0,0 +1,13 @@ +# Know How to Use Command-line Tools + +Today, many software development tools are packaged in the form of Integrated Development Environments (IDEs). Microsoft's Visual Studio and the open-source Eclipse are two popular examples, though there are many others. There is a lot to like about IDEs. Not only are they easy to use, they also relieve the programmer of thinking about a lot of little details involving the build process. + +Ease of use, however, has its downside. Typically, when a tool is easy to use, it's because the tool is making decisions for you and doing a lot of things automatically, behind the scenes. Thus, if an IDE is the only programming environment that you ever use, you may never fully understand what your tools are actually doing. You click a button, some magic occurs, and an executable file appears in the project folder. + +By working with command-line build tools, you will learn a lot more about what the tools are doing when your project is being built. Writing your own make files will help you to understand all of the steps (compiling, assembling, linking, etc.) that go into building an executable file. Experimenting with the many command-line options for these tools is a valuable educational experience as well. To get started with using command-line build tools, you can use open-source command-line tools such as GCC or you can use the ones supplied with your proprietary IDE. After all, a well-designed IDE is just a graphical front-end to a set of command-line tools. + +In addition to improving your understanding of the build process, there are some tasks that can be performed more easily or more efficiently with command-line tools than with an IDE. For example, the search and replace capabilities provided by the *grep* and *sed* utilities are often more powerful than those found in IDEs. Command-line tools inherently support scripting, which allows for the automation of tasks such as producing scheduled daily builds, creating multiple versions of a project, and running test suites. In an IDE, this kind of automation may be more difficult (if not impossible) to do as build options are usually specified using GUI dialog boxes and the build process is invoked with a mouse click. If you never step outside of the IDE, you may not even realize that these kinds of automated tasks are possible. + +But wait. Doesn't the IDE exist to make development easier, and to improve the programmer's productivity? Well, yes. The suggestion presented here is not that you should stop using IDEs. The suggestion is that you should "look under the hood" and understand what your IDE is doing for you. The best way to do that is to learn to use command-line tools. Then, when you go back to using your IDE, you'll have a much better understanding of what it is doing for you and how you can control the build process. On the other hand, once you master the use of command-line tools and experience the power and flexibility that they offer, you may find that you prefer the command line over the IDE. + +By [Carroll Robinson](http://programmer.97things.oreilly.com/wiki/index.php/Carroll_Robinson) \ No newline at end of file diff --git a/fr-IR/thing_44/README.md b/fr-IR/thing_44/README.md new file mode 100644 index 00000000..81556bef --- /dev/null +++ b/fr-IR/thing_44/README.md @@ -0,0 +1,19 @@ +# Know Well More than Two Programming Languages + +The psychology of programming people have known for a long time now that programming expertise is related directly to the number of different programming paradigms that a programmer is comfortable with. That is not just know about, or know a bit, but genuinely can program with. + +Every programmer starts with one programming language. That language has a dominating effect on the way that programmer thinks about software. No matter how many years of experience the programmer gets using that language, if they stay with that language, they will only know that language. A *one language* programmer is constrained in their thinking by that language. + +A programmer who learns a second language will be challenged, especially if that language has a different computational model than the first. C, Pascal, Fortran, all have the same fundamental computational model. Switching from Fortran to C introduces a few, but not many, challenges. Moving from C or Fortran to C++ or Ada introduces fundamental challenges in the way programs behave. Moving from C++ to Haskell is a significant change and hence a significant challenge. Moving from C to Prolog is a very definite challenge. + +We can enumerate a number of paradigms of computation: procedural, object-oriented, functional, logic, dataflow, etc. Moving between these paradigms creates the greatest challenges. + +Why are these challenges good? It is to do with the way we think about the implementation of algorithms and the idioms and patterns of implementation that apply. In particular, cross-fertilization is at the core of expertise. Idioms for problem solutions that apply in one language may not be possible in another language. Trying to port the idioms from one language to another teaches us about both languages and about the problem being solved. + +Cross-fertilization in the use of programming languages has huge effects. Perhaps the most obvious is the increased and increasing use of declarative modes of expression in systems implemented in imperative languages. Anyone versed in functional programming can easily apply a declarative approach even when using a language such as C. Using declarative approaches generally leads to shorter and more comprehensible programs. C++, for instance, certainly takes this on board with its wholehearted support for generic programming, which almost necessitates a declarative mode of expression. + +The consequence of all this is that it behooves every programmer to be well skilled in programming in at least two different paradigms, and ideally at least the five mentioned above. Programmers should always be interested in learning new languages, preferably from an unfamiliar paradigm. Even if the day job always uses the same programming language, the increased sophistication of use of that language when a person can cross-fertilize from other paradigms should not be underestimated. Employers should take this on board and allow in their training budget for employees to learn languages that are not currently being used as a way of increasing the sophistication of use of the languages that are used. + +Although it's a start, a one-week training course is not sufficient to learn a new language: It generally takes a good few months of use, even if part-time, to gain a proper working knowledge of a language. It is the idioms of use, not just the syntax and computational model, that are the important factors. + +By [Russel Winder](http://programmer.97things.oreilly.com/wiki/index.php/Russel_Winder) \ No newline at end of file diff --git a/fr-IR/thing_45/README.md b/fr-IR/thing_45/README.md new file mode 100644 index 00000000..52d33539 --- /dev/null +++ b/fr-IR/thing_45/README.md @@ -0,0 +1,23 @@ +# Know Your IDE + +In the 1980s our programming environments were typically nothing better than glorified text editors... if we were lucky. Syntax highlighting, which we take for granted nowadays, was a luxury that certainly was not available to everyone. Pretty printers to format our code nicely were usually external tools that had to be run to correct our spacing. Debuggers were also separate programs run to step through our code, but with a lot of cryptic keystrokes. + +During the 1990s companies began to recognize the potential income that they could derive from equipping programmers with better and more useful tools. The Integrated Development Environment (IDE) combined the previous editing features with a compiler, debugger, pretty printer, and other tools. During that time, menus and the mouse also became popular, which meant that developers no longer needed to learn cryptic key combinations to use their editors. They could simply select their command from the menu. + +In the 21st century IDEs have become so common place that they are given away for free by companies wishing to gain market share in other areas. The modern IDE is equipped with an amazing array of features. My favorite is automated refactoring, particularly *Extract Method*, where I can select and convert a chunk of code into a method. The refactoring tool will pick up all the parameters that need to be passed into the method, which makes it extremely easy to modify code. My IDE will even detect other chunks of code that could also be replaced by this method and ask me whether I would like to replace them too. + +Another amazing feature of modern IDEs is the ability to enforce style rules within a company. For example, in Java, some programmers have started making all parameters final (which, in my opinion, is a waste of time). However, since they have such a style rule, all I would need to do to follow it is set it up in my IDE: I would get a warning for any non-final parameter. Style rules can also be used to find probable bugs, such as comparing autoboxed objects for reference equality, e.g., using `==` on primitive values that are autoboxed into reference objects. + +Unfortunately modern IDEs do not require us to invest effort in order to learn how to use them. When I first programmed C on Unix, I had to spend quite a bit of time learning how the vi editor worked, due to its steep learning curve. This time spent up-front paid off handsomely over the years. I am even typing the draft of this article with *vi*. Modern IDEs have a very gradual learning curve, which can have the effect that we never progress beyond the most basic usage of the tool. + +My first step in learning an IDE is to memorize the keyboard shortcuts. Since my fingers are on the keyboard when I'm typing my code, pressing *Ctrl+Shift+I* to inline a variable saves breaking the flow, whereas switching to navigate a menu with my mouse interrupts the flow. These interruptions lead to unnecessary context switches, making me much less productive if I try to do everything the lazy way. The same rule also applies to keyboard skills: Learn to touch type, you won't regret the time invested up-front. + +Lastly, as programmers we have time proven Unix streaming tools that can help us manipulate our code. For example, if during a code review, I noticed that the programmers had named lots of classes the same, I could find these very easily using the tools *find*, *sed*, *sort*, *uniq*, and *grep*, like this: + +``` +find . -name "*.java" | sed 's/.*\///' | sort | uniq -c | grep -v "^ *1 " | sort -r +``` + +We expect a plumber coming to our house to be able to use his blow torch. Let's spend a bit of time to study how to become more effective with our IDE. + +by [Heinz Kabutz](http://programmer.97things.oreilly.com/wiki/index.php/Heinz_Kabutz) \ No newline at end of file diff --git a/fr-IR/thing_46/README.md b/fr-IR/thing_46/README.md new file mode 100644 index 00000000..22017199 --- /dev/null +++ b/fr-IR/thing_46/README.md @@ -0,0 +1,49 @@ +# Know Your Limits + +> *"Man's got to know his limitations." — Dirty Harry* + +Your resources are limited. You only have so much time and money to do your work, including the time and money needed to keep your knowledge, skills, and tools up-to-date. You can only work so hard, so fast, so smart, and so long. Your tools are only so powerful. Your target machines are only so powerful. So you have to respect the limits of your resources. + +How to respect those limits? Know yourself, know your people, know your budgets, and know your stuff. Especially, as a software engineer, know the space and time complexity of your data structures and algorithms, and the architecture and performance characteristics of your systems. Your job is to create an optimal marriage of software and systems. + +Space and time complexity are given as the function *O(f(n))* which for n equal the size of the input is the asymptotic space or time required as n grows to infinity. Important complexity classes for *f(n)* include *ln(n)*, *n*, *n ln(n)*, *ne*, and *en*. As graphing these functions clearly shows, as *n* gets bigger *O(ln(n))* is ever so much smaller than *O(n)* and *O(n ln(n))*, which are ever so much smaller than *O(ne)* and *O(en)*. As Sean Parent puts it, for achievable n all complexity classes amount to near-constant, near-linear, or near-infinite. + +![](http://programmer.97things.oreilly.com/wiki/images/c/c0/Clearly.jpeg) + +| | access time | capacity | +|--------------|-----------------:| ----------:| +| register | < 1 ns | 64b | +| cache line | | 64B | +| L1 cache | 1 ns | 64 KB | +| L2 cache | 4 ns | 8 MB | +| RAM | 20 ns | 32 GB | +| disk | 10 ms | 10 TB | +| LAN | 20 ms | > 1 PB | +| internet | 100 ms | > 1 ZB | + +Complexity analysis is in terms of an abstract machine, but software runs on real machines. Modern computer systems are organized as hierarchies of physical and virtual machines, including language runtimes, operating systems, CPUs, cache memory, random-access memory, disk drives, and networks. The first table shows the limits on random access time and storage capacity for a typical networked server. + +Note that capacity and speed vary by several orders of magnitude. Caching and lookahead are used heavily at every level of our systems to hide this variation, but they only work when access is predictable. When cache misses are frequent the system will be thrashing. For example, to randomly inspect every byte on a hard drive could take 32 years. Even to randomly inspect every byte in RAM could take 11 minutes. Random access is not predictable. What is? That depends on the system, but re-accessing recently used items and accessing items sequentially are usually a win. + +Algorithms and data structures vary in how effectively they use caches. For instance: +- Linear search makes good use of lookahead, but requires *O(n)* comparisons. +- Binary search of a sorted array requires only *O(log(n))* comparisons. +- Search of a van Emde Boas tree is *O(log(n))* and cache-oblivious. + + +|Elements | Search time (ns)| | | +|:--------|-----------:|-----------:|--------:| +| | **linear** | **binary** | **vEB** | +| 8 | 50 | 90 | 40 | +| 64 | 180 | 150 | 70 | +| 512 | 1200 | 230 | 100 | +| 4096 | 17000 | 320 | 160 | + + +How to choose? In the last analysis, by measuring. The second table shows the time required to search arrays of 64-bit integers via these three methods. On my computer: +- Linear search is competitive for small arrays, but loses exponentially for larger arrays. +- van Emde Boas wins hands down, thanks to its predictable access pattern. + +> *"You pays your money and you takes your choice." — [Punch](http://www.nytimes.com/1988/02/28/magazine/on-language-you-pays-yer-money.html?pagewanted=all)* + +By [Greg Colvin](http://programmer.97things.oreilly.com/wiki/index.php/Greg_Colvin) diff --git a/fr-IR/thing_47/README.md b/fr-IR/thing_47/README.md new file mode 100644 index 00000000..f62c5d6c --- /dev/null +++ b/fr-IR/thing_47/README.md @@ -0,0 +1,19 @@ +# Know Your Next Commit + +I tapped three programmers on their shoulders and asked what they were doing. "I am refactoring these methods," the first answered. "I am adding some parameters to this web action," the second answered. The third answered, "I am working on this user story." + +It might seem that the first two were engrossed in the details of their work while only the third could see the bigger picture, and that the latter had the better focus. However, when I asked when and what they would commit, the picture changed dramatically. The first two where pretty clear over what files would be involved and would be finished within an hour or so. The third programmer answered, "Oh, I guess I will be ready within a few days. I will probably add a few classes and might change those services in some way." + +The first two did not lack a vision of the overall goal. They had selected tasks they thought led in a productive direction, and could be finished within a couple of hours. Once they had finished those tasks, they would select a new feature or refactoring to work on. All the code written was thus done with a clear purpose and a limited, achievable goal in mind. + +The third programmer had not been able to decompose the problem and was working on all aspects at once. He had no idea of what it would take, basically doing speculative programming, hoping to arrive at some point where he would be able to commit. Most probably the code written at the start of this long session was poorly matched for the solution that came out in the end. + +What would the first two programmers do if their tasks took more than two hours? After realizing they had taken on too much, they would most likely throw away their changes, define smaller tasks, and start over. To keep working would have lacked focus and led to speculative code entering the repository. Instead, changes would be thrown away, but the insights kept. + +The third programmer might keep on guessing and desperately try to patch together his changes into something that could be committed. After all, you cannot throw away code changes you have done — that would be wasted work, wouldn't it? Unfortunately, not throwing the code away leads to slightly odd code that lacks a clear purpose entering the repository. + +At some point even the commit-focused programmers might fail to find something useful they thought could be finished in two hours. Then, they would go directly into speculative mode, playing around with the code and, of course, throwing away the changes whenever some insight led them back on track. Even these seemingly unstructured hacking sessions have purpose: to learn about the code to be able to define a task that would constitute a productive step. + +Know your next commit. If you cannot finish, throw away your changes, then define a new task you believe in with the insights you have gained. Do speculative experimentation whenever needed, but do not let yourself slip into speculative mode without noticing. Do not commit guesswork into your repository. + +By [Dan Bergh Johnsson](http://programmer.97things.oreilly.com/wiki/index.php/Dan_Bergh_Johnsson) \ No newline at end of file diff --git a/fr-IR/thing_48/README.md b/fr-IR/thing_48/README.md new file mode 100644 index 00000000..a42518f9 --- /dev/null +++ b/fr-IR/thing_48/README.md @@ -0,0 +1,15 @@ +# Large Interconnected Data Belongs to a Database + +If your application is going to handle a large, persistent, interconnected set of data elements, don't hesitate to store it in a relational database. In the past RDBMSs used to be expensive, scarce, complex, and unwieldy beasts. This is no longer the case. Nowadays RDBMS systems are easy to find — it is likely that the system you're using has already one or two installed. Some very capable RDBMSs, like MySQL and PostgreSQL, are available as open source software, so cost of purchase is no longer an issue. Even better, so-called embedded database systems can be linked as libraries directly into your application, requiring almost no setup or management — two notable open source ones are SQLite and HSQLDB. These systems are extremely efficient. + +If your application's data is larger than the system's RAM, an indexed RDBMS table will perform orders of magnitude faster than your library's map collection type, which will thrash virtual memory pages. Modern database offerings can easily grow with your needs. With proper care, you can scale up an embedded database to a larger database system when required. Later on you can switch from a free, open source offering to a better-supported or more powerful proprietary system. + +Once you get the hang of SQL, writing database-centric applications is a joy. After you've stored your properly normalized data in the database it's easy to extract facts efficiently with a readable SQL query; there's no need to write any complex code. Similarly, a single SQL command can perform complex data changes. For one-off modifications, say a change in the way you organize your persistent data, you don't even need to write code: Just fire up the database's direct SQL interface. This same interface also allows you to experiment with queries, sidestepping a regular programming language's compile–edit cycle. + +Another advantage of basing your code around an RDBMS involves the handling of relationships between your data elements. You can describe consistency constraints on your data in a declarative way, avoiding the risk of the dangling pointers you get if you forget to update your data in an edge case. For example, you can specify that if a user is deleted then the messages sent by that user should be removed as well. + +You can also create efficient links between the entities stored in the database anytime you want, simply by creating an index. There is no need to perform expensive and extensive refactorings of class fields. In addition, coding around a database allows multiple applications to access your data in a safe way. This makes it easy to upgrade your application for concurrent use and also to code each part of your application using the most appropriate language and platform. For instance, you could write the XML back-end of a web-based application in Java, some auditing scripts in Ruby, and a visualization interface in [Processing](http://www.processing.org/). + +Finally, keep in mind that the RDBMS will sweat hard to optimize your SQL commands, allowing you to concentrate on your application's functionality rather than on algorithmic tuning. Advanced database systems will even take advantage of multicore processors behind your back. And, as technology improves, so will your application's performance. + +By [Diomidis Spinellis](http://programmer.97things.oreilly.com/wiki/index.php/Diomidis_Spinellis) \ No newline at end of file diff --git a/fr-IR/thing_49/README.md b/fr-IR/thing_49/README.md new file mode 100644 index 00000000..455c33d5 --- /dev/null +++ b/fr-IR/thing_49/README.md @@ -0,0 +1,19 @@ +# Learn Foreign Languages + +Programmers need to communicate. A lot. + +There are periods in a programmer's life when most communication seems to be with the computer. More precisely, with the programs running on that computer. This communication is about expressing ideas in a machine-readable way. It remains an exhilarating prospect: Programs are ideas turned into reality, with virtually no physical substance involved. + +Programmers need to be fluent in the language of the machine, whether real or virtual, and in the abstractions that can be related to that language via development tools. It is important to learn many different abstractions, otherwise some ideas become incredibly hard to express. Good programmers need to be able to stand outside their daily routine, to be aware of other languages that are expressive for other purposes. The time always comes when this pays off. + +Beyond communication with machines, programmers need to communicate with their peers. Today's large projects are more social endeavors than simply an application of the art of programming. It is important to understand and express more than the machine-readable abstractions can. Most of the best programmers I know are also very fluent in their mother's tongue, and typically in other languages as well. This is not just about communication with others: Speaking a language well also leads to a clarity of thought that is indispensable when abstracting a problem. And this is what programming is also about. + +Beyond communication with machine, self, and peers, a project has many stakeholders, most with a different or no technical background. They live in testing, quality and deployment, in marketing and sales, they are end users in some office (or store or home). You need to understand them and their concerns. This is almost impossible if you cannot speak their language — the language of their world, their domain. While you might think a conversation with them went well, they probably don't. + +If you talk to accountants, you need a basic knowledge of cost-center accounting, of tied capital, capital employed, et al. If you talk to marketing or lawyers, some of their jargon and language (and thus, their minds) should be familiar to you. All these domain-specific languages need to be mastered by someone in the project — ideally the programmers. Programmers are ultimately responsible for bringing the ideas to life via a computer. + +And, of course, life is more than software projects. As noted by [Charlemagne](http://en.wikipedia.org/wiki/Charlemagne), to know another language is to have another soul. For your contacts beyond the software industry, you will appreciate knowing foreign languages. To know when to listen rather than talk. To know that most language is without words. + +> *Whereof one cannot speak, thereof one must be silent.* - Ludwig Wittgenstein + +By [Klaus Marquardt](http://programmer.97things.oreilly.com/wiki/index.php/Klaus_Marquardt) \ No newline at end of file diff --git a/fr-IR/thing_50/README.md b/fr-IR/thing_50/README.md new file mode 100644 index 00000000..f9b665db --- /dev/null +++ b/fr-IR/thing_50/README.md @@ -0,0 +1,31 @@ +# Learn to Estimate + +As a programmer you need to be able to provide estimates to your managers, colleagues, and users for the tasks you need to perform, so that they will have a reasonably accurate idea of the time, costs, technology, and other resources needed to achieve their goals. + +To be able to estimate well it is obviously important to learn some estimation techniques. First of all, however, it is fundamental to learn what estimates are, and what they should be used for — as strange as it may seem, many developers and managers don't really know this. + +The following exchange between a project manager and a programmer is not untypical: + +> *Project Manager:* Can you give me an estimate of the time necessary to develop feature *xyz*? + +> *Programmer:* One month. + +> *Project Manager:* That's far too long! We've only got one week. + +> *Programmer:* I need at least three. + +> *Project Manager:* I can give you two at most. + +> *Programmer:* Deal! + +The programmer, at the end, comes up with an "estimate" that matches what is acceptable for the manager. But since it is seen to be the programmer's estimate, the manager will hold the programmer accountable to it. To understand what is wrong with this conversation we need three definitions — estimate, target, and commitment: + +- An *estimate* is an approximate calculation or judgement of the value, number, quantity, or extent of something. This definition implies that an estimate is a factual measure based on hard data and previous experience — hopes and wishes must be ignored when calculating it. The definition also implies that, being approximate, an estimate cannot be precise, e.g., a development task cannot be estimated to last 234.14 days. +- A *target* is a statement of a desirable business objective, e.g., "The system must support at least 400 concurrent users." +- A *commitment* is a promise to deliver specified functionality at a certain level of quality by a certain date or event. One example could be "The search functionality will be available in the next release of the product." + +Estimates, targets, and commitments are independent from each other, but targets and commitments should be based on sound estimates. As Steve McConnell notes, "The primary purpose of software estimation is not to predict a project's outcome; it is to determine whether a project's targets are realistic enough to allow the project to be controlled to meet them." Thus, the purpose of estimation is to make proper project management and planning possible, allowing the project stakeholders to make commitments based on realistic targets. + +What the manager in the conversation above was really asking the programmer was to make a commitment based on an unstated target that the manager had in mind, not to provide an estimate. The next time you are asked to provide an estimate make sure everybody involved knows what they are talking about, and your projects will have a better chance of succeeding. Now it's time to learn some techniques.... + +By [Giovanni Asproni](http://programmer.97things.oreilly.com/wiki/index.php/Giovanni_Asproni) \ No newline at end of file diff --git a/fr-IR/thing_51/README.md b/fr-IR/thing_51/README.md new file mode 100644 index 00000000..1d0a5b31 --- /dev/null +++ b/fr-IR/thing_51/README.md @@ -0,0 +1,39 @@ +# Learn to Say "Hello, World" + +Paul Lee, username leep, more commonly known as Hoppy, had a reputation as the local expert on programming issues. I needed help. I walked across to Hoppy's desk and asked, could he take a look at some code for me? + +Sure, said Hoppy, pull up a chair. I took care not to topple the empty cola cans stacked in a pyramid behind him. + +What code? + +In a function in a file, I said. + +So let's take a look at this function. Hoppy moved aside a copy of K&R and slid his keyboard in front of me. + +Where's the IDE? Apparently Hoppy had no IDE running, just some editor which I couldn't operate. He grabbed back the keyboard. A few keystrokes later and we had the file open — it was quite a big file — and were looking at the function — it was quite a big function. He paged down to the conditional block I wanted to ask about. + +What would this clause actually do if `x` is negative? I asked. Surely it's wrong. + +I'd been trying all morning to find a way to force `x` to be negative, but the big function in the big file was part of a big project, and the cycle of recompiling *then* rerunning my experiments was wearing me down. Couldn't an expert like Hoppy just tell me the answer? + +Hoppy admitted he wasn't sure. To my surprise, he didn't reach for K&R. Instead, he copied the code block into a new editor buffer, re-indented it, wrapped it up in a function. A short while later he'd coded up a main function that looped forever, prompting the user for input values, passing them to the function, printing out the result. He saved the buffer as a new file, tryit.c. All of this I could have done for myself, though perhaps not as quickly. But his next step was wonderfully simple and, at the time, quite foreign to my way of working: + +``` +$ cc tryit.c && ./a.out +``` + +Look! His actual program, conceived just a few minutes earlier, was now up and running. We tried a few values and confirmed my suspicions (so I'd been right about something!) and then he cross-checked the relevant section of K&R. I thanked Hoppy and left, again taking care not to disturb his cola can pyramid. + +Back at my own desk, I closed down my IDE. I'd become so used to working on a big project within a big product I'd started to think that was what I should be doing. A general purpose computer can do little tasks too. I opened a text editor and began typing. + +``` +#include + +int main() +{ + printf("Hello, World\n"); + return 0; +} +``` + +By [Thomas Guest](http://programmer.97things.oreilly.com/wiki/index.php/Thomas_Guest) \ No newline at end of file diff --git a/fr-IR/thing_52/README.md b/fr-IR/thing_52/README.md new file mode 100644 index 00000000..da65147d --- /dev/null +++ b/fr-IR/thing_52/README.md @@ -0,0 +1,17 @@ +# Let Your Project Speak for Itself + +Your project probably has a version control system in place. Perhaps it is connected to a continuous integration server that verifies correctness by automated tests. That's great. + +You can include tools for static code analysis into your continuous integration server to gather code metrics. These metrics provide feedback about specific aspects of your code, as well as their evolution over time. When you install code metrics, there will always be a red line that you do not want to cross. Let's assume you started with 20% test coverage and never want to fall below 15%. Continuous integration helps you keep track of all these numbers, but you still have to check regularly. Imagine you could delegate this task to the project itself and rely on it to report when things get worse. + +You need to give your project a voice. This can be done by email or instant messaging, informing the developers about the latest decline or improvement in numbers. But it's even more effective to embody the project in your office by using an extreme feedback device (XFD). + +The idea of XFDs is to drive a physical device such as a lamp, a portable fountain, a toy robot, or even an USB rocket launcher, based on the results of the automatic analysis. Whenever your limits are broken, the device alters its state. In case of a lamp, it will light up, bright and obvious. You can't miss the message even if you're hurrying out the door to get home. + +Depending on the type of extreme feedback device, you can hear the build break, see the red warning signals in your code, or even smell your code smells. The devices can be replicated at different locations if you work on a distributed team. You can place a traffic light in your project manager's office, indicating overall project health state. Your project manager will appreciate it. + +Let your creativity guide you in choosing an appropriate device. If your culture is rather geeky, you might look for ways to equip your team mascot with radio-controlled toys. If you want a more professional look, invest in sleek designer lamps. Search the Internet for more inspiration. Anything with a power plug or a remote control has the potential to be used as an extreme feedback device. + +The extreme feedback device acts as the voice box of your project. The project now resides physically with the developers, complaining or praising them according to the rules the team has chosen. You can drive this personification further by applying speech synthesis software and a pair of loudspeakers. Now your project really speaks for itself. + +By [Daniel Lindner](http://programmer.97things.oreilly.com/wiki/index.php/Daniel_Lindner) \ No newline at end of file diff --git a/fr-IR/thing_53/README.md b/fr-IR/thing_53/README.md new file mode 100644 index 00000000..af6960a3 --- /dev/null +++ b/fr-IR/thing_53/README.md @@ -0,0 +1,52 @@ +# The Linker Is not a Magical Program + +Depressingly often (happened to me again just before I wrote this), the view many programmers have of the process of going from source code to a statically linked executable in a compiled language is: + +1. Edit source code +2. Compile source code into object files +3. Something magical happens +4. Run executable + +Step 3 is, of course, the linking step. Why would I say such an outrageous thing? I've been doing tech support for decades, and I get the following questions again and again: + +- The linker says def is defined more than once. +- The linker says abc is an unresolved symbol. +- Why is my executable so large? + +Followed by "What do I do now?" usually with the phrases "seems to" and "somehow" mixed in, and an aura of utter bafflement. It's the "seems to" and "somehow" that indicate that the linking process is viewed as a magical process, presumably understandable only by wizards and warlocks. The process of compiling does not elicit these kinds of phrases, implying that programmers generally understand how compilers work, or at least what they do. + +A linker is a very stupid, pedestrian, straightforward program. All it does is concatenate together the code and data sections of the object files, connect the references to symbols with their definitions, pull unresolved symbols out of the library, and write out an executable. That's it. No spells! No magic! The tedium in writing a linker is usually all about decoding and generating the usually ridiculously overcomplicated file formats, but that doesn't change the essential nature of a linker. + +So let's say the linker is saying def is defined more than once. Many programming languages, such as C, C++, and D, have both declarations and definitions. Declarations normally go into header files, like: + +``` +extern int iii; +``` + +which generates an external reference to the symbol `iii`. A definition, on the other hand, actually sets aside storage for the symbol, usually appears in the implementation file, and looks like this: + +``` +int iii = 3; +``` + +How many definitions can there be for each symbol? As in the film *Highlander*, there can be only one. So, what if a definition of iii appears in more than one implementation file? + +``` +// File a.c +int iii = 3; +``` + +``` +// File b.c +double iii(int x) { return 3.7; } +``` + +The linker will complain about `iii` being multiply defined. + +Not only can there be only one, there must be one. If iii only appears as a declaration, but never a definition, the linker will complain about iii being an unresolved symbol. + +To determine why an executable is the size it is, take a look at the map file that linkers optionally generate. A map file is nothing more than a list of all the symbols in the executable along with their addresses. This tells you what modules were linked in from the library, and the sizes of each module. Now you can see where the bloat is coming from. Often there will be library modules that you have no idea why were linked in. To figure it out, temporarily remove the suspicious module from the library, and relink. The undefined symbol error then generated will indicate who is referencing that module. + +Although it is not always immediately obvious why you get a particular linker message, there is nothing magical about linkers. The mechanics are straightforward; it's the details you have to figure out in each case. + +By [Walter Bright](http://creativecommons.org/licenses/by/3.0/us/) diff --git a/fr-IR/thing_54/README.md b/fr-IR/thing_54/README.md new file mode 100644 index 00000000..3a117d54 --- /dev/null +++ b/fr-IR/thing_54/README.md @@ -0,0 +1,33 @@ +# The Longevity of Interim Solutions + +Why do we create interim solutions? + +Typically there is some immediate problem to solve. It might be internal to the development team, some tooling that fills a gap in the tool chain. It might be external, visible to end users, such as a workaround that addresses missing functionality. + +In most systems and teams you will find some software that is somewhat dis-integrated from the system, that is considered a draft to be changed sometime, that does not follow the standards and guidelines that shaped the rest of the code. Inevitably you will hear developers complaining about these. The reasons for their creation are many and varied, but the key to an interim solution's success is simple: It is useful. + +Interim solutions, however, acquire inertia (or momentum, depending on your point of view). Because they are there, ultimately useful and widely accepted, there is no immediate need to do anything else. Whenever a stakeholder has to decide what action adds the most value, there will be many that are ranked higher than proper integration of an interim solution. Why? Because it is there, it works, and it is accepted. The only perceived downside is that it does not follow the chosen standards and guidelines — except for a few niche markets, this is not considered to be a significant force. + +So the interim solution remains in place. Forever. + +And if problems arise with that interim solution, it is unlikely there will be provision for an update that brings it into line with accepted production quality. What to do? A quick interim update on that interim solution often does the job. And will most likely be well received. It exhibits the same strengths as the initial interim solution... it is just more up to date. + +Is this a problem? + +The answer depends on your project, and on your personal stake in the production code standards. When the systems contains too many interim solutions, its entropy or internal complexity grows and its maintainability decreases. However, this is probably the wrong question to ask first. Remember that we are talking about a solution. It may not be your preferred solution — it is unlikely to be anyone's preferred solution — but the motivation to rework this solution is weak. + +So what can we do if we see a problem? + +1. Avoid creating an interim solution in the first place. +2. Change the forces that influence the decision of the project manager. +3. Leave it as is. + +Let's examine these options more closely: + +1. Avoidance does not work in most places. There is an actual problem to solve, and the standards have turned out to be too restrictive. You might spend some energy trying to change the standards. An honorable albeit tedious endeavor... and that change will not be effective in time for your problem at hand. +2. The forces are rooted in the project culture, which resists volitional change. It could be successful in very small projects — especially if it's just you — and you just happen to clean the mess without asking in advance. It could also be successful if the project is such a mess that it is visibly stalled and some time for cleaning up is commonly accepted. +3. The status quo automatically applies if the previous option does not. + +You will create many solutions, some of them will be interim, most of them will be useful. The best way to overcome interim solutions is to make them superfluous, to provide a more elegant and useful solution. May you be granted the [serenity](http://en.wikipedia.org/wiki/Serenity_prayer) to accept the things you cannot change, courage to change the things you can, and wisdom to know the difference. + +By [Klaus Marquardt](http://programmer.97things.oreilly.com/wiki/index.php/Klaus_Marquardt) diff --git a/fr-IR/thing_55/README.md b/fr-IR/thing_55/README.md new file mode 100644 index 00000000..5a658369 --- /dev/null +++ b/fr-IR/thing_55/README.md @@ -0,0 +1,16 @@ +# Make Interfaces Easy to Use Correctly and Hard to Use Incorrectly + +One of the most common tasks in software development is interface specification. Interfaces occur at the highest level of abstraction (user interfaces), at the lowest (function interfaces), and at levels in between (class interfaces, library interfaces, etc.). Regardless of whether you work with end users to specify how they'll interact with a system, collaborate with developers to specify an API, or declare functions private to a class, interface design is an important part of your job. If you do it well, your interfaces will be a pleasure to use and will boost others' productivity. If you do it poorly, your interfaces will be a source of frustration and errors. + +Good interfaces are: + +- **Easy to use correctly.** People using a well-designed interface almost always use the interface correctly, because that's the path of least resistance. In a GUI, they almost always click on the right icon, button, or menu entry, because it's the obvious and easy thing to do. In an API, they almost always pass the correct parameters with the correct values, because that's what's most natural. With interfaces that are easy to use correctly, *things just work.* +- **Hard to use incorrectly.** Good interfaces anticipate mistakes people might make and make them difficult — ideally impossible — to commit. A GUI might disable or remove commands that make no sense in the current context, for example, or an API might eliminate argument-ordering problems by allowing parameters to be passed in any order. + +A good way to design interfaces that are easy to use correctly is to exercise them before they exist. Mock up a GUI — possibly on a whiteboard or using index cards on a table — and play with it before any underlying code has been created. Write calls to an API before the functions have been declared. Walk through common use cases and specify how you *want* the interface to behave. What do you *want* to be able to click on? What do you *want* to be able to pass? Easy to use interfaces seem natural, because they let you do what you want to do. You're more likely to come up with such interfaces if you develop them from a user's point of view. (This perspective is one of the strengths of test-first programming.) + +Making interfaces hard to use incorrectly requires two things. First, you must anticipate errors users might make and find ways to prevent them. Second, you must observe how an interface is misused during early release and modify the interface — yes, modify the interface! — to prevent such errors. The best way to prevent incorrect use is to make such use impossible. If users keep wanting to undo an irrevocable action, try to make the action revocable. If they keep passing the wrong value to an API, do your best to modify the API to take the values that users want to pass. + +Above all, remember that interfaces exist for the convenience of their users, not their implementers. + +By [Scott Meyers](http://programmer.97things.oreilly.com/wiki/index.php/Scott_Meyers) \ No newline at end of file diff --git a/fr-IR/thing_56/README.md b/fr-IR/thing_56/README.md new file mode 100644 index 00000000..777bf6b5 --- /dev/null +++ b/fr-IR/thing_56/README.md @@ -0,0 +1,19 @@ +# Make the Invisible More Visible + +Many aspects of invisibility are rightly lauded as software principles to uphold. Our terminology is rich in invisibility metaphors — mechanism transparency and information hiding, to name but two. Software and the process of developing it can be, to paraphrase Douglas Adams, *mostly invisible*: + +- Source code has no innate presence, no innate behavior, and doesn't obey the laws of physics. It's visible when you load it into an editor, but close the editor and it's gone. Think about it too long and, like the tree falling down with no one to hear it, you start to wonder if it exists at all. +- A running application has presence and behavior, but reveals nothing of the source code it was built from. Google's home page is pleasingly minimal; the goings on behind it are surely substantial. +- If you're 90% done and endlessly stuck trying to debug your way through the last 10% then you're not 90% done, are you? Fixing bugs is not making progress. You aren't paid to debug. Debugging is waste. It's good to make waste more visible so you can see it for what it is and start thinking about trying not to create it in the first place. +- If your project is apparently on track and one week later it's six months late you have problems, the biggest of which is probably not that it's six months late, but the invisibility force fields powerful enough to hide six months of lateness! Lack of visible progress is synonymous with lack of progress. + +Invisibility can be dangerous. You think more clearly when you have something concrete to tie your thinking to. You manage things better when you can see them and see them constantly changing: + +- Writing unit tests provides evidence about how easy the code unit is to unit test. It helps reveal the presence (or absence) of developmental qualities you'd like the code to exhibit; qualities such as low coupling and high cohesion. +- Running unit tests provides evidence about the code's behavior. It helps reveal the presence (or absence) of runtime of qualities you'd like the application to exhibit; qualities such as robustness and correctness. +- Using bulletin boards and cards makes progress visible and concrete. Tasks can be seen as *Not Started*, *In Progress*, or *Done* without reference to a hidden project management tool and without having to chase programmers for fictional status reports. +- Doing incremental development increases the visibility of development progress (or lack of it) by increasing the frequency of development evidence. Completion of releasable software reveals reality; estimates do not. + +It's best to develop software with plenty of regular visible evidence. Visibility gives confidence that progress is genuine and not an illusion, deliberate and not unintentional, repeatable and not accidental. + +By [Jon Jagger](http://programmer.97things.oreilly.com/wiki/index.php/Jon_Jagger) \ No newline at end of file diff --git a/fr-IR/thing_57/README.md b/fr-IR/thing_57/README.md new file mode 100644 index 00000000..74c35ed9 --- /dev/null +++ b/fr-IR/thing_57/README.md @@ -0,0 +1,19 @@ +# Message Passing Leads to Better Scalability in Parallel Systems + +Programmers are taught from the very outset of their study of computing that concurrency — and especially parallelism, a special subset of concurrency — is hard, that only the very best can ever hope to get it right, and even they get it wrong. There is invariably great focus on threads, semaphores, monitors, and how hard it is to get concurrent access to variables to be thread-safe. + +True, there are many difficult problems, and they can be very hard to solve. But what is the root of the problem? Shared memory. Almost all the problems of concurrency that people go on and on about relate to the use of shared mutable memory: race conditions, deadlock, livelock, etc. The answer seems obvious: Either forgo concurrency or eschew shared memory! + +Forgoing concurrency is almost certainly not an option. Computers have more and more cores on an almost quarterly basis, so harnessing true parallelism becomes more and more important. We can no longer rely on ever increasing processor clock speeds to improve application performance. Only by exploiting parallelism will the performance of applications improve. Obviously, not improving performance is an option, but it is unlikely to be acceptable to users. + +So can we eschew shared memory? Definitely. + +Instead of using threads and shared memory as our programming model, we can use processes and message passing. Process here just means a protected independent state with executing code, not necessarily an operating system process. Languages such as Erlang (and occam before it) have shown that processes are a very successful mechanism for programming concurrent and parallel systems. Such systems do not have all the synchronization stresses that shared memory, multi-threaded systems have. Moreover there is a formal model — Communicating Sequential Processes (CSP) — that can be applied as part of the engineering of such systems. + +We can go further and introduce dataflow systems as a way of computing. In a dataflow system there is no explicitly programmed control flow. Instead a directed graph of operators, connected by data paths, is set up and then data fed into the system. Evaluation is controlled by the readiness of data within the system. Definitely no synchronization problems. + +Having said all this, languages such as C, C++, Java, Python, and Groovy are the principal languages of systems development and all of these are presented to programmers as languages for developing shared memory, multi-threaded systems. So what can be done? The answer is to use — or, if they don't exist, create — libraries and frameworks that provide process models and message passing, avoiding all use of shared mutable memory. + +All in all, not programming with shared memory, but instead using message passing, is likely to be the most successful way of implementing systems that harness the parallelism that is now endemic in computer hardware. Bizarrely perhaps, although processes predate threads as a unit of concurrency, the future seems to be in using threads to implement processes. + +By [Russel Winder](http://programmer.97things.oreilly.com/wiki/index.php/Russel_Winder) \ No newline at end of file diff --git a/fr-IR/thing_58/README.md b/fr-IR/thing_58/README.md new file mode 100644 index 00000000..517f8afe --- /dev/null +++ b/fr-IR/thing_58/README.md @@ -0,0 +1,23 @@ +# A Message to the Future + +Maybe it's because most of them are smart people, but in all the years I've taught and worked side-by-side with programmers, it seems that most of them thought that since the problems they were struggling with were difficult that the solutions should be just as difficult for everyone (maybe even for themselves a few months after the code was written) to understand and maintain. + +I remember one incident with Joe, a student in my data structures class, who had to come in to show me what he'd written. "Betcha can't guess what it does!" he crowed. + +"You're right," I agreed without spending too much time on his example and wondering how to get an important message across. "I'm sure you've been working hard on this. I wonder, though, if you haven't forgotten something important. Say, Joe, don't you have a younger brother?" + +"Yep. Sure do! Phil! He's in your Intro class. He's learning to program, too!" Joe announced proudly. + +"That's great," I replied. "I wonder if he could read this code." + +"No way!" said Joe. "This is hard stuff!" + +"Just suppose," I suggested, "that this was real working code and that in a few years Phil was hired to make a maintenance update. What have you done for him?" Joe just stared at me blinking. "We know that Phil is really smart, right?" Joe nodded. "And I hate to say it, but I'm pretty smart, too!" Joe grinned. "So if I can't easily understand what you've done here and your very smart younger brother will likely puzzle over this, what does that mean about what you've written?" Joe looked at his code a little differently it seemed to me. "How about this," I suggested in my best 'I'm your friendly mentor' voice, "Think of every line of code you write as a message for someone in the future — someone who might be your younger brother. Pretend you're explaining to this smart person how to solve this tough problem. + +"Is this what you'd like to imagine? That the smart programmer in the future would see your code and say, 'Wow! This is great! I can understand perfectly what's been done here and I'm amazed at what an elegant — no, wait — what a beautiful piece of code this is. I'm going to show the other folks on my team. This is a masterpiece!' + +"Joe, do you think you can write code that solves this difficult problem but will be so beautiful it will sing? Yes, just like a haunting melody. I think that anyone who can come up with the very difficult solution you have here could also write something beautiful. Hmm... I wonder if I should start grading on beauty? What do you think, Joe?" + +Joe picked up his work and looked at me, a little smile creeping across his face. "I got it, prof, I'm off to make the world better for Phil. Thanks." + +By [Linda Rising](http://programmer.97things.oreilly.com/wiki/index.php/Linda_Rising) \ No newline at end of file diff --git a/fr-IR/thing_59/README.md b/fr-IR/thing_59/README.md new file mode 100644 index 00000000..3ffbc3e4 --- /dev/null +++ b/fr-IR/thing_59/README.md @@ -0,0 +1,51 @@ +# Missing Opportunities for Polymorphism + +Polymorphism is one of the grand ideas that is fundamental to OO. The word, taken from Greek, means many (*poly*) forms (*morph*). In the context of programming polymorphism refers to many forms of a particular class of objects or method. But polymorphism isn't simply about alternate implementations. Used carefully, polymorphism creates tiny localized execution contexts that let us work without the need for verbose *if-then-else* blocks. Being in a context allows us to do the right thing directly, whereas being outside of that context forces us to reconstruct it so that we can then do the right thing. With careful use of alternate implementations, we can capture context that can help us produce less code that is more readable. This is best demonstrated with some code, such as the following (unrealistically) simple shopping cart: + +``` +public class ShoppingCart { + private ArrayList cart = new ArrayList(); + public void add(Item item) { cart.add(item); } + public Item takeNext() { return cart.remove(0); } + public boolean isEmpty() { return cart.isEmpty(); } +} +``` + +Let's say our webshop offers items that can be downloaded and items that need to be shipped. Let's build another object that supports these operations: + +``` +public class Shipping { + public boolean ship(Item item, SurfaceAddress address) { ... } + public boolean ship(Item item, EMailAddress address) { ... } +} +``` + +When a client has completed checkout we need to ship the goods: + +``` +while (!cart.isEmpty()) { + shipping.ship(cart.takeNext(), ???); +} +``` + +The *???* parameter isn't some new fancy elvis operator, it's asking should I email or snail-mail the item? The context needed to answer this question no longer exists. We have could captured the method of shipment in a boolean or enum and then use an *if-then-else* to fill in the missing parameter. Another solution would be create two classes that both extend Item. Let's call these DownloadableItem and SurfaceItem. Now let's write some code. I'll promote Item to be an interface that supports a single method, ship. To ship the contents of the cart, we will call `item.ship(shipper)`. Classes `DownloadableItem` and `SurfaceItem` will both implement ship. + +``` +public class DownloadableItem implements Item { + public boolean ship(Shipping shipper) { + shipper.ship(this, customer.getEmailAddress()); + } +} + +public class SurfaceItem implements Item { + public boolean ship(Shipping shipper) { + shipper.ship(this, customer.getSurfaceAddress()); + } +} +``` + +In this example we've delegated the responsibility of working with `Shipping` to each Item. Since each item knows hows it's best shipped, this arrangement allows us to get on with it without the need for an *if-then-else*. The code also demonstrates a use of two patterns that often play well together: Command and Double Dispatch. Effective use of these patterns relies on careful use of polymorphism. When that happens there will be a reduction in the number of *if-then-else* blocks in our code. + +While there are cases where it's much more practical to use *if-then-else* instead of polymorphism, it is more often the case that a more polymorphic coding style will yield a smaller, more readable and less fragile code base. The number of missed opportunities is a simple count of the *if-then-else* statements in our code. + +By [Kirk Pepperdine](http://programmer.97things.oreilly.com/wiki/index.php/Kirk_Pepperdine) diff --git a/fr-IR/thing_60/README.md b/fr-IR/thing_60/README.md new file mode 100644 index 00000000..6eca432a --- /dev/null +++ b/fr-IR/thing_60/README.md @@ -0,0 +1,17 @@ +# News of the Weird: Testers Are Your Friends + +Whether they call themselves *Quality Assurance* or *Quality Control*, many programmers call them *Trouble*. In my experience, programmers often have an adversarial relationship with the people who test their software. "They're too picky" and "They want everything perfect" are common complaints. Sound familiar? + +I'm not sure why, but I've always had a different view of testers. Maybe it's because the "tester" at my first job was the company secretary. Margaret was a very nice lady who kept the office running, and tried to teach a couple of young programmers how to behave professionally in front of customers. She also had a gift for finding any bug, no matter how obscure, in mere moments. + +Back then I was working on a program written by an accountant who thought he was a programmer. Needless to say, it had some serious problems. When I thought I had a piece straightened out, Margaret would try to use it and, more often than not, it would fail in some new way after just a few keystrokes. It was at times frustrating and embarrassing, but she was such a pleasant person that I never thought to blame her for making me look bad. Eventually the day came when Margaret was able to cleanly start the program, enter an invoice, print it, and shut it down. I was thrilled. Even better, when we installed it on our customer's machine it all worked. They never saw any problems because Margaret had helped me find and fix them first. + +So that's why I say testers are your friends. You may think the testers make you look bad by reporting trivial issues. But when customers are thrilled because they weren't bothered by all those "little things" that QC made you fix, then you look great. See what I mean? + +Imagine this: You're test-driving a utility that uses "ground-breaking artificial intelligence algorithms" to find and fix concurrency problems. You fire it up and immediately notice they misspelled "intelligence" on the splash screen. A little inauspicious, but it's just a typo, right? Then you notice the configuration screen uses check boxes where there should be radio buttons, and some of the keyboard shortcuts don't work. Now, none of these is a big deal, but as the errors add up you begin to wonder about the programmers. If they can't get the simple things right, what are the odds their AI can really find and fix something tricky like concurrency issues? + +They could be geniuses who were so focused on making the AI insanely great that they didn't notice those trivial things. And without "picky testers" pointing out the problems, you wound up finding them. And now you're questioning the competency of the programmers. + +So as strange as it may sound, those testers who seem determined to expose every little bug in your code really are your friends. + +By [Burk Hufnagel](http://programmer.97things.oreilly.com/wiki/index.php/BurkHufnagel) \ No newline at end of file diff --git a/fr-IR/thing_61/README.md b/fr-IR/thing_61/README.md new file mode 100644 index 00000000..c790bfb5 --- /dev/null +++ b/fr-IR/thing_61/README.md @@ -0,0 +1,15 @@ +# One Binary + +I've seen several projects where the build rewrites some part of the code to generate a custom binary for each target environment. This always makes things more complicated than they should be, and introduces a risk that the team may not have consistent versions on each installation. At a minimum it involves building multiple, near-identical copies of the software, each of which then has to be deployed to the right place. It means more moving parts than necessary, which means more opportunities to make a mistake. + +I once worked on a team where every property change had to be checked in for a full build cycle, so the testers were left waiting whenever they needed a minor adjustment (did I mention that the build took too long as well?). I also worked on a team where the system administrators insisted on rebuilding from scratch for production (using the same scripts that we did), which meant that we had no proof that the version in production was the one that had been through testing. And so on. + +The rule is simple: *Build a single binary that you can identify and promote through all the stages in the release pipeline.* Hold environment-specific details in the environment. This could mean, for example, keeping them in the component container, in a known file, or in the path. + +If your team either has a code-mangling build or stores all the target settings with the code, that suggests that no one has thought through the design carefully enough to separate those features which are core to the application and those which are platform-specific. Or it could be worse: The team knows what to do but can't prioritize the effort to make the change. + +Of course, there are exceptions: You might be building for targets that have significantly different resource constraints, but that doesn't apply to the majority of us who are writing "database to screen and back again" applications. Alternatively, you might be living with some legacy mess that's too hard to fix right now. In such cases, you have to move incrementally — but start as soon as possible. + +And one more thing: Keep the environment information versioned too. There's nothing worse than breaking an environment configuration and not being able to figure out what changed. The environmental information should be versioned separately from the code, since they'll change at different rates and for different reasons. Some teams use distributed version control systems for this (such as bazaar and git), since they make it easier to push changes made in production environments — as inevitably happens — back to the repository. + +By [Steve Freeman](http://programmer.97things.oreilly.com/wiki/index.php/Steve_Freeman) \ No newline at end of file diff --git a/fr-IR/thing_62/README.md b/fr-IR/thing_62/README.md new file mode 100644 index 00000000..044f6570 --- /dev/null +++ b/fr-IR/thing_62/README.md @@ -0,0 +1,13 @@ +# Only the Code Tells the Truth + +The ultimate semantics of a program is given by the running code. If this is in binary form only, it will be a difficult read! The source code should, however, be available if it is your program, any typical commercial software development, an open source project, or code in a dynamically interpreted language. Looking at the source code, the meaning of the program should be apparent. To know what a program does, the source is ultimately all you can be sure of looking at. Even the most accurate requirements document does not tell the whole truth: It does not contain the detailed story of what the program is actually doing, only the high-level intentions of the requirements analyst. A design document may capture a planned design, but it will lack the necessary detail of the implementation. These documents may be lost sync with the current implementation... or may simply have been lost. Or never written in the first place. The source code may be the only thing left. + +With this in mind, ask yourself how clearly is your code telling you or any other programmer what it is doing? + +You might say, "Oh, my comments will tell you everything you need to know." But keep in mind that comments are not running code. They can be just as wrong as other forms of documentation. There has been a tradition saying comments are unconditionally a good thing, so unquestioningly some programmers write more and more comments, even restating and explaining trivia already obvious in the code. This is the wrong way to clarify your code. If your code needs comments, consider refactoring it so it doesn't. Lengthy comments can clutter screen space and might even be hidden automatically by your IDE. If you need to explain a change, do so in the version control system check-in message and not in the code. + +What can you do to actually make your code tell the truth as clearly as possible? Strive for good names. Structure your code with respect to cohesive functionality, which also eases naming. Decouple your code to achieve orthogonality. Write automated tests explaining the intended behavior and check the interfaces. Refactor mercilessly when you learn how to code a simpler, better solution. Make your code as simple as possible to read and understand. + +Treat your code like any other composition, such as a poem, an essay, a public blog, or an important email. Craft what you express carefully, so that it does what it should and communicates as directly as possible what it is doing, so that it still communicates your intention when you are no longer around. Remember that useful code is used much longer than ever intended. Maintenance programmers will thank you. And, if you are a maintenance programmer and the code you are working on does not tell the truth easily, apply the guidelines above in a proactive manner. Establish some sanity in the code and keep your own sanity. + +by [Peter Sommerlad](http://programmer.97things.oreilly.com/wiki/index.php/Peter_Sommerlad) \ No newline at end of file diff --git a/fr-IR/thing_63/README.md b/fr-IR/thing_63/README.md new file mode 100644 index 00000000..714c1e86 --- /dev/null +++ b/fr-IR/thing_63/README.md @@ -0,0 +1,15 @@ +# Own (and Refactor) the Build + +It is not uncommon for teams that are otherwise highly disciplined about coding practices to neglect build scripts, either out of a belief that they are merely an unimportant detail or from a fear that they are complex and need to be tended to by the cult of release engineering. Unmaintainable build scripts with duplication and errors cause problems of the same magnitude as those in poorly factored code. + +One rationale for why disciplined, skilled developers treat the build as something secondary to their work is that build scripts are often written in a different language than source code. Another is that the build is not really "code." These justifications fly in the face of the reality that most software developers enjoy learning new languages and that the build is what creates executable artifacts for developers and end users to test and run. The code is useless without being built, and the build is what defines the component architecture of the application. The build is an essential part of the development process, and decisions about the build process can make the code and the coding simpler. + +Build scripts written using the wrong idioms are difficult to maintain and, more significantly, improve. It is worth spending some time to understand the right way to make a change. Bugs can appear when an application is built with the wrong version of a dependency or when a build-time configuration is wrong. + +Traditionally testing has been something that was always left to the "Quality Assurance" team. We now realize that testing as we code is necessary to being able to deliver value predictably. In much the same way, the build process needs to be owned by the development team. + +Understanding the build can simplify the entire development lifecycle and reduce costs. A simple-to-execute build allows a new developer to get started quickly and easily. Automating configuration in the build can enable you to get consistent results when multiple people are working on a project, avoiding an "it works for me" conversation. Many build tools allow you to run reports on code quality, letting you to sense potential problems early. By spending time understanding how to make the build yours, you can help yourself and everyone else on your team. You can focus on coding features, benefiting your stakeholders and making work more enjoyable. + +Learn enough of your build process to know when and how to make changes. Build scripts are code. They are too important to be left to someone else, if for no other reason than because the application is not complete until it is built. The job of programming is not complete until we have delivered working software. + +By [Steve Berczuk](http://programmer.97things.oreilly.com/wiki/index.php/Steve_Berczuk) \ No newline at end of file diff --git a/fr-IR/thing_64/README.md b/fr-IR/thing_64/README.md new file mode 100644 index 00000000..49c9f6e7 --- /dev/null +++ b/fr-IR/thing_64/README.md @@ -0,0 +1,25 @@ +# Pair Program and Feel the Flow + +Imagine that you are totally absorbed by what you are doing — focused, dedicated, and involved. You may have lost track of time. You probably feel happy. You are experiencing flow. It is difficult to both achieve and maintain flow for a whole team of developers since there are so many interruptions, interactions, and other distractions that can easily break it. + +If you have already practiced pair programming, you are probably familiar with how pairing contributes to flow. If you have not, we want to use our experiences to motivate you to start right now! To succeed with pair programming both individual team members and the team as a whole have to put in some effort. + +As a team member, be patient with developers less experienced than you. Confront your fears about being intimidated by more skilled developers. Realize that people are different, and value it. Be aware of your own strengths and weaknesses, as well as those of other team members. You may be surprised how much you can learn from your colleagues. + +As a team, introduce pair programming to promote distribution of skills and knowledge throughout the project. You should solve your tasks in pairs and rotate pairs and tasks frequently. Agree upon a rule of rotation. Put the rule aside or adjust it when necessary. Our experience is that you do not necessarily need to complete a task before rotating it to another pair. Interrupting a task to pass it to another pair may sound counterintuitive, but we have found that it works. + +There are numerous situations where flow can be broken, but where pair programming helps you keep it: + +- **Reduce the "truck factor":** It's a slightly morbid thought experiment, but how many of your team members would have to be hit by a truck before the team became unable to complete the final deliverable? In other words, how dependent is your delivery on certain team members? Is knowledge privileged or shared? If you have been rotating tasks among pairs, there is always someone else who has the knowledge and can complete the work. Your team's flow is not as affected by the "truck factor." + +- **Solve problems effectively:** If you are pair programming and you run into a challenging problem, you always have someone to discuss it with. Such dialog is more likely to open up possibilities than if you are stuck by yourself. As the work rotates, your solution will be revisited and reconsidered by the next pair, so it does not matter if you did not choose the optimal solution initially. + +- **Integrate smoothly:** If your current task involves calling another piece of code, you hope the names of the methods, the docs, and the tests are descriptive enough to give you a grasp of what it does. If not, pairing with a developer who was involved in writing that code will give you better overview and faster integration into your own code. Additionally, you can use the discussion as an opportunity to improve the naming, docs, and testing. + +- **Mitigate interruptions:** If someone comes over to ask you a question, or your phone rings, or you have to answer an urgent email, or you have to attend a meeting, your pair programming partner can keep on coding. When you return your partner is still in the flow and you will quickly catch up and rejoin them. + +- **Bring new team members up to speed quickly:** With pair programming, and a suitable rotation of pairs and tasks, newcomers quickly get to know both the code and the other team members. + +Flow makes you incredibly productive. But it is also vulnerable. Do what you can to get it, and hold on to it when you've got it! + +By [Gudny Hauknes](http://programmer.97things.oreilly.com/wiki/index.php/Gudny_Hauknes), [Ann Katrin Gagnat](http://programmer.97things.oreilly.com/wiki/index.php/Ann_Katrin_Gagnat), and Kari Røssland \ No newline at end of file diff --git a/fr-IR/thing_65/README.md b/fr-IR/thing_65/README.md new file mode 100644 index 00000000..0bb9df7d --- /dev/null +++ b/fr-IR/thing_65/README.md @@ -0,0 +1,31 @@ +# Prefer Domain-Specific Types to Primitive Types + +On 23rd September 1999 the $327.6 million Mars Climate Orbiter was lost while entering orbit around Mars due to a software error back on Earth. The error was later called the *metric mix-up*. The ground station software was working in pounds while the spacecraft expected newtons, leading the ground station to underestimate the power of the spacecraft's thrusters by a factor of 4.45. + +This is one of many examples of software failures that could have been prevented if stronger and more domain-specific typing had been applied. It is also an example of the rationale behind many features in the Ada language, one of whose primary design goals was to implement embedded safety-critical software. Ada has strong typing with static checking for both primitive types and user-defined types: + +``` +type Velocity_In_Knots is new Float range 0.0 .. 500.00; + +type Distance_In_Nautical_Miles is new Float range 0.0 .. 3000.00; + +Velocity: Velocity_In_Knots; + +Distance: Distance_In_Nautical_Miles; + +Some_Number: Float; + +Some_Number:= Distance + Velocity; -- Will be caught by the compiler as a type error. +``` + +Developers in less demanding domains might also benefit from applying more domain-specific typing, where they might otherwise continue to use the primitive data types offered by the language and its libraries, such as strings and floats. In Java, C++, Python, and other modern languages the abstract data type is known as class. Using classes such as `Velocity_In_Knots` and `Distance_In_Nautical_Miles` adds a lot of value with respect to code quality: + +- The code becomes more readable as it expresses concepts of a domain, not just Float or String. +- The code becomes more testable as the code encapsulates behavior that is easily testable. +- The code facilitates reuse across applications and systems. + +The approach is equally valid for users of both statically and dynamically typed languages. The only difference is that developers using statically typed languages get some help from the compiler while those embracing dynamically typed languages are more likely to rely on their unit tests. The style of checking may be different, but the motivation and style of expression is not. + +The moral is to start exploring domain-specific types for the purpose of developing quality software. + +By [Einar Landre](http://programmer.97things.oreilly.com/wiki/index.php/Einar_Landre) diff --git a/fr-IR/thing_66/README.md b/fr-IR/thing_66/README.md new file mode 100644 index 00000000..990100ef --- /dev/null +++ b/fr-IR/thing_66/README.md @@ -0,0 +1,27 @@ +# Prevent Errors + +Error messages are the most critical interactions between the user and the rest of the system. They happen when communication between the user and the system is near breaking point. + +It is easy to think of an error as being caused by a wrong input from the user. But people make mistakes in predictable, systematic ways. So it is possible to 'debug' the communication between the user and the rest of the system just as you would between other system components. + +For instance, say you want the user to enter a date within an allowed range. Rather than letting the user enter any date, it is better to offer a device such as a list or calendar showing only the allowed dates. This eliminates any chance of the user entering a date outside of the range. + +Formatting errors are another common problem. For instance, if a user is presented with a Date text field and enters an unambiguous date such as "July 29, 2012" it is unreasonable to reject it simply because it is not in a preferred format (such as "DD/MM/YYYY"). It is worse still to reject "29 / 07 / 2012" because it contains extra spaces — this kind of problem is particularly hard for users to understand as the date appears to be in the desired format. + +This error occurs because it is easier to reject the date than parse the three or four most common date formats. These kind of petty errors lead to user frustration, which in turn lead to additional errors as the user loses concentration. Instead, respect users' preference to enter information, not data. + +Another way of avoiding formatting errors is to offer cues — for instance, with a label within the field showing the desired format ("DD/MM/YYYY"). Another cue might be to divide the field into three text boxes of two, two, and four characters. + +Cues are different from instructions: Cues tend to be hints; instructions are verbose. Cues occur at the point of interaction; instructions appear before the point of interaction. Cues provide context; instructions dictate use. + +In general, instructions are ineffective at preventing error. Users tend to assume that interfaces will work in line with their past experience ("Surely everyone knows what 'July 29, 2012' means?"). So instructions go unread. Cues nudge users away from errors. + +Another way of avoiding errors is to offer defaults. For instance, users typically enter values that correspond to *today*, *tomorrow*, *my birthday*, *my deadline*, or *the date I entered last time I used this form*. Depending on context, one of these is likely to be a good choice as a smart default. + +Whatever the cause, systems should be tolerant of errors. You can do this by providing multiple levels of *undo* to all actions — and in particular actions which have the potential to destroy or amend users' data. + +Logging and analyzing *undo* actions can also highlight where the interface is drawing users into unconscious errors, such as persistently clicking on the 'wrong' button. These errors are often caused by misleading cues or interaction sequences that you can redesign to prevent further error. + +Whichever approach you take, most errors are systematic — the result of misunderstandings between the user and the software. Understanding how users think, interpret information, make decisions, and input data will help you debug the interactions between your software and your users. + +by [Giles Colborne](http://programmer.97things.oreilly.com/wiki/index.php/Giles_Colborne) \ No newline at end of file diff --git a/fr-IR/thing_67/README.md b/fr-IR/thing_67/README.md new file mode 100644 index 00000000..6260202a --- /dev/null +++ b/fr-IR/thing_67/README.md @@ -0,0 +1,19 @@ +# The Professional Programmer + +What is a professional programmer? + +The single most important trait of a professional programmer is *personal responsibility*. Professional programmers take responsibility for their career, their estimates, their schedule commitments, their mistakes, and their workmanship. A professional programmer does not pass that responsibility off on others. + +- If you are a professional, then *you* are responsible for your own career. *You* are responsible for reading and learning. You are responsible for staying up-to-date with the industry and the technology. Too many programmers feel that it is their employer's job to train them. Sorry, this is just dead wrong. Do you think doctors behave that way? Do you think lawyers behave that way? No, they train themselves on their own time, and their own nickel. They spend much of their off-hours reading journals and decisions. They keep themselves up-to-date. And so must we. The relationship between you and your employer is spelled out nicely in your employment contract. In short: They promise to pay you, and you promise to do a good job. + +- Professionals take responsibility for the code they write. They do not release code unless they know it works. Think about that for a minute. How can you possibly consider yourself a professional if you are willing to release code that you are not sure of? Professional programmers expect QA to find *nothing* because *they don't release their code until they've thoroughly tested it*. Of course QA will find some problems, because no one is perfect. But as professionals our attitude must be that we will leave nothing for QA to find. + +- Professionals are team players. They take responsibility for the output of the whole team, not just their own work. They help each other, teach each other, learn from each other, and even cover for each other when necessary. When one team-mate falls down, the others step in, knowing that one day they'll be the ones to need cover. + +- Professionals do not tolerate big bug lists. A huge bug list is sloppy. Systems with thousands of issues in the issue tracking database are tragedies of carelessness. Indeed, in most projects the very need for an issue tracking system is a symptom of carelessness. Only the very biggest systems should have bug lists so long that automation is required to manage them. + +- Professionals do not make a mess. They take pride in their workmanship. They keep their code clean, well structured, and easy to read. They follow agreed upon standards and best practices. They never, *ever* rush. Imagine that you are having an out-of-body experience watching a doctor perform open-heart surgery on *you*. This doctor has a *deadline* (in the literal sense). He must finish before the heart-lung bypass machine damages too many of your blood cells. How do you want him to behave? Do you want him to behave like the typical software developer, rushing and making a mess? Do you want him to say: "I'll go back and fix this later?" Or do you want him to hold carefully to his disciplines, taking his time, confident that his approach is the best approach he can reasonably take. Do you want a mess, or professionalism? + +Professionals are responsible. They take responsibility for their own careers. They take responsibility for making sure their code works properly. They take responsibility for the quality of their workmanship. They do not abandon their principles when deadlines loom. Indeed, when the pressure mounts, professionals hold ever tighter to the disciplines they know are right. + +by [Uncle Bob](http://programmer.97things.oreilly.com/wiki/index.php/Uncle_Bob) \ No newline at end of file diff --git a/fr-IR/thing_68/README.md b/fr-IR/thing_68/README.md new file mode 100644 index 00000000..771a11d8 --- /dev/null +++ b/fr-IR/thing_68/README.md @@ -0,0 +1,19 @@ +# Put Everything Under Version Control + +Put everything in all your projects under version control. The resources you need are there: free tools, like Subversion, Git, Mercurial, and CVS; plentiful disk space; cheap and powerful servers; ubiquitous networking; and even project-hosting services. After you've installed the version control software all you need in order to put your work in its repository is to issue the appropriate command in a clean directory containing your code. And there are just two new basic operations to learn: you *commit* your code changes to the repository and you update your working version of the project with the repository's version. + +Once your project is under version control you can obviously track its history, see who wrote what code, and refer to a file or project version through a unique identifier. More importantly you can make bold code changes without fear — no more commented-out code just in case you need it in the future, because the old version lives safely in the repository. You can (and should) tag a software release with a symbolic name so that you can easily revisit in the future the exact version of the software your customer runs. You can create branches of parallel development: Most projects have an active development branch and one or more maintenance branches for released versions that are actively supported. + +A version-control system minimizes friction between developers. When programmers work on independent software parts these get integrated almost by magic. When they step on each others' toes the system notices and allows them to sort out the conflicts. With some additional setup the system can notify all developers for each committed change, establishing a common understanding of the project's progress. + +When you set up your project, don't be stingy: place *all* the project's assets under version control. Apart from the source code, include the documentation, tools, build scripts, test cases, artwork, and even libraries. With the complete project safely tucked into the (regularly backed up) repository the damage of losing your disk or data is minimized. Setting up for development on a new machine involves simply checking out the project from the repository. This simplifies distributing, building, and testing the code on different platforms: On each machine a single update command will ensure that the software is the current version. + +Once you've seen the beauty of working with a version control system, following a couple of rules will make you and your team even more effective: + +- Commit each logical change in a separate operation. Lumping many changes together in a single commit will make it difficult to disentangle them in the future. This is especially important when you make project-wide refactorings or style changes, which can easily obscure other modifications. +- Accompany each commit with an explanatory message. At a minimum describe succinctly what you've changed, but if you also want to record the change's rationale this is the best place to store it. +- Finally, avoid committing code that will break a project's build, otherwise you'll become unpopular with the project's other developers. + +Life under a version control system is too good to ruin it with easily avoidable missteps. + +By [Diomidis Spinellis](http://programmer.97things.oreilly.com/wiki/index.php/Diomidis_Spinellis) \ No newline at end of file diff --git a/fr-IR/thing_69/README.md b/fr-IR/thing_69/README.md new file mode 100644 index 00000000..a90c7cdd --- /dev/null +++ b/fr-IR/thing_69/README.md @@ -0,0 +1,50 @@ +# Put the Mouse Down and Step Away from the Keyboard + +You've been focused for hours on some gnarly problem and there's no solution in sight. So you get up to stretch your legs, or to hit the vending machines, and on the way back the answer suddenly becomes obvious. + +Does this scenario sound familiar? Ever wonder why it happens? The trick is that while you're coding, the logical part of your brain is active and the creative side is shut out. It can't present anything to you until the logical side takes a break. + +Here's a real-life example: I was cleaning up some legacy code and ran into an 'interesting' method. It was designed to verify that a string contained a valid time using the format *hh:mm:ss xx*, where *hh* represents the hour, *mm* represents minutes, *ss* represents seconds, and *xx* is either *AM* or *PM*. + +The method used the following code to convert two characters (representing the hour) into a number, and verify it was within the proper range: + +``` +try { + Integer.parseInt(time.substring(0, 2)); +} catch (Exception x) { + return false; +} + +if (Integer.parseInt(time.substring(0, 2)) > 12) { + return false; +} +``` + +The same code appeared twice more, with appropriate changes to the character offset and upper limit, to test the minutes and seconds. The method ended with these lines to check for AM and PM: + +``` +if (!time.substring(9, 11).equals("AM") & + !time.substring(9, 11).equals("PM")) { + return false; +} +``` + +If none of this series of comparisons failed, returning false, the method returned true. + +If the preceding code seems wordy and difficult to follow, don't worry. I thought so too — which meant I'd found something worth cleaning up. I refactored it and wrote a few unit tests, just to make sure it still worked. + +When I finished, I felt pleased with the results. The new version was easy to read, half the size, and more accurate because the original code tested only the upper boundary for the hours, minutes, and seconds. + +While getting ready for work the next day, an idea popped in my head: Why not validate the string using a regular expression? After a few minutes typing, I had a working implementation in just one line of code. Here it is: + +``` +public static boolean validateTime(String time) { + return time.matches("(0[1-9]|1[0-2]):[0-5][0-9]:[0-5][0-9] ([AP]M)"); +} +``` + +The point of this story is not that I eventually replaced over thirty lines of code with just one. The point is that until I got away from the computer, I thought my first attempt was the best solution to the problem. + +So the next time you hit a nasty problem, do yourself a favor. Once you really understand the problem go do something involving the creative side of your brain — sketch out the problem, listen to some music, or just take a walk outside. Sometimes the best thing you can do to solve a problem is to put the mouse down and step away from the keyboard. + +By [BurkHufnagel](http://programmer.97things.oreilly.com/wiki/index.php/BurkHufnagel) \ No newline at end of file diff --git a/fr-IR/thing_70/README.md b/fr-IR/thing_70/README.md new file mode 100644 index 00000000..081aa5aa --- /dev/null +++ b/fr-IR/thing_70/README.md @@ -0,0 +1,13 @@ +# Read Code + +We programmers are weird creatures. We love writing code. But when it comes to reading it we usually shy away. After all, writing code is so much more fun, and reading code is hard — sometimes almost impossible. Reading other people's code is particularly hard. Not necessarily because other people's code is bad, but because they probably think and solve problems in a different way to you. But did you ever consider that reading someone else's code could improve your own? + +The next time you read some code, stop and think for a moment. Is the code easy or hard to read? If it is hard to read, why is that? Is the formatting poor? Is naming inconsistent or illogical? Are several concerns mixed together in the same piece of code? Perhaps the choice of language prohibits the code from being readable? Try to learn from other people's mistakes, so that your code won't contain the same ones. You may receive a few surprises. For example, dependency-breaking techniques may be good for low coupling, but they can sometimes also make code harder to read. And what some people call *elegant code*, others call *unreadable*. + +If the code is easy to read, stop to see if there is something useful you can learn from it. Maybe there's a design pattern in use that you don't know about, or had previously struggled to implement. Perhaps the methods are shorter and their names more expressive than yours. Some open source projects are full of good examples of how to write brilliant, readable code — while others serve as examples of the exact opposite! Check out some of their code and take a look. + +Reading your own old code, from a project you are not currently working on, can also be an enlightening experience. Start with some of your oldest code and work your way forward to the present. You will probably find that it is not at all as easy to read as when you wrote it. Your early code may also have a certain embarrassing entertainment value, kind of in the same way as being reminded of all the things you said when you were drinking in the pub last night. Look at how you have developed your skills over the years — it can be truly motivating. Observe what areas of the code are hard to read, and consider whether you are still writing code in the same way today. + +So the next time you feel the need to improve your programming skills, don't read another book. Read code. + +by [Karianne Berg](http://programmer.97things.oreilly.com/wiki/index.php/Karianne_Berg) \ No newline at end of file diff --git a/fr-IR/thing_71/README.md b/fr-IR/thing_71/README.md new file mode 100644 index 00000000..4d0f58a9 --- /dev/null +++ b/fr-IR/thing_71/README.md @@ -0,0 +1,13 @@ +# Read the Humanities + +In all but the smallest development project people work with people. In all but the most abstracted field of research people write software for people to support them in some goal of theirs. People write software with people for people. It's a people business. Unfortunately what is taught to programmers too often equips them very poorly to deal with people they work for and with. Luckily there is an entire field of study that can help. + +For example, Ludwig Wittgenstein makes a very good case in the *Philosophical Investigations* (and elsewhere) that any language we use to speak to one another is not, cannot be, a serialization format for getting a thought or idea or picture out of one person's head and into another's. Already we should be on our guard against misunderstanding when we "gather requirements." Wittgenstein also shows that our ability to understand one another at all does not arise from shared definitions, it arises from a shared experience, from a form of life. This may be one reason why programmers who are steeped in their problem domain tend to do better than those who stand apart from it. + +Lakoff and Johnson present us with a catalog of *Metaphors We Live By*, suggesting that language is largely metaphorical, and that these metaphors offer an insight into how we understand the world. Even seemingly concrete terms like cash flow, which we might encounter in talking about a financial system, can be seen as metaphorical: "money is a fluid." How does that metaphor influence the way we think about systems that handle money? Or we might talk about layers in a stack of protocols, with some high level and some low level. This is powerfully metaphorical: the user is "up" and the technology is "down." This exposes our thinking about the structure of the systems we build. It can also mark a lazy habit of thought that we might benefit from breaking from time to time. + +Martin Heidegger studied closely the ways that people experience tools. Programmers build and use tools, we think about and create and modify and recreate tools. Tools are objects of interest to us. But for its users, as Heiddeger shows in *Being and Time*, a tool becomes an invisible thing understood only in use. For users tools only become objects of interest when they don't work. This difference in emphasis is worth bearing in mind whenever usability is under discussion. + +Eleanor Rosch overturned the Aristotelean model of the categories by which we organize our understanding of the world. When programmers ask users about their desires for a system we tend to ask for definitions built out of predicates. This is very convenient for us. The terms in the predicates can very easily become attributes on a class or columns in a table. These sorts of categories are crisp, disjoint, and tidy. Unfortunately, as Rosch showed in "Natural Categories" and later works, that just isn't how people in general understand the world. They understand it in ways that are based on examples. Some examples, so-called prototypes, are better than others and so the resulting categories are fuzzy, they overlap, they can have rich internal structure. In so far as we insist on Aristotelean answers we can't ask users the right questions about the user's world, and will struggle to come to the common understanding we need. + +by [Keith Braithwaite](http://programmer.97things.oreilly.com/wiki/index.php/Keith_Braithwaite) \ No newline at end of file diff --git a/fr-IR/thing_72/README.md b/fr-IR/thing_72/README.md new file mode 100644 index 00000000..b21fc6cb --- /dev/null +++ b/fr-IR/thing_72/README.md @@ -0,0 +1,15 @@ +# Reinvent the Wheel Often + +"Just use something that exists — it's silly to reinvent the wheel..." + +Have you ever heard this or some variation thereof? Sure you have! Every developer and student probably hears comments like this frequently. Why though? Why is reinventing the wheel so frowned upon? Because, more often than not, existing code is working code. It has already gone through some sort of quality control, rigorous testing, and is being used successfully. Additionally, the time and effort invested in reinvention are unlikely to pay off as well as using an existing product or code base. Should you bother reinventing the wheel? Why? When? + +Perhaps you have seen publications about patterns in software development, or books on software design. These books can be sleepers regardless of how wonderful the information contained in them is. The same way watching a movie about sailing is very different to going sailing, so too is using existing code versus designing your own software from the ground up, testing it, breaking it, repairing it, and improving it along the way. + +Reinventing the wheel is not just an exercise in where to place code constructs: It is how to get an intimate knowledge of the inner workings of various components that already exist. Do you know how memory managers work? Virtual paging? Could you implement these yourself? How about double-linked lists? Dynamic array classes? ODBC clients? Could you write a graphical user interface that works like a popular one you know and like? Can you create your own web-browser widgets? Do you know when to write a multiplexed system versus a multi-threaded one? How to decide between a file- or a memory-based database? Most developers simply have never created these types of core software implementations themselves and therefore do not have an intimate knowledge of how they work. The consequence is all these kinds of software are viewed as mysterious black boxes that just work. Understanding only the surface of the water is not enough to reveal the hidden dangers beneath. Not knowing the deeper things in software development will limit your ability to create stellar work. + +Reinventing the wheel and getting it wrong is more valuable than nailing it first time. There are lessons learned from trial and error that have an emotional component to them that reading a technical book alone just cannot deliver! + +Learned facts and book smarts are crucial, but becoming a great programmer is as much about acquiring experience as it is about collecting facts. Reinventing the wheel is as important to a developer's education and skill as weight lifting is to a body builder. + +By [Jason P Sage](http://programmer.97things.oreilly.com/wiki/index.php/Jason_P_Sage) \ No newline at end of file diff --git a/fr-IR/thing_73/README.md b/fr-IR/thing_73/README.md new file mode 100644 index 00000000..ecde8923 --- /dev/null +++ b/fr-IR/thing_73/README.md @@ -0,0 +1,25 @@ +# Resist the Temptation of the Singleton Pattern + +The Singleton pattern solves many of your problems. You know that you only need a single instance. You have a guarantee that this instance is initialized before it's used. It keeps your design simple by having a global access point. It's all good. What's not to like about this classic design pattern? + +Quite a lot, it turns out. Tempting they may be, but experience shows that most singletons really do more harm than good. They hinder testability and harm maintainability. Unfortunately, this additional wisdom is not as widespread as it should be and singletons continue to be irresistible to many programmers. But it is worth resisting: + +- The single-instance requirement is often imagined. In many cases it's pure speculation that no additional instances will be needed in the future. Broadcasting such speculative properties across an application's design is bound to cause pain at some point. Requirements will change. Good design embraces this. Singletons don't. + +- Singletons cause implicit dependencies between conceptually independent units of code. This is problematic both because they are hidden and because they introduce unnecessary coupling between units. This code smell becomes pungent when you try to write unit tests, which depend on loose coupling and the ability to selectively substitute a mock implementation for a real one. Singletons prevent such straightforward mocking. + +- Singletons also carry implicit persistent state, which again hinders unit testing. Unit testing depends on tests being independent of one another, so the tests can be run in any order and the program can be set to a known state before the execution of every unit test. Once you have introduced singletons with mutable state, this may be hard to achieve. In addition, such globally accessible persistent state makes it harder to reason about the code, especially in a multi-threaded environment. + +- Multi-threading introduces further pitfalls to the singleton pattern. As straightforward locking on access is not very efficient, the so-called double-checked locking pattern (DCLP) has gained in popularity. Unfortunately, this may be a further form of fatal attraction. It turns out that in many languages DCLP is not thread-safe and, even where it is, there are still opportunities to get it subtly wrong. + +The cleanup of singletons may present a final challenge: + +- There is no support for explicitly killing singletons, which can be a serious issue in some contexts. For example, in a plug-in architecture where a plug-in can only be safely unloaded after all its objects have been cleaned up. + +- There is no order to the implicit cleanup of singletons at program exit. This can be troublesome for applications that contain singletons with interdependencies. When shutting down such applications, one singleton may access another that has already been destroyed. + +- Some of these shortcomings can be overcome by introducing additional mechanisms. However, this comes at the cost of additional complexity in code that could have been avoided by choosing an alternative design. + +Therefore, restrict your use of the Singleton pattern to the classes that truly must never be instantiated more than once. Don't use a singleton's global access point from arbitrary code. Instead, direct access to the singleton should be from only a few well-defined places, from where it can be passed around via its interface to other code. This other code is unaware, and so does not depend on whether a singleton or any other kind of class implements the interface. This breaks the dependencies that prevented unit testing and improves the maintainability. So, next time you are thinking about implementing or accessing a singleton, hopefully you'll pause, and think again. + +by [Sam Saariste](http://programmer.97things.oreilly.com/wiki/index.php/Sam_Saariste) \ No newline at end of file diff --git a/fr-IR/thing_74/README.md b/fr-IR/thing_74/README.md new file mode 100644 index 00000000..57f07fff --- /dev/null +++ b/fr-IR/thing_74/README.md @@ -0,0 +1,13 @@ +# The Road to Performance Is Littered with Dirty Code Bombs + +More often than not, performance tuning a system requires you to alter code. When we need to alter code, every chunk that is overly complex or highly coupled is a dirty code bomb laying in wait to derail the effort. The first casualty of dirty code will be your schedule. If the way forward is smooth it will be easy to predict when you'll finish. Unexpected encounters with dirty code will make it very difficult to make a sane prediction. + +Consider the case where you find an execution hot spot. The normal course of action is to reduce the strength of the underlying algorithm. Let's say you respond to your manager's request for an estimate with an answer of 3-4 hours. As you apply the fix you quickly realize that you've broken a dependent part. Since closely related things are often necessarily coupled, this breakage is most likely expected and accounted for. But what happens if fixing that dependency results in other dependent parts breaking? Furthermore, the farther away the dependency is from the origin, the less likely you are to recognize it as such and account for it in your estimate. All of a sudden your 3-4 hour estimate can easily balloon to 3-4 weeks. Often this unexpected inflation in the schedule happens 1 or 2 days at a time. It is not uncommon to see "quick" refactorings eventually taking several months to complete. In these instances, the damage to the credibility and political capital of the responsible team will range from severe to terminal. If only we had a tool to help us identify and measure this risk. + +In fact, we have many ways of measuring and controlling the degree and depth of coupling and complexity of our code. Software metrics can be used to count the occurrences of specific features in our code. The values of these counts do correlate with code quality. Two of a number of metrics that measure coupling are fan-in and fan-out. Consider fan-out for classes: It is defined as the number of classes referenced either directly or indirectly from a class of interest. You can think of this as a count of all the classes that must be compiled before your class can be compiled. Fan-in, on the other hand, is a count of all classes that depend upon the class of interest. Knowing fan-out and fan-in we can calculate an instability factor using *I = fo / (fi + fo)*. As *I* approaches 0, the package becomes more stable. As *I* approaches 1, the package becomes unstable. Packages that are stable are low risk targets for recoding whereas unstable packages are more likely to be filled with dirty code bombs. The goal in refactoring is to move *I* closer to 0. + +When using metrics one must remember that they are only rules of thumb. Purely on math we can see that increasing *fi* without changing fo will move *I* closer to 0. There is, however, a downside to a very large fan-in value in that these class will be more difficult to alter without breaking dependents. Also, without addressing fan-out you're not really reducing your risks so some balance must be applied. + +One downside to software metrics is that the huge array of numbers that metrics tools produce can be intimidating to the uninitiated. That said, software metrics can be a powerful tool in our fight for clean code. They can help us to identify and eliminate dirty code bombs before they are a serious risk to a performance tuning exercise. + +By [Kirk Pepperdine](http://programmer.97things.oreilly.com/wiki/index.php/Kirk_Pepperdine) \ No newline at end of file diff --git a/fr-IR/thing_75/README.md b/fr-IR/thing_75/README.md new file mode 100644 index 00000000..c7b4f4a0 --- /dev/null +++ b/fr-IR/thing_75/README.md @@ -0,0 +1,19 @@ +# Simplicity Comes from Reduction + +"Do it again...," my boss told me as his finger pressed hard on the delete key. I watched the computer screen with an all too familiar sinking feeling, as my code — line after line — disappeared into oblivion. + +My boss, Stefan, wasn't always the most vocal of people, but he knew bad code when he saw it. And he knew exactly what to do with it. + +I had arrived in my present position as a student programmer with lots of energy, plenty of enthusiasm but absolutely no idea how to code. I had this horrible tendency to think that the solution to every problem was to add in another variable some place. Or throw in another line. On a bad day, instead of the logic getting better with each revision, my code gradually got larger, more complex, and farther away from working consistently. + +It's natural, particularly when in a rush, to just want to make the most minimal changes to an existing block of code, even if it is awful. Most programmers will preserve bad code, fearing that starting anew will require significantly more effort than just going back to the beginning. That can be true for code that is close to working, but there is just some code that is beyond all help. + +More time gets wasted in trying to salvage bad work than it should. Once something becomes a resource sink, it needs to be discarded. Quickly. + +Not that one should easily toss away all of that typing, naming, and formatting. My boss's reaction was extreme, but it did force me to rethink the code on the second (or occasionally third) attempt. Still, the best approach to fixing bad code is to flip into a mode were the code is mercilessly refactored, shifted around, or deleted. + +The code should be simple. There should be a minimal number of variables, functions, declarations, and other syntactic language necessities. Extra lines, extra variables... extra *anything*, really, should be purged. Removed immediately. What's there, what's left, should only be just enough to get the job done, completing the algorithm or performing the calculations. Anything and everything else is just extra unwanted noise, introduced accidentally and obscuring the flow. Hiding the important stuff. + +Of course, if that doesn't do it then just delete it all and type it in over again. Drawing from one's memory in that way can often help cut through a lot of unnecessarily clutter. + +By [Paul W. Homer](http://programmer.97things.oreilly.com/wiki/index.php/Paul_W._Homer) \ No newline at end of file diff --git a/fr-IR/thing_76/README.md b/fr-IR/thing_76/README.md new file mode 100644 index 00000000..6929cc1b --- /dev/null +++ b/fr-IR/thing_76/README.md @@ -0,0 +1,41 @@ +# The Single Responsibility Principle + +One of the most foundational principles of good design is: + +> Gather together those things that change for the same reason, and separate those things that change for different reasons. + +This principle is often known as the *Single Responsibility Principle* or SRP. In short, it says that a subsystem, module, class, or even a function, should not have more than one reason to change. The classic example is a class that has methods that deal with business rules, reports, and database: + +``` +public class Employee { + public Money calculatePay() ... + public String reportHours() ... + public void save() ... +} +``` + +Some programmers might think that putting these three functions together in the same class is perfectly appropriate. After all, classes are supposed to be collections of functions that operate on common variables. However, the problem is that the three functions change for entirely different reasons. The `calculatePay` function will change whenever the business rules for calculating pay change. The `reportHours` function will change whenever someone wants a different format for the report. The save function will change whenever the DBAs change the database schema. These three reasons to change combine to make `Employee` very volatile. It will change for any of those reasons. More importantly, any classes that depend upon `Employee` will be affected by those changes. + +Good system design means that we separate the system into components that can be independently deployed. Independent deployment means that if we change one component we do not have to redeploy any of the others. However, if `Employee` is heavily used by many other classes in other components, then every change to Employee is likely to cause the other components to be redeployed; thus negating a major benefit of component design (or SOA if you prefer the more trendy name). + +``` +public class Employee { + public Money calculatePay() ... +} + +public class EmployeeReporter { + public String reportHours(Employee e) ... +} + +public class EmployeeRepository { + public void save(Employee e) ... +} +``` + +The simple partitioning shown above resolves the issues. Each of these classes can be placed in a component of its own. Or rather, all the reporting classes can go into the reporting component. All the database related classes can go into the repository component. And all the business rules can go into the business rule component. + +The astute reader will see that there are still dependencies in the above solution. That `Employee` is still depended upon by the other classes. So if `Employee` is modified, the other classes will likely have to be recompiled and redeployed. Thus, `Employee` cannot be modified and then independently deployed. However, the other classes can be modified and independently deployed. No modification of one of them can force any of the others to be recompiled or redeployed. Even `Employee` could be independently deployed through a careful use of the *Dependency Inversion Principle* (DIP), but that's a topic for a [different book](http://www.amazon.com/dp/0135974445/). + +Careful application of the SRP, separating things that change for different reasons, is one of the keys to creating designs that have an independently deployable component structure. + +by [Uncle Bob](http://programmer.97things.oreilly.com/wiki/index.php/Uncle_Bob) diff --git a/fr-IR/thing_77/README.md b/fr-IR/thing_77/README.md new file mode 100644 index 00000000..41002b4b --- /dev/null +++ b/fr-IR/thing_77/README.md @@ -0,0 +1,23 @@ +# Start from Yes + +Recently I was at a grocery store searching high and low for "edamame" (which I only vaguely knew was some kind of a vegetable). I wasn't sure whether this was something I'd find in the vegetable section, the frozen section, or in a can. I gave up and tracked down an employee to help me out. She didn't know either! + +The employee could have responded in many different ways. She could have made me feel ignorant for not knowing where to look, or given me vague possibilities, or even just told me they didn't have the item. But instead she treated the request as an opportunity to find a solution and help a customer. She called other employees and within minutes had guided me to the exact item, nestled in the frozen section. + +The employee in this case looked at a request and started from the premise that we would solve the problem and satisfy the request. She started from *yes* instead of starting from no. + +When I was first placed in a technical leadership role, I felt that my job was to protect my beautiful software from the ridiculous stream of demands coming from product managers and business analysts. I started most conversations seeing a request as something to defeat, not something to grant. + +At some point, I had an epiphany that maybe there was a different way to work that merely involved shifting my perspective from starting at no to starting at *yes*. In fact, I've come to believe that starting from *yes* is actually an essential part of being a technical leader. + +This simple change radically altered how I approached my job. As it turns out, there are a lot of ways to say *yes*. When someone says to you "Hey, this app would really be the bees knees if we made all the windows round and translucent!" you could reject it as ridiculous. But it's often better to start with "Why?" instead. Often there is some actual and compelling reason why that person is asking for round translucent windows in the first place. For example, you may be just about to sign a big new customer with a standards committee that mandates round translucent windows. + +Usually you'll find that when you known the context of the request, new possibilities open up. It's common for the request to be accomplished with the existing product in some other way allowing you to say *yes* with no work at all: "Actually, in the user preferences you can download the round translucent windows skin and turn it on." + +Sometimes the other person will simply have an idea that you find incompatible with your view of the product. I find it's usually helpful to turn that "Why?" on yourself. Sometimes the act of voicing the reason will make it clear that your first reaction doesn't make sense. If not, you might need to kick it up a notch and bring in other key decision makers. Remember, the goal of all of this is to say *yes* to the other person and try to make it work, not just for him but for you and your team as well. + +If you can voice a compelling explanation as to why the feature request is incompatible with the existing product, then you are likely to have a productive conversation about whether you are building the right product. Regardless of how that conversation concludes, everyone will focus more sharply on what the product is, and what it is not. + +Starting from *yes* means working with your colleagues, not against them. + +By [Alex Miller](http://programmer.97things.oreilly.com/wiki/index.php/Alex_Miller) \ No newline at end of file diff --git a/fr-IR/thing_78/README.md b/fr-IR/thing_78/README.md new file mode 100644 index 00000000..735b373b --- /dev/null +++ b/fr-IR/thing_78/README.md @@ -0,0 +1,29 @@ +# Step Back and Automate, Automate, Automate + +I worked with programmers who, when asked to produce a count of the lines of code in a module, pasted the files into a word processor and used its "line count" feature. And they did it again next week. And the week after. It was bad. + +I worked on a project that had a cumbersome deployment process, involving code signing and moving the result to a server, requiring many mouse clicks. Someone automated it and the script ran hundreds of times during final testing, far more often than anticipated. It was good. + +So, why do people do the same task over and over instead of stepping back and taking the time to automate it? + +## Common misconception #1: Automation is only for testing. + +Sure, test automation is great, but why stop there? Repetitive tasks abound in any project: version control, compiling, building JAR files, documentation generation, deployment, and reporting. For many of these tasks, the script is mightier than the mouse. Executing tedious tasks becomes faster and more reliable. + +## Common misconception #2: I have an IDE, so I don't have to automate. + +Did you ever have a "But it (checks out|builds|passes tests) on my machine?" argument with your teammates? Modern IDEs have thousands of potential settings, and it is essentially impossible to ensure that all team members have identical configurations. Build automation systems such as Ant or Autotools give you control and repeatability. + +## Common misconception #3: I need to learn exotic tools in order to automate. + +You can go a long way with a decent shell language (such as bash or PowerShell) and a build automation system. If you need to interact with web sites, use a tool such as iMacros or Selenium. + +## Common misconception #4: I can't automate this task because I can't deal with these file formats. + +If a part of your process requires Word documents, spreadsheets, or images, it may indeed be challenging to automate it. But is that really necessary? Can you use plain text? Comma-separated values? XML? A tool that generates a drawing from a text file? Often, a slight tweak in the process can yield good results with a dramatic reduction in tediousness. + +## Common misconception #5: I don't have the time to figure it out. + +You don't have to learn all of bash or Ant to get started. Learn as you go. When you have a task that you think can and should be automated, learn just enough about your tools to do it. And do it early in a project when time is usually easier to find. Once you have been successful, you (and your boss) will see that it makes sense to invest in automation. + +By [Cay Horstmann](http://programmer.97things.oreilly.com/wiki/index.php/Cay_Horstmann) diff --git a/fr-IR/thing_79/README.md b/fr-IR/thing_79/README.md new file mode 100644 index 00000000..0a7c883c --- /dev/null +++ b/fr-IR/thing_79/README.md @@ -0,0 +1,13 @@ +# Take Advantage of Code Analysis Tools + +The value of testing is something that is drummed into software developers from the early stages of their programming journey. In recent years the rise of unit testing, test-driven development, and agile methods has seen a surge of interest in making the most of testing throughout all phases of the development cycle. However, testing is just one of many tools that you can use to improve the quality of code. + +Back in the mists of time, when C was still a new phenomenon, CPU time and storage of any kind were at a premium. The first C compilers were mindful of this and so cut down on the number of passes through the code they made by removing some semantic analyses. This meant that the compiler checked for only a small subset of the bugs that could be detected at compile time. To compensate, Stephen Johnson wrote a tool called *lint* — which removes the fluff from your code — that implemented some of the static analyses that had been removed from its sister C compiler. Static analysis tools, however, gained a reputation for giving large numbers of false-positive warnings and warnings about stylistic conventions that aren't always necessary to follow. + +The current landscape of languages, compilers, and static analysis tools is very different. Memory and CPU time are now relatively cheap, so compilers can afford to check for more errors. Almost every language boasts at least one tool that checks for violations of style guides, common gotchas, and sometimes cunning errors that can be difficult to catch, such as potential null pointer dereferences. The more sophisticated tools, such as Splint for C or Pylint for Python, are configurable, meaning that you can choose which errors and warnings the tool emits with a configuration file, via command line switches, or in your IDE. Splint will even let you annotate your code in comments to give it better hints about how your program works. + +If all else fails, and you find yourself looking for simple bugs or standards violations which are not caught by your compiler, IDE, or lint tools, then you can always roll your own static checker. This is not as difficult as it might sound. Most languages, particularly ones branded *dynamic*, expose their abstract syntax tree and compiler tools as part of their standard library. It is well worth getting to know the dusty corners of standard libraries that are used by the development team of the language you are using, as these often contain hidden gems that are useful for static analysis and dynamic testing. For example, the Python standard library contains a disassembler which tells you the bytecode used to generate some compiled code or code object. This sounds like an obscure tool for compiler writers on the python-dev team, but it is actually surprisingly useful in everyday situations. One thing this library can disassemble is your last stack trace, giving you feedback on exactly which bytecode instruction threw the last uncaught exception. + +So, don't let testing be the end of your quality assurance — take advantage of analysis tools and don't be afraid to roll your own. + +By [Sarah Mount](http://programmer.97things.oreilly.com/wiki/index.php/Sarah_Mount) \ No newline at end of file diff --git a/fr-IR/thing_80/README.md b/fr-IR/thing_80/README.md new file mode 100644 index 00000000..b07f1bff --- /dev/null +++ b/fr-IR/thing_80/README.md @@ -0,0 +1,15 @@ +# Test for Required Behavior, not Incidental Behavior + +A common pitfall in testing is to assume that exactly what an implementation does is precisely what you want to test for. At first glance this sounds more like a virtue than a pitfall. Phrased another way, however, the issue becomes more obvious: A common pitfall in testing is to hardwire tests to the specifics of an implementation, where those specifics are incidental and have no bearing on the desired functionality. + +When tests are hardwired to implementation incidentals, changes to the implementation that are actually compatible with the required behavior may cause tests to fail, leading to false positives. Programmers typically respond either by rewriting the test or by rewriting the code. Assuming that a false positive is actually a true positive is often a consequence of fear, uncertainty, or doubt. It has the effect of raising the status of incidental behavior to required behavior. In rewriting a test, programmers either refocus the test on the required behavior (good) or simply hardwire it to the new implementation (not good). Tests need to be sufficiently precise, but they also need to be accurate. + +For example, in a three-way comparison, such as C's `strcmp` or Java's `String.compareTo`, the requirements on the result are that it is negative if the left-hand side is less than the right, positive if the left-hand side is greater than the right, and zero if they are considered equal. This style of comparison is used in many APIs, including the comparator for C's `qsort` function and `compareTo` in Java's `Comparable` interface. Although the specific values `-1` and `+1` are commonly used in implementations to signify *less than* and *greater than*, respectively, programmers often mistakenly assume that these values represent the actual requirement and consequently write tests that nail this assumption up in public. + +A similar issue arises with tests that assert spacing, precise wording, and other aspects of textual formatting and presentation that are incidental. Unless you are writing, for example, an XML generator that offers configurable formatting, spacing should not be significant to the outcome. Likewise, hardwiring placement of buttons and labels on UI controls reduces the option to change and refine these incidentals in future. Minor changes in implementation and inconsequential changes in formatting suddenly become build breakers. + +Overspecified tests are often a problem with whitebox approaches to unit testing. Whitebox tests use the structure of the code to determine the test cases needed. The typical failure mode of whitebox testing is that the tests end up asserting that the code does what the code does. Simply restating what is already obvious from the code adds no value and leads to a false sense of progress and security. + +To be effective, tests need to state contractual obligations rather than parrot implementations. They need to take a blackbox view of the units under test, sketching out the interface contracts in executable form. Therefore, align tested behavior with required behavior. + +By [Kevlin Henney](http://programmer.97things.oreilly.com/wiki/index.php/Kevlin_Henney) \ No newline at end of file diff --git a/fr-IR/thing_81/README.md b/fr-IR/thing_81/README.md new file mode 100644 index 00000000..b8388bdb --- /dev/null +++ b/fr-IR/thing_81/README.md @@ -0,0 +1,45 @@ +# Test Precisely and Concretely + +It is important to test for the desired, essential behavior of a unit of code, rather than test for the incidental behavior of its particular implementation. But this should not be taken or mistaken as an excuse for vague tests. Tests need to be both accurate *and* precise. + +Something of a tried, tested, and testing classic, sorting routines offer an illustrative example. Implementing a sorting algorithm is not necessarily an everyday task for a programmer, but sorting is such a familiar idea that most people believe they know what to expect from it. This casual familiarity, however, can make it harder to see past certain assumptions. + +When programmers are asked "What would you test for?" by far and away the most common response is "The result of sorting is a sorted sequence of elements." While this is true, it is not the whole truth. When prompted for a more precise condition, many programmers add that the resulting sequence should be the same length as the original. Although correct, this is still not enough. For example, given the following sequence: + +``` +3 1 4 1 5 9 +``` + +The following sequence satisfies a postcondition of being sorted in non-descending order and having the same length as the original sequence: + +``` +3 3 3 3 3 3 +``` + +Although it satisfies the spec, it is also most certainly not what was meant! This example is based on an error taken from real production code (fortunately caught before it was released), where a simple slip of a keystroke or a momentary lapse of reason led to an elaborate mechanism for populating the whole result with the first element of the given array. + +The full postcondition is that the result is sorted and that it holds a permutation of the original values. This appropriately constrains the required behavior. That the result length is the same as the input length comes out in the wash and doesn't need restating. + +Even stating the postcondition in the way described is not enough to give you a good test. A good test should be readable. It should be comprehensible and simple enough that you can see readily that it is correct (or not). Unless you already have code lying around for checking that a sequence is sorted and that one sequence contains a permutation of values in another, it is quite likely that the test code will be more complex than the code under test. As Tony Hoare observed: + +> There are two ways of constructing a software design: One way is to make it so simple that there are *obviously* no deficiencies and the other is to make it so complicated that there are no obvious deficiencies. + +Using concrete examples eliminates this accidental complexity and opportunity for accident. For example, given the following sequence: + +``` +3 1 4 1 5 9 +``` + +The result of sorting is the following: + +``` +1 1 3 4 5 9 +``` + +No other answer will do. Accept no substitutes. + +Concrete examples helps to illustrate general behavior in an accessible and unambiguous way. The result of adding an item to an empty collection is not simply that it is not empty: It is that the collection now has a single item. And that the single item held is the item added. Two or more items would qualify as not empty. And would also be wrong. A single item of a different value would also be wrong. The result of adding a row to a table is not simply that the table is one row bigger. It also entails that the row's key can be used to recover the row added. And so on. + +In specifying behavior, tests should not simply be accurate: They must also be precise. + +By [Kevlin Henney](http://programmer.97things.oreilly.com/wiki/index.php/Kevlin_Henney) \ No newline at end of file diff --git a/fr-IR/thing_82/README.md b/fr-IR/thing_82/README.md new file mode 100644 index 00000000..9f171cc6 --- /dev/null +++ b/fr-IR/thing_82/README.md @@ -0,0 +1,15 @@ +# Test While You Sleep (and over Weekends) + +Relax. I am not referring to offshore development centers, overtime on weekends, or working the night shift. Rather, I want to draw your attention to how much computing power we have at our disposal. Specifically, how much we are not harnessing to make our lives as programmers a little easier. Are you constantly finding it difficult to get enough computing power during the work day? If so, what are your test servers doing outside of normal work hours? More often than not, the test servers are idling overnight and over the weekend. You can use this to your advantage. + +- *Have you been guilty of committing a change without running all the tests?* One of the main reasons programmers don't run test suites before committing code is because of the length of time they may take. When deadlines are looming and push comes to shove, humans naturally start cutting corners. One way to address this is to break down your large test suite into two or more profiles. A smaller, mandatory test profile that is quick to run, will help to ensure that tests are run before each commit. All of the test profiles (including the mandatory profile — just to be sure) can be automated to run overnight, ready to report their results in the morning. + +- *Have you had enough opportunity to test the stability of your product?* Longer-running tests are vital for identifying memory leaks and other stability issues. They are seldom run during the day as it will tie up time and resources. You could automate a soak test to be run during the night, and a bit longer over the weekend. From 6.00 pm Friday to 6.00 am the following Monday there are 60 hours worth of potential testing time. + +- *Are you getting quality time on your Performance testing environment?* I have seen teams bickering with each other to get time on the performance testing environment. In most cases neither team gets enough quality time during the day, while the environment is virtually idle after hours. The servers and the network are not as busy during the night or over the weekend. It's an ideal time to run some quality performance tests. + +- *Are there too many permutations to test manually?* In many cases your product is targeted to run on a variety of platforms. For example, both 32-bit and 64-bit, on Linux, Solaris, and Windows, or simply on different versions of the same operating system. To make matters worse, many modern applications expose themselves to a plethora of transport mechanisms and protocols (HTTP, AMQP, SOAP, CORBA, etc.). Manually testing all of these permutations is very time consuming and most likely done close to a release due to resource pressure. Alas, it may be too late in the cycle to catch certain nasty bugs. + +Automated tests run during the night or over weekends will ensure all these permutations are tested more often. With a little bit of thinking and some scripting knowledge, you can schedule a few *cron* jobs to kick off some testing at night and over the weekend. There are also many testing tools out there that could help. Some organizations even have server grids that pool servers across different departments and teams to ensure that resources are utilized efficiently. If this is available in your organization, you can submit tests to be run at night or over weekends. + +by [Rajith Attapattu](http://programmer.97things.oreilly.com/wiki/index.php/Rajith_Attapattu) \ No newline at end of file diff --git a/fr-IR/thing_83/README.md b/fr-IR/thing_83/README.md new file mode 100644 index 00000000..c3fe3d09 --- /dev/null +++ b/fr-IR/thing_83/README.md @@ -0,0 +1,11 @@ +# Testing Is the Engineering Rigor of Software Development + +Developers love to use tortured metaphors when trying to explain what it is they do to family members, spouses, and other non-techies. We frequently resort to bridge building and other "hard" engineering disciplines. All these metaphors fall down quickly, though, when you start trying to push them too hard. It turns out that software development is *not* like many of the "hard" engineering disciplines in lots of important ways. + +Compared to "hard" engineering, the software development world is at about the same place the bridge builders were when the common strategy was to build a bridge and then roll something heavy over it. If it stayed up, it was a good bridge. If not, well, time to go back to the drawing board. Over the past few thousand years, engineers have developed mathematics and physics they can use for a structural solution without having to build it to see what it does. We don't have anything like that in software, and perhaps never will because software is in fact very different. For a deep-dive exploration of the comparison between software "engineering" and regular engineering, ["What is Software Design?"](http://www.developerdotstar.com/mag/articles/reeves_design.html), written by Jack Reeves in *C++ Journal* in 1992, is a classic. Even though it was written almost two decades ago, it is still remarkably accurate. He painted a gloomy picture in this comparison, but the thing that was missing in 1992 was a strong testing ethos for software. + +Testing "hard" things is tough because you have to build them to test them, which discourages speculative building just to see what will happen. But the building process in software is ridiculously cheap. We've developed an entire ecosystem of tools that make it easy to do just that: unit testing, mock objects, test harnesses, and lots of other stuff. Other engineers would love to be able to build something and test it under realistic conditions. As software developers, we should embrace testing as the primary (but not the only) verification mechanism for software. Rather than waiting for some sort of calculus for software, we already have the tools at our disposal to ensure good engineering practices. Viewed in this light, we now have ammunition against managers who tell us "We don't have time to test." A bridge builder would never hear from their boss "Don't bother doing structural analysis on that building — we have a tight deadline." The recognition that testing is indeed the path to reproducibility and quality in software allows us as developers to push back on arguments against it as professionally irresponsible. + +Testing takes time, just like structural analysis takes time. Both activities ensure the quality of the end product. It's time for software developers to take up the mantle of responsibility for what they produce. Testing alone isn't sufficient, but it is necessary. Testing * **is** * the engineering rigor of software development. + +By [Neal Ford](http://programmer.97things.oreilly.com/wiki/index.php/Neal_Ford) \ No newline at end of file diff --git a/fr-IR/thing_84/README.md b/fr-IR/thing_84/README.md new file mode 100644 index 00000000..687c0b96 --- /dev/null +++ b/fr-IR/thing_84/README.md @@ -0,0 +1,39 @@ +# Thinking in States + +People in the real world have a weird relationship with state. This morning I stopped by the local store to prepare for another day of converting caffeine to code. Since my favorite way of doing that is by drinking latte, and I couldn't find any milk, I asked the clerk. + +"Sorry, we're super-duper, mega-out of milk." + +To a programmer, that's an odd statement. You're either out of milk or you're not. There is no scale when it comes to being out of milk. Perhaps she was trying to tell me that they'd be out of milk for a week, but the outcome was the same — espresso day for me. + +In most real-world situations, people's relaxed attitude to state is not an issue. Unfortunately, however, many programmers are quite vague about state too — and that is a problem. + +Consider a simple webshop that only accepts credit cards and does not invoice customers, with an `Order` class containing this method: + +``` + public boolean isComplete() { + return isPaid() && hasShipped(); + } +``` + +Reasonable, right? Well, even if the expression is nicely extracted into a method instead of copy'n'pasted everywhere, the expression shouldn't exist at all. The fact that it does highlights a problem. Why? Because an order can't be shipped before it's paid. Thereby, `hasShipped` can't be true unless `isPaid` is true, which makes part of the expression redundant. You may still want `isComplete` for clarity in the code, but then it should look like this: + +``` + public boolean isComplete() { + return hasShipped(); + } +``` + +In my work, I see both missing checks and redundant checks all the time. This example is tiny, but when you add cancellation and repayment, it'll become more complex and the need for good state handling increases. In this case, an order can only be in one of three distinct states: + +- *In progress:* Can add or remove items. Can't ship. +- *Paid:* Can't add or remove items. Can be shipped. +- *Shipped:* Done. No more changes accepted. + +These states are important and you need to check that you're in the expected state before doing operations, and that you only move to a legal state from where you are. In short, you have to protect your objects carefully, in the right places. + +But how do you begin thinking in states? Extracting expressions to meaningful methods is a very good start, but it is just a start. The foundation is to understand state machines. I know you may have bad memories from CS class, but leave them behind. State machines are not particularly hard. Visualize them to make them simple to understand and easy to talk about. Test-drive your code to unravel valid and invalid states and transitions and to keep them correct. Study the State pattern. When you feel comfortable, read up on Design by Contract. It helps you ensure a valid state by validating incoming data and the object itself on entry and exit of each public method. + +If your state is incorrect, there's a bug and you risk trashing data if you don't abort. If you find the state checks to be noise, learn how to use a tool, code generation, weaving, or aspects to hide them. Regardless of which approach you pick, thinking in states will make your code simpler and more robust. + +By [Niclas Nilsson](http://programmer.97things.oreilly.com/wiki/index.php/Niclas_Nilsson) \ No newline at end of file diff --git a/fr-IR/thing_85/README.md b/fr-IR/thing_85/README.md new file mode 100644 index 00000000..aed4fecb --- /dev/null +++ b/fr-IR/thing_85/README.md @@ -0,0 +1,23 @@ +# Two Heads Are Often Better than One + +Programming requires deep thought, and deep thought requires solitude. So goes the programmer stereotype. + +This "lone wolf" approach to programming has been giving way to a more collaborative approach, which, I would argue, improves quality, productivity, and job satisfaction for programmers. This approach has developers working more closely with each other and also with non-developers — business and systems analysts, quality assurance professionals, and users. + +What does this mean for developers? Being the expert technologist is no longer sufficient. You must become effective at working with others. + +Collaboration is not about asking and answering questions or sitting in meetings. It's about rolling up your sleeves with someone else to jointly attack work. + +I'm a big fan of pair programming. You might call this "extreme collaboration." As a developer, my skills grow when I pair. If I am weaker than my pairing partner in the domain or technology, I clearly learn from his or her experience. When I am stronger in some aspect, I learn more about what I know and don't know by having to explain myself. Invariably, we both bring something to the table and learn from each other. + +When pairing, we each bring our collective programming experiences — domain as well as technical — to the problem at hand and can bring unique insight and experience into writing software effectively and efficiently. Even in cases of extreme imbalance in domain or technical knowledge, the more experienced participant invariably learns something from the other — perhaps a new keyboard shortcut, or exposure to a new tool or library. For the less-experienced member of the pair, this is a great way to get up to speed. + +Pair programming is popular with, though not exclusive to, proponents of agile software development. Some who object to pairing suggest "Why should I pay two programmers to do the work of one?" My response is that, indeed, you should not. I argue that pairing increases quality, understanding of the domain and technology, techniques (like IDE tricks), and mitigates the impact of lottery risk (one of your expert developers wins the lottery and quits the next day). + +What is the long-term value of learning a new keyboard shortcut? How do we measure the overall quality improvement to the product resulting from pairing? How do we measure the impact of your partner not letting you pursue a dead-end approach to solving a difficult problem? One study cites an increase of 40% in effectiveness and speed (J T Nosek, "The Case for Collaborative Programming," *Communications of the ACM*, March 1998). What is the value of mitigating your "lottery risk?" Most of these gains are difficult to measure. + +Who should pair with whom? If you're new to the team, it's important to find a team member who is knowledgeable. Just as important find someone who has good interpersonal and coaching skills. If you don't have much domain experience, pair with a team member who is an expert in the domain. + +If you are not convinced, experiment: collaborate with your colleagues. Pair on an interesting, gnarly problem. See how it feels. Try it a few times. + +By [Adrian Wible](http://programmer.97things.oreilly.com/wiki/index.php/Adrian_Wible) \ No newline at end of file diff --git a/fr-IR/thing_86/README.md b/fr-IR/thing_86/README.md new file mode 100644 index 00000000..6caa5af9 --- /dev/null +++ b/fr-IR/thing_86/README.md @@ -0,0 +1,23 @@ +# Two Wrongs Can Make a Right (and Are Difficult to Fix) + +Code never lies, but it can contradict itself. Some contradictions lead to those "How can that possibly work?" moments. + +In an [interview](http://www.netjeff.com/humor/item.cgi?file=ApolloComputer), the principal designer of the Apollo 11 Lunar Module software, Allan Klumpp, disclosed that the software controlling the engines contained a bug that should have made the lander unstable. However, another bug compensated for the first and the software was used for both Apollo 11 and 12 Moon landings before either bug was found or fixed. + +Consider a function that returns a completion status. Imagine that it returns false when it should return true. Now imagine the calling function neglects to check the return value. Everything works fine until one day someone notices the missing check and inserts it. + +Or consider an application that stores state as an XML document. Imagine that one of the nodes in incorrectly written as `TimeToLive` instead of `TimeToDie`, as the documentation says it should. Everything appears fine while the writer code and the reader code both contain the same error. But fix one, or add a new application reading the same document, and the symmetry is broken, as well as the code. + +When two defects in the code create one visible fault, the methodical approach to fixing faults can itself break down. The developer gets a bug report, finds the defect, fixes it, and retests. The reported fault still occurs, however, because a second defect is at work. So the first fix is removed, the code inspected until the second underlying defect is found, and a fix applied for that. But the first defect has returned, the reported fault is still seen, and so the second fix is rolled back. The process repeats but now the developer has dismissed two possible fixes and is looking to make a third that will never work. + +The interplay between two code defects that appear as one visible fault not only makes it hard to fix the problem but leads developers down blind alleys, only to find they tried the right answers early on. + +This doesn't happen only in code: The problem also exists in written requirements documents. And it can spread, virally, from one place to another. An error in the code compensates for an error in the written description. + +It can spread to people too: Users learn that when the application says Left it means Right, so they adjust their behavior accordingly. They even pass it on to new users: "Remember when that applications says click the left button it really means the button on the right." Fix the bug and suddenly the users need retraining. + +Single wrongs can be easy to spot and easy to fix. It is the problems with multiple causes, needing multiple changes, that are harder to resolve. In part it is because easy problems are so easily fixed that people tend to fix them relatively quickly and store up the more difficult problems for a later date. + +There is no simple advice to give on how to address faults arising from sympathetic defects. Awareness of the possibility, a clear head, and a willingness to consider all possibilities are needed. + +By [Allan Kelly](http://programmer.97things.oreilly.com/wiki/index.php/Allan_Kelly) \ No newline at end of file diff --git a/fr-IR/thing_87/README.md b/fr-IR/thing_87/README.md new file mode 100644 index 00000000..1a82b37c --- /dev/null +++ b/fr-IR/thing_87/README.md @@ -0,0 +1,15 @@ +# Ubuntu Coding for Your Friends + +So often we write code in isolation and the code reflects our personal interpretation of a problem, as well as a very personalized solution. We may be part of the team, yet we are isolated, as is the team. We forget all too easily that this code created in isolation will be executed, used, extended, and relied upon by others. It is easy to overlook the social side of software creation. Creating software is a technical exercise mixed into a social exercise. We just need to lift our heads more often to realize that we are not working in isolation, and we have shared responsibility towards increasing the probability of success for everyone, not just the development team. + +You can write good quality code in isolation, all the while lost in self. From one perspective, that is an egocentric approach (not *ego* as in arrogant, but *ego* as in personal). It is also a Zen view and it is about you, in that moment of creating code. I always try to live in the moment because it helps me get closer to good quality, but then I live in *my* moment. What about the moment of my team? Is my moment the same as the team's moment? + +In Zulu, the philosophy of Ubuntu is summed up as "Umuntu ngumuntu ngabantu" which roughly translates to "A person is a person through (other) persons." I get better because you make me better through your good actions. The flip side is that you get worse at what you do when I am bad at what I do. Among developers, we can narrow it down to "A developer is a developer through (other) developers." If we take it down to the metal, then "Code is code through (other) code." + +The quality of the code I write affects the quality of the code you write. What if my code is of poor quality? Even if you write very clean code, it is the points where you use my code that your code quality will degrade to close to the quality of my code. You can apply many patterns and techniques to limit the damage, but the damage has already been done. I have caused you to do more than what you needed to do simply because I did not think about you when I was living in my moment. + +I may consider my code to be clean, but I can still make it better just by Ubuntu coding. What does Ubuntu code look like? It looks just like good clean code. It is not about the code, the artifact. It is about the act of creating that artifact. Coding for your friends, with Ubuntu, will help your team live your values and reinforce your principles. The next person that touches your code, in whatever way, will be a better person and a better developer. + +Zen is about the individual. Ubuntu is about Zen for a group of people. Very, very rarely do we create code for ourselves alone. + +By [Aslam Khan](http://programmer.97things.oreilly.com/wiki/index.php/Aslam_Khan) \ No newline at end of file diff --git a/fr-IR/thing_88/README.md b/fr-IR/thing_88/README.md new file mode 100644 index 00000000..4c2aa947 --- /dev/null +++ b/fr-IR/thing_88/README.md @@ -0,0 +1,31 @@ +# The Unix Tools Are Your Friends + +If on my way to exile on a desert island I had to choose between an IDE and the Unix toolchest, I'd pick the Unix tools without a second thought. Here are the reasons why you should become proficient with Unix tools. + +First, IDEs target specific languages, while Unix tools can work with anything that appears in textual form. In today's development environment where new languages and notations spring up every year, learning to work in the Unix way is an investment that will pay off time and again. + +Furthermore, while IDEs offer just the commands their developers conceived, with Unix tools you can perform any task you can imagine. Think of them as (classic pre-Bionicle) Lego blocks: You create your own commands simply by combining the small but versatile Unix tools. For instance, the following sequence is a text-based implementation of Cunningham's signature analysis — a sequence of each file's semicolons, braces, and quotes, which can reveal a lot about the file's contents. + +``` +for i in *.java; do + echo -n "$i: " + sed 's/[^"{};]//g' $i | tr -d '\n' + echo +done +``` + +In addition, each IDE operation you learn is specific to that given task; for instance, adding a new step in a project's debug build configuration. By contrast, sharpening your Unix tool skills makes you more effective at any task. As an example, I've employed the sed tool used in the preceding command sequence to morph a project's build for cross-compiling on multiple processor architectures. + +Unix tools were developed in an age when a multiuser computer had 128kB of RAM. The ingenuity that went into their design means that nowadays they can handle huge data sets extremely efficiently. Most tools work like filters, processing just a single line at the time, meaning that there is no upper limit in the amount of data they can handle. You want to search for the number of edits stored in the half-terabyte English Wikipedia dump? A simple invocation of + +``` +grep '' | wc –l +``` + +will give you the answer without sweat. If you find a command sequence generally useful, you can easily package it into a shell script, using some uniquely powerful programming constructs, such as piping data into loops and conditionals. Even more impressively, Unix commands executing as pipelines, like the preceding one, will naturally distribute their load among the many processing units of modern multicore CPUs. + +The small-is-beautiful provenance and open source implementations of the Unix tools make them ubiquitously available, even on resource-constrained platforms, like my set-top media player or DSL router. Such devices are unlikely to offer a powerful graphical user interface, but they often include the BusyBox application, which provides the most commonly-used tools. And if you are developing on Windows, the Cygwin environment offers you all imaginable Unix tools, both as executables and in source code form. + +Finally, if none of the available tools match your needs, it's very easy to extend the world of the Unix tools. Just write a program (in any language you fancy) that plays by a few simple rules: Your program should perform just a single task; it should read data as text lines from its standard input; and it should display its results unadorned by headers and other noise on its standard output. Parameters affecting the tool's operation are given in the command line. Follow these rules and "yours is the Earth and everything that's in it." + +By [Diomidis Spinellis](http://programmer.97things.oreilly.com/wiki/index.php/Diomidis_Spinellis) \ No newline at end of file diff --git a/fr-IR/thing_89/README.md b/fr-IR/thing_89/README.md new file mode 100644 index 00000000..0b79cbba --- /dev/null +++ b/fr-IR/thing_89/README.md @@ -0,0 +1,37 @@ +# Use the Right Algorithm and Data Structure + +> A big bank with many branch offices complained that the new computers it had bought for the tellers were too slow. This was in the time before everyone used electronic banking and ATMs were not as widespread as they are now. People would visit the bank far more often, and the slow computers were making the people queue up. Consequently, the bank threatened to break its contract with the vendor. + +> The vendor sent a performance analysis and tuning specialist to determine the cause of the delays. He soon found one specific program running on the terminal consuming almost all the CPU capacity. Using a profiling tool, he zoomed in on the program and he could see the function that was the culprit. The source code read: + +> ``` +> for (i=0; i if (... s[i] ...) ... +> } +> ``` + +> And string s was, on average, thousands of characters long. The code (written by the bank) was quickly changed, and the bank tellers lived happily ever after.... + +Shouldn't the programmer have done better than to use code that needlessly scaled quadratically? +Each call to strlen traversed every one of the many thousand characters in the string to find its terminating null character. The string, however, never changed. By determining its length in advance, the programmer could have saved thousands of calls to strlen (and millions of loop executions): + +``` +n=strlen(s); +for (i=0; i allCustomers = new ArrayList(); + // ... + public ArrayList findCustomersThatSpendAtLeast(Money amount) { + ArrayList customersOfInterest = new ArrayList(); + for (Customer customer: allCustomers) { + if (customer.spendsAtLeast(amount)) + customersOfInterest.add(customer); + } + return customersOfInterest; + } +} +``` + +By exposing this raw collection to clients, we have violated encapsulation. This not only limits our ability to refactor, it forces users of our code to violate DRY by having each of them re-implement potentially the same query. This situation can easily be avoided by removing the exposed raw collections from the API. In this example we can introduce a new, domain-specific collective type called `CustomerList`. This new class is more semantically in line with our domain. It will act as a natural home for all our queries. + +Having this new collection type will also allow us to easily see if these queries are a performance bottleneck. By incorporating the queries into the class we eliminate the need to expose representation choices, such as `ArrayList`, to our clients. This gives us the freedom to alter these implementations without fear of violating client contracts: + +``` +public class CustomerList { + private ArrayList customers = new ArrayList(); + private SortedList customersSortedBySpendingLevel = new SortedList(); + // ... + public CustomerList findCustomersThatSpendAtLeast(Money amount) { + return new CustomerList(customersSortedBySpendingLevel.elementsLargerThan(amount)); + } +} + +public class UsageExample { + public static void main(String[] args) { + CustomerList customers = new CustomerList(); + // ... + CustomerList customersOfInterest = customers.findCustomersThatSpendAtLeast(someMinimalAmount); + // ... + } +} +``` + +In this example, adherence to DRY allowed us to introduce an alternate indexing scheme with SortedList keyed on our customers level of spending. More important than the specific details of this particular example, following DRY helped us to find and repair a performance bottleneck that would have been more difficult to find were the code to be WET. + +By [Kirk Pepperdine](http://programmer.97things.oreilly.com/wiki/index.php/Kirk_Pepperdine) \ No newline at end of file diff --git a/fr-IR/thing_92/README.md b/fr-IR/thing_92/README.md new file mode 100644 index 00000000..730d20b2 --- /dev/null +++ b/fr-IR/thing_92/README.md @@ -0,0 +1,13 @@ +# When Programmers and Testers Collaborate + +Something magical happens when testers and programmers start to collaborate. There is less time spent sending bugs back and forth through the defect tracking system. Less time is wasted trying to figure out whether something is really a bug or a new feature, and more time is spent developing good software to meet customer expectations. There are many opportunities for starting collaboration before coding even begins. + +Testers can help customers write and automate acceptance tests using the language of their domain with tools such as Fit (Framework for Integrated Test). When these tests are given to the programmers before they coding begins, the team is practicing Acceptance Test Driven Development (ATDD). The programmers write the fixtures to run the tests, and then code to make the tests pass. These tests then become part of the regression suite. When this collaboration occurs, the functional tests are completed early allowing time for exploratory testing on edge conditions or through workflows of the bigger picture. + +We can take it one step further. As a tester, I can supply most of my testing ideas before the programmers start coding a new feature. When I ask the programmers if they have any suggestions, they almost always provide me with information that helps me with better test coverage, or helps me to avoid spending a lot of time on unnecessary tests. Often we have prevented defects because the tests clarify many of the initial ideas. For example, in one project I was on, the Fit tests I gave the programmers displayed the expected results of a query to respond to a wildcard search. The programmer had fully intended to code only complete word searches. We were able to talk to the customer and determine the correct interpretation before coding started. By collaborating, we prevented the defect, which saved us both a lot of wasted time. + +Programmers can collaborate with testers to create successful automation as well. They understand good coding practices and can help testers set up a robust test automation suite that works for the whole team. I have often seen test automation projects fail because the tests are poorly designed. The tests try to test too much or the testers haven't understood enough about the technology to be able to keep tests independent. The testers are often the bottleneck, so it makes sense for programmers to work with them on tasks like automation. Working with the testers to understand what can be tested early, perhaps by providing a simple tool, will give the programmers another cycle of feedback which will help them deliver better code in the long run. + +When testers stop thinking their only job is to break the software and find bugs in the programmers' code, programmers stop thinking that testers are 'out to get them,' and are more open to collaboration. When programmers start realizing they are responsible for building quality into their code, testability of the code is a natural by-product, and the team can automate more of the regression tests together. The magic of successful teamwork begins. + +By [Janet Gregory](http://programmer.97things.oreilly.com/wiki/index.php/Janet_Gregory) \ No newline at end of file diff --git a/fr-IR/thing_93/README.md b/fr-IR/thing_93/README.md new file mode 100644 index 00000000..e4ff8323 --- /dev/null +++ b/fr-IR/thing_93/README.md @@ -0,0 +1,13 @@ +# Write Code as If You Had to Support It for the Rest of Your Life + +You could ask 97 people what every programmer should know and do, and you might hear back 97 distinct answers. This could be both overwhelming and intimidating at the same time. All advice is good, all principles are sound, and all stories are compelling, but where do you start? More important, once you have started, how do you keep up with all the best practices you've learned and how do you make them an integral part of your programming practice? + +I think the answer lies in your frame of mind or, more plainly, in your attitude. If you don't care about your fellow developers, testers, managers, sales and marketing people, and end users, then you will not be driven to employ Test-Driven Development or write clear comments in your code, for example. I think there is a simple way to adjust your attitude and always be driven to deliver the best quality products: + +> *Write code as if you had to support it for the rest of your life.* + +That's it. If you accept this notion, many wonderful things will happen. If you were to accept that any of your previous or current employers had the right to call you in the middle of the night, asking you to explain the choices you made while writing the fooBar method, you would gradually improve toward becoming an expert programmer. You would naturally want to come up with better variable and method names. You would stay away from blocks of code comprising hundreds of lines. You would seek, learn, and use design patterns. You would write comments, test your code, and refactor continually. Supporting all the code you'd ever written for the rest of your life should also be a scalable endeavor. You would therefore have no choice but to become better, smarter, and more efficient. + +If you reflect on it, the code you wrote many years ago still influences your career, whether you like it or not. You leave a trail of your knowledge, attitude, tenacity, professionalism, level of commitment, and degree of enjoyment with every method and class and module you design and write. People will form opinions about you based on the code that they see. If those opinions are constantly negative, you will get less from your career than you hoped. Take care of your career, of your clients, and of your users with every line of code — write code as if you had to support it for the rest of your life. + +By [Yuriy Zubarev](http://programmer.97things.oreilly.com/wiki/index.php/Yuriy_Zubarev) \ No newline at end of file diff --git a/fr-IR/thing_94/README.md b/fr-IR/thing_94/README.md new file mode 100644 index 00000000..4b5181cd --- /dev/null +++ b/fr-IR/thing_94/README.md @@ -0,0 +1,26 @@ +# Write Small Functions Using Examples + +We would like to write code that is correct, and have evidence on hand that it is correct. It can help with both issues to think about the "size" of a function. Not in the sense of the amount of code that implements a function — although that is interesting — but rather the size of the mathematical function that our code manifests. + +For example, in the game of Go there is a condition called *atari* in which a player's stones may be captured by their opponent: A stone with two or more free spaces adjacent to it (called *liberties*) is not in atari. It can be tricky to count how many liberties a stone has, but determining atari is easy if that is known. We might begin by writing a function like this: + +``` +boolean atari(int libertyCount) + libertyCount < 2 +``` + +This is larger than it looks. A mathematical function can be understood as a set, some subset of the Cartesian product of the sets that are its domain (here, `int`) and range (here, `boolean`). If those sets of values were the same size as in Java then there would be `2L*(Integer.MAX_VALUE+(-1L*Integer.MIN_VALUE)+1L)` or 8,589,934,592 members in the set `int×boolean`. Half of these are members of the subset that is our function, so to provide complete evidence that our function is correct we would need to check around 4.3×109 examples. + +This is the essence of the claim that tests cannot prove the absence of bugs. Tests can demonstrate the presence of features, though. But still we have this issue of size. + +The problem domain helps us out. The nature of Go means that number of liberties of a stone is not any int, but exactly one of {1,2,3,4}. So we could alternatively write: + +``` +LibertyCount = {1,2,3,4} +boolean atari(LibertyCount libertyCount) + libertyCount == 1 +``` + +This is much more tractable: The function computed is now a set with at most eight members. In fact, four checked examples would constitute evidence of complete certainty that the function is correct. This is one reason why it's a good idea to use types closely related to the problem domain to write programs, rather than native types. Using domain–inspired types can often make our functions much smaller. One way to find out what those types should be is to find the examples to check in problem domain terms, before writing the function. + +by [Keith Braithwaite](http://programmer.97things.oreilly.com/wiki/index.php/Keith_Braithwaite) \ No newline at end of file diff --git a/fr-IR/thing_95/README.md b/fr-IR/thing_95/README.md new file mode 100644 index 00000000..7ba49719 --- /dev/null +++ b/fr-IR/thing_95/README.md @@ -0,0 +1,15 @@ +# Write Tests for People + +You are writing automated tests for some or all of your production code. Congratulations! You are writing your tests before you write the code? Even better!! Just doing this makes you one of the early adopters on the leading edge of software engineering practice. But are you writing good tests? How can you tell? One way is to ask "Who am I writing the tests for?" If the answer is "For me, to save me the effort of fixing bugs" or "For the compiler, so they can be executed" then the odds are you aren't writing the best possible tests. So *who* should you be writing the tests for? For the person trying to understand your code. + +Good tests act as documentation for the code they are testing. They describe how the code works. For each usage scenario the test(s): + +1. Describe the context, starting point, or preconditions that must be satisfied +2. Illustrate how the software is invoked +3. Describe the expected results or postconditions to be verified + +Different usage scenarios will have slightly different versions of each of these. The person trying to understand your code should be able to look at a few tests and by comparing these three parts of the tests in question, be able to see what causes the software to behave differently. Each test should clearly illustrate the cause and effect relationship between these three parts. This implies that what isn't visible in the test is just as important as what is visible. Too much code in the test distracts the reader with unimportant trivia. Whenever possible hide such trivia behind meaningful method calls — the Extract Method refactoring is your best friend. And make sure you give each test a meaningful name that describes the particular usage scenario so the test reader doesn't have to reverse engineer each test to understand what the various scenarios are. Between them, the names of the test class and class method should include at least the starting point and how the software is being invoked. This allows the test coverage to be verified via a quick scan of the method names. It can also be useful to include the expected results in the test method names as long as this doesn't cause the names to be too long to see or read. + +It is also a good idea to test your tests. You can verify they detect the errors you think they detect by inserting those errors into the production code (your own private copy that you'll throw away, of course). Make sure they report errors in a helpful and meaningful way. You should also verify that your tests speak clearly to a person trying to understand your code. The only way to do this is to have someone who isn't familiar with your code read your tests and tell you what they learned. Listen carefully to what they say. If they didn't understand something clearly it probably isn't because they aren't very bright. It is more likely that you weren't very clear. (Go ahead and reverse the roles by reading their tests!) + +by [Gerard Meszaros](http://programmer.97things.oreilly.com/wiki/index.php/Gerard_Meszaros) diff --git a/fr-IR/thing_96/README.md b/fr-IR/thing_96/README.md new file mode 100644 index 00000000..d6cc6dcc --- /dev/null +++ b/fr-IR/thing_96/README.md @@ -0,0 +1,23 @@ +# You Gotta Care about the Code + +It doesn't take Sherlock Holmes to work out that good programmers write good code. Bad programmers... don't. They produce monstrosities that the rest of us have to clean up. You want to write the good stuff, right? You want to be a good programmer. + +Good code doesn't pop out of thin air. It isn't something that happens by luck when the planets align. To get good code you have to work at it. Hard. And you'll only get good code if you actually care about good code. + +Good programming is not born from mere technical competence. I've seen highly intellectual programmers who can produce intense and impressive algorithms, who know their language standard by heart, but who write the most awful code. It's painful to read, painful to use, and painful to modify. I've seen more humble programmers who stick to very simple code, but who write elegant and expressive programs that are a joy to work with. + +Based on my years of experience in the software factory, I've concluded that the real difference between adequate programmers and great programmers is this: *attitude*. Good programming lies in taking a professional approach, and wanting to write the best software you can, within the Real World constraints and pressures of the software factory. + +*The code to hell is paved with good intentions.* To be an excellent programmer you have to rise above good intentions, and actually *care* about the code — foster positive perspectives and develop healthy attitudes. Great code is carefully crafted by master artisans, not thoughtlessly hacked out by sloppy programmers or erected mysteriously by self-professed coding gurus. + +You want to write good code. You want to be a good programmer. So, you care about the code: + +- In any coding situation, you refuse to hack something that only seems to work. You strive to craft elegant code that is clearly correct (and has good tests to show that it is correct). +- You write code that is *discoverable* (that other programmers can easily pick up and understand), that is *maintainable* (that you, or other programmers, will be easily able to modify in the future), and that is correct (you take all steps possible to determine that you have solved the problem, not just made it look like the program works). +- You work well alongside other programmers. No programmer is an island. Few programmers work alone; most work in a team of programmers, either in a company environment or on an open source project. You consider other programmers, and construct code that others can read. You want the team to write the best software possible, rather than to make yourself look clever. +- Any time you touch a piece of code you strive to leave it better than you found it (either better structured, better tested, more understandable...). +- You care about code and about programming, so you are constantly learning new languages, idioms, and techniques. But you only apply them when appropriate. + +Fortunately, you're reading this collection of advice because you do care about code. It interests you. It's your passion. Have fun programming. Enjoy cutting code to solve tricky problems. Produce software that makes you proud. + +By [Pete Goodliffe](http://programmer.97things.oreilly.com/wiki/index.php/Pete_Goodliffe) \ No newline at end of file diff --git a/fr-IR/thing_97/README.md b/fr-IR/thing_97/README.md new file mode 100644 index 00000000..8a812b72 --- /dev/null +++ b/fr-IR/thing_97/README.md @@ -0,0 +1,13 @@ +# Your Customers Do not Mean What They Say + +I've never met a customer yet that wasn't all too happy to tell me what they wanted — usually in great detail. The problem is that customers don't always tell you the whole truth. They generally don't lie, but they speak in customer speak, not developer speak. They use their terms and their contexts. They leave out significant details. They make assumptions that you've been at their company for 20 years, just like they have. This is compounded by the fact that many customers don't actually know what they want in the first place! Some may have a grasp of the "big picture," but they are rarely able to communicate the details of their vision effectively. Others might be a little lighter on the complete vision, but they know what they don't want. So, how can you possibly deliver a software project to someone who isn't telling you the whole truth about what they want? It's fairly simple. Just interact with them more. + +Challenge your customers early and challenge them often. Don't simply restate what they told you they wanted in their words. Remember: They didn't mean what they told you. I often do this by swapping out words in conversation with them and judging their reaction. You'd be amazed how many times the term *customer* has a completely different meaning to the term *client*. Yet the guy telling you what he wants in his software project will use the terms interchangeably and expect you to keep track as to which one he's talking about. You'll get confused and the software you write will suffer. + +Discuss topics numerous times with your customers before you decide that you understand what they need. Try restating the problem two or three times with them. Talk to them about the things that happen just before or just after the topic you're talking about to get better context. If at all possible, have multiple people tell you about the same topic in separate conversations. They will almost always tell you different stories, which will uncover separate yet related facts. Two people telling you about the same topic will often contradict each other. Your best chance for success is to hash out the differences before you start your ultra-complex software crafting. + +Use visual aids in your conversations. This could be as simple as using a whiteboard in a meeting, as easy as creating a visual mock-up early in the design phase, or as complex as crafting a functional prototype. It is generally known that using visual aids during a conversation helps lengthen our attention span and increases the retention rate of the information. Take advantage of this fact and set your project up for success. + +In a past life, I was a "multimedia programmer" on a team who produced glitzy projects. A client of ours described their thoughts on the look and feel of the project in great detail. The general color scheme discussed in the design meetings indicated a black background for the presentation. We thought we had it nailed. Teams of graphic designers began churning out hundreds of layered graphics files. Loads of time was spent molding the end product. A startling revelation was made on the day we showed the client the fruits of our labor. When she saw the product, her exact words about the background color were "When I said black, I meant white." So, you see, it is never as clear as black and white. + +By [Nate Jackson](http://programmer.97things.oreilly.com/wiki/index.php/Icnatejackson) \ No newline at end of file From 803e5a8dd56791d73dd01230881a03b7d5d95b01 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Mon, 23 Jan 2023 14:42:47 +0300 Subject: [PATCH 127/290] Update README.md Updated general README.md. --- fr-IR/README.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/fr-IR/README.md b/fr-IR/README.md index aa344994..f00d4fec 100644 --- a/fr-IR/README.md +++ b/fr-IR/README.md @@ -1,11 +1,11 @@ 97 چیزی که هر برنامه نویس باید بداند ====== -*Pearls of wisdom for programmers collected from leading practitioners.* +*مروارید حکمت برای برنامه نویسان جمع آوری شده از تمرین کنندگان برجسته.* -This is a [GitBook](https://www.gitbook.io) version of the ['97 Things Every Programmer Should Know' project](http://programmer.97things.oreilly.com/wiki/index.php/97_Things_Every_Programmer_Should_Know). +این یک [گیت بوک](https://www.gitbook.io) بر اساس کتاب [97 Things Every Programmer Should Know project](http://programmer.97things.oreilly.com/wiki/index.php/97_Things_Every_Programmer_Should_Know) است. -All content is licensed under the [Creative Commons Attribution-NonCommercial-ShareAlike 3.0 license](http://creativecommons.org/licenses/by-nc-sa/3.0/). Print versions of the book are available on [Amazon.com](http://www.amazon.com/Things-Every-Programmer-Should-Know/dp/0596809484). +[فهرست](fr-IR/SUMMARY.md) -If you find any mistakes or have any suggestions, you can [create an issue](https://github.com/97-things/97-things-every-programmer-should-know/issues) or [file a pull request](https://github.com/97-things/97-things-every-programmer-should-know/pulls) to the [repository](https://github.com/97-things/97-things-every-programmer-should-know). +همه محتوا تحت مجوز [Creative Commons Attribution Non Commercial Share Alike 3.0 license](http://creativecommons.org/licenses/by-nc-sa/3.0/) است. نسخه های چاپی کتاب را میتوانید در [Amazon.com](http://www.amazon.com/Things-Every-Programmer-Should-Know/dp/0596809484) بیابید. From 0d528863a959eaf584c8fcb56814e7e03dac43c1 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 25 Jan 2023 10:40:29 +0300 Subject: [PATCH 128/290] Update README.md --- fr-IR/thing_01/README.md | 16 ++++------------ 1 file changed, 4 insertions(+), 12 deletions(-) diff --git a/fr-IR/thing_01/README.md b/fr-IR/thing_01/README.md index 3604026b..0c45026a 100644 --- a/fr-IR/thing_01/README.md +++ b/fr-IR/thing_01/README.md @@ -1,15 +1,7 @@ -# Act with Prudence +# بدهی فنی (Technical Debt) -> *"Whatever you undertake, act with prudence and consider the consequences" Anon* +پیش می‌آید که می بایست مابین «انجام اصولی یک پروژه» و «انجام سریع یک پروژه» یکی را انتخاب کنیم و در ابتدای کار سرعت بخشیدن به فرایند طراحی یک پروژه جذاب‌تر به نظر می‌رسد با این استدلال که بعداً هم می‌شود مجدد به کدها سر زد و اگر مشکلی داشت آن ها را از بین برد! اما تجربه نشان داده است زمانی که در بر گیرنده واژه ی بعداً است، خود حاوی بسیاری باگ ها و مشکلات خواهد بود که برنامه نویس مجبور است بیشتر تمرکز خود را روی آن‌ها بگذارد و از توجه به مشکلات -هرچند جزئی- گذشته باز می ماند. -No matter how comfortable a schedule looks at the beginning of an iteration, you can't avoid being under pressure some of the time. If you find yourself having to choose between "doing it right" and "doing it quick" it is often appealing to "do it quick" on the understanding that you'll come back and fix it later. When you make this promise to yourself, your team, and your customer, you mean it. But all too often the next iteration brings new problems and you become focused on them. This sort of deferred work is known as technical debt and it is not your friend. Specifically, Martin Fowler calls this deliberate technical debt in his [taxonomy of technical debt](http://martinfowler.com/bliki/TechnicalDebtQuadrant.html), which should not be confused with inadvertent technical debt. +چنین سیاستی در برنامه نویسی اصطلاحاً Technical Debt گفته می‌شود که به صورت تحت الفظی می‌توان آن را به «بدهی فنی» ترجمه کرد (توجه داشته باشید که در واژه انگلیسی Debt حرف b تلفظ نمی شود!) این بدهی فنی اصلاً چیز خوبی نیست و گاهی اوقات منجر به بوجود آمدن فجایعی در تولید نرم افزار می شود. برای روشن شدن این مسأله مثالی می زنیم. بدهی فنی همچون وام گرفتن است که در کوتاه مدت کار ما را راه می‌اندازد اما غافل از این که در آینده می بایست با بهره ای که روی آن می‌آید -مثلا 30 درصد بیشتر- قرض خود را پرداخت کنیم (راستی می گن در برخی کشورهایی که مسلمان نیستند بهره بانکی چیزی در حدود یکی دو درصد است در حالی که در ایران اسلامی ما گاها تا پنجاه درصد می رسد. آن‌ها مسلمانند یا ما. بگذریم!) -Technical debt is like a loan: You benefit from it in the short-term, but you have to pay interest on it until it is fully paid off. Shortcuts in the code make it harder to add features or refactor your code. They are breeding grounds for defects and brittle test cases. The longer you leave it, the worse it gets. By the time you get around to undertaking the original fix there may be a whole stack of not-quite-right design choices layered on top of the original problem making the code much harder to refactor and correct. In fact, it is often only when things have got so bad that you must fix it, that you actually do go back to fix it. And by then it is often so hard to fix that you really can't afford the time or the risk. - -There are times when you must incur technical debt to meet a deadline or implement a thin slice of a feature. Try not to be in this position, but if the situation absolutely demands it, then go ahead. But (and this is a big BUT) you must track technical debt and pay it back quickly or things go rapidly downhill. As soon as you make the decision to compromise, write a task card or log it in your issue tracking system to ensure that it does not get forgotten. - -If you schedule repayment of the debt in the next iteration, the cost will be minimal. Leaving the debt unpaid will accrue interest and that interest should be tracked to make the cost visible. This will emphasize the effect on business value of the project's technical debt and enables appropriate prioritization of the repayment. The choice of how to calculate and track the interest will depend on the particular project, but track it you must. - -Pay off technical debt as soon as possible. It would be imprudent to do otherwise. - -By [Seb Rose](http://programmer.97things.oreilly.com/wiki/index.php/Seb_Rose) \ No newline at end of file +در برنامه نویسی هم قضیه دقیقاً به همین صورت است. اگرچه گاهی اوقات می‌توان از راه کارهایی استفاده کرد که به کدنویسی ما سرعت بخشند اما این در حالی است که در آینده اضافه کردن ویژگی‌های جدیدی به پروژه را دشوار می‌سازد و به اصطلاح نمی‌توان به سادگی کدهای خود را Refactor کرد. جالب اینجا است که هرچه از زمان ایجاد این دست مشکلات بیشتر می گذرد، یافتن راه‌کار هم برای آن‌ها دشوارتر خواهد شد. اما اگر ما از زمان بندی پروژه عقب باشیم و مجبور باشیم سرعت عمل را بر کیفیت ترجیح دهیم چطور؟ توصیه ما این است که هرگز سیاست فدا کردن کیفیت کار به خاطر سرعت بخشیدن به آن را دنبال نکنید اما اگر واقعاً مجبور هستید، پس این کار را انجام دهید اما حتماً به خاطر داشته باشید که شما با این کار یک بدهی فنی برای خود ایجاد کرده‌اید که می بایست در اولین فرصت این بدهی خود را صاف کنید. برای این منظور هم، حتماً در مستندات پروژه این قضیه را ذکر کنید تا فراموش نشود که در غیر این صورت ممکن است مجبور شوید بهای گزافی بابت آن پرداخت کنید. From 888a5a9bec3d10443e49c6c3ec6c6bc95253e91a Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 25 Jan 2023 10:42:44 +0300 Subject: [PATCH 129/290] Update README.md --- fr-IR/thing_02/README.md | 20 +++----------------- 1 file changed, 3 insertions(+), 17 deletions(-) diff --git a/fr-IR/thing_02/README.md b/fr-IR/thing_02/README.md index bf229069..3aefb6d6 100644 --- a/fr-IR/thing_02/README.md +++ b/fr-IR/thing_02/README.md @@ -1,19 +1,5 @@ -# Apply Functional Programming Principles +# برنامه نویسی تابعی یا Functional Programming -Functional programming has recently enjoyed renewed interest from the mainstream programming community. Part of the reason is because *emergent properties* of the functional paradigm are well positioned to address the challenges posed by our industry's shift toward multi-core. However, while that is certainly an important application, it is not the reason this piece admonishes you to *know thy functional programming*. +برنامه نویسی تابعی یا Functional Programming در چند سال گذشته طرفداران بسیاری پیدا کرده است. این پارادایم عبارت است از روشی که در آن منطق به کار گرفته شده در برنامه به صورت توابع ریاضیاتی در نظر گرفته می شوند. درک صحیح این نوع پارادایم به طرز قابل توجهی کمک به ارتقاء کیفیت کدی که نوشته می‌شود خواهد کرد و چنانچه شما -به عنوان یک برنامه نویسی- از اصول برنامه نویسی تابعی استفاده کنید، کیفیت برنامه‌ای که می نویسید دوچندان خواهد شد که در نهایت با تعداد خطوط کدی کمتری، نتیجه ای که نیاز دارید را به دست خواهید آورد. -Mastery of the functional programming paradigm can greatly improve the quality of the code you write in other contexts. If you deeply understand and apply the functional paradigm, your designs will exhibit a much higher degree of *referential transparency*. - -Referential transparency is a very desirable property: It implies that functions consistently yield the same results given the same input, irrespective of where and when they are invoked. That is, function evaluation depends less — ideally, not at all — on the side effects of mutable state. - -A leading cause of defects in imperative code is attributable to mutable variables. Everyone reading this will have investigated why some value is not as expected in a particular situation. Visibility semantics can help to mitigate these insidious defects, or at least to drastically narrow down their location, but their true culprit may in fact be the providence of designs that employ inordinate mutability. - -And we certainly don't get much help from industry in this regard. Introductions to object orientation tacitly promote such design, because they often show examples composed of graphs of relatively long-lived objects that happily call mutator methods on each other, which can be dangerous. However, with astute test-driven design, particularly when being sure to ["Mock Roles, not Objects"](http://www.jmock.org/oopsla2004.pdf), unnecessary mutability can be designed away. - -The net result is a design that typically has better responsibility allocation with more numerous, smaller functions that act on arguments passed into them, rather than referencing mutable member variables. There will be fewer defects, and furthermore they will often be simpler to debug, because it is easier to locate where a rogue value is introduced in these designs than to otherwise deduce the particular context that results in an erroneous assignment. This adds up to a much higher degree of referential transparency, and positively nothing will get these ideas as deeply into your bones as learning a functional programming language, where this model of computation is the norm. - -Of course, this approach is not optimal in all situations. For example, in object-oriented systems this style often yields better results with domain model development (i.e., where collaborations serve to break down the complexity of business rules) than with user-interface development. - -Master the functional programming paradigm so you are able to judiciously apply the lessons learned to other domains. Your object systems (for one) will resonate with referential transparency goodness and be much closer to their functional counterparts than many would have you believe. In fact, some would even assert that the apex of functional programming and object orientation are *merely a reflection of each other*, a form of computational yin and yang. - -By [Edward Garson](http://programmer.97things.oreilly.com/wiki/index.php/Edward_Garson) \ No newline at end of file +زمانی که در پروژه های خود از توابع استفاده می کنیم، مسئولیت های خاصی را می‌توان به هر تابع اختصاص داد و توابع با استفاده از آرگومان هایی که می گیرند، می‌توانند خروجی های مختلفی را در اختیار سایر بخش های برنامه قرار دهند. برنامه‌هایی که در آن‌ها از توابع به درستی استفاده شده باشد، نسبت به روش‌های سنتی برنامه نویسی به سادگی قابل Debug کردن هستند. برنامه نویسی تابعی در برنامه نویسی شیئ گرایی به خوبی جواب داده است اما این در حالی است که در تمامی موقعیت ها نمی‌توان از این پارادایم استفاده کرد. From 4514812af1c37243c14cb68922e702b29ebea440 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 25 Jan 2023 10:44:14 +0300 Subject: [PATCH 130/290] Update README.md --- fr-IR/thing_03/README.md | 17 +++++------------ 1 file changed, 5 insertions(+), 12 deletions(-) diff --git a/fr-IR/thing_03/README.md b/fr-IR/thing_03/README.md index f101d7ad..ad755174 100644 --- a/fr-IR/thing_03/README.md +++ b/fr-IR/thing_03/README.md @@ -1,16 +1,9 @@ -# Ask "What Would the User Do?" (You Are not the User) +# نیاز کاربر چیست؟ -We all tend to assume that other people think like us. But they don't. Psychologists call this the false consensus bias. When people think or act differently to us, we're quite likely to label them (subconsciously) as defective in some way. +همه کسانی که برنامه نویسی می‌کنند فکر می‌کنند که کاربران برنامه یا اپلیکیشنی که توسعه می دهند مثل ایشان فکر می‌کنند و بر این باورند که همان ارتباطی که خود ایشان با برنامه شان دارند را کاربران دیگر هم خواهند داشت که این ایده بس اشتباه است. چنین باوری از دید روانشناسی اصطلاحاً False Consensus Bias نامیده می شود. جالب است بدانیم وقتی کاربران به طرزی با برنامه نوشته شده توسط ما تعامل برقرار می‌سازند که بر خلاف انتظار ما است،‌ روی ایشان برچسب «یک کاربر غیر حرفه ای» را می زنیم! اما این در صورتی است که ما یک برنامه نویس غیر حرفه ای هستیم که نیازهای جامعه ی هدف خود را به خوبی تشخیص نداده ایم! -This bias explains why programmers have such a hard time putting themselves in the users' position. Users don't think like programmers. For a start, they spend much less time using computers. They neither know nor care how a computer works. This means they can't draw on any of the battery of problem-solving techniques so familiar to programmers. They don't recognize the patterns and cues programmers use to work with, through, and around an interface. +آنچه مسلم است این که کاربران هرگز مثل برنامه نویسان فکر نمی‌کنند چرا که ایشان برخلاف توسعه دهندگان زمان کمتری را پای کامپیوتر می نشینند،‌ با نحوه کار کردن سیستم‌ها خیلی آشنایی ندارند، فاقد مهارت های حل مسأله هستند که اکثر برنامه نویسان از آن‌ها برخوردارند، با الگوهایی که برنامه نویسان برای طراحی و کدنویسی مورد استفاده قرار می‌دهند آشنا نیستند و غیره. به عبارت دیگر، ارتباطی که یک End User با یک برنامه یا اپلیکیشن دارد همچون ارتباطی است که یک برنامه نویس با یک خودرو دارد. درست است که برنامه نویس می‌داند که چگونه سوار خودرو شود، کمربند خود را ببندد و ...، اما این آقا یا خانم برنامه نویس هرگز نمی‌داند که سازوکار سیستم این خودرو به چه شکل است. -The best way to find out how users think is to watch one. Ask a user to complete a task using a similar piece of software to what you're developing. Make sure the task is a real one: "Add up a column of numbers" is OK; "Calculate your expenses for the last month" is better. Avoid tasks that are too specific, such as "Can you select these spreadsheet cells and enter a *SUM* formula below?" — there's a big clue in that question. Get the user to talk through his or her progress. Don't interrupt. Don't try to help. Keep asking yourself "Why is he doing that?" and "Why is she not doing that?" +برای رفع این مشکل، می بایست از یک کاربر عادی بخواهیم که به تعامل با برنامه، سایت یا اپلیکیشن ما بپردازد و نحوه ارتباط برقرار ساختن وی با نرم‌افزار را به دقت مورد بررسی قرار دهیم. در‌واقع می بایست ببینیم که نیازهای این کاربر چیست، کجاها به مشکل بر می خورد، در کدام بخش‌ها سردرگم می‌شود و … برای روشن شدن این مسأله مثالی می زنیم. زمانی که یک برنامه نویس به عنوان مثال سایتی را کدنویسی می کند، زمانی که در ناحیه کاربری به مشکلی برخورد می‌کند به طور حتم می‌داند که از چه طریق می بایست آن مشکل را رفع کرد اما این مسأله در مورد کابران عادی صدق نمی‌کند و ایشان ممکن است به محض برخورد با کوچک‌ترین مشکل، از هدف خود دست بکشند. نکته دیگری که می بایست همواره مد نظر قرار دهیم این است که در اکثر مواقع مابین آنچه کاربران واقعاً به آن نیاز دارند و آنچه بیان می‌کنند یک شکاف وجود دارد. به عبارت دیگر و به قول مرحوم استیو جابز، این کاربران نیستند که می‌گویند چه می‌خواهند بلکه این شما به عنوان یک طراح هستید که می بایست به نیاز کاربران پی برده و نیاز ایشان را به بهترین شکل به ایشان عرضه کنید. -The first thing you'll notice is that users do a core of things similarly. They try to complete tasks in the same order — and they make the same mistakes in the same places. You should design around that core behavior. This is different from design meetings, where people tend to be listened to for saying "What if the user wants to...?" This leads to elaborate features and confusion over what users want. Watching users eliminates this confusion. - -You'll see users getting stuck. When you get stuck, you look around. When users get stuck, they narrow their focus. It becomes harder for them to see solutions elsewhere on the screen. It's one reason why help text is a poor solution to poor user interface design. If you must have instructions or help text, make sure to locate it right next to your problem areas. A user's narrow focus of attention is why tool tips are more useful than help menus. - -Users tend to muddle through. They'll find a way that works and stick with it no matter how convoluted. It's better to provide one really obvious way of doing things than two or three shortcuts. -You'll also find that there's a gap between what users say they want and what they actually do. That's worrying as the normal way of gathering user requirements is to ask them. It's why the best way to capture requirements is to watch users. Spending an hour watching users is more informative than spending a day guessing what they want. - -by [Giles Colborne](http://programmer.97things.oreilly.com/wiki/index.php/Giles_Colborne) \ No newline at end of file +برای رفع این مشکل، به جای گوش کردن به صحبت‌های کاربران، می بایست به تعامل ایشان با سایت، نرم‌افزار یا اپلیکیشن نگاه کرده و از روی رفتار ایشان با برنامهٔ‌مان، وی را نیاز سنجی کنیم. در یک کلام، اگر چند دقیقه به رفتار یک کاربر با برنامه خود نگاه کنیم، به مراتب مثمرثمر تر از انجام یک مصاحبه چند ساعتی با چندین مخاطب بالقوه در مورد نیازهای ایشان خواهد بود. From becbac023ce7dc249b6c4c21db8483d8bb4f7710 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 25 Jan 2023 10:52:24 +0300 Subject: [PATCH 131/290] Update README.md --- fr-IR/thing_04/README.md | 57 ++++++++++++++++++++++++++-------------- 1 file changed, 37 insertions(+), 20 deletions(-) diff --git a/fr-IR/thing_04/README.md b/fr-IR/thing_04/README.md index 7bc02205..6537744b 100644 --- a/fr-IR/thing_04/README.md +++ b/fr-IR/thing_04/README.md @@ -1,20 +1,37 @@ -# Automate Your Coding Standard - -You've probably been there too. At the beginning of a project, everybody has lots of good intentions — call them "new project's resolutions." Quite often, many of these resolutions are written down in documents. The ones about code end up in the project's coding standard. During the kick-off meeting, the lead developer goes through the document and, in the best case, everybody agrees that they will try to follow them. Once the project gets underway, though, these good intentions are abandoned, one at a time. When the project is finally delivered the code looks like a mess, and nobody seems to know how it came to be this way. - -When did things go wrong? Probably already at the kick-off meeting. Some of the project members didn't pay attention. Others didn't understand the point. Worse, some disagreed and were already planning their coding standard rebellion. Finally, some got the point and agreed but, when the pressure in the project got too high, they had to let something go. Well-formatted code doesn't earn you points with a customer that wants more functionality. Furthermore, following a coding standard can be quite a boring task if it isn't automated. Just try to indent a messy class by hand to find out for yourself. - -But if it's such a problem, why is that we want to have a coding standard in the first place? One reason to format the code in a uniform way is so that nobody can "own" a piece of code just by formatting it in his or her private way. We may want to prevent developers using certain anti-patterns, in order to avoid some common bugs. In all, a coding standard should make it easier to work in the project, and maintain development speed from the beginning to the end. It follows then that everybody should agree on the coding standard too — it does not help if one developer uses three spaces to indent code, and another one four. - -There exists a wealth of tools that can be used to produce code quality reports and to document and maintain the coding standard, but that isn't the whole solution. It should be automated and enforced where possible. Here are a few examples: - -- Make sure code formatting is part of the build process, so that everybody runs it automatically every time they compile the code. -- Use static code analysis tools to scan the code for unwanted anti-patterns. If any are found, break the build. -- Learn to configure those tools so that you can scan for your own, project-specific anti-patterns. -- Do not only measure test coverage, but automatically check the results too. Again, break the build if test coverage is too low. - -Try to do this for everything that you consider important. You won't be able to automate everything you really care about. As for the things that you can't automatically flag or fix, consider them to be a set of guidelines supplementary to the coding standard that is automated, but accept that you and your colleagues may not follow them as diligently. - -Finally, the coding standard should be dynamic rather than static. As the project evolves, the needs of the project change, and what may have seemed smart in the beginning, isn't necessarily smart a few months later. - -By [Filip van Laenen](http://programmer.97things.oreilly.com/wiki/index.php/Filip_van_Laenen) \ No newline at end of file +# استاندارهای کدنویسی +استاندارهای کدنویسی یا Coding Standards یکی از چیزهایی است که هر برنامه نویسی که قصد دارد لیبل حرفه‌ای رویش بخورد می بایست دنبال کند. پیروی از استانداردهای کدنویسی کار خیلی آسانی هم نیست و گاهی اوقات خیلی خسته‌کننده می‌شود اما واقعیت امر این است که در پروژه های نسبتاً بزرگ اعضای تیم نیاز دارند تا از یکسری قوانین تبعیت کنند. + +توجه داشته باشیم زمانی که یک سری قوانین کدنویسی -مثلا تعداد اسپیس هایی که می بایست در کدها استفاده کرد- را وضع می کنیم، تمامی اعضای تیم می بایست قبول کنند که از آن قوانین تبعیت کنند که در غیر این صورت، یک برنامه نویس خاطی می‌تواند هر چه سایر برنامه نویسان رشته کرده‌اند را پنبه کند! برای اعمال استانداردهای کدنویسی می‌توان از یکسری ابزارها هم استفاده کرد که فرایند استاندارد سازی را تا حد قابل توجهی برای برنامه نویس سهل و آسان می سازند که این ابزارها بسته به IDEیی که استفاده می کنیم می توانند از خصوصیات مختلفی برخوردار باشند. + +به عنوان نمونه، می‌توان زبان برنامه نویسی پی اچ پی را مثال زد. سایتی تحت عنوان php-fig.org استانداردی تحت عنوان PSR که مخفف واژگان PHP Standard Recommendation است را برای برنامه نویسان پی اچ پی طراحی کرده که علاقمندان با استفاده از این استانداردها می توانند از کدهایی برخوردار شوند که سایر برنامه نویسان پی اچ پی با نگاه کردن به کدهای ایشان کمتر دچار سردرگمی شوند. + +به طور مثال، کدی که در زیر مشاهده می کنید بر اساس استاندارد PSR نوشته شده است: + +``` + $b) { + $foo->bar($arg1); + } else { + BazClass::bar($arg2, $arg3); + } + } + + final public static function bar() + { + // method body + } +} +``` +در واقع، در کد بالا پس از namespace و دستورات use یک اینتر قرار گرفته است و یا این که علامت } مرتبط با کلاس Foo در خط بعد نوشته شده است. به عنوان مثالی دیگر، آرگومان های متد sampleFunction با یک کاما و اسپیس از یکدیگر مجزا شده اند و این در حالی است که کاما به آرگومان اول چسبیده، سپس یک فاصله قرار گرفته و در نهایت آرگومان دوم نوشته شده است. From 0b4aa9ee50039e999ddfdd91f1bfed98aca70d21 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 25 Jan 2023 10:54:49 +0300 Subject: [PATCH 132/290] Update README.md --- fr-IR/thing_05/README.md | 28 ++++------------------------ 1 file changed, 4 insertions(+), 24 deletions(-) diff --git a/fr-IR/thing_05/README.md b/fr-IR/thing_05/README.md index b25e7757..e76f2cda 100644 --- a/fr-IR/thing_05/README.md +++ b/fr-IR/thing_05/README.md @@ -1,27 +1,7 @@ -# Beauty Is in Simplicity +# ساده زیباست -There is one quote that I think is particularly good for all software developers to know and keep close to their hearts: +جمله‌ای از افلاطون وجود دارد با این مظمون که «هارمونی، زیبایی ظاهری، ظرافت و موزون بودن همه و همه به سادگی بستگی دارند.» و این جمله اگر توسط برنامه نویسان به کار گرفته شود، مزایای بسیار زیادی برای ایشان در بر خواهد داشت که از آن جمله می‌توان به خوانایی بیشتر کدها، نگهداری راحت‌تر اسکریپت ها، افزایش سرعت کدنویسی و در نهایت کیفیت بالاتر کدهای نوشته شده اشاره کرد و تمامی این موارد -و حتی موارد بیشتر- جز با به کارگیری دیدگاه افلاطون یعنی همان سادگی امکان‌پذیر نیست. -> *Beauty of style and harmony and grace and good rhythm depends on simplicity.* — Plato +حال می بایست به این سؤال پاسخ دهیم که به چه نوع کدی صفت زیبا اطلاق می گردد. این سؤال بسیار انتزاعی است چرا که مفهوم زیبایی چیزی کاملاً نسبی است. درکی که هنرمندان از زیبایی دارند به مراتب متفاوت تر از مهندسان یا برنامه نویسان است. لذا نیاز است تا مسئله ی زیبایی در برنامه نویسی را کمی بشکافیم! -In one sentence I think this sums up the values that we as software developers should aspire to. - -There are a number of things we strive for in our code: - -- Readability -- Maintainability -- Speed of development -- The elusive quality of beauty - -Plato is telling us that the enabling factor for all of these qualities is simplicity. - -What is beautiful code? This is potentially a very subjective question. Perception of beauty depends heavily on individual background, just as much of our perception of anything depends on our background. People educated in the arts have a different perception of (or at least approach to) beauty than people educated in the sciences. Arts majors tend to approach beauty in software by comparing software to works of art, while science majors tend to talk about symmetry and the golden ratio, trying to reduce things to formulae. In my experience, simplicity is the foundation of most of the arguments from both sides. - -Think about source code that you have studied. If you haven't spent time studying other people's code, stop reading this right now and find some open source code to study. Seriously! I mean it! Go search the web for some code in your language of choice, written by some well-known, acknowledged expert. - -You're back? Good. Where were we? Ah yes... I have found that code that resonates with me and that I consider beautiful has a number of properties in common. Chief among these is simplicity. I find that no matter how complex the total application or system is, the individual parts have to be kept simple. Simple objects with a single responsibility containing similarly simple, focused methods with descriptive names. Some people think the idea of having short methods of five to ten lines of code is extreme, and some languages make it very hard to do this, but I think that such brevity is a desirable goal nonetheless. - -The bottom line is that beautiful code is simple code. Each individual part is kept simple with simple responsibilities and simple relationships with the other parts of the system. This is the way we can keep our systems maintainable over time, with clean, simple, testable code, keeping the speed of development high throughout the lifetime of the system. -Beauty is born of and found in simplicity. - -By Jørn Ølmheim \ No newline at end of file +برای درک بهتر این موضوع، بهتر است سری به گیت هاب زده و برخی اسکریپت های نوشته شده توسط برنامه نویسان از نقاط مختلف جهان را مشاهده کنید. با مقایسه کدهای مختلف متوجه خواهید شد که برخی برنامه نویسان هستند که یکسری قوانین را به خوبی رعایت می‌کنند و همین مسأله منجر می‌گردد تا کدهای نوشته شده توسط ایشان زیبا‌تر به نظر برسد. جالب است بدانیم که هرچه کدی ساده‌تر باشد، در عین حال زیبا‌تر هم به نظر می رسد. اگرچه برخی برنامه‌ها هستند که بسیار پیچیده هستند و کارهای عجیب و غریبی انجام می‌دهند که آدم را به شگفتی وا می دارند، اما اگر همین برنامه‌ها را به بخش‌های کوچک‌تری تقسیم‌بندی کنیم، خواهیم دید که اگر برنامه نویس آن برنامه مد نظر حرفه‌ای بوده باشد و به سادگی در کدنویسی ایمان داشته باشد، بخش‌های کوچک برنامه کاملاً ساده و قابل درک هستند، هر ماژول وظیفه ی مشخصی دارد، بخش‌های مختلف مثل کلاس ها، متدها و متغیرها به خوبی نامگذاری شده‌اند به طوری که اگر سایر برنامه نویسان هم به سورس کد نگاه کنند، به راحتی متوجه وظیفه هر بخش از کد خواهند شد. به طور خلاصه، کد زیبا کدی است که ساده باشد. بخش‌های مختلف نرم‌افزار می بایست دارای روابط ساده‌ای با سایر بخش‌ها بوده و به سادگی قابل درک باشند. From 9aa1eb2d3c137d7eee819139de1bfc81509fac87 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 25 Jan 2023 11:32:04 +0300 Subject: [PATCH 133/290] Update README.md --- fr-IR/thing_06/README.md | 20 ++++++++------------ 1 file changed, 8 insertions(+), 12 deletions(-) diff --git a/fr-IR/thing_06/README.md b/fr-IR/thing_06/README.md index a1c73ce3..52a1b029 100644 --- a/fr-IR/thing_06/README.md +++ b/fr-IR/thing_06/README.md @@ -1,19 +1,15 @@ -# Before You Refactor +# آشنایی با مفهوم ریفکتورینگ در کدنویسی -At some point every programmer will need to refactor existing code. But before you do so please think about the following, as this could save you and others a great deal of time (and pain): +کی از چیزهایی که اکثر برنامه نویسان با آن رو به رو می‌شوند مفهومی است تحت عنوان Refactor که به معنی بازنویسی کدهایی است که پیش از این نوشته شده اند. نیاز به توضیح نیست تجربیاتی که یک برنامه نویس پس از چند سال کدنویسی کسب می‌کند قابل مقایسه با زمانی نیست که وی تازه شروع به کار کرده و مسلماً پس از چند صباحی که به کدهای خود نگاه کند، حالش از سبک کدنویسی خود به هم خواهد خورد و تصمیم می‌گیرد تا کدهای نوشته شده ی خود را اصطلاحاً Refactor کند. در این قسمت از آموزش، قصد داریم ببینیم که زمان مناسب برای بازنویسی کدهای پیشین چه موقع است و این در حالی است که اگر بدانیم چرا و چگونه این کار را انجام دهیم، در زمان ما به طرز قابل توجهی صرفه جویی خواهد شد. -- *The best approach for restructuring starts by taking stock of the existing codebase and the tests written against that code.* This will help you understand the strengths and weaknesses of the code as it currently stands, so you can ensure that you retain the strong points while avoiding the mistakes. We all think we can do better than the existing system... until we end up with something no better — or even worse — than the previous incarnation because we failed to learn from the existing system's mistakes. +پیش از آن که اقدام به بازنویسی کدهای خود کنید، حتماً موارد زیر را مد نظر قرار دهید: همواره یکی از بهترین رویکردها نسبت به این که کدهای خود را بازنویسی کنیم یا نکنیم این است که کدها را با استفاده از تست هایی که برای آن‌ها می نویسیم تست کنیم چرا که با این کار به نقاط ضعف و قوت برنامه خود به خوبی پی برده و زمانی که بخواهیم کدها را Refactor کنیم، بخش‌هایی از کد که دارند به خوبی کار می‌کنند را دست کاری نخواهیم کرد اما در عین حال نقاط ضعف را برطرف خواهیم نمود. برنامه نویس ها همواره فکر می‌کنند که می‌توانند کدی بنویسند که بهتر از کد فعلی کار کند و این همان اشتباهی است که می بایست تا حد ممکن از آن اجتناب کرد. -- *Avoid the temptation to rewrite everything.* It is best to reuse as much code as possible. No matter how ugly the code is, it has already been tested, reviewed, etc. Throwing away the old code — especially if it was in production — means that you are throwing away months (or years) of tested, battle-hardened code that may have had certain workarounds and bug fixes you aren't aware of. If you don't take this into account, the new code you write may end up showing the same mysterious bugs that were fixed in the old code. This will waste a lot of time, effort, and knowledge gained over the years. +هشدار علاوه بر این، حتماً بایستی مقابل وسوسه بازنویسی هر سورس کدی ایستادگی کرد. همواره به خاطر داشته باشیم که بایستی تا حد ممکن از کدهای قبلی استفاده کنیم حتی اگر کدها تمیز نوشته نشده اند! زمانی که کدهای قبلی را پاک می کنیم، این بدان معنا است که ما ماه ها و یا سال‌ها تلاش و کدنویسی را هدر می دهیم. -- *Many incremental changes are better than one massive change.* Incremental changes allows you to gauge the impact on the system more easily through feedback, such as from tests. It is no fun to see a hundred test failures after you make a change. This can lead to frustration and pressure that can in turn result in bad decisions. A couple of test failures is easy to deal with and provides a more manageable approach. +در فرایند بازنویسی کد، اعمال چندین تغییر ساختاری کوچک به مراتب بهتر است از یک تغییر عمده است. به عبارت دیگر، تغییرات کوچک این امکان را به شما می‌دهند تا تأثیر آن تغییرات را روی برنامه خود راحت‌تر تست کرده و بازخورد آن‌ها را مشاهده نمایید. -- *After each iteration, it is important to ensure that the existing tests pass.* Add new tests if the existing tests are not sufficient to cover the changes you made. Do not throw away the tests from the old code without due consideration. On the surface some of these tests may not appear to be applicable to your new design, but it would be well worth the effort to dig deep down into the reasons why this particular test was added. +پس از تکمیل هر ماژول -یا بهتر بگوییم هر بخش از برنامه- سورس کد ما حتماً بایستی از سد چندین تست عبور کند. به محض این که یک تغییر جدید در کد خود ایجاد می کنید، حتماً تست آن تغییرات را هم بنویسید. در‌ واقع این تست ها عملکردی همچون End User دارند که گویی دارد با برنامه ما کار می‌کند و این اطمینان را حاصل می‌کنند نرم افزاری که به دست مشتری خواهد رسید بدون باگ است. در ضمن، هرگز تست های نرم افزاری قدیمی را پاک نکنید چرا که ممکن است در ماه های گذشته ایده خاصی مد نظر شما بوده که برای تست کردن آن یک Unit Test نوشته‌اید اما اکنون که دارید به بازنویسی کدها می پردازید، فکر شما اصلاً به سمت و سوی آن ایده خاص نرفته است. -- *Personal preferences and ego shouldn't get in the way.* If something isn't broken, why fix it? That the style or the structure of the code does not meet your personal preference is not a valid reason for restructuring. Thinking you could do a better job than the previous programmer is not a valid reason either. +سعی کنید تا حد ممکن سلایق شخصی را وارد کدنویسی نکنید. اگر بخشی از کد دارد به درستی کار می کند، اصلاً نیازی به بازنویسی آن نیست. اگر کدهایی که نوشته‌اید تمیز نیستند، این اصلاً دلیل خوبی برای بازنویسی آن‌ها نیست. اگر هم کدهای پیش روی شما از برنامه نویس دیگری به شما به ارث رسیده، احتمال این که فکر کنید کدهای شما به مراتب بهتر از برنامه نویسی قبلی خواهد بود زیاد است که این هم اصلاً دلیل موجهی نیست! -- *New technology is insufficient reason to refactor.* One of the worst reasons to refactor is because the current code is way behind all the cool technology we have today, and we believe that a new language or framework can do things a lot more elegantly. Unless a cost–benefit analysis shows that a new language or framework will result in significant improvements in functionality, maintainability, or productivity, it is best to leave it as it is. - -- *Remember that humans make mistakes.* Restructuring will not always guarantee that the new code will be better — or even as good as — the previous attempt. I have seen and been a part of several failed restructuring attempts. It wasn't pretty, but it was human. - -by [Rajith Attapattu](http://programmer.97things.oreilly.com/wiki/index.php/Rajith_Attapattu) \ No newline at end of file +استفاده از فناوری های جدید هم اصلاً دلیل مناسبی برای Refactoring نیست. یکی از بدترین دلایلی که یک برنامه نویسی برای بازنویسی کدها می‌تواند بیاورد این است که کدهای برنامه مربوط به فناوری های چندین سال پیش هستند و در حال حاضر نسخه نرم‌افزارها و زبان‌های برنامه نویسی استفاده شده در آن برنامه به‌ خصوص خیلی ارتقاء یافته اند. در چنین مواقعی حتماً می بایست به بررسی دقیق فریم ورک یا زبان برنامه نویسی مد نظر پرداخته تا ببینیم که آیا نسخه های جدید آن واقعاً بهبود یافته‌اند یا خیر. اگر واقعاً کمکی به بهبود عملکرد، نگهداری و راندمان نرم‌افزار می‌کردند که بایستی به بازنویسی کدها پرداخت و در غیر این صورت می بایست کدها را همان‌طور که هستند رها کرد. در پایان هم همواره به خاطر داشته باشید که آدم‌ها همیشه در معرض ارتکاب خطا هستند. بازنویسی کدها اصلاً بدان معنا نیست که کدهای جدید بهتر از کدهای قبلی یا به همان خوبی کدهای قبلی خواهند بود. From ff7cda9a973e14f03daf63452c6bc170e58f3496 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 25 Jan 2023 11:33:31 +0300 Subject: [PATCH 134/290] Update README.md --- fr-IR/thing_07/README.md | 22 +++++----------------- 1 file changed, 5 insertions(+), 17 deletions(-) diff --git a/fr-IR/thing_07/README.md b/fr-IR/thing_07/README.md index e0fc4dcf..3af487ea 100644 --- a/fr-IR/thing_07/README.md +++ b/fr-IR/thing_07/README.md @@ -1,21 +1,9 @@ -# Beware the Share +# نظافت را رعایت کنید! -It was my first project at the company. I'd just finished my degree and was anxious to prove myself, staying late every day going through the existing code. As I worked through my first feature I took extra care to put in place everything I had learned — commenting, logging, pulling out shared code into libraries where possible, the works. The code review that I had felt so ready for came as a rude awakening — reuse was frowned upon! +برخی از آدم‌های متشخص هستند که وقتی زباله ای را روی زمین مشاهده می کنند، بدون توجه به این که چه کسی آن را روی زمین انداخته، زباله را برداشته و در جایگاه مخصوص به آن می اندازند (البته این قضیه بیشتر در کشورهای جهان اول مشاهده می گردد!) به عبارت دیگر، چنین افراد خیر خواهی، فضایی تمیز برای سایر افرادی که در آن محیط حضور خواهند داشت آماده می سازند. جمله‌ای وجود دارد با این مضمون که «دنیا را برای نسل ها آتی به مکان بهتری نسبت به آنچه تحویل شما داده شده مبدل سازید.» -How could this be? All through college reuse was held up as the epitome of quality software engineering. All the articles I had read, the textbooks, the seasoned software professionals who taught me. Was it all wrong? +یک برنامه نویس خوب کسی است که وقتی کدهای یک برنامه نویس دیگر را تحویل می‌گیرد -فارغ از این که برنامه نویس قبلی چه کسی بوده- تمام تلاش خود را به کار خواهد بست تا کدها را بهبود بخشد و این در حالی است که این بهبود کار می‌تواند هم در زمینه بهبود راندمان کدها بوده و یا حتی در زمینه کامنت گذاری باشد. به نظر شما در چنین شرایطی نتیجه نهایی چه خواهد شد؟ -It turns out that I was missing something critical. +به نظر می‌رسد که اگر برنامه نویسان دنباله رو چنین رویکردی باشند، روز به روز کیفیت کدهایی که نوشته می‌شوند بیشتر خواهد شد تا جایی که وجود باگ در کدها به یک امر انتزاعی مبدل خواهد شد. حال ممکن است این سؤال برای شما پیش بیاید که اگر برنامه نویس قبلی به جای کدنویسی، … بود چه؟ در پاسخ به چنین سؤالی بایستی گفت که اصلاً نیاز نیست تا شما تمامی بخش‌های کد را بهبود ببخشید بلکه صرفاً نیاز است تا هر آنچه که از دست شما بر می‌آید را انجام دهید و یا حداقل کدهایی که به ماژول قبلی می افزایید را سعی کنید تمیز و مرتب بنویسید. این تمیز نویسی کدها می‌تواند به نام گذاری صحیح توابع و متغیرها، رعایت فاصله ها و … ختم گردد. -Context. - -The fact that two wildly different parts of the system performed some logic in the same way meant less than I thought. Up until I had pulled out those libraries of shared code, these parts were not dependent on each other. Each could evolve independently. Each could change its logic to suit the needs of the system's changing business environment. Those four lines of similar code were accidental — a temporal anomaly, a coincidence. That is, until I came along. - -The libraries of shared code I created tied the shoelaces of each foot to each other. Steps by one business domain could not be made without first synchronizing with the other. Maintenance costs in those independent functions used to be negligible, but the common library required an order of magnitude more testing. - -While I'd decreased the absolute number of lines of code in the system, I had increased the number of dependencies. The context of these dependencies is critical — had they been localized, it may have been justified and had some positive value. When these dependencies aren't held in check, their tendrils entangle the larger concerns of the system even though the code itself looks just fine. - -These mistakes are insidious in that, at their core, they sound like a good idea. When applied in the right context, these techniques are valuable. In the wrong context, they increase cost rather than value. When coming into an existing code base with no knowledge of the context where the various parts will be used, I'm much more careful these days about what is shared. - -Beware the share. Check your context. Only then, proceed. - -By [Udi Dahan](http://programmer.97things.oreilly.com/wiki/index.php/Udi_Dahan) \ No newline at end of file +در تیم های برنامه نویسی می بایست پس از اتخاذ رویکردی همچون آنچه در بالا به آن اشاره شد، فضایی ایجاد گردد که حتی اگر یکی از اعضای تیم خواست تا کدنویسی نامرتبی انجام دهد از سایر اعضای تیم خجالت کشیده و خود را اصلاح کند دقیقاً شبیه به شرایطی که در یک مهمانی مجلل اتفاق می افتد: آیا کسی رویش می‌شود که پس از خوردن خیار، پوست آن را روی پارکت پرتاب کند؟ هرگز. From 8a163d02607ee635edd32b511ec499c2ea4fc7d8 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 25 Jan 2023 11:34:49 +0300 Subject: [PATCH 135/290] Update README.md --- fr-IR/thing_08/README.md | 16 +++------------- 1 file changed, 3 insertions(+), 13 deletions(-) diff --git a/fr-IR/thing_08/README.md b/fr-IR/thing_08/README.md index b14af7dd..db4c74b3 100644 --- a/fr-IR/thing_08/README.md +++ b/fr-IR/thing_08/README.md @@ -1,15 +1,5 @@ -# The Boy Scout Rule +# پیش از آن که دیگران را متهم کنید، کد خود را چک کنید! -The Boy Scouts have a rule: "Always leave the campground cleaner than you found it." If you find a mess on the ground, you clean it up regardless of who might have made the mess. You intentionally improve the environment for the next group of campers. Actually the original form of that rule, written by Robert Stephenson Smyth Baden-Powell, the father of scouting, was "Try and leave this world a little better than you found it." +رفتاری رایج در میان اکثر برنامه نویسان دنیا این است که وقتی اسکریپتی می‌نویسند که کار نمی کند، پیش از هر چیز تقصیر را به گردن کامپایلر، وب سرویس و یا حتی سایر برنامه نویسان می‌اندازند که چنین رویکردی در اکثر مواقع نادرست است. اگرچه گاهی اوقات پیش می‌آید که مثلاً باگی در یک وب سرور مثل آپاچی به وجود می‌آید و همین مسأله منجر به بوجود آمدن مشکلی برای ما می‌شود، اما از آنجا که چنین نرم افزارهایی جهانی هستند و عدم وجود باگ در آن‌ها از اهمیت ویژه ای برخوردار است، توسعه دهندگان چنین نرم افزارهایی در اسرع وقت آن باگ را رفع خواهند کرد. لذا وقتی کد ما کار نمی کند، پیش از هر چیز و هر کس، می بایست انگشت اتهام را به سمت خودمان نگاه داریم … -What if we followed a similar rule in our code: "Always check a module in cleaner than when you checked it out." No matter who the original author was, what if we always made some effort, no matter how small, to improve the module. What would be the result? - -I think if we all followed that simple rule, we'd see the end of the relentless deterioration of our software systems. Instead, our systems would gradually get better and better as they evolved. We'd also see *teams* caring for the system as a whole, rather than just individuals caring for their own small little part. - -I don't think this rule is too much to ask. You don't have to make every module perfect before you check it in. You simply have to make it a *little bit better* than when you checked it out. Of course, this means that any code you *add* to a module must be clean. It also means that you clean up at least one other thing before you check the module back in. You might simply improve the name of one variable, or split one long function into two smaller functions. You might break a circular dependency, or add an interface to decouple policy from detail. - -Frankly, this just sounds like common decency to me — like washing your hands after you use the restroom, or putting your trash in the bin instead of dropping it on the floor. Indeed the act of leaving a mess in the code should be as socially unacceptable as *littering*. It should be something that *just isn't done*. - -But it's more than that. Caring for our own code is one thing. Caring for the team's code is quite another. Teams help each other, and clean up after each other. They follow the Boy Scout rule because it's good for everyone, not just good for themselves. - -by [Uncle Bob](http://programmer.97things.oreilly.com/wiki/index.php/Uncle_Bob) \ No newline at end of file +گاهی اوقات هم برای برنامه نویسان پیش می‌آید که با مشکلی مواجه می‌شوند و این در حالی است که ایشان از یک برنامه جدید متن باز که نسخه آن هم 0.1 است استفاده می کنند. در چنین شرایطی ایشان می‌توانند به عدم کارکرد صحیح نرم‌افزار یا سرویس مورد نظر خود شک کنند اما وقتی پای سرویس های با قدمت زیاد به میان می آید که گاها چندین میلیون کاربر در سرتاسر دنیا دارند، می بایست شکی به خود راه ندهیم که مشکل از خود ما است! From 20790bc4fced0005b997ed638bf5c20ead7015c7 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 25 Jan 2023 11:39:54 +0300 Subject: [PATCH 136/290] Update README.md --- fr-IR/thing_09/README.md | 32 ++++++++++++++++++++------------ 1 file changed, 20 insertions(+), 12 deletions(-) diff --git a/fr-IR/thing_09/README.md b/fr-IR/thing_09/README.md index 112231cb..89f47d45 100644 --- a/fr-IR/thing_09/README.md +++ b/fr-IR/thing_09/README.md @@ -1,22 +1,30 @@ -# Check Your Code First before Looking to Blame Others +# انتخاب ابزار مناسب -Developers — all of us! — often have trouble believing our own code is broken. It is just so improbable that, for once, it must be the compiler that's broken. +بسیاری از نرم‌افزارها و اپلیکیشن هایی که ما امروزه می‌بینیم و به موفقیت‌های نسبتاً خوبی هم دست پیدا کرده‌اند هرگز کدنویسی آن‌ها از صفر شروع نشده است بلکه این دست نرم‌افزارها با استفاده از ابزارهای موجود -در اینجا منظور از ابزار کامپوننت ها، کتابخانه ها، فریم ورک ها و … است- ساخته شده اند. در همین راستا، زمانی که قصد شروع پروژه ای را داریم حتماً می بایست مناسب‌ترین ابزارها را برای پروژه خود انتخاب کنیم و هرچه پروژه ما بزرگ‌تر باشد، لزوم تحقیق در این زمینه نیز بیشتر خواهد شد. -Yet in truth it is very (very) unusual that code is broken by a bug in the compiler, interpreter, OS, app server, database, memory manager, or any other piece of system software. Yes, these bugs exist, but they are far less common than we might like to believe. +در ارتباط با دلایلی که چرا برخی از پروژه ها از صفر کدنویسی نمی‌شوند و در آن‌ها از کامپوننت ها و کتابخانه‌های موجود استفاده می شود، می‌توان موارد زیر اشاره کرد: -I once had a genuine problem with a compiler bug optimizing away a loop variable, but I have imagined my compiler or OS had a bug many more times. I have wasted a lot of my time, support time, and management time in the process only to feel a little foolish each time it turned out to be my mistake after all. +1- نرم‌افزارها و اپلیکیشن ها در طول زمان رشد می کنند، پیچیده‌تر می‌شود و در نهایت نسبت به نسخه بتای خود به مراتب حرفه‌ای تر می‌شوند و این در حالی است که زمان اختصاص یافته برای توسعه این دست نرم‌افزارها و اپلیکیشن ها محدود و محدودتر می گردد. منطقی‌تر به نظر می‌رسد اگر برنامه نویسان بیشتر از آن که روی کدنویسی زیرساخت پروژه زمان صرف کنند (که در اکثر پروژه ها این زیرساخت تاحدودی مشابه است)، تمرکز خود را روی کدنویسی بخش‌های اختصاصی پروژه شان متمرکز سازند. -Assuming the tools are widely used, mature, and employed in various technology stacks, there is little reason to doubt the quality. Of course, if the tool is an early release, or used by only a few people worldwide, or a piece of seldom downloaded, version 0.1, Open Source Software, there may be good reason to suspect the software. (Equally, an alpha version of commercial software might be suspect.) +2- کامپوننت ها و فریم ورک هایی که در سرتاسر دنیا مورد استفاده قرار می‌گیرند به مراتب دارای باگ های کمتری نسبت به کدهایی هستند که یک برنامه نویس فریلنسر در اتاق کارش می نویسد! -Given how rare compiler bugs are, you are far better putting your time and energy into finding the error in your code than proving the compiler is wrong. All the usual debugging advice applies, so isolate the problem, stub out calls, surround it with tests; check calling conventions, shared libraries, and version numbers; explain it to someone else; look out for stack corruption and variable type mismatches; try the code on different machines and different build configurations, such as debug and release. +3- بسیاری از فریم ورک های موجود در بازار به صورت رایگان در اختیار توسعه دهندگان قرار می‌گیرد و همین مسأله حاکی از آن است که هزینه‌های مرتبط با توسعه یک پروژه به مراتب کاهش خواهد یافت. -Question your own assumptions and the assumptions of others. Tools from different vendors might have different assumptions built into them — so too might different tools from the same vendor. -When someone else is reporting a problem you cannot duplicate, go and see what they are doing. They may be doing something you never thought of or are doing something in a different order. +4- توسعه زیرساخت پروژه در زمینه‌های مختلف مثل امنیت، راندمان و … کاری حساس، دقیق، زمان بر و پرهزینه است اما اگر شما از کامپوننت های متن باز و رایگان استفاده کنید، می توانید از به روزرسانی به هنگام و ساختاری پروژه خود اطمینان حاصل کنید. -As a personal rule if I have a bug I can't pin down, and I'm starting to think it's the compiler, then it's time to look for stack corruption. This is especially true if adding trace code makes the problem move around. +به خاطر داشته باشید +توجه داشته باشیم که شرکت فیسبوک ابتدا برای برنامه نویسی این شبکه ی اجتماعی از زبان برنامه نویسی PHP استفاده کرد اما پس از آن که این شبکه جای خود را در میان کاربران باز کرد و به درآمدزایی هنگفتی دست یافت، مدیران این شرکت تصمیم گرفتند زبان اختصاصی این شرکت تحت عنوان Hack را توسعه داده و شبکه ی اجتماعی فیسبوک را روی آن بنا کنند. -Multi-threaded problems are another source of bugs to turn hair gray and induce screaming at the machine. All the recommendations to favor simple code are multiplied when a system is multi-threaded. Debugging and unit tests cannot be relied on to find such bugs with any consistency, so simplicity of design is paramount. +آنچه مسلم است این که انتخاب ترکیبی از ابزارهای موجود برای توسعه اپلیکیشن خود کاری حساس بوده و نیازمند برخورداری از تجربه در این زمینه است. برای همین منظور، راه کارهایی را در ادامه برای شما آورده‌ایم که می‌تواند به شما در انتخاب ابزار مد نظرتان کمک شایانی کند: -So before you rush to blame the compiler, remember Sherlock Holmes' advice, "Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth," and prefer it to Dirk Gently's, "Once you eliminate the improbable, whatever remains, no matter how impossible, must be the truth." +*- هر ابزاری در یک بستر خاص بهترین اثربخشی را خواهد داشت. منظور ما در اینجا از بستر عبارت است از ساختار دیتابیس، پروتوکل های ارتباطی، سرور،‌ وب سرویس، ای پی آی و … پس این احتمال وجود دارد ابزاری که شما انتخاب کرده‌اید با بستر توسعه نرم افزاری تان همخوانی نداشته باشد و همین مسأله منجر به پیچیده‌تر شدن پروژه شما خواهد شد. -By [Allan Kelly](http://programmer.97things.oreilly.com/wiki/index.php/Allan_Kelly) +*- ابزارهایی که امروزه مشاهده می‌کنیم از عمر مشخصی برخوردارند و زمانی که آپدیتی برای آن‌ها به بازار عرضه می‌شود و یا نسخه جدیدی از آن‌ها در دسترس توسعه دهندگان قرار می گیرد، ممکن است -اگر نگوییم حتماً همین‌طور است- شاهد تغییرات بسیاری نسبت به نسخه قدیمی باشیم که گاهی اوقات نسخه های جدید از یک ابزار خاص -مثلا یک فریم ورک برنامه نویسی- دارای تغییرات ساختاری زیادی نسبت به نسخه قبلی است که آن ها را اصلا غیر قابل مقایسه می کند. به طور مثال، فریم ورک برنامه نویسی تحت وب لاراول، در نسخه ۵ خود کاملاً ساختار این فریم ورک را تغییر داده و این در حالی است که اگر شما از نسخه ۴ این فریم ورک استفاده می‌کرده اید و حال قصد مهاجرت به آخرین نسخه را دارید، کل پروژه شما دستخوش تغییر خواهد شد (توجه داشته باشیم که هرچه تعداد فریم ورک ها و ابزارهای استفاده شده در پروژه ما بیشتر باشد، عمق این فاجعه هم بیشتر خواهد شد!) + +*- برخی از ابزارهای موجود نیازمند کانفیگ یا تنظیم کردن هستند که مسأله تنظیم کردن آن‌ها شاید نیازمند صرف وقت و هزینه قابل توجهی باشد. + +*- برخی از ابزارهای به اصطلاح رایگان آن طور که باید و شاید Free نیستند. در ابتدا ما تصور می‌کنیم که ابزار مد نظر ما کاملاً رایگان است و شروع به استفاده از آن می‌کنیم اما وقتی پروژه به جاهای حساس خود می‌رسد و نیازمند استفاده از کامپوننت های خاصی است، کاشف به عمل خواهد آمد که می بایست بخشی از سورس کد را از توسعه‌دهنده اصلی خریداری کنیم و همین مسأله می‌تواند آینده نرم‌افزار ما را تحت الشعاع قرار دهد. + +*- برخی از ابزارها پس از توسعه نرم‌افزار با آن‌ها برای ما محدودیت ایجاد می کنند. به طور مثال، برخی از لایسنس های نرم افزاری هستند که توسعه دهندگانی که از آن‌ها استفاده می‌کنند را ملزم به انتشار نرم افزارشان به علاوه سورس کد آن به صورت کاملا باز و رایگان می‌کنند که چنین محدودیتی مسلما برای خیلی از توسعه دهندگان خوشایند نخواهد بود! + +آنچه مسلم است این که تصمیم گیرنده نهایی خود شما خواهید بود لذا می بایست تا حد ممکن کدهایی که مرتبط با زیرساخت پروژه می‌شوند را با استفاده از بهترین ابزار یا فریم ورک موجود توسعه داده و کدهای مرتبط با ماژول اختصاصی پروژه خود را شخصاً کدنویسی کنید. From cc603ef4c7f961bc7333cd041b35e60366bbcf77 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 25 Jan 2023 11:42:18 +0300 Subject: [PATCH 137/290] Update README.md --- fr-IR/thing_10/README.md | 36 ++++++++++-------------------------- 1 file changed, 10 insertions(+), 26 deletions(-) diff --git a/fr-IR/thing_10/README.md b/fr-IR/thing_10/README.md index 8d08c3bc..bcb092f2 100644 --- a/fr-IR/thing_10/README.md +++ b/fr-IR/thing_10/README.md @@ -1,29 +1,13 @@ -# Choose Your Tools with Care +# برنامه های خود را به زبان مشتریان بنویسید! -Modern applications are very rarely built from scratch. They are assembled using existing tools — components, libraries, and frameworks — for a number of good reasons: +به عنوان یک برنامه نویس احتمالاً صاحبان صنایع و مشاغل مختلف به شما مراجعه می کنند و به شما سفارش کار می دهند. برای انجام این سفارشات که مربوط به فرآیند های کاری مشتریان می باشند، شما می توانید با استفاده از قابلیت های زبان های برنامه نویسی مختلف، آن فرآیند ها را مدل سازی کنید. به طور مثال ممکن است صاحب یک فروشگاه به شما سفارش برنامه ای برای کنترل کالاهای موجود در انبار فروشگاه بدهد. بنابراین شما باید یک انبار را مدل سازی کنید که کالاهای خریداری و ذخیره شده در آن ثبت شوند و بتوان وضعیت آن ها را تا زمانی که در انبار موجود باشند پیگیری کرد. توصیه ای که ما به شما داریم این است که در این موارد برنامه ی خود را به زبان مشتری سفارش دهنده بنویسید. -- Applications grow in size, complexity, and sophistication, while the time available to develop them grows shorter. It makes better use of developers' time and intelligence if they can concentrate on writing more business-domain code and less infrastructure code. +منظور از این که برنامه ی سفارشی خود را به زبان مشتری بنویسید این است که در کدهای برنامه از اصطلاحات کسب و کار مشتری استفاده کنید و روابط و رویه های کاری او را در برنامه پیاده سازی کنید. بگذارید با مثال هایی موضوع را شفاف تر سازیم. مثال فروشگاه را در نظر بگیرید. برای مدل سازی کالاهای خریداری شده، باید متغیری تعریف کنیم که نام کالای جدید را در آن ذخیره کنیم تا بعداً در بخش های دیگر برنامه از آن استفاده شود. می دانیم که برای تعریف هر متغیر یا Variable در برنامه نویسی، نیاز به یک اسم داریم. بهترین کار این است که به جای استفاده از یک نام بی معنی، مثلاً x، نامی را انتخاب کنیم که معرف این باشد که قرار است چه چیزی در متغیر مد نظرمان ذخیره شده و در عین حال برای مشتری هم شناخته شده باشد. به طور مثال این متغیر را new_product_name نام گذاری کنیم و با ورود هر کالای جدید آن را در این متغیر ذخیره کنیم، +``` +new_product_name = "Icecream" +// or +new_product_name = "Pen" +``` +در مورد رویه ها نیز به همین ترتیب عمل کنیم. مثلاً این طور نیست که کارکنان انبار تمام اجناس خریداری شده را در یک قسمت نگه داری کنند، بلکه متناسب با نوع محصول، آن ها را در بخش های مختلف انبار می کنند. مواد غذایی فاسد شدنی را در سردخانه، کرم ها را در بخش لوازم بهداشتی، پارچه ها را در بخش منسوجات و . . . وقتی نوبت به شما می رسد تا این رویه را مدل سازی کنید، شاید با خود فکر کنید در این مدل مجازی کنار هم قرار دادن کالاهایی مثل مواد غذایی، لوازم بهداشتی، و غیره تأثیری روی آن ها نمی گذارد. بنابراین به جای آن که با صرف زمان بیش تر و نوشتن کدهای بیش تر، نام این محصولات را در جداول جداگانه ای در دیتابیس قرار دهید، تصمیم می گیرید تمام آن ها را در یک جدول قرار داده تا در زمانی که بخواهید وضعیت یک محصول را بررسی کنید، کدهای برنامه به جای چند جدول دیتابیس، یک جدول را بیش تر در دیتابیس نگردند. شاید این کار برای شما راحت باشد، اما این نکته را در نظر داشته باشید که این برنامه برای صاحب فروشگاه است، نه شما! -- Widely used components and frameworks are likely to have fewer bugs than the ones developed in-house. - -- There is a lot of high-quality software available on the web for free, which means lower development costs and greater likelihood of finding developers with the necessary interest and expertise. - -- Software production and maintenance is human-intensive work, so buying may be cheaper than building. - -However, choosing the right mix of tools for your application can be a tricky business requiring some thought. In fact when making a choice, there are a few things you should keep in mind: - -- Different tools may rely on different assumptions about their context — e.g., surrounding infrastructure, control model, data model, communication protocols, etc. — which can lead to an architectural mismatch between the application and the tools. Such a mismatch leads to hacks and workarounds that will make the code more complex than necessary. - -- Different tools have different lifecycles, and upgrading one of them may become an extremely difficult and time-consuming task since the new functionality, design changes, or even bug fixes may cause incompatibilities with the other tools. The greater the number tools the worse the problem can become. - -- Some tools require quite a bit of configuration, often by means of one or more XML files, which can grow out of control very quickly. The application may end up looking as if it was all written in XML plus a few odd lines of code in some programming language. The configurational complexity will make the application difficult to maintain and to extend. - -- Vendor lock-in occurs when code that depends heavily on specific vendor products ends up being constrained by them on several counts: maintainability, performances, ability to evolve, price, etc. - -- If you plan to use free software, you may discover that it's not so free after all. You may need to buy commercial support, which is not necessarily going to be cheap. - -- Licensing terms matter, even for free software. For example, in some companies it is not acceptable to use software licensed under the GNU license terms because of its viral nature — i.e., software developed with it must be distributed along with its source code. - -My personal strategy to mitigate these problems is to start small by using only the tools that are absolutely necessary. Usually the initial focus is on removing the need to engage in low-level infrastructure programming (and problems), e.g., by using some middleware instead of using raw sockets for distributed applications. And then add more if needed. I also tend to isolate the external tools from my business domain objects by means of interfaces and layering, so that I can change the tool if I have to with just a small amount of pain. A positive side effect of this approach is that I generally end up with a smaller application that uses fewer external tools than originally forecast. - -By [Giovanni Asproni](http://programmer.97things.oreilly.com/wiki/index.php/Giovanni_Asproni) \ No newline at end of file +بهتر است که کدهای شما صریحاً رویه های ذخیره سازی در انبار را شبیه سازی کنند. مزیت این نوع کدنویسی صریح و مطابق با روال های کاری مشتری آن است که اولاً، تصحیح خطاها و تغییرات مورد نیاز در برنامه را برای شما راحت تر می کند (حتی اگر فراموش کنید هر قطعه از کد شما چه طور و برای چه منظوری کار می کند، می توانید به رویه های کاری مشتری رجوع کنید و الگوریتم آن را رمز گشایی کنید) ثانیاً، اگر برنامه نویس دیگری جایگزین شما شود تا سیستم موجود را به روز رسانی کند، از طریق آشنایی با این رویه های کاری، منظور کدهای شما را به راحتی درک می کند و نیازی نیست که به شما مراجعه کند تا آن ها را تفسیر کنید یا این که بخواهد برنامه ی جدیدی که برای خودش قابل فهم باشد را بازنویسی کند! From da2a2b5d3a44b14d60e227ef87ac1ee3d09be2ec Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 25 Jan 2023 17:55:14 +0300 Subject: [PATCH 138/290] Update README.md --- fr-IR/thing_11/README.md | 41 +++++++--------------------------------- 1 file changed, 7 insertions(+), 34 deletions(-) diff --git a/fr-IR/thing_11/README.md b/fr-IR/thing_11/README.md index 6cf4dd8f..58f2950c 100644 --- a/fr-IR/thing_11/README.md +++ b/fr-IR/thing_11/README.md @@ -1,40 +1,13 @@ -# Code in the Language of the Domain +# طرح‌های خود را بی‌نقص کنید -Picture two codebases. In one you come across: +در این مطلب قصد داریم در مورد یکی از بحران های کنونی در دنیای برنامه نویسی و طراحی نرم افزار صحبت کنیم. با پیشرفت تکنولوژی و افزایش وابستگی افراد و صنایع به کامپیوترها، جامعه ی برنامه نویسان با تقاضای فزاینده ای برای طراحی نرم افزارهای کاربردی مواجه شده اند. به طور طبیعی برنامه نویسی که بتواند کدهای خود را سریع تر بنویسند و نیازهای مشتریان بیش تری را پاسخگو باشد، بهره ی بیش تری از این بازار خواهد برد؛ اما همین موضوع سرعت انجام کارها مسئله ساز شده است و باید ببینیم این افزایش سرعت به چه قیمتی است. -``` -if (portfolioIdsByTraderId.get(trader.getId()) - .containsKey(portfolio.getId())) {...} -``` - -You scratch your head, wondering what this code might be for. It seems to be getting an ID from a trader object, using that to get a map out of a, well, map-of-maps apparently, and then seeing if another ID from a portfolio object exists in the inner map. You scratch your head some more. You look for the declaration of portfolioIdsByTraderId and discover this: +به خاطر داشته باشید که کدنویسی یک کار خلاقانه است و برنامه نویس در هر پروژه، طرحی نو خلق می کند. بنابراین برای خلق یک طرح باکیفیت و معتبر باید از قبل برنامه ریزی انجام شود، تمام جنبه های طرح به دقت بررسی شود، بهترین ابزارهایی که می توان برای اجرای طرح از آن ها استفاده کرد فراهم شوند، و در نهایت به دقت از تمام قابلیت ها و امکانات استفاده شود و پس از اتمام کار، نرم افزار طراحی شده را از جنبه های مختلف آزمود تا تمام باگ ها و نقص های آن برطرف شود. اما بحرانی که دنیای طراحی نرم افزارها با آن مواجه است این است که بسیاری از برنامه نویسان به دلیلی که در بالا به آن اشاره شد برای افزایش سرعت، این رویه ها را نادیده می گیرند. -``` -Map> portfolioIdsByTraderId; -``` +برخی از برنامه نویسان پس از قبول هر پروژه بلافاصله شروع به کدنویسی می کنند، بدون آن که طرح خاصی را در ذهن داشته باشند. در نوشتن هر قطعه از برنامه در لحظه به آن فکر می کنند که کدام دستور می تواند کار را پیش ببرد. بدون توجه به این که آیا کدهای نوشته شده از کیفیت و زیبایی لازم برخوردارند، و در صورتی که بتوانند تا حدودی به خواسته ی مد نظر مشتری دست یابند، کار را ادامه می دهند و تنها وقتی که به مشکلی برخورد کنند به تغییر کدها فکر می کنند. -Gradually you realise it might be something to do with whether a trader has access to a particular portfolio. And of course you will find the same lookup fragment — or more likely a similar-but-subtly-different code fragment — whenever something cares whether a trader has access to a particular portfolio. +در واقع در این موارد برنامه نویس از قابل دسترس ترین امکانات زبان برنامه نویسی مد نظر خود استفاده می کند تا کارش را سرهم بندی کند و به سرعت تحویل مشتری دهد. مشتری ها هم که غالباً چیزی از طراحی نرم افزار نمی دانند تنها به سرعت کار توجه می کنند، و در انتهای کار ناگزیر متحمل نتایجی ناقص و ناکامل می شوند! -In the other codebase you come across this: +شاید این نوع فعالیت ها در کوتاه مدت بتوانند بهره ای برای برنامه نویسان داشته باشند، اما باید بدانید که در بلند مدت برنامه نویسان حرفه ای را از برنامه نویسان غیر حرفه ای متمایز می سازند. بنابراین سعی کنید طرح های ماندگار و بااعتباری خلق کنید. ممکن است مشتری شما تا مدتی بعضی از قابلیت های نرم افزار را به کار نگیرد و درنتیجه متوجه نقایص احتمالی آن نشود، اما این وظیفه ی شما است که نرم افزار خود را به دقت بررسی کنید. -``` -if (trader.canView(portfolio)) {...} -``` - -No head scratching. You don't need to know how a trader knows. Perhaps there is one of these maps-of-maps tucked away somewhere inside. But that's the trader's business, not yours. - -Now which of those codebases would you rather be working in? - -Once upon a time we only had very basic data structures: bits and bytes and characters (really just bytes but we would pretend they were letters and punctuation). Decimals were a bit tricky because our base 10 numbers don't work very well in binary, so we had several sizes of floating-point types. Then came arrays and strings (really just different arrays). Then we had stacks and queues and hashes and linked lists and skip lists and lots of other exciting data structures *that don't exist in the real world*. "Computer science" was about spending lots of effort mapping the real world into our restrictive data structures. The real gurus could even remember how they had done it. - -Then we got user-defined types! OK, this isn't news, but it does change the game somewhat. If your domain contains concepts like traders and portfolios, you can model them with types called, say, Trader and Portfolio. But, more importantly than this, you can model *relationships between them* using domain terms too. - -If you don't code using domain terms you are creating a tacit (read: secret) understanding that *this* int over here means the way to identify a trader, whereas *that* int over there means the way to identify a portfolio. (Best not to get them mixed up!) And if you represent a business concept ("Some traders are not allowed to view some portfolios — it's illegal") with an algorithmic snippet, say an existence relationship in a map of keys, you aren't doing the audit and compliance guys any favors. - -The next programmer along might not be in on the secret, so why not make it explicit? Using a key as a lookup to another key that performs an existence check is not terribly obvious. How is someone supposed to intuit that's where the business rules preventing conflict of interest are implemented? - -Making domain concepts explicit in your code means other programmers can gather the *intent* of the code much more easily than by trying to retrofit an algorithm into what they understand about a domain. It also means that when the domain model evolves — which it will as your understanding of the domain grows — you are in a good position to evolve the code. Coupled with good encapsulation, the chances are good that the rule will exist in only one place, and that you can change it without any of the dependent code being any the wiser. - -The programmer who comes along a few months later to work on the code will thank you. The programmer who comes along a few months later might be you. - -By [Dan North](http://programmer.97things.oreilly.com/wiki/index.php/Dan_North) \ No newline at end of file +باید بدانید که طراحی یک نرم افزار کامل نمی شود مگر آن که از جنبه های مختلف کیفیت آن را تست کنید و کارایی آن را زمانی که منتشر می شود کنترل کنید. زبان ها و تکنیک های پیشرفته ی طراحی کمک بزرگی به شما می کنند تا طرح های کامل و بدون نقصی خلق کنید و این حقیقت را بدانید که صرف نظر از کدها، طرح های بزرگ و عالی توسط برنامه نویسان بزرگی ایجاد می شوند که خود را وقف خبرگی در حرفه ی خود کرده اند! From 016fd9c74c9ce4d369d1045fbf5804266dbd8870 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 25 Jan 2023 17:56:22 +0300 Subject: [PATCH 139/290] Update README.md --- fr-IR/thing_12/README.md | 21 ++++++++++----------- 1 file changed, 10 insertions(+), 11 deletions(-) diff --git a/fr-IR/thing_12/README.md b/fr-IR/thing_12/README.md index 31439994..eac01afe 100644 --- a/fr-IR/thing_12/README.md +++ b/fr-IR/thing_12/README.md @@ -1,17 +1,16 @@ -# Code Is Design +# به چیدمان کدها توجه کنید! -Imagine waking up tomorrow and learning the construction industry has made the breakthrough of the century. Millions of cheap, incredibly fast robots can fabricate materials out of thin air, have a near-zero power cost, and can repair themselves. And it gets better: Given an unambiguous blueprint for a construction project, the robots can build it without human intervention, all at negligible cost. +اگر تجربه ی کدنویسی برنامه های نسبتاً بزرگ را داشته باشید حتماً متوجه شده اید که بیش تر وقت خود را به جای نوشتن کدهای جدید صرف مرور کدهای قبلی کرده اید تا تغییراتی را که لازم است در آن ها اعمال کنید و اشکالات آن ها را رفع نمایید. یکی از فاکتورهای مهمی که سرعت و کارایی شما را در مرور کدها تعیین می کند چیدمان کدها (Code Layout) است. یک چیدمان خوب با تورفتگی های صحیح و قرار دادن میزان فضای سفید مناسب، تفاوت چشمگیری را در مدت زمانی که طول می کشد تا دستورات یک کد را بررسی کنید و منظور آن ها را بفهمید ایجاد می کند. در این آموزش قصد داریم راه کارهایی را برای بهینه سازی نحوه ی چیدمان و آرایش کدها مطرح کنیم. -One can imagine the impact on the construction industry, but what would happen upstream? How would the behavior of architects and designers change if construction costs were negligible? Today, physical and computer models are built and rigorously tested before investing in construction. Would we bother if the construction was essentially free? If a design collapses, no big deal — just find out what went wrong and have our magical robots build another one. There are further implications. With models obsolete, unfinished designs evolve by repeatedly building and improving upon an approximation of the end goal. A casual observer may have trouble distinguishing an unfinished design from a finished product. +پویش کدها را ساده تر کنید: +فرض کنید تیم شما برنامه ای نوشته است که چندین کلاس مختلف دارد. در هنگام اجرای کلاس های برنامه، برای کامپایلر تفاوتی ندارد که در بدنه ی کلاس ابتدا عناصر public تعریف شده اند یا عناصر private، یا این که ابتدا ثابت ها تعریف شوند یا فیلدها و یا متد ها؛ به عبارت دیگر، ترتیب قرار گرفتن اجزای یک کلاس برای کامپایلر تفاوتی ندارد، اما برای شما چه طور؟ -Our ability to predict time lines will fade away. Construction costs are more easily calculated than design costs — we know the approximate cost of installing a girder, and how many girders we need. As predictable tasks shrink toward zero, the less predictable design time starts to dominate. Results are produced more quickly, but reliable time lines slip away. +باید بدانید که افراد غالباً در تطبیق الگوهای بصری خوب هستند، بنابراین یکی از رویکردهایی که می توانید با دنبال کردن آن، مرور کدهای خود را آسان تر کنید این است که الگویی برای قرار دادن عناصر برنامه در کدهای خود تعریف کنید و تمام اعضای تیم در زمان کدنویسی بخش های مختلف برنامه از آن الگو پیروی کنند. به عنوان نمونه، می‌توان زبان برنامه نویسی پی اچ پی را مثال زد. سایتی تحت عنوان php-fig.org استانداردی تحت عنوان PSR که مخفف واژگان PHP Standard Recommendation است را برای برنامه نویسان پی اچ پی طراحی کرده که علاقمندان با استفاده از این استانداردها می توانند از کدهایی برخوردار شوند که سایر برنامه نویسان پی اچ پی با نگاه کردن به کدهای ایشان کمتر دچار سردرگمی شوند (لازم به ذکر است که در کدنویسی سکان آکادمی نیز از این استاندارد استفاده شده است.) -Of course, the pressures of a competitive economy still apply. With construction costs eliminated, a company that can quickly complete a design gains an edge in the market. Getting design done fast becomes the central push of engineering firms. Inevitably, someone not deeply familiar with the design will see an unvalidated version, see the market advantage of releasing early, and say "This looks good enough." +برای روشن تر شدن این مسئله، از سایر زبان های برنامه نویسی هم چند مثال می زنیم. اکثر برنامه نویسان ++C ابتدا تعریف متدهای public را در بدنه ی کدهای خود قرار می دهند و در زیر آن ها متدهای private را، در حالی که این رویه در کدنویسی به زبان #C کاملاً برعکس است. البته توجه کنید که ما این الگوها را به طور تجربی در زمان یادگیری هر زبان از منابع آموزش دهنده دریافت کرده و ناخواسته از آن ها تبعیت می کنیم و پیروی از آن ها باعث می شود سایر برنامه نویسان هم به راحتی کدهای ما را بخوانند، با این حال شما می توانید استاندارد مخصوصی برای خود تعریف کنید تا تمام اعضای تیم از آن تبعیت کنند. -Some life-or-death projects will be more diligent, but in many cases consumers learn to suffer through the incomplete design. Companies can always send out our magic robots to 'patch' the broken buildings and vehicles they sell. All of this points to a startlingly counterintuitive conclusion: Our sole premise was a dramatic reduction in construction costs, with the result that *quality got worse*. +چیدمان کدها را طوری تنظیم کنید که منظور کدها را برساند: +یکی از توصیه هایی که همیشه به برنامه نویسان می شود این است که در زمان نام گذاری کلاس ها، متغیرها، متدها، و سایر عناصر برنامه از اسامی با معنا استفاده کنند که تا حد ممکن نشان دهد که هر عنصر برنامه چه کاری انجام می دهد. باید بدانید که چیدمان کدها نیز باید به گونه ای باشد که تا جای ممکن منظور کدها را به روشنی مشخص کند. اگر شما کدهای خود را در یک ویرایش گر ساده ی متن بنویسید زحمت تنظیم چیدمان آن بر عهده ی خودتان است، اما امروزه بیش تر برنامه نویسان از محیط های توسعه ی یکپارچه (IDE) مثل اکلیپس استفاده می کنند که می توانند به صورت خودکار چیدمان کدها را تعیین می کنند. با این وجود توصیه ای که به شما داریم این است که همیشه در نظر داشته باشید که این ابزارها نمی توانند منظور شما را از کدهایی که نوشته اید بفهمند، بنابراین گاهی لازم است به صورت دستی تغییراتی را در چیدمان کدها ایجاد کنید تا منظور خود را شفاف سازید. -It shouldn't surprise us the above story has played out in software. If we accept that code is design — a creative process rather than a mechanical one — the *software crisis* is explained. We now have a *design crisis*: The demand for quality, validated designs exceeds our capacity to create them. The pressure to use incomplete design is strong. - -Fortunately, this model also offers clues on how we can get better. Physical simulations equate to automated testing; software design isn't complete until it is validated with a brutal battery of tests. To make such tests more effective we are finding ways to rein in the huge state space of large systems. Improved languages and design practices give us hope. Finally, there is one inescapable fact: Great designs are produced by great designers dedicating themselves to the mastery of their craft. Code is no different. - -By [Ryan Brush](http://programmer.97things.oreilly.com/wiki/index.php/Ryan_Brush) \ No newline at end of file +چیدمان خود را تا جای ممکن فشرده سازید: +اکثر برنامه نویسان زمانی که در یک محیط توسعه کد می زنند هر کامند یا دستوری را در یک خط جداگانه وارد می کنند، تا جایی که می بینیم بیش تر دستورات حتی تا پایان خط هم ادامه پیدا نمی کنند، بنابراین در پایان کار برنامه ای با خطوط زیادی کد و فضاهای خالی بی شمار دارند. با این حال باید بدانید که بهترین رویکرد این است که چیدمان خود را -تا جایی که به خوانایی کدها لطمه ای نزند- فشرده سازید. مزیت این کار آن است که حرکت میان کدها راحت تر و سریع تر می شود (به خصوص در برنامه های بزرگ)، یا به طور مثال در برنامه های تحت وب حجم داده هایی که از سمت سرور به کلاینت ها ارسال می شود و یا زمان لود شدن صفحات را کاهش می دهد. From e5e38d0af3456e6dece14c27fb51b19426cd6e77 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 25 Jan 2023 17:57:29 +0300 Subject: [PATCH 140/290] Update README.md --- fr-IR/thing_13/README.md | 30 ++++++++++++++++++++++-------- 1 file changed, 22 insertions(+), 8 deletions(-) diff --git a/fr-IR/thing_13/README.md b/fr-IR/thing_13/README.md index 7f9d7ca1..8d691201 100644 --- a/fr-IR/thing_13/README.md +++ b/fr-IR/thing_13/README.md @@ -1,15 +1,29 @@ -# Code Layout Matters +# نقد و بررسی کدها -An infeasible number of years ago I worked on a Cobol system where staff weren't allowed to change the indentation unless they already had a reason to change the code, because someone once broke something by letting a line slip into one of the special columns at the beginning of a line. This applied even if the layout was misleading, which it sometimes was, so we had to read the code very carefully because we couldn't trust it. The policy must have cost a fortune in programmer drag. +یکی از توصیه های مهمی که همواره به تیم های برنامه نویسی می شود برگزاری جلسات نقد و بررسی کدها است. بسیاری از سازمان ها و شرکت های نرم افزاری روی این موضوع تأکید ویژه ای دارند و برگزاری جلساتی از این دست در آیین نامه های فرآیند توسعه ی نرم افزاری آن ها آمده است و تبدیل به یک فرآیند رسمی اداری شده است، که تیم برنامه نویسی آن ها را ملزم به انجام این کار می کند. چنین تأکیدی دلالت بر اهمیت و کارایی این جلسات دارد. با این وجود، بیش تر تیم های برنامه نویسی به دلیل برخی مسائل تمایل زیادی به شرکت در این جلسات ندارند. در این آموزش قصد داریم به بررسی این مشکلات بپردازیم و راه کارهایی را برای برگزاری بهتر این جلسات ارائه دهیم. برنامه نویسانی که تجربه ی قبلی بدی در این زمینه داشته اند غالباً مسائلی از این دست را مطرح می کنند که: -There's research to show that we all spend much more of our programming time navigating and reading code — finding *where* to make the change — than actually typing, so that's what we want to optimize for. +- برخی انتقادات و نظرات در مورد کدها این احساس را در برنامه نویس ایجاد می کند که منتقد تنها قصد خراب کردن وجهه ی او را دارد و فرصتی را پیدا کرده است تا به شخصیت او حمله کند و کار او را به باد انتقاد بگیرد. -- *Easy to scan.* People are really good at visual pattern matching (a leftover from the time when we had to spot lions on the savannah), so I can help myself by making everything that isn't directly relevant to the domain, all the "accidental complexity" that comes with most commercial languages, fade into the background by standardizing it. If code that behaves the same looks the same, then my perceptual system will help me pick out the differences. That's why I also observe conventions about how to lay out the parts of a class within a compilation unit: constants, fields, public methods, private methods. +- برخی منتقدان به جای بررسی مسائل مهم و اساسی تنها روی ساختار و چیدمان کدها مثل نحوه ی تورفتگی ها تأکید می کنند. -- *Expressive layout.* We've all learned to take the time to find the right names so that our code expresses as clearly as possible what it does, rather than just listing the steps — right? The code's layout is part of this expressiveness too. A first cut is to have the team agree on an automatic formatter for the basics, then I might make adjustments by hand while I'm coding. Unless there's active dissension, a team will quickly converge on a common "hand-finished" style. A formatter cannot understand my intentions (I should know, I once wrote one), and it's more important to me that the line breaks and groupings reflect the intention of the code, not just the syntax of the language. (Kevin McGuire freed me from my bondage to automatic code formatters.) +- در بسیاری از مواقع منتقدان قبلاً کدها را مرور نکرده اند و بدون آمادگی قبلی وارد جلسه می شوند. -- *Compact format.* The more I can get on a screen, the more I can see without breaking context by scrolling or switching files, which means I can keep less state in my head. Long procedure comments and lots of whitespace made sense for 8-character names and line printers, but now I live in an IDE that does syntax coloring and cross linking. Pixels are my limiting factor so I want every one to contribute towards my understanding of the code. I want the layout to help me understand the code, but no more than that. +- گاهی تنها یک بخش نمونه از کدها بررسی شده و سایر بخش های مهم نادیده گرفته می شود. -A non-programmer friend once remarked that code looks like poetry. I get that feeling from really good code, that everything in the text has a purpose and that it's there to help me understand the idea. Unfortunately, writing code doesn't have the same romantic image as writing poetry. +- در برخی مواقع، تیم بررسی کدها را تا زمانی که بخش اصلی کدها کامل شود به تأخیر می اندازد و پس از آن به دلیل حجم زیاد اطلاعات، مرور کدها دیگر نه امکان پذیر است و نه اثربخش خواهد بود. -By [Steve Freeman](http://programmer.97things.oreilly.com/wiki/index.php/Steve_Freeman) +- در بعضی موارد چون اعضا با این دید وارد جلسه می شوند که قرار است تنها یک وظیفه ی اداری را به دستور مدیر انجام دهند، توجه چندانی به جریان جلسه ندارند و انرژی کافی را صرف پیش برد آن نمی کنند. + +- در برخی جلسات هم افرادی به جلسه دعوت می شوند که هیچ ارتباطی با پروژه ندارند و این موضوع کمی برای توسعه دهندگان نگران کننده است چرا که ممکن است نظرات خامی به زبان آورند! + +مسائلی از این دست به علاوه خیلی موارد دیگر، موجب عدم تمایل توسعه دهندگان برای شرکت در این جلسات می شود. بنابراین تیم های برنامه نویسی باید به دنبال راه کارهایی برای برطرف کردن این مشکلات باشند تا بتوانند از مزایای آن بهره ببرند. + +اولین نکته ای که در مورد جلسات نقد و بررسی باید مورد توجه قرار گیرد این است که هدف چنین جلساتی صرفاً پیدا کردن خطاهای موجود در کدها نیست، بلکه این جلسات باید با هدف به اشتراک گذاری دانش و آگاهی در میان اعضای تیم و برقراری راهبردهای مشترک کدنویسی برگزار شوند. به اشتراک گذاری کدها با سایر برنامه نویسان احساس مالکیت مشترک کدها را در افراد به وجود می آورد. به این ترتیب، هر کسی تلاش می کند در کنار سایرین روی کدها کار کند و به جای آن که صرفاً به دنبال خطاها و غلط گیری باشد سعی کند کدها را بفهمد و منظور و هدف آن ها را دریابد و در پیش برد و بهبود آن ها همکاری کند. + +در طی جلسه نقد و بررسی سعی کنید آرام باشید و نظرات خود را با ملایمت بیان کنید و احترام سایرین را حفظ کنید. مطمئن شوید که نقدهای شما سازنده باشد، نه این که با زبان تلخ و صرفاً برای کنایه زدن به دیگران بیان شوند. نقش های متفاوت را در جلسه ی بازنگری بشناسید تا به این ترتیب اجازه ندهید مثلاً نظر مدیر گروه صرفاً به این دلیل که جایگاه سازمانی بالاتری نسبت به سایرین دارد نظرات دیگران را تحت تأثیر قرار دهد یا مانع بیان حقیقت شود. برای مثال یک نوع از تقسیم نقش ها می تواند به این صورت باشد که یکی از اعضا روی مستند سازی، دیگری روی استثنائات، و نفر سوم روی کارکردها و قابلیت استفاده ی کدها متمرکز شود. این شیوه کمک می کند تا مسئولیت نقد و بررسی بر عهده ی همه ی اعضای گروه باشد و همه ی شرکت کنندگان جلسه فعال باشند. + +بازنگری کدها را به صورت مرتب در هر هفته انجام دهید. چند ساعت از وقت خود را صرف شرکت در این جلسات کنید. به صورت گردشی منتقدان را انتخاب کنید. به اعضای تازه وارد تیم هم اجازه دهید در این جلسات حضور فعال داشته باشند. شاید تجربه ی کاری آن ها کم باشد، با این حال چون این افراد غالباً به تازگی از دانشگاه فارغ التحصیل شده اند و دانش و آگاهی جدیدی دارند می توانند زاویه ی دید متفاوتی را در گروه ایجاد کنند. البته حضور اعضای حرفه ای و متخصص هم امری ضروری است تا از این طریق بتوانند دانش و تجربه منحصر به فرد خود را به سایرین منتقل کنند. چنین افرادی می توانند کدهای مستعد خطا را با سرعت و دقت بیش تری نسبت به سایرین پیدا کنند. + +اگر همه ی کدهای نوشته شده توسط تیم برنامه نویسی از قراردادها و استانداردهای تعریف شده ای پیروی کنند که بتوان آن ها را با ابزارهای خاصی کنترل کرد، جریان بازنگری و مرور کدها راحت تر و سریع تر پیش می رود و از این طریق، تیم در جلسه ی بررسی وقت خود را برای شکل دهی و فرمت بندی کدها تلف نمی کند. + +شاید مهم ترین چیزی که به تیم ها کمک می کند تا از مزایای چنین جلساتی بهره مند شوند تبدیل کردن یک جلسه ی خسته کننده و کسالت آور به یک جلسه ی پر نشاط و مفرح باشد. اگر اعضای جلسه احساس کنند که موقعیت آن ها تهدید می شود، به سختی می توان انگیزه ی شرکت در جلسات بعدی را در آن ها ایجاد کرد. جلسات بررسی کدها باید به صورت غیر رسمی و با هدف اصلی انتقال دانش و اطلاعات در میان اعضا برگزار شوند. هرکس باید سعی کند به جای اظهار نظر طعنه آمیز و تحریک کننده، جوی صمیمی و به دور از استرس را ایجاد کند. مطمئن باشید برگزاری جلسات در چنین فضایی کیفیت کدها را بهبود می بخشد، رعایت استانداردها را تضمین می کند، و به عنوان یک ابزار آموزشی ارزشمند دانش و تجربه ی توسعه دهندگان را بالاتر می برد. From 27149fb114aa3611cc0d5a03097ed630a5803a79 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 25 Jan 2023 17:59:35 +0300 Subject: [PATCH 141/290] Update README.md --- fr-IR/thing_14/README.md | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/fr-IR/thing_14/README.md b/fr-IR/thing_14/README.md index e96190c3..2799845b 100644 --- a/fr-IR/thing_14/README.md +++ b/fr-IR/thing_14/README.md @@ -1,15 +1,16 @@ -# Code Reviews +# کامنت‌گذاری را فراموش نکنید -You should do code reviews. Why? Because they *increase code quality* and *reduce defect rate*. But not necessarily for the reasons you might think. +یک برنامه ی کامپیوتری که به خوبی کدنویسی شده است باید این قابلیت را داشته باشد که خودش را به طور شفاف توضیح دهد که هر بخش اش چه کار می کند و رابطه ماژول های مختلف برنامه با یکدیگر به چه شکل است. به طور مثال، برنامه نویس می تواند با انتخاب اسامی مناسب و با معنا برای متغیرها، توابع، کلاس ها، و ...، و همچنین برای برقرار ساختن یک جریان منطقی در دستورات نوشته شده این امکان را فراهم سازد تا کدهای او برای سایر برنامه نویسان خوانا باشد. با این حال اگر مدتی از نوشتن کدها گذشته باشد خود برنامه نویس هم نمی تواند به راحتی و بلافاصله تنها با خواندن کدهایش هدف آن ها و این موضوع که کدها چه کاری انجام می دهند را بفهمد؛ بنابراین سایر برنامه نویسان هم حتماً در بررسی کدهای ایشان به منظور توسعه یا رفع باگ ها به مشکل بر خواهند خورند. این جا است که نقش توضیحاتی که در بدنه ی کدها قرار می گیرند یا همان Comment ها پر رنگ می شود و اضافه کردن آن ها در میان خطوط کدهای برنامه اهمیت ویژه ای برای برنامه نویسان پیدا می کند. -Because they may previously have had some bad experiences with reviews, many programmers tend to dislike code reviews. I have seen organizations that require that all code pass a formal review before being deployed to production. Often it is the architect or a lead developer doing this review, a practice that can be described as *architect reviews everything*. This is stated in their software development process manual, so therefore the programmers must comply. There may be some organizations that need such a rigid and formal process, but most do not. In most organizations such an approach is counterproductive. Reviewees can feel like they are being judged by a parole board. Reviewers need both the time to read the code and the time to keep up to date with all the details of the system. The reviewers can rapidly become the bottleneck in this process, and the process soon degenerates. +بیش تر زبان های برنامه نویسی جدید سطح بالا، ابزارهایی در خود دارند که به خوبی می توانند یک برنامه را مستند سازی کنند. اگرچه استفاده از آن ها یک شروع خوب برای شفاف کردن هدف برنامه است با این وجود قطعاً تمام نیازهای برنامه نویس را رفع نخواهند کرد. مستندسازی باید در سراسر خطوط نوشته شده انجام گیرد تا به وضوح نشان دهد هر قطعه کد چه کاری را انجام خواهد داد. برای آن که بتوانیم توضیحات مناسب را در برنامه ی خود بگنجانیم، باید با شیوه های استاندارد درج کامنت که مشخص می کنند آن ها باید در کدام قسمت از بدنه ی کدها قرار داده شوند و چه اطلاعاتی را در بر داشته باشند آشنا باشیم که در این جا به بعضی از این استایل های استاندارد اشاره می کنیم: -Instead of simply correcting mistakes in code, the purpose of code reviews should be to *share knowledge* and establish common coding guidelines. Sharing your code with other programmers enables collective code ownership. Let a random team member *walk through the code* with the rest of the team. Instead of looking for errors you should review the code by trying to learn it and understand it. +توضیحات سرآمد یا Header Comments: +هر برنامه باید با یک توضیح آغازین همراه باشد که به آن "توضیحات سرآمد" می گوییم. این توضیحات باید حاوی اطلاعاتی از این قبیل باشند: نام برنامه نویس، تاریخ، نام فایلی که برنامه در آن ذخیره می شود، توضیحی در مورد برنامه و نحوه ی اجرا و استفاده از آن. یکی از بهترین استراتژی ها برای نوشتن برنامه های بزرگ و پیچیده تقسیم کردن کدهای آن در مجموعه فایل های جداگانه ای به نام ماژول است که این کار بررسی و توسعه ی کدها را راحت تر می کند (به طور مثال، سکان آکادمی از ماژول های Application, Tutorial, Blog, Wiki, Jobs, Forum و ... تشکیل شده است.) در این صورت هر فایل نیاز به توضیحات سرآمد دارد که شامل این اطلاعات می شود: نام برنامه نویس، تاریخ، نام فایلی که کدها در آن ذخیره می شوند. هم چنین در این توضیحات باید نام فایل های دیگری که کدهای ماژول کنونی به آن ها وابسته هستند، مثلاً کلاسی را از فایل دیگری به ارث می برند را هم بیاورید. -Be gentle during code reviews. Ensure that comments are *constructive, not caustic*. Introduce different *review roles* for the review meeting, to avoid having organizational seniority among team members affect the code review. Examples of roles could include having one reviewer focus on documentation, another on exceptions, and a third to look at the functionality. This approach helps to spread the review burden across the team members. +توضیحات مربوط به توابع: +هر کلاس پیچیده به بخش های کوچک تری تقسیم می شود که به آن ها توابع می گویند و هر تابع مسئول انجام یک وظیفه ی خاص در برنامه است. پیش از معرفی هر تابع، توضیحاتی مربوط به آن نوشته می شود که اطلاعاتی از این قبیل را شامل می شود: تابع قرار است چه کاری را در برنامه انجام دهد، چه ورودی هایی لازم است که به تابع داده شود تا عملیات خود را اجرا کند، و این که تابع در نهایت چه تغییراتی را ایجاد می کند و خروجی آن چه خواهد بود یا اصطلاحاً این تابع چه چیزی را return می کند یا برمی گرداند. -Have a regular *code review* day each week. Spend a couple of hours in a review meeting. Rotate the reviewee every meeting in a simple round-robin pattern. Remember to switch roles among team members every review meeting too. *Involve newbies* in code reviews. They may be inexperienced, but their fresh university knowledge can provide a different perspective. *Involve experts* for their experience and knowledge. They will identify error-prone code faster and with more accuracy. Code reviews will flow more easily if the team has *coding conventions* that are checked by tools. That way, code formatting will never be discussed during the code review meeting. +توضیحات بین خطوط یا Inline Comments: +به غیر از توضیحات سرآمد، لازم است که کامنت هایی را هم در بدنه ی کدهای خود وارد کنید تا به توسعه دهندگان دیگر امکان تصحیح خطاها یا توسعه ی کدها را در آینده بدهند. این گونه توضیحات به دو گروه تقسیم می شوند: توضیحات خطی که در کنار یک خط از سورس کد می آیند و توضیحاتی در مورد آن خط از کد می دهند -مثلاً در یک خط متغیری از جنس عددی تعریف می شود و در توضیح آن، دامنه ای که می تواند اختیار کند را می آوریم- و یا کامنت های بلوکی که شبیه به توضیحات سرآمد، به طور کامل کاری را که یک بخش یا بلوک از کدهای برنامه انجام می دهد را توضیح می دهند. -*Making code reviews fun* is perhaps the most important contributor to success. Reviews are about the people reviewing. If the review meeting is painful or dull it will be hard to motivate anyone. Make it an *informal code review* whose prime purpose is sharing knowledge between team members. Leave sarcastic comments outside and bring a cake or brown bag lunch instead. - -by [Mattias Karlsson](http://programmer.97things.oreilly.com/wiki/index.php/Mattias_Karlsson) \ No newline at end of file +هشدار توجه داشته باشید که دقت کنید توضیحات شما تنها منظور کدهایتان را روشن کنند نه این که آن ها را تحت الشعاع قرار دهند. بسیاری از برنامه نویسان تازه کار حتی برای واضح ترین و ابتدایی ترین کدها هم کامنت می نویسند که این کاری بس اشتباه است! نوشتن توضیحات زیاد و مفصل می تواند به مانعی برای خوانایی کدهای شما در آینده تبدیل شود. From 0def1074a8f5d0ca87cfc72351cb181b887e4cf3 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 25 Jan 2023 18:03:12 +0300 Subject: [PATCH 142/290] Update README.md --- fr-IR/thing_15/README.md | 26 ++++++-------------------- 1 file changed, 6 insertions(+), 20 deletions(-) diff --git a/fr-IR/thing_15/README.md b/fr-IR/thing_15/README.md index 69af4e71..262fb356 100644 --- a/fr-IR/thing_15/README.md +++ b/fr-IR/thing_15/README.md @@ -1,25 +1,11 @@ -# Coding with Reason +# تنها توضیحاتی را بنویسید که کدهایتان قادر به شرح آنها نباشند! -Trying to reason about software correctness by hand results in a formal proof that is longer than the code and is more likely to contain errors than the code. Automated tools are preferable, but not always possible. What follows describes a middle path: reasoning semi-formally about correctness. +پیش از این در مورد "کامنت‌ گذاری را فراموش نکنید" در مورد لزوم افزودن کامنت به سورس کد برنامه ها و مستندسازی آن ها و برخی شیوه های استاندارد برای درج کامنت ها در برنامه ها صحبت کردیم. موضوع مهمی که در این میان وجود دارد توجه به این نکته است که با وجود تمام مزایایی که درج کامنت برای برنامه نویسان ایجاد می کند، گاهی استفاده ی نادرست از آن ها می تواند منجر به ناخوانایی کدها و حتی بروز برخی مشکلات شود. بنابراین آشنایی با نحوه ی کامنت گذاری صحیح اهمیت زیادی دارد و برنامه نویسان باید در کنار سایر مهارت های برنامه نویسی، مهارت نوشتن کامنت مناسب را هم کسب کنند. شاید بتوان گفت بخش عمده ای از این مهارت، آگاهی از این موضوع است که در کجا نباید از کامنت ها استفاده شود. -The underlying approach is to divide all the code under consideration into short sections — from a single line, such as a function call, to blocks of less than ten lines — and arguing about their correctness. The arguments need only be strong enough to convince your devil's advocate peer programmer. +اگر در ساختار کدها ایرادات و خطاهایی وجود داشته باشد، کامپایلرها، مفسرها و ابزارهایی از این قبیل آن ها را پیدا خواهند کرد. باگ های نرم افزاری هم توسط بازبین ها، تست کننده های نرم افزار، تحلیل گران -و حتی گاهی هم در زمان استفاده توسط کاربران- شناسایی شده و رفع می شوند. بنابراین اغلب نگرانی چندانی در مورد کدهایی که اجرا می شوند وجود ندارد، اما در مورد کامنت ها چنین نیست و از آن جا که این موارد در زمان اجرا نادیده گرفته می شوند، ممکن است وجود یک کامنت اشتباه در میان کدها که می تواند منجر به حواس پرتی و یا حتی ارائه ی اطلاعات غلط به برنامه نویس شود هرگز تشخیص داده نشود. -A section should be chosen so that at each endpoint the *state of the program* (namely, the program counter and the values of all "living" objects) satisfies an easily described property, and that the functionality of that section (state transformation) is easy to describe as a single task — these will make reasoning simpler. Such endpoint properties generalize concepts like *precondition* and *postcondition* for functions, and *invariant* for loops and classes (with respect to their instances). Striving for sections to be as independent of one another as possible simplifies reasoning and is indispensable when these sections are to be modified. +بعضی از کامنت ها از نظر فنی مشکلی ندارند با این حال هیچ ارزشی برای برنامه نویس ایجاد نمی کنند. مثلاً کامنت هایی که دقیقاً اطلاعاتی را که از خود کد می توان به دست آورد را تکرار می کنند و تنها باعث شلوغی برنامه می شوند. یکی از کاربردهای کامنت قرار دادن در سورس کد این است که اگر بخواهیم قطعه کد خاصی در برنامه اجرا نشود آن را تبدیل به کامنت می کنیم تا در زمان اجرا نادیده گرفته شود. وجود چنین کدهایی نیز برنامه را شلوغ می کند و هیچ ارزشی برای برنامه نویس نخواهد داشت. به این موارد، باید کامنت های مربوط به نسخه و تاریخچه ی نرم افزار را هم افزود، چرا که این موارد به صورت دقیق تر توسط ابزارهای کنترل نسخه مشخص می شوند. -Many of the coding practices that are well known (although perhaps less well followed) and considered 'good' make reasoning easier. Hence, just by intending to reason about your code, you already start thinking toward a better style and structure. Unsurprisingly, most of these practices can be checked by static code analyzers: +یکی از معایبی که وجود بیش از حد کامنت اشتباه یا بی ارزش دارد این است که باعث می شود برنامه نویس ترجیح دهد تمام کامنت ها را نادیده بگیرد و با استفاده از ابزارها و امکانات مختلف آن ها را بپوشاند یا از میان کدهای برنامه حذف کند تا درگیر خواندن توضیحات بی ارزش نشود. واضح است که این کار باعث از دست رفتن کامنت های ضروری و ارزشمند نیز می شود، بنابراین بهترین کار این است که در زمان درج کامنت، دقت کنیم که با آن ها مثل کدهای خود رفتار کنیم. تنها کامنت هایی را درج کنیم که ارزشی برای خواننده ی کدها داشته باشند و در غیر این صورت آن ها را حذف یا مجدداً اصلاح کنیم. -- Avoid using goto statements, as they make remote sections highly interdependent. -- Avoid using modifiable global variables, as they make all sections that use them dependent. -- Each variable should have the smallest possible scope. For example, a local object can be declared right before its first usage. -- Make objects *immutable* whenever relevant. -- Make the code readable by using spacing, both horizontal and vertical. For example, aligning related structures and using an empty line to separate two sections. -- Make the code self-documenting by choosing descriptive (but relatively short) names for objects, types, functions, etc. -- If you need a nested section, make it a function. -- Make your functions short and focused on a single task. The old *24-line limit* still applies. Although screen size and resolution have changed, nothing has changed in human cognition since the 1960s. -- Functions should have few parameters (four is a good upper bound). This does not restrict the data communicated to functions: Grouping related parameters into a single object benefits from *object invariants* and saves reasoning, such as their coherence and consistency. -- More generally, each unit of code, from a block to a library, should have a *narrow interface*. Less communication reduces the reasoning required. This means that *getters* that return internal state are a liability — don't ask an object for information to work with. Instead, ask the object to do the work with the information it already has. In other words, *encapsulation* is all — and only — about *narrow interfaces*. -- In order to preserve class *invariants*, usage of *setters* should be discouraged, as *setters* tend to allow invariants that govern an object's state to be broken. - -As well as reasoning about its correctness, arguing about your code gives you understanding of it. Communicate the insights you gain for everyone's benefit. - -By [Yechiel Kimchi](http://programmer.97things.oreilly.com/wiki/index.php/Yechiel_Kimchi) +وقتی صحبت از کامنت ارزشمند می کنیم، باید بدانیم چه چیزی ارزش آفرین است. مفهوم کامنت ارزشمند -در کدنویسی- به چیزی اطلاق می شود که بیان کننده ی مواردی است که کدها قادر به بیان آن نباشند. درج توضیحات می تواند انگیزه ای باشد برای تغییر ساختار کد و قراردادهای کدگذاری به طوری که کدها بتوانند نحوه ی کار خودشان را تشریح کنند. به طور مثال، شاید خواندن توضیحات مربوط به عملکرد یک کلاس یا تابع باعث شود نام مناسب تری برای آن انتخاب کنید که این نام گویای تمام توضیحات باشد. یا به جای توضیح در مورد بخش های مختلف یک تابع تلاش کنید آن را به توابع کوچکتری تقسیم کنید که نام هر یک از این توابع تمام توضیحات بخش های قبلی را بیان کند. در نهایت این که باید تلاش کنیم در کامنت های خود تنها نکات لازمی را بگنجانیم که کدها نمی توانند آن ها را بیان کنند، نه نکاتی را که کدها آن ها را بیان نکرده اند، و تا حد ممکن باید از ظرفیت کدها استفاده شود، آن گاه به سراغ کامنت گذاری برویم. From 85a0de51955208c30602b71f408a14413975aa19 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 25 Jan 2023 19:47:03 +0300 Subject: [PATCH 143/290] Update SUMMARY.md --- fr-IR/SUMMARY.md | 180 +++++++++++++++++++++++------------------------ 1 file changed, 90 insertions(+), 90 deletions(-) diff --git a/fr-IR/SUMMARY.md b/fr-IR/SUMMARY.md index 782cb57d..3e261801 100644 --- a/fr-IR/SUMMARY.md +++ b/fr-IR/SUMMARY.md @@ -1,100 +1,100 @@ -# Summary +# فهرست چیزها! -* [Introduction](README.md) -1. [Act with Prudence](thing_01/README.md) -1. [Apply Functional Programming Principles](thing_02/README.md) -1. [Ask "What Would the User Do?" (You Are not the User)](thing_03/README.md) -1. [Automate Your Coding Standard](thing_04/README.md) -1. [Beauty Is in Simplicity](thing_05/README.md) -1. [Before You Refactor](thing_06/README.md) -1. [Beware the Share](thing_07/README.md) -1. [The Boy Scout Rule](thing_08/README.md) -1. [Check Your Code First before Looking to Blame Others](thing_09/README.md) -1. [Choose Your Tools with Care](thing_10/README.md) -1. [Code in the Language of the Domain](thing_11/README.md) -1. [Code Is Design](thing_12/README.md) -1. [Code Layout Matters](thing_13/README.md) -1. [Code Reviews](thing_14/README.md) -1. [Coding with Reason](thing_15/README.md) -1. [A Comment on Comments](thing_16/README.md) -1. [Comment Only What the Code Cannot Say](thing_17/README.md) -1. [Continuous Learning](thing_18/README.md) -1. [Convenience Is not an -ility](thing_19/README.md) -1. [Deploy Early and Often](thing_20/README.md) -1. [Distinguish Business Exceptions from Technical](thing_21/README.md) -1. [Do Lots of Deliberate Practice](thing_22/README.md) -1. [Domain-Specific Languages](thing_23/README.md) -1. [Don't Be Afraid to Break Things](thing_24/README.md) -1. [Don't Be Cute with Your Test Data](thing_25/README.md) -1. [Don't Ignore that Error!](thing_26/README.md) -1. [Don't Just Learn the Language, Understand its Culture](thing_27/README.md) -1. [Don't Nail Your Program into the Upright Position](thing_28/README.md) -1. [Don't Rely on "Magic Happens Here"](thing_29/README.md) -1. [Don't Repeat Yourself](thing_30/README.md) -1. [Don't Touch that Code!](thing_31/README.md) -1. [Encapsulate Behavior, not Just State](thing_32/README.md) -1. [Floating-point Numbers Aren't Real](thing_33/README.md) -1. [Fulfill Your Ambitions with Open Source](thing_34/README.md) -1. [The Golden Rule of API Design](thing_35/README.md) -1. [The Guru Myth](thing_36/README.md) -1. [Hard Work Does not Pay Off](thing_37/README.md) -1. [How to Use a Bug Tracker](thing_38/README.md) -1. [Improve Code by Removing It](thing_39/README.md) -1. [Install Me](thing_40/README.md) -1. [Inter-Process Communication Affects Application Response Time](thing_41/README.md) -1. [Keep the Build Clean](thing_42/README.md) -1. [Know How to Use Command-line Tools](thing_43/README.md) -1. [Know Well More than Two Programming Languages](thing_44/README.md) -1. [Know Your IDE](thing_45/README.md) -1. [Know Your Limits](thing_46/README.md) -1. [Know Your Next Commit](thing_47/README.md) -1. [Large Interconnected Data Belongs to a Database](thing_48/README.md) -1. [Learn Foreign Languages](thing_49/README.md) -1. [Learn to Estimate](thing_50/README.md) -1. [Learn to Say "Hello, World"](thing_51/README.md) -1. [Let Your Project Speak for Itself](thing_52/README.md) -1. [The Linker Is not a Magical Program](thing_53/README.md) -1. [The Longevity of Interim Solutions](thing_54/README.md) -1. [Make Interfaces Easy to Use Correctly and Hard to Use Incorrectly](thing_55/README.md) -1. [Make the Invisible More Visible](thing_56/README.md) -1. [Message Passing Leads to Better Scalability in Parallel Systems](thing_57/README.md) -1. [A Message to the Future](thing_58/README.md) -1. [Missing Opportunities for Polymorphism](thing_59/README.md) -1. [News of the Weird: Testers Are Your Friends](thing_60/README.md) -1. [One Binary](thing_61/README.md) -1. [Only the Code Tells the Truth](thing_62/README.md) -1. [Own (and Refactor) the Build](thing_63/README.md) +* [مقدمه](README.md) +1. [ بدهی فنی](thing_01/README.md) +1. [به کار گیری اصولی توابع برنامه نویسی](thing_02/README.md) +1. [نیاز کاربر چیست؟](thing_03/README.md) +1. [ استاندارهای کدنویسی](thing_04/README.md) +1. [زیبایی در سادگی است](thing_05/README.md) +1. [قبل از انجام ریفکتورینگ دقت کنید](thing_06/README.md) +1. [در دستکاری کدها و منابع مشترک بین پروژه ها محتاط باشید.(نظافت را رعایت کنید!)](thing_07/README.md) +1. [پیش از آن که دیگران را متهم کنید، کد خود را چک کنید!](thing_08/README.md) +1. [انتخاب ابزار مناسب](thing_09/README.md) +1. [برنامه های خود را به زبان مشتریان بنویسید!](thing_10/README.md) +1. [طرح‌های خود را بی‌نقص کنید](thing_11/README.md) +1. [به چیدمان کدها توجه کنید!](thing_12/README.md) +1. [نقد و بررسی کدها](thing_13/README.md) +1. [کامنت‌گذاری را فراموش نکنید](thing_14/README.md) +1. [تنها توضیحاتی را بنویسید که کدهایتان قادر به شرح آنها نباشند!](thing_15/README.md) +1. [](thing_16/README.md) +1. [](thing_17/README.md) +1. [](thing_18/README.md) +1. [](thing_19/README.md) +1. [](thing_20/README.md) +1. [](thing_21/README.md) +1. [](thing_22/README.md) +1. [](thing_23/README.md) +1. [](thing_24/README.md) +1. [](thing_25/README.md) +1. [](thing_26/README.md) +1. [](thing_27/README.md) +1. [](thing_28/README.md) +1. [](thing_29/README.md) +1. [](thing_30/README.md) +1. [](thing_31/README.md) +1. [](thing_32/README.md) +1. [](thing_33/README.md) +1. [جاه طلبی خود را با شرکت در پروژه های متن باز برآروده کنید.](thing_34/README.md) +1. [قانون طلایی طراحی API](thing_35/README.md) +1. [اسطوره ها!](thing_36/README.md) +1. [کار سخت نتیجه همیشه بهترین نتیجه را نمی دهد](thing_37/README.md) +1. [چگونه از ابزارهای اشکال زدایی استفاده کنیم؟](thing_38/README.md) +1. [کد را با حذف آن بهبود دهید!](thing_39/README.md) +1. [من را نصب کن](thing_40/README.md) +1. [تعداد بالای فرآیندهای داخلی برنامه قطعاً روی کارایی برنامه تاثیر خواهند داشت](thing_41/README.md) +1. [نظافت را رعایت کنید](thing_42/README.md) +1. [نحوه استفاده از ابزارهای خط فرمان را بیاموزید](thing_43/README.md) +1. [بیش از دو زبان برنامه نویسی را به خوبی بلد باشید](thing_44/README.md) +1. [به IDE خود مسلط باشید](thing_45/README.md) +1. [محدودیت های خود را بشناسید](thing_46/README.md) +1. [با آگاهی از قدم بعدی قدم فعلی را بردارید](thing_47/README.md) +1. [داده های بزرگ به هم پیوسته متعلق به یک پایگاه داده](thing_48/README.md) +1. [زبان های خارجی را یاد بگیرید، حداقل انگلیسی](thing_49/README.md) +1. [تخمین زدن را بیاموزید](thing_50/README.md) +1. [گاهی مسائل و مشکلات بزرگ را به قسمت های کوچکتر بشکنید و با تکه های کوچک سعی و خطا کنید!](thing_51/README.md) +1. [طوری کد بزنید که پروژه ی شما خودش معرف خودش باشد](thing_52/README.md) +1. [لینکر (Linker) یک برنامه جادویی نیست](thing_53/README.md) +1. [طول عمر راه حل های موقت](thing_54/README.md) +1. [سعی کنید Interface ها را طوری بنویسید که برای استفاده ی صحیح آسان باشند و برای استفاده ی ناصحیح سخت!](thing_55/README.md) +1. [موارد نامرئی را بیشتر قابل مشاهده(شفاف سازی) کنید](thing_56/README.md) +1. [رد و بدل کردن مسیج ها منجر به مقیاس پذیری بهتر در سیستم های موازی می شود](thing_57/README.md) +1. [پیامی به آینده](thing_58/README.md) +1. [فرصت های از دست رفته برای چند ریختی یا Polymorphism](thing_59/README.md) +1. [اخبار عجیب و غریب : تستر دوست شماست!🤣](thing_60/README.md) +1. [یک باینری](thing_61/README.md) +1. [فقط کد حقیقت را می گوید](thing_62/README.md) +1. [صاحب شو و ریفکتور کن!](thing_63/README.md) 1. [Pair Program and Feel the Flow](thing_64/README.md) 1. [Prefer Domain-Specific Types to Primitive Types](thing_65/README.md) -1. [Prevent Errors](thing_66/README.md) -1. [The Professional Programmer](thing_67/README.md) -1. [Put Everything Under Version Control](thing_68/README.md) -1. [Put the Mouse Down and Step Away from the Keyboard](thing_69/README.md) -1. [Read Code](thing_70/README.md) -1. [Read the Humanities](thing_71/README.md) -1. [Reinvent the Wheel Often](thing_72/README.md) -1. [Resist the Temptation of the Singleton Pattern](thing_73/README.md) -1. [The Road to Performance Is Littered with Dirty Code Bombs](thing_74/README.md) -1. [Simplicity Comes from Reduction](thing_75/README.md) +1. [جلوگیری از خطاها](thing_66/README.md) +1. [برنامه نویس حرفه ای](thing_67/README.md) +1. [همه چیز را روی سییستم های کنترل نسخه قرار بدهید](thing_68/README.md) +1. [ماوس را زمین بگذارید و از صفحه کلید فاصله بگیرید!](thing_69/README.md) +1. [کد را بخوانید](thing_70/README.md) +1. [علوم انسانی بخوانید!](thing_71/README.md) +1. [گاهی چرخ را دوباره اختراع کنید](thing_72/README.md) +1. [در مقابل وسوسه الگوی Singleton مقاومت کنید](thing_73/README.md) +1. [مسیر(جاده ی) Performance مملو از بمب های کد کثیف است!](thing_74/README.md) +1. [سادگی از اختصار می آید(کم گوی و گزیده گوی!)](thing_75/README.md) 1. [The Single Responsibility Principle](thing_76/README.md) -1. [Start from Yes](thing_77/README.md) -1. [Step Back and Automate, Automate, Automate](thing_78/README.md) -1. [Take Advantage of Code Analysis Tools](thing_79/README.md) +1. [با بله هم میتوانید شروع کنید!](thing_77/README.md) +1. [گامی به عقب و خودکارسازی، خودکارسازی، خودکارسازی](thing_78/README.md) +1. [از مزایای ابزارهای تحلیل کد بهره ببرید](thing_79/README.md) 1. [Test for Required Behavior, not Incidental Behavior](thing_80/README.md) -1. [Test Precisely and Concretely](thing_81/README.md) -1. [Test While You Sleep (and over Weekends)](thing_82/README.md) +1. [به طور دقیق و مشخص تست کنید](thing_81/README.md) +1. [تست هنگام خواب (و آخر هفته ها)](thing_82/README.md) 1. [Testing Is the Engineering Rigor of Software Development](thing_83/README.md) 1. [Thinking in States](thing_84/README.md) -1. [Two Heads Are Often Better than One](thing_85/README.md) -1. [Two Wrongs Can Make a Right (and Are Difficult to Fix)](thing_86/README.md) +1. [دو تا مغز بهتر ایک مغز است!](thing_85/README.md) +1. [دو اشتباه می توانند یک بخش درست ایجاد کنند! (و رفع آنها دشوار است)](thing_86/README.md) 1. [Ubuntu Coding for Your Friends](thing_87/README.md) -1. [The Unix Tools Are Your Friends](thing_88/README.md) -1. [Use the Right Algorithm and Data Structure](thing_89/README.md) -1. [Verbose Logging Will Disturb Your Sleep](thing_90/README.md) +1. [ابزارهای یونیکس دوست شما هستند](thing_88/README.md) +1. [از الگوریتم و ساختار داده مناسب استفاده کنید](thing_89/README.md) +1. [لاگ بیش از حد خواب را از شما خواهد گرفت!](thing_90/README.md) 1. [WET Dilutes Performance Bottlenecks](thing_91/README.md) -1. [When Programmers and Testers Collaborate](thing_92/README.md) -1. [Write Code as If You Had to Support It for the Rest of Your Life](thing_93/README.md) +1. [زمانی که برنامه نویسان و تسترها با هم همکاری کنند!](thing_92/README.md) +1. [طوری کد بنویسید که انگار باید تا آخر عمر برای آن پشتیبانی بدهید](thing_93/README.md) 1. [Write Small Functions Using Examples](thing_94/README.md) -1. [Write Tests for People](thing_95/README.md) -1. [You Gotta Care about the Code](thing_96/README.md) -1. [Your Customers Do not Mean What They Say](thing_97/README.md) +1. [برای دیگران هم تست بنویسید](thing_95/README.md) +1. [به کدهایتان اهمیت بدهید](thing_96/README.md) +1. [منظور مشتریان شما چیزی نیست که می گویند!](thing_97/README.md) From 04ecfed4efdc60e82f556eeefb65f73cf279b526 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Mon, 6 Feb 2023 00:22:24 +0300 Subject: [PATCH 144/290] Update README.md --- fr-IR/thing_16/README.md | 24 ++++++++++++++++-------- 1 file changed, 16 insertions(+), 8 deletions(-) diff --git a/fr-IR/thing_16/README.md b/fr-IR/thing_16/README.md index be7c2e36..44eb49b8 100644 --- a/fr-IR/thing_16/README.md +++ b/fr-IR/thing_16/README.md @@ -1,15 +1,23 @@ -# A Comment on Comments +# از کدهای قبلی خود در شرایط مناسب مجدداً استفاده کنید -In my first programming class in college, my teacher handed out two BASIC coding sheets. On the board, the assignment read "Write a program to input and average 10 bowling scores." Then the teacher left the room. How hard could this be? I don't remember my final solution but I'm sure it had a `FOR/NEXT` loop in it and couldn't have been more than 15 lines long in total. Coding sheets — for you kids reading this, yes, we used to write code out longhand before actually entering it into a computer — allowed for around 70 lines of code each. I was very confused as to why the teacher would have given us two sheets. Since my handwriting has always been atrocious, I used the second one to recopy my code very neatly, hoping to get a couple extra points for style. +بسیاری از توسعه دهندگان حرفه ای نرم افزارها عادت دارند کدهایی بنویسند که اصطلاحاً Reusable یا دارای قابلیت استفاده ی مجدد باشند. وجود قابلیت استفاده ی مجدد در یک قطعه کد باعث می شود که بتوانیم در کدنویسی چندین برنامه ی مختلف از آن استفاده کنیم. وقتی می گوییم برنامه نویسان حرفه ای چنین قابلیتی را در کدهای خود وارد می کنند به نحوی مثبت بودن چنین چیزی را عنوان می کنیم، با این حال باید این موضوع به دقت بررسی شود و ببینیم که آیا این کاری تحت هر شرایطی درست است یا خیر؟ -Much to my surprise, when I received the assignment back at the start of the next class, I received a barely passing grade. (It was to be an omen to me for the rest of my time in college.) Scrawled across the top of my neatly copied code, "No comments?" +آیا استفاده ی مجدد از کدها همواره و تحت هر شرایطی مورد تأیید است؟ برای پاسخ به این سؤال باید از مزایا و معایب چنین کاری اطلاع پیدا کنیم و آن گاه با سبک و سنگین کردن شرایط، بین استفاده مجدد از کدهای از قبل نوشته شده و نوشتن کدهای جدید یکی را انتخاب کنیم. از این رو در این آموزش قصد داریم در مورد مزایا و معایب استفاده ی مجدد از کدها صحبت کنیم. -It was not enough that the teacher and I both knew what the program was supposed to do. Part of the point of the assignment was to teach me that my code should explain itself to the next programmer coming behind me. It's a lesson I've not forgotten. +مزایا +استفاده ی مجدد از کدها زمان کدنویسی را کاهش می دهد، که این امر موجب کاهش هزینه های یک پروژه ی برنامه نویسی خواهد شد. فرض کنید پیش از این خود شما یا تیم برنامه نویسی دیگری روی یک مسئله کار کرده و پاسخ بهینه ای برای آن یافته اید و اکنون این پاسخ در دسترس شما است. بنابراین دلیلی وجود ندارد که شما بخواهید مجدداً به دنبال جواب برای یک مسئله ی حل شده باشید. -Comments are not evil. They are as necessary to programming as basic branching or looping constructs. Most modern languages have a tool akin to javadoc that will parse properly formatted comments to automatically build an API document. This is a very good start, but not nearly enough. Inside your code should be explanations about what the code is supposed to be doing. Coding by the old adage, "If it was hard to write, it should be hard to read," does a disservice to your client, your employer, your colleagues, and your future self. +استفاده ی مجدد از کدهایی که قبلاً نوشته و امتحان شده اند باعث می شود میزان باگ های احتمالی برنامه تا حد زیادی کاهش پیدا کند. به طور کلی هر چه در یک برنامه خطوط کد بیش تری نوشته شود، احتمال وجود خطا در میان آن کدها بیش تر می شود. وقتی از یک قطعه کد در چندین برنامه ی مختلف استفاده می شود به نوعی بارها و بارها آن بخش مشترک در تمام برنامه ها تست می شود و به مراتب احتمال وجود خطا در آن کاهش پیدا می کند. -On the other hand, you can go too far in your commenting. Make sure that your comments clarify your code but do not obscure it. Sprinkle your code with relevant comments explaining what the code is supposed to accomplish. Your header comments should give any programmer enough information to use your code without having to read it, while your in-line comments should assist the next developer in fixing or extending it. +معمولاً کدهایی که قابلیت استفاده ی مجدد دارند در قالب کتابخانه های نرم افزاری جداگانه تقسیم بندی می شوند، به نحوی که هر برنامه نویس می تواند بر اساس نیاز خود از این کتابخانه های آماده استفاده کند. مزیت این کار در آن است که هر برنامه نویس می تواند با توجه به نقاط قوت خود در یک زمینه ی خاص به صورت تخصصی کدنویسی کند. به طور مثال متخصصین بخش امنیت می توانند روی کدهای مربوط به این حوزه کار کنند و با تولید کتابخانه های قدرتمند نرم افزاری در زمینه ی امنیت آن ها را با دیگر برنامه نویسان به اشتراک بگذارند، این در حالی است که مثلاً متخصصان UI روی مسائل مربوط به طراحی و بهینه سازی واسط های کاربری متمرکز می شوند. استفاده ی مجدد از کدها به طور مناسب و کارآمد می تواند به جلوگیری از تکرارهای غیر ضروری و دستورات زائد کمک کند. -At one job, I disagreed with a design decision made by those above me. Feeling rather snarky, as young programmers often do, I pasted the text of the email instructing me to use their design into the header comment block of the file. It turns out that managers at this particular shop actually reviewed the code when it was committed. It was my first introduction to the term *career-limiting move*. +معایب +با وجود تمام مزیت هایی که استفاده ی مجدد از کدها برای ما دارد بسته به شرایط مختلف امکان دارد این کار نه تنها فایده ای برای ما نداشته باشد، بلکه ضررهایی را هم به برنامه وارد کند. -by [Cal Evans](http://programmer.97things.oreilly.com/wiki/index.php/Cal_Evans) \ No newline at end of file +فرض کنید از یک کتابخانه از کدها در چند بخش مختلف از برنامه استفاده کنیم. این کار باعث می شود که وابستگی کدهای این بخش ها به هم زیاد شوند. اگر بخواهیم کدهای مشترک بعضی از این قسمت ها را تغییر دهیم یا اصلاح کنیم باید مراقب باشیم که این کار چه تأثیری روی سایر بخش ها می گذارد. + +این احتمال وجود دارد که کتابخانه یا فریم ورکی که می خواهید از آن در برنامه ی خود مجدداً استفاده کنید سرعتی پایین تر از حد انتظار داشته باشد و این بستگی به زبان برنامه نویسی یا پلتفرمی دارد که شما روی آن کار می کنید. + +اگر شما از کدهایی استفاده کنید که قبلاً توسط برنامه نویسان دیگر نوشته شده باشند مسائل مربوط به امنیت و میزان قابل اعتماد بودن آن ها و مسائل مربوط به مجوزهای استفاده مطرح می شود. به علاوه ارزیابی این کدها معمولاً زمان بر است و این امکان وجود دارد که شما بعد از گذشت یک زمان طولانی متوجه ضعف در طراحی و باگ های آن کدها شوید. + +مدیریت کدهایی که بین برنامه های مختلف به اشتراک گذاشته می شوند می تواند هزینه ی اضافی برای برنامه ایجاد کند. علاوه بر این، گاهی اوقات پیاده سازی و همگام سازی این کدها با کدهای خودتان بیش از حد زمان بر است و کار زیادی را طلب می کند. به هر حال شما به عنوان یک برنامه نویس باید این مهارت را پیدا کنید که با در نظر گرفتن تمام جوانب انتخاب کنید که آیا می خواهید چرخ را دوباره اختراع کنید، یا با کمی اصلاح و تطبیق آن با سورس کد خود، مجدداً از آن استفاده کنید. From d6636667c36318aef05a5cb38552539d895cb43d Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Mon, 6 Feb 2023 00:28:22 +0300 Subject: [PATCH 145/290] Update README.md --- fr-IR/thing_13/README.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/fr-IR/thing_13/README.md b/fr-IR/thing_13/README.md index 8d691201..d6877227 100644 --- a/fr-IR/thing_13/README.md +++ b/fr-IR/thing_13/README.md @@ -2,19 +2,19 @@ یکی از توصیه های مهمی که همواره به تیم های برنامه نویسی می شود برگزاری جلسات نقد و بررسی کدها است. بسیاری از سازمان ها و شرکت های نرم افزاری روی این موضوع تأکید ویژه ای دارند و برگزاری جلساتی از این دست در آیین نامه های فرآیند توسعه ی نرم افزاری آن ها آمده است و تبدیل به یک فرآیند رسمی اداری شده است، که تیم برنامه نویسی آن ها را ملزم به انجام این کار می کند. چنین تأکیدی دلالت بر اهمیت و کارایی این جلسات دارد. با این وجود، بیش تر تیم های برنامه نویسی به دلیل برخی مسائل تمایل زیادی به شرکت در این جلسات ندارند. در این آموزش قصد داریم به بررسی این مشکلات بپردازیم و راه کارهایی را برای برگزاری بهتر این جلسات ارائه دهیم. برنامه نویسانی که تجربه ی قبلی بدی در این زمینه داشته اند غالباً مسائلی از این دست را مطرح می کنند که: -- برخی انتقادات و نظرات در مورد کدها این احساس را در برنامه نویس ایجاد می کند که منتقد تنها قصد خراب کردن وجهه ی او را دارد و فرصتی را پیدا کرده است تا به شخصیت او حمله کند و کار او را به باد انتقاد بگیرد. +1- برخی انتقادات و نظرات در مورد کدها این احساس را در برنامه نویس ایجاد می کند که منتقد تنها قصد خراب کردن وجهه ی او را دارد و فرصتی را پیدا کرده است تا به شخصیت او حمله کند و کار او را به باد انتقاد بگیرد. -- برخی منتقدان به جای بررسی مسائل مهم و اساسی تنها روی ساختار و چیدمان کدها مثل نحوه ی تورفتگی ها تأکید می کنند. +2- برخی منتقدان به جای بررسی مسائل مهم و اساسی تنها روی ساختار و چیدمان کدها مثل نحوه ی تورفتگی ها تأکید می کنند. -- در بسیاری از مواقع منتقدان قبلاً کدها را مرور نکرده اند و بدون آمادگی قبلی وارد جلسه می شوند. +3- در بسیاری از مواقع منتقدان قبلاً کدها را مرور نکرده اند و بدون آمادگی قبلی وارد جلسه می شوند. -- گاهی تنها یک بخش نمونه از کدها بررسی شده و سایر بخش های مهم نادیده گرفته می شود. +4- گاهی تنها یک بخش نمونه از کدها بررسی شده و سایر بخش های مهم نادیده گرفته می شود. -- در برخی مواقع، تیم بررسی کدها را تا زمانی که بخش اصلی کدها کامل شود به تأخیر می اندازد و پس از آن به دلیل حجم زیاد اطلاعات، مرور کدها دیگر نه امکان پذیر است و نه اثربخش خواهد بود. +5- در برخی مواقع، تیم بررسی کدها را تا زمانی که بخش اصلی کدها کامل شود به تأخیر می اندازد و پس از آن به دلیل حجم زیاد اطلاعات، مرور کدها دیگر نه امکان پذیر است و نه اثربخش خواهد بود. -- در بعضی موارد چون اعضا با این دید وارد جلسه می شوند که قرار است تنها یک وظیفه ی اداری را به دستور مدیر انجام دهند، توجه چندانی به جریان جلسه ندارند و انرژی کافی را صرف پیش برد آن نمی کنند. +6- در بعضی موارد چون اعضا با این دید وارد جلسه می شوند که قرار است تنها یک وظیفه ی اداری را به دستور مدیر انجام دهند، توجه چندانی به جریان جلسه ندارند و انرژی کافی را صرف پیش برد آن نمی کنند. -- در برخی جلسات هم افرادی به جلسه دعوت می شوند که هیچ ارتباطی با پروژه ندارند و این موضوع کمی برای توسعه دهندگان نگران کننده است چرا که ممکن است نظرات خامی به زبان آورند! +7- در برخی جلسات هم افرادی به جلسه دعوت می شوند که هیچ ارتباطی با پروژه ندارند و این موضوع کمی برای توسعه دهندگان نگران کننده است چرا که ممکن است نظرات خامی به زبان آورند! مسائلی از این دست به علاوه خیلی موارد دیگر، موجب عدم تمایل توسعه دهندگان برای شرکت در این جلسات می شود. بنابراین تیم های برنامه نویسی باید به دنبال راه کارهایی برای برطرف کردن این مشکلات باشند تا بتوانند از مزایای آن بهره ببرند. From e5aac9bae2a83fc523aa44e085b0cf4ad735141d Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Mon, 6 Feb 2023 00:31:43 +0300 Subject: [PATCH 146/290] Update README.md --- fr-IR/thing_17/README.md | 40 +++++++++++++++++++++++++++++++++------- 1 file changed, 33 insertions(+), 7 deletions(-) diff --git a/fr-IR/thing_17/README.md b/fr-IR/thing_17/README.md index eb887df6..ee5e77dc 100644 --- a/fr-IR/thing_17/README.md +++ b/fr-IR/thing_17/README.md @@ -1,13 +1,39 @@ -# Comment Only What the Code Cannot Say +# همواره در حال یادگیری موضوعات جدید باشید -The difference between theory and practice is greater in practice than it is in theory — an observation that certainly applies to comments. In theory, the general idea of commenting code sounds like a worthy one: Offer the reader detail, an explanation of what's going on. What could be more helpful than being helpful? In practice, however, comments often become a blight. As with any other form of writing, there is a skill to writing good comments. Much of the skill is in knowing when not to write them. +زندگی ما در عصر تکنولوژی بسیار هیجان انگیز و جالب است. فناوری ها به سرعت در حال رشد هستند و هر روز اخباری از ابتکارات و دستاوردهای جدید در عرصه ی علم و تکنولوژی منتشر می شود. از سوی دیگر، شاهد آن هستیم که رشد تکنولوژی تأثیر زیادی هم در فرآیندهای یادگیری داشته است؛ به طور مثال اینترنت بستری را فراهم کرده است که کاربران را قادر می سازد به شبکه ی عظیمی از اطلاعات دسترسی پیدا کنند و با نوآوری های جدید آشنا شوند. -When code is ill-formed, compilers, interpreters, and other tools will be sure to object. If the code is in some way functionally incorrect, reviews, static analysis, tests, and day-to-day use in a production environment will flush most bugs out. But what about comments? In The *Elements of Programming Style* Kernighan and Plauger noted that "a comment is of zero (or negative) value if it is wrong." And yet such comments often litter and survive in a code base in a way that coding errors never could. They provide a constant source of distraction and misinformation, a subtle but constant drag on a programmer's thinking. +این سرعت بالای رشد علمی و دسترسی آسان تر به منابع علمی سبب افزایش تعداد رقبای شغلی به ویژه در میان برنامه نویسان شده است. آن چه بیش از هر چیز دیگر اهمیت دارد آن است که ما متوجه این تغییرات و پیشرفت ها باشیم و بدانیم برای ادامه ی کار و رقابت با دیگر برنامه نویسانی که در بازار برنامه نویسی مشغول به فعالیت هستند، لازم است که دانسته های خود را دائماً به روز کنیم که در غیر این صورت روزی دانش ما آن قدر قدیمی می شود که عملاً در هیچ جا کاربرد نخواهد داشت. -What of comments that are not technically wrong, but add no value to the code? Such comments are noise. Comments that parrot the code offer nothing extra to the reader — stating something once in code and again in natural language does not make it any truer or more real. Commented-out code is not executable code, so it has no useful effect for either reader or runtime. It also becomes stale very quickly. Version-related comments and commented-out code try to address questions of versioning and history. These questions have already been answered (far more effectively) by version control tools. +اگر به این باور رسیدیم که امروز هر اندازه هم که ما در کار خود حرفه ای باشیم در آینده ای نزدیک این سطح از اطلاعات و مهارت بسیار اندک خواهد بود و نسبت به سایر برنامه نویسان برای ما مزیت رقابتی ایجاد نخواهد کرد، باید به دنبال راه کارهایی برای افزایش دانش و مهارت خود باشیم. خوشبختانه برخی از کارفرمایان برای حمایت از منابع انسانی و کمک به کسب و کار خود با صرف هزینه و زمان اقدام به برگزاری دوره های آموزشی و بالا بردن سطح علمی و مهارتی نیروهای کار خود می کنند. با این حال شاید شما شانس کار با چنین تیم هایی را نداشته باشید و مجبور باشید خود به دنبال راه کاری برای یادگیری موضوعات جدید باشید. -A prevalence of noisy comments and incorrect comments in a code base encourage programmers to ignore all comments, either by skipping past them or by taking active measures to hide them. Programmers are resourceful and will route around anything perceived to be damage: folding comments up; switching coloring scheme so that comments and the background are the same color; scripting to filter out comments. To save a code base from such misapplications of programmer ingenuity, and to reduce the risk of overlooking any comments of genuine value, comments should be treated as if they were code. Each comment should add some value for the reader, otherwise it is waste that should be removed or rewritten. +در این جا قصد داریم بعضی از روش های کاربردی و منابع مفید را به شما معرفی کنیم تا بتوانید با استفاده از آن ها سطح دانش و مهارت خود را به عنوان یک برنامه نویس افزایش دهید. لیست این پیشنهادات به قرار زیر است: -What then qualifies as value? Comments should say something code does not and cannot say. A comment explaining what a piece of code should already say is an invitation to change code structure or coding conventions so the code speaks for itself. Instead of compensating for poor method or class names, rename them. Instead of commenting sections in long functions, extract smaller functions whose names capture the former sections' intent. Try to express as much as possible through code. Any shortfall between what you can express in code and what you would like to express in total becomes a plausible candidate for a useful comment. Comment what the code cannot say, not simply what it does not say. +1- کتاب و مجله بخوانید، از پست های وبلاگی، سایت ها، و فیدهای توئیتر که اخبار و موضوعات جدید حوزه ی نرم افزار و آی تی را بررسی می کنند بازدید کنید. سعی کنید پیوسته با جامعه ای از برنامه نویسان در ارتباط باشید. برای مثال طرح موضوعات جدید علمی در تالار گفتگوی سکان آکادمی و بحث و گفتگو با سایر برنامه نویسان در چنین محیط های مجازی می تواند سطح دانش عمومی را بالا ببرد. -By [Kevlin Henney](http://programmer.97things.oreilly.com/wiki/index.php/Kevlin_Henney) \ No newline at end of file +2- اگر واقعاً می خواهید با یک تکنولوژی جدید آشنا شوید، دست خود را به آن آلوده کنید! شروع به کدنویسی کنید. تلاش کنید با امتحان کردن نرم افزارهای جدید به آن ها مسلط شوید. + +3- سعی کنید همیشه با کسانی کار کنید که چیزی بیش تر از شما بدانند، چون کار کردن در کنار افراد با هوش تر و با تجربه تر و نظارت آن ها بر کار شما هم انگیزه ی یادگیری را در شما ایجاد می کند و هم در تعامل با آن ها می توانید درس های زیادی بیاموزید و اطلاعات مفیدی به دست آورید. وقتی شما تنها در کنار افرادی باشید که سطحی پایین تر از شما دارند، هم انگیزه ی رقابتی خود را برای یادگیری از دست می دهید و هم این که احتمالاً تمام وقت خود را باید صرف آموزش به آن ها کنید که به نوعی مانع یادگیری موضوعات جدید خواهد بود. + +4- از کمک منتورهای مجازی استفاده کنید. افراد شناخته شده ای در فضای وب فعالیت می کنند که نویسندگان و توسعه دهندگان بزرگی هستند. فعالیت ها و نوشته های آن ها را در وب سایت ها و وبلاگ های ایشان دنبال کنید. بسیاری از این افراد به سؤالات دیگران پاسخ می دهند و شما می توانید از راهنمایی چنین کسانی که شاید حتی در قاره ای دیگر زندگی کنند به صورت مجازی استفاده کنید. + +5- شروع به یادگیری دقیق فریم ورک ها و کتابخانه هایی که از آن ها استفاده می کنید نمایید. آگاهی از روش دقیق کار یک چیز باعث می شود بفهمید که چگونه می توانید استفاده ی بهتری از آن داشته باشید. اگر آن ها متن باز باشند که بخت با شما یار است. به جستجو در سورس کد آن ها بپردازید، چون به هر حال توسط افرادی با هوش و با تجربه نوشته شده اند و خواندن آن ها دید بهتری به شما خواهد داد و الهام بخش ایده های جدیدی در ذهن شما خواهد بود. سعی کنید سورس کد سایت هایی را که طراحی خوبی دارند مشاهده کنید تا با نحوه ی طراحی آن ها نیز آشنا شوید. + +6- زمانی که اشتباهی انجام می دهید، به باگی در میان کدهای خود برخورد می کنید، یا با مشکلی در کدنویسی برنامه ی خود مواجه می شوید سعی کنید بفهیمد واقعاً چه اتفاقی افتاده است. ممکن است قبل از شما کسی با چنین مشکلی رو به رو شده باشد و بعد از یافتن راه حل، آن را روی فضای اینترنت به اشتراک گذاشته باشد. در این موارد جستجو در گوگل -و همچنین جستجو در سایت Stack Overflow- به شما کمک زیادی خواهد کرد. به علاوه سعی کنید شما هم یافته های خود را در اختیار دیگران قرار دهید. + +7- به گفته ی یک طنزپردازی: "کسانی که بر موضوعی تسلط کامل دارند از آن استفاده می کنند و با آن کار می کنند و کسانی که چیزی از آن نمی دانند همان موضوع را درس می دهند!" واقعیت این است که یکی از راه های یادگیری یک موضوع تدریس آن و صحبت کردن در مورد آن موضوع است. وقتی قرار باشد عده ای مخاطب شما باشند و از شما در مورد مطلبی سؤال بپرسند، انگیزه ی زیادی را برای یادگیری در شما ایجاد خواهد کرد. سعی کنید در مورد موضوعات و تکنولوژی های جدید اطلاعات به دست آورید و این اطلاعات را در جمع دوستان و همکاران به دیگران منتقل کنید. + +8- موضوعی را که به آن علاقمند هستید انتخاب کنید و سعی کنید با گروهی از افراد به مطالعه ی جمعی آن موضوع بپردازید. مطمئن باشید بواسطه ی همکاری با دیگران و استفاده از نظرات و تجربیات آن ها تاثیر این یادگیری جمعی به مراتب بیش تر از یادگیری انفرادی است. خوشبختانه با ظهور شبکه های گسترده ی اجتماعی می توان این فعالیت ها را در قالب تیمی و به صورت مجازی انجام داد. + +9- شرکت در کنفرانس ها هم گزینه ی مناسبی برای اطلاع از یافته ها و موضوعات علمی جدید است. حتی اگر امکان حضور فیزیکی در چنین کنفرانس ها و سمینارهایی را ندارید می توانید بسیاری از آن ها را به صورت آنلاین و بدون پرداخت هیچ هزینه ای دنبال کنید. + +10- آیا تا به حال از ابزارهای تحلیل کدهای برنامه استفاده کرده اید، یا توجهی به پیغام های اخطار محیط توسعه ای که در آن کدنویسی می کنید داشته اید؟ یک راه مناسب برای یادگیری این است که بفهمید آن ها چه می گویند و چرا چنین تحلیل هایی را روی کدهای شما دارند. + +11- به این توصیه ی برنامه نویسان حرفه ای عمل کنید که می گویند هر سال یک زبان برنامه نویسی جدید یاد بگیرید. حداقل با یک ابزار یا تکنولوژی جدید آشنا شوید و شیوه ی به کارگیری آن را بیاموزید. دانش در مورد تکنولوژی های جدید ایده های تازه ای را برای استفاده ی بهتر از تکنولوژی های کنونی به شما خواهد داد. + +12- این روزها همه می دانند که صرف یادگیری زبان های برنامه نویسی یا دانش استفاده ازتکنولوژی های جدید برای شما مزیت رقابتی ایجاد نخواهد کرد. شما باید با حوزه ای که در آن کار می کنید آشنایی کامل داشته باشید تا بتوانید نیازهای مشتریان خود را بشناسید. آگاهی از این که چه طور کارکرد مؤثرتر و نقش سازنده تری در محیط کاری داشته باشید نیز مفید خواهد بود. برای مثال این روزها بیش تر شرکت ها به دنبال برنامه نویسانی هستند که در کنار مهارت های کدنویسی با روش های Agile یا چابک نیز آشنایی داشته باشند. + +13- اگر شما هم جزء کسانی باشید که بخش زیادی از زمان خود را در رفت و آمد و ترافیک شهری از دست می دهند، می توانید با گوش کردن به فایل های صوتی و پادکست های آموزشی که به وفور روی اینترنت قابل دسترسی هستند این زمان های تلف شده را تبدیل به فرصت مناسبی برای یادگیری و کسب اطلاعات جدید نمایید. + +14- شاید بد نباشد که به ادامه ی تحصیل در دانشگاه هم فکر کنید. گرچه بسیاری از افراد عقیده دارند دانشگاه های کشور بازدهی مطلوبی ندارند و خروجی آن ها برنامه نویسانی که آماده ی ورود به بازار کار باشند نیست، با این وجود باید بدانید که اولاً کلاس های دانشگاهی قطعاً یک پایه ی علمی مستحکم برای اطلاعات شما ایجاد می کنند، ثانیاً هر کدام از ما می توانیم با انگیزه و علاقه ی خود تا حد زیادی به پویایی محیط های دانشجویی و نزدیک کردن صنعت و دانشگاه کمک کنیم. + +به هر حال تکنولوژی به سرعت در حال تغییر است و اگر بخواهیم از این قافله عقب نمانیم باید در کنار کار زمانی را هم به یادگیری دانش و اطلاعات جدید اختصاص دهیم. این زمان هر اندازه هم که کم باشد، حتی در حد چند ساعت در هفته، می تواند نتایج مفیدی را به بار آورد. From ff6a269f470ea629f6e84277f36289f545a814d8 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Mon, 6 Feb 2023 00:48:52 +0300 Subject: [PATCH 147/290] Update README.md --- fr-IR/thing_18/README.md | 61 ++++++++++++++++++++++++++-------------- 1 file changed, 40 insertions(+), 21 deletions(-) diff --git a/fr-IR/thing_18/README.md b/fr-IR/thing_18/README.md index 335da53b..5f297905 100644 --- a/fr-IR/thing_18/README.md +++ b/fr-IR/thing_18/README.md @@ -1,28 +1,47 @@ -# Continuous Learning +# ویژگی‌های یک API با طراحی مناسب -We live in interesting times. As development gets distributed across the globe, you learn there are lots of people capable of doing your job. You need to keep learning to stay marketable. Otherwise, you'll become a dinosaur, stuck in the same job until, one day, you'll no longer be needed or your job gets outsourced to some cheaper resource. +امروزه بعید به نظر می رسد که کسی در دنیای برنامه نویسی دستی بر آتش داشته باشد اما اصطلاح API به گوش او نخورده باشد! اگر شما به عنوان یک برنامه نویس با ای پی آی ها کار کرده باشید از اهمیت آن ها مطلع هستید، با این حال سایر افراد ممکن است بپرسند که «اصلاً ای پی آی ها چه هستند و چرا تا این حد مورد توجه قرار می گیرند؟» در این آموزش به دنبال پاسخ دادن به این پرسش ها هستیم و می خواهیم ببینیم یک API خوش ساخت از چه ویژگی هایی برخوردار است. -So what do you do about it? Some employers are generous enough to provide training to broaden your skill set. Others may not be able to spare the time or money for any training at all. To play it safe, you need to take responsibility for your own education. +اگر بخواهیم تعریف ساده ای از API که مخفف عبارت Application Programming Interface ی «واسط برنامه نویسی اپلیکیشن»است داشته باشیم باید بگوییم که ای پی آی ها مجموعه مقرراتی هستند که مشخص می کنند چه طور یک اپلیکیشن می تواند با اپلیکیشن دیگری ارتباط برقرار کند. زمانی که از یک پی سی یا لپ تاپ استفاده می کنیم، ای پی آی ها همان چیزهایی هستند که انتقال اطلاعات را بین برنامه ها امکان پذیر می کنند، برای مثال ای پی آی های سیستمی، اجرای برنامه ای مانند آفیس ورد را روی سیستم عامل ویندوز امکان پذیر می سازند. -Here's a list of ways to keep you learning. Many of these can be found on the Internet for free: +همان طور که از نام API مشخص است، آن ها مانند یک رابط بین برنامه نویسان و یک اپلیکیشن هستند؛ به این صورت که اگر برنامه نویس برای پیش برد برنامه ی خود نیاز به اطلاعاتی از اپلیکیشن دیگری داشت، این واسط ها به او می گویند که می تواند برای دریافت چه اطلاعاتی درخواست دهد، چگونه درخواست خود را مطرح کند، و چگونه اطلاعات خود را دریافت کنند. در واقع API هر اپلیکیشن درخواست های مجاز را از سایر برنامه ها تحویل می گیرد، به اپلیکیشن مورد نظر می فرستد، آن گاه اطلاعات را دریافت می کند و تحویل برنامه های دیگر می دهد. +دروافع API ها در فضای وب هم برای سرویس هایی مانند گوگل مپ یا فیسبوک این امکان را فراهم می کنند تا این برنامه ها به اپلیکیشن های دیگر اجازه دهند که آن ها را اجرا کنند. برای مثال یک اپلیکیشن Yelp با استفاده از ای پی آی ها می تواند نزدیک ترین رستوران در اطراف کاربر را روی نقشه های گوگل مپ نشان دهد. یا یک اپ بازی می تواند با سرویس ابری دراپ باکس ارتباط برقرار کند تا تاریخچه ای از نتایج بازی های کاربر روی حافظه ی ابری این سرویس ذخیره شود، بدون آن که توسعه دهنده مجبور باشد یک ذخیره ساز ابری مخصوص اپلیکیشن خود طراحی کند. -- Read books, magazines, blogs, twitter feeds, and web sites. If you want to go deeper into a subject, consider joining a mailing list or newsgroup. -- If you really want to get immersed in a technology, get hands on — write some code. -- Always try to work with a mentor, as being the top guy can hinder your education. Although you can learn something from anybody, you can learn a whole lot more from someone smarter or more experienced than you. If you can't find a mentor, consider moving on. -- Use virtual mentors. Find authors and developers on the web who you really like and read everything they write. Subscribe to their blogs. -- Get to know the frameworks and libraries you use. Knowing how something works makes you know how to use it better. If they're open source, you're really in luck. Use the debugger to step through the code to see what's going on under the hood. You'll get to see code written and reviewed by some really smart people. -- Whenever you make a mistake, fix a bug, or run into a problem, try to really understand what happened. It's likely that somebody else ran into the same problem and posted it somewhere on the web. Google is really useful here. -- A really good way to learn something is to teach or speak about it. When people are going to listen to you and ask you questions, you'll be highly motivated to learn. Try a lunch-n-learn at work, a user group, or a local conference. -- Join or start a study group (à la patterns community) or a local user group for a language, technology, or discipline you are interested in. -- Go to conferences. And if you can't go, many conferences put their talks online for free. -- Long commute? Listen to podcasts. -- Ever run a static analysis tool over the code base or look at the warnings in your IDE? Understand what they're reporting and why. -- Follow the advice of [The Pragmatic Programmers](http://www.pragprog.com/titles/tpp/the-pragmatic-programmer) and learn a new language every year. At least learn a new technology or tool. Branching out gives you new ideas you can use in your current technology stack. -- Not everything you learn has to be about technology. Learn the domain you're working in so you can better understand the requirements and help solve the business problem. Learning how to be more productive — how to work better — is another good option. -- Go back to school. +اکنون باید ببینیم که ای پی آی ها چگونه این ارتباطات را امکان پذیر می کنند. در حقیقت ای پی آی ها با استفاده از روشی محدود شده و در چارچوب قوانینی خاص با "افشای" برخی از توابع داخلی یک برنامه به محیط خارج از آن تمام این کارها را انجام می دهند. با این کار بدون آن که نیاز باشد توسعه دهنده ها تمام سورس کدهای برنامه ی خود را در اختیار دیگران قرار دهند، اپلیکیشن ها می توانند با به اشتراک گذاری بخشی از داده ها با هم ارتباط برقرار کرده و تعامل داشته باشند. -It would be nice to have the capability that Neo had in The Matrix, and simply download the information we needed into our brains. But we don't, so it will take a time commitment. You don't have to spend every waking hour learning. A little time, say each week, is better than nothing. There is (or should be) a life outside of work. +درواقع API ها با محدود کردن دسترسی برنامه های خارجی به بخش خاصی از قابلیت های یک برنامه -که اغلب هم این سطح از دسترسی کافی است- تمام اطلاعات مورد نیاز سایر اپلیکیشن ها برای ارتباط با نرم افزار مورد نظر را فراهم می کنند. در حقیقت می توان API ها را هم چون پنجره ای به داخل یک برنامه تصور کرد. -Technology changes fast. Don't get left behind. +با توجه به تمام مثال هایی که از کاربرد API های مختلف بیان کردیم، به نظر می رسد که متوجه اهمیت آن ها در حوزه ی توسعه ی نرم افزار شده باشیم. همان طور که اعضای یک جامعه برای زندگی در کنار هم به یکدیگر نیاز دارند و باید با هم در تعامل باشند، هر چند که در بسیاری از موارد نیازی نیست یک شناخت عمیق از هم داشته باشند -مثلاً برای خرید سبزی، شما لازم نیست که در مورد زندگی خصوصی سبزی فروش محلتان اطلاعات داشته باشید، کافی است که بدانید چه کسی سبزی فروش است و مغازه ی او کجا است- این روزها اپلیکیشن های مختلف نیز به شدت نیاز به تعامل با هم دارند و برای این کار لازم است اطلاعاتی را در مورد هم داشته باشند. ای پی آی ها که تأمین کننده ی این اطلاعات هستند، علاوه بر حفظ امنیت اپلیکیشن ها، با فراهم کردن اطلاعات لازم و حذف داده های غیر ضروری، دقت و سرعت توسعه ی نرم افزارها را بالا می برند. حال باید ببینیم خصوصیات یک API خوب کدامند؟ می توان گفت که یک ای پی آی خوب، ای پی آی یی است که: -by [Clint Shank](http://programmer.97things.oreilly.com/wiki/index.php/Clint_Shank) \ No newline at end of file + - یادگیری آن آسان باشد؛ +- کاربرد آن حتی بدون استفاده از اسناد، باز هم آسان باشد؛ +- امکان استفاده ی نادرست از آن کم باشد؛ +- خوانایی و امکان نگهداری و پشتیبانی از کدهایی که از آن استفاده می کنند بالا باشد؛ +- برای رفع نیازهای ارتباطی نرم افزارهای دیگر با آن به اندازه ی کافی قدرتمند باشد؛ +- توسعه و گسترش آن ساده باشد؛ + +برای این که چنین خصوصیاتی را در یک ای پی آی ایجاد کنیم لازم است در زمان طراحی آن قواعدی را رعایت کنیم. از جمله این قواعد می توان به موارد زیر اشاره کرد: + +1- هر API یک وظیفه دارد و باید آن را به بهترین نحو ممکن انجام دهد. کارکرد یک API باید به گونه ای باشد که بتوان آن را به ساده ترین صورت ممکن بیان کرد. به طور مثال می گوییم وظیفه ی یک ای پی آی این است که امکان استفاده از شبکه ی اجتماعی یوتیوب را در داخل اپلیکیشن ها فراهم می کند. اگر نتوانید وظیفه ی یک API را به راحتی شرح دهید به این معنا است که مشکلی وجود دارد، و برای رفع آن می توانید طراحی ای پی آی را در قالب ماژول های کوچک تر پیاده سازی کنید، که هر کدام وظیفه ی خاصی داشته باشند. + +2- باید API تا حد ممکن کوچک باشند؛ هر چه اطلاعات کمتری افشا شود بهتر است. با این حال باید دقت داشته باشیم که ای پی آی طراحی شده حاوی تمام اطلاعات ضروری باشد. تنها به خاطر داشته باشید که همیشه امکان اضافه کردن اطلاعات وجود دارد، اما حذف اطلاعات افشا شده غیر ممکن است! + +3- این API ها نباید از پیاده سازی های مختلف تأثیر بگیرند. به عبارت دیگر، روش استفاده ی واحدی از آن API وجود داشته باشد. + +4- دسترسی ها به هر چیز را در پایین ترین سطح ممکن قرار دهید. کلاس ها و آبجکت ها را تا جای ممکن private کنید. کلاس های public نباید فیلدهای public داشته باشند (به استثنای ثابت ها). + +5- در زمان طراحی و ساخت API سعی کنید که از کاربران نهایی خود فیدبک بگیرید تا مطمئن شوید محصول نهایی شما تمام نیازهای معقول آن ها را برآورده می کند. به علاوه، باید بدانید که طراحی ای پی آی ها نیاز به یک کار تیمی دارد و به شدت پیشنهاد می شود که تمام اعضای تیم طراحی نرم افزار روی طراحی ای پی آی هم کار کنند. + +6- در طراحی API از تکرارهای بیش از حد اجتناب کنید. برای مثال اگر دو متد یک کار را انجام می دهند، نباید از هر دوی آن ها استفاده کنیم. این کار باعث سردرگمی کاربران می شود. + +7- از پروتکل امن SSL استفاده کنید. بیش تر کاربران از نقاط دسترسی غیر رمز گذاری شده برای دسترسی به اینترنت استفاده می کنند که امکان هک شدن آن ها را به راحتی فراهم می کند. + +نکته SSL مخفف واژگان Secure Sockets Layer به معنی «لایه ی سوکت های ایمن» یکی از پروتوکل های رمزنگاری استاندارد است که به منظور تأمین امنیت ارتباطات اینترنتی توسط شرکت Netscape به منظور انتقال داده‌های خصوصی از طریق اینترنت توسعه داده شد. این پروتوکل امنیت انتقال داده‌ها را در اینترنت برای مقاصدی همچون درگاه های بانک، تصدیق اطلاعات کاربری، انتقال اطلاعات هویتی و دیگر داده‌های حساس امکان پذیر می سازد. به طور خلاصه، کارکرد پروتوکل اس اس ال به این شکل است که مابین کاربر و سایت -که به طور معمول نماینده ی کاربر مرورگری است همچون فایرفاکس یا گوگل کروم و نماینده ی سایت هم وب سرور است- یک لینک رمزنگاری شده ایجاد می‌گردد. در شرایط عادی، اطلاعاتی از این دست به صورت Plain Text یا «متن ساده» مابین مرورگرها و وب سرورها رد و بدل می‌شوند که بسیار آسیب‌پذیر است اما در اس اس ال، کلیه ی داده های رمزنگاری می شوند و به طور کلی، یو آر ال هایی که نیاز به ارتباط اس اس ال دارند، به جای http، با https شروع می شوند. + +-از نوشتن مستندات غفلت نکنید. این موضوعی است که بسیاری از برنامه نویسان آن را نادیده می گیرند یا به درستی انجام نمی دهند. مستندات خود را به صورت دقیق و ساده تهیه کنید. بهترین تاکتیک برای این کار این است که فکر کنید می خواهید موضوع را برای یک کودک 10 ساله شرح دهید. از نوشتن در مورد هیچ مرحله ای اجتناب نکنید و هرگز این پیش فرض را نداشته باشید که چون موضوعی برای شما بدیهی است دیگران هم باید آن را بدانند. مستندسازی مناسب به ویژه در شرایطی که فرآیندها پیچیده اند کمک بزرگی به کاربران خواهد کرد. + +-واقع گرا باشید. به هر حال با وجود رعایت تمامی قواعد و مشورت اعضای تیم با یکدیگر باز هم امکان اشتباه و نادیده گرفتن یک سری مسائل وجود دارد. اما آن چه باید بدانید این است که در نهایت شما نمی توانید رضایت همه ی افراد را به دست آورید. + +در انتها باید این نکته را به شما یادآوری کنیم که هر چند API ها ابزارهایی سودمند در دست برنامه نویسان هستند اما استفاده از آن ها با چالش هایی همراه است. باید بدانید که اگر یک API امروز در دسترس کاربران قرار دارد دلیلی ندارد که این دسترسی برای همیشه وجود داشته باشد. برای مثال چند سال پیش شرکت توئیتر دسترسی کاربران را به ای پی آی های خود محدود کرد. + +علاوه بر این، کمپانی هایی که API های خود را در دسترس کاربران قرار می دهند ممکن است بعد از مدتی به ارائه ی خدمات خود پایان دهند. در این صورت اگر اپلیکیشن شما وابسته به API های این شرکت ها باشند با مشکل مواجه خواهند شد. برای مثال فرض کنید شرکت گوگل تصمیم بگیرد ارائه ی خدمات سرویس گوگل مپ را متوقف کند، در این صورت کار اپلیکیشن Yelp نیز متوقف خواهد شد. به هر حال با وجود تمام چالش هایی از این دست، توسعه دهندگان علاقه ی زیادی به استفاده از API ها دارند و هر روز شاهد گسترش ای پی آی های مختلف هستیم. From 431bff5d5d1e24606a056b575f05eed06d9933c5 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Mon, 6 Feb 2023 00:54:59 +0300 Subject: [PATCH 148/290] Update README.md --- fr-IR/thing_19/README.md | 37 ++++++++++++++++++++++++------------- 1 file changed, 24 insertions(+), 13 deletions(-) diff --git a/fr-IR/thing_19/README.md b/fr-IR/thing_19/README.md index 00c42feb..917baafb 100644 --- a/fr-IR/thing_19/README.md +++ b/fr-IR/thing_19/README.md @@ -1,21 +1,32 @@ -# Convenience Is not an -ility +# از ابتدای کار توسعهٔ اپلیکیشن خود روی فرآیند نصب و دیپلوی آن به طور پیوسته کار کنید -Much has been said about the importance and challenges of designing good API's. It's difficult to get right the first time and it's even more difficult to change later. Sort of like raising children. Most experienced programmers have learned that a good API follows a consistent level of abstraction, exhibits consistency and symmetry, and forms the vocabulary for an expressive language. Alas, being aware of the guiding principles does not automatically translate into appropriate behavior. Eating sweets is bad for you. +استقرار نرم افزار یا Software Deployment فرآیند آماده سازی یک برنامه برای نصب و پیکربندی آن روی سیستم های مشتریان است. یک اپلیکیشن جدید ممکن است روی سیستم شما که توسعه دهنده ی آن هستید به خوبی کار کند، اما این به معنای آن نیست که واقعا برای کار روی سایر سیستم ها آماده شده باشد. بسیاری از قابلیت ها وجود دارند که ممکن است شما اصلاً به آن ها احتیاج پیدا نکرده باید، با این حال سایر کاربران به آن ها نیاز دارند و شما مسئول ایجاد این قابلیت ها در نرم افزار خود هستید تا به نیاز مشتریانتان به خوبی پاسخ دهید. وجود این قابلیت ها از این نظر مهم است که نرم افزار شما را اصطلاحاً کاربر پسندتر می کند و به شما کمک خواهد کرد تا از سرقت نرم افزار خود جلوگیری کنید. در این آموزش به معرفی گام های فرآیند استقرار نرم افزار و برخی الزامات آن می پردازیم. -Instead of preaching from on high, I want to pick on a particular API design 'strategy,' one that I encounter time and again: the argument of convenience. It typically begins with one of the following 'insights:' +گفتیم فرآیند استقرار نرم افزار به تمام اقدامات لازمی اطلاق می شود که با انجام آن ها، کاربران می توانند به راحتی از یک نرم افزار استفاده کنند. از آن جا که هر سیستم نرم افزاری قابلیت های منحصر به فرد خود را دارا است، نمی توان در مورد پروسه ی دقیق هر فعالیت چیزی گفت. از این رو می توانیم دیپلویمنت نرم افزار را یک فرآیند کلی در نظر بگیریم که باید بر اساس خصوصیات و الزامات خاص هر سیستمی شخصی سازی شود. با این وجود می توانیم به طور خلاصه توضیحاتی کلی در مورد برخی از اقدامات این فرآیند به شرح زیر داشته باشیم: -- I don't want other classes to have to make two separate calls to do this one thing. -- Why should I make another method if it's almost the same as this method? I'll just add a simple switch. -- See, it's very easy: If the second string parameter ends with ".txt", the method automatically assumes that the first parameter is a file name, so I really don't need two methods. +توزیع یا Release:این فعالیت در حقیقت واسطی بین فرآیند توسعه و فرآیند دیپلویمنت نرم افزار است که شامل تمام عملیات مورد نیاز برای آماده سازی یک نرم افزار به منظور یکپارچه سازی و انتقال آن به سیستم کاربران می شود. بنابراین توزیع یک سیستم نرم افزاری باید تمام منابع لازم را به همراه داشته باشد تا نرم افزار به درستی روی سیستم کاربران اجرا شود. به طور کلی توزیع یک نرم افزار شامل پکیجی از اجزای مورد نیاز برای راه اندازی سیستم، توضیحات راهنما در مورد نحوه ی نصب سیستم، و اطلاعاتی در مورد خصوصیات، موارد استفاده و جامعه ی هدف سیستم نرم افزاری است. -While well intended, such arguments are prone to decrease the readability of code using the API. A method invocation like + نصب یا Installation: این مرحله اولین اقدام برای دیپلویمنت نرم افزار روی سیستم مشتریان است. معمولاً این مرحله پیچیده ترین مرحله ی دیپلویمنت نرم افزار است، چرا که برای این کار باید تمام منابع مورد نیاز برای استفاده از سیستم به طور مناسب گردآوری شوند. -``` -parser.processNodes(text, false); -``` +فعال سازی یا Activation : این فعالیت مربوط به راه اندازی اجزایی از سیستم می شود که برای اجرای نرم افزار مستقر شده ابتدا باید آن ها اجرا شوند. معمولاً فعال سازی با استفاده از پنجره های راهنما و آیکون ها و دکمه های گرافیکی طراحی شده صورت می گیرد. باید دقت داشته باشیم که در مرحله ی فعال سازی ممکن است نیاز به فعال بودن یک سری نرم افزارهای دیگر داشته باشیم. برای مثال اگر در این مرحله یک فایل فشرده ی زیپ داشته باشیم، برای باز کردن آن نیاز به یک نرم افزار نصب شده ی دیگر روی سیستم خواهیم داشت که فایل های زیپ را بخواند. -is virtually meaningless without knowing the implementation or at least consulting the documentation. This method was likely designed for the convenience of the implementer as opposed to the convenience of the caller — "I don't want the caller to have to make two separate calls" translated into "I didn't want to code up two separate methods." There's nothing fundamentally wrong with convenience if it's intended to be the antidote to tediousness, clunkiness, or awkwardness. However, if we think a bit more carefully about it, the antidote to those symptoms is efficiency, consistency, and elegance, not necessarily convenience. APIs are supposed to hide underlying complexity, so we can realistically expect good API design to require some effort. A single large method could certainly be more convenient to write than a well thought-out set of operations, but would it be easier to use? +غیر فعال سازی یا De-Activation :اقدامی درست بر خلاف فعالیت قبلی که اجرای تمام اجزای نرم افزار را متوقف می کند. این عملیات معمولاً قبل از فعالیت های دیگر فرآیند دیپلویمنت مانند به روز رسانی سیستم اتفاق می افتد. -The metaphor of API as a language can guide us towards better design decisions in these situations. An API should provide an expressive language, which gives the next layer above sufficient vocabulary to ask and answer useful questions. This does not imply it should provide exactly one method, or verb, for each question that may be worth asking. A diverse vocabulary allows us to express subtleties in meaning. For example, we prefer to say run instead of walk(true), even though it could be viewed as essentially the same operation, just executed at different speeds. A consistent and well thought out API vocabulary makes for expressive and easy to understand code in the next layer up. More importantly, a composable vocabulary allows other programmers to use the API in ways you may not have anticipated — a great convenience indeed for the users of the API! Next time you are tempted to lump a few things together into one API method, remember that the English language does not have one word for `MakeUpYourRoomBeQuietAndDoYourHomeWork`, even though it would seem really convenient for such a frequently requested operation. +به روز رسانی یا Update: این فعالیت در حقیقت حالت خاصی از نصب نرم افزار است که معمولاً پیچیدگی کم تری نسبت به عملیات نصب دارد، چرا که نرم افزار قبلاً یک بار روی سیستم نصب شده است. + +پاک کردن نرم افزار نصب شده یا De-Installation: زمانی پیش می آید که یک کاربر دیگر نیازی به یک نرم افزار ندارد و می خواهد آن را از سیستم خود پاک کند. در این شرایط باید تمام اجزای نصب شده به درستی غیر فعال شده، سپس از روی سیستم پاک شوند. در این مورد باید دقت لازم صورت بگیرد که آسیبی به سایر منابع و فایل های مشترک وارد نشود. + +منسوخ شدن یا Obsolescence: در نهایت یک نرم افزار پس از مدتی منسوخ می شود و سازندگانش دیگر از آن پشتیبانی نخواهند کرد. دقیقاً مانند زمانی که نسخه ی نصب شده را غیر فعال می شود، باید مراقب باشیم که مشکلی برای سایر اجزای سیستم به وجود نیاید. یکی از الزامات این کار این است که به کاربران زمان منسوخ شدن نرم افزار از پیش اطلاع داده شده باشد. + +به منظور استقرار یک اپلیکیشن در محیط سیستم مشتریان، مراحل بالا باید به طور دقیق طراحی و آزمایش شوند. از آن جا که تمام این اقدامات پس از توسعه ی یک نرم افزار روی سیستم کاربران صورت می گیرد، معمولاً طراحی و اشکال زدایی آن ها تا مراحل پایانی توسعه نرم افزار به تعویق می افتد. مسئولیت کدنویسی بخش مربوط به نصب نرم افزار در آخرین مرحله به یک مهندس توزیع محول می شود که به واسطه ی پیچیدگی های مربوط به آن، کار خود را با نارضایتی پیش می برد. نتیجه ی این کار این است که تیم نرم افزاری هیچ تجربه ای در مورد فرآیند دیپلویمنت نرم افزار یا محیط واقعی که نرم افزار در آن استقرار می یابد پیدا نمی کند، تا زمانی که بسیار دیر می شود و عملاً نمی توان تغییری را در سیستم اِعمال کرد یا نتیجه ی اِعمال تغییرات بسیار سنگین می شود. + +از آن جا که فرآیند نصب و دیپلویمنت اولین چیزی است که مشتری با آن رو به رو می شود، هر اندازه این فرآیند ساده تر باشد، کاربر نهایی راحت تر و با خطای کم تر می تواند نرم افزار شما را روی سیستم خود به کار گیرد، در نتیجه به نرم افزار اعتماد پیدا می کند و راحت تر برای پذیرش آن قانع می شود. + +زمانی که پروژه ی نرم افزاری خود را با کار روی عملیات نصب آغاز می کنید، فرصت بیش تری برای کار روی این فرآیند دارید، در نتیجه شانس این را دارید که هم زمان با توسعه ی نرم افزار بتوانید بخشی از کدهای برنامه را به منظور تسهیل فرآیند نصب تغییر دهید. اجرا و تست فرآیند نصب در یک محیط تمیز به صورت دوره ای خیال شما را از این بابت راحت خواهد کرد که فرآیند طراحی شده به قابلیت های منحصر به سیستم شما که روی آن نرم افزار را توسعه می دهید وابستگی ندارد، و روی هر سیستمی قابل راه اندازی و اجرا است. + +به تأخیر انداختن طراحی و تست اقدامات فرآیند دیپلویمنت نرم افزار به این معنا است که در مراحل پایانی با پیچیدگی های بیش تری رو به رو خواهید بود. به این دلیل که مجموعه ای از کدهای نرم افزار عملاً قابل تغییر نیستند، یا این که گاهی کدنویسی برنامه با فرضیاتی در مورد سیستم صورت گرفته است که منحصر به سیستم خاص شما است و برای کار روی سایر سیستم ها نیازمند تغییر است. + +اگرچه فکر کردن در مورد فرآیند دیپلویمنت نرم افزار و کار روی آن در همان آغاز پروژه توجیه اقتصادی ندارد و ارجحیت با این است که توسعه دهنده بتواند اپلیکیشنی را طراحی و توسعه دهد که در محیط توسعه، روی سیستم خودش به درستی اجرا شود؛ با این حال نکته ی اساسی در این است که شما نهایتاً زمانی می توانید از پروژه ی خود سود اقتصادی ببرید که بتوانید نسخه ی قابل نصب و اجرا را در اختیار مشتریان قرار دهید و آن ها بتوانند از نرم افزار کدنویسی شده به درستی روی سیستم خود استفاده کنند، در غیر این صورت هیچ کس برای اپلیکیشنی که کدهای آن تنها در یک IDE اجرا می شوند پولی پرداخت نخواهد کرد. + +به عنوان نکته ی پایانی باید به این مورد اشاره داشته باشیم که فرآیند نصب و دیپلویمنت نرم افزار نقش مهمی در میزان بهره وری مشتریان و تیم خدمات تخصصی شما دارد، بنابراین به همان نسبت که برای تست و دیباگ کردن سورس کد نرم افزار خود وقت صرف می کنید، روی آزمایش، ارزیابی، و اشکال زدایی فرآیند نصب و دیپلویمنت نرم افزار نیز زمان بگذارید. -By [Gregor Hohpe](http://programmer.97things.oreilly.com/wiki/index.php/Gregor_Hohpe) \ No newline at end of file From 9a76f213e0a108c9fd4dd2fdd1f1f26beeaebcfd Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Mon, 6 Feb 2023 09:36:25 +0300 Subject: [PATCH 149/290] Update SUMMARY.md --- fr-IR/SUMMARY.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/fr-IR/SUMMARY.md b/fr-IR/SUMMARY.md index 3e261801..694e0b6a 100644 --- a/fr-IR/SUMMARY.md +++ b/fr-IR/SUMMARY.md @@ -16,10 +16,10 @@ 1. [نقد و بررسی کدها](thing_13/README.md) 1. [کامنت‌گذاری را فراموش نکنید](thing_14/README.md) 1. [تنها توضیحاتی را بنویسید که کدهایتان قادر به شرح آنها نباشند!](thing_15/README.md) -1. [](thing_16/README.md) -1. [](thing_17/README.md) -1. [](thing_18/README.md) -1. [](thing_19/README.md) +1. [از کدهای قبلی خود در شرایط مناسب مجدداً استفاده کنید](thing_16/README.md) +1. [همواره در حال یادگیری موضوعات جدید باشید](thing_17/README.md) +1. [ویژگی‌های یک API با طراحی مناسب](thing_18/README.md) +1. [از ابتدای کار توسعهٔ اپلیکیشن خود روی فرآیند نصب و دیپلوی آن به طور پیوسته کار کنید](thing_19/README.md) 1. [](thing_20/README.md) 1. [](thing_21/README.md) 1. [](thing_22/README.md) From 7b11c6beb789d7ccbc8c11b852f9e8602d2bb810 Mon Sep 17 00:00:00 2001 From: Max Coplan Date: Wed, 1 Mar 2023 18:41:40 -0800 Subject: [PATCH 150/290] Fix online formatting to print version in the print version of the book, the word "is" is just italicized but in the online version it is bolded and surrounded by `*`s. This commit brings the online version more in line with the print version --- en/thing_83/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/en/thing_83/README.md b/en/thing_83/README.md index c3fe3d09..52ad01a5 100644 --- a/en/thing_83/README.md +++ b/en/thing_83/README.md @@ -6,6 +6,6 @@ Compared to "hard" engineering, the software development world is at about the s Testing "hard" things is tough because you have to build them to test them, which discourages speculative building just to see what will happen. But the building process in software is ridiculously cheap. We've developed an entire ecosystem of tools that make it easy to do just that: unit testing, mock objects, test harnesses, and lots of other stuff. Other engineers would love to be able to build something and test it under realistic conditions. As software developers, we should embrace testing as the primary (but not the only) verification mechanism for software. Rather than waiting for some sort of calculus for software, we already have the tools at our disposal to ensure good engineering practices. Viewed in this light, we now have ammunition against managers who tell us "We don't have time to test." A bridge builder would never hear from their boss "Don't bother doing structural analysis on that building — we have a tight deadline." The recognition that testing is indeed the path to reproducibility and quality in software allows us as developers to push back on arguments against it as professionally irresponsible. -Testing takes time, just like structural analysis takes time. Both activities ensure the quality of the end product. It's time for software developers to take up the mantle of responsibility for what they produce. Testing alone isn't sufficient, but it is necessary. Testing * **is** * the engineering rigor of software development. +Testing takes time, just like structural analysis takes time. Both activities ensure the quality of the end product. It's time for software developers to take up the mantle of responsibility for what they produce. Testing alone isn't sufficient, but it is necessary. Testing *is* the engineering rigor of software development. -By [Neal Ford](http://programmer.97things.oreilly.com/wiki/index.php/Neal_Ford) \ No newline at end of file +By [Neal Ford](http://programmer.97things.oreilly.com/wiki/index.php/Neal_Ford) From 934266f11f2c454622719312397c350af9f014ec Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 13:58:16 +0300 Subject: [PATCH 151/290] Added number 20 --- fr-IR/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fr-IR/SUMMARY.md b/fr-IR/SUMMARY.md index 694e0b6a..aedbf288 100644 --- a/fr-IR/SUMMARY.md +++ b/fr-IR/SUMMARY.md @@ -20,7 +20,7 @@ 1. [همواره در حال یادگیری موضوعات جدید باشید](thing_17/README.md) 1. [ویژگی‌های یک API با طراحی مناسب](thing_18/README.md) 1. [از ابتدای کار توسعهٔ اپلیکیشن خود روی فرآیند نصب و دیپلوی آن به طور پیوسته کار کنید](thing_19/README.md) -1. [](thing_20/README.md) +1. [مدیریت اکسپشن‌ها](thing_20/README.md) 1. [](thing_21/README.md) 1. [](thing_22/README.md) 1. [](thing_23/README.md) From 6af2e3be75f69936ee854fb8c791aba0a734a04f Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 13:58:29 +0300 Subject: [PATCH 152/290] Added number 20. --- fr-IR/thing_20/README.md | 19 ++++++++----------- 1 file changed, 8 insertions(+), 11 deletions(-) diff --git a/fr-IR/thing_20/README.md b/fr-IR/thing_20/README.md index e9596868..478ee176 100644 --- a/fr-IR/thing_20/README.md +++ b/fr-IR/thing_20/README.md @@ -1,15 +1,12 @@ -# Deploy Early and Often +# مدیریت اکسپشن ها -Debugging the deployment and installation processes is often put off until close to the end of a project. In some projects writing installation tools is delegated to a release engineer who take on the task as a "necessary evil." Reviews and demonstrations are done from a hand-crafted environment to ensure that everything works. The result is that the team gets no experience with the deployment process or the deployed environment until it may be too late to make changes. +یک Exception (اکسپشن یا استثناء) مشکلی است که در زمان اجرای برنامه رخ می دهد. زمانی که یک اکسپشن اتفاق می افتد جریان عادی برنامه مختل می شود و برنامه یا اپلیکیشن به طور غیر عادی پایان می یابد. -The installation/deployment process is the first thing that the customer sees, and a simple installation/deployment process is the first step to having a reliable (or, at least, easy to debug) production environment. The deployed software is what the customer will use. By not ensuring that the deployment sets up the application correctly, you'll raise questions with your customer before they get to use your software thoroughly. +برای جلوگیری از چنین پایان ناخواسته ای باید اکسپشن ها مدیریت یا هَندل شوند و عملیات لازم برای رفع مشکل انجام شود. از این رو در زمان رخ دادن یک اکسپشن آبجکتی تحت عنوان Exception Object ایجاد می شود که حاوی اطلاعاتی در مورد نوع و زمان ایجاد خطا در برنامه یا اپلیکیشن است، سپس این آبجکت در اختیار سیستم قرار می گیرد. از این مرحله به بعد، سیستم سعی می کند تا راهی برای رفع خطا پیدا کند. اگر سیستم قطعه کدی پیدا کند که بتواند خطای ایجاد شده را رفع کند، استفاده ی مجدد از سیستم امکان پذیر خواهد بود. پس لازم است در بخش هایی از برنامه که احتمال بروز اکسپشن وجود دارد از قبل آینده نگری شود و برای مدیریت اکسپشن ها برنامه ریزی و کدنویسی شود. رخ دادن یک اکسپشن می تواند دلایل زیادی داشته باشد که برخی از مهم ترین آن ها عبارتند از: +- کاربر داده ی نامعتبری وارد کرده است. +- برنامه برای اجرا نیاز به فایلی دارد که نمی تواند آن را پیدا کند و محتوای آن را بخواند. +- ارتباط با شبکه قطع می شود و یا حافظه ی دستگاه از دسترس خارج می شود. -Starting your project with an installation process will give you time to evolve the process as you move through the product development cycle, and the chance to make changes to the application code to make the installation easier. Running and testing the installation process on a clean environment periodically also provides a check that you have not made assumptions in the code that rely on the development or test environments. +برخی از این سناریوها به دلیل خطای کاربر، برخی بواسطه ی خطای برنامه نویس و دسته ای دیگر به خاطر نبود ریسورس کافی یا بهتر بگوییم «منابع فیزیکی» اتفاق می افتند. با این حال تمام این اکسپشن ها در دسته ی "خطاهای فنی" قرار می گیرند. در کنار این خطاها گروهی دیگری از اکسپشن ها وجود دارند که به واسطه ی برآورده نشدن Business Logic اتفاق می افتند. برای مثال فرض کنیم اپلیکیشنی طراحی شده است که به کاربران امکان خرید آنلاین می دهد. حال یکی از کاربران این اپلیکیشن بخواهد خریدی انجام دهد، اما اعتبار پولی کافی در حساب خود نداشته باشد. در این صورت یک شرایط استثناء اتفاق می افتد که مربوط به جنبه های فنی برنامه نمی شود، بلکه «منطق تجاری» برنامه این اجازه را به کاربر نمی دهد که با اعتبار ناکافی تراکنش خود را انجام دهد. -Putting deployment last means that the deployment process may need to be more complicated to work around assumptions in the code. What seemed a great idea in an IDE, where you have full control over an environment, might make for a much more complicated deployment process. It is better to know all the trade-offs sooner rather than later. - -While "being able to deploy" doesn't seem to have a lot of business value early on as compared to seeing an application run on a developer's laptop, the simple truth is that until you can demonstrate your application on the target environment, there is a lot of work to do before you can deliver business value. If your rationale for putting off a deployment process is that it is trivial, then do it anyway since it is low cost. If it's too complicated, or if there are too many uncertainties, do what you would do with application code: experiment, evaluate, and refactor the deployment process as you go. - -The installation/deployment process is essential to the productivity of your customers or your professional services team, so you should be testing and refactoring this process as you go. We test and refactor the source code throughout a project. The deployment deserves no less. - -By [Steve Berczuk](http://programmer.97things.oreilly.com/wiki/index.php/Steve_Berczuk) +نکته ای که باید در مورد اکسپشن ها رعایت شود این است که می بایست بین انواع فنی و عملی اکسپشن ها تمایز قائل شویم. با این کار، امکان این را خواهیم داشت که از مکانیزم های عمومی مدیریت اکسپشن ها در زبان های برنامه نویسی مختلف استفاده کرده و حتی برای مدیریت اکسپشن ها از برخی فریم ورک های نرم افزاری استفاده کنیم، اما در مورد اکسپشن های عملی باید کاربر حتما از شرایط استثنایی رخ داده شده آگاه شود و آماده ی مدیریت آن باشد، که در این موارد بهتر است یک اکسپشن جداگانه یا سلسله مراتب استثناء متمایز برای مدیریت اکسپشن ها در نظر گرفته شود تا کاربر بتواند بر اساس شرایط خود، آن ها را مدیریت کند. From 2b0127188fc67e7e77cfa7ce8c4a83c44ef5b7fe Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 14:01:08 +0300 Subject: [PATCH 153/290] Added number 21 --- fr-IR/thing_21/README.md | 23 ++++++++++++++--------- 1 file changed, 14 insertions(+), 9 deletions(-) diff --git a/fr-IR/thing_21/README.md b/fr-IR/thing_21/README.md index 591e1136..6bda166f 100644 --- a/fr-IR/thing_21/README.md +++ b/fr-IR/thing_21/README.md @@ -1,17 +1,22 @@ -# Distinguish Business Exceptions from Technical +# تمرین آگاهانه، لازمهٔ حرفه‌ای شدن است! -There are basically two reasons that things go wrong at runtime: technical problems that prevent us from using the application and business logic that prevents us from misusing the application. Most modern languages, such as LISP, Java, Smalltalk, and C#, use exceptions to signal both these situations. However, the two situations are so different that they should be carefully held apart. It is a potential source of confusion to represent them both using the same exception hierarchy, not to mention the same exception class. +فرض کنید شما در یک کلاس برنامه نویسی شرکت کرده اید، یا یک دوره ی برنامه نویسی، مانند دوره های آنلاین برنامه نویسی در سکان آکادمی را گذرانده اید. مطمئناً در این دوره ها با مفاهیم زیادی مثل استفاده از شرط ها و حلقه ها، اصول شیء گرایی، مدیریت اکسپشن ها و بسیاری موارد پایه ای دیگر آشنا شده اید. به علاوه در هر کدام از این دوره ها با جزئیات عملی زیادی مثل این که در زبان پایتون برای بلوک بندی قطعه کدها به جای کروشه از تورفتگی استفاده می کنیم، یا این که زبان جاوا نسبت به حالت حروف حساس است آشنا شده اید. -An unresolvable technical problem can occur when there is a programming error. For example, if you try to access element 83 from an array of size 17, then the program is clearly off track, and some exception should result. The subtler version is calling some library code with inappropriate arguments, causing the same situation on the inside of the library. +با وجود آشنایی با تمام این مفاهیم و جزئیات عملی ممکن است شما باز هم نتوانید یک اپلیکیشن خوب توسعه دهید. دلیل این موضوع این است که دانش مفاهیم نظری پایه ی کار برای شروع برنامه نویسی است، با این حال تنها تمرین کردن و تمرین کردن و تمرین کردن در کدنویسی و کسب مهارت است که از شما یک برنامه نویس حرفه ای می سازد. -It would be a mistake to attempt to resolve these situations you caused yourself. Instead we let the exception bubble up to the highest architectural level and let some general exception-handling mechanism do what it can to ensure the system is in a safe state, such as rolling back a transaction, logging and alerting administration, and reporting back (politely) to the user. +هیچ جایگزینی برای تمرین وجود ندارد. شما نمی توانید به خودتان بگویید که خب من یک منبع خوب برای یادگیری برنامه نویسی پیدا کردم و با مطالعه ی آن تا دو هفته ی دیگر تبدیل به یکی از خبرگان برنامه نویسی می شوم. بدون تمرین مفاهیم نظری هم به سرعت فراموش خواهند شد. با این حال همان طور که اگر برای یادگیری مفاهیم نظری استاد خوب و منابع درسی کاملی در دست داشته باشید می توانید با سرعت بیش تری مطالب را بفهمید و یاد بگیرید، در مورد یادگیری مهارت های عملی نیز راه هایی وجود دارد که می توانید با استفاده از آن ها سرعت خود را بیش تر کنید، یا اگر بخواهیم به طور دقیق تر صحبت کنیم با استفاده از این روش ها شما وقت خود را برای تمرین های بیهوده که تأثیری در مهارت آموزی شما نخواهند داشت تلف نخواهید کرد. -A variant of this situation is when you are in the "library situation" and a caller has broken the contract of your method, e.g., passing a totally bizarre argument or not having a dependent object set up properly. This is on a par with accessing 83rd element from 17: the caller should have checked; not doing so is a programmer error on the client side. The proper response is to throw a technical exception. +Deliberate Practice یا «تمرین آگاهانه» تکنیک قدرتمندی است که به شما این اطمینان را می دهد که از زمانی که برای تمرین کردن اختصاص داده اید، بیش ترین استفاده را کرده اید. تکنیک تمرین آگاهانه بر اساس تحقیقات کی. آندرس اریکسون طراحی شده است. این تکنیک چندین اصل پایه ای برای تمرین آگاهانه دارد، اما در این جا ما روی دو مورد از آن ها تمرکز می کنیم: -A different, but still technical, situation is when the program cannot proceed because of a problem in the execution environment, such as an unresponsive database. In this situation you must assume that the infrastructure did what it could to resolve the situation — repairing connections and retrying a reasonable number of times — and failed. Even if the cause is different, the situation for the calling code is similar: there is little it can do about it. So, we signal the situation through an exception that we let bubble up to the general exception handling mechanism. +1- تمرین بر لبه ی توانایی ها و دانش کنونی: +تمرین بسیار ساده چیز تازه ای به شما یاد نمی دهد و تمرین بسیار سخت مانع پیشرفت شما خواهد شد. اولین نکته بسیار آشکار است. اگر سطح دشواری تمرین های شما بسیار پایین باشد، پیشرفت چندانی نخواهید داشت. اگر شما مدتی است که یادگیری برنامه نویسی را شروع کرده اید، نوشتن یک برنامه ی ساده ی HelloWorld هیچ کمکی به شما نخواهد کرد و چیز تازه ای به شما یاد نخواهد داد. -In contrast to these, we have the situation where you cannot complete the call for a domain-logical reason. In this case we have encountered a situation that is an exception, i.e., unusual and undesirable, but not bizarre or programmatically in error. For example, if I try to withdraw money from an account with insufficient funds. In other words, this kind of situation is a part of the contract, and throwing an exception is just an *alternative return path* that is part of the model and that the client should be aware of and be prepared to handle. For these situations it is appropriate to create a specific exception or a separate exception hierarchy so that the client can handle the situation on its own terms. +بنابراین حتی در پیاده سازی برنامه های ساده نیز خلاقیت به خرج دهید. اگر روی مثال های آموزشی خود کار می کنید، سعی کنید آن ها را به نحوی تغییر دهید و با دانش قبلی خود ترکیب کنید. مثلاً اگر یاد می گیرید که فانکشنی بنویسید که یک آرگومان استرینگ می گیرد، سعی کنید خودتان فانکشن های جدیدی بنویسید که تعداد آرگومان های بیش تر، با انواع متنوع تری داشته باشد. با این حال اگر سطح دشواری تمرین های شما بیش از حد بالا باشد، شانس زیادی برای موفقیت نخواهید داشت. اگر شما روی یک برنامه ی بسیار پیشرفته کار کنید که نتوانید بفهمید هر بخش آن چطور کار می کند، در این صورت تمرین کردن بی معنی خواهد بود. اگر شما همین دیروز شروع به یادگیری برنامه نویسی کرده اید، و امروز بخواهید روی کدنویسی یک پروژه ی بزرگ کار کنید قطعاً راه به جایی نخواهید برد. -Mixing technical exceptions and business exceptions in the same hierarchy blurs the distinction and confuses the caller about what the method contract is, what conditions it is required to ensure before calling, and what situations it is supposed to handle. Separating the cases gives clarity and increases the chances that technical exceptions will be handled by some application framework, while the business domain exceptions actually are considered and handled by the client code. +2- بازخورد گرفتن: +کارهای خود را به دیگران ارائه کنید و از آن ها بخواهید نظر خود را در مورد نقاط ضعف و قوت برنامه هایتان اعلام کنند. +اصل دوم نیز بسیار مشهود است، با این حال بسیاری از افراد در زمان تمرین یک مهارت جدید آن را فراموش می کنند. بازخورد گرفتن به طور غیر قابل باوری اهمیت دارد، زیرا به شما این امکان را می دهد تا کار خود را تصحیح و تعدیل کنید. اگر هیچ کس به شما نگوید که چه اشتباهی کرده اید، چطور پی به خطای خود می برید و آن را اصلاح می کنید؟ -By [Dan Bergh Johnsson](http://programmer.97things.oreilly.com/wiki/index.php/Dan_Bergh_Johnsson) \ No newline at end of file +مثلاً فرض کنید شما کدهای برنامه ی خود را روی یک برگه کاغذ بنویسید؛ این کار برای شما راحت تر خواهد بود، اما تا زمانی که آن ها را در محیط کامپیوتری کامپایل و اجرا نکرده باشید چطور مطمئن خواهید بود که برنامه ی درست و بدون باگی نوشته اید. به علاوه تمام تکنیک های کدنویسی را نمی توان تنها با اجرای کامپیوتری برنامه ها یاد گرفت. لازم است گاهی دیگران نگاهی به کار شما بیاندازند و نظر خود را در مورد آن بگویند. + +تمرین کردن کدنویسی بدون آن که کار خود را به دیگران ارائه کنید و از آن ها بازخورد بگیرید، مثل این است که در تاریکی قدم برمی دارید. ممکن است به جلو پیش روید، ممکن است تنها دور خود بچرخید، اما نمی توانید تفاوت این دو را بفهمید. From 63c9fb48183ae6ee6be75be16a71e7ee72a2b29f Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 14:01:20 +0300 Subject: [PATCH 154/290] Added Number 21 --- fr-IR/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fr-IR/SUMMARY.md b/fr-IR/SUMMARY.md index aedbf288..4ea4eef7 100644 --- a/fr-IR/SUMMARY.md +++ b/fr-IR/SUMMARY.md @@ -21,7 +21,7 @@ 1. [ویژگی‌های یک API با طراحی مناسب](thing_18/README.md) 1. [از ابتدای کار توسعهٔ اپلیکیشن خود روی فرآیند نصب و دیپلوی آن به طور پیوسته کار کنید](thing_19/README.md) 1. [مدیریت اکسپشن‌ها](thing_20/README.md) -1. [](thing_21/README.md) +1. [ تمرین آگاهانه لازمهٔ حرفه‌ای شدن است!](thing_21/README.md) 1. [](thing_22/README.md) 1. [](thing_23/README.md) 1. [](thing_24/README.md) From 5d709364f9df1f94ea1b1802c71baa79b8a95630 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 14:04:03 +0300 Subject: [PATCH 155/290] Added number 22 --- fr-IR/thing_22/README.md | 30 ++++++++++++++++-------------- 1 file changed, 16 insertions(+), 14 deletions(-) diff --git a/fr-IR/thing_22/README.md b/fr-IR/thing_22/README.md index 866ce294..df9b2a37 100644 --- a/fr-IR/thing_22/README.md +++ b/fr-IR/thing_22/README.md @@ -1,25 +1,27 @@ -# Do Lots of Deliberate Practice +# پشت هر خط از کد شما می‌بایست یک منطق وجود داشته باشد! +یکسری ابزارها در اختیار برنامه نویسان هستند که این امکان را به ایشان می‌دهند تا کدهایشان را به منظور عدم وجود هرگونه باگی چک کنند اما واقعیت امر آن است که این دست ابزارها همیشه کارآمد نیستند و نتیجه ی دلخواه را بوجود نمی آورند. در همین راستا، برنامه نویسان نیاز به رویکردی دارند تا از آن طریق بتوانند از درستی کدهای خود اطمینان حاصل کنند و این همان چیزی است که در این آموزش قصد داریم مورد بررسی قرار دهیم. -Deliberate practice is not simply performing a task. If you ask yourself "Why am I performing this task?" and your answer is "To complete the task," then you're not doing deliberate practice. +یک برنامه نویس حرفه‌ای کسی است که سورس کد پروژه ی خود را به بخش‌های کوچک تقسیم‌بندی کرده -خواه بخش‌های یک خطی مثل فراخوانی یک فانکشن، خواه بخش‌های مثلاً ده خطی- و از صحت کارکرد این بخش‌های سورس کد اطمینان حاصل کند. اگر شما بتوانید به اندازه‌ای از کارکرد سورس کد پروژه ی خود اطمینان داشته باشید که یکی از دوستان برنامه نویس شما -که نقش Devil`s Advocate را بازی می کند- نتواند به آن گیر دهد، کفایت می‌کند و شما به هدف خود دست یافته اید. -You do deliberate practice to improve your ability to perform a task. It's about skill and technique. Deliberate practice means repetition. It means performing the task with the aim of increasing your mastery of one or more aspects of the task. It means repeating the repetition. Slowly, over and over again. Until you achieve your desired level of mastery. You do deliberate practice to master the task not to complete the task. +به خاطر داشته باشید به طور کلی منظور از Devil`s Advocate یا «وکیل مدافع شیطان» کسی است که مهارت خاصی در ایراد بنی اسرائیلی گرفتن دارد و همواره نیمه ی خالی لیوان را نگاه می کند. ممکن است این تصور برای شما پیش بیاد که در شرکت های حرفه‌ای چنین افرادی اصلاً جایگاه خوبی ندارند اما این باور کاملاً اشتباه است. شرکت های تراز اول برای وکلای مدافع شیطان سر و دست می شکنند چرا که این افراد می‌توانند متضمن موفقیت یک محصول شوند. +در بررسی تک تک خطوط سورس کد، می بایست همواره این نکته را مد نظر قرار دهیم که تا حد ممکن بلوک های کد مستقل از یکدیگر باشند و اصطلاحاً Dependency (دیپندنسی یا وابستگی) کمی مابین بخش‌های مختلف کد وجود داشته باشد چرا که در این صورت، بررسی سورس کد به مراتب راحت‌تر خواهد بود. به طور کلی، یکسری نکات هستند که اگر بتوانیم از آن‌ها در کدنویسی پیروی کنیم، تا حد قابل توجهی می‌توانند متضمن یک محصول نهایت بهینه گردند که عبارتند از: -The principal aim of paid development is to finish a product whereas the principal aim of deliberate practice is to improve your performance. They are not the same. Ask yourself, how much of your time do you spend developing someone else's product? How much developing yourself? +- تا حد ممکن از فانکشن هایی که ماهیت GoTo دارند اجتناب کنید. در اینجا منظور از GoTo، فانکشن هایی است که برای انجام کاری خاص نیاز به سایر فانکشن ها دارند و همین مسأله منجر ارتباط بین فانکشنی و در نهایت پیچیدگی بیشتر سورس کد می شود. -How much deliberate practice does it take to acquire expertise? +- تا حد ممکن از متغیرهای گلوبال که امکان تغییر مقادیر آن‌ها وجود دارد استفاده نکنید چرا که این دست متغیرها منجر به ایجاد وابستگی مابین بخش‌های مختلف کد می‌شوند (منظور از متغیرهای گلوبال، متغیرهایی است که در بدنه ی کلاس‌ها تعریف شده و به نوعی public هستند؛ یعنی از هر کجای برنامه می‌توان به آن‌ها دسترسی داشت.) -- Peter Norvig [writes](http://norvig.com/21-days.html) that "It may be that 10,000 hours [...] is the magic number." -- In *Leading Lean Software Development* Mary Poppendieck notes that "It takes elite performers a minimum of 10,000 hours of deliberate focused practice to become experts." +- هر متغیر می بایست تا حد ممکن از Scope یا «حوزه ی» کوچکی برخوردار باشد. به عبارت دیگر، مثلاً به جای تعریف کردن متغیری تحت عنوان userAccountNumber که گلوبال است، بهتر است که این متغیر را داخل یک فانکشن تعریف کنیم و صرفاً داخل همان فانکشن به آن دسترسی داشته باشیم. -The expertise arrives gradually over time — not all at once in the 10,000th hour! Nevertheless, 10,000 hours is a lot: about 20 hours per week for 10 years. Given this level of commitment you might be worrying that you're just not expert material. You are. Greatness is largely a matter of conscious choice. *Your choice.* Research over the last two decades has shown the main factor in acquiring expertise is time spent doing deliberate practice. Innate ability is *not* the main factor. +- از فضاهای خالی به منظور خوانایی بیشتر کد استفاده کنید. به عبارت دیگر، بخش‌های مختلف سورس کد را با زدن اینتر مجزا کنید و در عین حال هم از Indentation های درست استفاده کنید (منظور از Indentation، اسپیس هایی است که از سمت چپ ویرایشگر کد تا ابتدای دستورات وجود دارند.) امروزه اکثر IDE ها دارای این قابلیت هستند تا به صورت خودکار، فواصل سورس کد را منظم کنند. -- Mary: "There is broad consensus among researchers of expert performance that inborn talent does not account for much more than a threshold; you have to have a minimum amount of natural ability to get started in a sport or profession. After that, the people who excel are the ones who work the hardest." +- کد خود را گویا کنید. به عبارت دیگر، نام هایی برای کلاس ها، فانکشن ها، متغیرها و … استفاده کنید که نیازی به کامنت گذاری نداشته و مثلاً نام یک فانکشن به خوبی نمایانگر ماهیت و کاری که آن فانکشن انجام می‌دهد باشد. به طور مثال، اگر فانکشی قرار است اطلاعات کاربر را از دیتابیس گرفته و در اختیار ما قرار دهد، نامی همچون fetchUserInfo مناسب است چرا که هم کوتاه است اما در عین حال گویای ماهیت این فانکشن نیز هست. -There is little point deliberately practicing something you are already an expert at. Deliberate practice means practicing something you are not good at. +- اگر منطق برنامه ی شما به گونه‌ای است که نیازمند بخش‌های تو در تو است، بهتر آن است که هر بخش را در قالب یک فانکشن کدنویسی کنید. -- Peter: "The key [to developing expertise] is *deliberative* practice: not just doing it again and again, but challenging yourself with a task that is just beyond your current ability, trying it, analyzing your performance while and after doing it, and correcting any mistakes." -- Mary: "Deliberate practice does not mean doing what you are good at; it means challenging yourself, doing what you are not good at. So it's not necessarily fun." +- هر فانکشن می بایست فقط و فقط یک کار را انجام دهد و از نوشتن فانکشن های «همه کاره» شدیدا خودداری کنید. گفته می‌شود که یک فانکشن خوب، فانکشنی است که در صفحه ی مانیتور، بدون نیاز به اسکرول کردن، ابتدا و انتهای آن معلوم باشد. یعنی چیزی در حدود 24 خط کد! (البته بسته به رزولوشن و اندازه ی مانتیور، این قانون برای برنامه نویسان مختلف نتایج کاملا متفاوتی دارد.) -Deliberate practice is about learning. About learning that changes you; learning that changes your behavior. Good luck. +- تعداد پارامترهای ورودی فانکشن ها می بایست محدود باشد (مثلاً 4 پارامتر ورودی به نظر محدودیت خوبی به نظر می آید) و در صورتی هم که تعداد پارامترهای ورودی مد نظر شما زیاد است -مثلا 12 پارامتر ورودی- می‌توانید پارامترهای مرتبط با یکدیگر را در قالب یک آبجکت تعریف کرده و از آن آبجکت به عنوان یکی از پارامترها استفاده نمایید. -By [Jon Jagger](http://programmer.97things.oreilly.com/wiki/index.php/Jon_Jagger) \ No newline at end of file +علاوه بر موارد فوق الذکر، راه کارهای دیگر نیز هستند که با اعمال آن‌ها می‌توان درک بهتری از سورس کد پیدا کرد اما موارد مطروحه جزو مهم‌ترین چیزهایی هستند که به شما کمک خواهند کرد تا کدی تمیز، بدون باگ، بدون وابستگی، گویا و بهینه داشته باشید.. + + From 0abb2aaff1ad413335e4a173df045d3b35526950 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 14:10:22 +0300 Subject: [PATCH 156/290] Added Number 23 --- fr-IR/thing_23/README.md | 38 ++++++++++++++++++++++++++++++-------- 1 file changed, 30 insertions(+), 8 deletions(-) diff --git a/fr-IR/thing_23/README.md b/fr-IR/thing_23/README.md index 66ad8e0e..a0e0664f 100644 --- a/fr-IR/thing_23/README.md +++ b/fr-IR/thing_23/README.md @@ -1,15 +1,37 @@ -# Domain-Specific Languages +# مفهوم DSL چیست و چرا آشنایی با آن در حوزهٔ برنامه‌نویسی اهمیت دارد؟ -Whenever you listen to a discussion by experts in any domain, be it chess players, kindergarten teachers, or insurance agents, you'll notice that their vocabulary is quite different from everyday language. That's part of what domain-specific languages (DSLs) are about: A specific domain has a specialized vocabulary to describe the things that are particular to that domain. +منظور ازDSL که مخفف واژگان Domain-Specific Language به معنی «زبان اختصاصی هر حوزه ی کاری» می باشد، یکسری زبان‌های برنامه نویسی است که به صورت تخصصی برای یکسری کارهای خاص در یکسری حوزه های خاص مورد استفاده قرار می‌گیرند. برای درک بهتر دی اس ال ها، می‌توان آن‌ها را همچون زبان‌های برنامه نویسی کوچکی تلقی کرد که برای انجام یکسری کارهای خاص در یک سیستم مورد استفاده قرار می‌گیرند و از جمله حوزه های خاصی که از دی اس ال ها در آن‌ها استفاده می شود، می‌توان به صنعت بیمه، صنعت هواپیمایی، پتروشیمی و … اشاره کرد. -In the world of software, DSLs are about executable expressions in a language specific to a domain with limited vocabulary and grammar that is readable, understandable, and — hopefully — writable by domain experts. DSLs targeted at software developers or scientists have been around for a long time. For example, the Unix 'little languages' found in configuration files and the languages created with the power of LISP macros are some of the older examples. +یکی از دلایلی که دی اس ال ها بوجود آمدند این بود که زبان‌های رایج و همه منظوره برای یکسری ابزارها، سیستم ها، پلتفرم ها و حتی صنایع آن طور که باید و شاید اثربخش نبودند و همین شد که این گروه از زبان‌های برنامه نویسی کوچک اما در عین حال کاربری ابداع شدند. -DSLs are commonly classified as either *internal* or *external*: +بر خلاف زبان‌های برنامه نویسی همه منظوره ای همچون جاوا، پایتون، پرل و غیره، حوزه ای که از دی اس ال ها می‌توان در آن استفاده کرد محدود است اما این در حالی است که در آن حوزه ی خاص، دی اس ال ها با سرعت بیشتر و عملکرد به مراتب بهتری نسبت به زبان‌های همه منظور عمل خواهند کرد. -- **Internal DSLs** are written in a general purpose programming language whose syntax has been bent to look much more like natural language. This is easier for languages that offer more syntactic sugar and formatting possibilities (e.g., Ruby and Scala) than it is for others that do not (e.g., Java). Most internal DSLs wrap existing APIs, libraries, or business code and provide a wrapper for less mind-bending access to the functionality. They are directly executable by just running them. Depending on the implementation and the domain, they are used to build data structures, define dependencies, run processes or tasks, communicate with other systems, or validate user input. The syntax of an internal DSL is constrained by the host language. There are many patterns — e.g., expression builder, method chaining, and annotation — that can help you to bend the host language to your DSL. If the host language doesn't require recompilation, an internal DSL can be developed quite quickly working side by side with a domain expert. +در ضمن، به نوعی می‌توان گفت که دی اس ال ها برای حوزه ی خاصی که طراحی می‌شوند فوق‌العاده خوب هستند اما برای حوزه هایی که خارج از ساختار از پیش تعریف شده ی دی اس ال باشند فوق‌العاده بد هستند. -- **External DSLs** are textual or graphical expressions of the language — although textual DSLs tend to be more common than graphical ones. Textual expressions can be processed by a tool chain that includes lexer, parser, model transformer, generators, and any other type of post-processing. External DSLs are mostly read into internal models which form the basis for further processing. It is helpful to define a grammar (e.g., in EBNF). A grammar provides the starting point for generating parts of the tool chain (e.g., editor, visualizer, parser generator). For simple DSLs, a handmade parser may be sufficient — using, for instance, regular expressions. Custom parsers can become unwieldy if too much is asked of them, so it makes sense to look at tools designed specifically for working with language grammars and DSLs — e.g., openArchitectureWare, ANTlr, SableCC, AndroMDA. Defining external DSLs as XML dialects is also quite common, although readability is often an issue — especially for non-technical readers. +نکته توجه داشته باشیم که ما با استفاده از دی اس ال ها نخواهیم توانست یک برنامه ی کامل و جامع بنویسیم بلکه صرفاً به منظور انجام کارهای کوچکی که به سرعت می بایست انجام شوند می‌توان از این زبان‌های برنامه نویسی کوچک استفاده کرد. +از جمله دی اس ال های رایج می‌توان به CSS, Ant و SQL اشاره کرد. به یاد داشته باشید که از برخی زبان‌های General Purpose یا «چند منظوره» همچون سی شارپ، اسکالا، روبی و … می‌توان به منظور ساخت یک DSL استفاده کرد. مثلاً از زبان اسکالا -که خود این زبان برگرفته از زبان برنامه نویسی جاوا است- می‌توان برای ساخت DSL هایی برای صنایع بسیار حساس همچون صنعت نفت استفاده کرد. -You must always take the target audience of your DSL into account. Are they developers, managers, business customers, or end users? You have to adapt the technical level of the language, the available tools, syntax help (e.g., intellisense), early validation, visualization, and representation to the intended audience. By hiding technical details, DSLs can empower users by giving them the ability to adapt systems to their needs without requiring the help of developers. It can also speed up development because of the potential distribution of work after the initial language framework is in place. The language can be evolved gradually. There are also different migration paths for existing expressions and grammars available. +انواع DSL ها +به طور کلی، زبان‌های دی اس ال را می‌توان به دو دسته ی Internal (اینترنال یا داخلی) و External (اکسترنال یا خارجی) تقسیم‌بندی کرد. -By [Michael Hunger](http://programmer.97things.oreilly.com/wiki/index.php/Michael_Hunger) \ No newline at end of file +دی اس ال های اینترنال به گروهی از زبان‌های برنامه نویسی گفته می‌شود که بر پایه زبان‌های برنامه نویسی همه منظوره ای همچون سی شارپ، جاوا، اسکالا، روبی و … بوده و این در حالی است که بسیاری از قابلیت‌های این زبان‌های مادر در DSL هایی که بر پایه ی آن‌ها نوشته شده‌اند مشهود است که به عنوان مثال می‌توان به سینتکس -نحوه ی نوشتار- این زبان‌ها اشاره کرد. از زبان‌های دی اس ال اینترنال در جامعه ی توسعه دهندگان زبان برنامه نویسی Lisp به کرات استفاده می شود. + +در مقابل، دی اس ال های اکسترنال قرار دارند که خود توسعه‌دهنده می‌تواند تصمیم بگیرد که از چه نشانه ها، سینتکس و ساختاری برای زبان مد نظرش استفاده کند. دی اس ال های اکسترنال تا حد بسیار زیادی دست شما را باز می‌گذارند اما این در حالی است که طراحی این دست زبان‌ها به مراتب دشوارتر بوده و مستلزم صرف زمان نسبتاً زیادی برای توسعه ی آن‌ها است چرا که شما می بایست کامپایلر اختصاصی دی اس ال را به منظور اجرای سینتکسی که مد نظر شماست را نیز طراحی کنید. در توسعه ی سیستم عامل های مبتنی بر Unix از زبان‌های دی اس ال اسکترنال به کرات استفاده می شود. + +در زمان طراحی DSL ها، همواره می بایست مخاطب را مد نظر قرار داد و دید که مخاطبین این زبان برنامه نویسی جدید چه گروهی از کاربران هستند؛ آیا توسعه‌دهنده اند یا جزو مدیران و تیم اجرایی یک شرکت محسوب می شوند. پس از آن که مخاطبین زبان مشخص شدند، می بایست بر اساس نیاز و تخصص ایشان اقدام به طراحی سینتکس، سطح فنی مورد نیاز زبان، ابزارهای مورد نیاز و نحوه ی به کارگیری زبان کرد. با پنهان سازی جزئیات فنی در زبان‌های دی اس ال، می‌توان کاربران هدف را به ابزاری تجهیز کرد که بدون نیاز به کمک توسعه دهندگان، بتوانند نیازهای خود را مرتفع سازند. + +مزایای DSL ها +به طور کلی، مزایای طراحی زبان های دی اس ال را می توان به صورت زیر خلاصه کرد: +- برخلاف زبان های همه منظوره، دی اس ال ها بهترین گزینه برای نیازهای خاص هستند. +- کسانی که با برنامه نویسی هم آشنایی نداشته باشند به سادگی قادر خواهند بود تا یک دید کلی نسبت به آن ها پیدا کنند. +- این امکان وجود خواهد داشت تا با طراحی یک GUI یا «رابط گرافیکی کاربری» فرایند استفاده از دی اس ال را ساده تر نمود. +- امکان ساخت Prototype (پروتوتایپ یا نمونه ی اولیه) یک نرم افزار یا اپلیکیشن با استفاده از دی اس ال ها به مراتب راحت تر صورت می گیرد. + +یکی از بهترین نمونه های دی اس ال، CSS است که مخفف واژگان Cascading Style Sheets به معنی «الگوی های آبشاری» می باشد. به طور کلی، کدهای سی اس اس به طراحان سایت اجازه می دهند تا به عناصر تشکیل دهنده ی یک صفحه ی وب شکل و ساختار دهند. برای مثال، کدهای سی اس اس زیر رنگ بنده ی یک صفحه ی سایت را قرمز کرده، اندازه ی فونت را 16 پیکسل کرده و رنگ فونت را هم سفید می کنند: +```Css +body { + background: #F00 + font-size: 16px; + color: #FFF +} +``` From dc6107192f03d8aab41bb3ab0361815c27864c14 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 14:10:33 +0300 Subject: [PATCH 157/290] Added Number 23 --- fr-IR/SUMMARY.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fr-IR/SUMMARY.md b/fr-IR/SUMMARY.md index 4ea4eef7..c727eb1a 100644 --- a/fr-IR/SUMMARY.md +++ b/fr-IR/SUMMARY.md @@ -22,8 +22,8 @@ 1. [از ابتدای کار توسعهٔ اپلیکیشن خود روی فرآیند نصب و دیپلوی آن به طور پیوسته کار کنید](thing_19/README.md) 1. [مدیریت اکسپشن‌ها](thing_20/README.md) 1. [ تمرین آگاهانه لازمهٔ حرفه‌ای شدن است!](thing_21/README.md) -1. [](thing_22/README.md) -1. [](thing_23/README.md) +1. [ پشت هر خط از کد شما می‌بایست یک منطق وجود داشته باشد!](thing_22/README.md) +1. [مفهوم DSL چیست و چرا آشنایی با آن در حوزهٔ برنامه‌نویسی اهمیت دارد؟](thing_23/README.md) 1. [](thing_24/README.md) 1. [](thing_25/README.md) 1. [](thing_26/README.md) From ce9b31f1909895fe78ab93b164e49de3bce5a3d7 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 14:12:56 +0300 Subject: [PATCH 158/290] Added Number 24 --- fr-IR/thing_24/README.md | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/fr-IR/thing_24/README.md b/fr-IR/thing_24/README.md index 8649ba8a..386591cc 100644 --- a/fr-IR/thing_24/README.md +++ b/fr-IR/thing_24/README.md @@ -1,13 +1,14 @@ -# Don't Be Afraid to Break Things +# از ساختارشکنی نترسید! -Everyone with industry experience has undoubtedly worked on a project where the codebase was precarious at best. The system is poorly factored, and changing one thing always manages to break another unrelated feature. Whenever a module is added, the coder's goal is to change as little as possible, and hold their breath during every release. This is the software equivalent of playing Jenga with I-beams in a skyscraper, and is bound for disaster. +کمتر کسی را می‌توان یافت که در حوزه ی برنامه نویسی کار کرده باشد و با پروژه یی مواجه نشده باشد که ساختار کدنویسی آن مشکل داشته باشد. در چنین پروژه هایی، رفع یک باگ منجر به ایجاد ده‌ها باگ دیگر خواهد شد! در چنین شرایطی، برنامه نویس کاملاً دست به عصا کدنویسی کرده و همیشه این نگرانی را دارد که پروژه از هم بپاشد. -The reason that making changes is so nerve wracking is because the system is sick. It needs a doctor, otherwise its condition will only worsen. You already know what is wrong with your system, but you are afraid of breaking the eggs to make your omelet. A skilled surgeon knows that cuts have to be made in order to operate, but the skilled surgeon also knows that the cuts are temporary and will heal. The end result of the operation is worth the initial pain, and the patient should heal to a better state than they were in before the surgery. +دلیل مواجهه با چنین مشکلی کاملاً واضح است و این دلیل چیزی نیست جز «بیمار» بودن سیستم و این بیمار نیاز به یک پزشک دارد و در غیر این صورت، اوضاع از این هم وخیم تر خواهد شد. در‌ واقع، همان‌طور که یک عمل جراحی در ابتدا با درد همراه است و شرایط اصلاً خوشایندی را برای بیمار فراهم نمی کند اما در نهایت منجر به سلامت بیمار می شود، در این گونه پروژه ها نیز می بایست متحمل چنین دردی شویم! -Don't be afraid of your code. Who cares if something gets temporarily broken while you move things around? A paralyzing fear of change is what got your project into this state to begin with. Investing the time to refactor will pay for itself several times over the life cycle of your project. An added benefit is that your team's experience dealing with the sick system makes you all experts in knowing how it *should* work. Apply this knowledge rather than resent it. Working on a system you hate is not how anybody should have to spend their time. +خود شما –به عنوان برنامه نویس یا یکی از برنامه نویسان چنین پروژه یی- دقیقاً می‌دانید که مشکل از کجا است و چه بخش‌هایی نیاز به ریفکتور شدن دارند اما از دست به عمل شدن هراس دارید. -Redefine internal interfaces, restructure modules, refactor copy–pasted code, and simplify your design by reducing dependencies. You can significantly reduce code complexity by eliminating corner cases, which often result from improperly coupled features. Slowly transition the old structure into the new one, testing along the way. Trying to accomplish a large refactor in "one big shebang" will cause enough problems to make you consider abandoning the whole effort midway through. +به خاطر داشته باشید به طور خلاصه، منظور از Code Refactoring (کد ریفکتورینگ) این است که ساختار فعلی سورس کد یک پروژه را تغییر دهیم -یا بهتر بگوییم بهبود بخشیم- بدون آن که تاثیری در نوع ماهیت پروژه ایجاد گردد. فرض کنیم چند سال پیش کدی را نوشته ایم، حال که چیزهای جدید فرا گرفته ایم و به کد نگاه می کنیم، می بینیم کدی که مثلا در 40 خط نوشته ایم را می توان خیلی بهینه تر کرده و به 10 خط کاهش داده و در عین حال اثربخشی آن را نیز بیشتر کرد. به چنین کاری Refactoring گفته می شود. +مادامی که شما به صورت لوکال اقدام به تغییر و تحول سورس کد خود می کنید، هرگز از دست کاری کد خود نترسید چرا که در نهایت منجر به بهبود وضعیت پروژه خواهد شد. خیلی از اوقات ما -به عنوان برنامه نویس- می‌دانیم که مشکل از کجا است اما یا حوصله ی رفع کردن آن را نداریم یا به دلیل طولانی شدن زمان کار کردن روی پروژه، ترجیح می‌دهیم مشکلات را به حال خود رها کرده و روی پروژه ی دیگری کار کنیم و یا این که از رو به رو شدن با مشکلات پروژه هراس داریم. -Be the surgeon who isn't afraid to cut out the sick parts to make room for healing. The attitude is contagious and will inspire others to start working on those cleanup projects they've been putting off. Keep a "hygiene" list of tasks that the team feels are worthwhile for the general good of the project. Convince management that even though these tasks may not produce visible results, they will reduce expenses and expedite future releases. Never stop caring about the general "health" of the code. +متأسفانه خبر بد این که این شتری است که درب خانه ی هر برنامه نویسی می خوابد! شما چاره یی جز این ندارید که سورس کد خود را ریفکتور کنید، باگ ها را رفع کنید و وابستگی‌ها را به حداقل برسانید. اگر هم روی پروژه یی کار می‌کنید که شما مسئول مستقیم آن نیستید، سعی کنید مدیر خود را مجاب کنید که اگرچه این اصلاحات نتایج ملموس و قابل مشاهده یی ایجاد نمی کنند، اما در نهایت منجر به کاهش هزینه‌ها در دراز مدت و تجربه ی کاربری بهتری می شوند. -By [Mike Lewis](http://programmer.97things.oreilly.com/wiki/index.php/Mike_Lewis) \ No newline at end of file +به خاطر داشته باشید Dependency (دیپندنسی یا وابستگی) در توسعه ی نرم افزار به این نکته اشاره دارد که سورس کد پروژه ما برای اجرای تمام و کمال، نیاز به سایر کدها، لایبرری ها و حتی سایر نرم افزارها داشته باشد. توجه داشته باشیم که در توسعه ی نرم افزار، می بایست تمام تلاش خود را به کار بندیم تا این وابستگی ها به حداقل برسند. علاوه بر این، اصطلاحی داریم تحت عنوان Dependency Hell یا «جهنم وابستگی» که وقتی رخ می دهد که نرم افزار ثالثی که از آن در پروژه ی خود استفاده می کنیم تغییری در سورس کد اش ایجاد می کند که این تغییر منجر به عملکرد ناصحیح نرم افزار ما خواهد شد. From 66c76f50ea8cebc2609d349dbe1b3bec8e9b5f56 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 14:13:32 +0300 Subject: [PATCH 159/290] Added number 24 --- fr-IR/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fr-IR/SUMMARY.md b/fr-IR/SUMMARY.md index c727eb1a..6f3527ed 100644 --- a/fr-IR/SUMMARY.md +++ b/fr-IR/SUMMARY.md @@ -24,7 +24,7 @@ 1. [ تمرین آگاهانه لازمهٔ حرفه‌ای شدن است!](thing_21/README.md) 1. [ پشت هر خط از کد شما می‌بایست یک منطق وجود داشته باشد!](thing_22/README.md) 1. [مفهوم DSL چیست و چرا آشنایی با آن در حوزهٔ برنامه‌نویسی اهمیت دارد؟](thing_23/README.md) -1. [](thing_24/README.md) +1. [از ساختارشکنی نترسید!](thing_24/README.md) 1. [](thing_25/README.md) 1. [](thing_26/README.md) 1. [](thing_27/README.md) From 9c0fec86689f7ff7b70fa75e7284f3f06848ab6b Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 14:15:11 +0300 Subject: [PATCH 160/290] Added Number 25 --- fr-IR/thing_25/README.md | 27 ++++++--------------------- 1 file changed, 6 insertions(+), 21 deletions(-) diff --git a/fr-IR/thing_25/README.md b/fr-IR/thing_25/README.md index 66cbd942..865de090 100644 --- a/fr-IR/thing_25/README.md +++ b/fr-IR/thing_25/README.md @@ -1,26 +1,11 @@ -# Don't Be Cute with Your Test Data +# برای تست نرم‌افزار از دیتای واقعی استفاده کنید -> *It was getting late. I was throwing in some placeholder data to test the page layout I'd been working on.* +پیش از هر گونه توضیحی، سناریویی تعریف می‌کنیم تا ببینیم برای چند درصد از ما آشنایی دارد؛ نرم افزاری نوشته‌ایم -مثلا یک وب اپلیکیشن- حال نیاز است تا یکسری دیتای اولیه وارد دیتابیس کرده تا بتوانیم تست نهایی را انجام دهیم. پیش از هر چیز، چند یوزر می بایست تعریف کنیم؛ برای این کار، از نام کاربری‌هایی همچون ali1, ali2 و ali3 استفاده می کنیم. اکنون تک تک این یوزرها را می بایست به یک گروه کاربری ربط دهیم. مثلاً گروه‌های کاربری ادمین، کاربر معمولی و کاربر میهمان (در ضمن، برای ثبت نام در سایت، برای انتخاب نام کاربری حتماً می بایست هشت کاراکتر وارد کرد اما چون در مرحله ی تست است و قصد داریم برای ثبت نام و مهم‌تر از آن لاگین کردن، تعداد کاراکتر کمتری را وارد کنیم، بخشی از کد که مسئول چک کردن تعداد کاراکترهای نام کاربری است که کامنت می کنیم.) -> *I appropriated the members of The Clash for the names of users. Company names? Song titles by the Sex Pistols would do. Now I needed some stock ticker symbols — just some four letter words in capital letters.* +به علاوه این که آقا/خانم برنامه نویس برای تست یک اینپوت فرم -مثلا ناحیه یی برای وارد کردن نام خانوادگی- عبارت jfldjf'sdjfsjf یا چیزی شبیه به آن را وارد می کند! سناریو را بیش از این ادامه نمی‌دهیم اما پر واضح است که مثال‌های زیادی از این نوع رفتارهای توسعه دهندگان می‌توان زد به این صورت که از آنجا که ایشان فکر می‌کنند در مرحله ی تست هیچ‌ کس کد ایشان را نمی بیند، از دیتای غیر واقعی و … استفاده می کنند. -> *I used **those** four letter words.* +وقتی ما به عنوان یک توسعه دهنده و گاهی اوقات هم تست کننده ی نرم افزار اقدام به تست می کنیم، تحت هیچ عنوان نمی بایست از نام های کاربری همانند آنچه در بالا گفته شد برای ثبت نام استفاده کنیم؛ علاوه بر این، برای تست کردن فرم ها و ... حتما می بایست دیتای واقعی وارد کنیم چرا که آدم های واقعی قرار است که این نرم افزار را مورد استفاده قرار دهند و در غیر این صورت، احتمال زیادی وجود دارد که به هدف نهایی خود که همان ارائه ی یک محصول باکیفیت و بدون باگ است نرسیم. -> *It seemed harmless. Just something to amuse myself, and maybe the other developers the next day before I wired up the real data source.* +خیلی از اوقات پیش می آید زمانی که برای تست نرم افزار خود بخشی از کد را کامنت می کنیم -از روی تنبلی- زمانی که می خواهیم محصول نهایی را Deploy (دیپلوی یا منتشر) کنیم، فراموش می کنیم که بخش مد نظر را از کامنت خارج کنیم و این می تواند تبعات بسیاری مخربی داشته باشد! -> *The following morning, a project manager took some screenshots for a presentation.** - -Programming history is littered with these kinds of war stories. Things that developers and designers did "that no one else would see" which unexpectedly became visible. -The leak type can vary but, when it happens, it can be deadly to the person, team, or company responsible. Examples include: - -- During a status meeting, a client clicks on an button which is as yet unimplemented. They are told: "Don't click that again, you moron." -- A programmer maintaining a legacy system has been told to add an error dialog, and decides to use the output of existing behind-the-scenes logging to power it. Users are suddenly faced with messages such as "Holy database commit failure, Batman!" when something breaks. -- Someone mixes up the test and live administration interfaces, and does some "funny" data entry. Customers spot a $1m "Bill Gates-shaped personal massager" on sale in your online store. - -To appropriate the old saying that "a lie can travel halfway around the world while the truth is putting on its shoes," in this day and age a screw-up can be Dugg, Twittered, and Flibflarbed before anyone in the developer's timezone is awake to do anything about it. - -Even your source code isn't necessarily free of scrutiny. In 2004, when a tarball of the Windows 2000 source code made its way onto file sharing networks, some folks merrily grepped through it for profanity, insults, and [other funny content](http://www.kuro5hin.org/story/2004/2/15/71552/7795). (The comment `// TERRIBLE HORRIBLE NO GOOD VERY BAD HACK` has, I will admit, become appropriated by me from time to time since!) - -In summary, when writing any text in your code — whether comments, logging, dialogs, or test data — always ask yourself how it will look if it becomes public. It will save some red faces all round. - -By [Rod Begbie](http://programmer.97things.oreilly.com/wiki/index.php/Rod_Begbie) \ No newline at end of file +خلاصه ی کلام این که تست کردن به این روش می‌تواند آینده ی اپلیکیشن را تحت الشعاع قرار دهد. همواره سعی کنید در فرایند تست محصول نهایی، از دیتای شبیه به واقعی استفاده کنید چرا که در بسیاری از مواقع، دیتای تستی -به صورت ناخواسته- منتشر شده و در اختیار End-user ها قرار می‌گیرد و نیاز به توضیح نیست که امروزه با وجود شبکه‌های اجتماعی، هر گونه «کم کاری» از طرف تیم برنامه نویسی شما می تواند در معرض دید هزاران کاربر بالقوه قرار گرفته و آبروی تیم برنامه نویسی شما را به کلی تحت تأثیر قرار دهد. From a72f258c98c085f7761c92ca06d1e3f86ff9ac5e Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 14:15:23 +0300 Subject: [PATCH 161/290] Added Number 25 --- fr-IR/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fr-IR/SUMMARY.md b/fr-IR/SUMMARY.md index 6f3527ed..9a462ea0 100644 --- a/fr-IR/SUMMARY.md +++ b/fr-IR/SUMMARY.md @@ -25,7 +25,7 @@ 1. [ پشت هر خط از کد شما می‌بایست یک منطق وجود داشته باشد!](thing_22/README.md) 1. [مفهوم DSL چیست و چرا آشنایی با آن در حوزهٔ برنامه‌نویسی اهمیت دارد؟](thing_23/README.md) 1. [از ساختارشکنی نترسید!](thing_24/README.md) -1. [](thing_25/README.md) +1. [برای تست نرم‌افزار از دیتای واقعی استفاده کنید](thing_25/README.md) 1. [](thing_26/README.md) 1. [](thing_27/README.md) 1. [](thing_28/README.md) From 2f742768cc4dfb72a1f46af0562e4d1ef1fbccb1 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 14:16:15 +0300 Subject: [PATCH 162/290] Added number 26 --- fr-IR/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fr-IR/SUMMARY.md b/fr-IR/SUMMARY.md index 9a462ea0..7f9d2225 100644 --- a/fr-IR/SUMMARY.md +++ b/fr-IR/SUMMARY.md @@ -26,7 +26,7 @@ 1. [مفهوم DSL چیست و چرا آشنایی با آن در حوزهٔ برنامه‌نویسی اهمیت دارد؟](thing_23/README.md) 1. [از ساختارشکنی نترسید!](thing_24/README.md) 1. [برای تست نرم‌افزار از دیتای واقعی استفاده کنید](thing_25/README.md) -1. [](thing_26/README.md) +1. [حتی یک ارور را هم نادیده نگیرید!](thing_26/README.md) 1. [](thing_27/README.md) 1. [](thing_28/README.md) 1. [](thing_29/README.md) From 085c841dc45ba7d5b5550e8705066ec8e40d4f49 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 14:17:54 +0300 Subject: [PATCH 163/290] Added number 26 --- fr-IR/thing_26/README.md | 53 ++++++++++++---------------------------- 1 file changed, 16 insertions(+), 37 deletions(-) diff --git a/fr-IR/thing_26/README.md b/fr-IR/thing_26/README.md index 0cecf78d..3b44c46a 100644 --- a/fr-IR/thing_26/README.md +++ b/fr-IR/thing_26/README.md @@ -1,47 +1,26 @@ -# Don't Ignore that Error! +# حتی یک ارور را هم نادیده نگیرید! -> *I was walking down the street one evening to meet some friends in a bar. We hadn't shared a beer in some time and I was looking forward to seeing them again. In my haste, I wasn't looking where I was going. I tripped over the edge of a curb and ended up flat on my face. Well, it serves me right for not paying attention, I guess.* +پیش از هر چیز، ابتدا نیم نگاهی به داستانی فرضی داشته باشیم و در ادامه به بررسی ربط این داستان به ارورهای کدنویسی خواهیم پرداخت. فرض کنید که پس از فارغ التحصیلی از دانشگاه، چند سالی است که هم دانشکده یی های خود را ندیده اید و به لطف شبکه‌های اجتماعی، شما و همکلاسی هایتان همدیگر را می یابید. در یک کافه یا رستورانی قرار می‌گذارید تا یکدیگر را ملاقات کنید. زمان جلسه ساعت 5 بعد از ظهر است و اما شما تازه ساعت 4:30 از منزل بیرون رفته‌اید و از آنجا که اصلاً دوست ندارید پس از سال ها، آدم بدقولی جلوه کنید، با سرعت هرچه تمام تر به سوی محل قرار ملاقات پیش می روید. -> *It hurt my leg, but I was in a hurry to meet my friends. So I pulled myself up and carried on. As I walked further the pain was getting worse. Although I'd initially dismissed it as shock, I rapidly realized there was something wrong.* +از این تاکسی به اون تاکسی، از این اتوبوس به آن اتوبوس، جاهایی را هم از کوچه پس کوچه‌ها می‌روید که سریع‌تر به مقصد برسید. در حال عبور کردن از مقابل مغازه یی که صاحب آن داشت جلوی مغازه اش را آبپاشی می کرد، کمی تلو تلو می‌خورید و ناگهان نقش بر زمین می شوید! -> *But I hurried on to the bar regardless. I was in agony by the time I arrived. I didn't have a great night out, because I was terribly distracted. In the morning I went to the doctor and found out I'd fractured my shin bone. Had I stopped when I felt the pain, I'd've prevented a lot of extra damage that I caused by walking on it. Probably the worst morning after of my life.* +با توجه به این که خیلی عجله دارید، اول احساس درد زیادی نمی‌کنید و به سرعت بلند شده، لباس هایتان را می تکانید و مجدد به سرعت هرچه تمام تر به راه خود ادامه می‌دهید و در نهایت تقریبا به‌موقع به قرار ملاقات خود می رسید. در حین گپ و گفتگو با دوستان، باز هم کمی احساس درد می‌کنید که با خود می‌گویید که "خب زمین خودم ام و کمرم کمی کوفتگی پیدا کرده!" در طول کل جلسه، آن طور که باید و شاید از در کنار دوستان قدیمی خود بودن لذت نمی برید تا این که جلسه به پایان می‌رسد اما از آنجا که ثانیه به ثانیه به درد کمر شما افزوده می شود، مجبور می‌شوید که فردای آن روز به درمانگاه مراجعه کنید و می‌بینید که دیسک کمر شما آسیب دیده است. -Too many programmers write code like my disastrous night out. +واقعیت امر آن است که اگر به محض زمین خوردن، موضوع جدی گرفته می‌شد و به درمانگاه مراجعه می کردیم، شاید هرگز این آسیب دیدگی به دیسک های کمر کشیده نمی‌شد و صرفاً با چند روز استراحت و مراعات مشکل حل می شد! کدنویسی بسیاری از برنامه نویسان هم شبیه به داستان بالا است. چگونه؟ به این شکل که وقتی با اروری در کدهای خود مواجه می شوند، اگر آن ارور به گونه یی باشد که وی را از ادامه ی توسعه ی نرم افزارش نگاه ندارد، ارور را نادیده گرفته و به کار خود ادامه می‌دهند و همین مسأله منجر به بروز مشکلاتی گاها بسیار بزرگ در آینده ی نرم‌افزار می شوند. اگر بخواهیم به مسأله ی ارورها از این بعد نگاه کنیم، ارورهای نرم افزاری را می‌توان به دسته های زیر تقسیم‌بندی کرد: -*Error, what error? It won't be serious. Honestly. I can ignore it.* This is not a winning strategy for solid code. In fact, it's just plain laziness. (The wrong sort.) No matter how unlikely you think an error is in your code, you should always check for it, and always handle it. Every time. You're not saving time if you don't: You're storing up potential problems for the future. +- دستورات return: خیلی اوقات پیش می‌آید فانکشن هایی که می نویسیم، باید چیزی را اصطلاحاً ریترن کنند اما هرگز چک نمی‌کنیم که فانکشن مد نظر دقیقاً چه چیزی را ریترن کرده است چرا که گاهی اوقات پیش می‌آید که اگر فانکشن ما چیزی را ریترن نکند، ما در مراحل ابتدایی توسعه ی نرم‌افزار اصلاً متوجه آن نخواهیم شد. -We report errors in our code in a number of ways, including: - -- **Return codes** can be used as the resulting value of a function to mean "it didn't work." Error return codes are far too easy to ignore. You won't see anything in the code to highlight the problem. Indeed, it's become standard practice to ignore some standard C functions' return values. How often do you check the return value from printf? - -- **errno** is a curious C aberration, a separate global variable set to signal error. It's easy to ignore, hard to use, and leads to all sorts of nasty problems — for example, what happens when you have multiple threads calling the same function? Some platforms insulate you from pain here; others do not. - -- **Exceptions** are a more structured language-supported way of signaling and handling errors. And you can't possibly ignore them. Or can you? I've seen lots of code like this: - -``` +- اکسپشن ها: مدیریت Exception ها در بسیاری از زبان‌های برنامه نویسی سطح بالا دیده می‌شود و کار برنامه نویسان را ساده کرده است چرا که در صورت بروز چنین اکسپشن هایی، مفسر زبان برنامه نویسی مد نظر به ما هشدار خواهد داد. گاهی اوقات برنامه نویسانی را می‌بینیم که مثلاً در زبان برنامه نویسی پی اچ پی به شکل زیر از ساختار مدیریت اکسپشن ها استفاده می کنند: +```C# try { - // ...do something... -} -catch (...) {} // ignore errors + // do something +} catch() {} // ignoring catching any errors ``` +همان طور که در بلوک کد بالا مشاهده می شود، برنامه نویس به خوبی بخش try را هندل کرده است اما اگر به هر دلیلی این قسمت به مشکل برخورد، در بخش catch هیچ کدی برای گرفتن اکسپشن ها نوشته نشده است! -The saving grace of this awful construct is that it highlights the fact you're doing something morally dubious. - -If you ignore an error, turn a blind eye, and pretend that nothing has gone wrong, you run great risks. Just as my leg ended up in a worse state than if I'd stopped walking on it immediately, plowing on regardless can lead to very complex failures. Deal with problems at the earliest opportunity. Keep a short account. - -Not handling errors leads to: - -- **Brittle code.** Code that's filled with exciting, hard-to-find bugs. -- **Insecure code.** Crackers often exploit poor error handling to break into software systems. -- **Poor structure.** If there are errors from your code that are tedious to deal with continually, you probably have a poor interface. Express it so that the errors are less intrusive and the their handling is less onerous. - -Just as you should check all potential errors in your code, you need to expose all potentially erroneous conditions in your interfaces. Do not hide them, pretending that your services will always work. - -Why don't we check for errors? There are a number of common excuses. Which of these do you agree with? How would you counter each one? - -- Error handling clutters up the flow of the code, making it harder to read, and harder to spot the "normal" flow of execution. -- It's extra work and I have a deadline looming. -- I know that this function call will *never* return an error (printf always works, malloc always returns new memory — if it fails we have bigger problems...). -- It's only a toy program, and needn't be written to a production-worthy level. +به طور خلاصه، باید بگوییم همان‌طور که بی توجه به درد کمر می‌تواند منجر به صدماتی جدی به دیسک های کمر شود، بی توجه به ارورها، هشدارها، اکسپشن ها و … در حین فرایند توسعه ی نرم‌افزار -خواه نرم‌افزار دسکتاپ باشد، خواه اپ موبایل یا وب اپلیکیشن- می‌تواند منجر به مشکلاتی جدی در مراحل تکمیلی توسعه ی نرم‌افزار گردد که از آن جمله می‌توان به موارد زیر اشاره کرد: +- دشواری در یافتن باگ ها زمانی که برنامه بزرگ‌تر می شود. +- ایجاد حفره های امنیتی در نرم‌افزار و بالا رفتن ضریب هک. +- عدم تمایل سایر توسعه دهندگان به مشارکت در توسعه ی نرم‌افزار شما -By [Pete Goodliffe](http://programmer.97things.oreilly.com/wiki/index.php/Pete_Goodliffe) +لذا ضروری به نظر می رسد که به محض مواجهه با ارورهایی از هر نوع، فورا اقدام به رفع آن ها کرده و هرگز کار امروز را به فردا محول نکنیم. From c1f235b8b8ab8da91efea7bae93594b96c5cff37 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 14:19:00 +0300 Subject: [PATCH 164/290] Added number 27 --- fr-IR/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fr-IR/SUMMARY.md b/fr-IR/SUMMARY.md index 7f9d2225..108227e7 100644 --- a/fr-IR/SUMMARY.md +++ b/fr-IR/SUMMARY.md @@ -27,7 +27,7 @@ 1. [از ساختارشکنی نترسید!](thing_24/README.md) 1. [برای تست نرم‌افزار از دیتای واقعی استفاده کنید](thing_25/README.md) 1. [حتی یک ارور را هم نادیده نگیرید!](thing_26/README.md) -1. [](thing_27/README.md) +1. [فرهنگ استفاده از یک زبان برنامه‌نویسی را در کنار سینتکس آن بیاموزید](thing_27/README.md) 1. [](thing_28/README.md) 1. [](thing_29/README.md) 1. [](thing_30/README.md) From 19d074a9fbda530273686ddfdc5cb3e42415609d Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 14:19:41 +0300 Subject: [PATCH 165/290] Added number 27 --- fr-IR/thing_27/README.md | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/fr-IR/thing_27/README.md b/fr-IR/thing_27/README.md index 0ddeef10..f4d87c40 100644 --- a/fr-IR/thing_27/README.md +++ b/fr-IR/thing_27/README.md @@ -1,13 +1,14 @@ -# Don't Just Learn the Language, Understand its Culture +# فرهنگ استفاده از یک زبان برنامه‌نویسی را در کنار سینتکس آن بیاموزید -In high school, I had to learn a foreign language. At the time I thought that I'd get by nicely being good at English so I chose to sleep through three years of French class. A few years later I went to Tunisia on vacation. Arabic is the official language there and, being a former French colony, French is also commonly used. English is only spoken in the touristy areas. Because of my linguistic ignorance, I found myself confined at the poolside reading *Finnegans Wake*, James Joyce's tour de force in form and language. Joyce's playful blend of more than forty languages was a surprising albeit exhausting experience. Realizing how interwoven foreign words and phrases gave the author new ways of expressing himself is something I've kept with me in my programming career. +یش از آن که به موضوع این بخش از آموزش که «صرفاً سینتکس یک زبان برنامه نویسی را فرا نگیرید، بلکه فرهنگ استفاده از آن زبان را نیز بیاموزید» است بپردازیم، نیاز است تا مثالی از دنیای واقعی و آموزش یک زبان زنده بزنیم. -In their seminal book, *The Pragmatic Programmer*, Andy Hunt and Dave Thomas encourage us to learn a new programming language every year. I've tried to live by their advice and throughout the years I've had the experience of programming in many languages. My most important lesson from my polyglot adventures is that it takes more than just learning the syntax to learn a language: You need to understand its culture. You can write Fortran in any language, but to truly learn a language you have to embrace the language. Don't make excuses if your C# code is a long Main method with mostly static helper methods, but learn why classes make sense. Don't shy away if you have a hard time understanding the lambda expressions used in functional languages, force yourself to use them. +در فرایند آموزش زبان‌های خارجی به‌خصوص زبان انگلیسی، بسیاری از مدرسین زبان را می‌بینیم که می‌گویند "برای یادگیری زبان انگلیسی، شما نیاز به فراگیری چهار مهارت Reading, Writing, Listening, Speaking دارید." این توصیه اصلاً اشتباه نیست اما ناقص است! پیش از آن که بگوییم نقص این توصیه کجا است، ابتدا مثالی می زنیم. فرض کنیم که یک نفر از ایران به کشوری انگلیسی زبان مثل کانادا مهاجرت می کند. این فرد در محفلی نشسته و همه گپ و گفتگو می کنند. آقا/خانم مهاجر پس از آن که چیزی می گوید، یکی از حضار از حرفش لذت می‌برد یک شصت به وی نشان می دهد . شصت نشان دادن در فرهنگ غربی یعنی Bravo یا «آفرین، ایول، خیلی خوب بود!» اما در فرهنگ ما چه طور؟ نیاز به توضیح نیست که در فرهنگ ایرانی این علامت معنی خیلی خوبی ندارد! -Once you've learned the ropes of a new language, you'll be surprised how you'll start using languages you already know in new ways. I learned how to use delegates effectively in C# from programming Ruby, releasing the full potential of .NETs generics gave me ideas on how I could make Java generics more useful, and LINQ made it a breeze to teach myself Scala. +آقا/خانم مهاجر به دلیل این که از زیرساخت های فرهنگی کشور مقصد خبر ندارد، در چنین شرایطی کاملاً دستپاچه شده و حتی ممکن است سوء تفاهم در ذهنش شکل گیرد اما این در حالی است که اگر در کلاس‌های زبانی که پیش از مهاجرت شرکت کرده بود، مدرس اش علاوه بر مهارت های چهارگانه ی Reading, Writing, Listening, Speaking مهارت پنجمی تحت عنوان Culture یا «فرهنگ» را نیز به وی آموخته بود، او هرگز دچار سوء تفاهم نمی شد. -You'll also get a better understanding of design patterns by moving between different languages. C programmers find that C# and Java have commoditized the iterator pattern. In Ruby and other dynamic languages you might still use a visitor, but your implementation won't look like the example from the Gang of Four book. +به خاطر داشته باشید لیست این خرده فرهنگ‌ها بسیار زیاد است اما اگر بخواهیم به نمونه یی دیگر از اختلافات فرهنگی میان ایران و غرب مثال بزنیم، این که در ایران وقتی ما بخواهیم عدم تمایل خود را برای انجام کار با سر نشان دهیم، سر خود را بالا می‌اندازیم و نظر منفی خود را القاء می‌کنیم اما در فرهنگ غرب، برای نشان دادن این حس، سر خود را به سمت راست و چپ تکان می دهند! +یادگیری زبان‌های برنامه نویسی هم تاحدودی شبیه به یادگیری یک زبان زنده ی دنیا است. به عبارت دیگر، علاوه بر یادگیری سینتکس یک زبان برنامه نویسی، شما باید «فرهنگ» استفاده از آن زبان به‌خصوص را نیز بیاموزید. خیلی اوقات ما به خاطر عدم آگاهی از زیر و بم یک زبان برنامه نویسی، نمی‌توانیم آن طور که باید و شاید از تمام پتانسیل زبان انتخابی خود بهره ببریم و به طور مثال از یک زبان شیء گرای قدرتمند، همچون یک زبان پروسیژرال ساده استفاده می‌کنیم. -Some might argue that *Finnegans Wake* is unreadable, while others applaud it for its stylistic beauty. To make the book a less daunting read, single language translations are available. Ironically, the first of these was in French. Code is in many ways similar. If you write *Wakese* code with a little Python, some Java, and a hint of Erlang, your projects will be a mess. If you instead explore new languages to expand your mind and get fresh ideas on how you can solve things in different ways, you will find that the code you write in your trusty old language gets more beautiful for every new language you've learned. +علاوه بر این، آشنایی با زبان‌های برنامه نویسی مختلف، می‌تواند به شما دید بازتری در پیاده‌سازی ایده های نرم افزاری بدهد. به طور مثال، اگر یک زبان برنامه نویسی مثل پایتون، زبان اصلی شما باشد اما در عین حال با زبان‌هایی همچون جاوا و پی اچ پی هم آشنایی داشته باشید، درک به مراتب بهتری از تفاوت زبان‌های مختلف و دلایل انتخاب یک زبان برای پروژه یی خاص خواهید داشت. علاوه بر این، آشنایی با زبان‌های برنامه نویسی مختلف، می‌تواند دید خوبی در درک دیزاین پترن ها به شما بدهد. -By Anders Norås \ No newline at end of file +هشدار این نکته که آشنایی با زبان‌های برنامه نویسی چیز خوبی است هرگز بدان معنا نیست که شما باید از هر زبان برنامه نویسی کمی بدانید اما در هیچ کدام حرفه یی نباشید؛ همچون اقیانوسی به عمق یک سانتی متر! همواره توصیه این است که به جای تست کردن تکنولوژی های مختلف، به یک زبان برنامه نویسی چسبیده و در آن حرفه یی شد اما در عین حال نیم نگاهی هم به سایر فناوری ها داشته باشیم. From 6e57596f1721648ea2afe6c40d869aad054e0279 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 14:20:35 +0300 Subject: [PATCH 166/290] Added number 28 --- fr-IR/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fr-IR/SUMMARY.md b/fr-IR/SUMMARY.md index 108227e7..ef80c2d5 100644 --- a/fr-IR/SUMMARY.md +++ b/fr-IR/SUMMARY.md @@ -28,7 +28,7 @@ 1. [برای تست نرم‌افزار از دیتای واقعی استفاده کنید](thing_25/README.md) 1. [حتی یک ارور را هم نادیده نگیرید!](thing_26/README.md) 1. [فرهنگ استفاده از یک زبان برنامه‌نویسی را در کنار سینتکس آن بیاموزید](thing_27/README.md) -1. [](thing_28/README.md) +1. [اکسپش‌ها را به راحت‌ترین شکل ممکن هَندل کنید](thing_28/README.md) 1. [](thing_29/README.md) 1. [](thing_30/README.md) 1. [](thing_31/README.md) From 78f3a544f4ea6ec41bbb6dd5cdfc714f11d7108e Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 14:21:44 +0300 Subject: [PATCH 167/290] Added number 28 --- fr-IR/thing_28/README.md | 29 ++++++++++++----------------- 1 file changed, 12 insertions(+), 17 deletions(-) diff --git a/fr-IR/thing_28/README.md b/fr-IR/thing_28/README.md index 190805f9..07e21950 100644 --- a/fr-IR/thing_28/README.md +++ b/fr-IR/thing_28/README.md @@ -1,20 +1,15 @@ -# Don't Nail Your Program into the Upright Position +# اکسپش‌ها را به راحت‌ترین شکل ممکن هَندل کنید -I once wrote a spoof C++ quiz, in which I satirically suggested the following strategy for exception handling: +فرض کنیم برای هندل کردن Exception ها یا بهتر بگوییم «خطاهای» برنامه ی خود، کلاسی مخصوص این کار می نویسیم که مسئول هندل کردن هر گونه اکسپشنی است. مثلاً در زبان PHP برای هندل کردن اکسپشن ها، از ساختار زیر استفاده می شود: +``` C +try { + // do something + } catch (Exception $e) { + return $e; + } + ``` +کدی که می‌خواهیم اجرا شود را داخل بلوک try قرار داده و در صورت بروز هر گونه اکسپشنی، بلوک داخل catch اجرا خواهد شد. برخی برنامه نویسان هستند که داخل بلوک catch از یک جفت try/catch دیگر نیز استفاده می‌کنند تا بتوانند به صورت لایه به لایه، اصطلاحاً اکسپشن ها را هندل کنند. -> By dint of plentiful `try...catch` constructs throughout our code base, we are sometimes able to prevent our applications from aborting. We think of the resultant state as "nailing the corpse in the upright position." +چنین رویکردی گاهی اوقات منجر به سردرگمی های فراوانی می‌شود و نتیجه این که وقتی با یک اکسپشن رو به رو می شوید، متوجه نخواهید شد که مشکل دقیقاً از کجا است. همواره سعی کنید برای هندل کردن اکسپشن ها راحت‌ ترین و سر راست ترین رویکرد ممکن را انتخاب کنید تا در حین بزرگ شدن برنامه، با کمترین میزان سردرگمی مواجه شوید. -Despite my levity, I was actually summarizing a lesson I received at the knee of Dame Bitter Experience herself. - -It was a base application class in our own, homemade C++ library. It had suffered the pokings of many programmers' fingers over the years: Nobody's hands were clean. It contained code to deal with all escaped exceptions from everything else. Taking our lead from Yossarian in Catch-22, we decided, or rather felt (*decided* implies more thought than went into the construction of this monster) that an instance of this class should live forever or die in the attempt. - -To this end, we intertwined multiple exception handlers. We mixed in Windows' structured exception handling with the native kind (remember `__try...__except` in C++? Me neither). When things threw unexpectedly, we tried calling them again, pressing the parameters harder. Looking back, I like to think that when writing an inner `try...catch` handler within the catch clause of another, some sort of awareness crept over me that I might have accidentally taken a slip road from the motorway of good practice into the aromatic but insalubrious lane of lunacy. However, this is probably retrospective wisdom. - -Needless to say, whenever something went wrong in applications based on this class, they vanished like Mafia victims at the dockside, leaving behind no useful trail of bubbles to indicate what the hell happened, notwithstanding the dump routines that were supposedly called to record the disaster. Eventually — a long eventually — we took stock of what we had done, and experienced shame. We replaced the whole mess with a minimal and robust reporting mechanism. But this was many crashes down the line. - -I wouldn't bother you with this — for surely nobody else could ever be as stupid as we were — but for an online argument I had recently with a bloke whose academic job title declared he should know better. We were discussing Java code in a remote transaction. If the code failed, he argued, it should catch and block the exception *in situ*. ("And then do *what* with it?" I asked. "Cook it for supper?") - -He quoted the UI designers' rule: NEVER LET THE USER SEE AN EXCEPTION REPORT, rather as though this settled the matter, what with it being in caps and everything. I wonder if he was responsible for the code in one of those blue-screened ATMs whose photos decorate the feebler blogs, and had been permanently traumatized. -Anyway, if you should meet him, nod and smile and take no notice, as you sidle towards the door. - -By [Verity Stob](http://programmer.97things.oreilly.com/wiki/index.php/Verity_Stob) \ No newline at end of file +علاوه بر این، توجه داشته باشید که کاربر نرم‌افزار شما تحت هیچ عنوان نباید اکسپشن هایی که اساساً راهنمای توسعه دهندگان برای رفع باگ های سیستم هستند را مشاهده کنند چرا که علاوه بر ایجاد یک تجربه کاربری نامطلوب، اکسپشن ها معمولاً اطلاعاتی زیرساخت از نرم‌افزار در اختیار کاربر قرار می‌دهند که همین مسأله می‌تواند منجر به پایین آمدن ضریب امنیتی نرم‌افزار شما شود. From 55f30764971638b27d98583eb0e3c12ef1c58534 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 14:22:13 +0300 Subject: [PATCH 168/290] Added number 29 --- fr-IR/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fr-IR/SUMMARY.md b/fr-IR/SUMMARY.md index ef80c2d5..7cf3a9f5 100644 --- a/fr-IR/SUMMARY.md +++ b/fr-IR/SUMMARY.md @@ -29,7 +29,7 @@ 1. [حتی یک ارور را هم نادیده نگیرید!](thing_26/README.md) 1. [فرهنگ استفاده از یک زبان برنامه‌نویسی را در کنار سینتکس آن بیاموزید](thing_27/README.md) 1. [اکسپش‌ها را به راحت‌ترین شکل ممکن هَندل کنید](thing_28/README.md) -1. [](thing_29/README.md) +1. [فرایند توسعه یک نرم‌افزار خوب اصلاً شانسی نیست](thing_29/README.md) 1. [](thing_30/README.md) 1. [](thing_31/README.md) 1. [](thing_32/README.md) From 98c04c8ee6016ca817d75c1039e867e78f20524b Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 14:23:13 +0300 Subject: [PATCH 169/290] Added number 29 --- fr-IR/thing_29/README.md | 22 ++++++---------------- 1 file changed, 6 insertions(+), 16 deletions(-) diff --git a/fr-IR/thing_29/README.md b/fr-IR/thing_29/README.md index 7db46819..eec4c488 100644 --- a/fr-IR/thing_29/README.md +++ b/fr-IR/thing_29/README.md @@ -1,21 +1,11 @@ -# Don't Rely on "Magic Happens Here" +# فرایند توسعه یک نرم‌افزار خوب اصلاً شانسی نیست -If you look at any activity, process, or discipline from far enough away it looks simple. Managers with no experience of development think what programmers do is simple and programmers with no experience of management think the same of what managers do. +اگر ما به هر چیزی از مکانیکی گرفته تا نجاری و یا طراحی و سایر کارهای هنری نگاه کنیم، خارج از گود همه این کارها ساده به نظر می رسند؛ مدیران معمولاً بر این باورند که توسعه دهندگان اصلاً کار عجیب و غریبی انجام نمی‌دهند و توسعه دهندگان هم در مقابل فکر می‌کنند مدیران فقط در دفتر خود نشسته و دستور می دهند! -Programming is something some people do — some of the time. And the hard part — the thinking — is the least visible and least appreciated by the uninitiated. There have been many attempts to remove the need for this skilled thinking over the decades. One of the earliest and most memorable is the effort by Grace Hopper to make programming languages less cryptic — which some accounts predicted would remove the need for specialist programmers. The result (COBOL) has contributed to the income of many specialist programmers over subsequent decades. +برنامه نویسی صرفاً نوشتن کد نیست بلکه توانایی حل مسئله، الگوریتم نویسی، تحلیل دیتابیس و … جزو بخش‌های لاینفک حرفه ی برنامه نویسی اند که کمتر مد نظر قرار داده می‌شوند و سختی این دست مهارت ها در مقایسه با کدنویسی به مراتب بیشتر است. -The persistent vision that software development can be simplified by removing programming is, to the programmer who understands what is involved, obviously naïve. But the mental process that leads to this mistake is part of human nature and programmers are just as prone to making it as everyone else. +با در نظر گرفتن این مسائل، باز هم شاهد برخی برنامه نویسان هستیم که صرفاً درگیر فرایند توسعه ی نرم‌افزار بوده و هرگز در مسائلی همچون تحلیل بازار، تجربه ی کاربری، تأمین بودجه ی توسعه ی نرم افزار، راه اندازی سرور، تضمین کیفیت محصول نهایی، نگهداری نرم‌افزار و … دخالت نمی کنند و معمولاً فکر می‌کنند که دشوارترین کار ممکن در توسعه ی یک محصول نرم‌افزاری مختص به خودشان است و سایر اعضای تیم هیچ کار خاصی انجام نمی دهند. -On any project there are likely many things that an individual programmer doesn't get actively involved in: eliciting requirements from users, getting budgets approved, setting up the build server, deploying the application to QA and production environments, migrating the business from the old processes or programs, etc. +گاهی اوقات مدیران شرکت های نرم افزاری هم در چنین دامی می افتند. پروژه آنقدر سر وقت، بدون باگ و خوب تحویل مشتری می‌شود که مدیر فکر می‌کند همه چیز با «اجی مجی لاترجی» درست شده و حضور «مدیر پروژه» را اساساً اضافی تلقی می کنند. -When you aren't actively involved in things there is an unconscious tendency to assume that they are simple and happen "by magic." While the magic continues to happen all is well. But when — it is usually "when" and not "if" — the magic stops the project is in trouble. - -I've known projects lose weeks of developer time because no one understood how they relied on "the right" version of a DLL being loaded. When things started failing intermittently team members looked everywhere else before someone noticed that "a wrong" version of the DLL was being loaded. - -Another department was running smoothly — projects delivered on time, no late night debugging sessions, no emergency fixes. So smoothly, in fact, that senior management decided that things "ran themselves" and they could do without the project manager. Inside six months the projects in the department looked just like the rest of the organization — late, buggy and continually being patched. - -You don't have to understand all the magic that makes your project work, but it doesn't hurt to understand some of it — or to appreciate someone who understands the bits you don't. - -Most importantly, make sure that when the magic stops it can be started again. - -By [AlanGriffiths](http://programmer.97things.oreilly.com/wiki/index.php/AlanGriffiths) \ No newline at end of file +این‌ها دام‌هایی هستند که معمولاً اعضای تیم های نرم افزاری در آن‌ها می‌افتند که شدیداً باید از این‌گونه دام‌ها حذر کرد. در فرایند توسعه ی نرم‌افزار سعی کنید در یک حوزه عمیق شوید و به خوبی زیر و بم آن را فرا بگیرید اما هرگز از سایر حوزه ها مثل هاستینگ، کانفیگ سرور، مسائل امنیتی، بهینه سازی و … غافل نشوید چرا که آگاهی از این حوزه ها، منجر به این خواهد شد تا با دید بازتری بتوانید برای حل مسائل پیچیده ی پروژه ی خود، الگوریتم هایی اصولی و بهینه بنویسید. From de4537a32b21c05b37befc6c0980a54c5d3bb14a Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 14:23:48 +0300 Subject: [PATCH 170/290] Added number 29 --- fr-IR/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fr-IR/SUMMARY.md b/fr-IR/SUMMARY.md index 7cf3a9f5..ce269a5c 100644 --- a/fr-IR/SUMMARY.md +++ b/fr-IR/SUMMARY.md @@ -30,7 +30,7 @@ 1. [فرهنگ استفاده از یک زبان برنامه‌نویسی را در کنار سینتکس آن بیاموزید](thing_27/README.md) 1. [اکسپش‌ها را به راحت‌ترین شکل ممکن هَندل کنید](thing_28/README.md) 1. [فرایند توسعه یک نرم‌افزار خوب اصلاً شانسی نیست](thing_29/README.md) -1. [](thing_30/README.md) +1. [آشنایی با قانون DRY](thing_30/README.md) 1. [](thing_31/README.md) 1. [](thing_32/README.md) 1. [](thing_33/README.md) From 1cc4a1929fa0157192afbd9b686b722eb4baef6a Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 14:26:00 +0300 Subject: [PATCH 171/290] Added number 30 --- fr-IR/thing_30/README.md | 28 ++++++++++++---------------- 1 file changed, 12 insertions(+), 16 deletions(-) diff --git a/fr-IR/thing_30/README.md b/fr-IR/thing_30/README.md index 45f99d2f..0dbb82d7 100644 --- a/fr-IR/thing_30/README.md +++ b/fr-IR/thing_30/README.md @@ -1,27 +1,23 @@ -# Don't Repeat Yourself +# آشنایی با قانون DRY -Of all the principles of programming, Don't Repeat Yourself (DRY) is perhaps one of the most fundamental. The principle was formulated by Andy Hunt and Dave Thomas in *The Pragmatic Programmer*, and underlies many other well-known software development best practices and design patterns. The developer who learns to recognize duplication, and understands how to eliminate it through appropriate practice and proper abstraction, can produce much cleaner code than one who continuously infects the application with unnecessary repetition. +در حوزه ی توسعه ی نرم افزار، اصول و قواعد بسیاری وجود دارد که گاها یکی از دیگری مهم‌تر جلوه می‌کند اما یکی از اساسی‌ترین قواعد برنامه نویسی، قانون DRY است که مخفف واژگان Don't Repeat Yourself به معنی«دوباره کاری نکن» است! -Duplication is waste ---- +این قانون توسط دو توسعه‌دهنده به نام های Andy Hunt و Dave Thomas ابداع شد که بسیاری از دیزاین پترن های معروف برنامه نویسی، ریشه در این قانون دارند. -Every line of code that goes into an application must be maintained, and is a potential source of future bugs. Duplication needlessly bloats the codebase, resulting in more opportunities for bugs and adding accidental complexity to the system. The bloat that duplication adds to the system also makes it more difficult for developers working with the system to fully understand the entire system, or to be certain that changes made in one location do not also need to be made in other places that duplicate the logic they are working on. DRY requires that "every piece of knowledge must have a single, unambiguous, authoritative representation within a system." +برنامه نویسی که بتواند تشخیص دهد کدام بخش‌های کد اصطلاحاً Duplicate یا «مشابه» هستند و تمام تلاش خود را به کار بندد تا با استفاده از کلاس‌ها و فانکشن های مختلف، میزان استفاده از کدهای تکراری در سراسر برنامه را به حداقل برساند، در نهایت سورس کد تمیز تری تحویل خواهد داد که در آینده نگهداری چنین پروژه یی به مراتب راحت‌تر از سورس کدی است که پر است از کدهای مشابه! -Repetition in process calls for automation ---- +هرچه میزان کدهای دوپلیکیت در سورس کد شما بیشتر باشد، احتمال ایجاد باگ در آینده به مراتب بیشتر خواهد شد؛ علاوه بر این، اگر روزی بخواهید بخشی از کد خود را ریفکتور کنید یا تغییر دهید، به جای یک بخش، می بایست چندین بخش را ریفکتور کنید که این کاری بس زمان گیر است. -Many processes in software development are repetitive and easily automated. The DRY principle applies in these contexts as well as in the source code of the application. Manual testing is slow, error-prone, and difficult to repeat, so automated test suites should be used, if possible. Integrating software can be time consuming and error-prone if done manually, so a build process should be run as frequently as possible, ideally with every check-in. Wherever painful manual processes exist that can be automated, they should be automated and standardized. The goal is to ensure there is only one way of accomplishing the task, and it is as painless as possible. +در فرایند توسعه ی نرم افزار، بخش‌های بسیاری از کد را می‌توان دید که تکراری هستند و قانون DRY دقیقاً برای چنین موقعیت هایی است. شما به عنوان یک توسعه‌دهنده ی حرفه یی، همواره باید این ذهنیت را داشته باشید که در نرم افزاری که می نویسید -خواه یک اپ موبایل باشد و خواه یک سایت- صرفاً از یک راه باید بتوان کار خاصی را انجام داد (مثلاً ارتباط با دیتابیس) و این راه‌کار باید تا حد ممکن ساده، ایمن و اثربخش باشد. -Repetition in logic calls for abstraction ---- +دوپلیکیت شدن در منطق نرم‌افزار می‌تواند به اشکال مختلفی جلوه کند که از جمله ی رایج ترین آن‌ها می‌توان به آبجکت هایی که از روی کلاس خاصی ساخته می‌شوند اشاره کرد و اینجا است که بسیاری از دیزاین پترن ها به داد توسعه دهندگان می آیند. در واقع، ابداع دیزاین پترن ها یا «الگوهای طراحی» جلوگیری از استفاده از کدهای مشابه است. -Repetition in logic can take many forms. Copy-and-paste *if-then* or *switch-case* logic is among the easiest to detect and correct. Many design patterns have the explicit goal of reducing or eliminating duplication in logic within an application. If an object typically requires several things to happen before it can be used, this can be accomplished with an Abstract Factory or a Factory Method. If an object has many possible variations in its behavior, these behaviors can be injected using the Strategy pattern rather than large *if-then* structures. In fact, the formulation of design patterns themselves is an attempt to reduce the duplication of effort required to solve common problems and discuss such solutions. In addition, DRY can be applied to structures, such as database schema, resulting in normalization. +به طور مثال، اگر آبجکتی داریم که «عملکردها و رفتارهای» متنوعی از آن انتظار می رود، به جای استفاده از دستورات شرطی if برای هندل کردن چنین موقعیت هایی، چنین عملکردها و رفتارهایی را می‌توان با استفاده از دیزاین پترن Strategy عملی ساخت. -A Matter of principle ---- +علاوه بر دیزاین پترن ها، یکسری اصول کدنویسی که تحت عنوان SOLID شناخته می‌شوند نیز بر پایه ی اصل DRY هستند (برای آشنایی بیشتر با مفهوم SOLID، به آموزش آشنایی با قوانین پنج گانهٔ SOLID مراجعه نمایید.) به طور مثال، حرف S در ابتدای SOLID به اصطلاح Single Responsibility اشاره دارد. به عبارت دیگر، هر کلاسی که در پروژه ی خود ایجاد می‌کنیم فقط و فقط باید مسئول یک کار باشد و در صورت نیاز به اعمال تغییرات در کلاس مد نظر، فقط و فقط باید یک دلیل برای ایجاد آن تغییر وجود داشته باشد نه اینکه کلاس مد نظر در جای جای نرم‌افزار برای کارهای مختلفی استفاده شده باشد و به هر دلیلی، نیاز به اعمال تغییرات در آن کلاس داشته باشیم. -Other software principles are also related to DRY. The Once and Only Once principle, which applies only to the functional behavior of code, can be thought of as a subset of DRY. The Open/Closed Principle, which states that "software entities should be open for extension, but closed for modification," only works in practice when DRY is followed. Likewise, the well-known Single Responsibility Principle requires that a class have "only one reason to change," relies on DRY. +به عنوان مثالی دیگر، حرف O در SOLID به اصلی تحت عنوان Open/Closed Principle اشاره دارد. این اصل حاکی از آن است که کدی که می نویسید باید «امکان توسعه یافتن را به برنامه نویسان دیگر بدهد اما تحت هیچ عنوان امکان ایجاد تغییر در کدهای قبلی را ندهد.» چنین اصلی این تضمین را ایجاد می‌کند که نرم‌افزار در فرایند توسعه و تکمیل با این مشکل مواجه نخواهد شد که برنامه نویس دیگری بیاید، بخش‌هایی را تغییر دهد غافل از اینکه این اعمال تغییرات، منجر به ایجاد خرابی در سایر بخش‌های نرم‌افزار شده است. -When followed with regard to structure, logic, process, and function, the DRY principle provides fundamental guidance to software developers and aids the creation of simpler, more maintainable, higher-quality applications. While there are scenarios where repetition can be necessary to meet performance or other requirements (e.g., data denormalization in a database), it should be used only where it directly addresses an actual rather than an imagined problem. +به طور کلی، مد نظر داشتن قانون DRY در توسعه ی نرم افزار، راه‌کاری است که از آن طریق می‌توان برنامه‌هایی اصولی تر، ساده تر، بدون باگ تر، قابل نگهداری تر و مهم‌تر از همه، باکیفیت تر نوشت؛ البته هرگز فراموش نکنیم که گاهی اوقات شرایطی برای توسعه‌دهنده پیش می‌آید که مجبور به تکرار کد است -مثلا در فرایند Denormalization دیتابیس- که در چنین شرایطی دوباره کاری اصلاً مشکلی ندارد! -By [Steve Smith](http://programmer.97things.oreilly.com/wiki/index.php/Steve_Smith) \ No newline at end of file +به خاطر داشته باشید در کار با دیتابیس یا پایگاه داده، Denormalization به فرایندی گفته می‌شود که از آن طریق توسعه‌دهنده سعی می‌کند پرفورمنس یا عملکرد فراخوانی داده‌ها از دیتابیس را با اضافه کردن داده‌های تکراری یا اضافی و همچنین گروه بندی کردن داده‌ها ارتقاء بخشد. نقطه ی مقابل این فرایند، Normalization قرار دارد که تمرکزش بر کاهش هرچه تمام تر داده‌های اضافی و تکراری در دیتابیس است. From 23a3e5de71a4510c18250a35975a5510faed4a88 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 14:30:26 +0300 Subject: [PATCH 172/290] Added number 31 --- fr-IR/thing_31/README.md | 38 ++++++++++++++++++++++++-------------- 1 file changed, 24 insertions(+), 14 deletions(-) diff --git a/fr-IR/thing_31/README.md b/fr-IR/thing_31/README.md index 22ed6e5c..2264b99e 100644 --- a/fr-IR/thing_31/README.md +++ b/fr-IR/thing_31/README.md @@ -1,23 +1,33 @@ -# Don't Touch that Code! +# شنایی با مراحل توسعهٔ نرم‌افزار -It has happened to everyone of us at some point. Your code was rolled on to the staging server for system testing and the testing manager writes back that she has hit a problem. Your first reaction is "Quick, let me fix that — I know what's wrong." +ه طور کلی، فرایند توسعه ی نرم‌افزار به‌خصوص وب اپلیکیشن ها به ۴ دسته ی زیر تقسیم‌بندی می‌شوند که یک توسعه‌دهنده باید به خوبی با ویژگی‌های هر کدام آشنا باشد که در این آموزش، به تفصیل در مورد خصوصیات هر مرحله توضیح خواهیم داد. -In the bigger sense, though, what is wrong is that as a developer you think you should have access to the staging server. +فرایند توسعه ی نرم‌افزار دارای مراحل مختلفی است که به هر کدام از آن‌ها اصطلاحاً Tier (تایر به معنی مرحله) گفته می شود. شرکت های کوچک دارای سه محیط Development و Stage و Production هستند اما شرکت های متوسط و بزرگ معمولاً یک محیط QA یا Quality Assurance به معنی «تضمین کیفیت» نیز می باشند. -In most web-based development environments the architecture can be broken down like this: +مفهوم Development: این محیط که به صورت خلاصه dev نامیده می شود، شامل کلیه ی سخت افزارها و نرم افزارهای مورد نیاز برای اجرای صحیح نرم‌افزار است که توسط توسعه‌دهنده مورد استفاده قرار می‌گیرد و معمولاً شامل آخرین تغییرات صورت گرفته روی نرم‌افزار است. توسعه‌دهنده تغییرات مد نظر خود را روی سورس کد اعمال کرده و آن‌ها را در محیط توسعه ی نرم‌افزار لوکال خود -مثلا لپ تاپش- تست می‌کند و از درست کار کردن کدها اطمینان حاصل می کند. -- Local development and unit testing on the developer's machine -- Development server where manual or automated integration testing is done -- Staging server where the QA team and the users do acceptance testing -- Production server +لازم به ذکر است که این محیط توسعه ی نرم‌افزار کاملاً فردی است و تغییرات اعمال شده روی کد، عملکرد کدهای سایر توسعه دهندگان را تحت تأثیر خود قرار نخواهد داد. علاوه بر این، در محیط dev، توسعه‌دهنده از ابزارهای مختلفی برای توسعه ی نرم‌افزار استفاده می‌کند که از آن جمله می‌توان به ماشین‌های مجازی، لایبرری های مختلف، IDE های مختلف، کامپایلر و … اشاره کرد. با توجه به اینکه محیط توسعه ی dev یک محیط کاملاً فردی است و از توسعه‌دهنده یی به توسعه‌دهنده ی دیگر متفاوت است، این محیط را Local Environment یا Sandbox هم می نامند. -Yes, there are other servers and services sprinkled in there, like source code control and ticketing, but you get the idea. Using this model, a developer — even a senior developer — should never have access beyond the development server. Most development is done on a developer's local machine using their favorite blend of IDEs, virtual machines, and an appropriate amount of black magic sprinkled over it for good luck. +مفهوم Staging: این مرحله از توسعه ی نرم‌افزار که تحت عنوان Integration هم شناخته می شود، مرحله یی است که سایت یا اپلیکیشن در محیطی کاملاً شبیه به محیط Production تست می‌شود و Quality Assurance به معنی «تضمین کیفیت» که به طور خلاصه QA نامیده می‌شود نیز روی آن اعمال می گردد. کانفیگ سروری که برای این مرحله از کار استفاده می شود کاملاً مشابه سرور اصلی است. تیم های توسعه ی نرم‌افزار حرفه یی برای اپلیکیشن هایی که هزاران کاربر دارند را پیش از فرستادن روی سرور اصلی، حتماً روی Staging Server تست می کنند. -Once checked into SCC, whether automatically or manually, it should be rolled over to the development server where it can be tested and tweaked if necessary to make sure everything works together. From this point on, though, the developer is a spectator to the process. +مفهوم Production: این محیط که اصطلاحاً محیط Live نامیده می شود، همان سروری است که نرم‌افزار -مثلا وب سایت- روی آن پیاده‌سازی شده و کاربران نهایی می‌توانند از آن استفاده کنند و آخرین مرحله از فرایند توسعه ی نرم‌افزار است (سروری که هم اکنون سکان آکادمی روی آن پیاده سازی شده و شما قادرید این آموزش را مطالعه فرمایید یک محیط Production است.) اپلیکیشن پس از تست و اطمینال حاصل کردن از درست بودن همه چیز و Bug-free بودن آن، روی سرور Production فرستاده می شود. -The staging manager should package and roll the code to the staging server for the QA team. Just like developers should have no need to access anything beyond the development server, the QA team and the users have no need to touch anything on the development server. If it's ready for acceptance testing, cut a release and roll, don't ask the user to "Just look at something real quick" on the development server. Remember, unless you are coding the project by yourself, other people have code there and they may not be ready for the user to see it. The release manager is the only person who should have access to both. +نکته توجه داشته باشید که آپدیت کردن اپلیکیشن در مرحله ی Production باید در زمانی صورت گیرد که حداقل تعداد کاربران در حال استفاده از اپلیکیشن -مثلا وب سایت- باشند (مثلا ساعت ۳ نیمه شب). علاوه بر این، زمانی که آخرین تغییرات روی سرور Live اعمال می شوند، باید تمامی اعضای تیم از این قضیه مطلع باشند تا در صورت بروز هرگونه مشکلی، خیلی سریع بتوان آن را مرتفع ساخت. -Under no circumstances — ever, at all — should a developer have access to a production server. If there is a problem, your support staff should either fix it or request that you fix it. After it's -checked into SCC they will roll a patch from there. Some of the biggest programming disasters I've been a part of have taken place because someone \**cough*\*me\**cough\** violated this last rule. If it's broke, production is not the place to fix it. +در واقع Production Deployment شکل‌های مختلفی دارد که بسته به ماهیت اپلیکیشن، می‌توان یکی از آن‌ها را انتخاب کرد: +- جایگزین -Override- کردن کدهای قدیمی با کدهای جدید از طریف اف تی پی +- پیاده‌سازی نسخه یی جدید از اپلیکیشن روی سرور به موازات نسخه ی قبلی و هدایت کردن کاربران به نسخه ی جدید با تغییر کانفیگ سرور +- استفاده از یک سرور کاملاً جدید حاوی آخرین ریلیس و ریدایرکت کردن ترافیک از سرور قدیمی به سرور جدید -by [Cal Evans](http://programmer.97things.oreilly.com/wiki/index.php/Cal_Evans) \ No newline at end of file +چه موقع Rollback کنیم؟ +گاهی اوقات در فرایند توسعه نرم‌افزار پیش می‌آید که همه چیز به خوبی پیش نمی‌رود و بلافاصله پس از Deployment یا «فرستادن آخرین نسخه روی سرور اصلی» اپلیکیشن می ترکد! در چنین شرایطی ما نیاز به Rollback کردن داریم. به عبارت دیگر، اپلیکیشن خود را به آخرین ورژنی که به درستی کار می‌کرد باز گردانیم. گاهی اوقات با Rollback کردن نه تنها مشکل برطرف نمی شود، بلکه چندین مشکل دیگر نیز ایجاد می‌گردد؛ لذا در چنین شرایطی کاملاً باید با احتیاط عمل کنیم. زمانی که نیاز به رول بک پیدا کردید، پیش از هرگونه اقدامی، سؤالات زیر را از خود بپرسید؟ + +آیا مشکل به خاطر کدی که Deploy کردید بوجود آمد یا دلیل دیگری وجود دارد؟ شما صرفاً زمانی می‌توانید رول بک کنید که مشکل بوجود آمده مرتبط با فایل‌هایی باشد که آپلود کرده‌اید و در غیر این صورت، رول بک کاری از پیش نخواهد برد! ممکن است دقیقا در زمانی که شما آخرین ریلیس را آپلود می کنید، یک مشکل سروری هم بوجود آید و شما فکر کنید که مشکل از آخرین آپدیت بوده و کاملا گمراه شوید. + +آیا رول بک کردن امکان‌پذیر است؟ هر Release یا نسخه یی از اپلیکیشن قابل رول بک کردن نیست؛ فرض کنید که آخرین ریلیس نرم‌افزار شما حاوی اسکمای متفاوتی از دیتابیس است که در چنین شرایطی رول بک کردن اوضاع را وخیم تر هم می کند. + +به هر حال، اگر پاسخ شما به دو سؤال فوق «آری» است، با خیال راحت می‌توانید رول بک کنید اما توجه داشته باشید که پاسخ آری دادن به دو سؤال بالا هرگز کاری آسان نیست. + +نکته ی دیگری که در ارتباط با ریلیس نسخه های جدید نرم‌افزار باید مد نظر قرار داد، مفهومی است تحت عنوان Automatic Deployments to Production که این اصطلاح حاکی از آن است که ما به صورت اتوماتیک، آخرین تغییرات را بلافاصله روی سرور اصلی آپلود کنیم. به طور مثال، می‌توان نرم‌افزار اف تی پی را به گونه یی تنظیم کرد که بلافاصله پس از مشاهده ی تغییری در هر فایلی، آن فایل را جایگزین فایل متناظر روی سرور کند (جهت آشنایی بیشتر با مفهوم اف تی پی، به آموزش اف تی پی چیست؟ مراجعه نمایید.) + +چنین کاری را می‌توان به عنوان یکی از پر ریسک ترین و خطرناک ترین کارها در فرایند توسعه ی نرم‌افزار قلمداد کرد و شدیدا باید از آن پرهیز کرد. فرض کنید توسعه‌دهنده یی به اشتباه کدی را تغییر می‌دهد و آن کد هم بلافاصله روی سرور آپلود می‌شود و فرایند اجرای صحیح نرم‌افزار دچار اختلال می شود. From bb98eb38996a48cdb619db86c30a026bfceff89c Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 14:30:36 +0300 Subject: [PATCH 173/290] Added number 31 --- fr-IR/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fr-IR/SUMMARY.md b/fr-IR/SUMMARY.md index ce269a5c..9d366fbb 100644 --- a/fr-IR/SUMMARY.md +++ b/fr-IR/SUMMARY.md @@ -31,7 +31,7 @@ 1. [اکسپش‌ها را به راحت‌ترین شکل ممکن هَندل کنید](thing_28/README.md) 1. [فرایند توسعه یک نرم‌افزار خوب اصلاً شانسی نیست](thing_29/README.md) 1. [آشنایی با قانون DRY](thing_30/README.md) -1. [](thing_31/README.md) +1. [شنایی با مراحل توسعهٔ نرم‌افزار](thing_31/README.md) 1. [](thing_32/README.md) 1. [](thing_33/README.md) 1. [جاه طلبی خود را با شرکت در پروژه های متن باز برآروده کنید.](thing_34/README.md) From b6a9bdcf90fffe9a656815dd8dc9a0cae0770c6f Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 14:31:05 +0300 Subject: [PATCH 174/290] Added number 32 --- fr-IR/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fr-IR/SUMMARY.md b/fr-IR/SUMMARY.md index 9d366fbb..553e3ad2 100644 --- a/fr-IR/SUMMARY.md +++ b/fr-IR/SUMMARY.md @@ -32,7 +32,7 @@ 1. [فرایند توسعه یک نرم‌افزار خوب اصلاً شانسی نیست](thing_29/README.md) 1. [آشنایی با قانون DRY](thing_30/README.md) 1. [شنایی با مراحل توسعهٔ نرم‌افزار](thing_31/README.md) -1. [](thing_32/README.md) +1. [به‌کارگیری درست از اصول برنامه‌نویسی شیٔ‌گرا](thing_32/README.md) 1. [](thing_33/README.md) 1. [جاه طلبی خود را با شرکت در پروژه های متن باز برآروده کنید.](thing_34/README.md) 1. [قانون طلایی طراحی API](thing_35/README.md) From f4ac51b2a4bb86601048fb0c58762d2b31492ae7 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 14:31:52 +0300 Subject: [PATCH 175/290] Added number 32 --- fr-IR/thing_32/README.md | 16 +++++++--------- 1 file changed, 7 insertions(+), 9 deletions(-) diff --git a/fr-IR/thing_32/README.md b/fr-IR/thing_32/README.md index 867a9891..91cc29a0 100644 --- a/fr-IR/thing_32/README.md +++ b/fr-IR/thing_32/README.md @@ -1,15 +1,13 @@ -# Encapsulate Behavior, not Just State +# به‌کارگیری درست از اصول برنامه‌نویسی شیٔ‌گرا -In systems theory, containment is one of the most useful constructs when dealing with large and complex system structures. In the software industry the value of containment or encapsulation is well understood. Containment is supported by programming language constructs such as subroutines and functions, modules and packages, classes, and so on. +در برنامه نویسی شیء گرا مفهومی داریم تحت عنوان Encapsulation که به زمانی اطلاق می‌شود که ما Attribute ها وBehavior های یک آبجکت را در کپسولی فرضی در کنار یکدیگر قرار می دهیم. علاوه بر این، با به کارگیری مفهومی تحت عنوان Encapsulation ما خواهیم توانست دسترسی به بخش یا بخش‌هایی از یک کلاس یا آبجکتی که بر اساس آن کلاس نوشته شده را محدود کنیم. -Modules and packages address the larger scale needs for encapsulation, while classes, subroutines, and functions address the more fine-grained aspects of the matter. Over the years I have discovered that classes seem to be one of the hardest encapsulation constructs for developers to get right. It's not uncommon to find a class with a single 3000-line main method, or a class with only *set* and *get* methods for its primitive attributes. These examples demonstrate that the developers involved have not fully understood object-oriented thinking, having failed to take advantage of the power of objects as modeling constructs. For developers familiar with the terms POJO (Plain Old Java Object) and POCO (Plain Old C# Object or Plain Old CLR Object), this was the intent in going back to the basics of OO as a modeling paradigm — the objects are plain and simple, but not dumb. +حال ممکن است این سؤال برای شما پیش بیاید که "اگر من خودم اقدام به ساخت یک کلاس می کنم، چه لزومی دارد که بخش یا بخش‌هایی از کلاس ساخته شده را از خودم پنهان سازم؟" در پاسخ به چنین سؤالی بایستی گفت که در اینجا قضیه پنهان کاری و … نیست، بلکه در اینجا منظور به حداقل رساندن وابستگی میان بخش‌های مختلف برنامه است. در چنین شرایطی، ایجاد یک تغییر کوچک در کلاس مد نظر -مثلا محدود کردن سطح دسترسی به برخی قابلیت‌های کلاس- فوراً روی تمامی آبجکت های ساخته شده از روی این کلاس اعمال خواهد شد. -An object encapsulates both state and behavior, where the behavior is defined by the actual state. Consider a door object. It has four states: closed, open, closing, opening. It provides two operations: open and close. Depending on the state, the open and close operations will behave differently. This inherent property of an object makes the design process conceptually simple. It boils down to two simple tasks: allocation and delegation of responsibility to the different objects including the inter-object interaction protocols. +امروزه برخی برنامه نویسان را می‌بینیم که مثلاً کلاسی ساخته‌اند که یک متد main چند صد خطی دارد و یا کلاسی که صرفاً داری متدهای set و get است. چنین نمونه‌هایی حاکی از آنند که توسعه دهندگان هنوز با مفهوم واقعی شیء گرایی آشنا نشده اند. -How this works in practice is best illustrated with an example. Let's say we have three classes: Customer, Order, and Item. A Customer object is the natural placeholder for the credit limit and credit validation rules. An Order object knows about its associated Customer, and its addItem operation delegates the actual credit check by calling `customer.validateCredit(item.price())`. If the postcondition for the method fails, an exception can be thrown and the purchase aborted. +پیش از این گفتیم که یک آبجکت دربرگیرنده ی یکسری Attribute ها وBehavior ها است و این در حالی است که رفتار آبجکت بسته به فضایی که در آن قرار گرفته متغیر است. برای روشن شدن این مسأله مثالی می زنیم. فرض کنیم یک درب منزل داریم. این در، می‌تواند چهار State (یا حالت) مختلف داشته باشد: بسته، باز، در حال بسته شدن و در حال باز شدن اما این درب منزل به هر حال دارای دو عملکرد بیشتر نیست: باز شدن و بسته شدن و بسته به حالتی که در آن قرار دارد، عملکردهای باز و بسته رفتارهای متفاوتی می توانند داشته باشند. -Less experienced object oriented developers might decide to wrap all the business rules into an object very often referred to as `OrderManager` or `OrderService`. In these designs, `Order`, `Customer`, and `Item` are treated as little more than record types. All logic is factored out of the classes and tied together in one large, procedural method with a lot of internal *if-then-else* constructs. These methods are easily broken and are almost impossible to maintain. The reason? The encapsulation is broken. +برای روشن تر شدن مطلب، مثالی از دنیای برنامه نویسی بزنیم. فرض کنیم سه کلاًس داریم تحت عناوین Customer, Order و Item. کلاس Customer برای نگهداری اعتبار حساب مشتریان و سایر مسائل مربوطه مورد استفاده قرار می گیرد. آبجکتی هم که از روی کلاس Order ساخته می‌شود مسئول سفارش‌های مربوط به یک مشتری را هندل می‌کند و آبجکت های ساخته شده از روی کلاس Item هم مسئول اضافه کردن محصول به سبد خرید هستند. داشتن چنین کلاس هایی حاکی از آنند که ما به درستی اصول برنامه نویسی شیء گرایی را به کار می گیریم. -So in the end, don't break the encapsulation, and use the power of your programming language to maintain it. - -By [Einar Landre](http://programmer.97things.oreilly.com/wiki/index.php/Einar_Landre) \ No newline at end of file +اما در مقابل، برنامه نویسانی که تجربه ی کمتری در زمینه ی شیء گرایی دارند تمامی منطق نرم افزاری خود را مثلاً در کلاسی تحت عنوان OrderService قرار داده و بسته به نیاز خود آبجکت هایی از روی آن می سازند که این اصلا کار درستی نیست! به عنوان فصل الخطاب، سعی کنید تا حد ممکن یکی از اصول مهم برنامه نویسی شیء گرا یعنی Encapsulation را در حین کدنویسی رعایت کنید. From 34d3c7e4171016fed1e370fd93fb245fc6e39686 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 14:32:19 +0300 Subject: [PATCH 176/290] Added number 33 --- fr-IR/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fr-IR/SUMMARY.md b/fr-IR/SUMMARY.md index 553e3ad2..3f2b3005 100644 --- a/fr-IR/SUMMARY.md +++ b/fr-IR/SUMMARY.md @@ -33,7 +33,7 @@ 1. [آشنایی با قانون DRY](thing_30/README.md) 1. [شنایی با مراحل توسعهٔ نرم‌افزار](thing_31/README.md) 1. [به‌کارگیری درست از اصول برنامه‌نویسی شیٔ‌گرا](thing_32/README.md) -1. [](thing_33/README.md) +1. [اعداد اعشاری با خطای محاسباتی در کامپیوتر ذخیره می‌شوند](thing_33/README.md) 1. [جاه طلبی خود را با شرکت در پروژه های متن باز برآروده کنید.](thing_34/README.md) 1. [قانون طلایی طراحی API](thing_35/README.md) 1. [اسطوره ها!](thing_36/README.md) From e36fab4a91e85d92060cebac71a4f872ff096b92 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 14:32:57 +0300 Subject: [PATCH 177/290] Added number 33 --- fr-IR/thing_33/README.md | 23 ++++++++++++++--------- 1 file changed, 14 insertions(+), 9 deletions(-) diff --git a/fr-IR/thing_33/README.md b/fr-IR/thing_33/README.md index 0df4f299..89ede394 100644 --- a/fr-IR/thing_33/README.md +++ b/fr-IR/thing_33/README.md @@ -1,17 +1,22 @@ -# Floating-point Numbers Aren't Real +# اعداد اعشاری با خطای محاسباتی در کامپیوتر ذخیره می‌شوند -Floating-point numbers are not "real numbers" in the mathematical sense, even though they are called *real* in some programming languages, such as Pascal and Fortran. Real numbers have infinite precision and are therefore continuous and non-lossy; floating-point numbers have limited precision, so they are finite, and they resemble "badly-behaved" integers, because they're not evenly spaced throughout their range. +در این بخش می خواهیم در مورد اعداد اعشاری و نحوه ی ذخیره ی آن ها در کامپیوتر صحبت کنیم، بنابراین بهتر است در ابتدا تعریفی از این نوع اعداد با ذکر مثالی داشته باشیم. -To illustrate, assign 2147483647 (the largest signed 32-bit integer) to a 32-bit float variable (x, say), and print it. You'll see 2147483648. Now print `x - 64`. Still 2147483648. Now print `x - 65` and you'll get 2147483520! Why? Because the spacing between adjacent floats in that range is 128, and floating-point operations round to the nearest floating-point number. +یک خط کش ۱۰ سانتی متری را در ذهن خود متصور شوید؛ حال عدد ۳/۶ را روی این خط کش فرضی در نظر بگیرید. این عدد از 3 بزرگتر و از 4 کوچکتر است. برای نشان دادن این که این عدد چقدر از 3 بزرگتر و از 4 کوچکتر است از علامت ممیز یا اعشار / استفاده می کنیم که به طور کلی، به این دست اعداد «اعداد اعشاری» می گوییم. بنابراین می توان گفت که یک عدد اعشاری بین دو عدد صحیح قرار دارد. -IEEE floating-point numbers are fixed-precision numbers based on base-two scientific notation: 1.d1d2...dp-1 × 2e, where *p* is the precision (24 for float, 53 for double). The spacing between two consecutive numbers is 21-p+e, which can be safely approximated by ε|x|, where ε is the *machine epsilon* (21-p). +برای تعریف اعداد صحیح در کامپیوتر از استانداردهای IEEE استفاده می شود. بر اساس این استاندارد برای ذخیره ی هر عدد اعشاری سه فیلد در نظر گرفته می شود: +- اعشار یا مانتیس +- توان +- علامت -Knowing the spacing in the neighborhood of a floating-point number can help you avoid classic numerical blunders. For example, if you're performing an iterative calculation, such as searching for the root of an equation, there's no sense in asking for greater precision than the number system can give in the neighborhood of the answer. Make sure that the tolerance you request is no smaller than the spacing there; otherwise you'll loop forever. +برای مثال، بر طبق این استاندارد داریم: -Since floating-point numbers are approximations of real numbers, there is inevitably a little error present. This error, called *roundoff*, can lead to surprising results. When you subtract nearly equal numbers, for example, the most significant digits cancel each other out, so what was the least significant digit (where the roundoff error resides) gets promoted to the most significant position in the floating-point result, essentially contaminating any further related computations (a phenomenon known as *smearing*). You need to look closely at your algorithms to prevent such *catastrophic cancellation*. To illustrate, consider solving the equation *x2 - 100000x + 1 = 0* with the quadratic formula. Since the operands in the expression *-b + sqrt(b2 - 4)* are nearly equal in magnitude, you can instead compute the root *r1 = -b + sqrt(b2 - 4)*, and then obtain *r2 = 1/r1*, since for any quadratic equation, ax2 + bx + c = 0, the roots satisfy *r1r2 = c/a*. +101 × 2.7495 = 27.495 -Smearing can occur in even more subtle ways. Suppose a library naively computes *ex* by the formula *1 + x + x2/2 + x3/3! + ...*. This works fine for positive *x*, but consider what happens when *x* is a large negative number. The even-powered terms result in large positive numbers, and subtracting the odd-powered magnitudes will not even affect the result. The problem here is that the roundoff in the large, positive terms is in a digit position of much greater significance than the true answer. The answer diverges toward positive infinity! The solution here is also simple: for negative *x*, compute *ex = 1/e|x|*. +که 2.7495 مانتیس، 1 توان و علامت آن نیز مثبت است (البته اعداد در کامپیوتر در پایه ی 2 ذخیره می شوند نه پایه ی 10). -It should go without saying that you shouldn't use floating-point numbers for financial applications — that's what decimal classes in languages like Python and C# are for. Floating-point numbers are intended for efficient scientific computation. But efficiency is worthless without accuracy, so remember the source of rounding errors and code accordingly! +هر پیاده سازی اعداد اعشاری تعداد مشخصی بیت را برای مانتیس در نظر می گیرد، به عبارت دیگر تعداد اعداد قابل ذخیره سازی در کامپیوتر با محدودیت مواجه است. برای مثال برای ذخیره ی اعداد اعشاری در سیستم های ۳۲ بیتی، برای مانتیس ۲۳ بیت در نظر گرفته شده است. این موضوع باعث می شود که نتوانیم اعداد اعشاری که نمایش آن ها دارای تعداد رقم اعشاری متناهی نیست را به طور دقیق در کامپیوتر ذخیره کنیم. -By [Chuck Allison](http://programmer.97things.oreilly.com/wiki/index.php/Chuck_Allison) \ No newline at end of file +برای ذخیره سازی هر عدد بسته به فضای اختصاص داده شده به مانتیس، ابتدا عدد مورد نظر گرد می شود و سپس در کامپیوتر ذخیره می شود؛ به همین دلیل ممکن است نمایش یک عدد اعشاری در کامپیوتر 32 بیتی با کامپیوتر 64 بیتی متفاوت باشد، چرا که فضای اختصاص داده شده به مانتیس در آن ها متفاوت است. + +بنابراین باید توجه داشته باشیم که امکان ذخیره سازی دقیق تمام اعداد حقیقی که بخش اعشاری آن ها دارای تعداد نامتناهی رقم است در کامپیوترها وجود ندارد و به دلیل این نوع ذخیره سازی در زمان کدنویسی و انجام محاسبات روی اعداد صحیح ممکن است با خطای گرد کردن یا Roundoff Error مواجه شویم و جواب های غیر قابل انتظار از محاسبات کامپیوتری دریافت کنیم. بنابراین می توان گفت که بهتر است در برنامه هایی که نیازمند محاسبات دقیق هستند تا حد امکان از اعداد اعشاری استفاده نکنیم. From 7da905079d65d896d67d89fbb2816da7243ce7b6 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 14:34:49 +0300 Subject: [PATCH 178/290] Added number 34 --- fr-IR/thing_34/README.md | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/fr-IR/thing_34/README.md b/fr-IR/thing_34/README.md index c5ebfea0..c3d0db65 100644 --- a/fr-IR/thing_34/README.md +++ b/fr-IR/thing_34/README.md @@ -1,13 +1,17 @@ -# Fulfill Your Ambitions with Open Source +# جاه طلبی خود را با شرکت در پروژه های متن باز برآروده کنید! -Chances are pretty good that you are not developing software at work that fulfills your most ambitious software development daydreams. Perhaps you are developing software for a huge insurance company when you would rather be working at Google, Apple, Microsoft, or your own start-up developing the next big thing. You'll never get where you want to go developing software for systems you don't care about. +اگر شما برنامه نویسی باشید که در یک شرکت آی تی کار می‌کند، به احتمال قریب به یقین هر روز روی پروژه هایی کار می‌کنید که اصلاً جذاب نیستند به طوری که بارها و بارها می بایست یک کار واحد را انجام دهید؛‌ مثلاً بخش لاگین یک سایت را بنویسید و یا سیستم مالی یک نرم‌افزار حسابداری را تکمیل کنید. -Fortunately, there is an answer to your problem: open source. There are thousands of open source projects out there, many of them quite active, which offer you any kind of software development experience you could want. If you love the idea of developing operating systems, go help with one of the dozen operating system projects. If you want to work on music software, animation software, cryptography, robotics, PC games, massive online player games, mobile phones, or whatever, you'll almost certainly find at least one open source project dedicated to that interest. +در چنین شرایطی حس جاه طلبی که یکی از خصیصه های اصلی اکثر توسعه دهندگانی است که دوست دارند کارهای کارهای خارق‌العاده یی انجام دهند تحت هیچ عنوان ارضاء نمی‌شود و نتیجه این که پس از مدتی از کار خود خسته می‌شوند. خبر خوشحال کننده برای این دست توسعه دهندگان این است که می‌توانند شروع به کار روی پروژه های اپن سورس کنند چرا که در چنین شرایطی می‌توانند واقعاً چیزی را که دوست دارند کدنویسی کنند. -Of course there is no free lunch. You have to be willing to give up your free time because you probably cannot work on an open source video game at your day job — you still have a responsibility to your employer. In addition, very few people make money contributing to open source projects — some do but most don't. You should be willing to give up some of your free time (less time playing video games and watching TV won't kill you). The harder you work on an open source project the faster you'll realize your true ambitions as a programmer. It's also important to consider your employee contract — some employers may restrict what you can contribute, even on your own time. In addition, you need to be careful about violating intellectual property laws having to do with copyright, patents, trade marks, and trade secrets. +امروزه به یمن پلتفرم هایی همچون گیت هاب و غیره، هزاران پروژه ی اپن سورس پرطرفدار وجود دارد که بخش قابل توجهی از آن‌ها فعال بوده و توسعه دهندگان بسیاری روی آن‌ها کار می‌کنند. این پروژه های اپن سورس طیف گسترده یی را شامل می شوند؛ از سیستم عامل گرفته تا هوش مصنوعی، ربات ها، یادگیری ماشینی و غیره به طوری که برای هر سلیقه یی، می‌توان یک پروژه ی مناسب یافت! -Open source provides enormous opportunities for the motivated programmer. First, you get to see how someone else would implement a solution that interests you — you can learn a lot by reading other people's source code. Second, you get to contribute your own code and ideas to the project — not every brilliant idea you have will be accepted but some might and you'll learn something new just by working on solutions and contributing code. Third, you'll meet great people with the same passion for the type of software that you have — these open source friendships can last a lifetime. Fourth, assuming you are a competent contributor, you'll be able to add real-world experience in the technology that actually interests you. +چیزی که در زمینه ی پروژه های اپن سورس همواره می بایست مد نظر داشت، این است که کار کردن روی این دست پروژه ها هیچ گونه عایدی برایتان نخواهد داشت؛ لذا اگر به دنبال کسب درآمد از طریق مشارکت در پروژه های اپن سورس هستید، بایستی بگوییم که متأسفانه مسیر نادرستی را انتخاب کرده اید. -Getting started with open source is pretty easy. There is a wealth of documentation out there on the tools you'll need (e.g., source code management, editors, programming languages, build systems, etc.). Find the project you want to work on first and learn about the tools that project uses. The documentation on projects themselves will be light in most cases, but this perhaps matters less because the best way to learn is to investigate the code yourself. If you want to get involved, you could offer to help out with the documentation. Or you could start by volunteering to write test code. While that may not sound exciting, the truth is you learn much faster by writing test code for other people's software than almost any other activity in software. Write test code, really good test code. Find bugs, suggest fixes, make friends, work on software you like, and fulfill your software development ambitions. +گرچه کار کردن روی پروژه های اپن سورس عایدی چندانی به صورت مستقیم برای توسعه دهندگان ندارد، اما خبر خوب این که مشارکت در این پروژه های اپن سورس منجر به تقویت رزومه ی توسعه‌دهنده شده به طوری که در آینده فرصت های شغلی به مراتب بهتری برایش رقم خواهد خورد و زمانی که روی توسعه ی پروژه های اپن سورس صرف کرده است، به شکلی دیگر جبران خواهد شد! -by [Richard Monson-Haefel](http://programmer.97things.oreilly.com/wiki/index.php/Richard_Monson-Haefel) \ No newline at end of file +علاوه بر ارضاء شدن حس درونی توسعه‌دهنده پس از مشارکت در پروژه های اپن سورس، اتفاقات خوبی دیگر نیز در انتظار وی هستند که از آن جمله می‌توان به این نکته اشاره کرد که ما با کار کردن روی پروژه های اپن سورس، با نحوه ی کدنویسی سایر برنامه نویسان سراسر دنیا آشنا شده و خواهیم دید که یک توسعه‌دهنده دیگر، چه راه‌کاری برای مسأله یی یکسان به در نظر گرفته است و همین مسأله می‌تواند به بهبود رویکردمان در برنامه نویسی کمک کند. + +در ضمن، زمانی که ما در یک پروژه ی اپن سورس مشارکت می‌کنیم و بخشی که کدنویسی کرده‌ایم مورد قبول واقع می‌گردد -البته در بسیاری مواقع هم سورس ما صد در صد رد خواهد شد- این مسأله می‌تواند به افزایش اعتماد به نفس ما کمک کند. چه چیزی بهتر از این که در حوزه ی فناوری اطلاعات فرد تأثیر گذاری باشیم و کمک به توسعه ی چیزی کنیم که تا سال‌های سال، چندین هزار نفر کاربر عادی از آن استفاده کرده و لذت ببرند! + +پس به راحتی می‌توانید شروع به کار روی پروژه های اپن سورس کنید، باگ های احتمالی آن‌ها را بیابید، پیشنهاداتی به منظور بهبود عملکرد پروژه بدهید، دوستان اپن سورسی دیگری از سراسر دنیا پیدا کنید، روی نرم‌افزار که دوست دارید کار کنید و در کل، از کاری که می‌کنید لذت ببرید! From 5906fb82dc9c4b832fcf7a65894ca57b00258b03 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 14:35:47 +0300 Subject: [PATCH 179/290] Added number 35 --- fr-IR/thing_35/README.md | 14 ++++---------- 1 file changed, 4 insertions(+), 10 deletions(-) diff --git a/fr-IR/thing_35/README.md b/fr-IR/thing_35/README.md index 5dc245b0..d171ba6b 100644 --- a/fr-IR/thing_35/README.md +++ b/fr-IR/thing_35/README.md @@ -1,13 +1,7 @@ -# The Golden Rule of API Design +# قانون طلایی طراحی API -API design is tough, particularly in the large. If you are designing an API that is going to have hundreds or thousands of users, you have to think about how you might change it in the future and whether your changes might break client code. Beyond that, you have to think about how users of your API affect you. If one of your API classes uses one of its own methods internally, you have to remember that a user could subclass your class and override it, and that could be disastrous. You wouldn't be able to change that method because some of your users have given it a different meaning. Your future internal implementation choices are at the mercy of your users. +به طور کلی، طراحی API کار دشواری است مخصوصاً اگر قصد طراحی برای سیستم‌های بزرگی را داشته باشیم؛ اگر شما قصد طراحی API را در سر می پرورانید که در آینده یی نه چندان دور چندین هزار کاربر از API شما استفاده خواهند کرد، حتماً می‌باید به این موضوع هم فکر کنید که تغییرات احتمالی در آینده چه اتفاقی برای کاربران رقم خواهد زد و اگر یک تغییر کوچک در API خود دادید، کاربران چگونه می‌باید با این تغییر کنار بیایند! -API developers solve this problem in various ways, but the easiest way is to lock down the API. If you are working in Java you might be tempted to make most of your classes and methods final. In C#, you might make your classes and methods sealed. Regardless of the language you are using, you might be tempted to present your API through a singleton or use static factory methods so that you can guard it from people who might override behavior and use your code in ways which may constrain your choices later. This all seems reasonable, but is it really? +علاوه بر این، توجه به این نکته که کاربران API مثلاً چگونه با Override کردن برخی متدهای کلاس‌های API شما، سرویس تان را تحت تأثیر قرار خواهند داد نیز حائز اهمیت است. یکی از استراتژی هایی که توسعه‌دهندگان از آن تبعیت می‌کنند، محدود کردن سطح دسترسی کاربران است؛ به طور مثال، در زبان جاوا بسیاری از متدها را می‌توان final کرد و در زبان سی‌شارپ، می‌توان از کیورد sealed استفاده کرد تا جلوی دستکاری سیستم توسط کاربران را گرفت اما این تمام ماجرا نیست. -Over the past decade, we've gradually realized that unit testing is an extremely important part of practice, but that lesson has not completely permeated the industry. The evidence is all around us. Take an arbitrary untested class that uses a third-party API and try to write unit tests for it. Most of the time, you'll run into trouble. You'll find that the code using the API is stuck to it like glue. There's no way to impersonate the API classes so that you can sense your code's interactions with them, or supply return values for testing. - -Over time, this will get better, but only if we start to see testing as a real use case when we design APIs. Unfortunately, it's a little bit more involved than just testing our code. That's where the **Golden Rule of API Design** fits in: *It's not enough to write tests for an API you develop; you have to write unit tests for code that uses your API. When you do, you learn first-hand the hurdles that your users will have to overcome when they try to test their code independently.* - -There is no one way to make it easy for developers to test code which uses your API. `static`, `final`, and `sealed` are not inherently bad constructs. They can be useful at times. But it is important to be aware of the testing issue and, to do that, you have to experience it yourself. Once you have, you can approach it as you would any other design challenge. - -By [Michael Feathers](http://programmer.97things.oreilly.com/wiki/index.php/Michael_Feathers) \ No newline at end of file +ما با نوشتن Unit Testها، تا حدودی می‌توانیم از صحت عملکرد API خود اطمینان حاصل کنیم اما این کافی نیست! قانون طلایی طراحی ای‌پی‌آی حاکی از آن است که «علاوه بر نوشتن یونیت تست برای ای‌پی‌آی، خود را جای کاربران ای‌پی‌آی گذاشته و اقدام به استفاده ی واقعی از ای‌پی‌آی کنید!» که در چنین شرایطی، خواهید دید که کاربران با چه مشکلاتی دست و پنجه نرم خواهند کرد، مشکلات احتمالی چیست، راه های در رو کدامند و ... From a599882a8f681a1f2a363cc7741a0009f110a76a Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 14:37:01 +0300 Subject: [PATCH 180/290] Added number 36 --- fr-IR/thing_36/README.md | 18 +++++------------- 1 file changed, 5 insertions(+), 13 deletions(-) diff --git a/fr-IR/thing_36/README.md b/fr-IR/thing_36/README.md index dfc8b65e..ef3dc740 100644 --- a/fr-IR/thing_36/README.md +++ b/fr-IR/thing_36/README.md @@ -1,17 +1,9 @@ -# The Guru Myth +# کسی که چند سال است کدنویسی می‌کند، اصلاً علامهٔ دهر نیست! -Anyone who has worked in software long enough has heard questions like this: +افرادی که چند سالی است در حوزه ی توسعه ی اپلیکیشن و برنامه نویسی کار می‌کنند و جزو حرفه یی های این حوزه محسوب می شوند، مسلماً حداقل یک بار با سؤال یا سؤالاتی از این دست رو به رو شده اند که «من فلان مشکل را در سورس کد خود دارم، می دونی مشکل از کجاست و چطور می‌شود آن را رفع کرد؟» -> *I'm getting exception XYZ. Do you know what the problem is?* +کسانی که معمولاً از این دست سؤالات می‌پرسند، اطلاعات چندانی از ارور لاگ ها و یا شرایطی که منجر به ایجاد مشکل مربوطه می‌شوند در اختیار شما نمی‌گذارند؛ ایشان بر این باروند که یک توسعه‌دهنده ی حرفه یی علامه ی دهر است و پاسخ به هر سؤالی را می‌داند و بلد است که چگونه هر باگی را دیباگ کند! -Those asking the question rarely bother to include stack traces, error logs, or any context leading to the problem. They seem to think you operate on a different plane, that solutions appear to you without analysis based on evidence. They think you are a guru. +به طور کلی، چنین رویکردی را به کرات می‌توان در برنامه نویسان مبتدی مشاهده کرد؛ ایشان بر این باورند که منتور ایشان یا برنامه نویس ارشد تیم توسعه ی نرم‌افزار پاسخ به هر سؤالی را باید بداند بدون آن که جزئیاتی دقیق از مشکل مربوطه را در اختیارش قرار دهند. -We expect such questions from those unfamiliar with software: To them systems can seem almost magical. What worries me is seeing this in the software community. Similar questions arise in program design, such as "I'm building inventory management. Should I use optimistic locking?" Ironically, people asking the question are often better equipped to answer it than the question's recipient. The questioners presumably know the context, know the requirements, and can read about the advantages and disadvantages of different strategies. Yet they expect you to give an intelligent answer without context. They expect magic. - -It's time for the software industry to dispel this guru myth. "Gurus" are human. They apply logic and systematically analyze problems like the rest of us. They tap into mental shortcuts and intuition. Consider the best programmer you've ever met: At one point that person knew less about software than you do now. If someone seems like a guru, it's because of years dedicated to learning and refining thought processes. A "guru" is simply a smart person with relentless curiosity. - -Of course, there remains a huge variance in natural aptitude. Many hackers out there are smarter, more knowledgeable, and more productive than I may ever be. Even so, debunking the guru myth has a positive impact. For instance, when working with someone smarter than me I am sure to do the legwork, to provide enough context so that person can efficiently apply his or her skills. Removing the guru myth also means removing a perceived barrier to improvement. Instead of a magical barrier, I see a continuum on which I can advance. - -Finally, one of software's biggest obstacles is smart people who purposefully propagate the guru myth. This might be done out of ego, or as a strategy to increase one's value as perceived by a client or employer. Ironically, this attitude can make smart people less valuable, since they don't contribute to the growth of their peers. We don't need gurus. We need experts willing to develop other experts in their field. There is room for all of us. - -By [Ryan Brush](http://programmer.97things.oreilly.com/wiki/index.php/Ryan_Brush) \ No newline at end of file +در دنیای برنامه نویسی، به کسانی که تجربه ی زیادی در کدنویسی دارند اصطلاحاً Guru گفته می‌شود اما همواره باید این نکته را به خاطر داشته باشیم که Guru ها هم همچون سایر افراد هستند با این تفاوت که به مسائل و مشکلات از زوایای مختلفی نگاه می‌کنند، تفکر الگوریتمیک دارند، کنجکاو هستند و زود دست از تلاش نمی کشند. لذا این دیدگاه که یک برنامه نویس باتجربه می بایست پاسخ به تمامی سوالات را بداند، دیدگاهی کاملا اشتباه است. From 3415c62283f59058eb4ba3b095c12cc5add6a9e8 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 14:37:43 +0300 Subject: [PATCH 181/290] Added number 37 --- fr-IR/thing_37/README.md | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/fr-IR/thing_37/README.md b/fr-IR/thing_37/README.md index 807c85a5..63470543 100644 --- a/fr-IR/thing_37/README.md +++ b/fr-IR/thing_37/README.md @@ -1,13 +1,17 @@ -# Hard Work Does not Pay Off +# کار زیاد ضمانت موفقیت در برنامه‌نویسی نیست! -As a programmer, working hard often does not pay off. You might fool yourself and a few colleagues into believing that you are contributing a lot to a project by spending long hours at the office. But the truth is that by working less you might achieve more — sometimes much more. If you are trying to be focused and 'productive' for more than 30 hours a week you are probably working too hard. You should consider reducing the workload to become more effective and get more done. +به عنوان یک برنامه نویس، دیر یا زود متوجه خواهید شد که گرچه زیاد کار کردن و سخت کوشی شرط لازم برای موفقیت در این حوزه است، اما هرگز شرط کافی نبوده و صرفاً با کار زیاد نمی‌توان به موفقیت‌های چشمگیری در این زمینه دست یافت. -This statement may seem counterintuitive and even controversial, but it is a direct consequence of the fact that programming and software development as a whole involve a continuous learning process. As you work on a project you will understand more of the problem domain and, hopefully, find more effective ways of reaching the goal. To avoid wasted work, you must allow time to observe the effects of what you are doing, reflect over the things that you see, and change your behavior accordingly. +به طور مثال، فرض کنیم که شما و تعدادی از همکارانتان روی پروژه یی در حال کار کردن هستید؛ ماندن زمان های طولانی در آفیس یا شرکت و کد زدن روی پروژه هرگز بدان معنا نیست که شما ارزش بیشتری در این پروژه می آفرینید. گاهی اوقات پیش می‌آید که حتی با کمتر کار کردن، شما می‌توانید ارزش بیشتری برای تیم نرم افزاری خود رقم بزنید. حال ممکن است بپرسید که چطور؟ -Professional programming is usually not like running hard for a few kilometers, where the goal can be seen at the end of a paved road. Most software projects are more like a long orienteering marathon. In the dark. With only a sketchy map as guidance. If you just set off in one direction, running as fast as you can, you might impress some, but you are not likely to succeed. You need to keep a sustainable pace and you need to adjust the course when you learn more about where you are and where you are heading. +برنامه نویسی و به طور کلی توسعه ی نرم‌افزار دربرگیرنده ی یادگیری مداوم است؛ هرچه شما بیشتر روی پروژه یی وقت می‌گذارید، بیشتر با جنبه‌های مختلف پروژه آشنا شده و بالتبع زوایای بیشتری از پروژه را درک کرده که در نهایت می‌توانند منجر به یافتن راه کارهای به مراتب بیشتر و بهینه‌تری گردند. -In addition, you always need to learn more about software development in general and programming techniques in particular. You probably need to read books, go to conferences, communicate with other professionals, experiment with new implementation techniques, and learn about powerful tools that simplify your job. As a professional programmer you must keep yourself updated in your field of expertise — just as brain surgeons and pilots are expected to keep themselves up to date in their own fields of expertise. You need to spend evenings, weekends, and holidays educating yourself, therefore you cannot spend your evenings, weekends, and holidays working overtime on your current project. Do you really expect brain surgeons to perform surgery 60 hours a week, or pilots to fly 60 hours a week? Of course not, preparation and education is an essential part of their profession. +برنامه نویسی حرفه یی همچون دوی سرعت نیست که شما موظف باشید یک مسیر مشخص را در سریع‌ترین زمان ممکن طی کرده تا به انتهای مسیر برسید. بسیاری از پروژه های برنامه نویسی همچون صخره نوردی است؛ به عبارت دیگر، هرگز نمی‌توان این‌گونه تصور کرد که یک مسیر از صخره ها را انتخاب کرده و با بیشترین سرعت ممکن از آن‌ها بالا رفت. پروژه های برنامه نویسی نیاز به تحلیل فرایندها -یا در صخره نوردی تحلیل مسیرهای مختلف و کم خطر- دارند و شما به عنوان یک برنامه نویس حرفه یی می بایست با سرعتی یکنواخت به مسیر خود ادامه داده و هر کجا که احساس کرده‌اید مسیر را اشتباه رفته اید،‌ بازگشته و مسیر به مراتب بهتری اتخاذ نمایید. -Be focused on the project, contribute as much as you can by finding smart solutions, improve your skills, reflect on what you are doing, and adapt your behavior. Avoid embarrassing yourself, and our profession, by behaving like a hamster in a cage spinning the wheel. As a professional programmer you should know that trying to be focused and 'productive' 60 hours a week is not a sensible thing to do. Act like a professional: prepare, effect, observe, reflect, and change. +علاوه بر این، یک برنامه نویس خوب می بایست همواره تشنه ی یادگیری اطلاعات عمومی در زمینه ی توسعه ی نرم‌افزار از یک سو و همچنین یادگیری تکنیک های برنامه نویسی با زبان مد نظر به صورت تخصصی از سوی دیگر باشد. در این راستا، نیاز به مطالعه ی کتب مختلف، شرکت در سمینار/وبینارهیا مربوطه، ارتباط با افراد حرفه یی این حوزه، امتحان کردن ابزارهای جدیدی که به بازار عرضه شده‌اند و … خواهید داشت. -By [Olve Maudal](http://programmer.97things.oreilly.com/wiki/index.php/Olve_Maudal) \ No newline at end of file +به عنوان یک برنامه نویس حرفه یی، همان‌طور که مثلاً پزشکان خود را آپدیت نگاه می‌دارند تا بتوانند جان بیماران خود را نجات دهند، نیاز دارید تا آپدیت باشید و همواره از آخرین دستاوردهای حوزه ی کاری خود مطلع بوده و آن‌ها را به خدمت گیرید. + +به جای این که در زمان استراحت خود -بعد از ظهرها، آخر هفته‌ها و در تعطیلات- کماکان روی پروژه یی که در دست دارید کد بزنید، این زمان گرانبها را به مطالعه در حوزه ی کاری خود اختصاص دهید و پس از مدت زمانی -مثلا ۶ ماه- تفاوت چشمگیری در توانمندی‌های خود مشاهده خواهید کرد. + + From 95edbe9c9ca2352a3dc00c877ba57671d24ae59e Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 14:39:27 +0300 Subject: [PATCH 182/290] Added number 38 --- fr-IR/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fr-IR/SUMMARY.md b/fr-IR/SUMMARY.md index 3f2b3005..1f642f98 100644 --- a/fr-IR/SUMMARY.md +++ b/fr-IR/SUMMARY.md @@ -38,7 +38,7 @@ 1. [قانون طلایی طراحی API](thing_35/README.md) 1. [اسطوره ها!](thing_36/README.md) 1. [کار سخت نتیجه همیشه بهترین نتیجه را نمی دهد](thing_37/README.md) -1. [چگونه از ابزارهای اشکال زدایی استفاده کنیم؟](thing_38/README.md) +1. [چگونه به یک باگ نگاه کنیم؟](thing_38/README.md) 1. [کد را با حذف آن بهبود دهید!](thing_39/README.md) 1. [من را نصب کن](thing_40/README.md) 1. [تعداد بالای فرآیندهای داخلی برنامه قطعاً روی کارایی برنامه تاثیر خواهند داشت](thing_41/README.md) From d27019a612e198beb794a38c2d27f40b23bde641 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 14:39:49 +0300 Subject: [PATCH 183/290] Added number 38 --- fr-IR/thing_38/README.md | 27 +++++++-------------------- 1 file changed, 7 insertions(+), 20 deletions(-) diff --git a/fr-IR/thing_38/README.md b/fr-IR/thing_38/README.md index 9fc14259..27ebc7e4 100644 --- a/fr-IR/thing_38/README.md +++ b/fr-IR/thing_38/README.md @@ -1,23 +1,10 @@ -# How to Use a Bug Tracker +# چگونه به یک باگ نگاه کنیم؟ -Whether you call them *bugs*, *defects*, or even *design side effects*, there is no getting away from them. Knowing how to submit a good bug report and also what to look for in one are key skills for keeping a project moving along nicely. +برخی توسعه دهندگان برچسب «باگ» روی مسائل خارج از عرف نرم افزاری می‌گذارند و برخی دیگر صرفاً به «مشکل» اکتفا می‌کنند؛ خواه این مسائل را باگ بنامییم خواه مشکل، آن‌ها وجود دارند و به راحتی می‌توانند موفقیت نرم‌افزار ما را تحت الشعاع قرار دهند و یکی از مهارت های اصلی هر توسعه‌دهنده ی حرفه یی، این می‌تواند باشد که چگونه باگ های یک نرم‌افزار را رصد کند و تمام تلاش خود را به کار گیرد تا آن‌ها را مرتفع سازد. -A good bug report needs three things: +برای رفع باگ ها، ما پیش از هر چیز به یک ‌Bug Report (باگ ریپورت) نیاز داریم تا بیش از پیش، با خصوصیات باگ احتمالی آشنا شده و دیگر اعضای تیم را نیز در جریان قرار دهیم؛ یک باگ ریپورت خوب از ویژگی‌های زیر برخوردار است: +- نحوه ی کار با نرم‌افزار به گونه یی که منجر به مشاهده ی باگ شود را ارائه می‌دهد؛ علاوه بر این، به ما می‌گوید که این باگ هر چند وقت یک بار پدید می‌آید. +- به نظر شما چه اتفاقی باید افتاده باشد که این باگ ایجاد شده؟ +- گزارشی کامل از اتفاقاتی که رخ داده‌اند به منظور درک بهتر ماهیت باگ و در صورت امکان، ارائه ی دلیل اصلی پدید آمدن باگ -- How to reproduce the bug, as precisely as possible, and how often this will make the bug appear. -- What should have happened, at least in your opinion. -- What actually happened, or at least as much information as you have recorded. - -The amount and quality of information reported in a bug says as much about the reporter as it does about the bug. Angry, terse bugs ("This function sucks!") tell the developers that you were having a bad time, but not much else. A bug with plenty of context to make it easier to reproduce earns the respect of everyone, even if it stops a release. - -Bugs are like a conversation, with all the history right there in front of everyone. Don't blame others or deny the bug's very existence. Instead ask for more information or consider what you could have missed. - -Changing the status of a bug, e.g., *Open* to *Closed*, is a public statement of what you think of the bug. Taking the time to explain why you think the bug should be closed will save tedious hours later on justifying it to frustrated managers and customers. Changing the priority of a bug is a similar public statement, and just because it's trivial to you doesn't mean it isn't stopping someone else from using the product. - -Don't overload a bug's fields for your own purposes. Adding "VITAL:" to a bug's subject field may make it easier for you to sort the results of some report, but it will eventually be copied by others and inevitably mistyped, or will need to be removed for use in some other report. Use a new value or a new field instead, and document how the field is supposed to be used so other people don't have to repeat themselves. - -Make sure that everyone knows how to find the bugs that the team is supposed to be working on. This can usually be done using a public query with an obvious name. Make sure everyone is using the same query, and don't update this query without first informing the team that you're changing what everyone is working on. - -Finally, remember that a bug is not a standard unit of work any more than a line of code is a precise measurement of effort. - -By [Matt Doar](http://programmer.97things.oreilly.com/wiki/index.php/Matt_Doar) \ No newline at end of file +کمیت و کیفیت اطلاعاتی که ما از یک باگ پیدا می‌کنیم دارای ارتباطی مستقیم با فرایند Debugging (دیباگینگ یا رفع مشکل) است. به یاد داشته باشیم زمانی که با یک باگ در نرم‌افزار خود مواجه می‌شویم، تحت هیچ عنوان دست به انکار آن نزده و یا مشکل بوجود آمده را به گردن سایر اعضای تیم نیندازید! بلکه تا حد ممکن اطلاعات مرتبط در مورد باگ مربوطه کسب نمایید و در صدد رفع آن برآیید. From a29f6b32e06944690865d80533361986aecea3f6 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 14:41:04 +0300 Subject: [PATCH 184/290] Added number 39 --- fr-IR/thing_39/README.md | 25 ++++--------------------- 1 file changed, 4 insertions(+), 21 deletions(-) diff --git a/fr-IR/thing_39/README.md b/fr-IR/thing_39/README.md index 49052b81..956d0d24 100644 --- a/fr-IR/thing_39/README.md +++ b/fr-IR/thing_39/README.md @@ -1,24 +1,7 @@ -# Improve Code by Removing It +# با حذف کدهای اضافی، سورس‌کد خود را بهبود بخشید -*Less* is more. It's a quite trite little maxim, but sometimes it really is true. +آمریکایی ها شعاری دارند تحت عنوان Less Is More با این مضمون که «هرچه کمتر، بهتر!» و شاید بتوان گفت که این جمله خیلی کلیشه یی است و ممکن است در بسیاری مواقع کاربرد نداشته باشد، اما حداقل در کدنویسی کاربرد دارد به این شکل که با حذف کلاس‌ها، فانکشن ها و بلوک های کد اضافی از سورس کد خود، در نهایت سورس کد به مراتب بهتر و تمیزتری در اختیار خواهید داشت. -One of the improvements I've made to our codebase over the last few weeks is to remove chunks of it. +گاهی اوقات در حین کدنویسی فکر می‌کنیم که یکسری کارها به بهبود نرم‌افزار ما منجر خواهند شد اما در نهایت کاشف به عمل می‌آید که در حین اجرا، باعث کاهش راندمان نرم‌افزار می‌شوند و تنها در صورت حذف آن‌ها است که بهبودی حاصل می‌شود. در کدنویسی همواره می بایست این نکته را به خاطر داشته باشیم که باید کدی بنویسیم که «ارزشی برای نرم‌افزار ما بیاورد نه این که صرفاً از نوشتن آن لذت ببریم». -We'd written the software following XP tenets, including YAGNI (that is, You Aren't Gonna Need It). Human nature being what it is, we inevitably fell short in a few places. - -I observed that the product was taking too long to execute certain tasks — simple tasks that should have been near instantaneous. This was because they were overimplemented; festooned with extra bells and whistles that were not required, but at the time had seemed like a good idea. - -So I've simplified the code, improved the product performance, and reduced the level of global code entropy simply by removing the offending features from the codebase. Helpfully, my unit tests tell me that I haven't broken anything else during the operation. - -A simple and thoroughly satisfying experience. - -So why did the unnecessary code end up there in the first place? Why did one programmer feel the need to write extra code, and how did it get past review or the pairing process? Almost certainly something like: - -- It was a fun bit of extra stuff, and the programmer wanted to write it. *(Hint: Write code because it adds value, not because it amuses you.)* -- Someone thought that it might be needed in the future, so felt it was best to code it now. *(Hint: That isn't YAGNI. If you don't need it right now, don't write it right now.)* -- It didn't appear to be that big an "extra," so it was easier to implement it rather than go back to the customer to see whether it was really required. *(Hint: It always takes longer to write and to maintain extra code. And the customer is actually quite approachable. A small extra bit of code snowballs over time into a large piece of work that needs maintenance.)* -- The programmer invented extra requirements that were neither documented nor discussed that justified the extra feature. The requirement was actually bogus. *(Hint: Programmers do not set system requirements; the customer does.)* - -What are you working on right now? Is it all needed? - -By [Pete Goodliffe](http://programmer.97things.oreilly.com/wiki/index.php/Pete_Goodliffe) +گاهی اوقات هم در تحلیل نرم‌افزار و مراحل اولیه ی کدنویسی، فکر می‌کنیم که یک قابلیت ممکن است در آینده به کارمان آید، لذا با خود فکر می‌کنیم که زمان زیادی از ما نمی‌برد و آن را در سورس کد خود می گنجانیم اما همواره به یاد داشته باشیم که اگر به قابلیتی در حال حاضر نیاز نداریم، نیاز به نوشتن آن نیست! From 4e40cff93cacd133a1ddcf00ce73175f42eea3a1 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 14:41:40 +0300 Subject: [PATCH 185/290] Added number 40 --- fr-IR/thing_40/README.md | 25 ++++++------------------- 1 file changed, 6 insertions(+), 19 deletions(-) diff --git a/fr-IR/thing_40/README.md b/fr-IR/thing_40/README.md index a2ebdc01..bba45ec0 100644 --- a/fr-IR/thing_40/README.md +++ b/fr-IR/thing_40/README.md @@ -1,24 +1,11 @@ -# Install Me +# برنامه‌هایی که می‌نویسید را کاربرپسند کنید -I am not the slightest bit interested in your program. +اگر به فولدر Downloads سیستم خود نگاهی بیندازید، و ببینید که پر است از فایل‌های zip و exe که شاید حتی یک بار هم آن‌ها را استفاده نکرده باشید! شما جزو آن دسته از کاربرانی هستید که علاقمند به جمع آوری هرگونه نرم افزاری -از نرم افزاری های گرافیکی گرفته تا هک و غیره- هستید. -I am surrounded by problems and have a to-do list as long as my arm. The only reason I am at your website right now is because I have heard an unlikely rumor that every one my problems will be eliminated by your software. You'll forgive me if I'm skeptical. +در نقطه ی مقابل این دست کاربران، کاربرانی هستند که خیلی وسواسی هستند و دوست دارند که سیستم خود را تا حد ممکن تمیز نگاه دارند و صرفاً نرم افزارهایی را روی آن نصب کنند که به آن ها نیاز دارند. این دست کاربران خیلی برایشان مهم است نرم افزاری که Install می‌کنند، قابلیت Uninstall شدن داشته باشد؛ لذا اگر برنامه یی نوشته‌اید که نمی‌توان را آن را حذف نمود و یا اگر می‌شود، به سختی این کار صورت می‌گیرد، به طور حتم نظر مساعد این دست از کاربران را از دست خواهید داد. -If eyeball tracking studies are correct, I've already read the title and I'm scanning for blue underlined text marked *download now*. As an aside, if I arrived at this page with a Linux browser from a UK IP, chances are I would like the Linux version from a European mirror, so please don't ask. Assuming the file dialog opens straight away, I consign the thing to my download folder and carry on reading. +اگر برنامه یی که نوشته‌اید که Graphical User Interface (یا به اختصار GUI به معنی رابط کاربری گرافیکی) دارد، تا حد ممکن مراحل انجام کار را ساده نگاه دارید و همچون نرم افزارهای شرکت ادوبی، از منوهای تو در تو و گاها گیج‌کننده استفاده نکنید. -We all constantly perform cost-benefit analysis of everything we do. If your project drops below my threshold for even a second, I will ditch it and go onto something else. Instant gratification is best. +اگر یک لایبرری نوشته اید، بهتر است که در سایت مربوطه یا صفحه ی گیت هاب لایبرری خود، راهنمایی خلاصه و مفید از نحوه ی کارکرد لایبرری خود در نظر بگیرید. نیاز به توضیح نیست که لایبرری های رغیب همیشه ادعا می‌کنند به بهینه‌تر هستند، راحت‌تر هستند، سبک‌تر هستند و بسیار مزیت دیگر؛ لذا اگر به هر دلیلی در چند دقیقه ی اول نتوانید مشتری بالقوه ی خود را به مشتری بالفعل درآورید، این رقبای شما هستند که برنده ی بازی خواهند بود. -The first hurdle is *install*. Don't think that's much of a problem? Go to your download folder now and have a look around. Full of *tar* and *zip* files right? What percentage of those have you unpacked? How many have you installed? If you are like me, only a third are doing little more than acting as hard drive filler. - -I may want doorstep convenience, but I don't want you entering my house uninvited. Before typing install I would like to know exactly where you are putting stuff. It's my computer and I like to keep it tidy when I can. I also want to be able to remove your program the instant I am disenchanted with it. If I suspect that's impossible I won't install it in the first place. My machine is stable right now and I want to keep it that way. - -If your program is GUI based then I want to do something simple and see a result. Wizards don't help, because they do stuff that I don't understand. Chances are I want to read a file, or write one. I don't want to create projects, import directories, or tell you my email address. If all is working, on to the tutorial. - -If your software is a library, then I carry on reading your web page looking for a *quick start guide*. I want the equivalent of "Hello world" in a five-line no-brainer with exactly the output described by your website. No big XML files or templates to fill out, just a single script. Remember, I have also downloaded your rival's framework. You know, the one who always claims to be so much better than yours in the forums? If all is working, onto the tutorial. - -There is a tutorial isn't there? One that talks to me in language I can understand? - -And if the tutorial mentions my problem, I'll cheer up. Now I'm reading about the things I can do it starts to get interesting, fun even. I'll lean back and sip my tea — did I mention I was from the UK? — and I'll play with your examples and learn to use your creation. If it solves my problem, I'll send you a thank-you email. I'll send you bug reports when it crashes, and suggestions for features too. I'll even tell all my friends how your software is the best, even though I never did try your rival's. And all because you took such care over my first tentative steps. -How could I ever have doubted you? - -By [Marcus Baker](http://programmer.97things.oreilly.com/wiki/index.php/Marcus_Baker) \ No newline at end of file +به طور کلی، شما به عنوان یک توسعه‌دهنده ی نرم‌افزار -خواه یک پروژه ی اپن سورس برای تفنن بنویسید و خواه پروژه ی بزرگ یک مشتری را کدنویسی کنید- می بایست این نکته را مد نظر داشته باشید که کاربران نرم افزاری بسیار بی‌وفا هستند و به محض آن که نرم افزاری بیابند که از نرم‌افزار شما ارزان‌تر، کاربرپسندتر، بهینه‌تر و در کل اثربخش تر باشد، به سمت رقبای شما خواهند رفت؛ لذا وقتی کدنویسی می‌کنید، به نیازهای پایه یی کاربران -که اغلب اوقات آنقدر بدیهی هستند که از قلم می‌افتند- تمام توجه خود را به کار گیرید. From 66581151a84c6ef2286d004eb4011c3f5b2c62bf Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 14:42:27 +0300 Subject: [PATCH 186/290] Added number 41 --- fr-IR/thing_41/README.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/fr-IR/thing_41/README.md b/fr-IR/thing_41/README.md index 66879100..2fffa637 100644 --- a/fr-IR/thing_41/README.md +++ b/fr-IR/thing_41/README.md @@ -1,13 +1,13 @@ -# Inter-Process Communication Affects Application Response Time +# فرایندهای برون برنامه‌ای، زمان پاسخگویی نرم‌افزار را تحت‌الشعاع خود قرار می‌دهند -Response time is critical to software usability. Few things are as frustrating as waiting for some software system to respond, especially when our interaction with the software involves repeated cycles of stimulus and response. We feel as if the software is wasting our time and affecting our productivity. However, the causes of poor response time are less well appreciated, especially in modern applications. Much performance management literature still focuses on data structures and algorithms, issues that can make a difference in some cases but are far less likely to dominate performance in modern multi-tier enterprise applications. +یکی از چیزهایی که در ارزیابی کیفیت یک نرم‌افزار مورد توجه قرار می‌گیرد، Response Time (ریسپانس تایم یا زمان پاسخگویی) نرم‌افزار است. این نرم‌افزار می‌تواند یک وب سایت آنلاین باشد و یا یک نرم‌افزار حسابداری که روی سیستم خود نصب می‌کنیم؛ هرچه که باشد، اگر نوع کاربری نرم‌افزار به گونه یی باشد که کاربران نیاز به تعامل مکرر با سیستم داشته باشد، ریسپانس تایم نقش تعیین کننده در تجربه ی کاربری نرم‌افزار ایفا می‌کند به طوری که اگر کاربری کاری را انجام دهد و چند ثانیه منتظر بماند تا سیستم پاسخ وی را بدهد، این حس به کاربر نرم افزارمان دست که می‌دهد که وقت اش تلف می‌شود. -When performance is a problem in such applications, my experience has been that examining data structures and algorithms isn't the right place to look for improvements. Response time depends most strongly on the number of remote inter-process communications (IPCs) conducted in response to a stimulus. While there can be other local bottlenecks, the number of remote inter-process communications usually dominates. Each remote inter-process communication contributes some non-negligible latency to the overall response time, and these individual contributions add up, especially when they are incurred in sequence. +ریسپانس تایم یکی از چیزهایی است که در فرایند تحلیل نرم افزار، طراحی پایگاه داده و همچنین الگوریتم های به کار گرفته شده در سیستم می بایست مد نظر قرار داده شود؛ علاوه بر این موارد، نکته ی دیگری هم وجود دارد که در زیاد شدن ریسپانس تایم دخیل است و آن هم چیزی نیست جز برقراری ارتباط با سایر نرم‌افزارها همچون وب سرویس ها و … -A prime example is *ripple loading* in an application using object–relational mapping. Ripple loading describes the sequential execution of many database calls to select the data needed for building a graph of objects (see [Lazy Load](http://martinfowler.com/eaaCatalog/lazyLoad.html) in Martin Fowler's *Patterns of Enterprise Application Architecture*). When the database client is a middle-tier application server rendering a web page, these database calls are usually executed sequentially in a single thread. Their individual latencies accumulate, contributing to the overall response time. Even if each database call takes only 10ms, a page requiring 1000 calls (which is not uncommon) will exhibit at least a 10-second response time. Other examples include web-service invocation, HTTP requests from a web browser, distributed object invocation, request–reply messaging, and data-grid interaction over custom network protocols. The more remote IPCs needed to respond to a stimulus, the greater the response time will be. +فرض کنیم که نرم افزاری نوشته‌ایم که قیمت روز خودرو را از یک API گرفته و در دسترس ما قرار می‌دهد؛ زمانی که کاربر مثلاً روی دکمه ی خودروهای داخلی کلیک می‌کنید، یک ریکوئست برای API مد نظر ارسال می‌شود تا قیمت خودروها را از دیتابیس سرویس مربوطه گرفته و در قالب یک ریسپانس -که معمولاً در فرمت جیسون است- در اختیار ما قرار می‌دهد. حال اگر این API هرگونه تاخیری در گرفتن دیتای مد نظر داشته باشد، این تأخیر به حساب نرم‌افزار ما نوشته شده و ریسپانس تایم آن را افزایش می‌دهد که در نهایت منجر به ایجاد یک تجربه ی کاربری نامطلوب برای کاربرانمان می‌شود. -There are a few relatively obvious and well-known strategies for reducing the number of remote inter-process communications per stimulus. One strategy is to apply the principle of parsimony, optimizing the interface between processes so that exactly the right data for the purpose at hand is exchanged with the minimum amount of interaction. Another strategy is to parallelize the inter-process communications where possible, so that the overall response time becomes driven mainly by the longest-latency IPC. A third strategy is to cache the results of previous IPCs, so that future IPCs may be avoided by hitting local cache instead. +برای رفع این مشکل، راه کارهای متعددی را می‌توان اتخاد نمود؛ به عنوان مثال، می‌توان تعامل نرم‌افزار خود با مثلاً وب سرویس مربوطه را به حداقل رساند و در هر بار ریکوئست فرستادن، کمترین دیتای ممکن را درخواست کرد. -When you're designing an application, be mindful of the number of inter-process communications in response to each stimulus. When analyzing applications that suffer from poor performance, I have often found IPC-to-stimulus ratios of thousands-to-one. Reducing this ratio, whether by caching or parallelizing or some other technique, will pay off much more than changing data structure choice or tweaking a sorting algorithm. +راه‌کار دیگری که می‌توان به کار برد این است که داده‌هایی که قبلاً به دست آمده را Cache کرد، بنابراین کاربران جدیدی که ریکوئست مشابهی ارسال می‌کنند، پاسخ خود را خیلی سریع از روی کش سیستم دریافت می‌کنند. -By [Randy Stafford](http://programmer.97things.oreilly.com/wiki/index.php/Randy_Stafford) \ No newline at end of file +به طور کلی، ریسپانس تایم نقش تعیین کننده یی در موفقیت نرم افزارهایی که می نویسیم دارد و باید تمام تلاش خود را به کار بندیم تا آن را پایین نگاه داریم. From 54cd9afb8791550d5d67530899d5d34de1310661 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 14:43:37 +0300 Subject: [PATCH 187/290] Added number 42 --- fr-IR/thing_42/README.md | 16 +++++++--------- 1 file changed, 7 insertions(+), 9 deletions(-) diff --git a/fr-IR/thing_42/README.md b/fr-IR/thing_42/README.md index 7e535b4d..3d761679 100644 --- a/fr-IR/thing_42/README.md +++ b/fr-IR/thing_42/README.md @@ -1,15 +1,13 @@ -# Keep the Build Clean +# بیلد (Build) اصولی ارائه کنید -Have you ever looked at a list of compiler warnings the length of an essay on bad coding and thought to yourself: "You know, I really should do something about that... but I don't have time just now?" On the other hand, have you ever looked at a lone warning that just appeared in a compilation and just fixed it? +در فرایند کدنویسی گاهی اوقات برایمان پیش می‌آید که با لیست بلند بالایی از ارورها در حین اجرای نرم‌افزار مواجه می‌شویم و این در حالی است که با خود می‌گوییم «ان شاء الله اگر فرصتی شد، همه ی ارورها را بعداً رفع خواهم کرد!» -When I start a new project from scratch, there are no warnings, no clutter, no problems. But as the code base grows, if I don't pay attention, the clutter, the cruft, the warnings, and the problems can start piling up. When there's a lot of noise, it's much harder to find the warning that I really want to read among the hundreds of warnings I don't care about. +زمانی که ما یک پروژه ی جدید را از پایه شروع به کدنویسی می‌کنیم، نه مشکلی وجود دارد و نه اروری اما همین که سورس کد ما به مرور زمان حجیم و حجیم تر می‌شود، احتمال این که ارورها، هشدارها و اکسپشن ها زیاد شوند هم بالا می‌رود و این در صورتی که اگر این ارورها را به‌ موقع رفع نکنیم، در آینده رفع کرد یک هشدار کوچک می‌تواند به دردسری بزرگ مبدل گردد! -To make warnings useful again, I try to use a zero-tolerance policy for warnings from the build. Even if the warning isn't important, I deal with it. If not critical, but still relevant, I fix it. If the compiler warns about a potential null-pointer exception, I fix the cause — even if I "know" the problem will never show up in production. If the embedded documentation (Javadoc or similar) refers to parameters that have been removed or renamed, I clean up the documentation. +یکی از استراتژی های خوب در حین کدنویسی، به کارگیری سیاست Zero-tolerance Policy است؛ در‌ واقع این سیاست حاکی از آن است که IDE و محیط توسعه ی نرم افزار خود را به گونه یی تنظیم کنیم که هرگونه هشدار، خطا و اروری را به ما گوشزد کند حتی اگر خیلی کوچک و در ظاهر بی اهمیت باشند. -If it's something I really don't care about and that really doesn't matter, I ask the team if we can change our warning policy. For example, I find that documenting the parameters and return value of a method in many cases doesn't add any value, so it shouldn't be a warning if they are missing. Or, upgrading to a new version of the programming language may make code that was previously OK now emit warnings. For example, when Java 5 introduced generics, all the old code that didn't specify the generic type parameter would give a warning. This is a sort of warning I don't want to be nagged about (at least, not yet). Having a set of warnings that are out of step with reality does not serve anyone. +برای درک بهتر این موضوع، مثالی از دنیای واقعی می‌زنیم؛ واژه ی «درد» معانی و تعاریف مختلفی می‌تواند داشته باشد. به طور مثال، اگر بخواهیم درد را تعریف کنیم، می‌توانیم از آن به عنوان یک «مکانیسم اطلاع رسانی» یاد کنیم. اگر درد وجود نداشت، ما به سادگی گرمای بیش از حد را نمی توانستیم حس کنیم و بالتبع از آن دوری کنیم و ممکن بود صدمات جبران ناپذیری به بدن خود وارد کنیم. -By making sure that the build is always clean, I will not have to decide that a warning is irrelevant every time I encounter it. Ignoring things is mental work, and I need to get rid of all the unnecessary mental work I can. Having a clean build also makes it easier for someone else to take over my work. If I leave the warnings, someone else will have to wade through what is relevant and what is not. Or more likely, just ignore all the warnings, including the significant ones. +در کدنویسی هم قضیه دقیقاً به همین شکل است؛ وجود ارورها، هشدارها و اکسپشن ها اصلاً چیز بدی نیستند چرا که همین هشدارها هستند که ما را از وجود باگی در سورس کد خود مطلع می‌کنند و باید قدر آن‌ها را دانست. در چنین شرایطی است که وقتی ما نرم افزار خود را Build می کنیم، نسخه ی بیلد شده ی سورس کد ما اصولی است و سایر توسعه دهندگانی که با آن‌ها روی یک پروژه کار می‌کنیم تا حد ممکن کمتر سردرگم خواهند شد. -Warnings from your build are useful. You just need to get rid of the noise to start noticing them. Don't wait for a big clean-up. When something appears that you don't want to see, deal with it right away. Either fix the source of the warning, suppress this warning or fix the warning policies of your tool. Keeping the build clean is not just about keeping it free of compilation errors or test failures: Warnings are also an important and critical part of code hygiene. - -By [Johannes Brodwall](http://programmer.97things.oreilly.com/wiki/index.php/Johannes_Brodwall) \ No newline at end of file +نکته به طور کلی، در شاخه ی برنامه نویسی و توسعه ی نرم‌افزار، Build به فرایندی گفته می‌شود که در آن سورس کد به برنامه یی قابل اجرا و قابل استفاده مبدل می‌گردد که معمولاً با یک شناسه -مثلا ۱۷- شناخته می‌شود که قبل از انتشار نهایی نرم‌افزار و در فرایند تست نرم افزار ایجاد می‌گردد. یکی از فرایندهای مهم در بیلد کردن، کامپایل کردن سورس کد است که در این فرایند سورس کد نرم‌افزار به کدهای قابل اجرا توسط ماشین تبدیل می‌شوند. From 4d7795cc4ff2e495580aeca78084f595604a0d97 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 14:44:10 +0300 Subject: [PATCH 188/290] Added number 43 --- fr-IR/thing_43/README.md | 21 ++++++++++++++------- 1 file changed, 14 insertions(+), 7 deletions(-) diff --git a/fr-IR/thing_43/README.md b/fr-IR/thing_43/README.md index 8abd0245..16a02c2d 100644 --- a/fr-IR/thing_43/README.md +++ b/fr-IR/thing_43/README.md @@ -1,13 +1,20 @@ -# Know How to Use Command-line Tools +# استفادهٔ بهینه از ابزارهای کامندلاینی -Today, many software development tools are packaged in the form of Integrated Development Environments (IDEs). Microsoft's Visual Studio and the open-source Eclipse are two popular examples, though there are many others. There is a lot to like about IDEs. Not only are they easy to use, they also relieve the programmer of thinking about a lot of little details involving the build process. +امروزه بسیاری از ابزارهای توسعه ی نرم‌افزار در IDE ها به صورت پیکج های از پیش نصب شده در اختیار توسعه‌دهندگان قرار می‌گیرند و همین مسئله منجر به محبوبیت بیش از پیش IDE در مقایسه با ادیتورهای کد در میان توسعه‌دهندگان می‌شود چرا که نه تنها کدنویسی با این محیط‌های توسعه راحت تر است، بلکه برنامه‌نویس دیگر نیازی نخواهد داشت تا به یک سری جزئیات همچون فرایند کامپایل کردن و … فکر کند. -Ease of use, however, has its downside. Typically, when a tool is easy to use, it's because the tool is making decisions for you and doing a lot of things automatically, behind the scenes. Thus, if an IDE is the only programming environment that you ever use, you may never fully understand what your tools are actually doing. You click a button, some magic occurs, and an executable file appears in the project folder. +به خاطر داشته باشید IDE مخفف واژگان Integrated Development Environment به معنی «محیط توسعه ی یکپارچه ی نرم‌افزار» است که از مهم‌ترین آن‌ها می‌توان به ویژوال استودیو، اکلیپس و نت بینز اشاره کرد. +سهولت در استفاده از IDE ها گرچه به عنوان یکی از نقاط قوت این دست نرم‌افزارها محسوب می‌گردد، اما IDE ها عاری از هر گونه عیبی هم نیستند! زمانی که ما می‌گوییم استفاده از یک نرم‌افزار بسیار سهل و آسان است، این بدان معنا است که نرم‌افزار بسیاری از کارها را به صورت خودکار انجام می‌دهد؛ به عبارت دیگر، بسیاری از تصمیماتی که بر عهده ی توسعه‌دهنده هستند را خود نرم‌افزار می‌گیرد و به همین دلیل هم هست که توسعه‌دهندگان ی که صد در صد وابسته به IDE انتخابی خود هستند -خواه ویژوال استودیوی مایکروسافت یا گزینه‌های اپن‌سورسی همچون اکلیپس- در یک سری از مواقع اصلاً متوجه نمی‌شوند که سورس‌کد ایشان چگونه بیلد می‌شود و ابزارهای مختلف دقیقاً چه کاری انجام می‌دهند (به طور مثال، شما یک دکمه را در اندروید استودیو می‌زنید و خروجی apk حاضر و آماده در اختیار شما قرار می‌گیرد.) -By working with command-line build tools, you will learn a lot more about what the tools are doing when your project is being built. Writing your own make files will help you to understand all of the steps (compiling, assembling, linking, etc.) that go into building an executable file. Experimenting with the many command-line options for these tools is a valuable educational experience as well. To get started with using command-line build tools, you can use open-source command-line tools such as GCC or you can use the ones supplied with your proprietary IDE. After all, a well-designed IDE is just a graphical front-end to a set of command-line tools. +در نقطه ی مقابل توسعه‌دهندگان ی که کاملاً وابسته به IDE ها هستند، برنامه‌نویسانی قرار دارند که از ابزارهای کامند لاینی استفاده می‌کنند؛ این دست برنامه‌نویسان زمانی که یک برنامه را بیلد می‌کنند -البته با استفاده از ابزارهای کامند لاین- دقیقاً می‌توانند متوجه شوند که پشت پرده چه اتفاقاتی رخ می‌دهد. -In addition to improving your understanding of the build process, there are some tasks that can be performed more easily or more efficiently with command-line tools than with an IDE. For example, the search and replace capabilities provided by the *grep* and *sed* utilities are often more powerful than those found in IDEs. Command-line tools inherently support scripting, which allows for the automation of tasks such as producing scheduled daily builds, creating multiple versions of a project, and running test suites. In an IDE, this kind of automation may be more difficult (if not impossible) to do as build options are usually specified using GUI dialog boxes and the build process is invoked with a mouse click. If you never step outside of the IDE, you may not even realize that these kinds of automated tasks are possible. +برای شروع کار با ابزارهای بیلد کردن کامند لاین، می‌توان از نمونه‌های اپن‌سورسی همچون GCC شروع کرد. زمانی که شما شخصاً اقدام به کامپایل کردن، اسمبل کردن و لینک کردن سورس‌کد خود می‌کنید و در نهایت یک بیلد نهایی به دست می آورید، کاملاً با فرایند های توسعه ی نرم‌افزار آشنا خواهید شد و از آن پس، یک IDE برایتان صرفاً نرم‌افزاری گرافیکی است که یک سری ابزارهای کامند لاینی را در خود جای داده است. -But wait. Doesn't the IDE exist to make development easier, and to improve the programmer's productivity? Well, yes. The suggestion presented here is not that you should stop using IDEs. The suggestion is that you should "look under the hood" and understand what your IDE is doing for you. The best way to do that is to learn to use command-line tools. Then, when you go back to using your IDE, you'll have a much better understanding of what it is doing for you and how you can control the build process. On the other hand, once you master the use of command-line tools and experience the power and flexibility that they offer, you may find that you prefer the command line over the IDE. +علاوه بر این که پس از استفاده از ابزارهای کامند لاین برای بیلد کردن سورس‌کد خود به ماهیت فرایندها پی می برید، یک سری کارهای دیگری نیز می‌توانید انجام دهید که در مقایسه با IDE ها از سهولت و اثربخشی بیشتری برخوردارند؛ برای مثال، ابزارهای جستجو و جایگزین کردنی همچون grep و sed گاهی اوقات از گزینه‌هایی که در نرم‌افزارهای گرافیکی در اختیار توسعه‌دهندگان قرار می‌گیرد اثربخش تر هستند. -By [Carroll Robinson](http://programmer.97things.oreilly.com/wiki/index.php/Carroll_Robinson) \ No newline at end of file +در ضمن، ابزارهای کامند لاینی امکان اسکریپت‌نویسی -خودکار کردن یک سری کارهای تکراری- را نیز به شما می‌دهند تا مثلاً در بازه های زمانی مشخص، نسخه‌های مختلفی از نرم‌افزار بیلد شده و ذخیره گردد. + +حال سؤالی که اینجا مطرح می‌شود این است که مگر به غیر از این است که IDE ها برای راحتی کار برنامه‌نویسان و افزایش بازدهی ایشان طراحی و ساخته شده‌اند؟ اگر پاسخ به این سؤال آری است، پس چرا باید برنامه‌نویسان را تشویق به استفاده از ابزارهای کامند لاینی کنیم؟ + +پاسخ به سؤال فوق «آری» است اما نکته یی که در این آموزش یاد آور شدیم هرگز بدان معنا نیست که شما از امروز باید IDE خود را کنار بگذارید و کلاً به صورت کامند لاینی فرایند توسعه ی نرم‌افزار خود را دنبال کنید بلکه منظور این است که آشنایی با ابزارهای کامند لاینی، دید به مراتب بازتری به شما به عنوان یک برنامه‌نویس می‌دهند و زمانی که کاری را در نرم‌افزارهای گرافیکی انجام می‌دهید که صرفا با چند کلیک به هدف خود می‌رسید، متوجه می‌شوید که پشت پرده چه اتفاقاتی رخ می‌دهد و بهترین رویکرد برای درک این موضوع هم استفاده از ابزارهای کامند لاین است. + +پس از آن که شما شروع به استفاده از ابزارهای کامند لاین کردید، هر وقت که با IDE خود کار کنید کاملاً متوجه می‌شوید که هر کلیک چه کاری انجام می‌دهد و با دید بازتری می‌توانید فرایند بیلد نرم‌افزار را کنترل کنید. نکته ی آخر هم این که وقتی به کامند لاین تسلط پیدا کنید، به احتمال قریب به یقین دیگر به سمت نرم‌افزارهای گرافیکی نخواهید رفت! From 712f46909de422866dd5c3fbfaa7fdae8cd0fbce Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 14:44:46 +0300 Subject: [PATCH 189/290] Added number 44 --- fr-IR/thing_44/README.md | 20 +++++++++----------- 1 file changed, 9 insertions(+), 11 deletions(-) diff --git a/fr-IR/thing_44/README.md b/fr-IR/thing_44/README.md index 81556bef..ab4657d1 100644 --- a/fr-IR/thing_44/README.md +++ b/fr-IR/thing_44/README.md @@ -1,19 +1,17 @@ -# Know Well More than Two Programming Languages +# یادگیری هم‌زمان بیش از یک زبان برنامه‌نویسی -The psychology of programming people have known for a long time now that programming expertise is related directly to the number of different programming paradigms that a programmer is comfortable with. That is not just know about, or know a bit, but genuinely can program with. +فلسفه ی برنامه نویسی حاکی از آن است که «مهارت برنامه نویسی مستقیماً وابسته به پارادایم های مختلف برنامه نویسی که یک برنامه نویس برای کدنویسی مورد استفاده قرار می‌دهد و با آن‌ها احساس راحتی می‌کند است نه دانش اندکی که وی ممکن است از یک زبان برنامه نویسی دیگر داشته باشد!» -Every programmer starts with one programming language. That language has a dominating effect on the way that programmer thinks about software. No matter how many years of experience the programmer gets using that language, if they stay with that language, they will only know that language. A *one language* programmer is constrained in their thinking by that language. +هر برنامه نویسی، با یک زبان برنامه نویسی پا به دنیای برنامه نویسی می‌گذارد و جالب است بدانیم که آن زبان، تأثیر بسزایی روی رویکرد فرد در مورد توسعه ی نرم‌افزار می‌گذارد؛ اصلاً مهم نیست که فرد برنامه نویس چند سال است که با زبان انتخابی اش کد می زند، بلکه مادامی که فرد در حال کار با آن زبان است، می‌توان گفت که فقط و فقط آن زبان را بلد است. جالب است بدانیم که برنامه نویسان اصطلاحاً تک-زبانه دایره ی فکر کردن خود را محدود به قابلیت‌های آن زبان می‌کنند اما برنامه نویسی که اقدام به یادگیری زبان دوم می‌کند، ذهنیت وی در مورد توسعه ی نرم‌افزار به چالش کشیده خواهد شد مخصوصاً اگر زبان دوم از لحاظ ساختاری دارای تفاوت‌های عمیقی نسبت به زبان اول باشد. -A programmer who learns a second language will be challenged, especially if that language has a different computational model than the first. C, Pascal, Fortran, all have the same fundamental computational model. Switching from Fortran to C introduces a few, but not many, challenges. Moving from C or Fortran to C++ or Ada introduces fundamental challenges in the way programs behave. Moving from C++ to Haskell is a significant change and hence a significant challenge. Moving from C to Prolog is a very definite challenge. +برای روشن‌تر شدن این مسأله مثالی می‌زنیم؛ زبان‌های سی، پاسکال و فورترن دارای مدل های ساختاری تقریباً یکسانی هستند به طوری که اگر کسی زبان سی را بلد باشد و زبان دومش را فوترن انتخاب کند، به طور حتم با چالش های خیلی زیادی مواجه نخواهد شد اما مهاجرت از زبان‌هایی همچون سی یا فوترن به زبان دیگری همچون سی پلاس پلاس یا آدا، برنامه نویس را با موقعیت های بسیار متفاوتی در زمینه ی نحوه عملکرد زبان برنامه نویسی مواجه خواهد ساخت و بالتبع مهاجرت از سی پلاس پلاس به هسکل هم چالشی مضاعف خواهد بود. -We can enumerate a number of paradigms of computation: procedural, object-oriented, functional, logic, dataflow, etc. Moving between these paradigms creates the greatest challenges. +در‌ واقع پارادایم های برنامه نویسی مختلف من جمله Procedural یا رویه یی، Object-oriented یا شیء گرا، Functional یا تابعی و … وجود دارند که از لحاظ ساختاری دارای تفاوت‌هایی با یکدیگر هستند و در صورت مهاجرت در میان این پارادایم ها، می بایست منتظر چالش های فراوانی هم باشیم! -Why are these challenges good? It is to do with the way we think about the implementation of algorithms and the idioms and patterns of implementation that apply. In particular, cross-fertilization is at the core of expertise. Idioms for problem solutions that apply in one language may not be possible in another language. Trying to port the idioms from one language to another teaches us about both languages and about the problem being solved. +نکته یی که در اینجا می بایست مد نظر داشته باشیم این است که این چالش ها هرگز بد نیستند بلکه اتفاقاً باید به استقبال آن‌ها برویم چرا که پارادایم های مختلف برنامه نویسی، نگاه ما به توسعه نرم‌افزار را دگرگون می‌کنند چرا که مسأله یی خاص در یک زبان برنامه نویسی ممکن است به شیوه یی نسبتاً دشوار حل شود در صورتی که با توجه به پارادایم های اعمال شده در زبانی دیگر، پاسخ به آن مسأله با دردسرهای به مراتب کمتری در دسترس مان قرار گیرد و در چنین شرایطی است که ما می‌توانیم به ماهیت واقعی هر دو زبان پی ببریم. -Cross-fertilization in the use of programming languages has huge effects. Perhaps the most obvious is the increased and increasing use of declarative modes of expression in systems implemented in imperative languages. Anyone versed in functional programming can easily apply a declarative approach even when using a language such as C. Using declarative approaches generally leads to shorter and more comprehensible programs. C++, for instance, certainly takes this on board with its wholehearted support for generic programming, which almost necessitates a declarative mode of expression. +به طور کلی، برنامه نویسان حرفه یی از یادگیری زبان‌های جدید اصلاً واهمه یی به خود راه نمی‌دهند و علاقمند به یادگیری زبان‌های جدید هستند؛ حتی اگر در کدنویسی روزمره ی خود، صرفاً از یک زبان برنامه نویسی استفاده کنند باز هم مشتاق به یادگیری زبان‌های دیگر هستند چرا که می‌دانند سایر زبان‌ها -مخصوصا اگر از پارادایم متفاوتی نسبت به آنچه زبان فعلی شان ارائه می‌کند- نگرش متفاوتی برای حل مسأله در اختیار ایشان قرار می‌دهند. -The consequence of all this is that it behooves every programmer to be well skilled in programming in at least two different paradigms, and ideally at least the five mentioned above. Programmers should always be interested in learning new languages, preferably from an unfamiliar paradigm. Even if the day job always uses the same programming language, the increased sophistication of use of that language when a person can cross-fertilize from other paradigms should not be underestimated. Employers should take this on board and allow in their training budget for employees to learn languages that are not currently being used as a way of increasing the sophistication of use of the languages that are used. +مدیران شرکت های نرم‌افزار می بایست بخشی از تایم کاری تیم توسعه ی نرم‌افزار خود را به یادگیری زبان‌های جدید اختصاص دهند حتی اگر قرار نباشد هیچ پروژه یی با زبان‌های جدید نوشته شود چرا که اتخاذ چنین رویکردی منجر به بازتر شدن دید برنامه نویسان شرکت نسبت به همان زبانی که به صورت روزمره مورد استفاده قرار می‌دهند می‌شود. -Although it's a start, a one-week training course is not sufficient to learn a new language: It generally takes a good few months of use, even if part-time, to gain a proper working knowledge of a language. It is the idioms of use, not just the syntax and computational model, that are the important factors. - -By [Russel Winder](http://programmer.97things.oreilly.com/wiki/index.php/Russel_Winder) \ No newline at end of file +در پایان هم می بایست این نکته را یادآور شد که یادگیری یک زبان صرفاً به یادگیری سینتکس اش و نوشتن یک برنامه ی Hello World خلاصه نمی‌شود بلکه نیاز به ماه ها کار مستمر و نوشتن پروژه های مختلف با آن زبان و درگیر شدن با بخش‌های مختلف زبان دارد. From 24a0c6aa17260243030aec35f3db435c8d96e8ec Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 14:46:03 +0300 Subject: [PATCH 190/290] Added number 45 --- fr-IR/thing_45/README.md | 25 ++++++++++++------------- 1 file changed, 12 insertions(+), 13 deletions(-) diff --git a/fr-IR/thing_45/README.md b/fr-IR/thing_45/README.md index 52d33539..fe8f119a 100644 --- a/fr-IR/thing_45/README.md +++ b/fr-IR/thing_45/README.md @@ -1,23 +1,22 @@ -# Know Your IDE +# محیط کد نویسی (IDE) خود را مثل موم در دست بگیرید -In the 1980s our programming environments were typically nothing better than glorified text editors... if we were lucky. Syntax highlighting, which we take for granted nowadays, was a luxury that certainly was not available to everyone. Pretty printers to format our code nicely were usually external tools that had to be run to correct our spacing. Debuggers were also separate programs run to step through our code, but with a lot of cryptic keystrokes. +در دهه ی ۸۰ میلادی، برنامه نویسان محدود بودند به ویرایشگرهای کد ساده یی که اگر خیلی خوش شانس بودند، ویرایشگر کد ایشان به Syntax Highlighting مجهز بود! در آن دوران اگر کسی می‌خواست برنامه ی خود را دیباگ کند، می بایست ابزارهای مجزایی نصب کند و اصلاً این‌ گونه نبود که با یک کلیک، فرایند دیباگ آغاز شود بلکه نیاز به انجام فرایندهای مختلفی بود. -During the 1990s companies began to recognize the potential income that they could derive from equipping programmers with better and more useful tools. The Integrated Development Environment (IDE) combined the previous editing features with a compiler, debugger, pretty printer, and other tools. During that time, menus and the mouse also became popular, which meant that developers no longer needed to learn cryptic key combinations to use their editors. They could simply select their command from the menu. +در دهه ی ۹۰، شرکت های نرم‌افزار متوجه خلائی در بازار برنامه نویسی شدند و آن هم چیزی نبود جز برنامه‌هایی کاربردی که می توانستند زندگی برنامه نویسان را ساده‌تر و در عین حال لذت بخش تر سازند و نتیجه این که IDE های مختلف به بازار عرضه شدند که قابلیت‌های جدید همچون کامپایلر، دیباگر و … را به نرم افزارهای ویرایشگر کد معمولی افزوده بودند. -In the 21st century IDEs have become so common place that they are given away for free by companies wishing to gain market share in other areas. The modern IDE is equipped with an amazing array of features. My favorite is automated refactoring, particularly *Extract Method*, where I can select and convert a chunk of code into a method. The refactoring tool will pick up all the parameters that need to be passed into the method, which makes it extremely easy to modify code. My IDE will even detect other chunks of code that could also be replaced by this method and ask me whether I would like to replace them too. +در همین دوران بود که برنامه‌های کامپیوتری به «منو» های مختلف مجهز شدند و با‌ عرضه ی دیوایس «ماوس» به بازار، برنامه نویسان دیگر مجبور نبودند تا برای انجام کاری خاص، از ترکیب کلیدهای مختلف استفاده کنند بلکه به سادگی با نشانگر ماوس خود، می توانستند روی یکی از منوهای نرم‌افزار کلیک کرده و پشت پرده، کامند خاصی اجرا گردد. -Another amazing feature of modern IDEs is the ability to enforce style rules within a company. For example, in Java, some programmers have started making all parameters final (which, in my opinion, is a waste of time). However, since they have such a style rule, all I would need to do to follow it is set it up in my IDE: I would get a warning for any non-final parameter. Style rules can also be used to find probable bugs, such as comparing autoboxed objects for reference equality, e.g., using `==` on primitive values that are autoboxed into reference objects. +پس از سال ۲۰۰۰، محیط های توسعه ی یکپارچه ی نرم‌افزار آنقدر رایج شدند که بسیاری از شرکت های نرم افزاری این IDE ها را به رایگان در اختیار برنامه نویسان قرار می‌دادند تا از این طریق شناخته تر شده و بتوانند سایر سرویس ها و محصولات خود را به فروش برسانند. این نرم‌افزارها از آن زمان تاکنون، روز به روز به ابزارهای بهتر و بیشتری مجهز شده اند به طوری که امروزه شاهد IDE هایی هستیم که قابلیت‌های منحصر به فردی همچون Automated Refactoring و یا Extract Method دارند. -Unfortunately modern IDEs do not require us to invest effort in order to learn how to use them. When I first programmed C on Unix, I had to spend quite a bit of time learning how the vi editor worked, due to its steep learning curve. This time spent up-front paid off handsomely over the years. I am even typing the draft of this article with *vi*. Modern IDEs have a very gradual learning curve, which can have the effect that we never progress beyond the most basic usage of the tool. +نکته کاری که Extract Method انجام می‌دهد این است که بخشی از کد را انتخاب کرده، سپس نرم‌افزار آن بلوک کد را به یک متد با نامی خاص برایمان تبدیل می‌کند. +یکی دیگر از قابلیت‌های محیط های توسعه ی یکپارچه ی نرم‌افزار امروزی -IDE- این است که می‌توان در تنظیمات نرم‌افزار یکسری «قوانین» وضع کرد و از آن پس، هر موقع که آن قانون را نقض کنیم، یک هشدار در معرض دیدمان قرار خواهد گرفت. به طور مثال، می خواهیم در زبان پی اچ پی قانونی را نظر بگیریم که هر پراپرتی که در بدنه ی کلاس خود تعریف می‌کنیم، protected باشد؛ در چنین شرایطی، هر موقعی که فراموش کنیم کلیدواژه ی protected را استفاده کنیم، نرم‌افزار به ما هشدار خواهد داد. -My first step in learning an IDE is to memorize the keyboard shortcuts. Since my fingers are on the keyboard when I'm typing my code, pressing *Ctrl+Shift+I* to inline a variable saves breaking the flow, whereas switching to navigate a menu with my mouse interrupts the flow. These interruptions lead to unnecessary context switches, making me much less productive if I try to do everything the lazy way. The same rule also applies to keyboard skills: Learn to touch type, you won't regret the time invested up-front. +تفاوتی که نرم افزارهایی همچون vi که در سیستم عامل های مبتنی بری یونیکس همچون گنو/لینوکس در دسترس کاربران قرار دارد با IDE های مدرن این است که استفاده از نرم افزاری همچون vi نیاز به مطالعه ی زیادی صرفاً برای یادگیری کار کردن با این نرم‌افزار است اما محیط گرافیکی بسیاری از IDE های مدرن به گونه یی طراحی شده است که برنامه نویس طی چند ساعت می‌تواند کار با آن را یاد بگیرد اما در طول زمان، بسیاری از برنامه نویسان به همان کارهای ابتدایی که یاد می‌گیرند با نرم‌افزار مد نظر خود انجام دهند اکتفا کرده و خیلی علاقه یی به کشف زیر و بم IDE از خود نشان نمی‌دهند! -Lastly, as programmers we have time proven Unix streaming tools that can help us manipulate our code. For example, if during a code review, I noticed that the programmers had named lots of classes the same, I could find these very easily using the tools *find*, *sed*, *sort*, *uniq*, and *grep*, like this: +برای روشن‌تر شدن این مسأله مثالی می‌زنیم. امروزه هر کاری که قبلاً از طریق کامند می‌شد انجام داد را می‌توان از طریق ماوس و منوهای تعبیه شده در نرم‌افزار انجام داد و برخی برنامه نویسان در طول زمان به استفاده از ماوس عادت می‌کنند اما غافل از این که برداشتن دست خود از روی کیبورد و استفاده از ماوس، زمان ایشان را هدر می‌دهد؛ برای کلیه ی کارهایی که از طریق ماوس می‌توان انجام داد، همچنین می‌توان «کلیدهای میانبر» نیز تعریف کرد به طوری که مثلاً برای باز کردن یک پنجره ی جدید، بستن پنجره، تغییر نام و … می‌توان بدون آن که دست خود را از روی کیبورد برداریم، کار مد نظر را انجام دهیم. -``` -find . -name "*.java" | sed 's/.*\///' | sort | uniq -c | grep -v "^ *1 " | sort -r -``` +اگر بخواهیم چکیده یی از این آموزش به دست آوریم، بایستی بگوییم که در توسعه ی نرم‌افزار زمان و مهم‌تر از آن صرفه جویی در زمان نقش بسیار تعیین کننده یی در موفقیت پروژه دارد و یکی از چیزهایی که می‌تواند به ما به عنوان یک برنامه نویس کمک کند، صرفه جویی در زمان کدنویسی با مسلط شدن به IDE مد نظر خود است؛ -We expect a plumber coming to our house to be able to use his blow torch. Let's spend a bit of time to study how to become more effective with our IDE. +سعی کنیم به جای آن که بیشتر از ماوس استفاده کنیم، از کلیدهای میانبر از پیش تعیین شده در IDE استفاده کرده و یا خود کلیدهای میانبری بسته به نیازمان تعریف کنیم تا به جای آن که زمانی را صرف بلند کردن دست خود از روی کیبورد، بردن به سمت ماوس، حرکت دادن آن، کلیک روی یک منو و باز شدن پنجره ی مد نظر کنیم، به سادگی در همان حین که کدنویسی می کنیم، یکی دو کلید میانبر را هم‌زمان فشرده و کامند مد نظرمان اجرا گردد. -by [Heinz Kabutz](http://programmer.97things.oreilly.com/wiki/index.php/Heinz_Kabutz) \ No newline at end of file +شاید در ابتدای راه استفاده ی صرف از کلیدهای میانبر کمی سخت باشد و به خاطر سپردن آن‌ها کاری دشوار، اما در طول زمان کدنویسی برایمان به مراتب لذت بخش تر خواهد شد. From 24d51cf7a4207bf6c06fb0770a34d6674af2b690 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 14:46:56 +0300 Subject: [PATCH 191/290] Added number 46 --- fr-IR/thing_46/README.md | 50 ++++------------------------------------ 1 file changed, 4 insertions(+), 46 deletions(-) diff --git a/fr-IR/thing_46/README.md b/fr-IR/thing_46/README.md index 22017199..bd75537a 100644 --- a/fr-IR/thing_46/README.md +++ b/fr-IR/thing_46/README.md @@ -1,49 +1,7 @@ -# Know Your Limits +# ا محدودیت‌های خود دست و پنجه نرم کنید -> *"Man's got to know his limitations." — Dirty Harry* +همواره به خاطر داشته باشید که منابع شما -شامل زمان و بودجه- محدود هستند؛ برای انجام پروژه های نرم افزاری یک زمان و پول کاملاً مشخصی در اختیار شما قرار می‌گیرد و این در حالی است که در این زمان محدود و بودجه ی کاملاً مشخص، علاوه بر تکمیل پروژه، شما می بایست دانش خود را به روز نگاه دارید، مهارت های جدید یاد بگیرید، با زبان‌های برنامه نویسی جدید آشنا شوید و … -Your resources are limited. You only have so much time and money to do your work, including the time and money needed to keep your knowledge, skills, and tools up-to-date. You can only work so hard, so fast, so smart, and so long. Your tools are only so powerful. Your target machines are only so powerful. So you have to respect the limits of your resources. +علاوه بر این، در حین پیاده‌سازی پروژه های نرم افزاری همواره بایستی به این نکته توجه داشته باشیم که برای به دست آوردن بیشترین میزان Performance (پرفورمنس یا عملکرد)، می بایست دید نسبتاً عمیقی از سخت افزاری که در اختیار ما قرار گرفته شامل سی پی یو، حافظه ی رم، زیرساخت های شبکه، هارد دیسک و … داشته باشیم به علاوه این که باید تمام تلاش خود را به کار گیریم تا الگوریتم هایی که می نویسیم را با توجه به این محدودیت‌ها، پیاده‌سازی کنیم تا بهترین نتیجه را بگیریم. -How to respect those limits? Know yourself, know your people, know your budgets, and know your stuff. Especially, as a software engineer, know the space and time complexity of your data structures and algorithms, and the architecture and performance characteristics of your systems. Your job is to create an optimal marriage of software and systems. - -Space and time complexity are given as the function *O(f(n))* which for n equal the size of the input is the asymptotic space or time required as n grows to infinity. Important complexity classes for *f(n)* include *ln(n)*, *n*, *n ln(n)*, *ne*, and *en*. As graphing these functions clearly shows, as *n* gets bigger *O(ln(n))* is ever so much smaller than *O(n)* and *O(n ln(n))*, which are ever so much smaller than *O(ne)* and *O(en)*. As Sean Parent puts it, for achievable n all complexity classes amount to near-constant, near-linear, or near-infinite. - -![](http://programmer.97things.oreilly.com/wiki/images/c/c0/Clearly.jpeg) - -| | access time | capacity | -|--------------|-----------------:| ----------:| -| register | < 1 ns | 64b | -| cache line | | 64B | -| L1 cache | 1 ns | 64 KB | -| L2 cache | 4 ns | 8 MB | -| RAM | 20 ns | 32 GB | -| disk | 10 ms | 10 TB | -| LAN | 20 ms | > 1 PB | -| internet | 100 ms | > 1 ZB | - -Complexity analysis is in terms of an abstract machine, but software runs on real machines. Modern computer systems are organized as hierarchies of physical and virtual machines, including language runtimes, operating systems, CPUs, cache memory, random-access memory, disk drives, and networks. The first table shows the limits on random access time and storage capacity for a typical networked server. - -Note that capacity and speed vary by several orders of magnitude. Caching and lookahead are used heavily at every level of our systems to hide this variation, but they only work when access is predictable. When cache misses are frequent the system will be thrashing. For example, to randomly inspect every byte on a hard drive could take 32 years. Even to randomly inspect every byte in RAM could take 11 minutes. Random access is not predictable. What is? That depends on the system, but re-accessing recently used items and accessing items sequentially are usually a win. - -Algorithms and data structures vary in how effectively they use caches. For instance: -- Linear search makes good use of lookahead, but requires *O(n)* comparisons. -- Binary search of a sorted array requires only *O(log(n))* comparisons. -- Search of a van Emde Boas tree is *O(log(n))* and cache-oblivious. - - -|Elements | Search time (ns)| | | -|:--------|-----------:|-----------:|--------:| -| | **linear** | **binary** | **vEB** | -| 8 | 50 | 90 | 40 | -| 64 | 180 | 150 | 70 | -| 512 | 1200 | 230 | 100 | -| 4096 | 17000 | 320 | 160 | - - -How to choose? In the last analysis, by measuring. The second table shows the time required to search arrays of 64-bit integers via these three methods. On my computer: -- Linear search is competitive for small arrays, but loses exponentially for larger arrays. -- van Emde Boas wins hands down, thanks to its predictable access pattern. - -> *"You pays your money and you takes your choice." — [Punch](http://www.nytimes.com/1988/02/28/magazine/on-language-you-pays-yer-money.html?pagewanted=all)* - -By [Greg Colvin](http://programmer.97things.oreilly.com/wiki/index.php/Greg_Colvin) +به عبارت دیگر، به منظور ایجاد یک پرفومنس بهینه، بایستی یک «سازگاری و آشتی» مابین مفاهیم انتزاعی همچون الگوریتم ها و سخت افزاری که در اختیار ما قرار گرفته است ایجاد کنیم و صرفاً در این صورت است که می‌توانیم ادعا کنیم یک نرم‌افزار بهینه تولید کرده ایم. From 5c42ea685f6a388eb3eed5fe6009cc71656f21fe Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 14:47:43 +0300 Subject: [PATCH 192/290] Added number 47 --- fr-IR/thing_47/README.md | 21 ++++++--------------- 1 file changed, 6 insertions(+), 15 deletions(-) diff --git a/fr-IR/thing_47/README.md b/fr-IR/thing_47/README.md index f62c5d6c..4939c5be 100644 --- a/fr-IR/thing_47/README.md +++ b/fr-IR/thing_47/README.md @@ -1,19 +1,10 @@ -# Know Your Next Commit +# همواره بدانید چه چیزی را قرار است کامیت کنید -I tapped three programmers on their shoulders and asked what they were doing. "I am refactoring these methods," the first answered. "I am adding some parameters to this web action," the second answered. The third answered, "I am working on this user story." +به نوعی می‌توان برنامه نویسان را به ۲ گروه مختلف تقسیم‌بندی کرد: گروهی که وقتی از ایشان می‌پرسید که مشغول به چه کاری هستند، به وضوح می‌توانند بگویند که مثلاً «در حال کار کردن روی کلاس مرتبط با یوزر هستم» و گروهی که پاسخی همچون «در تلاش برای بهبود روند سرویس یوزرها ام» که به نظر می‌رسد برنامه نویسی که پاسخ اول را داده است، دقیقاً می‌داند در حال انجام دادن چه کاری است اما در این در حالی است که برنامه نویس دوم بیشتر یک دید کلی نسبت به پروژه دارا است! -It might seem that the first two were engrossed in the details of their work while only the third could see the bigger picture, and that the latter had the better focus. However, when I asked when and what they would commit, the picture changed dramatically. The first two where pretty clear over what files would be involved and would be finished within an hour or so. The third programmer answered, "Oh, I guess I will be ready within a few days. I will probably add a few classes and might change those services in some way." +در همین راستا اگر از برنامه نویسی که پاسخ اول را داده است بپرسیم که چه چیزی را در نهایت کامیت خواهی کرد، به سادگی قادر خواهد بود تا نام تک تک فایل‌هایی که روی آن‌ها کار کرده و قرار است آن‌ها را کامیت کند ببرد اما برنامه نویسانی که به گروه دوم تعلق دارند، نه تنها نمی‌دانند که کارشان دقیقاً چه زمانی تمام خواهد شد، بلکه حتی نمی‌دانند که آیا قصد دارند فایل‌های قبلی را ریفکتور کنند یا مجبور می‌شوند که چند فایل جدید هم به پروژه بیافزایند. -The first two did not lack a vision of the overall goal. They had selected tasks they thought led in a productive direction, and could be finished within a couple of hours. Once they had finished those tasks, they would select a new feature or refactoring to work on. All the code written was thus done with a clear purpose and a limited, achievable goal in mind. +نکته به طور کلی، در سیستم‌های کنترل نسخه همچون Git، منظور از اصطلاح «Commit» ذخیره سازی تغییرات صورت گرفته روی سورس کد به صورت لوکال و روی سیستم خود برنامه نویس است و در صورتی که این تغییرات مورد تأیید باشند، در نهایت می‌تواند آن‌ها را اصطلاحاً Push کند تا سایر برنامه نویسان تیم هم بتوانند تغییرات صورت گرفته را در اختیار داشته باشند. +برنامه نویسی که پاسخی مشابه پاسخ اول را در اختیار ما می‌دهد، دقیقاً می‌داند که قرار است چه کاری انجام دهد و اصطلاحاً «فوکوس» روی پروژه دارد؛ کارهایی که می بایست روی پروژه انجام شوند را تقسیم‌بندی کرده، هر بخش را در بازه ی زمانی مشخصی انجام داده و در نهایت می‌داند که کدنویسی اش منجر به بهبود کدام بخش از پروژه شده است. اما برنامه نویسانی که پاسخی مشابه پاسخ دوم ارائه می‌دهند نمی‌توانند دقیقاً بگویند که مشغول به چه کاری هستند چرا که در آن واحد می‌خواهند یک بهبود کلی روی سیستم اعمال کنند که چنین بهبودی ممکن است نیاز به ریفکتورینگ بخش قابل توجهی از سورس کد داشته باشد. -The third programmer had not been able to decompose the problem and was working on all aspects at once. He had no idea of what it would take, basically doing speculative programming, hoping to arrive at some point where he would be able to commit. Most probably the code written at the start of this long session was poorly matched for the solution that came out in the end. - -What would the first two programmers do if their tasks took more than two hours? After realizing they had taken on too much, they would most likely throw away their changes, define smaller tasks, and start over. To keep working would have lacked focus and led to speculative code entering the repository. Instead, changes would be thrown away, but the insights kept. - -The third programmer might keep on guessing and desperately try to patch together his changes into something that could be committed. After all, you cannot throw away code changes you have done — that would be wasted work, wouldn't it? Unfortunately, not throwing the code away leads to slightly odd code that lacks a clear purpose entering the repository. - -At some point even the commit-focused programmers might fail to find something useful they thought could be finished in two hours. Then, they would go directly into speculative mode, playing around with the code and, of course, throwing away the changes whenever some insight led them back on track. Even these seemingly unstructured hacking sessions have purpose: to learn about the code to be able to define a task that would constitute a productive step. - -Know your next commit. If you cannot finish, throw away your changes, then define a new task you believe in with the insights you have gained. Do speculative experimentation whenever needed, but do not let yourself slip into speculative mode without noticing. Do not commit guesswork into your repository. - -By [Dan Bergh Johnsson](http://programmer.97things.oreilly.com/wiki/index.php/Dan_Bergh_Johnsson) \ No newline at end of file +برنامه نویسان گروه اول همواره این شانس را دارند که اگر بخواهند به گذشته بازگردند، این کار را به سادگی با چند بار Ctrl +Z انجام دهند اما این قضیه در مورد برنامه نویسان گروه دوم اصلاً صدق نمی‌کند! پس به خاطر داشته باشیم که در انجام پروژه های نرم افزاری، همواره تسک ها را به بخش های کوچک و قابل کنترلی تقسیم بندی کرده، برای هر کدام از آن ها یک Deadline (ددلاین یا ضرب الاجل) در نظر بگیریم و در آن واحد فقط و فقط روی یکی از آن ها کار کرده و به محض تکمیل یک تسک، با خیال راحت سراغ تسک بعدی برویم. From c3710ecfc773aa141187d9a76c592635d11234f5 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 14:48:35 +0300 Subject: [PATCH 193/290] Added number 48 --- fr-IR/thing_48/README.md | 21 +++++++++++++-------- 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/fr-IR/thing_48/README.md b/fr-IR/thing_48/README.md index a42518f9..07e70605 100644 --- a/fr-IR/thing_48/README.md +++ b/fr-IR/thing_48/README.md @@ -1,15 +1,20 @@ -# Large Interconnected Data Belongs to a Database +# آشنایی با نحوهٔ به‌کارگیری دیتابیس‌های رابطه‌ای -If your application is going to handle a large, persistent, interconnected set of data elements, don't hesitate to store it in a relational database. In the past RDBMSs used to be expensive, scarce, complex, and unwieldy beasts. This is no longer the case. Nowadays RDBMS systems are easy to find — it is likely that the system you're using has already one or two installed. Some very capable RDBMSs, like MySQL and PostgreSQL, are available as open source software, so cost of purchase is no longer an issue. Even better, so-called embedded database systems can be linked as libraries directly into your application, requiring almost no setup or management — two notable open source ones are SQLite and HSQLDB. These systems are extremely efficient. +درصورتی‌که دست به توسعهٔ اپلیکیشنی زده‌اید که قرار است حجم قابل‌توجهی از دیتاهای مرتبط با یکدیگر را جمع‌آوری کند، بدون شک نیاز به دیتابیسی از نوع Relational (رابطه‌ای) خواهید داشت. پیش از این، سیستم‌های مدیریت دیتابیس‌های رابطه‌ای یا اصطلاحاً RDBMS (که مخفف واژگان Relational DataBase Management System است) برای دولوپرها هزینه‌بر بودند و از سوی دیگر نیز استفاده از آن‌ها به سادگی آنچه امروزه می‌بینیم نبود. -If your application's data is larger than the system's RAM, an indexed RDBMS table will perform orders of magnitude faster than your library's map collection type, which will thrash virtual memory pages. Modern database offerings can easily grow with your needs. With proper care, you can scale up an embedded database to a larger database system when required. Later on you can switch from a free, open source offering to a better-supported or more powerful proprietary system. +اما خوشبختانه درحال‌حاضر RDBMSهایی اپن‌سورس و رایگان به بازار عرضه شده‌اند که از جملهٔ مهم‌ترین آن‌ها می‌توان به MySQL و PostgreSQL اشاره کرد؛ خبر بهتر این‌که دیتابیس‌های به‌اصطلاح Embedded را به‌سادگی استفاده از یک لایبرری در داخل اپلیکیشن‌های مختلف و تقریباً بدون نیاز به هرگونه ستاپ یا پیکربندی مورد استفاده قرار داد که از جملهٔ مهم‌ترین آن‌ها می‌توان به SQLite و HSQLDB اشاره کرد. -Once you get the hang of SQL, writing database-centric applications is a joy. After you've stored your properly normalized data in the database it's easy to extract facts efficiently with a readable SQL query; there's no need to write any complex code. Similarly, a single SQL command can perform complex data changes. For one-off modifications, say a change in the way you organize your persistent data, you don't even need to write code: Just fire up the database's direct SQL interface. This same interface also allows you to experiment with queries, sidestepping a regular programming language's compile–edit cycle. +درصورتی‌که دیتای اپلیکیشن‌ شما از توان پردازش میزان حافظهٔ RAM سرورتان بیشتر است، سیستم‌های RDBMS این امکان را در اختیار دلوپرها قرار داده‌اند تا با Index (ایندکس یا اندیس) کردن جداول، به‌سادگی بر این مشکل فائق آیند. -Another advantage of basing your code around an RDBMS involves the handling of relationships between your data elements. You can describe consistency constraints on your data in a declarative way, avoiding the risk of the dangling pointers you get if you forget to update your data in an edge case. For example, you can specify that if a user is deleted then the messages sent by that user should be removed as well. +مسلماً کار با سیستم‌های RDBMS نیازمند آشنایی با زبان SQL است؛ جالب است بدانید سینتکس زبان SQL بسیار قابل‌فهم بوده و پس از یادگیری این زبان پس از کمی تکرار و تمرین، به‌سادگی قادر خواهید بود دست به عملیات CRUD بزنید (منظور از اصطلاح CRUD،‌ انجام به‌اصطلاح Update، Read، Create و Delete به‌ترتیب به‌معنی ایجاد، فراخوانی، به‌روزرسانی و حذف است). -You can also create efficient links between the entities stored in the database anytime you want, simply by creating an index. There is no need to perform expensive and extensive refactorings of class fields. In addition, coding around a database allows multiple applications to access your data in a safe way. This makes it easy to upgrade your application for concurrent use and also to code each part of your application using the most appropriate language and platform. For instance, you could write the XML back-end of a web-based application in Java, some auditing scripts in Ruby, and a visualization interface in [Processing](http://www.processing.org/). +نکته SQL که به‌صورت «اس‌کیو‌ال» تلفظ می‌شود، مخفف واژگان Structured Query Language است که به‌منزلهٔ زبان استانداری برای ارتباط با دیتابیس‌های مختلف مورد استفاده قرار می‌گیرد. +یکی دیگر از مزایای آموختن کار با دیتابیس‌های RDBMS این است که این‌نوع سیستم‌های مدیریت دیتابیس همان‌طور که از نامشان پیدا است، اصطلاحاً Relational (رابطه‌ای) هستند؛ به‌عبارت دیگر، می‌توان بین جداول مختلف، ستون‌های یک جدول با سایر ستون‌های جداول دیگر و به‌طورکلی مابین دیتای ذخیره شده نوعی از ارتباط را برقرار ساخت. -Finally, keep in mind that the RDBMS will sweat hard to optimize your SQL commands, allowing you to concentrate on your application's functionality rather than on algorithmic tuning. Advanced database systems will even take advantage of multicore processors behind your back. And, as technology improves, so will your application's performance. +وجود چنین ارتباطی چندین مزیت دارا است؛ اولین مزیت این که درحین فراخوانی یک داده، می‌توان پی به ارتباطش با سایر داده‌های ذخیره‌سازی شده برد (مثلاً می‌شود مشخص کرد که اگر یک کاربر از جدول مخصوص ذخیره‌سازی اطلاعات کاربران پاک شد، کلیهٔ کامنت‌های ثبت شده توسط آن کاربر هم در جدول مخصوص این‌کار به‌صورت خودکار پاک شود). -By [Diomidis Spinellis](http://programmer.97things.oreilly.com/wiki/index.php/Diomidis_Spinellis) \ No newline at end of file +علاوه‌بر این، وجود چنین ارتباطی می‌تواند این تضمین را ایجاد کند که به‌صورت ناخواسته، تحت هیچ‌ عنوان نمی‌شود دیتایی را از دیتابیس حذف کرد؛ به‌عبارت دیگر، اگر مابین ستون‌های ۲ جدول مختلف نوعی ارتباط محدودکننده درنظر گرفته شده باشد، مادامی‌که دیتای یکی از جداول در جایی مورد استفاده قرار گرفته باشد،‌ دیگر امکان حذف آن داده وجود ندارد و همین مسأله این تضمین را ایجاد می‌کنند که یکپارچگی مابین کلیهٔ داده‌های ذخیره‌شده حفظ می‌گردد. + +یکی دیگر از نکاتی که در مورد RDBMSها می‌بایست مدنظر قرار داد این است که این سیستم‌های مدیریت دیتابیس با زبان‌های برنامه‌نویسی مختلفی سازگار هستند و امکان استفادهٔ هم‌زمان توسط چندین زبان مختلف را به دولوپر می‌دهند. + +به‌طور مثال، فرض کنیم وب اپلیکیشنی داریم که برای کدنویسی بخش صفحات دینامیک آن از زبان PHP استفاده کرده‌ایم اما درعین‌حال باتوجه به این که برای تحلیل داده‌ها به زبان و لایبرری‌هایی نیاز داریم که این فرایند را برایمان ساده‌تر کنند، برای این‌کار به‌سادگی بااستفاده از زبان Python می‌توان به تعامل با دیتابیس پرداخت. From ff69e34d56d4adca06d8e167875b76792266c5e4 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 14:49:28 +0300 Subject: [PATCH 194/290] Added number 49 --- fr-IR/thing_49/README.md | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/fr-IR/thing_49/README.md b/fr-IR/thing_49/README.md index 455c33d5..f364002f 100644 --- a/fr-IR/thing_49/README.md +++ b/fr-IR/thing_49/README.md @@ -1,19 +1,20 @@ -# Learn Foreign Languages +# آشنایی با مهارت‌های ارتباطی و فراگیری زبان‌های خارجی -Programmers need to communicate. A lot. +یکی بخش‌های لاینفک حرفه‌ٔ کدنویسی، ارتباطات است؛ گرچه بخش قابل‌توجی از زمان دولوپرها به تعامل با کامپیوتر، کامپایلر، ابزارهای توسعهٔ نرم‌افزار و مهم‌تر از همه پروژه‌ای که درحال کار کردن روی آن هستند می‌گذرد، اما درعین‌حال دولوپرها گاهی‌اوقات می‌بایست با سایرین نیز به دلایل مختلفی ارتباط داشته باشند. -There are periods in a programmer's life when most communication seems to be with the computer. More precisely, with the programs running on that computer. This communication is about expressing ideas in a machine-readable way. It remains an exhilarating prospect: Programs are ideas turned into reality, with virtually no physical substance involved. +موفقیت پروژه‌های بزرگ و مهم برنامه‌نویسی امروزه دیگر بیش از آن‌که دلیل فنی داشته باشد، مستلزم وجود تعاملی سازنده به‌صورت گروهی-اجتماعی است؛ بسیاری از برنامه‌نویسان موفق کسانی هستند که علاوه‌بر تسلط به یک یا چند زبان برنامه‌نویسی، به مهارت‌های ارتباطی و دیگر زبان‌های زندهٔ دنیا به‌غیر از زبان مادری خود نیز مسلط هستند. -Programmers need to be fluent in the language of the machine, whether real or virtual, and in the abstractions that can be related to that language via development tools. It is important to learn many different abstractions, otherwise some ideas become incredibly hard to express. Good programmers need to be able to stand outside their daily routine, to be aware of other languages that are expressive for other purposes. The time always comes when this pays off. +نیاز به توضیح نیست که در فرایند کدنویسی، دولوپر به‌نوعی از طریق کدهایی که می‌نویسد صحبت کرده و از سیستم می‌خواهد تا تسک‌های مدنظرش را به انجام برساند. یک برنامه‌نویس خوب در تعامل با دیگر افراد نیز به‌خوبی می‌داند که با چه زبانی و با چه شیوه‌ای به تعامل با ایشان بپردازد تا به بهترین شکل ممکن بتواند منظورش را به دیگران منتقل کرده و ارتباطی اثربخش ایجاد نماید. -Beyond communication with machines, programmers need to communicate with their peers. Today's large projects are more social endeavors than simply an application of the art of programming. It is important to understand and express more than the machine-readable abstractions can. Most of the best programmers I know are also very fluent in their mother's tongue, and typically in other languages as well. This is not just about communication with others: Speaking a language well also leads to a clarity of thought that is indispensable when abstracting a problem. And this is what programming is also about. +نکته‌ٔ دیگری که در زمینهٔ ارتباطات فردی در حوزهٔ توسعهٔ نرم‌افزار می‌بایست مدنظر قرار داد این است که به غیر از دولوپرها، افراد ذی‌نفع بسیاری در یک پروژهٔ نرم‌افزاری نسبتاً‌ بزرگ دخیل هستند که از آن جمله می‌توان به مدیر محصول، مدیر پروژه، کارشناس تجربهٔ کاربری، مدیر بازاریابی، تسترهای نرم‌افزار، دولوپرهای فرانت‌اند و همچنین صاحب اصلی محصول (مشتری) اشاره کرد که برخی از ایشان دارای دانش فنی هستند و برخی دیگر خیر. -Beyond communication with machine, self, and peers, a project has many stakeholders, most with a different or no technical background. They live in testing, quality and deployment, in marketing and sales, they are end users in some office (or store or home). You need to understand them and their concerns. This is almost impossible if you cannot speak their language — the language of their world, their domain. While you might think a conversation with them went well, they probably don't. +یک دولوپر خوب کسی است که به‌خوبی با نیازهای تک‌تک افراد فوق‌الذکر آشنایی داشته و ایشان را به‌خوبی درک کند و برای نیل به چنین مهمی، ما می‌بایست با هریک از افراد بالا با زبان خودش بتوانیم صحبت کنیم؛ به‌عبارت دیگر، جایی نیاز است فنی صحبت کنیم و جایی هم می‌بایست در غیرفنی‌ترین حالت ممکن منظور خود را بیان کنیم تا مخاطب کاملاً متوجه منظورمان شود. -If you talk to accountants, you need a basic knowledge of cost-center accounting, of tied capital, capital employed, et al. If you talk to marketing or lawyers, some of their jargon and language (and thus, their minds) should be familiar to you. All these domain-specific languages need to be mastered by someone in the project — ideally the programmers. Programmers are ultimately responsible for bringing the ideas to life via a computer. +اجازه دهید برای روشن‌تر شدن این مسأله، مثالی بزنیم؛ فرض کنیم یک مشتری داریم که حسابدار است و قرار است برایش یک نرم‌افزاری مالی بنویسیم؛ برای این که ارتباط کلامی با این مشتری به بهترین شکل ممکن صورت گیرد، ما می‌بایست با برخی مفاهیم حسابداری همچون ترازنامه، بدهکار، بستانکار، صورت مالی، دارایی جاری، اصل بهای تمام‌شده، بدهی، معوقه و غیره آشنایی داشته باشیم که اصطلاحاً به این موارد Jargon گفته می‌شود. -And, of course, life is more than software projects. As noted by [Charlemagne](http://en.wikipedia.org/wiki/Charlemagne), to know another language is to have another soul. For your contacts beyond the software industry, you will appreciate knowing foreign languages. To know when to listen rather than talk. To know that most language is without words. +نکته Jargon به اصطلاحات تخصصی هر حرفه‌ای گفته می‌شود که بخش قابل‌توجهی از مکالمات افراد فعال در آن حوزه بااستفاده از این اصطلاحات تخصصی صورت می‌گیرد؛ به‌عنوان مثال، افراد مختلفی همچون پزشکان، وکلا، حسابداران، مکانیک‌ها، برنامه‌نویس‌ها و دیگر متخصصین هرکدام اصطلاحات کاری خود را دارند که در حین صحبت با همکارانشان، به‌سادگی از آن‌ها استفاده کرده و هردو طرف هم به‌خوبی منظور یکدیگر را متوجه می‌شوند. +به‌طور‌کلی، زمانی‌که یک برنامه‌نویس این وظیفه را دارا است تا نیازها، ایده‌ها و دغدغه‌های مشتریان را به کد تبدیل کند، آشنایی با این جارگون‌ها یک ضرورت است. همچنین جدای از تمامی این مباحث و دانستن این نکته که مهارت‌های ارتباطی و اجتماعی بخشی جدایی‌ناپذیر از زندگی یک دولوپر است، برخورداری از دانش زبان انگلیسی برای دولوپری که قصد دارد برچسب حرفه‌ای روی خود بزند یک باید است. -> *Whereof one cannot speak, thereof one must be silent.* - Ludwig Wittgenstein +به‌عبارت دیگر، دولوپری که بخواهد پابه‌پای دانش روز نرم‌افزاری دنیا حرکت کند، به‌راحتی داکیومنت‌های زبان‌های برنامه‌نویسی، لایبرری‌ها و غیره را بخواند، به‌راحتی در گوگل و استک‌اورفلو سرچ کند و با دیگر دولوپرهای سراسر دنیا در ارتباط باشد، داشتن مهارت زبان انگلیسی (حداقل خواندن و نوشتن) کم‌ترین چیزی است که از وی انتظار می‌رود. -By [Klaus Marquardt](http://programmer.97things.oreilly.com/wiki/index.php/Klaus_Marquardt) \ No newline at end of file +به‌عبارت دیگر، اگر دولوپر تازه‌کاری هستید که قصد دارید حرفه‌ٔ توسعه‌ٔ نرم‌افزار را به‌عنوان شغل اصلی خود و محل درآمدتان انتخاب کنید اما دانش کافی در زمینهٔ زبان انگلیسی ندارید، توصیه می‌شود فراگیری زبان برنامه‌نویسی خود را متوقف کرده و شروع به یادگیری زبان انگلیسی کنید چراکه پس از مسلط شدن به مهارت‌های خواندن و نوشتن -و البته درصورت امکان مهارت‌های صحبت کردن و گوش کردن- سرعت یادگیری و پیشرفت شما در زمینهٔ کدنویسی به‌مراتب بیش از زمانی خواهد بود که زبان نمی‌دانستید! From e281d49041c8217f48d3e956a68eae0d7ebc9aea Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 14:50:49 +0300 Subject: [PATCH 195/290] Added number 50 --- fr-IR/thing_50/README.md | 35 ++++++++++++++++------------------- 1 file changed, 16 insertions(+), 19 deletions(-) diff --git a/fr-IR/thing_50/README.md b/fr-IR/thing_50/README.md index f9b665db..880b106e 100644 --- a/fr-IR/thing_50/README.md +++ b/fr-IR/thing_50/README.md @@ -1,31 +1,28 @@ -# Learn to Estimate +# خود را با مهارت تخمین زدن تجهیز کنید! -As a programmer you need to be able to provide estimates to your managers, colleagues, and users for the tasks you need to perform, so that they will have a reasonably accurate idea of the time, costs, technology, and other resources needed to achieve their goals. +به‌عنوان یک دولوپر، گاهی‌اوقات نیاز است تا در مورد چیزهای مختلف همچون زمان تکمیل یک تسک و غیره به مدیران، همکاران و حتی گاهی هم کاربران سرویسی که درحال توسعهٔ آن هستند تخمین بزنید تا ایشان به‌راحتی بتوانند در مورد زمان، هزینه‌های جاری، فناوری‌ و دیگر منابع مورد نیاز برای دستیایی به اهدافشان تصمیم‌گیری کنند. -To be able to estimate well it is obviously important to learn some estimation techniques. First of all, however, it is fundamental to learn what estimates are, and what they should be used for — as strange as it may seem, many developers and managers don't really know this. +تخمین زدن چیزهای مختلف، یک مهارت است که می‌بایست تکنیک‌هایی برای هرچه بهتر انجام دادن این کار آموخت؛ پیش از هرچیز، باید بدانیم که اصلاً «تخمین زدن» به چه معنا است و برای «چه کارهایی» می‌بایست از آمار و ارقام تخمینی استفاده کرد. اجازه دهید برای روشن‌تر شدن این مسأله، مکالمه‌ای فرضی مابین یک مدیر پروژه و یکی از دولوپرهای تیم نرم‌افزاری‌اش را در ادامه مدنظر قرار می‌دهیم: -The following exchange between a project manager and a programmer is not untypical: +مدیر پروژه: می‌تونی یک زمان تخمینی از تکمیل فیچر X بدی؟ +دولوپر: ۱ ماه -> *Project Manager:* Can you give me an estimate of the time necessary to develop feature *xyz*? +مدیر پروژه: خیلی طولانیه! ما فقط ۱ هفته زمان داریم. +دولوپر: حداقل ۳ هفته زمان نیاز دارم تا بتونم چنین چیزی رو بنویسم. -> *Programmer:* One month. +مدیر پروژه: بیش از ۲ هفته برام راه نداره. +دولوپر: اوکی مشکلی نیست. -> *Project Manager:* That's far too long! We've only got one week. +در پایان این مذاکره، دولوپر به تخمینی از انجام فیچر X دست پیدا می‌کند که مطلوب مدیر پروژه است؛ اما از آنجا که قبول ضرب‌العجل ۲ هفته‌ای از طرف دولوپر به‌نوعی زمان تخمینی مورد تأیید وی نیز محسوب می‌شود، هرگونه مسئولیتی درصورت نرسیدن به این ضرب‌العجل متوجه دولوپر خواهد بود و وی باید پاسخگو باشد. برای این که به درک درستی از چیزی که در این مکالمه اشتباه است برسیم، می‌بایست معنا و مفهوم ۳ چیز مختلف را به‌خوبی درک کنیم: تخمین، هدف و تعهد. -> *Programmer:* I need at least three. +1 - تخمین (Estimate) یک محاسبهٔ تقریبی یا قضاوت کردن در مورد کیفیت یا کمیت چیزی است؛ چنین تعریفی حاکی از آن است تخمین چیزی است که براساس تجربیات گذشته و دیتایی که در دسترس داریم صورت می‌گیرد و این درحالی است که احساسات و آمال و آرزوها در تخمین زدن همواره می‌بایست مدنظر قرار داده نشوند. تعریفی که از تخمین به‌دست می‌آید همچنین حاکی از آن است یک تخمین هرگز دقیق نیست (مثلاً نمی‌شود گفت که تکمیل فلان تسک برنامه‌نویسی، ۳ روز کاری کامل و ۵ ساعت ۳۰ دقیقه به‌طول خواهد انجامید.) -> *Project Manager:* I can give you two at most. +2 - هدف (Target) در کسب‌وکار به نقطه‌ای اشاره دارد که پس از رسیدن به آن نقطه، نتیجه‌ای دلخواه نصیبمان می‌شود (مثلاً در یک پروژهٔ نرم‌افزاری این هدف را داریم تا پس از انجام یک تسک، اپلیکیشن بتواند در آن واحد هم‌زمان ۱۰۰۰ کاربر را بدون کمبود در منابع سخت‌افزاری و نرم‌افزاری ساپورت کند). -> *Programmer:* Deal! +3 - تعهد (Commitment) قولی است که یکی از طرفین به دیگری می‌دهد تا تسک خواسته شده را در زمان مقرر با کیفیت مدنظر طرف مقابل به‌صورت مشخصی که روی آن از قبل توافق شده تحویل دهد (به‌طور مثال، در یک پروژهٔ طراحی سایت می‌توان گفت که افزودن شدن قابلیت سرچ به سایت در نسخهٔ ۲.۰ تعهدی است که دولوپر به مشتری می‌دهد). -The programmer, at the end, comes up with an "estimate" that matches what is acceptable for the manager. But since it is seen to be the programmer's estimate, the manager will hold the programmer accountable to it. To understand what is wrong with this conversation we need three definitions — estimate, target, and commitment: +گرچه تخمین، هدف و تعهد مجزا از یکدیگر می‌باشند، اما این درحالی است که اهداف و تعهدات می‌بایست براساس تخمین‌های درستی صورت گیرند؛ به‌عبارت دیگر، هدف اصلی از تخمین زدن در فرایند توسعهٔ نرم‌افزار این نیست که خروجی یک پروژه را پیش‌بینی کنیم بلکه هدف اصلی آن است که مشخص کنیم آیا اهداف پروژه به‌اندازهٔ کافی واقع‌گرایانه هستند تا بر آن اساس بتوان مدیریت و برنامه‌ریزی درستی انجام داد یا خیر تا درنهایت بتوان به تعهدات قول داده شده دست یافت. -- An *estimate* is an approximate calculation or judgement of the value, number, quantity, or extent of something. This definition implies that an estimate is a factual measure based on hard data and previous experience — hopes and wishes must be ignored when calculating it. The definition also implies that, being approximate, an estimate cannot be precise, e.g., a development task cannot be estimated to last 234.14 days. -- A *target* is a statement of a desirable business objective, e.g., "The system must support at least 400 concurrent users." -- A *commitment* is a promise to deliver specified functionality at a certain level of quality by a certain date or event. One example could be "The search functionality will be available in the next release of the product." +اگر مجدد به مکالمهٔ صورت گرفته مابین مدیر پروژه و دولوپرش باز گردیم، می‌بینیم که این مدیر قصد داشت تا براساس هدفی نادرست که در ذهنش داشت، دولوپر را مجبور کند متعهد به انجام تسک X شود و در این مکالمه اصلاً منظور مدیر پروژه گرفتن یک زمان تخمینی از دولوپر نبود! -Estimates, targets, and commitments are independent from each other, but targets and commitments should be based on sound estimates. As Steve McConnell notes, "The primary purpose of software estimation is not to predict a project's outcome; it is to determine whether a project's targets are realistic enough to allow the project to be controlled to meet them." Thus, the purpose of estimation is to make proper project management and planning possible, allowing the project stakeholders to make commitments based on realistic targets. - -What the manager in the conversation above was really asking the programmer was to make a commitment based on an unstated target that the manager had in mind, not to provide an estimate. The next time you are asked to provide an estimate make sure everybody involved knows what they are talking about, and your projects will have a better chance of succeeding. Now it's time to learn some techniques.... - -By [Giovanni Asproni](http://programmer.97things.oreilly.com/wiki/index.php/Giovanni_Asproni) \ No newline at end of file +در پایان هم یادآوری یک نکته ضروری است که هروقت از شما خواسته شد تا به‌عنوان یک برنامه‌نویس در مورد چیزی تخمین بزنید، اطمینان حاصل کنید که از تمامی جنبه‌های کار آگاهی دارید، پس از تخمین زدن و وسط کار از شما تکمیل تسک‌های جانبی خواسته نمی‌شود، تمامی ابزارها و حداقل شرایط لازم برای به انجام رساندن تسک خواسته شده را دارید و از همه مهم‌تر، کلیهٔ شرایط پیش‌روی شما واقع‌گرایانه هستند. From 2f4dbb241d7e9e7b69339dd0370d556056c4d64c Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 14:53:04 +0300 Subject: [PATCH 196/290] Added number 51 --- fr-IR/thing_51/README.md | 42 +++++++++++++--------------------------- 1 file changed, 13 insertions(+), 29 deletions(-) diff --git a/fr-IR/thing_51/README.md b/fr-IR/thing_51/README.md index 1d0a5b31..72f3e3f3 100644 --- a/fr-IR/thing_51/README.md +++ b/fr-IR/thing_51/README.md @@ -1,39 +1,23 @@ -# Learn to Say "Hello, World" +# کدام یک؟ IDE یا Editor ، مسأله این است! -Paul Lee, username leep, more commonly known as Hoppy, had a reputation as the local expert on programming issues. I needed help. I walked across to Hoppy's desk and asked, could he take a look at some code for me? +یکی از نکاتی که در ۹۷ چیزی که هر برنامه‌نویسی باید بلد باشد پیش از این گفته شد، مسألهٔ «IDE خود را مثل موم در دست بگیرید» بود؛ در این آموزش گفتیم که یک دولوپر حرفه‌ای کسی است که آنقدر به IDE خود مسط باشد که به‌سادگی و بااستفاده از کلیدهای میانبر بتواند به‌بخش‌های نرم‌افزار مورداستفادهٔ خود دسترسی یافته و به‌سرعت کدنویسی کند. -Sure, said Hoppy, pull up a chair. I took care not to topple the empty cola cans stacked in a pyramid behind him. +به خاطر داشته باشید IDE مخفف واژگان Integrated Development Environment به‌معنی «محیط توسعهٔ یکپارچهٔ برنامه‌نویسی» است که از جمله IDEهای معروف و محبوب می‌توان به Eclipse ،Visual Studio و IntelliJ IDEA اشاره کرد. +اما درعین‌حال، برخی متخصصین بر این باورند که IDEها -اگر نگوییم همیشه، اما در ابتدای راه فراگیری اصول کدنویسی- دولوپرها را به‌نوعی تنبل و وابسته می‌کنند. اجازه دهید برای روشن‌تر شدن دلیل چنین اتفاقی، چند مثال ساده بزنیم. -What code? +یکی از خصوصیات منحصربه‌فرد IDEها چیزی است تحت‌عنوان Code Completion؛ به‌عبارت دیگر، نرم‌افزار وقتی که شما ابتدای نام تابعی از پیش تعریف شده در زبان برنامه‌نویسی مدنظر خود را می‌نویسید، برای این که به فرایند کدنویسی شما سرعت بخشد پیشنهاداتی به شما داده و درنهایت کد تابع شما را تکمیل می‌کند. -In a function in a file, I said. +علاوه‌بر این، یکی دیگر از خصوصیات بسیار کاربردی IDEها برقرار ارتباط بین بخش‌های مختلف پروژه است؛ به‌عبارت دیگر، اگر مثلاً زبانی همچون PHP را درنظر بگیریم، وقتی که قصد داریم یک کلاس از یکی از ماژول‌های پروژه را در کلاسی در ماژولی دیگر مورد استفاده قرار دهیم، می‌بایست کلاس مدنظر را به‌اصطلاح use کنیم اما این درحالی است که نرم‌افزاری همچون اکلیپس این‌کار را به‌صورت خودکار برای برایمان انجام داده به‌طوری‌که اصلاً روحمان هم خبردار نخواهد شد که چنین اقدامی صورت‌ گرفته است! -So let's take a look at this function. Hoppy moved aside a copy of K&R and slid his keyboard in front of me. +این‌ها صرفاً ۲ مثال از صدها کاربرد اثربخش، مفید و منحصر‌به‌فرد IDEها است و اگر فقط‌وفقط به یک روی سکه نگاه کنیم، این ۲ مورد و صدها مورد دیگر را می‌توان به‌عنوان نقاط قوت یک IDE قلمداد کرد. -Where's the IDE? Apparently Hoppy had no IDE running, just some editor which I couldn't operate. He grabbed back the keyboard. A few keystrokes later and we had the file open — it was quite a big file — and were looking at the function — it was quite a big function. He paged down to the conditional block I wanted to ask about. +اما روی دیگر سکه چه‌طور؟ +برخی دولوپرها بر این باورند که روی دیگر سکه مادامی‌که برنامه‌نویسی مبتدی از یک IDE استفاده می‌کند را می‌توان به‌عنوان یک نقطهٔ ضعف قلمداد کرد. مجدد اجازه دهید برای روشن‌تر شدن این مسأله، به ۲ مثالی که در بالا بدان‌ها اشاره شد بازگردیم. -What would this clause actually do if `x` is negative? I asked. Surely it's wrong. +وقتی که ما از یک IDE استفاده می‌کنیم و این نرم‌افزار هم صرفاً قصد این را دارا است تا فرایند کدنویسی را برایمان لذت‌بخش‌تر سازد و مثلاً وقتی نام فانکشنی همچون explode در زبان پی‌اچ‌پی را می‌نویسیم، به‌صورت خودکار ادامهٔ نام این فانکشن را تکمیل کرده و حتی پارامترهای ورودی پیش‌فرض را نیز مدنظر قرار می‌دهد. -I'd been trying all morning to find a way to force `x` to be negative, but the big function in the big file was part of a big project, and the cycle of recompiling *then* rerunning my experiments was wearing me down. Couldn't an expert like Hoppy just tell me the answer? +نقطهٔ منفی چنین کاری این است که یک دولوپر -به‌خصوص زمانی‌که در ابتدای راه کدنویسی است- دیگر مبانی زبان مدنظرش در ذهنش نهادینه نشده و هموراه وابسته به نرم‌افزار برای تکمیل کدها است و اگر روزی قرار باشد تا با نرم‌افزاری مثلاً همچون Nodepad ویندوز، Gedit لینوکس و یا TextMate مکینتاش اقدام به ویرایش سورس‌کدی کند، به احتمال قریب‌به‌یقین در این رابطه به مشکل خواهد خورد. -Hoppy admitted he wasn't sure. To my surprise, he didn't reach for K&R. Instead, he copied the code block into a new editor buffer, re-indented it, wrapped it up in a function. A short while later he'd coded up a main function that looped forever, prompting the user for input values, passing them to the function, printing out the result. He saved the buffer as a new file, tryit.c. All of this I could have done for myself, though perhaps not as quickly. But his next step was wonderfully simple and, at the time, quite foreign to my way of working: +یا حتی وقتی که در مثال دوم گفتیم اکلیپس به‌صورت خودکار کلاس‌های مورد استفاده را اصطلاحاً use می‌کند، در دراز مدت ممکن است ما هرگز متوجهٔ بایدی بودن چنین کاری نشویم و از آنجا که همواره کلاس‌های use شده در بالای فایل هستند و معمولاً ما هم در بخش‌های پایینی یک فایل کدی را اضافه کرده و یا اقدام به ریفکتور کردن بخشی از کد می‌کنیم، هرگز متوجه نمی‌شویم که این کار باید صورت گیرد و مجدد اگر روزی قرار باشد تا با یک ادیتور ساده دست به ویرایش سورس‌کد بزنیم، ممکن است عدم توجه به این مسأله منجر به سردرگمی‌مان برای دقیقه‌های -و شاید ساعت‌های- متمادی گردد. -``` -$ cc tryit.c && ./a.out -``` - -Look! His actual program, conceived just a few minutes earlier, was now up and running. We tried a few values and confirmed my suspicions (so I'd been right about something!) and then he cross-checked the relevant section of K&R. I thanked Hoppy and left, again taking care not to disturb his cola can pyramid. - -Back at my own desk, I closed down my IDE. I'd become so used to working on a big project within a big product I'd started to think that was what I should be doing. A general purpose computer can do little tasks too. I opened a text editor and began typing. - -``` -#include - -int main() -{ - printf("Hello, World\n"); - return 0; -} -``` - -By [Thomas Guest](http://programmer.97things.oreilly.com/wiki/index.php/Thomas_Guest) \ No newline at end of file +در کل، IDEها بسیار خوب هست اما به‌نظر می‌رسد که در ابتدای راه کدنویسی،‌ بیش از آن‌که مفید باشند و در دراز مدت کمک برنامه‌نویس کنند، وی را تنبل و وابسته بار می‌آورند؛ لذا توصیه آن است که در حین یادگیری اصول کدنویسی و یا مبانی یک زبان برنامه‌نویسی، همواره از ادیتورهای ساده‌ای مثل موارد فوق‌الذکر استفاده نمایید تا اصول و زیروبم زبان مدنظر در ذهنتان نهادینه شود سپس زمانی‌که احساس کردید به‌خوبی می‌دانید که مثلاً فانکشن‌های مختلف به‌ چه شکلی نوشته می‌شوند، ارتباط بخش‌های مختلف یک زبان‌ برنامه‌نویسی خاص به چه شکل است و غیره، در آن موقع می‌توانید برای آن‌که سرعت کدنویسی خود را افزایش دهید -که خود این مسأله هم به‌نوعی حاکی از حرفه‌ای بودن است- می‌توانید به استفاده از یک IDE روی آورید. From 78fc11f69e10adfae2722fd62d899a459a115a5f Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 14:53:56 +0300 Subject: [PATCH 197/290] Added number 52 --- fr-IR/thing_52/README.md | 18 +++++++----------- 1 file changed, 7 insertions(+), 11 deletions(-) diff --git a/fr-IR/thing_52/README.md b/fr-IR/thing_52/README.md index da65147d..ac82681f 100644 --- a/fr-IR/thing_52/README.md +++ b/fr-IR/thing_52/README.md @@ -1,17 +1,13 @@ -# Let Your Project Speak for Itself +# ارسال پیام خطا به دولوپر توسط نرم‌افزار -Your project probably has a version control system in place. Perhaps it is connected to a continuous integration server that verifies correctness by automated tests. That's great. +شما ممکن است پروژه‌های نرم‌افزاری‌تان را بااستفاده از تست‌های خودکار (Automated Tests) سنجیده، آمار و ارقام مفیدی در مورد سورس‌کد، باگ‌ فیکس‌ها و … داشته باشید که حاوی اطلاعات ارزشمندی دربارهٔ فرایند تکامل پروژه در طول زمان باشند. -You can include tools for static code analysis into your continuous integration server to gather code metrics. These metrics provide feedback about specific aspects of your code, as well as their evolution over time. When you install code metrics, there will always be a red line that you do not want to cross. Let's assume you started with 20% test coverage and never want to fall below 15%. Continuous integration helps you keep track of all these numbers, but you still have to check regularly. Imagine you could delegate this task to the project itself and rely on it to report when things get worse. +دولوپرهای حرفه‌ای همواره یک خط قرمزی دارند که هرگز اجازه نمی‌دهند کیفیت کدها پایین‌تر از آن قرار گیرد؛ حال اگر چنین خط قرمزی توسط خود پروژه مدیریت شود چه اتفاقی رخ خواهد داد؟ به‌عبارت دیگر، خود سورس‌کد به گونه‌ای طراحی شود که اگر چیزی در شرف خراب شدن بود، به دولوپر هشدار دهد. -You need to give your project a voice. This can be done by email or instant messaging, informing the developers about the latest decline or improvement in numbers. But it's even more effective to embody the project in your office by using an extreme feedback device (XFD). +یک اپلیکیشن هم می‌تواند همچون ما آدم‌ها سخنگو باشد اما به این شکل که یا از طریق ایمیل و یا از طریق دیگر راه‌های ارتباطی همچون پیامک، نوتیفیکشن و غیره اطلاعاتی از چند و چون کارکرد اپلیکیشن را در اختیار دولوپر قرار دهد. -The idea of XFDs is to drive a physical device such as a lamp, a portable fountain, a toy robot, or even an USB rocket launcher, based on the results of the automatic analysis. Whenever your limits are broken, the device alters its state. In case of a lamp, it will light up, bright and obvious. You can't miss the message even if you're hurrying out the door to get home. +اگر در حین کدنویسی به چنین قابلیتی هم فکر کنیم -یعنی خود نرم‌افزار در مورد تعداد اکسپشن‌ها، ارورها و غیره به دولوپرش هشدار دهد- می‌توانیم اطمینان حاصل کنیم قبل از آن که اوضاع روبه وخامت بگذارد، می‌توانیم دست به اصلاح سورس‌کد بزنیم. -Depending on the type of extreme feedback device, you can hear the build break, see the red warning signals in your code, or even smell your code smells. The devices can be replicated at different locations if you work on a distributed team. You can place a traffic light in your project manager's office, indicating overall project health state. Your project manager will appreciate it. +برخی دولوپرها هم به‌خاطر مهم دانستن این موضوع، کمی خلاقیت به‌خرج داده و سیستمی طراحی می‌کنند که درصورت بروز مشکلات فنی در اپلیکیشن طراحی شده، یک چراغ قرمز هشدار چنین پیامی را به اعضای تیم توسعهٔ نرم‌افزار منتقل کند و شاید هم برخی پا را از این هم فراتر گذاشته و سیستمی طراحی کننده که بااستفاده از یک اسپیکر، نرم‌افزار درصورت بروز مشکل به صدا درآمد و مثلاً بگوید «دولوپرم عزیزم من اصلاً حالم خوب نیست و باگ‌ها امانم رو بریده‌اند!» -Let your creativity guide you in choosing an appropriate device. If your culture is rather geeky, you might look for ways to equip your team mascot with radio-controlled toys. If you want a more professional look, invest in sleek designer lamps. Search the Internet for more inspiration. Anything with a power plug or a remote control has the potential to be used as an extreme feedback device. - -The extreme feedback device acts as the voice box of your project. The project now resides physically with the developers, complaining or praising them according to the rules the team has chosen. You can drive this personification further by applying speech synthesis software and a pair of loudspeakers. Now your project really speaks for itself. - -By [Daniel Lindner](http://programmer.97things.oreilly.com/wiki/index.php/Daniel_Lindner) \ No newline at end of file +به‌طورکلی، لاگ‌ها اطلاعات بسیار ارزشمندی از نحوهٔ کارکرد نرم‌افزار در اختیار دولوپر قرار می‌دهند و این درحالی است که بسیاری از دولوپرها اصلاً توجهی به این دست اطلاعات ارزشمند نمی‌کنند! ما به‌سادگی و بااستفاده از لاگ‌های نرم‌افزارمان می‌توانیم روزبه‌روز دست به بهبود سورس‌کد زده و باگ‌ها، خطا‌ها و اکسپشن‌ها را به حداقل برسانیم. From ac0013bd6c7f313a8ce48d4999fc0aa2da4ecc50 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 14:55:43 +0300 Subject: [PATCH 198/290] Modified number 53 --- fr-IR/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fr-IR/SUMMARY.md b/fr-IR/SUMMARY.md index 1f642f98..421cf04d 100644 --- a/fr-IR/SUMMARY.md +++ b/fr-IR/SUMMARY.md @@ -53,7 +53,7 @@ 1. [تخمین زدن را بیاموزید](thing_50/README.md) 1. [گاهی مسائل و مشکلات بزرگ را به قسمت های کوچکتر بشکنید و با تکه های کوچک سعی و خطا کنید!](thing_51/README.md) 1. [طوری کد بزنید که پروژه ی شما خودش معرف خودش باشد](thing_52/README.md) -1. [لینکر (Linker) یک برنامه جادویی نیست](thing_53/README.md) +1. [چیزهای اضافی را لود نکنید!](thing_53/README.md) 1. [طول عمر راه حل های موقت](thing_54/README.md) 1. [سعی کنید Interface ها را طوری بنویسید که برای استفاده ی صحیح آسان باشند و برای استفاده ی ناصحیح سخت!](thing_55/README.md) 1. [موارد نامرئی را بیشتر قابل مشاهده(شفاف سازی) کنید](thing_56/README.md) From ad22b343f6b10c9e6b5444e6a84ed817dcf4c2ff Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 14:56:20 +0300 Subject: [PATCH 199/290] Added number 53 --- fr-IR/thing_53/README.md | 54 ++++++---------------------------------- 1 file changed, 8 insertions(+), 46 deletions(-) diff --git a/fr-IR/thing_53/README.md b/fr-IR/thing_53/README.md index af6960a3..c367f6b2 100644 --- a/fr-IR/thing_53/README.md +++ b/fr-IR/thing_53/README.md @@ -1,52 +1,14 @@ -# The Linker Is not a Magical Program +# چیزهای اضافی را لود نکنید! -Depressingly often (happened to me again just before I wrote this), the view many programmers have of the process of going from source code to a statically linked executable in a compiled language is: +به لطف جامعهٔ اپن‌سورس، امروزه می‌بینیم که بسیاری از زبان‌های برنامه‌نویسی، فریمورک‌ها، لایبرری‌ها و غیره به‌صورت اپن‌سورس و رایگان در اختیار دولوپرها قرار گرفته‌اند؛ این وفور نعمت، گاهی منجر به ایجاد آشفتگی در پروژه‌های نر‌م‌افزاری می‌شود زیرا از آنجا که دولوپر نمی‌خواهد برای استفاده از مثلاً لایبرری X در پروژه‌اش هزینه‌ای بپردازد، گرچه دیگر نیازی به این لایبرری ندارد، اما کماکان این لایبرری داخل پروژه قرار دارد که نه‌تنها فضایی را اشغال کرده است (ولو چند کیلوبایت) بلکه لینک به این لایبرری در جای‌جای سورس‌کد هم مشاهده می‌شود و این درحالی است که اگر دولوپر دیگری بخواهد این پروژه‌ را در آینده نگهداری کرده و یا توسعه دهد، ممکن است دچار سردرگمی شود. -1. Edit source code -2. Compile source code into object files -3. Something magical happens -4. Run executable +در چنین مواقعی می‌بایست تمام تلاش خود را به‌کار بندیم تا وابستگی‌های پروژه همچون ماژول‌ها، لایبرری‌ها و غیره کاملاً شفاف بوده و اگرهم تمایل نداریم تا مثلاً لایبرری‌های بلااستفاده را حذف کنیم، حتماً می‌بایست به‌نوعی مشخص شوند (که این کار را با کامنت‌گذاری صحیح می‌توان انجام داد). -Step 3 is, of course, the linking step. Why would I say such an outrageous thing? I've been doing tech support for decades, and I get the following questions again and again: +این قضیه نه‌تنها در مورد لایبرری‌های به‌اصطلاح Third Party صدق می‌کند، بلکه در مورد کلاس‌ها، متدها و حتی متغیرها هم صادق است؛ به‌عبارت‌دیگر، گاهی در سورس‌کد برخی پروژه‌ها فانکشن‌هایی را می‌بینیم که در هیچ کجای پروژه فراخوانی نشده‌اند و اما کماکان وجود داشته و حتی کامنت‌ هم نشده‌اند! -- The linker says def is defined more than once. -- The linker says abc is an unresolved symbol. -- Why is my executable so large? +نکته در صنعت توسعهٔ نرم‌افزار منظور از اصطلاح Third Party، کامپوننت‌های توسعه داده شده توسط هر تیم توسعه، شرکت و یا گروهی به‌غیر از توسعه‌‌دهندهٔ اصلی یک محصول (لایبرری، زبان‌برنامه‌نویسی، فریمورک و غیره) است که چنین کامپوننت‌هایی یا به‌صورت اپن‌سورس و رایگان و یا به‌صورت پولی عرضه می‌گردند. +در چنین شرایطی، وقتی که می‌خواهیم اقدام به حذف بخش‌هایی از سورس‌کد کنیم که دیگر مورد استفاده قرار نمی‌گیرند -همچون لایبرری‌های قدیمی یا حتی کلاس‌های بلااستفاده- حتماً می‌بایست به‌خاطر داشته باشیم اصلاً نباید این اطمینان را داشته باشیم که ۱۰۰٪ در هیچ‌کجای پروژه از موارد مدنظر استفاده نشده‌ است. -Followed by "What do I do now?" usually with the phrases "seems to" and "somehow" mixed in, and an aura of utter bafflement. It's the "seems to" and "somehow" that indicate that the linking process is viewed as a magical process, presumably understandable only by wizards and warlocks. The process of compiling does not elicit these kinds of phrases, implying that programmers generally understand how compilers work, or at least what they do. +برای اطمینان حاصل کردن از این موضوع، ابتدا باید لایبرری را به‌صورت موقت حذف کرده سپس به انحاء مختلف شروع به تست پروژه کنیم تا مطمئن شویم که بدون حضور مثلاً لایبرری X، پروژه کماکان بدون مشکل کار می‌کند. -A linker is a very stupid, pedestrian, straightforward program. All it does is concatenate together the code and data sections of the object files, connect the references to symbols with their definitions, pull unresolved symbols out of the library, and write out an executable. That's it. No spells! No magic! The tedium in writing a linker is usually all about decoding and generating the usually ridiculously overcomplicated file formats, but that doesn't change the essential nature of a linker. - -So let's say the linker is saying def is defined more than once. Many programming languages, such as C, C++, and D, have both declarations and definitions. Declarations normally go into header files, like: - -``` -extern int iii; -``` - -which generates an external reference to the symbol `iii`. A definition, on the other hand, actually sets aside storage for the symbol, usually appears in the implementation file, and looks like this: - -``` -int iii = 3; -``` - -How many definitions can there be for each symbol? As in the film *Highlander*, there can be only one. So, what if a definition of iii appears in more than one implementation file? - -``` -// File a.c -int iii = 3; -``` - -``` -// File b.c -double iii(int x) { return 3.7; } -``` - -The linker will complain about `iii` being multiply defined. - -Not only can there be only one, there must be one. If iii only appears as a declaration, but never a definition, the linker will complain about iii being an unresolved symbol. - -To determine why an executable is the size it is, take a look at the map file that linkers optionally generate. A map file is nothing more than a list of all the symbols in the executable along with their addresses. This tells you what modules were linked in from the library, and the sizes of each module. Now you can see where the bloat is coming from. Often there will be library modules that you have no idea why were linked in. To figure it out, temporarily remove the suspicious module from the library, and relink. The undefined symbol error then generated will indicate who is referencing that module. - -Although it is not always immediately obvious why you get a particular linker message, there is nothing magical about linkers. The mechanics are straightforward; it's the details you have to figure out in each case. - -By [Walter Bright](http://creativecommons.org/licenses/by/3.0/us/) +به‌طورکلی، تمیز بودن سورس‌کد پروژه -که نبود لایبرری‌ها، ماژول‌ها، کلاس‌ها و فانکشن‌های بلااستفاده در آن به‌نوعی مرتبط با تمیز بودن است- نشان از حرفه‌ای بودن دولوپرش دارد اما این تمیزی سورس‌کد بیش از هر چیزی، کمک به دیگر دولوپرهایی خواهد کرد که ممکن است در آینده بخواهند روی چنین پروژه‌ای کار کنند. From f6cd0cfc9fdd22b7b560dfa138a745e36018bea6 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 14:57:05 +0300 Subject: [PATCH 200/290] Modified number 54 --- fr-IR/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fr-IR/SUMMARY.md b/fr-IR/SUMMARY.md index 421cf04d..408ff3c9 100644 --- a/fr-IR/SUMMARY.md +++ b/fr-IR/SUMMARY.md @@ -54,7 +54,7 @@ 1. [گاهی مسائل و مشکلات بزرگ را به قسمت های کوچکتر بشکنید و با تکه های کوچک سعی و خطا کنید!](thing_51/README.md) 1. [طوری کد بزنید که پروژه ی شما خودش معرف خودش باشد](thing_52/README.md) 1. [چیزهای اضافی را لود نکنید!](thing_53/README.md) -1. [طول عمر راه حل های موقت](thing_54/README.md) +1. [چه‌موقع و چگونه از راه‌کارهای موقتی در کدنویسی استفاده کنیم؟](thing_54/README.md) 1. [سعی کنید Interface ها را طوری بنویسید که برای استفاده ی صحیح آسان باشند و برای استفاده ی ناصحیح سخت!](thing_55/README.md) 1. [موارد نامرئی را بیشتر قابل مشاهده(شفاف سازی) کنید](thing_56/README.md) 1. [رد و بدل کردن مسیج ها منجر به مقیاس پذیری بهتر در سیستم های موازی می شود](thing_57/README.md) From cb86fe78e2db880740efd430397efca09e862527 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 14:57:37 +0300 Subject: [PATCH 201/290] Added number 54 --- fr-IR/thing_54/README.md | 34 +++++++++++----------------------- 1 file changed, 11 insertions(+), 23 deletions(-) diff --git a/fr-IR/thing_54/README.md b/fr-IR/thing_54/README.md index 3a117d54..1cef0a2d 100644 --- a/fr-IR/thing_54/README.md +++ b/fr-IR/thing_54/README.md @@ -1,33 +1,21 @@ -# The Longevity of Interim Solutions +# چه‌موقع و چگونه از راه‌کارهای موقتی در کدنویسی استفاده کنیم؟ -Why do we create interim solutions? +در پاسخ به این سؤال که چرا برخی دولوپرها دست به استفاده از سولوشن‌های (راه‌کارهای) موقتی می‌زنند بایستی گفت که علت اصلی مشکلات غیرمنتظره‌ای هستند که پیش می‌آیند و بایستی در کوتاه‌ترین زمان ممکن رفع شوند. -Typically there is some immediate problem to solve. It might be internal to the development team, some tooling that fills a gap in the tool chain. It might be external, visible to end users, such as a workaround that addresses missing functionality. +در بسیاری از تیم‌های توسعه‌ٔ نرم‌افزار همواره بخش‌‌هایی وجود دارند که هرگز از استانداردهای کدنویسی تبعیت نکرده و با سایر بخش‌های سورس‌کد هم‌خوانی ندارند و بالاخره روزی می‌بایست ریفکتور شده و با سایر بخش‌های سیستم هارمونی پیدا کنند. -In most systems and teams you will find some software that is somewhat dis-integrated from the system, that is considered a draft to be changed sometime, that does not follow the standards and guidelines that shaped the rest of the code. Inevitably you will hear developers complaining about these. The reasons for their creation are many and varied, but the key to an interim solution's success is simple: It is useful. +نیاز به توضیح هم نیست که اکثر دولوپرها همواره از این موضوع شاکی هستند؛ گرچه دلایل بسیاری برای وجود این دست «راه‌کارهای موقتی» بسیارند اما کلید موفقیت این دست راه‌کارها کاربردی بودنشان است! -Interim solutions, however, acquire inertia (or momentum, depending on your point of view). Because they are there, ultimately useful and widely accepted, there is no immediate need to do anything else. Whenever a stakeholder has to decide what action adds the most value, there will be many that are ranked higher than proper integration of an interim solution. Why? Because it is there, it works, and it is accepted. The only perceived downside is that it does not follow the chosen standards and guidelines — except for a few niche markets, this is not considered to be a significant force. +باتوجه به این که Interim Solutions (راه‌کارهای موقتی) به‌نوعی مفید واقع شده و مورد قبول برخی دولوپرها قرار گرفته‌اند، کمتر کسی را می‌توان یافت که برای رفع آن‌ها گامی بردارد چراکه مفید، کاربردی و مشکل‌گشا بوده و تنها نقطه‌ضعفی که دارند این است که استانداردهای کدنویسی را فالو نمی‌کنند (البته این درحالی است که چنین چیزی در بسیاری از شرکت‌های نرم‌افزاری و تیم‌های توسعه اصلاً مشکل خاصی محسوب نمی‌شود). -So the interim solution remains in place. Forever. +حال ممکن است زمان‌هایی پیش آید که پس از پیاده‌سازی راه‌کارهای موقتی به‌منظور رفع یک باگ و یا افزودن یک فیچر جدید، نرم‌افزار پس از مدتی به مشکل می‌خورد و از آنجا که استانداردهای کدنویسی در پیاده‌سازی این دست راه‌کارها اعمال نشده، طبق روال هم به‌سادگی نمی‌توان دست به رفع مشکلات پیش آمده زد. -And if problems arise with that interim solution, it is unlikely there will be provision for an update that brings it into line with accepted production quality. What to do? A quick interim update on that interim solution often does the job. And will most likely be well received. It exhibits the same strengths as the initial interim solution... it is just more up to date. +در پاسخ به این سؤال که در چنین مواقعی چه باید کرد؟ بایستی گفت که معمولاً آپدیت‌های موقعی روی باگ‌های موجود در راه‌کارهای موقتی جواب می‌دهند و از لحاظ ماهیت، آپدیت‌های موقتی دقیقاً شبیه راه‌کارهای موقتی هستند با این تفاوت که کمی به‌روزشده‌تر می‌باشند. -Is this a problem? +همواره این نکته را به‌خاطر داشته باشیم زمانی‌که پروژه‌ای حاوی راه‌کارهای موقتی بسیاری باشد، از یک سو پیچیدگی سورس‌کد افزایش یافته و از سوی دیگر نگهداری، آپدیت و دیباگینگ نرم‌افزار هم به‌مراتب دشوارتر خواهد شد. به‌عنوان یک Best Practice کلی، وقتی در فرایند توسعه‌ٔ نرم‌افزار با مشکلی روبه‌رو شدید، ابتدا مراحل زیر را به ترتیب اولویت انجام دهید: -The answer depends on your project, and on your personal stake in the production code standards. When the systems contains too many interim solutions, its entropy or internal complexity grows and its maintainability decreases. However, this is probably the wrong question to ask first. Remember that we are talking about a solution. It may not be your preferred solution — it is unlikely to be anyone's preferred solution — but the motivation to rework this solution is weak. +۱- تا حد ممکن از ارائهٔ راه‌کارهای موقتی خودداری کنید. خودداری‌هایی از این دست در بسیاری از موارد چارهٔ کار نیست چراکه ممکن است مشکلی جدی بوجود آمده باشد که نیاز است تا در اسرع وقت رفع گردد و اگر دولوپر پروژه بخواهد استانداردهایی که تا پیش از این به‌کار می‌‌بسته را در رفع مشکل فعلی مدنظر گیرد، این استانداردها دست‌وپاگیر خواهند بود اما به‌هرحال به‌عنوان اولین تلاش چنین چیزی توصیه می‌شود. -So what can we do if we see a problem? +۲- تا حد ممکن مقابل اصرارهای مدیر پروژه به‌منظور اعمال یک فیچر خاص در کمترین زمان ممکن مقابله نمایید. در برخی موارد، اصرارهای مدیر پروژه آنقدرها هم که وی وانمود می‌کند لازم‌الاجرا نیست و از همین روی ضرری ندارد که تا حدی در مقابل اصرارهای وی مقاومت کرد. -1. Avoid creating an interim solution in the first place. -2. Change the forces that influence the decision of the project manager. -3. Leave it as is. - -Let's examine these options more closely: - -1. Avoidance does not work in most places. There is an actual problem to solve, and the standards have turned out to be too restrictive. You might spend some energy trying to change the standards. An honorable albeit tedious endeavor... and that change will not be effective in time for your problem at hand. -2. The forces are rooted in the project culture, which resists volitional change. It could be successful in very small projects — especially if it's just you — and you just happen to clean the mess without asking in advance. It could also be successful if the project is such a mess that it is visibly stalled and some time for cleaning up is commonly accepted. -3. The status quo automatically applies if the previous option does not. - -You will create many solutions, some of them will be interim, most of them will be useful. The best way to overcome interim solutions is to make them superfluous, to provide a more elegant and useful solution. May you be granted the [serenity](http://en.wikipedia.org/wiki/Serenity_prayer) to accept the things you cannot change, courage to change the things you can, and wisdom to know the difference. - -By [Klaus Marquardt](http://programmer.97things.oreilly.com/wiki/index.php/Klaus_Marquardt) +۳- اگر هم مجبور به این کار شدید، تا حد ممکن حداقل‌ استانداردهای کدنویسی را رعایت نمایید. به‌عبارت دیگر، اگر گایدلاین‌ها و استانداردهای کدنویسی را گروه‌بندی کنید، می‌توانید در اعمال چنین راه‌کارهایی آن‌دسته از استانداردهایی که به‌مراتب مهم‌تر از بقیه هستند را رعایت نموده و الباقی را نادیده بگیرید. From e4a8eb5479a7cb2ad239d3118dce9a55a66781a8 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 14:59:20 +0300 Subject: [PATCH 202/290] Added number 55 --- fr-IR/thing_55/README.md | 64 ++++++++++++++++++++++++++++++++++------ 1 file changed, 55 insertions(+), 9 deletions(-) diff --git a/fr-IR/thing_55/README.md b/fr-IR/thing_55/README.md index 5a658369..d33e3270 100644 --- a/fr-IR/thing_55/README.md +++ b/fr-IR/thing_55/README.md @@ -1,16 +1,62 @@ -# Make Interfaces Easy to Use Correctly and Hard to Use Incorrectly +# استفادهٔ نادرست از اینترفیس‌ها را غیرممکن سازید -One of the most common tasks in software development is interface specification. Interfaces occur at the highest level of abstraction (user interfaces), at the lowest (function interfaces), and at levels in between (class interfaces, library interfaces, etc.). Regardless of whether you work with end users to specify how they'll interact with a system, collaborate with developers to specify an API, or declare functions private to a class, interface design is an important part of your job. If you do it well, your interfaces will be a pleasure to use and will boost others' productivity. If you do it poorly, your interfaces will be a source of frustration and errors. +در برنامه‌نویسی شیٔ‌گرا به‌خصوص در مبحث Abstraction (انتزاع)، یکی از کارهای رایج ایجاد Interface است؛ اینترفیس‌ها بخشی لاینفک از فرایند کدنویسی حرفه‌ای هستند و این درحالی است که اگر شما به‌عنوان یک دولوپر به‌خوبی از عهدهٔ این‌کار برآیید، از یک سو استفاده از اینترفیس‌ها فرایند کدنویسی را بسیار لذت‌بخش خواهد ساخت و از سوی دیگر، سرعت کدنویسی تک‌تک‌ اعضای تیم افزایش می‌یابد اما درعین‌حال اگر طراحی اینترفیس‌ها به‌درستی صورت نپذیرد، به یک عامل مهم در ایجاد مشکلات پس از پیشروی پروژه مبدل شده و بیش از آن که منجر به سرعت کدنویسی اعضای تیم شود، بیشتر به یک گلوگاه مبدل خواهد شد! -Good interfaces are: +اینترفیس چیست؟ +اگر خیلی غیرفنی بخواهیم توضیح دهیم، در برنامه‌نویسی شیٔ‌گرایی (OOP) منظور از Interface مجموعه فانکشن‌ها و قابلیت‌هایی است که یک آبجکت می‌بایست داشته باشد تا بتواند تسک‌های مورد انتظار را به انجام برساند. حال اگر بخواهیم کمی فنی‌تر صحبت کنیم، منظور از یک اینترفیس، یک Abstract Class (کلاس انتزاعی) است حاوی یکسری فانکشن و دیگر ویژگی‌ها اما این درحالی است که این فانکشن‌ها تسک خاصی را انجام نمی‌دهند بلکه صرفاً مشخص‌کنندهٔ قابلیتی‌ هستند که یک کلاس می‌تواند داشته باشد و این وظیفهٔ کلاس است تا عملکرد خاصی را برای آن فانکشن‌ها تعریف نماید. -- **Easy to use correctly.** People using a well-designed interface almost always use the interface correctly, because that's the path of least resistance. In a GUI, they almost always click on the right icon, button, or menu entry, because it's the obvious and easy thing to do. In an API, they almost always pass the correct parameters with the correct values, because that's what's most natural. With interfaces that are easy to use correctly, *things just work.* -- **Hard to use incorrectly.** Good interfaces anticipate mistakes people might make and make them difficult — ideally impossible — to commit. A GUI might disable or remove commands that make no sense in the current context, for example, or an API might eliminate argument-ordering problems by allowing parameters to be passed in any order. +به‌طورکلی، یک اینترفیس خوب اینترفیسی است که اولاً استفادهٔ درست از آن آسان باشد، ثانیاً استفادهٔ نادرست از آن غیرممکن -یا حداقل مشکل- باشد! -A good way to design interfaces that are easy to use correctly is to exercise them before they exist. Mock up a GUI — possibly on a whiteboard or using index cards on a table — and play with it before any underlying code has been created. Write calls to an API before the functions have been declared. Walk through common use cases and specify how you *want* the interface to behave. What do you *want* to be able to click on? What do you *want* to be able to pass? Easy to use interfaces seem natural, because they let you do what you want to do. You're more likely to come up with such interfaces if you develop them from a user's point of view. (This perspective is one of the strengths of test-first programming.) +استفادهٔ درست از اینترفیس می‌بایست آسان باشد +وقتی اینترفیسی جهان‌شمول و خوب طراحی شده باشد، دولوپرها همواره تمام تلاش خود را به کار می‌گیرند تا از آن استفاده کنند چراکه می‌دانند در آینده کمتر به مشکل برخواهند خورد. -Making interfaces hard to use incorrectly requires two things. First, you must anticipate errors users might make and find ways to prevent them. Second, you must observe how an interface is misused during early release and modify the interface — yes, modify the interface! — to prevent such errors. The best way to prevent incorrect use is to make such use impossible. If users keep wanting to undo an irrevocable action, try to make the action revocable. If they keep passing the wrong value to an API, do your best to modify the API to take the values that users want to pass. +به‌طورمثال، استفاده از اینترفیس‌های اصولی در طراحی API منجر به این خواهد گشت تا دولوپرها همواره مجبور باشند پارامترهای درستی را به‌همراه مقادیر درست به فانکشن‌های مورد استفادهٔ خود پاس دهند. به‌عبارت دیگر، اینترفیس‌هایی که استفاده از آن‌ها آسان است، منجر به انجام طبیعی فرایندهای مورد انتظار از نرم‌افزار می‌شوند. -Above all, remember that interfaces exist for the convenience of their users, not their implementers. +استفادهٔ نادرست از اینترفیس می‌بایست دشوار باشد +اینترفیس‌های خوب و اصولی اشتباهات احتمالی کاربران را پیش‌بینی کرده و بروز چنین اشتباهاتی را غیرممکن -یا حداقل دشوار- می‌سازند. اگر مجدد به مثال API فوق‌الذکر بازگردیم، یک اینترفیس غیراصولی استفاده شده در یک API این امکان را به کاربر می‌دهد تا پارامتری که صرفاً می‌بایست Integer باشد را با هر دیتاتایپی ارسال کند که این اصلاً خوب نیست. -By [Scott Meyers](http://programmer.97things.oreilly.com/wiki/index.php/Scott_Meyers) \ No newline at end of file +چگونه اینترفیس‌هایی طراحی کنیم که استفادهٔ درست از آن‌ها آسان باشد؟ +در پاسخ به سؤال فوق بایستی گفت که یک راه مناسب برای طراحی اینترفیس‌های اصولی این است که پیش از ایجادشان، اقدام به استفاده از آن‌ها نماییم! از آنجا که ممکن است کمی گیج شده باشید، با ذکر مثالی به بررسی این موضوع می‌پردازیم. + +پیش از هر چیز، خود را جای دیگر دولوپرها بگذارید و از نگاه ایشان به فرایند کدنویسی پروژه‌ٔ‌تان نگاه کنید؛ سپس پیش از آن که دست‌به‌کد شوید، سناریوهای مختلف را روی کاغذ نوشته و به بررسی آن‌ها بپردازید. + +به‌عبارت دیگر، اگر فرضاً شما یکی از کاربران APIیی بودید که در طراحی آن از اینترفیسی استفاده شده است، دوست داشتید اینترفیس مدنظر تا چه اندازه دست شما با باز بگذارد تا به ساده‌ترین شکل ممکن بتوانید اقدام به استفاده از آن API نمایید. + +چگونه اینترفیس‌هایی طراحی کنیم که استفادهٔ نادرست از آن‌ها دشوار باشد؟ +برای به‌دست آوردن چنین قابلیتی، می‌بایست ۲ نکته را مدنظر قرار دهیم: اول این که باید ارورهایی که کاربران ممکن است مرتکب شوند را پیش‌بینی کرده و به هر شکلی که شده جلوی آن‌ها را بگیرید و دوم این که در ماه‌های ابتدایی عرضهٔ‌ اینترفیس می‌بایست کاربری‌های اشتباهش را رصد کرده و در صورت بروز کاربری‌های اشتباه، دست به ریفکتور کردن اینترفیس بزنید (مثلاً اگر مشاهده می‌کنید کاربرانی که از اینترفیس شما استفاده می‌کنند بارها‌وبارها اقدام به پاس دادن پارامترهای اشتباه به فانکشن X می‌کنند، سعی کنید کدها را به شکلی ریفکتور کنید که هم‌راستا با نیازهای کاربران باشد و فانکشن X موجب دردسر کاربران نشود). + +مثالی کاربردی از اینترفیس‌ها در زبان برنامه‌نویسی PHP +در زبان برنامه‌نویسی PHP همچون دیگر زبان‌های برنامه‌نویسی، اینترفیس‌ها این امکان را به دولوپر می‌دهند تا ساختاری واحد برای کلاس‌های مورد استفاده در پروژه تعریف کرده و کلیهٔ آبجکت‌ها از ساختاری استاندارد بهره‌مند گردند. علاوه‌بر این، زمانی‌که شما می‌دانید یک کلاس می‌بایست حاوی چه متدهایی باشد اما در مورد جزئیات داخل متدها مطمئن نیستید، استفاده از اینترفیس‌ها لازم می‌گردد. + +در زبان PHP تعریف کردن اینترفیس دقیقاً شبیه‌ به کلاس‌ها است با این تفاوت که به‌جای کلیدواژهٔ class می‌بایست از کلیدواژهٔ interface استفاده نمود و کلاس‌هایی که قرار است از یک اینترفیس بهره‌مند گردند نیز بااستفاده از کلیدواژهٔ implements به چنین قابلیتی دست خواهند یافت. + +در ادامه اینترفیسی خواهیم ساخت به‌نام Car که حاوی ۲ فانکشن انتزاعی تحت‌عناوین ()setModel و ()getModel است: +``` C +interface Car { + public function setModel($name); + + public function getModel(); +} +``` +همان‌طور که می‌بینیم، یکی از فانکشن‌ها شامل یک پارامتر ورودی نیز هست؛ حال کلاسی می‌سازیم تحت‌عنوان MyCar که قرار است حاوی ویژگی‌های انتزاعی اینترفیسی باشد که پیش از این نوشتیم: +``` C +class MyCar implements Car { + private $model; + + public function setModel($name) + { + $this->model = $name; + } + + public function getModel() + { + return $this->model; + } +} +``` +همان‌طور که می‌بینیم، کلاس MyCar بااستفاده از کلیدواژهٔ implements کلیهٔ ویژگی‌های اینترفیس Car را به‌دست آورده است. + +به خاطر داشته باشید وقتی کلاسی از یک اینترفیس implements می‌کند، می‌بایست کلیهٔ فانکشن‌های نوشته شده در اینترفیس در کلاس مدنظر نیز تعریف شوند حتی اگر مورد استفاده قرار نخواهند گرفت که در غیر این‌صورت با ارور مفسر پی‌اچ‌پی مواجه خواهیم شد. +حال اگر بخواهیم کلاس دیگری مثلاً تحت‌عنوان YourCar داشته باشیم، می‌توانیم این کلاس را نیز از اینترفیس Car بهره‌مند گردانده تا این اطمینان حاصل شود که کلیهٔ کلاس‌های مدنظر -همچون MyCar و YourCar و غیره- و بالتبع آبجکت‌های ساخته شده از روی آن‌ها دارای استاندارد واحدی هستند. + +در پایان هم به‌خاطر داشته باشیم که فلسفهٔ وجودی Interface سهولت دولوپرهایی یا کاربرانی است که از آن استفاده می‌کنند نه سهولت دولوپرهایی که اقدام به طراحیش نموده‌اند! From ec7fc44b75b7073953426d1bbc9f64fe01354a7e Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 15:20:15 +0300 Subject: [PATCH 203/290] Added number 56 --- fr-IR/thing_56/README.md | 24 +++++++++++------------- 1 file changed, 11 insertions(+), 13 deletions(-) diff --git a/fr-IR/thing_56/README.md b/fr-IR/thing_56/README.md index 777bf6b5..2de0d19b 100644 --- a/fr-IR/thing_56/README.md +++ b/fr-IR/thing_56/README.md @@ -1,19 +1,17 @@ -# Make the Invisible More Visible +# تا حد ممکن همه‌ چیز را شفاف‌سازی کنید -Many aspects of invisibility are rightly lauded as software principles to uphold. Our terminology is rich in invisibility metaphors — mechanism transparency and information hiding, to name but two. Software and the process of developing it can be, to paraphrase Douglas Adams, *mostly invisible*: +یکی از مشکلاتی که همواره مدیران پروژه و دولوپرها با آن دست‌وپنجه نرم‌ می‌کنند، ددلاین (ضرب‌العجل) هایی است که به حقیقت نمی‌پیوندند! به‌عبارت دیگر، مدیر پروژه قولی را به مشتری می‌دهد که مثلاً پروژه‌ای در تایم مشخصی تکمیل خواهد شد و یا دولوپر به مدیر پروژه قول می‌دهد که فلان ماژول پروژه ظرف مثلاً ۱ هفته به اتمام خواهد رسید اما این درحالی است که هیچ‌کدام از این قول و قرارها به واقعیت تبدیل نمی‌‌شوند! -- Source code has no innate presence, no innate behavior, and doesn't obey the laws of physics. It's visible when you load it into an editor, but close the editor and it's gone. Think about it too long and, like the tree falling down with no one to hear it, you start to wonder if it exists at all. -- A running application has presence and behavior, but reveals nothing of the source code it was built from. Google's home page is pleasingly minimal; the goings on behind it are surely substantial. -- If you're 90% done and endlessly stuck trying to debug your way through the last 10% then you're not 90% done, are you? Fixing bugs is not making progress. You aren't paid to debug. Debugging is waste. It's good to make waste more visible so you can see it for what it is and start thinking about trying not to create it in the first place. -- If your project is apparently on track and one week later it's six months late you have problems, the biggest of which is probably not that it's six months late, but the invisibility force fields powerful enough to hide six months of lateness! Lack of visible progress is synonymous with lack of progress. +یکی از دلایل چنین معضلی این است که روند پیشرفت پروژه شفاف نیست؛ درواقع،‌ وقتی که ما فرایند پیشرفت پروژه را به‌صورت لحظه‌ای رصد کنیم، اگر مشکلات پیش‌رو به اندازه‌ای باشند که ما را از رسیدن به ددلاین مدنظر باز دارند، پیش از آن که بدقول شویم می‌توانیم سیاست دیگری اتخاذ کنیم (مثلاً یا تعداد دولوپرهای پروژه را افزایش دهیم و یا به مذاکره برای گرفتن زمان بیشتر بپردازیم). -Invisibility can be dangerous. You think more clearly when you have something concrete to tie your thinking to. You manage things better when you can see them and see them constantly changing: +به‌طورکلی، بااستفاده از استیک‌نوت‌ها می‌توان فرایند تکمیل پروژه را دائماً در معرض دید خود و سایر اعضای تیم قرار داد بدین شکل که از عناوینی همچون «شروع نشده»، «در دست اقدام» و «تکمیل شده» برای نشان دادن روند انجام کار استفاده کرد. -- Writing unit tests provides evidence about how easy the code unit is to unit test. It helps reveal the presence (or absence) of developmental qualities you'd like the code to exhibit; qualities such as low coupling and high cohesion. -- Running unit tests provides evidence about the code's behavior. It helps reveal the presence (or absence) of runtime of qualities you'd like the application to exhibit; qualities such as robustness and correctness. -- Using bulletin boards and cards makes progress visible and concrete. Tasks can be seen as *Not Started*, *In Progress*, or *Done* without reference to a hidden project management tool and without having to chase programmers for fictional status reports. -- Doing incremental development increases the visibility of development progress (or lack of it) by increasing the frequency of development evidence. Completion of releasable software reveals reality; estimates do not. +شفاف‌سازی فقط در ارتباط با زمان تکمیل پروژه حائز اهمیت نیست بلکه شفاف‌سازی چیزی است که در تمامی مراحل توسعه‌‌ٔ نرم‌افزار می‌بایست مدنظر قرار داده شود که در ادامه به برخی چیزهایی که منجر به شفاف‌تر شدن کار می‌شوند خواهیم پرداخت: -It's best to develop software with plenty of regular visible evidence. Visibility gives confidence that progress is genuine and not an illusion, deliberate and not unintentional, repeatable and not accidental. +- مستندسازی پروژه: نیاز به توضیح نیست که کامنت‌گذاری بخش‌های کلیدی نرم‌افزار امری حیاتی است که درنهایت منجر به شفاف‌تر شدن سورس‌کد می‌شود (البته به‌خاطر داشته باشیم که کامنت‌گذاری بیش از اندازه هم اصلاً کار درستی نیست). -By [Jon Jagger](http://programmer.97things.oreilly.com/wiki/index.php/Jon_Jagger) \ No newline at end of file +- یونیت تست: تست کردن صحت عملکرد نرم‌افزار از طریق Unit Testها چیز دیگری است که منجر به شفاف‌تر شدن پروژه می‌شود؛ به‌عبارت دیگر، یونیت تست‌ به دولوپرها کمک می‌‌کنند تا کاملاً با وابستگی‌های پروژه آشنا شده و درصورت اعمال تغییر در یکی از بخش‌های پروژه، متوجه شوند که کدام‌یک از سایر بخش‌ها نیز دستخوش تغییر خواهند شد. + +- دیپلوی کردن سریع: چنانچه بتوان یک پروژهٔ نرم‌افزاری به را بخش‌های کوچک و مجزا از یکدیگر تقسیم‌بندی نمود و سپس با تکمیل هر بخش آن‌را دیپلوی (منتشر) کرد، به‌طور شفاف می‌توان خروجی کار را دید. + +به‌طورکلی، شفافیت در فرایند توسعه‌ٔ نرم‌افزار بسیار ويژگی خوبی است چراکه درنهایت منجر به بهبود خروجی کار می‌شود؛ وقتی همه‌چیز شفاف، صریح و قابل‌اندازه‌گیری باشد، اعضای تیم هم بهتر تکلیف خود را خواهند دانست و درنهایت پروژه به شکل بهتری به پیش خواهد رفت. From ed1a791563db4c50f0edbf17017c58e1782c12f4 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 15:22:30 +0300 Subject: [PATCH 204/290] Added number 57 --- fr-IR/thing_57/README.md | 29 +++++++++++++++++++---------- 1 file changed, 19 insertions(+), 10 deletions(-) diff --git a/fr-IR/thing_57/README.md b/fr-IR/thing_57/README.md index 74c35ed9..030161c8 100644 --- a/fr-IR/thing_57/README.md +++ b/fr-IR/thing_57/README.md @@ -1,19 +1,28 @@ -# Message Passing Leads to Better Scalability in Parallel Systems +# ضرورت آشنایی با مفاهیم کانکارنسی و پاراللیزم -Programmers are taught from the very outset of their study of computing that concurrency — and especially parallelism, a special subset of concurrency — is hard, that only the very best can ever hope to get it right, and even they get it wrong. There is invariably great focus on threads, semaphores, monitors, and how hard it is to get concurrent access to variables to be thread-safe. +بسیاری از دولوپرها بر این باورند که Concurrency (کانکارنسی یا هم‌زمانی) و Parallelism (پاراللیزم یا موازات) فرایندهای بسیار پیچیده‌ای بوده و فقط حرفه‌ای‌ها می‌توانند به شکل صحیحی آن‌ها را پیاده‌سازی کنند. -True, there are many difficult problems, and they can be very hard to solve. But what is the root of the problem? Shared memory. Almost all the problems of concurrency that people go on and on about relate to the use of shared mutable memory: race conditions, deadlock, livelock, etc. The answer seems obvious: Either forgo concurrency or eschew shared memory! +شاید به‌نوعی بتوان گفت که این دو مفهوم فرایندهای پیچیده‌ای بوده و برای پیاده‌سازی اصولی آن باید باتجربه بود، اما اگر دولوپری بخواهد برچسب حرفه‌ای روی خود بزند، چاره‌ای جز این ندارد که علاوه‌بر آشنایی با این مفاهیم، نحوهٔ پیاده‌سازی آن‌ها در سیستم‌هایی با تعداد پروسس‌های زیاد را هم بلد باشد. -Forgoing concurrency is almost certainly not an option. Computers have more and more cores on an almost quarterly basis, so harnessing true parallelism becomes more and more important. We can no longer rely on ever increasing processor clock speeds to improve application performance. Only by exploiting parallelism will the performance of applications improve. Obviously, not improving performance is an option, but it is unlikely to be acceptable to users. + مفهوم Concurrency چیست؟ +به‌طور خلاصه، بایستی گفت که منظور از کانکارنسی این است که ۲ یا بیش از ۲ تسک به‌صورت هم‌زمان شروع شده، اجرا شوند و درنهایت توسط منابع مشترک -همچون یک پردازنده یا حافظهٔ به اشتراک گذاشته شده- بدون ترتیب خاصی تکمیل گردند. به‌عبارت دیگر، زمانی‌که یک اپلیکیشن قادر به پردازش حداقل ۲ تسک در یک زمان باشد، آن را اپلیکیشنی کانکارنت (Concurrent) می‌نامیم. -So can we eschew shared memory? Definitely. +گرچه به‌نظر می‌رسد که تمامی‌ تسک‌ها به‌صورت موازی درحال اجرا هستند اما در عمل این‌چنین نیست بلکه بدین شکل است که تسک اول شروع شده سپس به حالت انتظار درمی‌آید و منابع به تسک دوم اختصاص می‌یابند و در ادامه سیستم‌عامل هم براساس اولویت تسک‌ها، سی‌پی‌یو و دیگر منابع سیستمی همچون مموری در اختیار تسک‌ها قرار داده تا تکمیل گردند. -Instead of using threads and shared memory as our programming model, we can use processes and message passing. Process here just means a protected independent state with executing code, not necessarily an operating system process. Languages such as Erlang (and occam before it) have shown that processes are a very successful mechanism for programming concurrent and parallel systems. Such systems do not have all the synchronization stresses that shared memory, multi-threaded systems have. Moreover there is a formal model — Communicating Sequential Processes (CSP) — that can be applied as part of the engineering of such systems. +مقهوم Parallelism چیست؟ +درصورتی‌که چندین تسک یا یک تسکی که به چندین بخش تقسیم‌بندی شده و در آن واحد توسط پردازنده‌ای چندهسته‌ای (Multi-Core) هندل شود ما با Parallelism سروکار داریم بدین شکل که هر هسته به یک تسک یا یکی از بخش‌های تسکی که به چندین بخش تقسیم‌بندی شده اختصاص می‌یابد. -We can go further and introduce dataflow systems as a way of computing. In a dataflow system there is no explicitly programmed control flow. Instead a directed graph of operators, connected by data paths, is set up and then data fed into the system. Evaluation is controlled by the readiness of data within the system. Definitely no synchronization problems. +به‌خاطر داشته باشیم که در Parallelism ما به سخت‌افزارهایی با پردازندهٔ چندهسته‌ای نیاز داریم و این درحالی است که اگر پردازده صرفاً یک هسته داشته باشد، کانکارنسی اتفاق خواهد افتاد نه پاراللیزم. -Having said all this, languages such as C, C++, Java, Python, and Groovy are the principal languages of systems development and all of these are presented to programmers as languages for developing shared memory, multi-threaded systems. So what can be done? The answer is to use — or, if they don't exist, create — libraries and frameworks that provide process models and message passing, avoiding all use of shared mutable memory. +تفاوت‌های Concurrency و Parallelism چیست؟ +1 - کانکارنسی زمانی است که حداقل ۲ تسک در بازهٔ زمانی Overlapping (روی‌هم افتاده) شروع، اجرا و تکمیل می‌گردند درحالی‌که پاراللیزم به زمان اطلاق می‌گردد که تسک‌ها به‌معنای واقعی کلمه در آن واحد -مثلاً در یک پردازندهٔ چندهسته‌ای- اجرا می‌شوند. -All in all, not programming with shared memory, but instead using message passing, is likely to be the most successful way of implementing systems that harness the parallelism that is now endemic in computer hardware. Bizarrely perhaps, although processes predate threads as a unit of concurrency, the future seems to be in using threads to implement processes. +2 - کانکارنسی مرتبط با اجرای پروسه‌های مجزا از یکدیگر است درحالی‌که پاراللیزم اجرای هم‌زمان تسک‌های -احتمالاً- مرتبط است. -By [Russel Winder](http://programmer.97things.oreilly.com/wiki/index.php/Russel_Winder) \ No newline at end of file +3 - یک اپلیکیشن می‌تواند کانکارنت باشد اما پارالل نباشد؛ به‌عبارت دیگر، چنین اپلیکیشنی بیش از یک تسک را در آن واحد پردازش می‌کند اما هیچ ۲ تسکی در یک لحظه اجرا نمی‌شوند. + +4 - یک اپلیکیشن می‌تواند پارالل باشد اما کانکارنت نباشد؛ به‌عبارت دیگر، چنین اپلیکیشنی بخش‌های مختلف یک تسک را توسط یک پردازندهٔ چندهسته‌ای در آن واحد پردازش می‌کند. + +5 - یک اپلیکیشن می‌تواند نه پارالل باشد و نه کانکارنت؛ به‌عبارت دیگر، چنین اپلیکیشنی تمامی تسک‌ها را به‌ترتیب یکی پس از دیگری پردازش می‌کند. + +6 - یک اپلیکیشن هم می‌تواند پارالل باشد و هم کانکارنت؛ به‌عبارت دیگر، چنین اپلیکیشنی می‌تواند چندین تسک‌ را به‌صورت هم‌زمان از طریق یک پردازندهٔ چندهسته‌ای در آن واحد پردازش کند. From 0a65a7a3b5e3449b9142911ef18fa3776fc9ca75 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 15:23:17 +0300 Subject: [PATCH 205/290] Modified number 57 --- fr-IR/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fr-IR/SUMMARY.md b/fr-IR/SUMMARY.md index 408ff3c9..b4cde38e 100644 --- a/fr-IR/SUMMARY.md +++ b/fr-IR/SUMMARY.md @@ -57,7 +57,7 @@ 1. [چه‌موقع و چگونه از راه‌کارهای موقتی در کدنویسی استفاده کنیم؟](thing_54/README.md) 1. [سعی کنید Interface ها را طوری بنویسید که برای استفاده ی صحیح آسان باشند و برای استفاده ی ناصحیح سخت!](thing_55/README.md) 1. [موارد نامرئی را بیشتر قابل مشاهده(شفاف سازی) کنید](thing_56/README.md) -1. [رد و بدل کردن مسیج ها منجر به مقیاس پذیری بهتر در سیستم های موازی می شود](thing_57/README.md) +1. [ضرورت آشنایی با مفاهیم کانکارنسی و پاراللیزم](thing_57/README.md) 1. [پیامی به آینده](thing_58/README.md) 1. [فرصت های از دست رفته برای چند ریختی یا Polymorphism](thing_59/README.md) 1. [اخبار عجیب و غریب : تستر دوست شماست!🤣](thing_60/README.md) From 54c7e201dabbc3ce2fe3a2348938ca423f511549 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 15:25:13 +0300 Subject: [PATCH 206/290] Modified number 58 --- fr-IR/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fr-IR/SUMMARY.md b/fr-IR/SUMMARY.md index b4cde38e..69f4b29b 100644 --- a/fr-IR/SUMMARY.md +++ b/fr-IR/SUMMARY.md @@ -58,7 +58,7 @@ 1. [سعی کنید Interface ها را طوری بنویسید که برای استفاده ی صحیح آسان باشند و برای استفاده ی ناصحیح سخت!](thing_55/README.md) 1. [موارد نامرئی را بیشتر قابل مشاهده(شفاف سازی) کنید](thing_56/README.md) 1. [ضرورت آشنایی با مفاهیم کانکارنسی و پاراللیزم](thing_57/README.md) -1. [پیامی به آینده](thing_58/README.md) +1. [یافتن راه‌کارهای ساده برای مشکلات سخت](thing_58/README.md) 1. [فرصت های از دست رفته برای چند ریختی یا Polymorphism](thing_59/README.md) 1. [اخبار عجیب و غریب : تستر دوست شماست!🤣](thing_60/README.md) 1. [یک باینری](thing_61/README.md) From ee39d49975abe24937178e391eb4d7fd2c011a11 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 15:25:22 +0300 Subject: [PATCH 207/290] Added number 58 --- fr-IR/thing_58/README.md | 77 +++++++++++++++++++++++++++++++++------- 1 file changed, 65 insertions(+), 12 deletions(-) diff --git a/fr-IR/thing_58/README.md b/fr-IR/thing_58/README.md index 517f8afe..c43b4643 100644 --- a/fr-IR/thing_58/README.md +++ b/fr-IR/thing_58/README.md @@ -1,23 +1,76 @@ -# A Message to the Future +# یافتن راه‌کارهای ساده برای مشکلات سخت -Maybe it's because most of them are smart people, but in all the years I've taught and worked side-by-side with programmers, it seems that most of them thought that since the problems they were struggling with were difficult that the solutions should be just as difficult for everyone (maybe even for themselves a few months after the code was written) to understand and maintain. +برخی برنامه‌نویسان بر این باورند از آنجا که برخی مشکلات توسعهٔ نرم‌افزار که بسیار چالشی و دشوار هستند را می‌بایست با راه‌کارهای پیچیده مرتفع سازند به‌طوری که اگر سورس‌کد چند ماه پس از کدنویسی در اختیارشان قرار گیرد، به سختی قادر خواهند بود تا اولاً آن‌را درک نموده ثانیاً آن‌را توسعه دهند! برای روشن‌تر شدن این مسأله، قصد داریم مقایسه‌ای مابین حرفه‌ٔ نویسندگی و برنامه‌نویسی داشته باشیم. -I remember one incident with Joe, a student in my data structures class, who had to come in to show me what he'd written. "Betcha can't guess what it does!" he crowed. +در عصر حاضر کدام رمان‌نویس مشهوری را می‌شناسید که در نگارش رمانش از لغات سخت، پیچیده و تاریخ‌گذشته استفاده کند؟ مگر غیر از این است که رمان‌هایی که امروزه در بازار به چاپ صدم و بالاتر می‌رسند همگی از نثری ساده و قابل‌فهم -حتی برای گروه‌های سنی پایین- برخورداند. اصلاً منکر فاخر بودن گلستان سعدی نیستیم، اما بعید به‌نظر می‌رسد که نثر زیر به‌سادگی قابل درک باشد: -"You're right," I agreed without spending too much time on his example and wondering how to get an important message across. "I'm sure you've been working hard on this. I wonder, though, if you haven't forgotten something important. Say, Joe, don't you have a younger brother?" +یاد دارم که در ایام طفلی متعبد بودمی و شب‌خیز و مولع زهد و پرهیز. شبی در خدمت پدر -علیه الرحمه- نشسته بودم و همه شب دیده برهم نبسته و مُصحف عزیز در کنار گرفته و طایفه‌ای گرد ما خفته. پدر را گفتم یکی از اینان سر بر نمی‌دارد که دوگانه‌ای بگذارد و چنان خواب غفلت برده‌اند که گویی نخفته‌اند که مرده‌اند. گفت جان پدر! تو نیز اگر بخفتی به که در پوستین خلق افتی. -"Yep. Sure do! Phil! He's in your Intro class. He's learning to program, too!" Joe announced proudly. +حال به بخشی از کتاب دا نوشته سیده زهرا حسینی تحت‌عنوان «و بالاخره خرمشهر آزاد شد» نگاهی می‌اندازیم: -"That's great," I replied. "I wonder if he could read this code." +بالاخره ساعت ۲، روز سوم خرداد سال 1361 اعلام کردند خرمشهر آزاد شد؛ چه‌کسی می‌توانست حال‌و‌هوای ما را از شنیدن این خبر درک کند. توی ساختمان کوشک ولوله‌ای افتاد، همه یکدیگر را بغل کرده و از خوشحالی گریه می‌کردند. مردم و همسایه‌های تهرانی ما تبریک می‌گفتند؛ همه خوشحال بودند. از خوشحالی نمی‌دانستیم چه‌کار کنیم و رفتیم بیرون ساختمان؛ مردم و کارمندان اداره‌ها همه از شادی این خبر کارشان را رها کرده و به خیابان آمده بودند. همه‌جا پر از هیاهو و سر‌و‌صدا شده بود. همه‌جا شادی موج می‌زد و ... -"No way!" said Joe. "This is hard stuff!" +از مقایسهٔ این ۲ نثر می‌توان به‌ این نتیجه رسید که فارغ از ارزش ادبی هر کدام، نثر برگرفته از کتاب دا به‌مراتب قابل‌فهم‌تر است. به‌ یاد داشته باشیم که یک رمان‌نویس حرفه‌ای می‌داند که خوانندگان از خرید کتابش چند هدف دارند که مهم‌ترین آن‌ها عبارتند از: +- گذران وقت +- آشنایی با تاریخ +- لذت بردن +- ارتباط برقرار گرفتن با داستان +- کسب تجربه +- یادگیری و … -"Just suppose," I suggested, "that this was real working code and that in a few years Phil was hired to make a maintenance update. What have you done for him?" Joe just stared at me blinking. "We know that Phil is really smart, right?" Joe nodded. "And I hate to say it, but I'm pretty smart, too!" Joe grinned. "So if I can't easily understand what you've done here and your very smart younger brother will likely puzzle over this, what does that mean about what you've written?" Joe looked at his code a little differently it seemed to me. "How about this," I suggested in my best 'I'm your friendly mentor' voice, "Think of every line of code you write as a message for someone in the future — someone who might be your younger brother. Pretend you're explaining to this smart person how to solve this tough problem. +حال اگر هریک از پارامترهای فوق -و حتی دیگر ویژگی‌های یک رمان خوب- غايب باشند، احتمال فراگیر شدن رمان در بین خوانندگان کم‌رنگ و کم‌رنگ‌تر خواهد شد. -"Is this what you'd like to imagine? That the smart programmer in the future would see your code and say, 'Wow! This is great! I can understand perfectly what's been done here and I'm amazed at what an elegant — no, wait — what a beautiful piece of code this is. I'm going to show the other folks on my team. This is a masterpiece!' +در صنعت توسعهٔ نرم‌افزار هم دقیقاً با چنین مسأله‌ای روبه‌رو هستیم؛ به‌عبارت دیگر، یک دولوپر کاری شبیه به نویسندگان دارد با این تفاوت که به‌جای نگارش به زبان فارسی -یا دیگر زبان‌ها- با زبان برنامه‌نویسی مدنظرش و با سینتکس خاصی شروع به نوشتن می‌کند. -"Joe, do you think you can write code that solves this difficult problem but will be so beautiful it will sing? Yes, just like a haunting melody. I think that anyone who can come up with the very difficult solution you have here could also write something beautiful. Hmm... I wonder if I should start grading on beauty? What do you think, Joe?" +همان‌طور که یک نویسنده در نگارش یک رمان نباید هرگز دامنهٔ لغات و دستور زبانش را بااستفاده از ساختارهای متکلف و پیچیده به رخ خواننده بکشد، یک برنامه‌نویس خوب هم هرگز نباید آن‌قدر پیچیده کد بزند که در آینده دیگر دولوپرها با سورس‌کد خوانی گیج شوند. -Joe picked up his work and looked at me, a little smile creeping across his face. "I got it, prof, I'm off to make the world better for Phil. Thanks." +حال همان‌طور که ۲ نثر متکلف و ساده را در بالا با یکدیگر مقایسه کردیم، در ادامه قصد داریم برنامه‌ٔ معروف Hello World را به ۲ صورت پیچیده و ساده بااستفاده از زبان ++C بنویسیم؛ ابتدا با برنامه‌ٔ پیچیده شروع می‌کنیم: -By [Linda Rising](http://programmer.97things.oreilly.com/wiki/index.php/Linda_Rising) \ No newline at end of file +``` C +#include < iostream > + + class AbstractHello { + public: + virtual~AbstractHello() { + std::cout << " World!"; + } + void Prnt() { + std::cout << "Hello"; + } + + + }; + +class ChildHello: public AbstractHello { + public: + ~ChildHello() { + Prnt(); + } +}; + +int main() { + ChildHello * Obj; + Obj = new ChildHello; + delete Obj; +} +``` +حال همین برنامه‌ را می‌توان با تعداد خطوط کد کمتر و درعین‌حال قابل‌فهم‌تر به‌صورت زیر نوشت: +``` C +#include < iostream > + +int main() { + std::cout << "Hello World!"; +} +``` +به‌عنوان خروجی هر دو برنامه داریم: +``` +Hello World! +``` +به‌طور خلاصه، یک دولوپر خوب کسی است که کدی بنویسد که از ویژگی‌های زیر برخوردار باشد: +- اسامی کلاس‌ها، فانکشن‌ها، متغیرها و … قابل‌فهم اما درعین‌حال ساده باشند. +- ساختار فولدرها و فایل‌ها همگون و سرراست باشند. +- استاندارد کدنویسی یکسانی در جای‌جای پروژه اعمال شده باشد. +- به‌گونه‌ای کدنویسی کند که به‌جای کامنت‌گذاری، خود سورس‌کد گویای ماهیتش باشد. +- و درنهایت کدنویسی‌اش طوری باشد که اگر یک برنامه‌نویس تازه‌کار هم به مرور سورس‌کد پرداخت، بتواند ارتباط بین اجزای مختلف کد را درک کند. + +هر برنامه‌ای -خواه کوچک باشد و خواه بزرگ- بالاخره روزی توسط دولوپری به غیر از دولوپر اولیه‌اش می‌بایست دیباگ، نگهداری و توسعه داده شود؛ به همین دلیل، در حین کدنویسی همواره این نکته را مدنظر داشته باشید که در آینده بالاخره روزی یکی از همکارانتان قرار است روی کدهایی که نوشته‌اید کار کند پس ضروری است تا به‌گونه‌ای کدنویسی کنید که دیگر دولوپرها تا حد ممکن کمتر دچار سردرگمی‌ شوند. From e8b0a203e95fa6f0a6326f9066d369c3478b7b55 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 15:27:17 +0300 Subject: [PATCH 208/290] Added number 59 --- fr-IR/thing_59/README.md | 83 ++++++++++++++++++++++++---------------- 1 file changed, 49 insertions(+), 34 deletions(-) diff --git a/fr-IR/thing_59/README.md b/fr-IR/thing_59/README.md index 3ffbc3e4..25eb612f 100644 --- a/fr-IR/thing_59/README.md +++ b/fr-IR/thing_59/README.md @@ -1,51 +1,66 @@ -# Missing Opportunities for Polymorphism +# دولوپری که نداند Polymorphism چیست، دولوپر نیست! -Polymorphism is one of the grand ideas that is fundamental to OO. The word, taken from Greek, means many (*poly*) forms (*morph*). In the context of programming polymorphism refers to many forms of a particular class of objects or method. But polymorphism isn't simply about alternate implementations. Used carefully, polymorphism creates tiny localized execution contexts that let us work without the need for verbose *if-then-else* blocks. Being in a context allows us to do the right thing directly, whereas being outside of that context forces us to reconstruct it so that we can then do the right thing. With careful use of alternate implementations, we can capture context that can help us produce less code that is more readable. This is best demonstrated with some code, such as the following (unrealistically) simple shopping cart: +مفهوم Polymorphism (پالیمورفیزم یا چندشکلی) یکی از ستون‌های برنامه‌نویسی شیٔ‌گرایی است؛ این اصلاح ریشهٔ یونانی دارد که از ۲ بخش Poly به‌معنی «چند» و Morph به‌معنی «شکل» تشکیل شده است و این اصطلاح در برنامه‌نویسی شیٔ‌گرایی به الگویی اشاره دارد که بر آن اساس، کلاس‌های مختلف با عملکردهای مجزا از یکدیگر می‌توانند از ساختار و کاربری یکسانی بهره‌مند گردند. -``` -public class ShoppingCart { - private ArrayList cart = new ArrayList(); - public void add(Item item) { cart.add(item); } - public Item takeNext() { return cart.remove(0); } - public boolean isEmpty() { return cart.isEmpty(); } -} -``` +پالیمورفیزم یا چندشکلی در برنامه‌نویسی مفهوم نسبتاً پیچده است که صرفاً با ذکر مثال می‌توان به‌خوبی مفهوم آن را درک کرد؛ لذا در ادامه سعی خواهیم کرد این مفهوم را بااستفاده از زبان PHP تشریح کنیم. -Let's say our webshop offers items that can be downloaded and items that need to be shipped. Let's build another object that supports these operations: +فرض کنیم یکسری کلاس داریم که مسئول ایجاد اشکالی همچون، دایره، مستطیل و … هستند؛ هریک از این اشکال دارای شکل متفاوتی نسبت به بقیه هستند اما همگی در یک چیز مشترک هستند و آن‌هم این که همهٔ اشکال دارای مساحتی هستند که بااستفاده از یک فانکشن می‌توان آن‌را محاسبه کرد. -``` -public class Shipping { - public boolean ship(Item item, SurfaceAddress address) { ... } - public boolean ship(Item item, EMailAddress address) { ... } -} -``` +مثلاً برای این‌کار می‌توان فانکشنی تحت‌عنوان ()calcArea درنظر گرفت که در تمامی کلاس‌ها وجود دارد، اما در کلاس دایره مساحت را به یک شکل (Morph) محاسبه می‌کند و در کلاس مستطیل به شکلی دیگر. -When a client has completed checkout we need to ship the goods: +چگونه پالیمورفیزم را پیاده‌سازی کنیم؟ +به‌منظور پیاده‌سازی این مفهوم در برنامه‌نویسی شیٔ‌گرایی، یا باید از Interfaceها استفاده نمود و یا از کلاس‌های به‌اصطلاح Abstract؛ که در ادامه استفاده از اینترفیس‌ها را با ذکر مثال توضیح خواهیم داد (جهت آشنایی بیشتر با مفهوم اینترفیس، به آموزش نود و هفت چیزی که هر برنامه‌نویسی باید بداند: استفادهٔ نادرست از اینترفیس‌ها را غیرممکن سازید مراجعه نمایید). -``` -while (!cart.isEmpty()) { - shipping.ship(cart.takeNext(), ???); +همان‌طور که در ادامه مشاهده می‌کنید، اینترفیسی داریم تحت‌عنوان Shape که حاوی فانکشنی تحت‌عنوان ()calcArea است و هر کلاسی که از این اینترفیس استفاده کند، باید دارای چنین فانکشنی باشد: +``` C +interface Shape { + public function calcArea(); } -``` +حال اقدام به نوشتن کلاس مربوط به دایره می‌کنیم که اینترفیس فوق‌الذکر روی آن اعمال شده است: -The *???* parameter isn't some new fancy elvis operator, it's asking should I email or snail-mail the item? The context needed to answer this question no longer exists. We have could captured the method of shipment in a boolean or enum and then use an *if-then-else* to fill in the missing parameter. Another solution would be create two classes that both extend Item. Let's call these DownloadableItem and SurfaceItem. Now let's write some code. I'll promote Item to be an interface that supports a single method, ship. To ship the contents of the cart, we will call `item.ship(shipper)`. Classes `DownloadableItem` and `SurfaceItem` will both implement ship. +class Circle implements Shape { + private $radius; -``` -public class DownloadableItem implements Item { - public boolean ship(Shipping shipper) { - shipper.ship(this, customer.getEmailAddress()); + public function __construct($radius) { + $this->radius = $radius; } -} -public class SurfaceItem implements Item { - public boolean ship(Shipping shipper) { - shipper.ship(this, customer.getSurfaceAddress()); + // calcArea calculates the area of circles + public function calcArea() { + return $this->radius * $this->radius * pi(); } } ``` +مجدد دست به ساخت کلاس دیگری این‌بار برای شکل مستطیل می‌زنیم که همانند کلاس مربوط به دایره است با این تفاوت که کدهای قرار گرفته داخل فانکش ()calcArea متفاوت است: +``` C +class Rectangle implements Shape { + private $width; + private $height; -In this example we've delegated the responsibility of working with `Shipping` to each Item. Since each item knows hows it's best shipped, this arrangement allows us to get on with it without the need for an *if-then-else*. The code also demonstrates a use of two patterns that often play well together: Command and Double Dispatch. Effective use of these patterns relies on careful use of polymorphism. When that happens there will be a reduction in the number of *if-then-else* blocks in our code. + public function __construct($width, $height) { + $this->width = $width; + $this->height = $height; + } -While there are cases where it's much more practical to use *if-then-else* instead of polymorphism, it is more often the case that a more polymorphic coding style will yield a smaller, more readable and less fragile code base. The number of missed opportunities is a simple count of the *if-then-else* statements in our code. + // calcArea calculates the area of rectangles + public function calcArea() { + return $this->width * $this->height; + } +} +``` +حال اقدام به ساخت آبجکت‌هایی از روی این ۲ کلاس کرده سپس بااستفاده از فانکشن ()calcArea مساحت شکل را محاسبه می‌کنیم: +``` C +$circ = new Circle(3); +echo $circ->calcArea(); + +$rect = new Rectangle(3, 4); +echo $rect->calcArea(); +``` +خروجی کدهای فوق به‌صورت زیر خواهد بود: +``` +28.274333882308 +12 +``` +در حقیقت، چندشکلی یا پالیمورفیزم این‌گونه تفسیر می‌شود که ما فانکشنی ثابت داریم تحت‌عنوان ()calcArea اما این درحالی است که این فانکشن بسته به این‌که در کدام کلاس قرار گرفته باشد، عملکردی متفاوت از خود نشان خواهد داد و به‌نوعی خود را در چند شکل مختلف عرضه می‌کند. -By [Kirk Pepperdine](http://programmer.97things.oreilly.com/wiki/index.php/Kirk_Pepperdine) +وقتی دلوپرها با این مفهوم در OOP آشنا باشند، به‌سادگی به‌جای استفاده از دستورات شرطی مختلف و یا سوئیچ‌ها به‌منظور هندل کردن شرایط مختلف، می‌توانند با به‌کارگیری از مفاهیم اینترفیس و پالیمورفیزم، شرایط مختلفی که در کدنویسی با آن‌ها مواجه می‌شوند را با نوشتن حداقل میزان کد مدیریت کنند. From 2966a9bd26b07c37e08c672b943569dd95b9c32e Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 15:27:57 +0300 Subject: [PATCH 209/290] Modified number 59 --- fr-IR/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fr-IR/SUMMARY.md b/fr-IR/SUMMARY.md index 69f4b29b..2bc6f4ce 100644 --- a/fr-IR/SUMMARY.md +++ b/fr-IR/SUMMARY.md @@ -59,7 +59,7 @@ 1. [موارد نامرئی را بیشتر قابل مشاهده(شفاف سازی) کنید](thing_56/README.md) 1. [ضرورت آشنایی با مفاهیم کانکارنسی و پاراللیزم](thing_57/README.md) 1. [یافتن راه‌کارهای ساده برای مشکلات سخت](thing_58/README.md) -1. [فرصت های از دست رفته برای چند ریختی یا Polymorphism](thing_59/README.md) +1. [دولوپری که نداند Polymorphism چیست، دولوپر نیست!](thing_59/README.md) 1. [اخبار عجیب و غریب : تستر دوست شماست!🤣](thing_60/README.md) 1. [یک باینری](thing_61/README.md) 1. [فقط کد حقیقت را می گوید](thing_62/README.md) From d7093bfcfa366f8ea2de33fc740756e3ffb7d424 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 15:28:50 +0300 Subject: [PATCH 210/290] Added number 60 --- fr-IR/thing_60/README.md | 19 +++++++++---------- 1 file changed, 9 insertions(+), 10 deletions(-) diff --git a/fr-IR/thing_60/README.md b/fr-IR/thing_60/README.md index 6eca432a..ba047db1 100644 --- a/fr-IR/thing_60/README.md +++ b/fr-IR/thing_60/README.md @@ -1,17 +1,16 @@ -# News of the Weird: Testers Are Your Friends +# تستر‌های نرم‌افزار دشمن دولوپرها نیستند! -Whether they call themselves *Quality Assurance* or *Quality Control*, many programmers call them *Trouble*. In my experience, programmers often have an adversarial relationship with the people who test their software. "They're too picky" and "They want everything perfect" are common complaints. Sound familiar? +کسانی که اقدام به تست نرم‌افزار به‌منظور اطمینان حاصل کردن از صحت عملکردش می‌کنند معمولاً با نام‌هایی همچون Quality Assurance ،Quality Control و یا Tester شناخته می‌شوند اما از دید دولوپرها فرقی نمی‌کند این متخصصین را چه بنامیم چراکه ایشان این گروه از افراد را «معضل» قلمداد می‌کنند! -I'm not sure why, but I've always had a different view of testers. Maybe it's because the "tester" at my first job was the company secretary. Margaret was a very nice lady who kept the office running, and tried to teach a couple of young programmers how to behave professionally in front of customers. She also had a gift for finding any bug, no matter how obscure, in mere moments. +جالب است بدانیم که وقتی در مورد تسترها و یا مسئولین کنترل کیفیت از دولوپرها سؤال می‌کنیم، جملاتی همچون «خیلی گیر هستن»، «بیش از حد مته به خشخاش می‌گذارن» و چیزهایی از این است از زبان ایشان می‌شنویم. -Back then I was working on a program written by an accountant who thought he was a programmer. Needless to say, it had some serious problems. When I thought I had a piece straightened out, Margaret would try to use it and, more often than not, it would fail in some new way after just a few keystrokes. It was at times frustrating and embarrassing, but she was such a pleasant person that I never thought to blame her for making me look bad. Eventually the day came when Margaret was able to cleanly start the program, enter an invoice, print it, and shut it down. I was thrilled. Even better, when we installed it on our customer's machine it all worked. They never saw any problems because Margaret had helped me find and fix them first. +چرا باید به تستترها به شکل یک رفیق نگاه کنیم؟ +ماحصل کار تسترها این است که آبروی ما جلوی مشتری نرود، کارفرما از دست ما شاکی نشود و درنهایت شغل خود را از دست ندهیم! با این تفاسیر، گرچه درظاهر تسترها با ریپورت کردن مشکلات نرم‌افزار ممکن است موجبات ناراحتی دولوپرها را فراهم آورند اما درنهایت این کار تسترها منجر به این خواهد گشت تا دولوپرها حرفه‌ای‌تر جلوه پیدا کنند و از همین روی بهترین رفیق دولوپرها محسوب می‌شوند. -So that's why I say testers are your friends. You may think the testers make you look bad by reporting trivial issues. But when customers are thrilled because they weren't bothered by all those "little things" that QC made you fix, then you look great. See what I mean? +برای روشن‌تر شدن اهمیت این مسأله، مثالی می‌زنیم؛ فرض کنیم شما دولوپری هستید که روی پروژه‌ای مرتبط با هوش مصنوعی کار می‌کنید (یکی از پیچیده‌ترین نمونه نرم‌افزارهایی که در صنعت IT می‌توان پیاده‌سازی کرد). -Imagine this: You're test-driving a utility that uses "ground-breaking artificial intelligence algorithms" to find and fix concurrency problems. You fire it up and immediately notice they misspelled "intelligence" on the splash screen. A little inauspicious, but it's just a typo, right? Then you notice the configuration screen uses check boxes where there should be radio buttons, and some of the keyboard shortcuts don't work. Now, none of these is a big deal, but as the errors add up you begin to wonder about the programmers. If they can't get the simple things right, what are the odds their AI can really find and fix something tricky like concurrency issues? +در ادمین پنل اپلیکیشن، یکسری Typo (تایپو یا غلط املایی) وجود دارد، برخی لینک‌ها به صفحهٔ درستی ارجاع نمی‌دهند و چیزهایی از این است که در مقایسه با باگ‌های ساختاری، اصلاً چیزی به‌حساب نمی‌آیند. -They could be geniuses who were so focused on making the AI insanely great that they didn't notice those trivial things. And without "picky testers" pointing out the problems, you wound up finding them. And now you're questioning the competency of the programmers. +وقتی‌که درحال ارائهٔ دمویی از اپلیکیشن به مشتری هستید، مشتری متوجه مشکلاتی جزئی از این دست می‌شود و اتفاقی که می‌افتد این است که باخود می‌گوید «کسی‌که چیزهایی ابتدایی از این دست رو نتونسته درست کنه، احتمال داره در طراحی الگوریتم‌های هوش مصنوعی، آنالیز داده‌ها و غیره هم بی‌دقتی کرده باشه!». -So as strange as it may sound, those testers who seem determined to expose every little bug in your code really are your friends. - -By [Burk Hufnagel](http://programmer.97things.oreilly.com/wiki/index.php/BurkHufnagel) \ No newline at end of file +به همین سادگی ایماژی منفی از شما در ذهن مشتری یا کارفرما می‌تواند شکل گیرد و این احتمال نیز وجود دارد که ماهیت قرارداد نیز به خطر بیافتد و اینجا است که نقش تسترها اهمیت پیدا می‌کند؛ به‌عبارت دیگر، این گروه از اعضای تیم -که حتی منشی شرکت هم اگر فرد بادقتی باشد می‌تواند به‌نوعی یک تستر خوب محسوب شود- نه‌تنها منجر به این خواهند گشت که آبروی شما نرود، بلکه این کار ایشان درنهایت هم به‌نفع شرکت و هم مشتری خواهد شد. From 28ba4978e7ad45e7605ec7179e2e8c4da5932e9e Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 15:29:48 +0300 Subject: [PATCH 211/290] Modified number 61 --- fr-IR/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fr-IR/SUMMARY.md b/fr-IR/SUMMARY.md index 2bc6f4ce..2f32b379 100644 --- a/fr-IR/SUMMARY.md +++ b/fr-IR/SUMMARY.md @@ -61,7 +61,7 @@ 1. [یافتن راه‌کارهای ساده برای مشکلات سخت](thing_58/README.md) 1. [دولوپری که نداند Polymorphism چیست، دولوپر نیست!](thing_59/README.md) 1. [اخبار عجیب و غریب : تستر دوست شماست!🤣](thing_60/README.md) -1. [یک باینری](thing_61/README.md) +1. [همواره یک نسخه از نرم‌افزار برای ریلیس داشته باشید](thing_61/README.md) 1. [فقط کد حقیقت را می گوید](thing_62/README.md) 1. [صاحب شو و ریفکتور کن!](thing_63/README.md) 1. [Pair Program and Feel the Flow](thing_64/README.md) From b2fa50128bed21f688e6dc6d9117cab51345e59c Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 15:30:10 +0300 Subject: [PATCH 212/290] Added number 61 --- fr-IR/thing_61/README.md | 16 ++++++---------- 1 file changed, 6 insertions(+), 10 deletions(-) diff --git a/fr-IR/thing_61/README.md b/fr-IR/thing_61/README.md index c790bfb5..42ec3ccf 100644 --- a/fr-IR/thing_61/README.md +++ b/fr-IR/thing_61/README.md @@ -1,15 +1,11 @@ -# One Binary +# همواره یک نسخه از نرم‌افزار برای ریلیس داشته باشید -I've seen several projects where the build rewrites some part of the code to generate a custom binary for each target environment. This always makes things more complicated than they should be, and introduces a risk that the team may not have consistent versions on each installation. At a minimum it involves building multiple, near-identical copies of the software, each of which then has to be deployed to the right place. It means more moving parts than necessary, which means more opportunities to make a mistake. +برخی تیم‌های توسعهٔ نرم‌افزار هستند که برای پلتفرم‌های مختلف، خروجی‌های مختلفی از نرم‌افزاری که توسعه داده‌اند می‌گیرند اما این درحالی است که چنین سیاستی صرفاً منجر به پیچیده‌تر شدن کارها می‌شود! -I once worked on a team where every property change had to be checked in for a full build cycle, so the testers were left waiting whenever they needed a minor adjustment (did I mention that the build took too long as well?). I also worked on a team where the system administrators insisted on rebuilding from scratch for production (using the same scripts that we did), which meant that we had no proof that the version in production was the one that had been through testing. And so on. +به‌عبارت دیگر، با چنین کاری تیم توسعه نسخه‌های تقریباً شبیه به همی تولید کرده که هریک از آن‌ها صرفاً در پلتفرم اختصاصی خودش می‌بایست دیپلوی گردد و همین مسأله ضریب خطا را بالا خواهد برد (مثلاً نسخهٔ توسعه‌ داده شده برای پلتفرم A روی پلتفرم B دیپلوی گردد یا بالعکس). -The rule is simple: *Build a single binary that you can identify and promote through all the stages in the release pipeline.* Hold environment-specific details in the environment. This could mean, for example, keeping them in the component container, in a known file, or in the path. +در یک کلام، وقتی دست به توسعهٔ یک نرم‌افزار می‌زنید همواره تمام تلاش خود را به‌کار گیرید تا صرفاً یک نسخهٔ نهایی از نرم‌افزار داشته باشید که از مراحل تست گرفته تا بارگزاری روی سرور اصلی، تمامی کارها روی همان یک نسخه صورت می‌گیرد. -If your team either has a code-mangling build or stores all the target settings with the code, that suggests that no one has thought through the design carefully enough to separate those features which are core to the application and those which are platform-specific. Or it could be worse: The team knows what to do but can't prioritize the effort to make the change. +حال ممکن است این سؤال پیش بیاید که یکسری تفاوت‌های مبتنی بر Environment وجود دارند که بایستی هندل شوند (منظور از Environment، پلتفرمی است که نرم‌افزار قرار است روی آن پیاده‌سازی گردد)؛ در پاسخ به این سؤال بایستی گفت که چنین تفاوت‌هایی را باید داخل همان Environment یا پلتفرم هندل کرد. -Of course, there are exceptions: You might be building for targets that have significantly different resource constraints, but that doesn't apply to the majority of us who are writing "database to screen and back again" applications. Alternatively, you might be living with some legacy mess that's too hard to fix right now. In such cases, you have to move incrementally — but start as soon as possible. - -And one more thing: Keep the environment information versioned too. There's nothing worse than breaking an environment configuration and not being able to figure out what changed. The environmental information should be versioned separately from the code, since they'll change at different rates and for different reasons. Some teams use distributed version control systems for this (such as bazaar and git), since they make it easier to push changes made in production environments — as inevitably happens — back to the repository. - -By [Steve Freeman](http://programmer.97things.oreilly.com/wiki/index.php/Steve_Freeman) \ No newline at end of file +حال ممکن است در زمان طراحی معماری نرم‌افزار آن‌قدر که باید و شاید دقت به‌خرج داده نشده باشد و برخی تنظیمات پیکربندی در سورس‌کد اعمال شده باشد که چنین مسأله‌ای مشکل‌زا خواهد شد؛ برای رفع چنین معضلی، می‌بایست تنظیمات پیکربندی کلی نرم‌افزار در فایلی مثلاً تحت‌عنوان global-config قرار داده شده و تنظیمات مرتبط با پلتفرمی که این نرم‌افزار قرار است روی آن پیاده‌سازی شود در فایلی مثلاً تحت‌عنوان env-config تا به‌سادگی بتوان نرم‌افزار را روی محیط‌های متفاوت به‌کار گرفت. From 1659a2de4c65e9658e8c0e4f39f82e309ff74bd4 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 15:30:48 +0300 Subject: [PATCH 213/290] Added number 62 --- fr-IR/thing_62/README.md | 19 ++++++++++++------- 1 file changed, 12 insertions(+), 7 deletions(-) diff --git a/fr-IR/thing_62/README.md b/fr-IR/thing_62/README.md index 044f6570..b819c29f 100644 --- a/fr-IR/thing_62/README.md +++ b/fr-IR/thing_62/README.md @@ -1,13 +1,18 @@ -# Only the Code Tells the Truth +# فقط سورس‌کد است که حرف اول و آخر را می‌زند -The ultimate semantics of a program is given by the running code. If this is in binary form only, it will be a difficult read! The source code should, however, be available if it is your program, any typical commercial software development, an open source project, or code in a dynamically interpreted language. Looking at the source code, the meaning of the program should be apparent. To know what a program does, the source is ultimately all you can be sure of looking at. Even the most accurate requirements document does not tell the whole truth: It does not contain the detailed story of what the program is actually doing, only the high-level intentions of the requirements analyst. A design document may capture a planned design, but it will lack the necessary detail of the implementation. These documents may be lost sync with the current implementation... or may simply have been lost. Or never written in the first place. The source code may be the only thing left. +سورس‌کد باید آن‌قدر واضح و شفاف باشد که با نگاه کردن به آن، بتوان به ماهیت نرم‌افزار پی برد و این درحالی است که کامل‌ترین مستندات نرم‌افزار هم آن‌طور که بایدوشاید ماهیت نرم‌افزار را روشن نمی‌کنند و در این‌گونه مستندات صرفاً به یکسری کلیات بسنده می‌شود. -With this in mind, ask yourself how clearly is your code telling you or any other programmer what it is doing? +در همین راستا، در حین کدنویسی همواره این سؤال را از خود بپرسید که آیا سورس‌کدتان به‌وضوح کامل چند و چون نرم‌افزار را هم برای خودتان و هم برای دیگر دولوپرها بیان می‌کند؟ -You might say, "Oh, my comments will tell you everything you need to know." But keep in mind that comments are not running code. They can be just as wrong as other forms of documentation. There has been a tradition saying comments are unconditionally a good thing, so unquestioningly some programmers write more and more comments, even restating and explaining trivia already obvious in the code. This is the wrong way to clarify your code. If your code needs comments, consider refactoring it so it doesn't. Lengthy comments can clutter screen space and might even be hidden automatically by your IDE. If you need to explain a change, do so in the version control system check-in message and not in the code. +در پاسخ به این سؤال ممکن است بگویید که کامنت‌های نوشته شده در جای‌جای سورس‌کد اطلاعات مورد نیاز را ارائه خواهند داد اما همواره به‌خاطر داشته باشید از آنجا که کامنت‌ها -همچون دیگر مستندات نرم‌افزار- در اجرای نرم‌افزار نقشی ندارند، می‌توانند حاوی اشتباهاتی باشند که ممکن است دولوپرها را گمراه سازند (این اشتباهات زمانی دوچندان می‌شوند که سورس‌کد ریفکتور شده، چیزی از آن کم شده و یا چیزی به آن افزوده گردیده اما درعین‌حال کامنت مدنظر آپدیت نشده است). -What can you do to actually make your code tell the truth as clearly as possible? Strive for good names. Structure your code with respect to cohesive functionality, which also eases naming. Decouple your code to achieve orthogonality. Write automated tests explaining the intended behavior and check the interfaces. Refactor mercilessly when you learn how to code a simpler, better solution. Make your code as simple as possible to read and understand. +کامنت‌ها اصلاً چیز خوبی برای شفاف‌سازی سورس‌کد نیستند! +اگر کدی که می‌زنید نیاز به کامنت دارد، در اولین فرصت اقدام به ریفکتور کردن کدتان کنید به شکلی که دیگر کد برای نشان دادن ماهیتش نیاز به کامنت نداشته و خود سورس‌کد گویای کاری باشد که قرار است انجام دهد. -Treat your code like any other composition, such as a poem, an essay, a public blog, or an important email. Craft what you express carefully, so that it does what it should and communicates as directly as possible what it is doing, so that it still communicates your intention when you are no longer around. Remember that useful code is used much longer than ever intended. Maintenance programmers will thank you. And, if you are a maintenance programmer and the code you are working on does not tell the truth easily, apply the guidelines above in a proactive manner. Establish some sanity in the code and keep your own sanity. +برای انجام چنین کاری هم صرفاً نیاز به چند تغییر کوچک خواهید داشت؛ از نام‌های مناسب و بامسمی برای کلاس‌ها، فانکشن‌ها، متغیرها و … استفاده کنید. ساختار فولدرها را به‌گونه‌ای بچینید که هارمونی بین بخش‌های مختلف پروژه وجود داشته باشد. کد را به‌گونه‌ای ریفکتور کنید که خواندن آن ساده‌تر گردد و کارهایی از این دست. -by [Peter Sommerlad](http://programmer.97things.oreilly.com/wiki/index.php/Peter_Sommerlad) \ No newline at end of file +همان‌طور که یک شاعر یا نویسنده به‌گونه‌ای اقدام به نوشتن یک شعر یا اثر ادبی می‌کند که سال‌ها پس از انتشار آن اثر -و حتی پس از مرگ پدید آورنده‌اش- بدون نیاز به هیچ‌‌گونه راهنما یا مفسری می‌توان آن اثر را درک کرد‌، یک دولوپر خوب هم به‌گونه‌ای کد می‌زند که خود سورس‌کد می‌تواند با دیگر دولوپرها ارتباط برقرار سازد. + +اگر چنین مواردی در کدنویسی رعایت شوند، زمانی‌که پروژه‌ٔ شما به‌اصطلاح Legacy می‌شود، دعای خیر دولوپرهایی که قرار است چنین پروژه‌ٔ قدیمی را مدیریت کنند همواره پشت‌ سر شما خواهد بود. + +نکته به‌طور‌کلی، منظور از سورس‌کدهای Legacy کدهایی است که خیلی قدیمی هستند و دیگر ساپورت نمی‌شوند. From dcc24d8600625e4892d760acd44b69a87f8275dd Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 15:31:49 +0300 Subject: [PATCH 214/290] Modified number 63 --- fr-IR/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fr-IR/SUMMARY.md b/fr-IR/SUMMARY.md index 2f32b379..ce598eca 100644 --- a/fr-IR/SUMMARY.md +++ b/fr-IR/SUMMARY.md @@ -63,7 +63,7 @@ 1. [اخبار عجیب و غریب : تستر دوست شماست!🤣](thing_60/README.md) 1. [همواره یک نسخه از نرم‌افزار برای ریلیس داشته باشید](thing_61/README.md) 1. [فقط کد حقیقت را می گوید](thing_62/README.md) -1. [صاحب شو و ریفکتور کن!](thing_63/README.md) +1. [فقط کد نزنید بلکه Build Process را نیز مدنظر قرار دهید](thing_63/README.md) 1. [Pair Program and Feel the Flow](thing_64/README.md) 1. [Prefer Domain-Specific Types to Primitive Types](thing_65/README.md) 1. [جلوگیری از خطاها](thing_66/README.md) From 714e05323677257abdc6a93fe9bcc9da5b479bf1 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 15:32:07 +0300 Subject: [PATCH 215/290] Added number 63 --- fr-IR/thing_63/README.md | 17 +++++++---------- 1 file changed, 7 insertions(+), 10 deletions(-) diff --git a/fr-IR/thing_63/README.md b/fr-IR/thing_63/README.md index 714c1e86..6059110c 100644 --- a/fr-IR/thing_63/README.md +++ b/fr-IR/thing_63/README.md @@ -1,15 +1,12 @@ -# Own (and Refactor) the Build +# فقط کد نزنید بلکه Build Process را نیز مدنظر قرار دهید -It is not uncommon for teams that are otherwise highly disciplined about coding practices to neglect build scripts, either out of a belief that they are merely an unimportant detail or from a fear that they are complex and need to be tended to by the cult of release engineering. Unmaintainable build scripts with duplication and errors cause problems of the same magnitude as those in poorly factored code. +دولوپرهایی هستند که تمام تمرکز خود را روی سورس‌کد اصلی نرم‌افزاری که درحال توسعهٔ آن هستند می‌گذارند و این درحالی است که برخی نرم‌افزارها هستند که برای اجرای کامل، نیاز به یکسری اسکرپیت‌های جانبی، پیکربندی‌ها و … دارند که در کنار یکدیگر منجر به ایجاد یک Build می‌شود. -One rationale for why disciplined, skilled developers treat the build as something secondary to their work is that build scripts are often written in a different language than source code. Another is that the build is not really "code." These justifications fly in the face of the reality that most software developers enjoy learning new languages and that the build is what creates executable artifacts for developers and end users to test and run. The code is useless without being built, and the build is what defines the component architecture of the application. The build is an essential part of the development process, and decisions about the build process can make the code and the coding simpler. +نکته در صنعت توسعهٔ نرم‌افزار، منظور از Build فرایندی است که از آن طریق سورس‌کد نرم‌افزار به برنامه‌ای قابل‌اجرا مبدل می‌گردد که به‌تنهایی قابل‌‌استفاده بوده و نتایج قابل‌مشاهده‌ای ارائه می‌دهد. +به‌طورکلی، Build بخشی مهم از فرایند توسعه است و درصورتی‌که این فرایند به درستی پیاده‌سازی نشود، سورس‌کد نرم‌افزار ارزشی نخواهد داشت! همان‌طور که قبلاً گفتیم، برخی نرم‌افزارها برای اجرای صحیح نیاز به یکسری اسکرپیت‌نویسی‌ها دارند که از آن جمله می‌توان به Bash Scripting در لینوکس اشاره کرد. -Build scripts written using the wrong idioms are difficult to maintain and, more significantly, improve. It is worth spending some time to understand the right way to make a change. Bugs can appear when an application is built with the wrong version of a dependency or when a build-time configuration is wrong. +اسکریپت‌نویسی معمولاًً به زبانی به غیر از زبان اصلی دولوپر صورت‌ می‌گیرد و همین مسأله منجر به این خواهد گشت تا دولوپرها خیلی تمایلی به این کار نداشته و این‌گونه اسکریپت‌نویسی‌ها را به دیگر اعضای تیم واگذار کنند! -Traditionally testing has been something that was always left to the "Quality Assurance" team. We now realize that testing as we code is necessary to being able to deliver value predictably. In much the same way, the build process needs to be owned by the development team. +برخی دولوپرها هم بر این باورند که فرایند بیلد کار متخصصین کنترل کیفیت است اما واقعیت امر آن است که در حین کدنویسی،‌ تست نرم‌افزار هم می‌بایست صورت گیرد که با این‌کار هم می‌توان از صحت عملکرد نرم‌افزار اطمینان حاصل کرد و هم هزینه‌های توسعهٔ نرم‌افزار را کاهش داد. در یک کلام، Build Process بخشی از کار دولوپر است نه کسی دیگر! -Understanding the build can simplify the entire development lifecycle and reduce costs. A simple-to-execute build allows a new developer to get started quickly and easily. Automating configuration in the build can enable you to get consistent results when multiple people are working on a project, avoiding an "it works for me" conversation. Many build tools allow you to run reports on code quality, letting you to sense potential problems early. By spending time understanding how to make the build yours, you can help yourself and everyone else on your team. You can focus on coding features, benefiting your stakeholders and making work more enjoyable. - -Learn enough of your build process to know when and how to make changes. Build scripts are code. They are too important to be left to someone else, if for no other reason than because the application is not complete until it is built. The job of programming is not complete until we have delivered working software. - -By [Steve Berczuk](http://programmer.97things.oreilly.com/wiki/index.php/Steve_Berczuk) \ No newline at end of file +به‌طور خلاصه، آنچه دولوپرها می‌بایست همواره مدنظر داشته باشند این است که از آماده‌سازی پلتفرمی که نرم‌افزار قرار است روی آن اجرا شود تا پیکربندی و اسکریپت‌نویسی و غیره جزو وظایف یک دولوپر است که درنهایت منجر به این خواهد گشت که نرم‌افزار به‌طور کامل و بدون هیچ‌گونه نقصی اجرا گردد. From ab65dcb5209603069e08ac2e90b409a47832bdff Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 15:33:04 +0300 Subject: [PATCH 216/290] Added number 64 --- fr-IR/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fr-IR/SUMMARY.md b/fr-IR/SUMMARY.md index ce598eca..7b43f569 100644 --- a/fr-IR/SUMMARY.md +++ b/fr-IR/SUMMARY.md @@ -64,7 +64,7 @@ 1. [همواره یک نسخه از نرم‌افزار برای ریلیس داشته باشید](thing_61/README.md) 1. [فقط کد حقیقت را می گوید](thing_62/README.md) 1. [فقط کد نزنید بلکه Build Process را نیز مدنظر قرار دهید](thing_63/README.md) -1. [Pair Program and Feel the Flow](thing_64/README.md) +1. [اهمیت برنامه‌نویسی دونفره](thing_64/README.md) 1. [Prefer Domain-Specific Types to Primitive Types](thing_65/README.md) 1. [جلوگیری از خطاها](thing_66/README.md) 1. [برنامه نویس حرفه ای](thing_67/README.md) From 26abea252d6dfa41399edab1f0564704da7263cc Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 15:33:25 +0300 Subject: [PATCH 217/290] Added number 64 --- fr-IR/thing_64/README.md | 26 ++++++++------------------ 1 file changed, 8 insertions(+), 18 deletions(-) diff --git a/fr-IR/thing_64/README.md b/fr-IR/thing_64/README.md index 49c9f6e7..2571875c 100644 --- a/fr-IR/thing_64/README.md +++ b/fr-IR/thing_64/README.md @@ -1,25 +1,15 @@ -# Pair Program and Feel the Flow +# اهمیت برنامه‌نویسی دونفره -Imagine that you are totally absorbed by what you are doing — focused, dedicated, and involved. You may have lost track of time. You probably feel happy. You are experiencing flow. It is difficult to both achieve and maintain flow for a whole team of developers since there are so many interruptions, interactions, and other distractions that can easily break it. +یکی از چیزهایی که باعث ارتقاء تیم‌های برنامه‌نویسی می‌شود، Pair Programming یا «برنامه‌نویسی دونفره» است؛ اگر شما برنامه‌نویس تازه‌کاری هستید که زیردست یک برنامه‌نویس ارشد هستید، می‌بایست به‌معنای واقعی کلمه صبور بوده و از مواجهه با دولوپرهای باتجربه‌تر از خود ترس به دلتان راه ندهید چراکه ایشان به‌منزلهٔ منبع ارزشمندی از اطلاعات هستند که چیزهای بسیاری از آن‌ها می‌توانید یاد بگیرید. -If you have already practiced pair programming, you are probably familiar with how pairing contributes to flow. If you have not, we want to use our experiences to motivate you to start right now! To succeed with pair programming both individual team members and the team as a whole have to put in some effort. +برنامه‌نویسی دونفره در تیم‌های نرم‌افزاری کمک به انتقال دانش مابین اعضای تیم می‌کند گرچه درظاهر ممکن است به‌نوعی اتلاف وقت تلقی گردد. برنامه‌نویسی دونفره مزایای بسیاری دارا است که در ادامه برخی از مهم‌ترین آن‌ها را برخواهیم شمرد: -As a team member, be patient with developers less experienced than you. Confront your fears about being intimidated by more skilled developers. Realize that people are different, and value it. Be aware of your own strengths and weaknesses, as well as those of other team members. You may be surprised how much you can learn from your colleagues. +- برخی پروژه‌ها هستند که وابسته به یک دولوپر یا گروه خاصی از دولوپرها هستند و این درحالی است که اگر ایشان حضور نداشته باشند، روند پیشرفت پروژه نیز متوقف خواهد شد اما اگر برنامه‌نویسی دونفره در تیم توسعهٔ نرم‌افزار به‌کار گرفته شده باشد، همواره این امکان وجود دارد تا دیگر دولوپرها نیز بتوانند پروژه‌ای نیمه‌کاره را تکمیل نمایند. -As a team, introduce pair programming to promote distribution of skills and knowledge throughout the project. You should solve your tasks in pairs and rotate pairs and tasks frequently. Agree upon a rule of rotation. Put the rule aside or adjust it when necessary. Our experience is that you do not necessarily need to complete a task before rotating it to another pair. Interrupting a task to pass it to another pair may sound counterintuitive, but we have found that it works. +- وقتی تیم‌های توسعهٔ نرم‌افزار در پیاده‌سازی پروژه‌های مختلف از برنامه‌نویسی دونفره کمک بگیرند، چالش‌های پیش‌روی ایشان همواره سریع‌تر مرتفع می‌گردند چراکه مشکلات مابین اعضای مختلف تیم پخش شده و ممکن است هرکسی ایده‌ای منحصربه‌فرد برای رفع آن در ذهن داشته باشد و این درحالی است که اگر دولوپری به‌تنهایی قصد داشته باشد مشکلی را رفع کند، از دریافت ایده‌های سایر همکاران محروم خواهد شد. -There are numerous situations where flow can be broken, but where pair programming helps you keep it: +- همواره یکی از چالش‌های دولوپرهایی که قرار است روی پروژه‌ٔ سایر همکاران کار کنند، نامگذاری کلاس‌ها، فانکشن‌ها، متغیرها و … است اما اگر برنامه‌نویسی دونفره به شکلی اصولی به‌کار گرفته شود، این مشکل نیز تا حد قابل‌توجهی مرتفع خواهد شد زیرا تمامی دولوپرها روی بخش‌های مختلف پروژه اشراف داشته، با نحوهٔ نامگذاری دیگر همکاران آشنا بوده و درصورت بروز مشکل، می‌توانند روی کمک یکدیگر حساب کنند. -- **Reduce the "truck factor":** It's a slightly morbid thought experiment, but how many of your team members would have to be hit by a truck before the team became unable to complete the final deliverable? In other words, how dependent is your delivery on certain team members? Is knowledge privileged or shared? If you have been rotating tasks among pairs, there is always someone else who has the knowledge and can complete the work. Your team's flow is not as affected by the "truck factor." +- وقتی در تیمی از دولوپرها برنامه‌نویسی دونفره به‌کار گرفته شده باشد، دولوپرها دیگر نگران ددلاین‌های پروژه و عدم توانایی برای گرفتن مرخصی برای رسیدگی به‌ کارهای شخصی نخواهند بود چراکه دیگر اعضای تیم به‌سادگی قادر خواهند بود تا ادامهٔ پروژه را با همان سبک کدنویسی دولوپر سابق ادامه دهند. -- **Solve problems effectively:** If you are pair programming and you run into a challenging problem, you always have someone to discuss it with. Such dialog is more likely to open up possibilities than if you are stuck by yourself. As the work rotates, your solution will be revisited and reconsidered by the next pair, so it does not matter if you did not choose the optimal solution initially. - -- **Integrate smoothly:** If your current task involves calling another piece of code, you hope the names of the methods, the docs, and the tests are descriptive enough to give you a grasp of what it does. If not, pairing with a developer who was involved in writing that code will give you better overview and faster integration into your own code. Additionally, you can use the discussion as an opportunity to improve the naming, docs, and testing. - -- **Mitigate interruptions:** If someone comes over to ask you a question, or your phone rings, or you have to answer an urgent email, or you have to attend a meeting, your pair programming partner can keep on coding. When you return your partner is still in the flow and you will quickly catch up and rejoin them. - -- **Bring new team members up to speed quickly:** With pair programming, and a suitable rotation of pairs and tasks, newcomers quickly get to know both the code and the other team members. - -Flow makes you incredibly productive. But it is also vulnerable. Do what you can to get it, and hold on to it when you've got it! - -By [Gudny Hauknes](http://programmer.97things.oreilly.com/wiki/index.php/Gudny_Hauknes), [Ann Katrin Gagnat](http://programmer.97things.oreilly.com/wiki/index.php/Ann_Katrin_Gagnat), and Kari Røssland \ No newline at end of file +- در تیم‌های توسعهٔ نرم‌افزار همواره این احتمال وجود دارد که یکسری دولوپر جدید به تیم اضافه شده و یکسری دولوپر قدیمی تیم را ترک کنند و این درحالی است که اگر برنامه‌نویسی دونفره مابین اعضای تیم صورت گیرد، چالش‌های این آمدن و رفتن‌ها به حداقل خواهد رسید چراکه تک‌تک اعضای تیم با پروژه‌های مختلف آشنا شده و کسانی که تازه‌وارد هستند خیلی سریع با چند و چون پروژه‌ها آشنا شده و بالتبع با رفتن برخی دولوپرها، تازه‌واردها می‌توانند جای ایشان را با حداقل چالش پر کنند. From f712dc3d6c0833502fb29dc5b7fbb57035f0efbe Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 15:33:50 +0300 Subject: [PATCH 218/290] Added number 65 --- fr-IR/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fr-IR/SUMMARY.md b/fr-IR/SUMMARY.md index 7b43f569..a9c9b708 100644 --- a/fr-IR/SUMMARY.md +++ b/fr-IR/SUMMARY.md @@ -65,7 +65,7 @@ 1. [فقط کد حقیقت را می گوید](thing_62/README.md) 1. [فقط کد نزنید بلکه Build Process را نیز مدنظر قرار دهید](thing_63/README.md) 1. [اهمیت برنامه‌نویسی دونفره](thing_64/README.md) -1. [Prefer Domain-Specific Types to Primitive Types](thing_65/README.md) +1. [آشنایی با تفاوت Static Typing و Dynamic Typing در برنامه‌نویسی](thing_65/README.md) 1. [جلوگیری از خطاها](thing_66/README.md) 1. [برنامه نویس حرفه ای](thing_67/README.md) 1. [همه چیز را روی سییستم های کنترل نسخه قرار بدهید](thing_68/README.md) From c2797619d9cfa4cd989926b1934ff372ac635625 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 15:34:53 +0300 Subject: [PATCH 219/290] Added number 65 --- fr-IR/thing_65/README.md | 38 +++++++++++++++----------------------- 1 file changed, 15 insertions(+), 23 deletions(-) diff --git a/fr-IR/thing_65/README.md b/fr-IR/thing_65/README.md index 0bb9df7d..7be13cce 100644 --- a/fr-IR/thing_65/README.md +++ b/fr-IR/thing_65/README.md @@ -1,31 +1,23 @@ -# Prefer Domain-Specific Types to Primitive Types +# آشنایی با تفاوت Static Typing و Dynamic Typing در برنامه‌نویسی -On 23rd September 1999 the $327.6 million Mars Climate Orbiter was lost while entering orbit around Mars due to a software error back on Earth. The error was later called the *metric mix-up*. The ground station software was working in pounds while the spacecraft expected newtons, leading the ground station to underestimate the power of the spacecraft's thrusters by a factor of 4.45. - -This is one of many examples of software failures that could have been prevented if stronger and more domain-specific typing had been applied. It is also an example of the rationale behind many features in the Ada language, one of whose primary design goals was to implement embedded safety-critical software. Ada has strong typing with static checking for both primitive types and user-defined types: +پیش از هرچیز، به این نکته توجه داشته باشیم که در اینجا منظور از Type، نوع داده‌ای است که با آن سرورکار خواهیم داشت. به‌طورکلی، زبانی که به‌اصطلاح Statically Typed است در آن نوع متغیرها در زمان کامپایل شدن (Compile Time) برنامه‌ مشخص می‌گردد که از آن جمله می‌توان به زبان‌های جاوا، اسکالا، سی‌شارپ، سی و سی‌پلاس‌پلاس اشاره کرد و همین مسأله منجر به این خواهد گشت که پرفورمنس برنامه بالا رود چراکه هر دفعه که برنامه اجرا می‌گردد، دیگر نیازی به چک کردن نوع متغیرها نخواهد بود (لازم به‌ذکر است که این فیچر به‌عنوان یکی از برگ‌برنده‌های زبان‌هایی از این دست است). +علاوه‌بر این، در این نوع زبان‌ها زمانی‌‌که دولوپر تایپی را برای یک متغیر درنظر می‌گیرد، دیگر قادر به تغییر آن نخواهد بود چراکه در این نوع زبان‌ها تایپ به متغیر اختصاص می‌یابد نه مقدار درنظر گرفته شده برای آن متغیر و درصورتی‌که تغییر تایپ صورت گیرد، با اکسپشن مواجه خواهیم شد. به‌عنوان نمونه در زبان جاوا داریم: ``` -type Velocity_In_Knots is new Float range 0.0 .. 500.00; - -type Distance_In_Nautical_Miles is new Float range 0.0 .. 3000.00; - -Velocity: Velocity_In_Knots; - -Distance: Distance_In_Nautical_Miles; - -Some_Number: Float; - -Some_Number:= Distance + Velocity; -- Will be caught by the compiler as a type error. +String str = "Hello World"; +str = 7; ``` +همان‌طور که در کد فوق ملاحظه می‌شود، ابتدا متغیری از جنس String با مقدار Hello World ایجاد کرده‌ایم که در این صورت برنامه بدون هیچ مشکلی کامپایل خواهد شد اما در خط دوم، مجدد مقدار این متغیر را برابر با یک عدد صحیح درنظر گرفته‌ایم و از آنجا که تایپ عدد صحیح با تایپ استرینگ متفاوت است، در حین کامپایل شدن برنامه با اکسپشن مواجه خواهیم شد. -Developers in less demanding domains might also benefit from applying more domain-specific typing, where they might otherwise continue to use the primitive data types offered by the language and its libraries, such as strings and floats. In Java, C++, Python, and other modern languages the abstract data type is known as class. Using classes such as `Velocity_In_Knots` and `Distance_In_Nautical_Miles` adds a lot of value with respect to code quality: - -- The code becomes more readable as it expresses concepts of a domain, not just Float or String. -- The code becomes more testable as the code encapsulates behavior that is easily testable. -- The code facilitates reuse across applications and systems. +یکی از خوبی‌های این نوع زبان‌ها این است که چک کردن برنامه توسط کامپایلر و در حین فرایند کامپایل شدن صورت می‌گیرد و بنابراین باگ‌های جزئی که ممکن است از دید پنهان بمانند خیلی زود یافت خواهند شد. -The approach is equally valid for users of both statically and dynamically typed languages. The only difference is that developers using statically typed languages get some help from the compiler while those embracing dynamically typed languages are more likely to rely on their unit tests. The style of checking may be different, but the motivation and style of expression is not. +زبانی هم که به‌اصطلاح Dynamically Typed است در آن نوع متغیرها در حین اجرای برنامه‌ (Run Time) مشخص می‌شود و دولوپر در حین کدنویسی نیازی به مشخص کردن دیتاتایپ‌ متغیر نخواهد داشت که از آن جمله می‌توان به زبان‌های پایتون، جاوااسکریپت و پی‌اچ‌پی اشاره کرد. -The moral is to start exploring domain-specific types for the purpose of developing quality software. +علاوه‌بر این، در این نوع زبان‌ها پس از آن که تایپی برای یک متغیر درنظر گرفته شد، مجدد می‌توان تایپ آن متغیر را تغییر داد چراکه در این نوع زبان‌ها، دیتاتایپ به مقادیر متغیرها بر‌می‌گردد نه خود آن‌ها؛ به‌عنوان‌مثال، در زبان پی‌اچ‌پی داریم: +``` +$str = "Hello World"; +$str = 7; +``` +می‌بینیم که در خط اول متغیری تحت‌عنوان str$ ساخته‌ایم که حاوی مقدار Hello World است و در خط دوم هم این مقدار که پیش از این استرینگ بود را به یک عدد صحیح (Integer) تغییر داده و برنامه هم بدون هیچ مشکلی اجرا خواهد شد. -By [Einar Landre](http://programmer.97things.oreilly.com/wiki/index.php/Einar_Landre) +به خاطر داشته باشید باتوجه به‌ این که در زبان‌های Dynamically Typed چک کردن دیتاتایپ‌ها در حین اجرا صورت می‌گیرد، برنامه‌های نوشته شده با این زبان‌ها تاحدودی مشکل پرفورمنسی دارند چراکه هردفعه در حین اجرا، فرایند چک کردن دیتاتایپ‌ها می‌بایست صورت گیرد. From 80670f2f740c6191f0c2e4f8e8c54dc39b63c341 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 15:35:45 +0300 Subject: [PATCH 220/290] Added number 66 --- fr-IR/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fr-IR/SUMMARY.md b/fr-IR/SUMMARY.md index a9c9b708..f7b968c7 100644 --- a/fr-IR/SUMMARY.md +++ b/fr-IR/SUMMARY.md @@ -66,7 +66,7 @@ 1. [فقط کد نزنید بلکه Build Process را نیز مدنظر قرار دهید](thing_63/README.md) 1. [اهمیت برنامه‌نویسی دونفره](thing_64/README.md) 1. [آشنایی با تفاوت Static Typing و Dynamic Typing در برنامه‌نویسی](thing_65/README.md) -1. [جلوگیری از خطاها](thing_66/README.md) +1. [تا حد ممکن از نمایش ارورها برای کاربر اجتناب کنید!ا](thing_66/README.md) 1. [برنامه نویس حرفه ای](thing_67/README.md) 1. [همه چیز را روی سییستم های کنترل نسخه قرار بدهید](thing_68/README.md) 1. [ماوس را زمین بگذارید و از صفحه کلید فاصله بگیرید!](thing_69/README.md) From e562f535e5affcaa7cfd57c741742a53a24ecd60 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 15:36:04 +0300 Subject: [PATCH 221/290] Added number 66 --- fr-IR/thing_66/README.md | 28 ++++++++++++---------------- 1 file changed, 12 insertions(+), 16 deletions(-) diff --git a/fr-IR/thing_66/README.md b/fr-IR/thing_66/README.md index 990100ef..852bcc44 100644 --- a/fr-IR/thing_66/README.md +++ b/fr-IR/thing_66/README.md @@ -1,27 +1,23 @@ -# Prevent Errors +# تا حد ممکن از نمایش ارورها برای کاربر اجتناب کنید! -Error messages are the most critical interactions between the user and the rest of the system. They happen when communication between the user and the system is near breaking point. +پیام‌های خطا (Error Messages) یکی از رایج‌ترین راه‌های ارتباطی کاربران با سیستم پیش‌رویشان است و درواقع این پیام‌‌ها خبر از اتفاقی غیرمنتظره می‌دهند. -It is easy to think of an error as being caused by a wrong input from the user. But people make mistakes in predictable, systematic ways. So it is possible to 'debug' the communication between the user and the rest of the system just as you would between other system components. +آنچه در ارتباط با تعامل کاربران با یک سیستم نرم‌افزاری می‌بایست همواره مدنظر قرار داد این است که کاربران معمولاً به شکلی سیستماتیک و قابل‌پیش‌بینی منجر به ایجاد ارورها می‌شوند (به‌طورمثال، وارد کردن یک ورودی غیر عددی در فیلدی که صرفاً عدد می‌گیرد). از همین روی، به دلیل قابل‌پیش‌بینی بودن این نوع تعامل، به‌سادگی قادر خواهیم بود همان‌طور که سایر بخش‌های سیستم را دیباگ می‌کنیم، دست به دیباگ کردن نحوهٔ تعامل کاربران با سیستم نیز بزنیم. -For instance, say you want the user to enter a date within an allowed range. Rather than letting the user enter any date, it is better to offer a device such as a list or calendar showing only the allowed dates. This eliminates any chance of the user entering a date outside of the range. +برای روشن‌تر شدن این مسأله، مثالی می‌زنیم؛ فرض کنیم یک فیلد ورودی داریم که صرفاً مخصوص دریافت تاریخ است آن‌هم در یک بازهٔ خاص؛ در چنین شرایطی، به‌جای آن که به کاربر اجازه دهیم تا هر تاریخی را وارد کند، به‌سادگی می‌توانیم طیفی از تاریخ‌هایی که مجاز هستند را درمعرض دیدش قرار داده تا وی یکی از آن‌ها را انتخاب کند. چنین کاری احتمال آن‌که کاربر تاریخی خارج از طیف مدنظر را وارد سازد کاهش داده و همین مسأله منجر به ایجاد تجربهٔ کاربری به‌مراتب بهتری می‌گردد. -Formatting errors are another common problem. For instance, if a user is presented with a Date text field and enters an unambiguous date such as "July 29, 2012" it is unreasonable to reject it simply because it is not in a preferred format (such as "DD/MM/YYYY"). It is worse still to reject "29 / 07 / 2012" because it contains extra spaces — this kind of problem is particularly hard for users to understand as the date appears to be in the desired format. +علاوه‌بر این، گاهی‌اوقات تنبلی دولوپرها هم منجر به سختی کشیدن بیشتر کاربران درحین استفاده از اپلیکیشن می‌شود. برای روشن‌تر شدن این مسأله، مجدد به مثال فوق بازمی‌گردیم؛ وقتی که کاربران با فیلدی که برای درج تاریخ درمعرض دیدشان قرار می‌گیرند مواجه می‌شوند، ممکن است تاریخ مدنظر خود را به‌صورت مثلاً 14-12-1390 وارد کنند اما این درحالی است که پس از ارسال دیتا برای سرور، صرفاً فرمتی همچون ۱۳۹۰/۱۲/۱۴ قابل‌قبول است و دادهٔ ورودی کاربر غیرقابل‌قبول تلقی می‌گردد. -This error occurs because it is easier to reject the date than parse the three or four most common date formats. These kind of petty errors lead to user frustration, which in turn lead to additional errors as the user loses concentration. Instead, respect users' preference to enter information, not data. +در چنین شرایطی، دولوپرها ۲ راه‌کار پیش‌رو دارند؛ راه‌کار اول این که انواع فرمت‌هایی که کاربر می‌تواند وارد کند را تفسیر کرده و در دیتابیس ذخیره سازند (مثلاً فرمت‌هایی همچون 14-12-1390 یا ۱۳۹۰/۱۲/۱۴ یا حتی بااستفاده از اسپیس و به‌صورت 14 12 1390) و راه‌کار دوم این که صرفاً یک فرمت را مدنظر قرار داده و اگر کاربری چیزی به غیر از آن‌را وارد ساخت، خیلی ساده یک پیام خطا درمعرض دیدش قرار دهند. -Another way of avoiding formatting errors is to offer cues — for instance, with a label within the field showing the desired format ("DD/MM/YYYY"). Another cue might be to divide the field into three text boxes of two, two, and four characters. +از آنجا که راه‌کار دوم بار کدنویسی کمتری روی دولوپر دارا است، اکثر دولوپرها چنین راه‌کاری را انتخاب می‌کنند غافل از این‌که انتخاب چنین رویکردی باعث سردرگمی بیشتر کاربران می‌شود! -Cues are different from instructions: Cues tend to be hints; instructions are verbose. Cues occur at the point of interaction; instructions appear before the point of interaction. Cues provide context; instructions dictate use. +حال اگر هم راه‌کار دوم مدنظر دولوپر باشد، بازهم راه‌کارهایی برای به حداقل رساندن خطاها از طرف کاربران وجود دارد؛ مثلاً به‌سادگی می‌توان لیبل‌هایی حاوی متنی مرتبط با فرمت مدنظر درمعرض دید کاربر قرار داد و یا ۳ فیلد مجزا یکی برای سال، یکی برای ماه و دیگری برای روز با لیبل‌های گویا و مشخص درنظر گرفت تا احتمال خطا را به حداقل رساند. -In general, instructions are ineffective at preventing error. Users tend to assume that interfaces will work in line with their past experience ("Surely everyone knows what 'July 29, 2012' means?"). So instructions go unread. Cues nudge users away from errors. +به‌طورکلی، برخی دولوپرها هستند که دستورالعمل‌هایی برای نحوهٔ تعامل کاربر با اپلیکیشن درنظر می‌گیرند اما این درحالی است که بسیاری از این دستورالعمل‌های توسط کاربران اصلاً خوانده نمی‌شوند چراکه کاربران یا حوصلهٔ مطالعهٔ چنین دستورالعمل‌هایی را ندارند و یا فرض را بر این می‌گذارند که نحوهٔ تعامل با سیستم -باتوجه به تجربیات گذشتهٔ خود در تعامل با سرویس‌هایی مشابه- را بلد هستند. -Another way of avoiding errors is to offer defaults. For instance, users typically enter values that correspond to *today*, *tomorrow*, *my birthday*, *my deadline*, or *the date I entered last time I used this form*. Depending on context, one of these is likely to be a good choice as a smart default. +در همین راستا، توصیه می‌شود که به‌جای استفاده از دستورالعمل‌های نحوهٔ استفاده از یک سرویس، اصطلاحاً Hint در اختیار کاربران قرار گیرد. درواقع، تفاوت Hint (به‌معنی ایما، تذکر و اشاره) با Instruction (دستورالعمل) در این است که دستورالعمل‌ها همواره پیش از تعامل کاربر با سیستم در قالب یک پاپ‌آپ، پیام، باکس و … درمعرض دیدش قرار می‌گیرد اما این درحالی است که هینت‌ها درحین تعامل کاربر با سیستم چیزی را به وی گوشزد می‌کنند و به همین دلیل هم هست که اثربخش‌تر هستند (مثلاً وقتی که در یکی از فیلدهای فرمی کلیک می‌کنیم و پیامی درمعرض دیدمان قرار می‌گیرد، این پیام نوعی Hint است). -Whatever the cause, systems should be tolerant of errors. You can do this by providing multiple levels of *undo* to all actions — and in particular actions which have the potential to destroy or amend users' data. +راه‌کار دیگری که برای جلوگیری از وقوع ارورها می‌توان اتخاذ کرد این است که مثلاً در فیلدهای یک فرم از مقادیر دیفات (پیش‌فرض) استفاده کرد؛ در همان مثال فیلد مرتبط با تاریخ، می‌توان تاریخ روز را به‌صورت مقدار پیش‌فرض درنظر گرفت و این درحالی است که اگر تاریخ مدنظر کاربر تاریخ همان روز باشد که آن‌را دست‌نخورده باقی می‌گذارد و در غیر این صورت، می‌داند که فرمت مدنظر سیستم چیست و چگونه دیتا را می‌بایست وارد کند. -Logging and analyzing *undo* actions can also highlight where the interface is drawing users into unconscious errors, such as persistently clicking on the 'wrong' button. These errors are often caused by misleading cues or interaction sequences that you can redesign to prevent further error. - -Whichever approach you take, most errors are systematic — the result of misunderstandings between the user and the software. Understanding how users think, interpret information, make decisions, and input data will help you debug the interactions between your software and your users. - -by [Giles Colborne](http://programmer.97things.oreilly.com/wiki/index.php/Giles_Colborne) \ No newline at end of file +به‌طورکلی، دولوپرها پیش از هرچیز می‌بایست به این درک برسند که کاربران هدفشان چگونه فکر می‌کنند و بر همین اساس هم سیستم را مطابق به نحوهٔ فکر کردن اکثر کاربران هدف طراحی کنند و همین مسأله منجر به بروز پیام‌های خطای کمتر و درنتیجه تجربهٔ کاربری بهتر از جانب کاربران می‌گردد. From a09fa57da4e0f1b66dc99f39d4c5d51957c3e05e Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 15:36:50 +0300 Subject: [PATCH 222/290] Added number 67 --- fr-IR/thing_67/README.md | 20 ++++++++------------ 1 file changed, 8 insertions(+), 12 deletions(-) diff --git a/fr-IR/thing_67/README.md b/fr-IR/thing_67/README.md index 6260202a..1368d6f0 100644 --- a/fr-IR/thing_67/README.md +++ b/fr-IR/thing_67/README.md @@ -1,19 +1,15 @@ -# The Professional Programmer +# به چه برنامه‌نویسی حرفه‌ای می‌گویند؟ -What is a professional programmer? +اصلی‌ترین خصیصهٔ یک برنامه‌نویس حرفه‌ای، مسئولیت‌پذیری است. برنامه‌نویسان حرفه‌ای مسئولیت کاری که انجام می‌دهند، پیش‌بینی‌هایشان، تعهداتشان و اشتباهاتشان را پذیرفته و تحت هیچ عنوان انگشت اتهام به‌سوی دیگر دولوپرها دراز نمی‌کنند. -The single most important trait of a professional programmer is *personal responsibility*. Professional programmers take responsibility for their career, their estimates, their schedule commitments, their mistakes, and their workmanship. A professional programmer does not pass that responsibility off on others. +اگر دوست دارید برچسب حرفه‌ای روی شما بخورد، همواره می‌بایست مسئولیت کاری که انجام می‌دهید را بپذیرید؛ شما در قبال به‌روز بودن در حوزهٔ کاری خود و آخرین تکنولوژی‌های عرضه شده به بازار مسئول هستید. جالب است بدانید بسیار از دولوپرهای تازه‌کار هستند که بر این باورند وظیفهٔ کارفرمای ایشان است که به ایشان آموزش دهد که این تصور کاملاً اشتباه است! هیچ کارفرمایی آن‌قدر وقت و هزینه ندارد که شروع به آموزش و به‌روز کردن تک‌تک اعضای تیم توسعهٔ نرم‌افزار خود کند با علم به این که در آینده‌ای نه‌چندان دور، دولوپر خود را از دست خواهد داد (لازم به‌ذکر است که عمر دولوپرها در شرکت‌های نرم‌افزاری بیش از ۳ الی ۴ سال نیست). -- If you are a professional, then *you* are responsible for your own career. *You* are responsible for reading and learning. You are responsible for staying up-to-date with the industry and the technology. Too many programmers feel that it is their employer's job to train them. Sorry, this is just dead wrong. Do you think doctors behave that way? Do you think lawyers behave that way? No, they train themselves on their own time, and their own nickel. They spend much of their off-hours reading journals and decisions. They keep themselves up-to-date. And so must we. The relationship between you and your employer is spelled out nicely in your employment contract. In short: They promise to pay you, and you promise to do a good job. +بازهم اگر دوست دارید حرفه‌ای دیده شوید، می‌بایست مسئولیت کدی که می‌زنید را ۱۰۰٪ قبول کنید. هیچ دولوپر حرفه‌ای را سراغ نداریم که پیش از اطمینان حاصل کردن از عملکرد کدش، آن‌را ریلیس کند. درواقع، دولوپرهای حرفه‌ای اصلاً واهمه‌ای از متخصصین QA (این اصطلاح مخفف واژگان Quality Assurance به‌معنی تضمین کیفیت است) ندارند چراکه می‌دانند ایشان هیچ باگی در کدی که ایشان نوشته‌اند نخواهند یافت. -- Professionals take responsibility for the code they write. They do not release code unless they know it works. Think about that for a minute. How can you possibly consider yourself a professional if you are willing to release code that you are not sure of? Professional programmers expect QA to find *nothing* because *they don't release their code until they've thoroughly tested it*. Of course QA will find some problems, because no one is perfect. But as professionals our attitude must be that we will leave nothing for QA to find. +یکی دیگر از خصیصه‌های دولوپرهای حرفه‌ای این است که ایشان در کار تیمی (Team Work) مهارت دارند. ایشان مسئولیت خروجی کار کل تیم را برعهده می‌گیرند و تحت هیچ عنوان از زبان ایشان نمی‌شنویم که «من فقط فلان X رو نوشتم و این کد مال من نیست». دولوپرهای حرفه‌ای به دیگر همکاران خود -به‌خصوص کسانی‌که تازه‌کار هستند- کمک می‌کنند، به یکدیگر یاد می‌دهند، از همدیگر یاد می‌گیرند و در یک کلام، دیگران را ساپورت می‌کنند. -- Professionals are team players. They take responsibility for the output of the whole team, not just their own work. They help each other, teach each other, learn from each other, and even cover for each other when necessary. When one team-mate falls down, the others step in, knowing that one day they'll be the ones to need cover. +برنامه‌نویسان که تصمیم گرفته‌اند جزو حرفه‌ای‌های صنعت کاری خود باشند، تحت هیچ عنوان لیست طولانی از باگ‌های موجود در نرم‌افزار را تحمل نمی‌کنند و به‌محض مواجه با یک باگ -خواه کوچک و خواه بزرگ- درصدد رفع آن بر‌می‌آیند. -- Professionals do not tolerate big bug lists. A huge bug list is sloppy. Systems with thousands of issues in the issue tracking database are tragedies of carelessness. Indeed, in most projects the very need for an issue tracking system is a symptom of carelessness. Only the very biggest systems should have bug lists so long that automation is required to manage them. +کدنویسی تمیز هم یکی دیگر از خصیصه‌های دولوپرهای حرفه‌ای است. کدی که یک دولوپر حرفه‌ای زده باشد در مقایسه با یک شخص غیرحرفه‌ای، بسیار تمیز با ساختاری قابل‌درک و درعین‌حال قابل‌ خواندن است. دولوپرهای حرفه‌ای همواره از استانداردهای کدنویسی (Best Practices) در حین کدنویسی استفاده می‌کنند و همین مسئله منجر به این خواهد گشت که دیگر دولوپرها در خواندن سورس‌کد ایشان به مشکل برنخواهند خورد. -- Professionals do not make a mess. They take pride in their workmanship. They keep their code clean, well structured, and easy to read. They follow agreed upon standards and best practices. They never, *ever* rush. Imagine that you are having an out-of-body experience watching a doctor perform open-heart surgery on *you*. This doctor has a *deadline* (in the literal sense). He must finish before the heart-lung bypass machine damages too many of your blood cells. How do you want him to behave? Do you want him to behave like the typical software developer, rushing and making a mess? Do you want him to say: "I'll go back and fix this later?" Or do you want him to hold carefully to his disciplines, taking his time, confident that his approach is the best approach he can reasonably take. Do you want a mess, or professionalism? - -Professionals are responsible. They take responsibility for their own careers. They take responsibility for making sure their code works properly. They take responsibility for the quality of their workmanship. They do not abandon their principles when deadlines loom. Indeed, when the pressure mounts, professionals hold ever tighter to the disciplines they know are right. - -by [Uncle Bob](http://programmer.97things.oreilly.com/wiki/index.php/Uncle_Bob) \ No newline at end of file +در یک کلام، حرفه‌ای‌ها جزو آدم‌های مسئول هستند؛ به‌عبارت دیگر، کسانی که مسئولیت کار خود را پذیرفته و سعی می‌کنند کدی بنویسند که بهینه بوده و به بهترین شکل کار کند. دولوپرهای حرفه‌ای زمانی که با کمبود وقت مواجه می‌شوند، هرگز بزن و برویی کد نمی‌زنند و تحت هیچ عنوان استانداردهای سفت و سخت کدنویسی خود را زیر پا نمی‌گذارند تا به ددلاین مدنظر برسند بلکه برعکس، در چنین شرایطی بیشتر به استانداردها پایبند می‌شوند چراکه می‌دانند در شرایط استراس‌زا، احتمال بروز خطا بسیار بالا خواهد بود. From 98b4ac67a729478d357294a790eb4c11489bcd21 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 15:37:43 +0300 Subject: [PATCH 223/290] Added number 68 --- fr-IR/thing_68/README.md | 28 +++++++++++++++++----------- 1 file changed, 17 insertions(+), 11 deletions(-) diff --git a/fr-IR/thing_68/README.md b/fr-IR/thing_68/README.md index 771a11d8..4cb6514f 100644 --- a/fr-IR/thing_68/README.md +++ b/fr-IR/thing_68/README.md @@ -1,19 +1,25 @@ -# Put Everything Under Version Control +# از ورژن کنترل غافل نشوید! -Put everything in all your projects under version control. The resources you need are there: free tools, like Subversion, Git, Mercurial, and CVS; plentiful disk space; cheap and powerful servers; ubiquitous networking; and even project-hosting services. After you've installed the version control software all you need in order to put your work in its repository is to issue the appropriate command in a clean directory containing your code. And there are just two new basic operations to learn: you *commit* your code changes to the repository and you update your working version of the project with the repository's version. +یکی از نشانه‌های حرفه‌ای بودن در صنعت توسعهٔ نرم‌افزار، استفاده از Version Control است. گرچه درظاهر سوییچ کردن به ورژن کنترل کمی دشوار به‌نظر می‌آید اما پس از آن‌که مزایای چنین کاری بر دولوپرها -اعم از تازه‌کار و باتجربه- آشکار شد، ثابت می‌شود که یادگیری کار در چنین فضایی ارزشش را دارا است. -Once your project is under version control you can obviously track its history, see who wrote what code, and refer to a file or project version through a unique identifier. More importantly you can make bold code changes without fear — no more commented-out code just in case you need it in the future, because the old version lives safely in the repository. You can (and should) tag a software release with a symbolic name so that you can easily revisit in the future the exact version of the software your customer runs. You can create branches of parallel development: Most projects have an active development branch and one or more maintenance branches for released versions that are actively supported. +از جمله پلتفرم‌های ورژن کنترل رایج می‌توان به Git و SVN اشاره کرد(لازم‌ به‌ذکر است که گیت توسط لینوس توروالدز -خالق کِرنِل لینوکس- طراحی شده است و امروزه به‌عنوان معروف‌ترین و محبوب‌ترین سیستم کنترل نسخه شناخته می‌شود). -A version-control system minimizes friction between developers. When programmers work on independent software parts these get integrated almost by magic. When they step on each others' toes the system notices and allows them to sort out the conflicts. With some additional setup the system can notify all developers for each committed change, establishing a common understanding of the project's progress. +امروزه وب‌سایت‌های زیادی هم اقدام به ارائهٔ خدمات ورژن کنترل می‌کنند که از معروف‌ترین آن‌ها می‌توان به گیت‌هاب و گیت‌لب اشاره کرد (برای آشنایی بیشتر با نحوهٔ عمل‌کرد ورژن کنترل، می‌توانید به مقالهٔ ورژن کنترل (Version Control) چگونه کار می‌کند؟ مراجعه نمایید). -When you set up your project, don't be stingy: place *all* the project's assets under version control. Apart from the source code, include the documentation, tools, build scripts, test cases, artwork, and even libraries. With the complete project safely tucked into the (regularly backed up) repository the damage of losing your disk or data is minimized. Setting up for development on a new machine involves simply checking out the project from the repository. This simplifies distributing, building, and testing the code on different platforms: On each machine a single update command will ensure that the software is the current version. +زمانی که شما به ورژن کنترل مهاجرت می‌کنید، به‌سادگی می‌توانید به تاریخچه‌ای از تغییرات صورت گرفته در پروژه دسترسی یافته و مهم‌تر از آن، ببینید که کدام‌یک از اعضای تیم و در چه زمانی آن تغییرات را ایجاد کرده‌‌اند. باتوجه به این‌که کلیه‌ٔ تغییرات صورت گرفته در سورس‌کد، ریفکتورینگ‌ها، باگ فیکس‌ها و … تحت ورژن کنترل ذخیره می‌شوند، دولوپرها بدون هیچ‌گونه نگرانی و دغدغه‌ای می‌توانند دست به اعمال تغییرات در سورس‌کد پروژ‌هایش بزنند چراکه این اطمینان خاطر را دارند که نسخه‌های پیشین پروژه را ذخیره دارند. -Once you've seen the beauty of working with a version control system, following a couple of rules will make you and your team even more effective: +یکی از چیزهایی که در ورژن کنترل اهمیت دارد، تگ‌‌گذاری نسخه‌های مختلف پروژه است چرا که براساس همین تگ‌ها -که توصیه می‌شود براساس تاریخ باشند- در آینده به‌سادگی امکان جستجوی نسخهٔ خاصی از نرم‌افزار امکان‌پذیر می‌گردد. -- Commit each logical change in a separate operation. Lumping many changes together in a single commit will make it difficult to disentangle them in the future. This is especially important when you make project-wide refactorings or style changes, which can easily obscure other modifications. -- Accompany each commit with an explanatory message. At a minimum describe succinctly what you've changed, but if you also want to record the change's rationale this is the best place to store it. -- Finally, avoid committing code that will break a project's build, otherwise you'll become unpopular with the project's other developers. +علاوه‌بر این، در ورژن کنترل مفهومی داریم تحت‌عنوان Branch (برنچ یا شاخه) که بااستفاده از آن می‌توان نسخه‌هایی موازی از پروژه‌ای واحد ایجاد کرد مثلاً یکی تحت‌عنوان Development (توسعه) و یک یا تعدادی برنچ دیگر تحت‌عنوان Maintanance (نگهداری) بدین شکل که کدنویسی پروژه روی برنچ توسعه صورت می‌گیرد و چنانچه پس از اعمال تغییرات و یا افزودن فیچر جدید به پروژه و ریلیس کردن آن نرم‌افزار و برخورد کردن به مشکلی خاص، به‌سادگی و درصورتی‌که نیاز به نسخه‌های قبلی باشد، می‌توان به یکی از برنچ‌های نگهداری مراجعه کرد. -Life under a version control system is too good to ruin it with easily avoidable missteps. +درصورتی‌که ورژن کنترل به‌درستی به‌کار گرفته شود، اصطکاک مابین دولوپرهایی که روی پروژه‌ای یکسان کار می‌کنند نیز به حداقل می‌رسد. درواقع، تغییرات صورت گرفته روی پروژه خیلی راحت به اطلاع تک‌تک دولوپرها رسیده و درصورتی‌که کانفلیکتی به‌وجود آید، به‌سادگی می‌توان آن‌را مرتفع ساخت. -By [Diomidis Spinellis](http://programmer.97things.oreilly.com/wiki/index.php/Diomidis_Spinellis) \ No newline at end of file +زمانی که قصد دارید پروژه‌ای را روی یک سرویس ورژن کنترل -مثل گیت‌لب که رایگان هم هست- قرار دهید، اصلاً خساست به‌خرج ندهید! به‌عبارت دیگر، تمامی فایل‌های پروژه از سورس‌کد گرفته تا تصاویر، مستندات، اسکمای دیتابیس + دیتای اولیه جهت تست، ابزارها و … را روی ورژن کنترل ارسال کنید (حتی توصیه می‌شود لایبرری‌ها که معمولاً به‌اصطلاح Ignore هستند و به‌صورت اتوماتیک روی سرور ارسال نمی‌شوند را هم آپلود کنید). با اتخاذ چنین رویکردی، این اطمینان حاصل می‌شود که همواره نسخه‌ای کامل از پروژه به‌صورت بکاپ در اختیار خواهیم داشت (فرض کنیم که سیستم‌عامل خود را تغییر می‌دهیم و یا کلاً سیستم‌مان عوض می‌شود که بااستفاده از چنین رویکردی، به‌راحتی می‌توان کل پروژه را از پلتفرم ورژن کنترل مدنظر گرفته و به‌کار خود ادامه داد). + +معرفی استراتژی‌های به‌منظور بهره‌وری بیشتر از Version Control +زمانی‌که شما به ورژن کنترل مهاجرت کردید و مزایای آن‌را درک نمودید، یکسری استراتژی‌ها و به‌اصطلاح Best Practice وجود دارد که چنانچه از آن‌ها پیروی کنید، می‌توانید اطمینان حاصل نمایید که از تمام پتانسیل یک سیستم ورژن کنترل استفاده می‌نمایید که عبارتند از: +- تغییرات اساسی در نرم‌افزار را در قالب یک Commit (کامیت) مجزا روی سرور بفرستید. چنانچه چند تغییر نامرتبط با یکدیگر را در قالب یک کامیت درنظر بگیرید، در آینده یافتن تاریخچهٔ پروژه کار دشواری خواهد شد. + +- برای هر کامیت، توضیحاتی واضح و شفاف درنظر بگیرید (اگر هم این کار برایتان دشوار است، حداقل توضیح دهید که چه‌چیزی را تغییر داده‌اید). این دست توضیحات می‌توانند در آینده چنانچه نیاز به نسخه‌های قبلی نرم‌افزار شد، بسیار مؤثر واقع شوند. + +- تحت هیچ عنوان کدی را قبل از تست کردن کامل و اطمینان حاصل کردن از این‌که نرم‌افزار به‌طور کامل کار می‌کند کامیت نکنید چراکه این‌کار در دراز مدت اعتبار شما در دید دیگر دولوپرهایی که روی پروژه کار می‌کنند را کم خواهد کرد. From 129836ea812e8dbaf67bef08758d60226ac45a85 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 15:38:15 +0300 Subject: [PATCH 224/290] Modified number 68 --- fr-IR/thing_68/README.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/fr-IR/thing_68/README.md b/fr-IR/thing_68/README.md index 4cb6514f..5045e292 100644 --- a/fr-IR/thing_68/README.md +++ b/fr-IR/thing_68/README.md @@ -18,8 +18,8 @@ معرفی استراتژی‌های به‌منظور بهره‌وری بیشتر از Version Control زمانی‌که شما به ورژن کنترل مهاجرت کردید و مزایای آن‌را درک نمودید، یکسری استراتژی‌ها و به‌اصطلاح Best Practice وجود دارد که چنانچه از آن‌ها پیروی کنید، می‌توانید اطمینان حاصل نمایید که از تمام پتانسیل یک سیستم ورژن کنترل استفاده می‌نمایید که عبارتند از: -- تغییرات اساسی در نرم‌افزار را در قالب یک Commit (کامیت) مجزا روی سرور بفرستید. چنانچه چند تغییر نامرتبط با یکدیگر را در قالب یک کامیت درنظر بگیرید، در آینده یافتن تاریخچهٔ پروژه کار دشواری خواهد شد. +1 - تغییرات اساسی در نرم‌افزار را در قالب یک Commit (کامیت) مجزا روی سرور بفرستید. چنانچه چند تغییر نامرتبط با یکدیگر را در قالب یک کامیت درنظر بگیرید، در آینده یافتن تاریخچهٔ پروژه کار دشواری خواهد شد. -- برای هر کامیت، توضیحاتی واضح و شفاف درنظر بگیرید (اگر هم این کار برایتان دشوار است، حداقل توضیح دهید که چه‌چیزی را تغییر داده‌اید). این دست توضیحات می‌توانند در آینده چنانچه نیاز به نسخه‌های قبلی نرم‌افزار شد، بسیار مؤثر واقع شوند. +2 - برای هر کامیت، توضیحاتی واضح و شفاف درنظر بگیرید (اگر هم این کار برایتان دشوار است، حداقل توضیح دهید که چه‌چیزی را تغییر داده‌اید). این دست توضیحات می‌توانند در آینده چنانچه نیاز به نسخه‌های قبلی نرم‌افزار شد، بسیار مؤثر واقع شوند. -- تحت هیچ عنوان کدی را قبل از تست کردن کامل و اطمینان حاصل کردن از این‌که نرم‌افزار به‌طور کامل کار می‌کند کامیت نکنید چراکه این‌کار در دراز مدت اعتبار شما در دید دیگر دولوپرهایی که روی پروژه کار می‌کنند را کم خواهد کرد. +3 - تحت هیچ عنوان کدی را قبل از تست کردن کامل و اطمینان حاصل کردن از این‌که نرم‌افزار به‌طور کامل کار می‌کند کامیت نکنید چراکه این‌کار در دراز مدت اعتبار شما در دید دیگر دولوپرهایی که روی پروژه کار می‌کنند را کم خواهد کرد. From 50bab33a4b328fdc4c94adfbbdd4f95161afe757 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 15:39:04 +0300 Subject: [PATCH 225/290] Added number 69 --- fr-IR/thing_69/README.md | 51 ++++------------------------------------ 1 file changed, 5 insertions(+), 46 deletions(-) diff --git a/fr-IR/thing_69/README.md b/fr-IR/thing_69/README.md index a90c7cdd..92d5e6ef 100644 --- a/fr-IR/thing_69/README.md +++ b/fr-IR/thing_69/README.md @@ -1,50 +1,9 @@ -# Put the Mouse Down and Step Away from the Keyboard +# ماوس و کیبورد را کنار بگذارید! -You've been focused for hours on some gnarly problem and there's no solution in sight. So you get up to stretch your legs, or to hit the vending machines, and on the way back the answer suddenly becomes obvious. +آیا تاکنون برایتان اتفاق افتاده که ساعت‌ها مشغول سروکله زدن با مشکل یا باگی بوده‌اید اما هیچ راه‌کاری به ذهنتان نرسیده، خسته شده و از پشت سیستم‌تان بلند شده تا کمی استراحت کنید یا چیزی بنوشید اما در کمال ناباوری ناگهان راه‌کار مدنظر به ذهنتان رسیده است؟ -Does this scenario sound familiar? Ever wonder why it happens? The trick is that while you're coding, the logical part of your brain is active and the creative side is shut out. It can't present anything to you until the logical side takes a break. +دلیلی که پشت این قضیه نهفته این است که وقتی شما درحال کدنویسی هستید، بخش منطقی مغز شما (سمت چپ مغز) فعال بوده و بخش احساسی مغز (سمت راست مغز) غیرفعال؛ مادامی‌که بخش منطقی مغز -که از قضا مسئول یافتن راه‌کار یا رفع باگ است- استراحت کافی نداشته باشد، هرگز قادر به کمک برای یافتن راه‌کاری مناسب نیست! -Here's a real-life example: I was cleaning up some legacy code and ran into an 'interesting' method. It was designed to verify that a string contained a valid time using the format *hh:mm:ss xx*, where *hh* represents the hour, *mm* represents minutes, *ss* represents seconds, and *xx* is either *AM* or *PM*. +درواقع، همان‌طور که پس از انجام کارهای فیزیکی مثل ورزش کردن و … بدن نیاز به استراحت دارد، پس از کارهای ذهنی مثل کدنویسی هم باید به عضوی از بدنمان که بیشترین درگیری را دارا است (مغز) استراحت دهیم که در غیر این‌ صورت راندمانش به‌طرز قابل‌توجهی کاهش خواهد یافت. -The method used the following code to convert two characters (representing the hour) into a number, and verify it was within the proper range: - -``` -try { - Integer.parseInt(time.substring(0, 2)); -} catch (Exception x) { - return false; -} - -if (Integer.parseInt(time.substring(0, 2)) > 12) { - return false; -} -``` - -The same code appeared twice more, with appropriate changes to the character offset and upper limit, to test the minutes and seconds. The method ended with these lines to check for AM and PM: - -``` -if (!time.substring(9, 11).equals("AM") & - !time.substring(9, 11).equals("PM")) { - return false; -} -``` - -If none of this series of comparisons failed, returning false, the method returned true. - -If the preceding code seems wordy and difficult to follow, don't worry. I thought so too — which meant I'd found something worth cleaning up. I refactored it and wrote a few unit tests, just to make sure it still worked. - -When I finished, I felt pleased with the results. The new version was easy to read, half the size, and more accurate because the original code tested only the upper boundary for the hours, minutes, and seconds. - -While getting ready for work the next day, an idea popped in my head: Why not validate the string using a regular expression? After a few minutes typing, I had a working implementation in just one line of code. Here it is: - -``` -public static boolean validateTime(String time) { - return time.matches("(0[1-9]|1[0-2]):[0-5][0-9]:[0-5][0-9] ([AP]M)"); -} -``` - -The point of this story is not that I eventually replaced over thirty lines of code with just one. The point is that until I got away from the computer, I thought my first attempt was the best solution to the problem. - -So the next time you hit a nasty problem, do yourself a favor. Once you really understand the problem go do something involving the creative side of your brain — sketch out the problem, listen to some music, or just take a walk outside. Sometimes the best thing you can do to solve a problem is to put the mouse down and step away from the keyboard. - -By [BurkHufnagel](http://programmer.97things.oreilly.com/wiki/index.php/BurkHufnagel) \ No newline at end of file +به‌عنوان راه‌کاری عملی، می‌توان گفت که پس از گیر کردن در یافتن یک باگ و یا به‌طورکلی پس از چندین ساعت کدنویسی، کمی استراحت کردن شامل گوش دادن به موسیقی مورد علاقه،‌ نوشیدن چای یا قهوه و کارهایی از این دست می‌تواند انرژی مورد نیاز برای ادامهٔ کارمان را تأ‌مین سازد. به‌عبارت دیگر، گاهی‌اوقات بهترین روش حل مسأله، کنار گذاشتن ماوس و کیبورد است. From ae0af9cf946b142cf9538aa060e9db670553484b Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 15:39:36 +0300 Subject: [PATCH 226/290] Added number 70 --- fr-IR/thing_70/README.md | 21 ++++++++++++++------- 1 file changed, 14 insertions(+), 7 deletions(-) diff --git a/fr-IR/thing_70/README.md b/fr-IR/thing_70/README.md index 081aa5aa..6c60a354 100644 --- a/fr-IR/thing_70/README.md +++ b/fr-IR/thing_70/README.md @@ -1,13 +1,20 @@ -# Read Code +# کدخوانی کنید! -We programmers are weird creatures. We love writing code. But when it comes to reading it we usually shy away. After all, writing code is so much more fun, and reading code is hard — sometimes almost impossible. Reading other people's code is particularly hard. Not necessarily because other people's code is bad, but because they probably think and solve problems in a different way to you. But did you ever consider that reading someone else's code could improve your own? +اکثر دولوپرها از کدزنی لذت می‌برند اما زمانی‌که پای کدخوانی به میان می‌آید، کمتر کسی را می‌توان یافت که از این کار لذت ببرد! از آنجا که کدزنی به‌مراتب لذت‌بخش‌تر از کدخوانی است و همچنین فرایند کدخوانی کاری سخت، طاقت‌فرسا و گاهی‌اوقات غیرممکن است، دولوپرها معمولاً تمایلی به انجام این کار ندارند مگر آن‌که مجبور شوند! -The next time you read some code, stop and think for a moment. Is the code easy or hard to read? If it is hard to read, why is that? Is the formatting poor? Is naming inconsistent or illogical? Are several concerns mixed together in the same piece of code? Perhaps the choice of language prohibits the code from being readable? Try to learn from other people's mistakes, so that your code won't contain the same ones. You may receive a few surprises. For example, dependency-breaking techniques may be good for low coupling, but they can sometimes also make code harder to read. And what some people call *elegant code*, others call *unreadable*. +به‌عنوان یک قانون کلی، معمولاً خواندن کدهایی که توسط دیگر دولوپرها نوشته شده است سخت است البته این بدان معنا نیست که دیگر دولوپرها کار خود را بلد نیستند بلکه این سختی بدین دلیل است که هیچ ۲ دولوپری همچون یکدیگر به یک Problem (مسأله) به شکلی یکسان نگاه نکرده و مشابه یکدیگر آن‌را حل نمی‌کنند. -If the code is easy to read, stop to see if there is something useful you can learn from it. Maybe there's a design pattern in use that you don't know about, or had previously struggled to implement. Perhaps the methods are shorter and their names more expressive than yours. Some open source projects are full of good examples of how to write brilliant, readable code — while others serve as examples of the exact opposite! Check out some of their code and take a look. +آیا کدخوانی منجر به بهبود کدنویسی می‌شود؟ +وقتی سورس‌کدی را می‌خوانید، همواره این سؤال را از خود بپرسید که آیا این فرایند راحت است یا دشوار؟ اگر پاسخ به چنین سؤالی «دشوار» بود،‌ بایستی بیابید که دلیل اصلی دشواری کدخوانی چیست، آیا فرمت‌ سورس‌کد مناسب نیست یا نامگذاری کلاس‌ها، متدها، متغیرها و … نامناسب است و یا این که زبان برنامه‌نویسی مدنظر به‌طورکلی دارای سینتکسی دشوار است! -Reading your own old code, from a project you are not currently working on, can also be an enlightening experience. Start with some of your oldest code and work your way forward to the present. You will probably find that it is not at all as easy to read as when you wrote it. Your early code may also have a certain embarrassing entertainment value, kind of in the same way as being reminded of all the things you said when you were drinking in the pub last night. Look at how you have developed your skills over the years — it can be truly motivating. Observe what areas of the code are hard to read, and consider whether you are still writing code in the same way today. +در چنین شرایطی می‌توان از اشتباهات دیگر دولوپرها درس گرفت به‌طوری‌که درحین کدنویسی، هرگز آن اشتباهات را مرتکب نشویم تا درنهایت سورس‌کدی که تحویل دیگر دولوپرها می‌دهیم، از دید ایشان سورس‌کدی حرفه‌ای، خوانا و قابل‌فهم باشد. -So the next time you feel the need to improve your programming skills, don't read another book. Read code. +اگر هم خواندن سورس‌کدی را «راحت» یافتیم، بازهم درس‌هایی می‌توان از آن آموخت. شاید از دیزاین پترنی استفاده شده که تاکنون از آن مطلع نبوده‌اید، شاید فانکشن‌ها کوتاه‌تر به‌همراه نامگذاری بهینه‌تری هستند و چیزهایی از این دست. -by [Karianne Berg](http://programmer.97things.oreilly.com/wiki/index.php/Karianne_Berg) \ No newline at end of file +به‌طورکلی، پروژه‌های اپن‌سورس فراوانی را در گیت‌هاب و دیگر پلتفرم‌ها می‌توان یافت که نمونه‌های خوبی از کدنویسی حرفه‌ای هستند که با دنبال کردن استراتژی‌های چنین دولوپرهایی، می‌توانیم خود را به یک Role Model برای دیگر دولوپرهای تازه‌کار مبدل سازیم. + +جالب است بدانید کدخوانی سورس‌کدهایی که چندین سال پیش نوشته‌ایم نیز می‌تواند درس‌های بسیاری برایمان به‌ ارمغان آورد بدین شکل که متوجه خواهید شد قدیمی‌ترین کدهایی که نوشته‌اید تحت هیچ عنوان مورد پسند شما -با استانداردهای کدنویسی کنونی‌تان- نیستند و گاهی‌اوقات هم اصلاً خوانا و قابل‌فهم نیستند! + +مشاهدهٔ چنین سیر پیشرفتی می‌تواند انگیزهٔ شما را دوچندان سازد و اگر هم می‌بینید که همان استانداردهای کدنویسی نامطلوبی که در گذشته استفاده می‌کرده‌اید درحال‌حاضر هم در کدهای شما موجود است، این زنگ خطری است که باید خیلی به آن توجه کنید. + +در یک کلام، هرموقع که تمایل داشتید مهارت‌های کدنویسی خود را ارتقاء بخشید، به‌جای شروع به خواندن یک کتاب آموزشی یا مراجعه به یک وب‌سایت آموزشی مرتبط با برنامه‌نویسی، می‌توانید شروع به خواندن سورس‌کد دیگر دولوپرهای حرفه‌ای نمایید. From 7a9df588b4582c9e9f724810a36b69b9fcb74c04 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 15:40:26 +0300 Subject: [PATCH 227/290] Added number 71 --- fr-IR/thing_71/README.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/fr-IR/thing_71/README.md b/fr-IR/thing_71/README.md index 4d0f58a9..2adb0bce 100644 --- a/fr-IR/thing_71/README.md +++ b/fr-IR/thing_71/README.md @@ -1,13 +1,13 @@ -# Read the Humanities +# تعاملات اجتماعی کلید موفقیت است! -In all but the smallest development project people work with people. In all but the most abstracted field of research people write software for people to support them in some goal of theirs. People write software with people for people. It's a people business. Unfortunately what is taught to programmers too often equips them very poorly to deal with people they work for and with. Luckily there is an entire field of study that can help. +آدم‌ها با کمک دیگر آدم‌ها برای آدم‌های دیگر کدنویسی می‌کنند! شاید چنین جمله‌ای در نگاه اول کمی عجیب به‌نظر برسد، اما واقعیت دارد. درواقع، این جمله تأکیدش برروی ارتباط افراد با یکدیگر و کار گروهی است. -For example, Ludwig Wittgenstein makes a very good case in the *Philosophical Investigations* (and elsewhere) that any language we use to speak to one another is not, cannot be, a serialization format for getting a thought or idea or picture out of one person's head and into another's. Already we should be on our guard against misunderstanding when we "gather requirements." Wittgenstein also shows that our ability to understand one another at all does not arise from shared definitions, it arises from a shared experience, from a form of life. This may be one reason why programmers who are steeped in their problem domain tend to do better than those who stand apart from it. +از بشر اول تاکنون، آدم‌ها به این دلیل که بتوانند به بقای خود ادامه دهند، سعی کرده‌اند روی کمک یکدیگر حساب کرده و در گروه‌ها زندگی کنند و این درحالی است که امروزه هم که در عصر فناوری به‌ سر می‌بریم از این قاعده مستثنی نیستیم. -Lakoff and Johnson present us with a catalog of *Metaphors We Live By*, suggesting that language is largely metaphorical, and that these metaphors offer an insight into how we understand the world. Even seemingly concrete terms like cash flow, which we might encounter in talking about a financial system, can be seen as metaphorical: "money is a fluid." How does that metaphor influence the way we think about systems that handle money? Or we might talk about layers in a stack of protocols, with some high level and some low level. This is powerfully metaphorical: the user is "up" and the technology is "down." This exposes our thinking about the structure of the systems we build. It can also mark a lazy habit of thought that we might benefit from breaking from time to time. +با این حال، برخی از دولوپرها را می‌بینیم که به‌نوعی از جامعه بریده شده و در انزوا کد می‌زنند و این درحالی است که دیگر دولوپرهایی که اجتماعی‌تر بوده،‌ به کار تیمی اعتقاد دارند و قبل از آن‌که برنامه‌نویس باشند، یک «موجود اجتماعی» هستند می‌توانند علاوه‌بر زندگی شخصی، در حرفهٔ برنامه‌نویسی‌شان نیز بیشتر پیشرفت کنند. -Martin Heidegger studied closely the ways that people experience tools. Programmers build and use tools, we think about and create and modify and recreate tools. Tools are objects of interest to us. But for its users, as Heiddeger shows in *Being and Time*, a tool becomes an invisible thing understood only in use. For users tools only become objects of interest when they don't work. This difference in emphasis is worth bearing in mind whenever usability is under discussion. +به‌طورکلی، دولوپرهایی که در پروژه‌های اپن‌سورس شرکت می‌کنند، در رویدادهای کدنویسی مشارکت دارند و دانسته‌های خود را با دیگر دولوپرهای غالباً تازه‌کار به اشتراک می‌گذارند، وبلاگ‌نویسی می‌کنند و به هر شکلی به تعامل با دیگر افراد می‌پردازند، تأثیر به‌مراتب بیشتری در صنعت نرم‌افزار می‌توانند داشته باشند. -Eleanor Rosch overturned the Aristotelean model of the categories by which we organize our understanding of the world. When programmers ask users about their desires for a system we tend to ask for definitions built out of predicates. This is very convenient for us. The terms in the predicates can very easily become attributes on a class or columns in a table. These sorts of categories are crisp, disjoint, and tidy. Unfortunately, as Rosch showed in "Natural Categories" and later works, that just isn't how people in general understand the world. They understand it in ways that are based on examples. Some examples, so-called prototypes, are better than others and so the resulting categories are fuzzy, they overlap, they can have rich internal structure. In so far as we insist on Aristotelean answers we can't ask users the right questions about the user's world, and will struggle to come to the common understanding we need. +علاوه‌بر این، یک روی دیگر سکه هم کاربرانی است که قرار است از حاصل کدنویسی‌های دولوپرها استفاده کنند. در اینجا هم مجدد نیاز به تعاملات اجتماعی داریم؛ به‌عبارت دیگر، مادامی‌که دولوپرها به تعامل با کاربران هدف نرم‌افزار یا اپلیکیشن نپردازند، ایشان تحت هیچ عنوان نخواهند توانست به رفع باگ‌ها، بهبود نرم‌افزار و درنهایت رقم زدن یک تجربه‌ٔ کاربری عالی بپردازند. -by [Keith Braithwaite](http://programmer.97things.oreilly.com/wiki/index.php/Keith_Braithwaite) \ No newline at end of file +درنتیجه، همواره به‌خاطر داشته باشیم که در صنعت توسعهٔ نرم‌افزار تعملات اجتماعی همچون هر حرفه‌ٔ دیگری دارای اهمیت بسیار بالایی است؛ از تعامل ما مشتریان گرفته تا مدیر پروژه، تستر نرم‌افزار و دیگر دولوپرها، همواره می‌بایست روی مهارت ارتباطات و مذاکره کار کرده و در این حوزه هم علاوه بر مهارت‌های کدنویسی تسلط یابیم. From fda4eedb12f6e9dda4edea74cfdc5c4cb65c3a43 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 15:41:07 +0300 Subject: [PATCH 228/290] Added number 72 --- fr-IR/thing_72/README.md | 16 ++++------------ 1 file changed, 4 insertions(+), 12 deletions(-) diff --git a/fr-IR/thing_72/README.md b/fr-IR/thing_72/README.md index b21fc6cb..a149f925 100644 --- a/fr-IR/thing_72/README.md +++ b/fr-IR/thing_72/README.md @@ -1,15 +1,7 @@ -# Reinvent the Wheel Often +# تا حد ممکن دست به اختراع مجدد چرخ نزنید! -"Just use something that exists — it's silly to reinvent the wheel..." +شاید وقتی پای توسعهٔ نرم‌افزار به میان می‌آید بارهاوبارها شنیده باشید که «تا حد ممکن باید از کدهای موجود استفاده کرد و اختراع مجدد چرخ کار احمقانه‌ای است!» حال ممکن است این سؤال پیش بیاید که چرا در دنیای توسعهٔ نرم‌افزار دوباره‌ کاری این‌قدر بد دیده می‌شود؟ پاسخ به این سؤال و سؤالات دیگری از این دست بسیار ساده است و آن‌ هم چیزی نیست جز این که کدهای موجود کار می‌کنند و در یک کلام، آزمون خود را پس داده‌اند. -Have you ever heard this or some variation thereof? Sure you have! Every developer and student probably hears comments like this frequently. Why though? Why is reinventing the wheel so frowned upon? Because, more often than not, existing code is working code. It has already gone through some sort of quality control, rigorous testing, and is being used successfully. Additionally, the time and effort invested in reinvention are unlikely to pay off as well as using an existing product or code base. Should you bother reinventing the wheel? Why? When? +اختراع مجدد چرخ صرفاً به این مسأله اشاره نمی‌کند که چگونه کدی بزنیم که نیاز ما را مرتفع سازد بلکه دارای ریزه‌کاری‌های بسیاری است که اگر ساده به این قضیه نگاه کنیم، شاید هیچ‌وقت متوجه آن‌ها نشویم! به‌طور مثال، سیستم‌هایی که پیش از این نوشته شده‌اند به‌طور کامل تست شده و توسط صدها دولوپر مورد استفاده قرار می‌گیرند و این درحالی است که به غیر از این‌ که کد کار می‌کند، در مورد مسائل فنی‌تر همچون پرفورمنس، معماری ساخت، الگوهای طراحی، توسعه‌پذیری و بسیار مسائل دیگر هم روی آن‌ها فکر شده است. -Perhaps you have seen publications about patterns in software development, or books on software design. These books can be sleepers regardless of how wonderful the information contained in them is. The same way watching a movie about sailing is very different to going sailing, so too is using existing code versus designing your own software from the ground up, testing it, breaking it, repairing it, and improving it along the way. - -Reinventing the wheel is not just an exercise in where to place code constructs: It is how to get an intimate knowledge of the inner workings of various components that already exist. Do you know how memory managers work? Virtual paging? Could you implement these yourself? How about double-linked lists? Dynamic array classes? ODBC clients? Could you write a graphical user interface that works like a popular one you know and like? Can you create your own web-browser widgets? Do you know when to write a multiplexed system versus a multi-threaded one? How to decide between a file- or a memory-based database? Most developers simply have never created these types of core software implementations themselves and therefore do not have an intimate knowledge of how they work. The consequence is all these kinds of software are viewed as mysterious black boxes that just work. Understanding only the surface of the water is not enough to reveal the hidden dangers beneath. Not knowing the deeper things in software development will limit your ability to create stellar work. - -Reinventing the wheel and getting it wrong is more valuable than nailing it first time. There are lessons learned from trial and error that have an emotional component to them that reading a technical book alone just cannot deliver! - -Learned facts and book smarts are crucial, but becoming a great programmer is as much about acquiring experience as it is about collecting facts. Reinventing the wheel is as important to a developer's education and skill as weight lifting is to a body builder. - -By [Jason P Sage](http://programmer.97things.oreilly.com/wiki/index.php/Jason_P_Sage) \ No newline at end of file +وقتی دولوپری قصد دارد دست به اختراع مجدد چرخ بزند و این درحالی است که در مورد مسائل پیچیدهٔ توسعه‌ٔ نرم‌افزار -همچون مواردی که در بالا بدان‌ها اشاره شد- آگاهی ندارد، نتیجه این شده که نرم‌افزاری تولید می‌شود که کار می‌کند و نیازهای خود دولوپر یا مشتری‌اش را مرتفع می‌سازد اما به احتمال زیاد در آینده زمانی‌که بار زیادی روی نرم‌افزار بیاید، نیاز به توسعه یا ریفکتورینگ آن باشد یا قرار باشد با دیگر نرم‌افزارها ادغام شده و دیگر مسائلی از این دست، به مشکل خواهد خورد. From db5b4205aaf4f729fea4c0ff681eeabadbfe9f23 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 15:42:04 +0300 Subject: [PATCH 229/290] Added number 72 --- fr-IR/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fr-IR/SUMMARY.md b/fr-IR/SUMMARY.md index f7b968c7..4e86c27e 100644 --- a/fr-IR/SUMMARY.md +++ b/fr-IR/SUMMARY.md @@ -72,7 +72,7 @@ 1. [ماوس را زمین بگذارید و از صفحه کلید فاصله بگیرید!](thing_69/README.md) 1. [کد را بخوانید](thing_70/README.md) 1. [علوم انسانی بخوانید!](thing_71/README.md) -1. [گاهی چرخ را دوباره اختراع کنید](thing_72/README.md) +1. [تا حد ممکن دست به اختراع مجدد چرخ نزنید!](thing_72/README.md) 1. [در مقابل وسوسه الگوی Singleton مقاومت کنید](thing_73/README.md) 1. [مسیر(جاده ی) Performance مملو از بمب های کد کثیف است!](thing_74/README.md) 1. [سادگی از اختصار می آید(کم گوی و گزیده گوی!)](thing_75/README.md) From 6c911ed681fbab37ffdd00705a20f2ca999cc7ef Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 15:42:51 +0300 Subject: [PATCH 230/290] Added number 73 --- fr-IR/thing_73/README.md | 26 ++++++-------------------- 1 file changed, 6 insertions(+), 20 deletions(-) diff --git a/fr-IR/thing_73/README.md b/fr-IR/thing_73/README.md index ecde8923..c00ae8bf 100644 --- a/fr-IR/thing_73/README.md +++ b/fr-IR/thing_73/README.md @@ -1,25 +1,11 @@ -# Resist the Temptation of the Singleton Pattern +# تا حد ممکن از Singleton Pattern استفاده نکنید -The Singleton pattern solves many of your problems. You know that you only need a single instance. You have a guarantee that this instance is initialized before it's used. It keeps your design simple by having a global access point. It's all good. What's not to like about this classic design pattern? +نیاز به توضیح نیست که Singleton Pattern مشکل‌گشای بسیاری از مشکلات شما در حین کدنویسی است؛ درواقع، زمانی که شما مطمئن باشید که فقط و فقط یک آبجکت از روی کلاس مدنظرتان نیاز خواهید داشت، می‌بایست از این الگو استفاده کنید اما این در حالی است که این تضمین باید وجود داشته باشد تا قبل از آنکه آن آبجکت مورد استفاده قرار گیرد، اصطلاحاً Initialize شده باشد. -Quite a lot, it turns out. Tempting they may be, but experience shows that most singletons really do more harm than good. They hinder testability and harm maintainability. Unfortunately, this additional wisdom is not as widespread as it should be and singletons continue to be irresistible to many programmers. But it is worth resisting: +اما تجربه نشان داده است که این نوع دیزاین پترن (الگوی طراحی) بیش از آنکه مفید واقع گردد، باعث دردسر خواهد شد چراکه توسعهٔ کد در آینده را دچار مشکل می‌کند! -- The single-instance requirement is often imagined. In many cases it's pure speculation that no additional instances will be needed in the future. Broadcasting such speculative properties across an application's design is bound to cause pain at some point. Requirements will change. Good design embraces this. Singletons don't. +یکی از دلایلی که دولوپرها به سمت استفاده از این الگوی طراحی می‌روند این است که در ابتدا فکر می‌کنند که مثلاً به کلاس X در کل پروژه صرفاً یک بار نیاز خواهند داشت اما این در حالی است که معمولاً پروژه‌های بزرگ نرم‌افزاری در طول زمان دستخوش تغییرات بسیاری شده و به مرور زمان نیازها دچار تغییر و تحول می‌گردند و چنانچه دولوپری بیش از حد روی این الگو حساب کرده باشد، ممکن است در آینده با مشکلات عدیده‌ای مواجه گردد. -- Singletons cause implicit dependencies between conceptually independent units of code. This is problematic both because they are hidden and because they introduce unnecessary coupling between units. This code smell becomes pungent when you try to write unit tests, which depend on loose coupling and the ability to selectively substitute a mock implementation for a real one. Singletons prevent such straightforward mocking. +نکتهٔ دیگری که در ارتباط با الگوی طراحی سینگلتون وجود دارد این است که این الگو دیپندنسی‌هایی (Dependency یا وابستگی) میان ماژول‌های مختلف پروژه‌ٔ شما به صورت انتزاعی ایجاد می‌کند و همین مسأله مشکل‌زا خواهد شد چرا که از یک سو این وابستگی‌ها خیلی به‌وضوح قابل مشاهده نیستند و از سوی دیگر بخش‌های مختلف سورس‌کد را به یکدیگر وابسته می‌سازند و همین مسأله منجر به این خواهد گشت که در آینده به‌سادگی نتوانیم از سورس‌کد خود در سایر پروژه‌ها استفاده کنیم. -- Singletons also carry implicit persistent state, which again hinders unit testing. Unit testing depends on tests being independent of one another, so the tests can be run in any order and the program can be set to a known state before the execution of every unit test. Once you have introduced singletons with mutable state, this may be hard to achieve. In addition, such globally accessible persistent state makes it harder to reason about the code, especially in a multi-threaded environment. - -- Multi-threading introduces further pitfalls to the singleton pattern. As straightforward locking on access is not very efficient, the so-called double-checked locking pattern (DCLP) has gained in popularity. Unfortunately, this may be a further form of fatal attraction. It turns out that in many languages DCLP is not thread-safe and, even where it is, there are still opportunities to get it subtly wrong. - -The cleanup of singletons may present a final challenge: - -- There is no support for explicitly killing singletons, which can be a serious issue in some contexts. For example, in a plug-in architecture where a plug-in can only be safely unloaded after all its objects have been cleaned up. - -- There is no order to the implicit cleanup of singletons at program exit. This can be troublesome for applications that contain singletons with interdependencies. When shutting down such applications, one singleton may access another that has already been destroyed. - -- Some of these shortcomings can be overcome by introducing additional mechanisms. However, this comes at the cost of additional complexity in code that could have been avoided by choosing an alternative design. - -Therefore, restrict your use of the Singleton pattern to the classes that truly must never be instantiated more than once. Don't use a singleton's global access point from arbitrary code. Instead, direct access to the singleton should be from only a few well-defined places, from where it can be passed around via its interface to other code. This other code is unaware, and so does not depend on whether a singleton or any other kind of class implements the interface. This breaks the dependencies that prevented unit testing and improves the maintainability. So, next time you are thinking about implementing or accessing a singleton, hopefully you'll pause, and think again. - -by [Sam Saariste](http://programmer.97things.oreilly.com/wiki/index.php/Sam_Saariste) \ No newline at end of file +چنین وابستگی‌هایی همچنین منجر به این خواهند شد که تست کردن نرم‌افزار با Unit Test که نیازمند وابستگی حداقلی مابین اجزای مختلف سورس‌کد است هم با مشکل مواجه شود. From 58da443858db35635ada355e099a22e9c7cbcf85 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 15:43:43 +0300 Subject: [PATCH 231/290] Added number 74 --- fr-IR/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fr-IR/SUMMARY.md b/fr-IR/SUMMARY.md index 4e86c27e..5826df6e 100644 --- a/fr-IR/SUMMARY.md +++ b/fr-IR/SUMMARY.md @@ -74,7 +74,7 @@ 1. [علوم انسانی بخوانید!](thing_71/README.md) 1. [تا حد ممکن دست به اختراع مجدد چرخ نزنید!](thing_72/README.md) 1. [در مقابل وسوسه الگوی Singleton مقاومت کنید](thing_73/README.md) -1. [مسیر(جاده ی) Performance مملو از بمب های کد کثیف است!](thing_74/README.md) +1. [وابستگی‌های زیاد دشمن ریفکتورینگ هستند!](thing_74/README.md) 1. [سادگی از اختصار می آید(کم گوی و گزیده گوی!)](thing_75/README.md) 1. [The Single Responsibility Principle](thing_76/README.md) 1. [با بله هم میتوانید شروع کنید!](thing_77/README.md) From 4d0d2ad3543e04ff0537ebfccbc3aeeb09f45ce8 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 15:43:59 +0300 Subject: [PATCH 232/290] Added number 74 --- fr-IR/thing_74/README.md | 14 ++++---------- 1 file changed, 4 insertions(+), 10 deletions(-) diff --git a/fr-IR/thing_74/README.md b/fr-IR/thing_74/README.md index 57f07fff..2233d18a 100644 --- a/fr-IR/thing_74/README.md +++ b/fr-IR/thing_74/README.md @@ -1,13 +1,7 @@ -# The Road to Performance Is Littered with Dirty Code Bombs +# وابستگی‌های زیاد دشمن ریفکتورینگ هستند! -More often than not, performance tuning a system requires you to alter code. When we need to alter code, every chunk that is overly complex or highly coupled is a dirty code bomb laying in wait to derail the effort. The first casualty of dirty code will be your schedule. If the way forward is smooth it will be easy to predict when you'll finish. Unexpected encounters with dirty code will make it very difficult to make a sane prediction. +در اغلب موارد، به‌ منظور دستیابی به پرفورمنس بیشتر، افزودن فیچرهای جدید و یا دیباگ کردن بخشی از نرم‌افزار بایستی کدها را دستکاری (ریفکتور) کرد اما این در حالی است که بخش‌هایی از کد که دارای Dependency (وابستگی‌) زیادی به دیگر بخش‌ها هستند تمام تلاش‌های ما را نقش بر آب خواهند کرد و هرچه این میزان وابستگی گسترده‌تر و ناواضح‌تر باشد، احتمال پی بردن به آن هم به‌ مراتب دشوارتر خواهد شد! -Consider the case where you find an execution hot spot. The normal course of action is to reduce the strength of the underlying algorithm. Let's say you respond to your manager's request for an estimate with an answer of 3-4 hours. As you apply the fix you quickly realize that you've broken a dependent part. Since closely related things are often necessarily coupled, this breakage is most likely expected and accounted for. But what happens if fixing that dependency results in other dependent parts breaking? Furthermore, the farther away the dependency is from the origin, the less likely you are to recognize it as such and account for it in your estimate. All of a sudden your 3-4 hour estimate can easily balloon to 3-4 weeks. Often this unexpected inflation in the schedule happens 1 or 2 days at a time. It is not uncommon to see "quick" refactorings eventually taking several months to complete. In these instances, the damage to the credibility and political capital of the responsible team will range from severe to terminal. If only we had a tool to help us identify and measure this risk. +به خاطر داشته باشیم که کدهای کثیف،‌ نامنظم و اسپاگتی هم اوضاع را بیش از پیش وخیم خواهند کرد به‌ طوری که وابستگی‌های زیاد در سورس‌کد به علاوهٔ کدهای اسپاگتی، یک تغییر کوچک که به نظر ۲ الی ۳ ساعت بیشتر زمان نمی‌برد، به یک فرایند دشوار، خسته‌کننده و گاهی‌اوقات غیرممکن چند هفته‌ای مبدل می‌سازد. -In fact, we have many ways of measuring and controlling the degree and depth of coupling and complexity of our code. Software metrics can be used to count the occurrences of specific features in our code. The values of these counts do correlate with code quality. Two of a number of metrics that measure coupling are fan-in and fan-out. Consider fan-out for classes: It is defined as the number of classes referenced either directly or indirectly from a class of interest. You can think of this as a count of all the classes that must be compiled before your class can be compiled. Fan-in, on the other hand, is a count of all classes that depend upon the class of interest. Knowing fan-out and fan-in we can calculate an instability factor using *I = fo / (fi + fo)*. As *I* approaches 0, the package becomes more stable. As *I* approaches 1, the package becomes unstable. Packages that are stable are low risk targets for recoding whereas unstable packages are more likely to be filled with dirty code bombs. The goal in refactoring is to move *I* closer to 0. - -When using metrics one must remember that they are only rules of thumb. Purely on math we can see that increasing *fi* without changing fo will move *I* closer to 0. There is, however, a downside to a very large fan-in value in that these class will be more difficult to alter without breaking dependents. Also, without addressing fan-out you're not really reducing your risks so some balance must be applied. - -One downside to software metrics is that the huge array of numbers that metrics tools produce can be intimidating to the uninitiated. That said, software metrics can be a powerful tool in our fight for clean code. They can help us to identify and eliminate dirty code bombs before they are a serious risk to a performance tuning exercise. - -By [Kirk Pepperdine](http://programmer.97things.oreilly.com/wiki/index.php/Kirk_Pepperdine) \ No newline at end of file +برای جلوگیری از مشکلاتی این چنین، می‌بایست در حین طراحی معماری نرم‌افزار تا حد ممکن میزان وابستگی‌ها را به حداقل رساند. گرچه به صفر رساندن میزان وابستگی عملاً غیرممکن است، اما هرچه میزان وابستگی مابین بخش‌های مختلف سورس‌کد کمتر باشد، و یا این وابستگی‌ها حداقل در حوزهٔ یک ماژول باشند و نه بیشتر، ریفکتورینگ کد به مراتب راحت‌تر خواهد شد. From 9022d4c1799e098fc43127f0ef8447161e7801d4 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 15:44:31 +0300 Subject: [PATCH 233/290] Added number 75 --- fr-IR/thing_75/README.md | 20 ++++---------------- 1 file changed, 4 insertions(+), 16 deletions(-) diff --git a/fr-IR/thing_75/README.md b/fr-IR/thing_75/README.md index c7b4f4a0..c37f2707 100644 --- a/fr-IR/thing_75/README.md +++ b/fr-IR/thing_75/README.md @@ -1,19 +1,7 @@ -# Simplicity Comes from Reduction +# هرچه تعداد خطوط کد کمتر، بهتر! -"Do it again...," my boss told me as his finger pressed hard on the delete key. I watched the computer screen with an all too familiar sinking feeling, as my code — line after line — disappeared into oblivion. +یکی از خصیصه‌های دولوپرهای تازه‌کار این است که به محض مواجه با یک مشکل و یا نیاز به افزودن یک فیچر جدید و دیگر کارهایی از این دست، سریعاً شروع به کدنویسی و افزودن بخش‌های جدیدی من‌جمله متغیرهای جدید، فانکشن‌های جدید و در یک کلام خطوط بیشتری به سورس‌کد می‌کنند که چنین خصیصه‌ای در نهایت منجر به حجیم شدن سورس‌کد و بالتبع پیچیدگی بیشتر آن می‌شود! -My boss, Stefan, wasn't always the most vocal of people, but he knew bad code when he saw it. And he knew exactly what to do with it. +چنین رویکردی در نهایت منجر به ایجاد سورسی می‌شود که بسیار پیچیده بوده و ریفکتور کردن آن در آینده، خواه توسط خود دولوپر و خواه توسط دیگر دولوپرها، کاری بس طاقت‌فرسا خواهد شد و کسی‌ که از خارج به چنین سورس‌کدی نگاه کند، به سادگی متوجه خواهد شد که توسط دولوپری غیرحرفه‌ای نوشته شده است. -I had arrived in my present position as a student programmer with lots of energy, plenty of enthusiasm but absolutely no idea how to code. I had this horrible tendency to think that the solution to every problem was to add in another variable some place. Or throw in another line. On a bad day, instead of the logic getting better with each revision, my code gradually got larger, more complex, and farther away from working consistently. - -It's natural, particularly when in a rush, to just want to make the most minimal changes to an existing block of code, even if it is awful. Most programmers will preserve bad code, fearing that starting anew will require significantly more effort than just going back to the beginning. That can be true for code that is close to working, but there is just some code that is beyond all help. - -More time gets wasted in trying to salvage bad work than it should. Once something becomes a resource sink, it needs to be discarded. Quickly. - -Not that one should easily toss away all of that typing, naming, and formatting. My boss's reaction was extreme, but it did force me to rethink the code on the second (or occasionally third) attempt. Still, the best approach to fixing bad code is to flip into a mode were the code is mercilessly refactored, shifted around, or deleted. - -The code should be simple. There should be a minimal number of variables, functions, declarations, and other syntactic language necessities. Extra lines, extra variables... extra *anything*, really, should be purged. Removed immediately. What's there, what's left, should only be just enough to get the job done, completing the algorithm or performing the calculations. Anything and everything else is just extra unwanted noise, introduced accidentally and obscuring the flow. Hiding the important stuff. - -Of course, if that doesn't do it then just delete it all and type it in over again. Drawing from one's memory in that way can often help cut through a lot of unnecessarily clutter. - -By [Paul W. Homer](http://programmer.97things.oreilly.com/wiki/index.php/Paul_W._Homer) \ No newline at end of file +لذا در حین کدنویسی می‌بایست تمام تلاش خود را به کار بست تا حداقل تعداد متغیر، کلاس، فانکشن و در یک کلام، حداقل تعداد خطوط کد را داشت. From 85b5dd622f2efae1013ce84196be12790d6a956a Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 15:46:07 +0300 Subject: [PATCH 234/290] Added number 76 --- fr-IR/thing_76/README.md | 51 ++++++++++++++++++++-------------------- 1 file changed, 25 insertions(+), 26 deletions(-) diff --git a/fr-IR/thing_76/README.md b/fr-IR/thing_76/README.md index 6929cc1b..19fc521c 100644 --- a/fr-IR/thing_76/README.md +++ b/fr-IR/thing_76/README.md @@ -1,41 +1,40 @@ -# The Single Responsibility Principle +# آشنایی با قانون Single Responsibility -One of the most foundational principles of good design is: +یکی از خصیصه‌های معماری نرم‌افزاری خوب این است که «چیزهایی که ماهیت مشابهی داشته، به دلایل یکسانی دستخوش تغییر می‌شوند و در یک کلام، به یک خانواده تعلق دارند را باید در کنار یکدیگر قرار داد و الباقی را مجزا ساخت.» -> Gather together those things that change for the same reason, and separate those things that change for different reasons. - -This principle is often known as the *Single Responsibility Principle* or SRP. In short, it says that a subsystem, module, class, or even a function, should not have more than one reason to change. The classic example is a class that has methods that deal with business rules, reports, and database: - -``` -public class Employee { - public Money calculatePay() ... - public String reportHours() ... - public void save() ... +از دید فنی، به چنین قابلیتی Single Responsibility Principle (اصل تک وظیفه‌ای) یا به طور خلاصه SRP گفته می‌شود. به عبارت دیگر، این اصل حاکی از آن است که یک ماژول، کلاس، فانکشن یا هر چیزی می‌بایست وظیفه‌ای واحد داشته، متمرکز بر یک تسک بوده و صرفاً به یک دلیل تغییر یابند نه اینکه به محض مواجه با یک نیاز در هر بخشی از نرم‌افزار، نیاز داشته باشیم تا آن را دستخوش تغییر سازیم. برای روشن‌تر شدن این مسأله، کلاسی فرضی تحت عنوان Employee که دارای ۳ فانکش مختلف است را در نظر می‌گیریم: +``` C# +public class Employee +{ + public function calculatePayment(); + public function reportHours(); + public function save(); } ``` +برخی برنامه‌نویسان بر این باورند از آنجا که این ۳ فانکشن به نوعی مرتبط با یکدیگر هستند، می‌بایست در قالب یک کلاس تعریف شوند اما این در حالی است که طبق قانون SRP، این ۳ فانکشن بنا به دلایلی کاملاً متفاوت ممکن است نیاز به تغییر کردن داشته باشند. برای مثال، فانکشن ()calculatePayment زمانی می‌بایست تغییر یابد که حقوق و مزیا کم‌ و زیاد شوند، فانکشن ()reportHours هم زمانی تغییر خواهد یافت که نحوهٔ گزارش‌دهی به مدیران تغییر کند و فانکشن ()save هم هر موقع که دیتابیس یا اسکمای برخی جداول تغییر یابد باید ریفکتور شود. -Some programmers might think that putting these three functions together in the same class is perfectly appropriate. After all, classes are supposed to be collections of functions that operate on common variables. However, the problem is that the three functions change for entirely different reasons. The `calculatePay` function will change whenever the business rules for calculating pay change. The `reportHours` function will change whenever someone wants a different format for the report. The save function will change whenever the DBAs change the database schema. These three reasons to change combine to make `Employee` very volatile. It will change for any of those reasons. More importantly, any classes that depend upon `Employee` will be affected by those changes. +می‌بینیم که ۳ دلیل مختلف برای تغییر یافتن فانکشن‌ها پیش‌ روی ما است و این باعث می‌گردد که کلاس Employee بنا به هر دلیلی و به خاطر تغییر در سیاست‌های مرتبط با هر یک از ۳ فانکشن زیرشاخه‌اش دستخوش تغییر قرار گیرد و نکتهٔ مهم‌تر اینکه اگر در دیگر بخش‌های کد وابستگی به این کلاس وجود داشته باشد و کلاس‌های دیگری از این کلاس ارث‌بری کرده باشند، آنها هم دستخوش تغییر خواهند شد! -Good system design means that we separate the system into components that can be independently deployed. Independent deployment means that if we change one component we do not have to redeploy any of the others. However, if `Employee` is heavily used by many other classes in other components, then every change to Employee is likely to cause the other components to be redeployed; thus negating a major benefit of component design (or SOA if you prefer the more trendy name). +یک معماری نرم‌افزاری خوب آن است که ما سورس‌کد را به بخش‌های مجزایی تقسیم‌بندی کنیم که بتوان هر یک از آن‌ها را به‌ طور مجزا و بدون وابستگی به سایر بخش‌ها مورد استفاده قرار داد. به عبارت دیگر، اگر ما بخشی را تغییر دادیم، دیگر بخش‌ها نیاز به هیچ‌گونه تغییری نداشته باشند. -``` -public class Employee { - public Money calculatePay() ... +اگر بخواهیم مجدد به مثال فوق بازگردیم، چنانچه کلاس Employee توسط دیگر کلاس‌های ماژول‌های مختلف پروژه استفاده شده باشد، بنابراین اعمال هرگونه تغییر در این کلاس، کلاس‌های دیگر را تحت‌الشعاع خود قرار خواهد داد که در بسیاری از مواقع منجر به ایجاد باگ می‌شود. حال اگر بخواهیم کلاس فوق را بر اساس قانون SRP ریفکتور کنیم، خواهیم داشت: +```C# +public class Employee +{ + public function calculatePayment(); } -public class EmployeeReporter { - public String reportHours(Employee e) ... +public class EmployeeReporter +{ + public function reportHours(); } -public class EmployeeRepository { - public void save(Employee e) ... +public class EmployeeRepository +{ + public function save(); } ``` +می‌بینیم که در کد فوق دارای ۳ کلاس مجزا از یکدیگر هستیم که هر کدام از آن‌ها متمرکز بر تسکی اختصاصی هستند. به عبارت دیگر، تمامی فانکشن‌های مرتبط با گزارش‌دهی را می‌توان در کلاس EmployeeReporter قرار داد، تمامی فانکشن‌های مرتبط با دیتابیس را در کلاس EmployeeRepository نوشت و هر آنچه که مرتبط با Business Rules (قوانین کاری) است را در کلاس Employee. -The simple partitioning shown above resolves the issues. Each of these classes can be placed in a component of its own. Or rather, all the reporting classes can go into the reporting component. All the database related classes can go into the repository component. And all the business rules can go into the business rule component. - -The astute reader will see that there are still dependencies in the above solution. That `Employee` is still depended upon by the other classes. So if `Employee` is modified, the other classes will likely have to be recompiled and redeployed. Thus, `Employee` cannot be modified and then independently deployed. However, the other classes can be modified and independently deployed. No modification of one of them can force any of the others to be recompiled or redeployed. Even `Employee` could be independently deployed through a careful use of the *Dependency Inversion Principle* (DIP), but that's a topic for a [different book](http://www.amazon.com/dp/0135974445/). - -Careful application of the SRP, separating things that change for different reasons, is one of the keys to creating designs that have an independently deployable component structure. +پیاده‌سازی اصولی SRP می‌تواند ضامن معماری‌های نرم‌افزاری خوبی باشد که در آن‌ها میزان Dependency (وابستگی) به صورت حداقلی بوده و اعمال یک تغییر در کد، منجر به ایجاد باگ در سایر بخش‌ها نخواهد شد. -by [Uncle Bob](http://programmer.97things.oreilly.com/wiki/index.php/Uncle_Bob) From 832f8720b757647e939b5117a6d340dcd45ce5fd Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 15:46:49 +0300 Subject: [PATCH 235/290] Added number 77 --- fr-IR/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fr-IR/SUMMARY.md b/fr-IR/SUMMARY.md index 5826df6e..72670b8d 100644 --- a/fr-IR/SUMMARY.md +++ b/fr-IR/SUMMARY.md @@ -77,7 +77,7 @@ 1. [وابستگی‌های زیاد دشمن ریفکتورینگ هستند!](thing_74/README.md) 1. [سادگی از اختصار می آید(کم گوی و گزیده گوی!)](thing_75/README.md) 1. [The Single Responsibility Principle](thing_76/README.md) -1. [با بله هم میتوانید شروع کنید!](thing_77/README.md) +1. [همه‌ چیز با یک آری شروع می‌شود!](thing_77/README.md) 1. [گامی به عقب و خودکارسازی، خودکارسازی، خودکارسازی](thing_78/README.md) 1. [از مزایای ابزارهای تحلیل کد بهره ببرید](thing_79/README.md) 1. [Test for Required Behavior, not Incidental Behavior](thing_80/README.md) From ad6a7621c63370f6bb09d1e2e38efdb7431d722f Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 15:47:12 +0300 Subject: [PATCH 236/290] Added number 77 --- fr-IR/thing_77/README.md | 24 ++++++++---------------- 1 file changed, 8 insertions(+), 16 deletions(-) diff --git a/fr-IR/thing_77/README.md b/fr-IR/thing_77/README.md index 41002b4b..791de60e 100644 --- a/fr-IR/thing_77/README.md +++ b/fr-IR/thing_77/README.md @@ -1,23 +1,15 @@ -# Start from Yes +# همه‌ چیز با یک آری شروع می‌شود! -Recently I was at a grocery store searching high and low for "edamame" (which I only vaguely knew was some kind of a vegetable). I wasn't sure whether this was something I'd find in the vegetable section, the frozen section, or in a can. I gave up and tracked down an employee to help me out. She didn't know either! +از یک دید کلی می‌توان پرسنل فروشگاه‌های را به ۲ گروه مختلف تقسیم‌بندی کرد: گروهی از فروشندگان که نیمهٔ پر لیوان را می‌بینند و گروه مقابل که صرفاً روی نیمهٔ خالی متمرکز هستند! به نظر می‌رسد که برای روشن‌تر شدن این مسأله، باید از یک مثال روزمره کمک گرفت. -The employee could have responded in many different ways. She could have made me feel ignorant for not knowing where to look, or given me vague possibilities, or even just told me they didn't have the item. But instead she treated the request as an opportunity to find a solution and help a customer. She called other employees and within minutes had guided me to the exact item, nestled in the frozen section. +وقتی که به یک فروشگاه زنجیره‌ای برای خرید می‌رویم، برخی فروشندگان هستند که وقتی سؤالی عجیب و غریب از ایشان می‌پرسیم، مثلاً نوعی شربت که بسیار کم‌مصرف است و فقط تعدادی فروشگاه خاص آن را عرضه می‌کنند، درخواست ما به عنوان یک مشتری را هرگز رد نکرده و فوراً با گفتن جمله‌ای همچون «خیر. متأسفانه ما این محصول را نداریم!» به قضیه فیصله نمی‌‌دهند بلکه این درخواست در ظاهر عجیب و غریب ما را به عنوان یک فرصت نگاه کرده،‌ اگر هم خودشان در این رابطه اطلاعی نداشته باشند از سایر همکارانشان کمک گرفته تا بلکه ایشان بتوانند راهنمایی کنند و در نهایت هم اگر کمکی از دست هیچ‌کس برنیاید، نام و مشخصات محصول مد نظرتان را گرفته تا برایتان تهیه کنند. -The employee in this case looked at a request and started from the premise that we would solve the problem and satisfy the request. She started from *yes* instead of starting from no. +در نقطهٔ مقابل این دست فروشندگان، گروهی دیگر قرار دارند که اصلاً مشتری‌مدار نیستند و صرفاً با گفتن جمله‌ای همچون «خیر. نداریم!» خود را خلاص می‌کنند. -When I was first placed in a technical leadership role, I felt that my job was to protect my beautiful software from the ridiculous stream of demands coming from product managers and business analysts. I started most conversations seeing a request as something to defeat, not something to grant. +پس از این مقایسه، حال قصد داریم نگاهی به رویکرد دولوپرها در تعامل با دیگر همکارانشان بیندازیم. در واقع، از یک دید کلی هم می‌توان دولوپرها را به گروه‌بندی مشابهی همانند آنچه در فروشگاه‌های زنجیره‌ای وجود دارد تقسیم کرد. برخی دولوپرها هرگونه پیشنهاد، اعمال ویژگی جدید و به طور کلی هر درخواستی را به عنوان دردسر می‌بینند و تمام تلاش خود را به کار می‌بندند تا آن را در نطفه خفه کنند! -At some point, I had an epiphany that maybe there was a different way to work that merely involved shifting my perspective from starting at no to starting at *yes*. In fact, I've come to believe that starting from *yes* is actually an essential part of being a technical leader. +در مقابل، برخی دولوپرها رویکردی به مراتب حرفه‌ای‌تر اتخاذ کرده و هرگونه پیشنهاد و درخواستی را به منزلهٔ فرصتی برای بهینه‌تر کردن نرم‌افزار یا اپلیکیشن و بهبود تجربه‌ٔ کاربری‌اش می‌بینند و این همان ویژگی‌ای است که یک دولوپر تمام عیار می‌بایست داشته باشد. -This simple change radically altered how I approached my job. As it turns out, there are a lot of ways to say *yes*. When someone says to you "Hey, this app would really be the bees knees if we made all the windows round and translucent!" you could reject it as ridiculous. But it's often better to start with "Why?" instead. Often there is some actual and compelling reason why that person is asking for round translucent windows in the first place. For example, you may be just about to sign a big new customer with a standards committee that mandates round translucent windows. +خیلی از اوقات با بله گفتن به درخواست‌هایی که از طرف مدیرعامل، مدیر محصول، مدیر پروژه، مشتری و یا حتی کاربران می‌آیند، اصلاً نیازی به کدزنی قابل‌توجهی نیست بلکه با چند تغییر کوچک، می‌توان به درخواست ارسال شده جامعهٔ عمل پوشید. -Usually you'll find that when you known the context of the request, new possibilities open up. It's common for the request to be accomplished with the existing product in some other way allowing you to say *yes* with no work at all: "Actually, in the user preferences you can download the round translucent windows skin and turn it on." - -Sometimes the other person will simply have an idea that you find incompatible with your view of the product. I find it's usually helpful to turn that "Why?" on yourself. Sometimes the act of voicing the reason will make it clear that your first reaction doesn't make sense. If not, you might need to kick it up a notch and bring in other key decision makers. Remember, the goal of all of this is to say *yes* to the other person and try to make it work, not just for him but for you and your team as well. - -If you can voice a compelling explanation as to why the feature request is incompatible with the existing product, then you are likely to have a productive conversation about whether you are building the right product. Regardless of how that conversation concludes, everyone will focus more sharply on what the product is, and what it is not. - -Starting from *yes* means working with your colleagues, not against them. - -By [Alex Miller](http://programmer.97things.oreilly.com/wiki/index.php/Alex_Miller) \ No newline at end of file +حال گاهی‌اوقات ممکن است با درخواست‌هایی مواجه شویم که در تضاد با استراتژی‌های توسعهٔ نرم‌افزار موجود است. اگر شما جزو آن دسته از دولوپرهایی هستید که ابتدا به ساکن کلمهٔ نه از زبانتان بیرون می‌آید، در چنین مواقعی سعی کنید سریع پاسخ ندادن را تمرین کنید و در صورت امکان، در حین فرایند تصمیم‌گیری به غیر از خودتان از دیگر اعضای تیم توسعهٔ نرم‌افزار هم بخواهید تا حضور داشته باشند تا بلکه بتوانند موضع‌گیری شما را تا حدی خنثی کنند و یا پاسخی منطقی در ارتباط با عدم امکان پیاده‌سازی قابلیت‌ مد نظر به طرف مقابل ارائه گردد. From 58476daec73c6023edcd24656eb21d5d056fa005 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 15:48:32 +0300 Subject: [PATCH 237/290] Added number 78 --- fr-IR/thing_78/README.md | 34 +++++++++------------------------- 1 file changed, 9 insertions(+), 25 deletions(-) diff --git a/fr-IR/thing_78/README.md b/fr-IR/thing_78/README.md index 735b373b..ada3d5ef 100644 --- a/fr-IR/thing_78/README.md +++ b/fr-IR/thing_78/README.md @@ -1,29 +1,13 @@ -# Step Back and Automate, Automate, Automate +# تا حد ممکن همه‌ چیز را خودکار کنید +اگرچه امروزه ابزارهای اتوماسیون توسعهٔ نرم‌افزار بسیار زیادی در اختیار دولوپرها قرار دارد، اما برخی از ایشان ترجیح می‌دهند که به جای استفاده از این ابزارها، کارها را به صورت دستی انجام دهند که شاید دلیل چنین مقاوتی، یکسری باورهای نادرست در مورد اتوماسیون باشد که مهم‌ترین آنها عبارتند از: -I worked with programmers who, when asked to produce a count of the lines of code in a module, pasted the files into a word processor and used its "line count" feature. And they did it again next week. And the week after. It was bad. +باور نادرست ۱: اتوماسیون صرفاً برای تست است +گرچه Automation (اتوماسیون) بیش از هر جای دیگری در فرایند تست نرم‌افزار صورت می‌گیرد اما این در حالی است که اگر اسکریپتی بنویسیم که بسیاری از کارهای روزمهٔ ما همچون گزارش‌گیری، مستندسازی، کامپایل، دیپلویمنت و … را انجام دهد، به مراتب از کلیک‌های ماوس قابل‌اعتمادتر است. -I worked on a project that had a cumbersome deployment process, involving code signing and moving the result to a server, requiring many mouse clicks. Someone automated it and the script ran hundreds of times during final testing, far more often than anticipated. It was good. +باور نادرست ۲: اگر از IDE استفاده کنیم، نیاز به اتوماسیون نداریم +IDEها دارای تنظیمات بسیار پیشرفته‌ای هستند که بسیاری از کارهای تکراری دولوپرها را انجام می‌دهند اما این در حالی است که به سختی می‌توان این تضمین را ایجاد کرد که در یک تیم توسعهٔ نرم‌افزار، تک‌تک دولوپرها از تنظیمات (Settings) یکسانی برخوردار باشند اما سیستم‌های اتوماسیون بیلدی همچون Ant (برای زبان برنامه‌نویسی جاوا)، iMacros و یا Selenium، به سادگی چنین امکانی را در اختیار ما قرار می‌دهند. -So, why do people do the same task over and over instead of stepping back and taking the time to automate it? +باور نادرست ۳: برای این کار، باید کار با ابزارهای زیادی را یاد گرفت +شما با استفاده از زبان‌های اسکریپت‌نویسی شل همچون بش یا پاورشل به سادگی می‌توانید دست به نوشتن اسکریپت‌هایی بزنید که کلیهٔ کارهای شما را خیلی سریع انجام دهند. -## Common misconception #1: Automation is only for testing. - -Sure, test automation is great, but why stop there? Repetitive tasks abound in any project: version control, compiling, building JAR files, documentation generation, deployment, and reporting. For many of these tasks, the script is mightier than the mouse. Executing tedious tasks becomes faster and more reliable. - -## Common misconception #2: I have an IDE, so I don't have to automate. - -Did you ever have a "But it (checks out|builds|passes tests) on my machine?" argument with your teammates? Modern IDEs have thousands of potential settings, and it is essentially impossible to ensure that all team members have identical configurations. Build automation systems such as Ant or Autotools give you control and repeatability. - -## Common misconception #3: I need to learn exotic tools in order to automate. - -You can go a long way with a decent shell language (such as bash or PowerShell) and a build automation system. If you need to interact with web sites, use a tool such as iMacros or Selenium. - -## Common misconception #4: I can't automate this task because I can't deal with these file formats. - -If a part of your process requires Word documents, spreadsheets, or images, it may indeed be challenging to automate it. But is that really necessary? Can you use plain text? Comma-separated values? XML? A tool that generates a drawing from a text file? Often, a slight tweak in the process can yield good results with a dramatic reduction in tediousness. - -## Common misconception #5: I don't have the time to figure it out. - -You don't have to learn all of bash or Ant to get started. Learn as you go. When you have a task that you think can and should be automated, learn just enough about your tools to do it. And do it early in a project when time is usually easier to find. Once you have been successful, you (and your boss) will see that it makes sense to invest in automation. - -By [Cay Horstmann](http://programmer.97things.oreilly.com/wiki/index.php/Cay_Horstmann) +علاوه بر این، برای اسکریپت‌نویسی شما اصلاً نیازی به یادگیری زیر و بم زبانی همچون Bash و یا ابزارهایی که پیش از این معرفی شدند ندارید. در چنین مواقعی، به محض نیاز به انجام کاری، تکنیک‌های مرتبط با همان کار را با سرچ در وب و مطالعهٔ منابع مختلف یاد بگیرید و اصلاً زمان خود را روی یادگیری از ۰ تا ۱۰۰ ابزار مد نظر نگذارید! From a0083311e1c84cc07dccf223213d1e478894ad9b Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 15:49:05 +0300 Subject: [PATCH 238/290] Added number 78 --- fr-IR/SUMMARY.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fr-IR/SUMMARY.md b/fr-IR/SUMMARY.md index 72670b8d..52e93721 100644 --- a/fr-IR/SUMMARY.md +++ b/fr-IR/SUMMARY.md @@ -76,9 +76,9 @@ 1. [در مقابل وسوسه الگوی Singleton مقاومت کنید](thing_73/README.md) 1. [وابستگی‌های زیاد دشمن ریفکتورینگ هستند!](thing_74/README.md) 1. [سادگی از اختصار می آید(کم گوی و گزیده گوی!)](thing_75/README.md) -1. [The Single Responsibility Principle](thing_76/README.md) +1. [آشنایی با قانون Single Responsibility](thing_76/README.md) 1. [همه‌ چیز با یک آری شروع می‌شود!](thing_77/README.md) -1. [گامی به عقب و خودکارسازی، خودکارسازی، خودکارسازی](thing_78/README.md) +1. [تا حد ممکن همه‌ چیز را خودکار کنید](thing_78/README.md) 1. [از مزایای ابزارهای تحلیل کد بهره ببرید](thing_79/README.md) 1. [Test for Required Behavior, not Incidental Behavior](thing_80/README.md) 1. [به طور دقیق و مشخص تست کنید](thing_81/README.md) From 1d62c67ada6f9a25c33a615cf72746cab91c4751 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 15:49:59 +0300 Subject: [PATCH 239/290] Added number 79 --- fr-IR/thing_79/README.md | 14 +++++--------- 1 file changed, 5 insertions(+), 9 deletions(-) diff --git a/fr-IR/thing_79/README.md b/fr-IR/thing_79/README.md index 0a7c883c..c6aa1420 100644 --- a/fr-IR/thing_79/README.md +++ b/fr-IR/thing_79/README.md @@ -1,13 +1,9 @@ -# Take Advantage of Code Analysis Tools +# شنایی با مزایای ابزارهای تحلیل سورس‌کد -The value of testing is something that is drummed into software developers from the early stages of their programming journey. In recent years the rise of unit testing, test-driven development, and agile methods has seen a surge of interest in making the most of testing throughout all phases of the development cycle. However, testing is just one of many tools that you can use to improve the quality of code. +در سال‌های اخیر شاهد آن بوده‌ایم که تست نرم‌افزار به بخشی لاینفک از فرایند توسعه مبدل شده است اما در عین حال، تست صرفاً یکی از ابزارهایی است که از آن طریق می‌توان کیفت کد را بهبود بخشید! -Back in the mists of time, when C was still a new phenomenon, CPU time and storage of any kind were at a premium. The first C compilers were mindful of this and so cut down on the number of passes through the code they made by removing some semantic analyses. This meant that the compiler checked for only a small subset of the bugs that could be detected at compile time. To compensate, Stephen Johnson wrote a tool called *lint* — which removes the fluff from your code — that implemented some of the static analyses that had been removed from its sister C compiler. Static analysis tools, however, gained a reputation for giving large numbers of false-positive warnings and warnings about stylistic conventions that aren't always necessary to follow. +از زمانی که زبان برنامه‌نویسی C یک پدیدهٔ تازه بود تا امروز که زبان‌های سطح‌بالای بسیاری وارد صنعت توسعهٔ نرم‌افزار شده‌اند، ابزارهای تحلیل کد روز به روز پیشرفت بیشتری کرده به طوری که امروزه این دست ابزارها قدرت تحلیل به مراتب بیشتری نسبت به نمونه‌های اولیهٔ‌شان دارند. -The current landscape of languages, compilers, and static analysis tools is very different. Memory and CPU time are now relatively cheap, so compilers can afford to check for more errors. Almost every language boasts at least one tool that checks for violations of style guides, common gotchas, and sometimes cunning errors that can be difficult to catch, such as potential null pointer dereferences. The more sophisticated tools, such as Splint for C or Pylint for Python, are configurable, meaning that you can choose which errors and warnings the tool emits with a configuration file, via command line switches, or in your IDE. Splint will even let you annotate your code in comments to give it better hints about how your program works. +مثلاً ابزاری همچون Pylint که برای تحلیل کدهای Python به کار می‌رود یا ابزار Splint برای زبان C، این امکان را به دولوپر می‌دهند که تنظیم کند چه نوع هشدارها، ارورها و خطاهایی در معرض دیدش قرار گیرند. -If all else fails, and you find yourself looking for simple bugs or standards violations which are not caught by your compiler, IDE, or lint tools, then you can always roll your own static checker. This is not as difficult as it might sound. Most languages, particularly ones branded *dynamic*, expose their abstract syntax tree and compiler tools as part of their standard library. It is well worth getting to know the dusty corners of standard libraries that are used by the development team of the language you are using, as these often contain hidden gems that are useful for static analysis and dynamic testing. For example, the Python standard library contains a disassembler which tells you the bytecode used to generate some compiled code or code object. This sounds like an obscure tool for compiler writers on the python-dev team, but it is actually surprisingly useful in everyday situations. One thing this library can disassemble is your last stack trace, giving you feedback on exactly which bytecode instruction threw the last uncaught exception. - -So, don't let testing be the end of your quality assurance — take advantage of analysis tools and don't be afraid to roll your own. - -By [Sarah Mount](http://programmer.97things.oreilly.com/wiki/index.php/Sarah_Mount) \ No newline at end of file +به طور کلی، امروزه در کنار تست نرم‌افزار نیاز به فاز دیگری تحت عنوان تحلیل هم داریم تا این اطمینان را حاصل کنیم که کدها بهینه هستند، مقدار استفاده از منابع سیستمی در بهترین حالت ممکن قرار دارند و در نهایت کدی که نوشته شده است، بهترین کدی است که می‌توانست وجود داشته باشد! From f4a1af964cec3a1b88a26c76200ec2e039fb3157 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 15:50:39 +0300 Subject: [PATCH 240/290] Added number 80 --- fr-IR/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fr-IR/SUMMARY.md b/fr-IR/SUMMARY.md index 52e93721..7c04db5a 100644 --- a/fr-IR/SUMMARY.md +++ b/fr-IR/SUMMARY.md @@ -80,7 +80,7 @@ 1. [همه‌ چیز با یک آری شروع می‌شود!](thing_77/README.md) 1. [تا حد ممکن همه‌ چیز را خودکار کنید](thing_78/README.md) 1. [از مزایای ابزارهای تحلیل کد بهره ببرید](thing_79/README.md) -1. [Test for Required Behavior, not Incidental Behavior](thing_80/README.md) +1. [در تست نرم‌افزار فقط رفتار مورد انتظار را بسنجید](thing_80/README.md) 1. [به طور دقیق و مشخص تست کنید](thing_81/README.md) 1. [تست هنگام خواب (و آخر هفته ها)](thing_82/README.md) 1. [Testing Is the Engineering Rigor of Software Development](thing_83/README.md) From 04e634fd13e33e6cb2930da4e95d9def2748b994 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 15:51:00 +0300 Subject: [PATCH 241/290] Added number 80 --- fr-IR/thing_80/README.md | 16 +++++----------- 1 file changed, 5 insertions(+), 11 deletions(-) diff --git a/fr-IR/thing_80/README.md b/fr-IR/thing_80/README.md index b07f1bff..abc9de39 100644 --- a/fr-IR/thing_80/README.md +++ b/fr-IR/thing_80/README.md @@ -1,15 +1,9 @@ -# Test for Required Behavior, not Incidental Behavior +# در تست نرم‌افزار فقط رفتار مورد انتظار را بسنجید -A common pitfall in testing is to assume that exactly what an implementation does is precisely what you want to test for. At first glance this sounds more like a virtue than a pitfall. Phrased another way, however, the issue becomes more obvious: A common pitfall in testing is to hardwire tests to the specifics of an implementation, where those specifics are incidental and have no bearing on the desired functionality. +یکی از دام‌هایی که دولوپرها در حین تست نرم‌افزار در آن گرفتار می‌شوند این است که بر این باورند آنچه نرم‌افزار انجام می‌دهد دقیقاً همان تسکی است که قصد تست آن را دارند. گرچه در ظاهر چنین چیزی اصلاً دام تلقی نمی‌شود اما اگر کمی بیشتر این موضوع را بشکافیم، منظور واضح‌تر بیان گردد: یک اشتباه رایج در فرایند تست نرم‌افزار این است که تست را برای خصوصیات جانبی نسخهٔ مد نظر نرم‌افزار نوشت و این در حالی است چنین خصوصیاتی جانبی بوده و خیلی سنخیتی با رفتاری از نرم‌افزار که قصد سنجش آن را داریم ندارند! -When tests are hardwired to implementation incidentals, changes to the implementation that are actually compatible with the required behavior may cause tests to fail, leading to false positives. Programmers typically respond either by rewriting the test or by rewriting the code. Assuming that a false positive is actually a true positive is often a consequence of fear, uncertainty, or doubt. It has the effect of raising the status of incidental behavior to required behavior. In rewriting a test, programmers either refocus the test on the required behavior (good) or simply hardwire it to the new implementation (not good). Tests need to be sufficiently precise, but they also need to be accurate. +در چنین شرایطی، یعنی زمانی‌ که تست‌ها به گونه‌ای نوشته می‌شوند که با برخی خصوصیات جانبی نرم‌افزار هماهنگ شده باشند، اعمال تغییرات روی بخش‌هایی از نرم‌افزار که مرتبط با رفتاری است که قرار آن را تست کنیم، منجر به شکست تست می‌شود. در چنین شرایطی، دولوپرها معمولاً یا دست به ریفکتورینگ کد می‌زنند و یا تست را مجدد می‌نویسند که چنین کاری اوضاع را خراب‌تر می‌کند بلکه توصیه می‌شود مشکل ریشه‌ای حل گردد. -For example, in a three-way comparison, such as C's `strcmp` or Java's `String.compareTo`, the requirements on the result are that it is negative if the left-hand side is less than the right, positive if the left-hand side is greater than the right, and zero if they are considered equal. This style of comparison is used in many APIs, including the comparator for C's `qsort` function and `compareTo` in Java's `Comparable` interface. Although the specific values `-1` and `+1` are commonly used in implementations to signify *less than* and *greater than*, respectively, programmers often mistakenly assume that these values represent the actual requirement and consequently write tests that nail this assumption up in public. +برای روشن‌تر شدن این مسأله مثالی می‌زنیم. اگر تستی بنویسیم که علاوه بر سنجش رفتار نرم‌افزار، مثلاً جایگاه قرارگیری اِلِمان‌های روی صفحه را نیز بسنجد، اگر به هر دلیلی تغییری در رابط کاربری بدهیم و سپس نرم‌افزار را تست کنیم، تست ما با شکست مواجه می‌شود و این در حالی است که مد نظر قرار دادن چنین مسائل جانبی و به نوعی حاشیه‌ای، صرفاً به پیچیده‌تر کردن تست‌ها منجر شده و احتمال بروز شکست آنها را بیشتر خواهد کرد. -A similar issue arises with tests that assert spacing, precise wording, and other aspects of textual formatting and presentation that are incidental. Unless you are writing, for example, an XML generator that offers configurable formatting, spacing should not be significant to the outcome. Likewise, hardwiring placement of buttons and labels on UI controls reduces the option to change and refine these incidentals in future. Minor changes in implementation and inconsequential changes in formatting suddenly become build breakers. - -Overspecified tests are often a problem with whitebox approaches to unit testing. Whitebox tests use the structure of the code to determine the test cases needed. The typical failure mode of whitebox testing is that the tests end up asserting that the code does what the code does. Simply restating what is already obvious from the code adds no value and leads to a false sense of progress and security. - -To be effective, tests need to state contractual obligations rather than parrot implementations. They need to take a blackbox view of the units under test, sketching out the interface contracts in executable form. Therefore, align tested behavior with required behavior. - -By [Kevlin Henney](http://programmer.97things.oreilly.com/wiki/index.php/Kevlin_Henney) \ No newline at end of file +با این تفاسیر، توصیه می‌شود که در حین نوشتن Unit Test، صرفاً رفتاری که از نرم‌افزار یا اپلیکیشن انتظار داریم را تست کنیم نه مسائل حاشیه‌ای که عملاً تغییری در رفتار اپلیکیشن ایجاد نمی‌کنند. From 452d743c6b17124ded3eb0a7992a85892ddbae66 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 15:51:51 +0300 Subject: [PATCH 242/290] Added number 81 --- fr-IR/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fr-IR/SUMMARY.md b/fr-IR/SUMMARY.md index 7c04db5a..43f20b6c 100644 --- a/fr-IR/SUMMARY.md +++ b/fr-IR/SUMMARY.md @@ -81,7 +81,7 @@ 1. [تا حد ممکن همه‌ چیز را خودکار کنید](thing_78/README.md) 1. [از مزایای ابزارهای تحلیل کد بهره ببرید](thing_79/README.md) 1. [در تست نرم‌افزار فقط رفتار مورد انتظار را بسنجید](thing_80/README.md) -1. [به طور دقیق و مشخص تست کنید](thing_81/README.md) +1. [تست‌ها علاوه بر صحیح بودن، می‌بایست دقیق هم باشند](thing_81/README.md) 1. [تست هنگام خواب (و آخر هفته ها)](thing_82/README.md) 1. [Testing Is the Engineering Rigor of Software Development](thing_83/README.md) 1. [Thinking in States](thing_84/README.md) From 56221e68ab19f5033cdad21dd585e60ebd6cf66b Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 15:52:31 +0300 Subject: [PATCH 243/290] Added number 81 --- fr-IR/thing_81/README.md | 43 ++++++++++------------------------------ 1 file changed, 10 insertions(+), 33 deletions(-) diff --git a/fr-IR/thing_81/README.md b/fr-IR/thing_81/README.md index b8388bdb..bde6e762 100644 --- a/fr-IR/thing_81/README.md +++ b/fr-IR/thing_81/README.md @@ -1,45 +1,22 @@ -# Test Precisely and Concretely +# تست‌ها علاوه بر صحیح بودن، می‌بایست دقیق هم باشند +در آموزش قبل گفتیم که در حین فرایند تست نرم‌افزار، ضروری است که عملکرد مورد انتظار از نرم‌افزار را تست کرد تا اینکه خصوصیات جانبی و حاشیه‌ای نرم‌افزار که ربطی هم به عملکردش ندارند مورد ارزیابی قرار گیرند اما این در حالی است که این سوء‌تفاهم نمی‌بایست پیش بیاید که تست‌های نرم‌افزاری می‌توانند کلی و دقیق نباشند! به‌ عنوان یک قانون کلی، یک تست خوب می‌بایست دقت و درستی عملکرد کد را بسنجد. -It is important to test for the desired, essential behavior of a unit of code, rather than test for the incidental behavior of its particular implementation. But this should not be taken or mistaken as an excuse for vague tests. Tests need to be both accurate *and* precise. - -Something of a tried, tested, and testing classic, sorting routines offer an illustrative example. Implementing a sorting algorithm is not necessarily an everyday task for a programmer, but sorting is such a familiar idea that most people believe they know what to expect from it. This casual familiarity, however, can make it harder to see past certain assumptions. - -When programmers are asked "What would you test for?" by far and away the most common response is "The result of sorting is a sorted sequence of elements." While this is true, it is not the whole truth. When prompted for a more precise condition, many programmers add that the resulting sequence should be the same length as the original. Although correct, this is still not enough. For example, given the following sequence: +برای روشن‌تر شدن این مسأله، مثالی از دنیای واقعی برنامه‌نویسی می‌زنیم. الگوریتم سورت کردن یکسری داده (مثلاً از بزرگ به کوچک یا به ترتیب حروف الفبا) چیزی است که معمولاً دولوپرها با آن سروکار دارند. وقتی از دولوپری این سؤال پرسیده شود که هدف از تست چنین الگوریتمی چیست، پاسخی که معمولاً با آن مواجه می‌شویم این است که «داده‌ها باید به درستی یا از بزرگ به کوچک و با بالعکس سورت شوند». +گرچه چنین پاسخی کاملاً درست است، اما تمام ماجرا نیست! در واقع، یک تست دقیق برای سنجش چنین الگوریتمی این‌گونه عمل می‌کند که پس از سورت شدن، طول عناصر آرایهٔ مد نظر می‌بایست با طول آرایه قبل از سورت شدن یکسان باشد. گرچه چنین دیدگاهی درست است،‌ اما باز هم کافی نیست! به عنوان نمونه داریم: ``` 3 1 4 1 5 9 ``` - -The following sequence satisfies a postcondition of being sorted in non-descending order and having the same length as the original sequence: - +خروجی زیر مجموعه اعدادی را نشان می‌دهد که هم از نظر طول با آرایهٔ اورجینال برابری می‌کند و هم اعداد از کوچک به بزرگ سورت شده‌اند: ``` 3 3 3 3 3 3 ``` +اما می‌بینیم که تک‌تک المان‌های آرایه در خروجی وجود ندارند. این مثال برگرفته از کدی واقعی است که خوشبختانه پیش از ریلیس، باگ آن رفع شد؛ در واقع،‌ مشکل از اینجا ناشی می‌شد که کل خروجی با اولین عضو آرایه (عدد ۳) پر می‌شد. -Although it satisfies the spec, it is also most certainly not what was meant! This example is based on an error taken from real production code (fortunately caught before it was released), where a simple slip of a keystroke or a momentary lapse of reason led to an elaborate mechanism for populating the whole result with the first element of the given array. - -The full postcondition is that the result is sorted and that it holds a permutation of the original values. This appropriately constrains the required behavior. That the result length is the same as the input length comes out in the wash and doesn't need restating. - -Even stating the postcondition in the way described is not enough to give you a good test. A good test should be readable. It should be comprehensible and simple enough that you can see readily that it is correct (or not). Unless you already have code lying around for checking that a sequence is sorted and that one sequence contains a permutation of values in another, it is quite likely that the test code will be more complex than the code under test. As Tony Hoare observed: - -> There are two ways of constructing a software design: One way is to make it so simple that there are *obviously* no deficiencies and the other is to make it so complicated that there are no obvious deficiencies. - -Using concrete examples eliminates this accidental complexity and opportunity for accident. For example, given the following sequence: - -``` -3 1 4 1 5 9 -``` - -The result of sorting is the following: - -``` -1 1 3 4 5 9 -``` - -No other answer will do. Accept no substitutes. +پس ما می‌بایست تستی می‌نوشتیم که بسنجد کلیهٔ اعضای آرایه سورت شده، طول آن‌ها برابر با آرایهٔ اصلی باشد و از همه مهم‌تر، اعضا دقیقاً همان اعضای اورجینال باشند. -Concrete examples helps to illustrate general behavior in an accessible and unambiguous way. The result of adding an item to an empty collection is not simply that it is not empty: It is that the collection now has a single item. And that the single item held is the item added. Two or more items would qualify as not empty. And would also be wrong. A single item of a different value would also be wrong. The result of adding a row to a table is not simply that the table is one row bigger. It also entails that the row's key can be used to recover the row added. And so on. +اگر بخواهیم تستی به معنای واقعی کلمه حرفه‌ای بنویسیم، باز هم شرایط توصیف شدهٔ بالا کفایت نمی‌کنند! در حقیقت، یک تست خوب باید خوانا، قابل‌فهم و در عین حال ساده باشد تا یک تستر به سادگی بتواند متوجه شود که آیا نتیجهٔ آن درست است یا غلط به طوری که یک دولوپر صاحب‌نام به اسم Hoare در این باره می‌گوید: -In specifying behavior, tests should not simply be accurate: They must also be precise. +به‌طورکلی ۲ راه برای طراحی معماری یک نرم‌افزار وجود داره؛ راه اول این‌که آن‌قدر آن‌را ساده طراحی کنی که هیچ نقصی در آن وجود نداشته باشه و راه دوم این‌که آن‌قدر آن‌را پیچیده طراحی کنی که هیچ نقصی آشکارا در آن دیده نشه! -By [Kevlin Henney](http://programmer.97things.oreilly.com/wiki/index.php/Kevlin_Henney) \ No newline at end of file +با این تفاسیر، به این نتیجه می‌رسیم که تست نرم‌افزاری در صنعت برنامه‌نویسی که روز به روز شاهد اپلیکیشن‌های پیچیده‌‌تری در آن هستیم الزامی است اما این در حالی است که تست‌ها علاوه بر سنجش صحت نرم‌افزار یا اپلیکیشن، می‌بایست دقیق هم باشند. From f34b282d9ac544ec1f0b93e9b16c194b72602aeb Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 15:53:31 +0300 Subject: [PATCH 244/290] Added number 82 --- fr-IR/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fr-IR/SUMMARY.md b/fr-IR/SUMMARY.md index 43f20b6c..cc59689f 100644 --- a/fr-IR/SUMMARY.md +++ b/fr-IR/SUMMARY.md @@ -82,7 +82,7 @@ 1. [از مزایای ابزارهای تحلیل کد بهره ببرید](thing_79/README.md) 1. [در تست نرم‌افزار فقط رفتار مورد انتظار را بسنجید](thing_80/README.md) 1. [تست‌ها علاوه بر صحیح بودن، می‌بایست دقیق هم باشند](thing_81/README.md) -1. [تست هنگام خواب (و آخر هفته ها)](thing_82/README.md) +1. [تست نرم‌افزار و سورس‌کد را آخر شب‌ها و آخر هفته‌ها انجام دهید!](thing_82/README.md) 1. [Testing Is the Engineering Rigor of Software Development](thing_83/README.md) 1. [Thinking in States](thing_84/README.md) 1. [دو تا مغز بهتر ایک مغز است!](thing_85/README.md) From e50cccac8f9bda45c76325101c0be7d6851cf866 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 15:53:49 +0300 Subject: [PATCH 245/290] Added number 82 --- fr-IR/thing_82/README.md | 16 ++++------------ 1 file changed, 4 insertions(+), 12 deletions(-) diff --git a/fr-IR/thing_82/README.md b/fr-IR/thing_82/README.md index 9f171cc6..0bde86eb 100644 --- a/fr-IR/thing_82/README.md +++ b/fr-IR/thing_82/README.md @@ -1,15 +1,7 @@ -# Test While You Sleep (and over Weekends) +# تست نرم‌افزار و سورس‌کد را آخر شب‌ها و آخر هفته‌ها انجام دهید! -Relax. I am not referring to offshore development centers, overtime on weekends, or working the night shift. Rather, I want to draw your attention to how much computing power we have at our disposal. Specifically, how much we are not harnessing to make our lives as programmers a little easier. Are you constantly finding it difficult to get enough computing power during the work day? If so, what are your test servers doing outside of normal work hours? More often than not, the test servers are idling overnight and over the weekend. You can use this to your advantage. +یکی از مسائلی که باعث می‌گردد دولوپرها پیش از تست کردن تغییرات خود، اقدام به کامیت آنها روی یک سیستم ورژن کنترل همچون گیت کنند این است که معمولاً تست‌ها زمان قابل‌توجهی برای تکمیل شدن به خود اختصاص می‌دهند. به همین دلیل، توصیه می‌شود که از زمان‌هایی که کار نمی‌کنید، مثل شب‌ها و آخر هفته‌ها، برای کارهای اتوماسیون همچون تست‌های طولانی و زمان‌بر استفاده نمایید و به سادگی صبح روز بعد خواهید توانست نتایج، لاگ‌ها و غیره را مشاهده کنید. -- *Have you been guilty of committing a change without running all the tests?* One of the main reasons programmers don't run test suites before committing code is because of the length of time they may take. When deadlines are looming and push comes to shove, humans naturally start cutting corners. One way to address this is to break down your large test suite into two or more profiles. A smaller, mandatory test profile that is quick to run, will help to ensure that tests are run before each commit. All of the test profiles (including the mandatory profile — just to be sure) can be automated to run overnight, ready to report their results in the morning. +نکته‌ای که در ارتباط با تست نرم‌افزار در زمان‌های فوق‌الذکر وجود دارد این است که شبکه و همچنین سرورها در چنین زمان‌هایی بار و فشار زیادی رویشان نبوده و بالتبع با سرعت‌ بیشتری می‌توانند تسک‌های در نظر گرفته شده را تکمیل کنند. -- *Have you had enough opportunity to test the stability of your product?* Longer-running tests are vital for identifying memory leaks and other stability issues. They are seldom run during the day as it will tie up time and resources. You could automate a soak test to be run during the night, and a bit longer over the weekend. From 6.00 pm Friday to 6.00 am the following Monday there are 60 hours worth of potential testing time. - -- *Are you getting quality time on your Performance testing environment?* I have seen teams bickering with each other to get time on the performance testing environment. In most cases neither team gets enough quality time during the day, while the environment is virtually idle after hours. The servers and the network are not as busy during the night or over the weekend. It's an ideal time to run some quality performance tests. - -- *Are there too many permutations to test manually?* In many cases your product is targeted to run on a variety of platforms. For example, both 32-bit and 64-bit, on Linux, Solaris, and Windows, or simply on different versions of the same operating system. To make matters worse, many modern applications expose themselves to a plethora of transport mechanisms and protocols (HTTP, AMQP, SOAP, CORBA, etc.). Manually testing all of these permutations is very time consuming and most likely done close to a release due to resource pressure. Alas, it may be too late in the cycle to catch certain nasty bugs. - -Automated tests run during the night or over weekends will ensure all these permutations are tested more often. With a little bit of thinking and some scripting knowledge, you can schedule a few *cron* jobs to kick off some testing at night and over the weekend. There are also many testing tools out there that could help. Some organizations even have server grids that pool servers across different departments and teams to ensure that resources are utilized efficiently. If this is available in your organization, you can submit tests to be run at night or over weekends. - -by [Rajith Attapattu](http://programmer.97things.oreilly.com/wiki/index.php/Rajith_Attapattu) \ No newline at end of file +با انجام کمی محاسبات و برخورداری از دانشی نسبی در مورد اسکریپت‌نویسی، می‌توان به سادگی تعدادی کرون جاب ایجاد کرد تا تست‌های مدنظرمان را در شب‌ها، آخر هفته‌ها و دیگر روزهای تعطیل رسمی تکمیل کنند. From 0ef2dcf2f6d8ddcc59c70e55e991847fc4012c20 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 15:54:29 +0300 Subject: [PATCH 246/290] Added number 83 --- fr-IR/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fr-IR/SUMMARY.md b/fr-IR/SUMMARY.md index cc59689f..6c65911d 100644 --- a/fr-IR/SUMMARY.md +++ b/fr-IR/SUMMARY.md @@ -83,7 +83,7 @@ 1. [در تست نرم‌افزار فقط رفتار مورد انتظار را بسنجید](thing_80/README.md) 1. [تست‌ها علاوه بر صحیح بودن، می‌بایست دقیق هم باشند](thing_81/README.md) 1. [تست نرم‌افزار و سورس‌کد را آخر شب‌ها و آخر هفته‌ها انجام دهید!](thing_82/README.md) -1. [Testing Is the Engineering Rigor of Software Development](thing_83/README.md) +1. [مقایسه‌ای مابین مهندسین نرم‌افزار و دیگر مهندسان](thing_83/README.md) 1. [Thinking in States](thing_84/README.md) 1. [دو تا مغز بهتر ایک مغز است!](thing_85/README.md) 1. [دو اشتباه می توانند یک بخش درست ایجاد کنند! (و رفع آنها دشوار است)](thing_86/README.md) From 5ab4ec3a90f4b726a8ed594c1b0ba5407ad1cd5f Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 15:54:53 +0300 Subject: [PATCH 247/290] Added number 83 --- fr-IR/thing_83/README.md | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/fr-IR/thing_83/README.md b/fr-IR/thing_83/README.md index c3fe3d09..261ac4bb 100644 --- a/fr-IR/thing_83/README.md +++ b/fr-IR/thing_83/README.md @@ -1,11 +1,7 @@ -# Testing Is the Engineering Rigor of Software Development +# مقایسه‌ای مابین مهندسین نرم‌افزار و دیگر مهندسان -Developers love to use tortured metaphors when trying to explain what it is they do to family members, spouses, and other non-techies. We frequently resort to bridge building and other "hard" engineering disciplines. All these metaphors fall down quickly, though, when you start trying to push them too hard. It turns out that software development is *not* like many of the "hard" engineering disciplines in lots of important ways. +مهندسانی همچون متخصصین راه و ساختمان، مکانیک‌ها و غیره در طول صدها سال بر اساس قوانین ریاضیات و فیزیک، به یکسری اصول و اصطلاحاً Best Practice دست یافته‌اند که می‌تواند ساخته‌‌های ایشان را ایمن سازد. به طور مثال، وقتی که یک مهندس راه و ساختمان پلی می‌سازد، تست آن پل بدین گونه خواهد بود که ماشینی با بار سنگین از روی آن عبور می‌دهند و چناچه پل بدون هیچ‌گونه لغزش و سستی پابرجا باقی بماند، این بدان معنا است که مهندسی به درستی کارش را انجام داده است. -Compared to "hard" engineering, the software development world is at about the same place the bridge builders were when the common strategy was to build a bridge and then roll something heavy over it. If it stayed up, it was a good bridge. If not, well, time to go back to the drawing board. Over the past few thousand years, engineers have developed mathematics and physics they can use for a structural solution without having to build it to see what it does. We don't have anything like that in software, and perhaps never will because software is in fact very different. For a deep-dive exploration of the comparison between software "engineering" and regular engineering, ["What is Software Design?"](http://www.developerdotstar.com/mag/articles/reeves_design.html), written by Jack Reeves in *C++ Journal* in 1992, is a classic. Even though it was written almost two decades ago, it is still remarkably accurate. He painted a gloomy picture in this comparison, but the thing that was missing in 1992 was a strong testing ethos for software. +خوشبختانه یا متأسفانه در مهندسی نرم‌افزار تست محصول بدین گونه نخواهد بود چرا که ماهیت مهندسی نرم‌افزار با گونه‌های دیگر مهندسی کاملاً متفاوت است. وقتی پای اطمینان حاصل کردن از خروجی کار به میان می‌آید، هیچ‌وقت از یک مدیر پروژهٔ راه و ساختمان جمله‌ای همچون «ما زمان کافی برای تست این پل نداریم» نخواهیم شنید اما متأسفانه بسیاری از مدیران پروژه در صنعت توسعهٔ نرم‌افزار به خاطر وجود ددلاین‌های فشرده و گاهی‌اوقات غیرواقعی، اهمیت تست‌ نهایی نرم‌افزار را نادیده گرفته و تمام تمرکزشان روی این موضوع است که پروژه هرچه سریع‌تر به دست مشتری برسد. -Testing "hard" things is tough because you have to build them to test them, which discourages speculative building just to see what will happen. But the building process in software is ridiculously cheap. We've developed an entire ecosystem of tools that make it easy to do just that: unit testing, mock objects, test harnesses, and lots of other stuff. Other engineers would love to be able to build something and test it under realistic conditions. As software developers, we should embrace testing as the primary (but not the only) verification mechanism for software. Rather than waiting for some sort of calculus for software, we already have the tools at our disposal to ensure good engineering practices. Viewed in this light, we now have ammunition against managers who tell us "We don't have time to test." A bridge builder would never hear from their boss "Don't bother doing structural analysis on that building — we have a tight deadline." The recognition that testing is indeed the path to reproducibility and quality in software allows us as developers to push back on arguments against it as professionally irresponsible. - -Testing takes time, just like structural analysis takes time. Both activities ensure the quality of the end product. It's time for software developers to take up the mantle of responsibility for what they produce. Testing alone isn't sufficient, but it is necessary. Testing * **is** * the engineering rigor of software development. - -By [Neal Ford](http://programmer.97things.oreilly.com/wiki/index.php/Neal_Ford) \ No newline at end of file +در چنین شرایطی، این وظیفهٔ دولوپرها است که تحت هیچ شرایطی زیر بار ریلیس کردن نرم‌افزار بدون تست کامل و جامع آن نروند. در واقع، تست نرم‌افزار نه تنها کافی نیست، بلکه ضروری هم هست و دولوپرهای حرفه‌ای می‌توانند با ابزارهای تستی که امروزه به بازار عرضه شده‌اند و بسیاری از کارهای دولوپرها را به صورت خودکار انجام می‌دهند خود را از دیگر دولوپرهای غیرحرفه‌ای متمایز سازند. From 770e4701aa92b7396f3cdce0129ada583966acc2 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 15:55:31 +0300 Subject: [PATCH 248/290] Added number 84 --- fr-IR/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fr-IR/SUMMARY.md b/fr-IR/SUMMARY.md index 6c65911d..98c05539 100644 --- a/fr-IR/SUMMARY.md +++ b/fr-IR/SUMMARY.md @@ -84,7 +84,7 @@ 1. [تست‌ها علاوه بر صحیح بودن، می‌بایست دقیق هم باشند](thing_81/README.md) 1. [تست نرم‌افزار و سورس‌کد را آخر شب‌ها و آخر هفته‌ها انجام دهید!](thing_82/README.md) 1. [مقایسه‌ای مابین مهندسین نرم‌افزار و دیگر مهندسان](thing_83/README.md) -1. [Thinking in States](thing_84/README.md) +1. [از نوشتن کدهای اضافی پرهیز کنید](thing_84/README.md) 1. [دو تا مغز بهتر ایک مغز است!](thing_85/README.md) 1. [دو اشتباه می توانند یک بخش درست ایجاد کنند! (و رفع آنها دشوار است)](thing_86/README.md) 1. [Ubuntu Coding for Your Friends](thing_87/README.md) From 9b07d455f9c12656dc10271154ea3b3043f33e09 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 15:56:29 +0300 Subject: [PATCH 249/290] Added number 84 --- fr-IR/thing_84/README.md | 55 +++++++++++++++------------------------- 1 file changed, 20 insertions(+), 35 deletions(-) diff --git a/fr-IR/thing_84/README.md b/fr-IR/thing_84/README.md index 687c0b96..89101b2b 100644 --- a/fr-IR/thing_84/README.md +++ b/fr-IR/thing_84/README.md @@ -1,39 +1,24 @@ -# Thinking in States - -People in the real world have a weird relationship with state. This morning I stopped by the local store to prepare for another day of converting caffeine to code. Since my favorite way of doing that is by drinking latte, and I couldn't find any milk, I asked the clerk. - -"Sorry, we're super-duper, mega-out of milk." - -To a programmer, that's an odd statement. You're either out of milk or you're not. There is no scale when it comes to being out of milk. Perhaps she was trying to tell me that they'd be out of milk for a week, but the outcome was the same — espresso day for me. - -In most real-world situations, people's relaxed attitude to state is not an issue. Unfortunately, however, many programmers are quite vague about state too — and that is a problem. - -Consider a simple webshop that only accepts credit cards and does not invoice customers, with an `Order` class containing this method: - +# از نوشتن کدهای اضافی پرهیز کنید + +فرض کنیم که در حال طراحی یک فروشگاه آنلاین بوده و درصدد هستیم تا بخش سبد خرید را کدنویسی کنیم. برای این منظور، کلاسی داریم تحت عنوان Order که حاوی متدهای مختلفی است من‌جمله ()isComplete که حاوی کدهای زیر است: +```C +function boolean isComplete() +{ + return isPaid() && hasShipped(); +} ``` - public boolean isComplete() { - return isPaid() && hasShipped(); - } +منطقاً یک سفارش قبل از اینکه پرداخت شود نمی‌تواند به دست مشتری برسد؛ لذا ()hasShipped نمی‌توان True باشد مگر اینکه ()isPaid برابر با True باشد و به خاطر همین مسأله است که بخشی از کد اضافی بوده و کد بالا را می‌توان به صورت زیر تغییر داد: +```C +function boolean isComplete() +{ + return hasShipped(); +} ``` - -Reasonable, right? Well, even if the expression is nicely extracted into a method instead of copy'n'pasted everywhere, the expression shouldn't exist at all. The fact that it does highlights a problem. Why? Because an order can't be shipped before it's paid. Thereby, `hasShipped` can't be true unless `isPaid` is true, which makes part of the expression redundant. You may still want `isComplete` for clarity in the code, but then it should look like this: - -``` - public boolean isComplete() { - return hasShipped(); - } -``` - -In my work, I see both missing checks and redundant checks all the time. This example is tiny, but when you add cancellation and repayment, it'll become more complex and the need for good state handling increases. In this case, an order can only be in one of three distinct states: - -- *In progress:* Can add or remove items. Can't ship. -- *Paid:* Can't add or remove items. Can be shipped. -- *Shipped:* Done. No more changes accepted. - -These states are important and you need to check that you're in the expected state before doing operations, and that you only move to a legal state from where you are. In short, you have to protect your objects carefully, in the right places. - -But how do you begin thinking in states? Extracting expressions to meaningful methods is a very good start, but it is just a start. The foundation is to understand state machines. I know you may have bad memories from CS class, but leave them behind. State machines are not particularly hard. Visualize them to make them simple to understand and easy to talk about. Test-drive your code to unravel valid and invalid states and transitions and to keep them correct. Study the State pattern. When you feel comfortable, read up on Design by Contract. It helps you ensure a valid state by validating incoming data and the object itself on entry and exit of each public method. +در تفسیر کدهای فوق بایستی گفت که به طور کلی، وقتی که در حال کار روی یک Order (سفارش) هستیم، ۳ وضعیت مختلف می‌تواند وجود داشته باشد: +- در جریان: مشتری می‌تواند آیتم‌هایی را به سبد خرید خود اضافه کرده و یا برخی موارد را حذف کند. +- پرداخت شده: مشتری دیگر نمی‌تواند آیتمی را حذف کند. +- ارسال شده: کار به اتمام رسیده است و هیچ‌گونه تغییری رخ نخواهد داد. -If your state is incorrect, there's a bug and you risk trashing data if you don't abort. If you find the state checks to be noise, learn how to use a tool, code generation, weaving, or aspects to hide them. Regardless of which approach you pick, thinking in states will make your code simpler and more robust. +در فرایند توسعهٔ نرم‌افزار، بسیاری مواقع پیش می‌آید که شاهد کدهای اضافی هستیم که این مسأله به خاطر عدم توجه به State (وضعیت) قرار گرفته در آن صورت می‌گیرد. به عبارت دیگر، ما می‌بایست ببینیم که در چه وضعیتی قرار داریم، سپس بسته به شرایطی که پیش روی ما است، فرایندها را تعریف کنیم. -By [Niclas Nilsson](http://programmer.97things.oreilly.com/wiki/index.php/Niclas_Nilsson) \ No newline at end of file +یکی از راه‌های خوب برای توجه به این مسأله، استفاده از متدهایی بامعنی، همچون چیزی که در بالا مشاهده کردیم، برای پیاده‌سازی دستوراتی است که مد نظر داریم. در یک کلام، به خاطر داشته باشیم که اگر فرایندی را روی تسکی در State (وضعیت) نادرستی انجام دهیم، کدهای ما منجر به ایجاد باگ‌ خواهد شد. From 1c599aef21b22018ebdbf6c5d3591ac69f96833c Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 15:58:06 +0300 Subject: [PATCH 250/290] Added number 85 --- fr-IR/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fr-IR/SUMMARY.md b/fr-IR/SUMMARY.md index 98c05539..adb22c7a 100644 --- a/fr-IR/SUMMARY.md +++ b/fr-IR/SUMMARY.md @@ -85,7 +85,7 @@ 1. [تست نرم‌افزار و سورس‌کد را آخر شب‌ها و آخر هفته‌ها انجام دهید!](thing_82/README.md) 1. [مقایسه‌ای مابین مهندسین نرم‌افزار و دیگر مهندسان](thing_83/README.md) 1. [از نوشتن کدهای اضافی پرهیز کنید](thing_84/README.md) -1. [دو تا مغز بهتر ایک مغز است!](thing_85/README.md) +1. [اهمیت برنامه‌نویسی دونفره در کدنویسی را هرگز نادیده نگیرید](thing_85/README.md) 1. [دو اشتباه می توانند یک بخش درست ایجاد کنند! (و رفع آنها دشوار است)](thing_86/README.md) 1. [Ubuntu Coding for Your Friends](thing_87/README.md) 1. [ابزارهای یونیکس دوست شما هستند](thing_88/README.md) From 856ed25cd4616192c13321c64c293498b9854651 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 15:58:39 +0300 Subject: [PATCH 251/290] Added number 85 --- fr-IR/thing_85/README.md | 25 ++++++++++--------------- 1 file changed, 10 insertions(+), 15 deletions(-) diff --git a/fr-IR/thing_85/README.md b/fr-IR/thing_85/README.md index aed4fecb..dd463db2 100644 --- a/fr-IR/thing_85/README.md +++ b/fr-IR/thing_85/README.md @@ -1,23 +1,18 @@ -# Two Heads Are Often Better than One +# اهمیت برنامه‌نویسی دونفره در کدنویسی را هرگز نادیده نگیرید -Programming requires deep thought, and deep thought requires solitude. So goes the programmer stereotype. +نیاز به توضیح نیست که کدنویسی نیاز به تفکر عمیقی دارد و تفکر عمیق هم در محیط‌های شلوغ امکان‌پذیر نبوده و نیازمند محیطی آرام و تنها است اما آنچه مسلم است اینکه در دنیای امروز فقط و فقط با تکیه بر داشته‌های خود نمی‌توان در حوزهٔ توسعهٔ نرم‌افزار به موفقیت‌های چندانی دست یافت و آشنایی با مهارت Team Work (کار گروهی) چیزی است که از دولوپرها، خواه فریلنسر باشند و خواه در تیم کد بزنند، انتظار می‌رود. -This "lone wolf" approach to programming has been giving way to a more collaborative approach, which, I would argue, improves quality, productivity, and job satisfaction for programmers. This approach has developers working more closely with each other and also with non-developers — business and systems analysts, quality assurance professionals, and users. +اما به خاطر داشته باشیم که منظور از کار گروهی این نیست که به سؤالات دیگر دولوپرها پاسخ دهیم، در جلسات شرکت کنیم، ایده بدهیم و کارهایی از این دست بلکه منظور کلی این است که به شکلی کاملاً پویا و فعال به همکاری با دیگر اعضای تیم بپردازیم. -What does this mean for developers? Being the expert technologist is no longer sufficient. You must become effective at working with others. +در همین راستا، یکی از راه‌های پیاده‌سازی کار گروهی چیزی است تحت‌ عنوان Pair Programming (برنامه‌نویسی دونفره) که مزایای بسیاری برای هر دو دولوپر دارا است. اگر فرض را بر این بگذاریم که شما از همکارتان حرفه‌ای‌تر باشید، مسلماً با انتقال دانش خود منجر به ارتقاء مهارت‌های تیم توسعه خواهید شد و همچنین به توانایی‌های خود بیشتر واقف می‌گردید؛ اگر هم همکارتان از شما حرفه‌ای‌تر باشد، دیگر نیاز به توضیح نیست که این نوع کدنویسی می‌تواند در بالا بردن سطح مهارت‌های شما مفید واقع گردد. -Collaboration is not about asking and answering questions or sitting in meetings. It's about rolling up your sleeves with someone else to jointly attack work. +آنچه مسلم است اینکه نگاه هیچ ۲ دولوپری در حین فرایند توسعهٔ نرم‌افزار ۱۰۰٪ شبیه به یکدیگر نیست و همین مسأله اهمیت برنامه‌نویسی دونفره را دوچندان می‌سازد چرا که دولوپرها می‌توانند از زوایای مختلفی به مسألهٔ پیش‌رویشان نگاه کرده و بهترین راه‌کار را برایش اتخاذ کنند. -I'm a big fan of pair programming. You might call this "extreme collaboration." As a developer, my skills grow when I pair. If I am weaker than my pairing partner in the domain or technology, I clearly learn from his or her experience. When I am stronger in some aspect, I learn more about what I know and don't know by having to explain myself. Invariably, we both bring something to the table and learn from each other. +حال بایستی از نقطه‌نظر مدیران شرکت‌های نرم‌افزاری هم به این قضیه نگاه کنیم؛ این دست مدیران که عموماً طرفدار مدیریت پروژه به سبک اجایل هستند بر این باورند که گماشتن ۲ دولوپر روی پروژه‌ای که ۱ دولوپر هم به خوبی از عهدهٔ آن برمی‌آید، کاری غیرمنطقی است! -When pairing, we each bring our collective programming experiences — domain as well as technical — to the problem at hand and can bring unique insight and experience into writing software effectively and efficiently. Even in cases of extreme imbalance in domain or technical knowledge, the more experienced participant invariably learns something from the other — perhaps a new keyboard shortcut, or exposure to a new tool or library. For the less-experienced member of the pair, this is a great way to get up to speed. +چنین دیدگاهی کاملاً درست و به‌جا است و ما هرگز نمی‌گوییم که «باید» همواره کلیهٔ پروژه‌ها را با گماشتن ۲ دولوپر پیاده‌سازی کرد اما در اینجا بحث بالا بردن کیفیت کار از یک سو و انتقال دانش و ارتقاء مهارت‌های تک‌تک اعضای تیم توسعهٔ نرم‌افزار از سوی دیگر است. -Pair programming is popular with, though not exclusive to, proponents of agile software development. Some who object to pairing suggest "Why should I pay two programmers to do the work of one?" My response is that, indeed, you should not. I argue that pairing increases quality, understanding of the domain and technology, techniques (like IDE tricks), and mitigates the impact of lottery risk (one of your expert developers wins the lottery and quits the next day). +نیاز به توضیح نیست که بازار کار همواره به دنبال بهترین دولوپرها است و اگر شرکت‌های نرم‌افزاری این شانس را داشته باشند که دولوپرهایی از این دست را به استخدام خود درآورده باشند، همواره بایستی این نگرانی را داشته باشند که روزی دولوپرهای درجه ۱ خود را از دست بدهند و این در حالی است که پیروی کردن از سیاست برنامه‌نویسی دونفره می‌تواند دانش، مهارت و تجربیات دولوپرهای حرفه‌ای تیم را تا حد امکان به دولوپرهای مبتدی‌تر انتقال دهد و چنانچه روزی برسد که دولوپر یا دولوپرهای حرفه‌ای تیم بخواهند شرکت را ترک کنند، می‌توان این اطمینان را داشت که بخش قابل‌توجهی از دانش ایشان با سایرین به اشتراک گذاشته شده است. -What is the long-term value of learning a new keyboard shortcut? How do we measure the overall quality improvement to the product resulting from pairing? How do we measure the impact of your partner not letting you pursue a dead-end approach to solving a difficult problem? One study cites an increase of 40% in effectiveness and speed (J T Nosek, "The Case for Collaborative Programming," *Communications of the ACM*, March 1998). What is the value of mitigating your "lottery risk?" Most of these gains are difficult to measure. - -Who should pair with whom? If you're new to the team, it's important to find a team member who is knowledgeable. Just as important find someone who has good interpersonal and coaching skills. If you don't have much domain experience, pair with a team member who is an expert in the domain. - -If you are not convinced, experiment: collaborate with your colleagues. Pair on an interesting, gnarly problem. See how it feels. Try it a few times. - -By [Adrian Wible](http://programmer.97things.oreilly.com/wiki/index.php/Adrian_Wible) \ No newline at end of file +چه نوع دولوپرهایی می‌بایست با یکدیگر در یک تیم قرار بگیرند؟ +اگر به طور مثال شما دولوپری مبتدی هستید، خیلی مهم است که در صورت داشتن امکان برنامه‌نویسی دونفره در شرکت به جای دولوپری مبتدی همچون خودتان، با فردی ماهرتر هم‌ گروه شوید اما بایستی به خاطر داشته باشیم که مهارت‌های فنی برای هم گروه شده صرفاً کافی نیستند بلکه فردی که قرار است هم گروه ما شود، می‌بایست از مهارت‌های برقراری ارتباط با دیگران و مربی‌گری نیز برخوردار باشد که در این صورت بهترین نتیجهٔ ممکن را خواهیم گرفت. From ee31cea63505784a809d8b673d34e55b37a5bdae Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 15:59:41 +0300 Subject: [PATCH 252/290] Added number 86 --- fr-IR/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fr-IR/SUMMARY.md b/fr-IR/SUMMARY.md index adb22c7a..f1664d3b 100644 --- a/fr-IR/SUMMARY.md +++ b/fr-IR/SUMMARY.md @@ -86,7 +86,7 @@ 1. [مقایسه‌ای مابین مهندسین نرم‌افزار و دیگر مهندسان](thing_83/README.md) 1. [از نوشتن کدهای اضافی پرهیز کنید](thing_84/README.md) 1. [اهمیت برنامه‌نویسی دونفره در کدنویسی را هرگز نادیده نگیرید](thing_85/README.md) -1. [دو اشتباه می توانند یک بخش درست ایجاد کنند! (و رفع آنها دشوار است)](thing_86/README.md) +1. [منفی در مفنی می‌شود مثبت!](thing_86/README.md) 1. [Ubuntu Coding for Your Friends](thing_87/README.md) 1. [ابزارهای یونیکس دوست شما هستند](thing_88/README.md) 1. [از الگوریتم و ساختار داده مناسب استفاده کنید](thing_89/README.md) From 6886936fdb5c4702d06537b1db037611c8df1486 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 16:00:10 +0300 Subject: [PATCH 253/290] Added number 86 --- fr-IR/thing_86/README.md | 25 +++++++------------------ 1 file changed, 7 insertions(+), 18 deletions(-) diff --git a/fr-IR/thing_86/README.md b/fr-IR/thing_86/README.md index 6caa5af9..f3bb48a7 100644 --- a/fr-IR/thing_86/README.md +++ b/fr-IR/thing_86/README.md @@ -1,23 +1,12 @@ -# Two Wrongs Can Make a Right (and Are Difficult to Fix) +# منفی در مفنی می‌شود مثبت! +دولوپرها به خوبی می‌دانند که سورس‌کد هیچ وقت دروغ نمی‌گوید اما این در حالی است که همین سورس‌کد گاهی اوقات تضادهایی دارا است و برخی از همین تضادها است که منجر به این سؤال می‌گردد «چه‌طور ممکنه با این شرایط نرم‌افزار کار کنه؟» -Code never lies, but it can contradict itself. Some contradictions lead to those "How can that possibly work?" moments. +یکی از دولوپرهای نرم‌افزار آپولو ۱۱ به نام Allan Klumpp در مصاحبه‌ای گفت که در این نرم‌افزار باگی وجود داشت که فرود آپولو را با مشکل مواجه می‌کرد اما این در حالی بود که باگی دیگری منجر به این شد که باگ اول خنثی گشته و این نرم‌افزار بدون هیچ مشکلی کار خود را انجام می‌داد و قبل از اینکه کشف گردد، در نرم‌افزار کنترل کنندهٔ موتورهای آپولو ۱۱ و آپولو ۱۲ مورد استفاده قرار می‌گرفت. -In an [interview](http://www.netjeff.com/humor/item.cgi?file=ApolloComputer), the principal designer of the Apollo 11 Lunar Module software, Allan Klumpp, disclosed that the software controlling the engines contained a bug that should have made the lander unstable. However, another bug compensated for the first and the software was used for both Apollo 11 and 12 Moon landings before either bug was found or fixed. +برای روشن‌تر شدن این مسأله، فانکشنی را در نظر بگیرید که این وظیفه را دارا است تا استاتوس (وضعیت) چیزی را برگرداند. گرچه این فانکشن می‌بایست در شرایط خاصی مقدار True را باز گرداند، اما خروجی همواره False است. علاوه بر این، فانکشنی که این فانکشن را صدا زده، هرگز مقداری بازگشتی را چک نمی‌کند! در چنین شرایطی، همه چیز به خوبی کار می‌کند تا اینکه دولوپری به این قضیه پی‌ببرد. -Consider a function that returns a completion status. Imagine that it returns false when it should return true. Now imagine the calling function neglects to check the return value. Everything works fine until one day someone notices the missing check and inserts it. +زمانی‌ که در سورس‌کدی ۲ باگ وجود داشته باشد که با همکاری یکدیگر منجر به این خواهند گشت تا نرم‌افزار در ظاهر بدون مشکل کار کند، وقتی یکی از باگ‌ها مرتفع گردد و باگ دیگر بابرجا باقی بماند، نرم‌افزار به مشکل برخواهد خورد. به عبارت دیگر، دولوپری که مسئولیت نگهداری کد را بر عهده دارد، ریپورتی دریافت می‌کند مبنی بر وجود باگی در سیستم؛ وی باگ را یافته و آن را رفع می‌کند اما مشاهده می‌شود که مشکل کماکان پابرجا است چرا که باگ دوم هنوز به قوت خود باقی است. در چنین شرایطی، وی باگ اول را به حالت اولیهٔ خود بازگردانده و کد را بررسی می‌کند تا به باگ دوم دست یابد و آن را فیکس می‌کند اما مشاهده می‌شود که مجدد مشکل نرم‌افزار پابرجا است. بنابراین مشکل دوم نرم‌افزار که ریفکتور شده بود را به حالت قبل بازمی‌گرداند و در چنین شرایطی دولوپر به دنبال یک باگ سومی می‌گردد که چیزی بیش از یک دور باطل نخواهد بود چرا که اصلاً باگ سومی در کار نیست! -Or consider an application that stores state as an XML document. Imagine that one of the nodes in incorrectly written as `TimeToLive` instead of `TimeToDie`, as the documentation says it should. Everything appears fine while the writer code and the reader code both contain the same error. But fix one, or add a new application reading the same document, and the symmetry is broken, as well as the code. +در چنین شرایطی، تعامل مابین ۲ باگ که منجر به ایجاد نتایج منتظره‌ای می‌شوند باعث می‌شود تا فرایند دیباگینگ نرم‌افزار بسیار دشوار گردد (جالب است بدانیم که چنین مسأله‌ای ممکن است در مستندات پروژه هم ایجاد گردد به طوری که اروری در کد با همکاری مشکلی در نوشتن مستندات پروژه دست به دست یکدیگر داده تا دولوپرها سردرگم شوند). -When two defects in the code create one visible fault, the methodical approach to fixing faults can itself break down. The developer gets a bug report, finds the defect, fixes it, and retests. The reported fault still occurs, however, because a second defect is at work. So the first fix is removed, the code inspected until the second underlying defect is found, and a fix applied for that. But the first defect has returned, the reported fault is still seen, and so the second fix is rolled back. The process repeats but now the developer has dismissed two possible fixes and is looking to make a third that will never work. - -The interplay between two code defects that appear as one visible fault not only makes it hard to fix the problem but leads developers down blind alleys, only to find they tried the right answers early on. - -This doesn't happen only in code: The problem also exists in written requirements documents. And it can spread, virally, from one place to another. An error in the code compensates for an error in the written description. - -It can spread to people too: Users learn that when the application says Left it means Right, so they adjust their behavior accordingly. They even pass it on to new users: "Remember when that applications says click the left button it really means the button on the right." Fix the bug and suddenly the users need retraining. - -Single wrongs can be easy to spot and easy to fix. It is the problems with multiple causes, needing multiple changes, that are harder to resolve. In part it is because easy problems are so easily fixed that people tend to fix them relatively quickly and store up the more difficult problems for a later date. - -There is no simple advice to give on how to address faults arising from sympathetic defects. Awareness of the possibility, a clear head, and a willingness to consider all possibilities are needed. - -By [Allan Kelly](http://programmer.97things.oreilly.com/wiki/index.php/Allan_Kelly) \ No newline at end of file +در یک کلام، بایستی گفت که هیچ راه‌کار عملی برای موقعیت‌هایی اینچنین وجود ندارد و چنانچه دولوپری در موقعیت‌هایی از این دست قرار گیرد، می‌توان این انتظار را داشت که روزها و شاید هفته‌ها یا ماه‌ها درگیر فرایند دیباگینگ گردد. From 11e5c8446a76783ed2664beb6c8e38e2b0db4b21 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 16:00:48 +0300 Subject: [PATCH 254/290] Added number 87 --- fr-IR/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fr-IR/SUMMARY.md b/fr-IR/SUMMARY.md index f1664d3b..8c79c8ae 100644 --- a/fr-IR/SUMMARY.md +++ b/fr-IR/SUMMARY.md @@ -87,7 +87,7 @@ 1. [از نوشتن کدهای اضافی پرهیز کنید](thing_84/README.md) 1. [اهمیت برنامه‌نویسی دونفره در کدنویسی را هرگز نادیده نگیرید](thing_85/README.md) 1. [منفی در مفنی می‌شود مثبت!](thing_86/README.md) -1. [Ubuntu Coding for Your Friends](thing_87/README.md) +1. [کدنویسی تمیز و اصولی یک باید است](thing_87/README.md) 1. [ابزارهای یونیکس دوست شما هستند](thing_88/README.md) 1. [از الگوریتم و ساختار داده مناسب استفاده کنید](thing_89/README.md) 1. [لاگ بیش از حد خواب را از شما خواهد گرفت!](thing_90/README.md) From 06c046be5902aa0f59598c693cbb7b4e8b0538c8 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 16:01:44 +0300 Subject: [PATCH 255/290] Added number 87 --- fr-IR/thing_87/README.md | 16 +++++----------- 1 file changed, 5 insertions(+), 11 deletions(-) diff --git a/fr-IR/thing_87/README.md b/fr-IR/thing_87/README.md index 1a82b37c..778c99df 100644 --- a/fr-IR/thing_87/README.md +++ b/fr-IR/thing_87/README.md @@ -1,15 +1,9 @@ -# Ubuntu Coding for Your Friends +# کدنویسی تمیز و اصولی یک باید است -So often we write code in isolation and the code reflects our personal interpretation of a problem, as well as a very personalized solution. We may be part of the team, yet we are isolated, as is the team. We forget all too easily that this code created in isolation will be executed, used, extended, and relied upon by others. It is easy to overlook the social side of software creation. Creating software is a technical exercise mixed into a social exercise. We just need to lift our heads more often to realize that we are not working in isolation, and we have shared responsibility towards increasing the probability of success for everyone, not just the development team. +وقتی دولوپری به تنهایی کد می‌زند، وی تفسیری شخصی از مسألهٔ پیش‌رو خواهد داشت و بالتبع هم راه‌کاری که اتخاذ می‌کند کاملاً شخصی خواهد بود. جالب است بدانیم گرچه برخی دیگر دولوپرها در یک تیم کار می‌کنند، اما باز هم ممکن است راه‌کارهایی که به کار می‌گیرند تکی و کاملاً شخصی باشند غافل از اینکه کدی که می‌نویسند، روزی می‌بایست توسط دیگر دولوپرها دیباگ شود، توسعه داده شود و یا نگهداری گردد. -You can write good quality code in isolation, all the while lost in self. From one perspective, that is an egocentric approach (not *ego* as in arrogant, but *ego* as in personal). It is also a Zen view and it is about you, in that moment of creating code. I always try to live in the moment because it helps me get closer to good quality, but then I live in *my* moment. What about the moment of my team? Is my moment the same as the team's moment? +آنچه در مورد توسعهٔ نرم‌افزار امروزه خیلی مورد توجه نمی‌گیرد این است که برخی کدنویسی را صرفاً یک مهارت فنی تلقی می‌کنند اما این در حالی است که توسعهٔ نرم‌افزار ترکیبی از مهارت‌های فنی + مهارت‌های اجتماعی و ارتباطی است! -In Zulu, the philosophy of Ubuntu is summed up as "Umuntu ngumuntu ngabantu" which roughly translates to "A person is a person through (other) persons." I get better because you make me better through your good actions. The flip side is that you get worse at what you do when I am bad at what I do. Among developers, we can narrow it down to "A developer is a developer through (other) developers." If we take it down to the metal, then "Code is code through (other) code." +زمانی که ما در یک تیم نرم‌افزاری کد می‌زنیم، بایستی توجه داشته باشیم که کیفیت کد ما می‌تواند کیفیت کد سایر دولوپرها را نیز تحت تأثیر خود قرار دهد. به عبارت دیگر، اگر یکی از اعضای تیم توسعه به کار با کیفیت اعتقاد نداشته باشد و یا آن‌طور که باید و شاید حرفه‌ای نباشد، این عدم مهارت وی می‌تواند سطح کدنویسی دیگر اعضای تیم را هم پایین بکشاند و این در حالی است که تأثیرات منفی این قضیه کل تیم را تحت‌الشعاع خود قرار خواهد داد. -The quality of the code I write affects the quality of the code you write. What if my code is of poor quality? Even if you write very clean code, it is the points where you use my code that your code quality will degrade to close to the quality of my code. You can apply many patterns and techniques to limit the damage, but the damage has already been done. I have caused you to do more than what you needed to do simply because I did not think about you when I was living in my moment. - -I may consider my code to be clean, but I can still make it better just by Ubuntu coding. What does Ubuntu code look like? It looks just like good clean code. It is not about the code, the artifact. It is about the act of creating that artifact. Coding for your friends, with Ubuntu, will help your team live your values and reinforce your principles. The next person that touches your code, in whatever way, will be a better person and a better developer. - -Zen is about the individual. Ubuntu is about Zen for a group of people. Very, very rarely do we create code for ourselves alone. - -By [Aslam Khan](http://programmer.97things.oreilly.com/wiki/index.php/Aslam_Khan) \ No newline at end of file +در واقع، وقتی که ما تمیز کدنویسی کنیم، سورس‌کدی که از ما به دیگر همکارانمان به ارث می‌رسد منجر به این خواهد گشت که ایشان هم با همان فرمان پروژه را ادامه دهند و این بدان معنا است که اگر ما خشت اول را درست بنا نهیم، این فرهنگ در میان تک‌تک اعضای تیم شکل خواهد گرفت که به کار باکیفیت، کدنویسی تمیز و اصولی پایبند باشند (البته عکس این موضوع هم کاملاً صادق است). From df5909a2eb5c5061599c9b6b6be6fc2ba03d6b95 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 16:02:32 +0300 Subject: [PATCH 256/290] Added number 88 --- fr-IR/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fr-IR/SUMMARY.md b/fr-IR/SUMMARY.md index 8c79c8ae..135076b9 100644 --- a/fr-IR/SUMMARY.md +++ b/fr-IR/SUMMARY.md @@ -88,7 +88,7 @@ 1. [اهمیت برنامه‌نویسی دونفره در کدنویسی را هرگز نادیده نگیرید](thing_85/README.md) 1. [منفی در مفنی می‌شود مثبت!](thing_86/README.md) 1. [کدنویسی تمیز و اصولی یک باید است](thing_87/README.md) -1. [ابزارهای یونیکس دوست شما هستند](thing_88/README.md) +1. [ ابزارهای یونیکسی دوست دولوپرها هستند!](thing_88/README.md) 1. [از الگوریتم و ساختار داده مناسب استفاده کنید](thing_89/README.md) 1. [لاگ بیش از حد خواب را از شما خواهد گرفت!](thing_90/README.md) 1. [WET Dilutes Performance Bottlenecks](thing_91/README.md) From 0a351ae82113e0051b599031d482650654fc85e9 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 16:03:19 +0300 Subject: [PATCH 257/290] Added number 88 --- fr-IR/thing_88/README.md | 33 ++++++++++----------------------- 1 file changed, 10 insertions(+), 23 deletions(-) diff --git a/fr-IR/thing_88/README.md b/fr-IR/thing_88/README.md index 4c2aa947..03279d86 100644 --- a/fr-IR/thing_88/README.md +++ b/fr-IR/thing_88/README.md @@ -1,31 +1,18 @@ -# The Unix Tools Are Your Friends +# ابزارهای یونیکسی دوست دولوپرها هستند! -If on my way to exile on a desert island I had to choose between an IDE and the Unix toolchest, I'd pick the Unix tools without a second thought. Here are the reasons why you should become proficient with Unix tools. +فارغ از اینکه با چه زبانی کد بزنیم، در چه حوزه‌ای به توسعهٔ اپلیکیشن بپردازیم و از چه ابزارهایی برای کدنویسی استفاده کنیم، برای دولوپرها استفاده از ابزارهایی که برای UNIX به بازار عرضه شده‌اند یک باید است. -First, IDEs target specific languages, while Unix tools can work with anything that appears in textual form. In today's development environment where new languages and notations spring up every year, learning to work in the Unix way is an investment that will pay off time and again. +اگر بخواهیم به عمده‌ترین دلایل استفاده از ابزارهای یونیکسی اشاره کنیم، بایستی بگوییم که به طور مثال IDEها برای زبان‌های برنامه‌نویسی به‌خصوصی طراحی شده‌اند اما این در حالی است که ابزارهای یونیکسی برای هر چیزی کاربرد خواهند داشت. در عصری که سال به سال زبان‌های برنامه‌نویسی جدیدی به بازار عرضه می‌شوند، سرمایه‌گذاری روی ابزارهای جهان‌شمولی همچون «اپلیکیشن‌های یونیکسی» به منزلهٔ سرمایه‌گذاری در صرفه‌جویی زمان و انرژی دولوپر است. -Furthermore, while IDEs offer just the commands their developers conceived, with Unix tools you can perform any task you can imagine. Think of them as (classic pre-Bionicle) Lego blocks: You create your own commands simply by combining the small but versatile Unix tools. For instance, the following sequence is a text-based implementation of Cunningham's signature analysis — a sequence of each file's semicolons, braces, and quotes, which can reveal a lot about the file's contents. +نکتهٔ دیگری که در ارتباط با تفاوت‌های یک IDE با یک UNIX Tool وجود دارد این است که معمولاً محیط‌های توسعهٔ یکپارچه (IDE) از یکسری کامندهای از پیش‌ تعریف شده برخوردارند که دولوپرها با استفاده از آنها به کدنویسی می‌پردازند،؛ اما دولوپرها با استفاده از ابزارهای یونیکسی می‌توانند محیط‌های توسعهٔ نرم‌افزار کاستومایز شدهٔ خود را ایجاد کنند و بسته به تمایلات شخصی خود، دست به ساخت محیطی بزنند که سرعت توسعهٔ ایشان را چند برابر کند. -``` -for i in *.java; do - echo -n "$i: " - sed 's/[^"{};]//g' $i | tr -d '\n' - echo -done -``` +علاوه بر این، وقتی که ما به عنوان یک دولوپر کار با یک IDE را فرا می‌گیریم، کلیدهای میانبر، کامندها و غیره همگی اختصاصی همان نرم‌افزار هستند و این در حالی است که اگر روزی بخواهیم به نرم‌افزار دیگری مهاجرت کنیم، می‌بایست با یکسری کلید میانبر جدید آشنا شویم اما وقتی که ما با ابزارهای یونیکسی همچون کامندهای cat ،sed ،grep و غیره آشنا شویم، این ابزارها جهان‌شمول بوده و در هر جایی و هر سیستم‌عامل قابل استفاده می‌باشند. -In addition, each IDE operation you learn is specific to that given task; for instance, adding a new step in a project's debug build configuration. By contrast, sharpening your Unix tool skills makes you more effective at any task. As an example, I've employed the sed tool used in the preceding command sequence to morph a project's build for cross-compiling on multiple processor architectures. +نکته البته به خاطر داشته باشیم که در IDEها به سادگی می‌توان کلیدهای میانبر را شخصی‌سازی کرد و همین مسأله منجر به این خواهد گشت که مهاجرت از یک نرم‌افزار به نرم‌افزاری دیگر خیلی چالش‌برانگیز نباشد. +جالب است بدانیم که ابزارهای UNIX در عصری ابداع شدند که یک سیستم چندکاربره (Multiuser) حافظهٔ رَمی برابر با ۱۲۸ کیلوبایت داشت و طراحان چنین ابزارهایی می‌بایست به بهینه‌ترین شکل ممکن به کدنویسی ابزارهای مد نظرشان می‌پرداختند تا با استفاده از کمترین منابع سیستمی، کار چنین کاربر را راه بیندازند. -Unix tools were developed in an age when a multiuser computer had 128kB of RAM. The ingenuity that went into their design means that nowadays they can handle huge data sets extremely efficiently. Most tools work like filters, processing just a single line at the time, meaning that there is no upper limit in the amount of data they can handle. You want to search for the number of edits stored in the half-terabyte English Wikipedia dump? A simple invocation of +علاوه بر این، اگر کامندی را خیلی مفید یافتیم و یا کارمان به شکلی است که بارها و بارها می‌بایست از آن در حین فرایند کاری خود استفاده نماییم، به سادگی می‌توان کامند مد نظر را در قالب یک فایل بَش پکیج نموده و به عنوان یک نرم‌افزار کامندلاینی کوچک از آن استفاده نماییم. -``` -grep '' | wc –l -``` +نکتهٔ دیگری که در ارتباط با ابزارهای یونیکسی که در سیستم‌عامل‌های مبتنی بر UNIX همچون لینوکس و مکینتاش وجود دارند این است که اکثر این ابزارها اپن‌سورس و رایگان هستند و همین مسأله میزان محبوبیت آنها را در میان دولوپرها دوچندان کرده است. -will give you the answer without sweat. If you find a command sequence generally useful, you can easily package it into a shell script, using some uniquely powerful programming constructs, such as piping data into loops and conditionals. Even more impressively, Unix commands executing as pipelines, like the preceding one, will naturally distribute their load among the many processing units of modern multicore CPUs. - -The small-is-beautiful provenance and open source implementations of the Unix tools make them ubiquitously available, even on resource-constrained platforms, like my set-top media player or DSL router. Such devices are unlikely to offer a powerful graphical user interface, but they often include the BusyBox application, which provides the most commonly-used tools. And if you are developing on Windows, the Cygwin environment offers you all imaginable Unix tools, both as executables and in source code form. - -Finally, if none of the available tools match your needs, it's very easy to extend the world of the Unix tools. Just write a program (in any language you fancy) that plays by a few simple rules: Your program should perform just a single task; it should read data as text lines from its standard input; and it should display its results unadorned by headers and other noise on its standard output. Parameters affecting the tool's operation are given in the command line. Follow these rules and "yours is the Earth and everything that's in it." - -By [Diomidis Spinellis](http://programmer.97things.oreilly.com/wiki/index.php/Diomidis_Spinellis) \ No newline at end of file +در پایان هم بایستی گفت اگر هیچ‌کدام از ابزارهای یونیکسی عرضه شده به بازار نیازهای شما را مرتفع نمی‌سازند، با یادگیری Shell Scripting به سادگی قادر خواهید بود دست به کدنویسی ابزارهای اختصاصی خود بزنید. From 1a34b40a0928ed28e75b8e6663cae252e508bbc5 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 16:04:02 +0300 Subject: [PATCH 258/290] Added number 89 --- fr-IR/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fr-IR/SUMMARY.md b/fr-IR/SUMMARY.md index 135076b9..3ce1ecb9 100644 --- a/fr-IR/SUMMARY.md +++ b/fr-IR/SUMMARY.md @@ -89,7 +89,7 @@ 1. [منفی در مفنی می‌شود مثبت!](thing_86/README.md) 1. [کدنویسی تمیز و اصولی یک باید است](thing_87/README.md) 1. [ ابزارهای یونیکسی دوست دولوپرها هستند!](thing_88/README.md) -1. [از الگوریتم و ساختار داده مناسب استفاده کنید](thing_89/README.md) +1. [استفادهٔ درست از الگوریتم‌ها و دیتا استراکچرها](thing_89/README.md) 1. [لاگ بیش از حد خواب را از شما خواهد گرفت!](thing_90/README.md) 1. [WET Dilutes Performance Bottlenecks](thing_91/README.md) 1. [زمانی که برنامه نویسان و تسترها با هم همکاری کنند!](thing_92/README.md) From a1f4d716ebb1f51c51491d85aef9c89021044d93 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 16:04:40 +0300 Subject: [PATCH 259/290] Added number 89 --- fr-IR/thing_89/README.md | 45 ++++++++++++++-------------------------- 1 file changed, 16 insertions(+), 29 deletions(-) diff --git a/fr-IR/thing_89/README.md b/fr-IR/thing_89/README.md index 0b79cbba..662c1c76 100644 --- a/fr-IR/thing_89/README.md +++ b/fr-IR/thing_89/README.md @@ -1,37 +1,24 @@ -# Use the Right Algorithm and Data Structure +# استفادهٔ درست از الگوریتم‌ها و دیتا استراکچرها -> A big bank with many branch offices complained that the new computers it had bought for the tellers were too slow. This was in the time before everyone used electronic banking and ATMs were not as widespread as they are now. People would visit the bank far more often, and the slow computers were making the people queue up. Consequently, the bank threatened to break its contract with the vendor. - -> The vendor sent a performance analysis and tuning specialist to determine the cause of the delays. He soon found one specific program running on the terminal consuming almost all the CPU capacity. Using a profiling tool, he zoomed in on the program and he could see the function that was the culprit. The source code read: - -> ``` -> for (i=0; i if (... s[i] ...) ... -> } -> ``` - -> And string s was, on average, thousands of characters long. The code (written by the bank) was quickly changed, and the bank tellers lived happily ever after.... - -Shouldn't the programmer have done better than to use code that needlessly scaled quadratically? -Each call to strlen traversed every one of the many thousand characters in the string to find its terminating null character. The string, however, never changed. By determining its length in advance, the programmer could have saved thousands of calls to strlen (and millions of loop executions): +زمانی که استفاده از کامپیوترهای تجاری تازه فراگیر شده بودند، بانکی معروف با شعب مختلف که به تازگی استفاده از سیستم‌های کامپیوتری را در دستور کار قرار داده بود، از پرفورمنس سیستم‌هایش به شرکت نرم‌افزار شکایت کرده و تهدید کرده بود که اگر سرعت نرم‌افزاری که منجر به ایجاد صف‌های طولانی مشتریان می‌شد را بهبود نبخشند، قرارداد را فسخ خواهد کرد. +شرکت‌ نرم‌افزاری هم چند متخصص و تحلیلگر به شعبه‌ٔ مرکزی بانک مذکور فرستاد تا ریشهٔ مشکل را بیابند و چیزی نگذشت که دریافتند کدی توسط مدیر آی‌تی خود بانک روی سیستم نوشته شده بود که در بک‌گراند به صورت کامندلاینی اجرا می‌شد و تقریباً می‌شود گفت تمام پتانسیل CPU را استفاده می‌کرد: +```C +for (i=0; i < strlen(s); ++i) { +if (... s[i] ...) ... +} ``` -n=strlen(s); -for (i=0; i Date: Wed, 17 May 2023 16:05:25 +0300 Subject: [PATCH 260/290] Added number 90 --- fr-IR/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fr-IR/SUMMARY.md b/fr-IR/SUMMARY.md index 3ce1ecb9..e6f5d389 100644 --- a/fr-IR/SUMMARY.md +++ b/fr-IR/SUMMARY.md @@ -90,7 +90,7 @@ 1. [کدنویسی تمیز و اصولی یک باید است](thing_87/README.md) 1. [ ابزارهای یونیکسی دوست دولوپرها هستند!](thing_88/README.md) 1. [استفادهٔ درست از الگوریتم‌ها و دیتا استراکچرها](thing_89/README.md) -1. [لاگ بیش از حد خواب را از شما خواهد گرفت!](thing_90/README.md) +1. [با لاگ‌گیری Verbose دچار دردسر خواهید شد!](thing_90/README.md) 1. [WET Dilutes Performance Bottlenecks](thing_91/README.md) 1. [زمانی که برنامه نویسان و تسترها با هم همکاری کنند!](thing_92/README.md) 1. [طوری کد بنویسید که انگار باید تا آخر عمر برای آن پشتیبانی بدهید](thing_93/README.md) From 4fb7bad8f23b601ed49e88f50da290a583cc6937 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 16:06:28 +0300 Subject: [PATCH 261/290] Added number 90 --- fr-IR/thing_90/README.md | 20 ++++++-------------- 1 file changed, 6 insertions(+), 14 deletions(-) diff --git a/fr-IR/thing_90/README.md b/fr-IR/thing_90/README.md index 8b1b4e76..0d09de53 100644 --- a/fr-IR/thing_90/README.md +++ b/fr-IR/thing_90/README.md @@ -1,17 +1,9 @@ -# Verbose Logging Will Disturb Your Sleep +# با لاگ‌گیری Verbose دچار دردسر خواهید شد! +لاگ گیری (Logging) به منزلهٔ بخشی مهم در فرایند توسعهٔ نرم‌افزار است. در واقع، این لاگ‌ها هستند که وقتی چیزی به درستی کار نمی‌کند، در فرایند مانیتورینگ نرم‌افزار چراغ راه دولوپر خواهند شد و تا حد ممکن وی را به سرچشمهٔ مشکل راهنمایی می‌کنند. در عین حال، در نظر داشته باشیم که همان‌قدر که نبود لاگ‌ها می‌توانند دولوپرها را فرایند دیباگینگ به دردسر بیاندازد، لاگ‌های غیرضروری و زیادی -اصطلاحاً Verbose- هم‌ می‌توانند آزاردهنده باشند! -When I encounter a system that has already been in development or production for a while, the first sign of real trouble is always a dirty log. You know what I'm talking about. When clicking a single link on a normal flow on a web page results in a deluge of messages in the only log that the system provides. Too much logging can be as useless as none at all. +نکته به طور کلی، منظور از Verbose Loggin نوعی از لاگ‌گیری است که در آن اطلاعاتی بیش از آنچه لازم است ذخیره خواهیم ساخت (Verbose در لغت به معنای «استفاده از واژگان بیش از حد» است). در واقع، Verbose Loggin زمان به کار می‌آید که نیاز به موشکافی دقیق یک سیستم نرم‌افزاری داشته باشیم و بخواهیم آن را دیباگ کنیم و در حالت عادی غیرفعال می‌گردد چرا که منجر به ایجاد لاگ فایل‌های بسیار حجیم خواهد شد. +برای درک بهتر این مسأله، بایستی فرایند لاگ‌گیری نرم‌افزار را به علائم بیماری تشبیه کنیم. در حقیقت، ورم زیاد در ناحیهٔ شکم یک نوع علامت است و سرفه کردن هم‌ نوع دیگری از علائم بیماری. مسلماً کمتر کسی را می‌توان یافت که ورم ناحیهٔ شکم را جدی نگیرد و به آن بی‌توجهی کند چرا که از یک مشکل ساده در معده تا خدای ناکرده وجود یک غدهٔ سرطانی را می‌تواند شامل گردد اما این در حالی است که در بسیاری از مواقع، سرفه کردن صرفاً نشان از یک سرماخوردگی ساده دارد (البته همواره استثناء‌هایی وجود دارد). -If your systems are like mine, when your job is done someone else's job is just starting. After the system has been developed, it will hopefully live a long and prosperous life serving customers. If you're lucky. How will you know if something goes wrong when the system is in production, and how will you deal with it? +البته در نظر داشته باشیم که فرایند لاگ‌گیری به همین سادگی‌ها نیست. به طور مثال، سرویس‌هایی که در آنها از چندین زبان‌ برنامه‌نویسی مختلف،‌ لایبرری و فریمورک استفاده شده است،‌ فرایند لاگ‌گیری بسیار پیچیده و دشوار خواهد بود و در چنین شرایطی حتماً می‌بایست این نکته را هم مد نظر داشته باشیم که گاهی‌اوقات ارور ایجاد شده کاملاً خارج از حیطهٔ اختیارات ما است (مثلاً زمانی که از API یک وب‌سایت دیگر استفاده می‌کنیم،‌ در صورت بروز مشکل در سرورهای آن وب‌سایت، مسلماً سرویس ما هم تحت‌الشعاع قرار خواهد گرفت). -Maybe someone monitors your system for you, or maybe you will monitor it yourself. Either way, the logs will be probably part of the monitoring. If something shows up and you have to be woken up to deal with it, you want to make sure there's a good reason for it. If my system is dying, I want to know. But if there's just a hiccup, I'd rather enjoy my beauty sleep. - -For many systems, the first indication that something is wrong is a log message being written to some log. Mostly, this will be the error log. So do yourself a favor: Make sure from day one that if something is logged in the error log, you're willing to have someone call and wake you in the middle of the night about it. If you can simulate load on your system during system testing, looking at a noise-free error log is also a good first indication that your system is reasonably robust. Or an early warning if it's not. - -Distributed systems add another level of complexity. You have to decide how to deal with an external dependency failing. If your system is very distributed, this may be a common occurrence. Make sure your logging policy takes this into account. - -In general, the best indication that everything is all right is that the messages at a lower priority are ticking along happily. I want about one INFO-level log message for every significant application event. - -A cluttered log is an indication that the system will be hard to control once it reaches production. If you don't expect anything to show up in the error log, it will be much easier to know what to do when something does show up. - -By [Johannes Brodwall](http://programmer.97things.oreilly.com/wiki/index.php/Johannes_Brodwall) \ No newline at end of file +برای این منظور، می‌توان ستونی تحت‌عنوان مثلاًً log_level در جدول مخصوص ذخیره‌سازی لاگ‌ها در نظر گرفته که سطح و نوع ارورهایی که سیستم با آنها دست و پنجه نرم‌ می‌کند را مشخص سازیم. به عبارت دیگر، سطوح پایین‌تر مثل سطح یک یا دو را به ارورهای قابل چشم‌پوشی و سطوح بالاتر از دو را به ارورهای جدی اختصاص داد و اینجا است که به سادگی فردی که مسئول مانیتور کردن سیستم است خواهد توانست مشکلات را در اسرع وقت رصد کند. From 1586b9c064a19365f804a1ace62ba496840fd998 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 16:07:16 +0300 Subject: [PATCH 262/290] Added number 91 --- fr-IR/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fr-IR/SUMMARY.md b/fr-IR/SUMMARY.md index e6f5d389..cf7484d4 100644 --- a/fr-IR/SUMMARY.md +++ b/fr-IR/SUMMARY.md @@ -91,7 +91,7 @@ 1. [ ابزارهای یونیکسی دوست دولوپرها هستند!](thing_88/README.md) 1. [استفادهٔ درست از الگوریتم‌ها و دیتا استراکچرها](thing_89/README.md) 1. [با لاگ‌گیری Verbose دچار دردسر خواهید شد!](thing_90/README.md) -1. [WET Dilutes Performance Bottlenecks](thing_91/README.md) +1. [درک تفاوت مفاهیم DRY و WET در کدنویسی بهینه](thing_91/README.md) 1. [زمانی که برنامه نویسان و تسترها با هم همکاری کنند!](thing_92/README.md) 1. [طوری کد بنویسید که انگار باید تا آخر عمر برای آن پشتیبانی بدهید](thing_93/README.md) 1. [Write Small Functions Using Examples](thing_94/README.md) From f9cef696ed37ae216b3ee1cfa7601e40d5a3b2f6 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 16:08:04 +0300 Subject: [PATCH 263/290] Added number 91 --- fr-IR/thing_91/README.md | 51 ++++++---------------------------------- 1 file changed, 7 insertions(+), 44 deletions(-) diff --git a/fr-IR/thing_91/README.md b/fr-IR/thing_91/README.md index 39afabcd..e0279aad 100644 --- a/fr-IR/thing_91/README.md +++ b/fr-IR/thing_91/README.md @@ -1,50 +1,13 @@ -# WET Dilutes Performance Bottlenecks +# درک تفاوت مفاهیم DRY و WET در کدنویسی بهینه -The importance of the DRY principle (Don't Repeat Yourself) is that it codifies the idea that every piece of knowledge in a system should have a singular representation. In other words, knowledge should be contained in a single implementation. The antithesis of DRY is WET (Write Every Time). Our code is WET when knowledge is codified in several different implementations. The performance implications of DRY versus WET become very clear when you consider their numerous effects on a performance profile. +در کدنویسی مفهومی داریم تحت عنوان DRY که مخفف واژگان Don't Repeat Yourself و به طور خلاصه این مفهوم حاکی از آن است که در کدنویسی هیچ‌گاه نمی‌بایست فانکشنی -یا به طور کلی کدی- که کار یکسانی انجام می‌دهد را دو بار بنویسیم. به عبارت دیگر،‌ در کدنویسی سیستم مد نظر، دوباره‌کاری ممنوع است. -Let's start by considering a feature of our system, say *X*, that is a CPU bottleneck. Let's say feature *X* consumes 30% of the CPU. Now let's say that feature *X* has ten different implementations. On average, each implementation will consume 3% of the CPU. As this level of CPU utilization isn't worth worrying about if we are looking for a quick win, it is likely that we'd miss that this feature is our bottleneck. However, let's say that we somehow recognized feature *X* as a bottleneck. We are now left with the problem of finding and fixing every single implementation. With WET we have ten different implementations that we need to find and fix. With DRY we'd clearly see the 30% CPU utilization and we'd have a tenth of the code to fix. And did I mention that we don't have to spend time hunting down each implementation? +نقطهٔ مقابل DRY،‌ مفهوم دیگری است تحت عنوان WET که مخفف واژگان Write Every Time است. به عبارت دیگر، وقتی برای کار واحد یا یکسانی بیش از یک بار فانکشنی -یا به طور کلی کدی- را بنویسیم، سورس‌کد ما اصطلاحاً WET شده است. -There is one use case where we are often guilty of violating DRY: our use of collections. A common technique to implement a query would be to iterate over the collection and then apply the query in turn to each element: +وقتی پای پرفورمنس (عملکرد) به میان می‌آید، تفاوت فاحشی مابین سورس‌کدهای به اصطلاح DRY و WET به میان می‌آید. برای روشن‌تر شدن این مسأله، مثالی می‌زنیم. -``` -public class UsageExample { - private ArrayList allCustomers = new ArrayList(); - // ... - public ArrayList findCustomersThatSpendAtLeast(Money amount) { - ArrayList customersOfInterest = new ArrayList(); - for (Customer customer: allCustomers) { - if (customer.spendsAtLeast(amount)) - customersOfInterest.add(customer); - } - return customersOfInterest; - } -} -``` +فرض کنیم در سیستم خود فیچری داریم تحت عنوان X که مصرف CPU زیادی را به خود اختصاص می‌دهد و چیزی بیش از ۳۰٪ توان هستهٔ سیستم را مصرف می‌کند. حال مجدد فرض کنیم که این فیچر بیش از ۱۰ بار در جای‌جای نرم‌افزار به کار گرفته شده است که به طور میانگین، هر بار فراخوانی این فیچر ۳٪ از توان CPU را استفاده می‌کند. اینجا است که دولوپری که قصد دیباگ کردن چنین سیستمی را داشته باشد گمراه خواهد شد چرا که در نگاه اول ۳٪ کاملاً قابل‌ چشم‌پوشی است. -By exposing this raw collection to clients, we have violated encapsulation. This not only limits our ability to refactor, it forces users of our code to violate DRY by having each of them re-implement potentially the same query. This situation can easily be avoided by removing the exposed raw collections from the API. In this example we can introduce a new, domain-specific collective type called `CustomerList`. This new class is more semantically in line with our domain. It will act as a natural home for all our queries. +اما اگر فرض کنیم که متوجه شدیم که مشکل از همین X می‌باشد، اینجا است که اگر از رویکرد WET استفاده کرده باشیم، از این پس بایستی به دنبال هر ده جایی که X در آن استفاده شده گشته و مشکل آنها تک به تک رفع کنیم اما این در حالی است که اگر از رویکرد DRY در کدنویسی پروژه استفاده کرده باشیم، صرفاً در یک جا کد را می‌بایست ریفکتور کرده و به یک‌باره ۳۰٪ بهبود پرفورمنس را مشاهده خواهیم کرد. -Having this new collection type will also allow us to easily see if these queries are a performance bottleneck. By incorporating the queries into the class we eliminate the need to expose representation choices, such as `ArrayList`, to our clients. This gives us the freedom to alter these implementations without fear of violating client contracts: - -``` -public class CustomerList { - private ArrayList customers = new ArrayList(); - private SortedList customersSortedBySpendingLevel = new SortedList(); - // ... - public CustomerList findCustomersThatSpendAtLeast(Money amount) { - return new CustomerList(customersSortedBySpendingLevel.elementsLargerThan(amount)); - } -} - -public class UsageExample { - public static void main(String[] args) { - CustomerList customers = new CustomerList(); - // ... - CustomerList customersOfInterest = customers.findCustomersThatSpendAtLeast(someMinimalAmount); - // ... - } -} -``` - -In this example, adherence to DRY allowed us to introduce an alternate indexing scheme with SortedList keyed on our customers level of spending. More important than the specific details of this particular example, following DRY helped us to find and repair a performance bottleneck that would have been more difficult to find were the code to be WET. - -By [Kirk Pepperdine](http://programmer.97things.oreilly.com/wiki/index.php/Kirk_Pepperdine) \ No newline at end of file +به طور کلی، مزیت DRY نسبت به WET علاوه بر پرفورمنس بالاتر و سورس‌کد تمیزتر، امکان دیباگ کردن سریع‌تر سورس‌کد خواهد بود که این مسأله در پروژه‌های بزرگ بسیار حیاتی است. From 505a613fcc1427e980be1fc5c74c0f8dfe697cbc Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 16:09:03 +0300 Subject: [PATCH 264/290] Added number 92 --- fr-IR/thing_92/README.md | 14 +++++--------- 1 file changed, 5 insertions(+), 9 deletions(-) diff --git a/fr-IR/thing_92/README.md b/fr-IR/thing_92/README.md index 730d20b2..c6f0d937 100644 --- a/fr-IR/thing_92/README.md +++ b/fr-IR/thing_92/README.md @@ -1,13 +1,9 @@ -# When Programmers and Testers Collaborate +# تعامل مابین دولوپرها و تسترها -Something magical happens when testers and programmers start to collaborate. There is less time spent sending bugs back and forth through the defect tracking system. Less time is wasted trying to figure out whether something is really a bug or a new feature, and more time is spent developing good software to meet customer expectations. There are many opportunities for starting collaboration before coding even begins. +اگر بتوان در تیم‌های توسعهٔ نرم‌افزار فضایی ایجاد کرد که دولوپرها و تسترها به تعامل سازنده‌ای با یکدیگر بپردازند، این کار مزایای بسیاری در بر خواهد داشت که از جملهٔ مهم‌ترین آن‌ها می‌توان به این نکته اشاره کرد که به راحتی تفاوت مابین یک باگ و فیچر در ذهن دولوپرها و تسترها مشخص می‌شود، نیازی به استفاده از نرم‌افزارهای پیشرفتهٔ دیباگینگ وجود نخواهد داشت چرا که یک تستر واقعی نرم‌افزار را تست کرده است و مهم‌تر از همه اینکه محصول نهایی که به دست مشتریان می‌رسد، اصطلاحاً Bug Free (بدون باگ) خواهد بود. -Testers can help customers write and automate acceptance tests using the language of their domain with tools such as Fit (Framework for Integrated Test). When these tests are given to the programmers before they coding begins, the team is practicing Acceptance Test Driven Development (ATDD). The programmers write the fixtures to run the tests, and then code to make the tests pass. These tests then become part of the regression suite. When this collaboration occurs, the functional tests are completed early allowing time for exploratory testing on edge conditions or through workflows of the bigger picture. +گاهی‌اوقات می‌شود پا را از این هم فراتر گذاشت و به عنوان یک تستر، حتی قبل از شروع کدنویسی یک فیچر جدید توسط دولوپرها، اقدام ارائهٔ روش‌های تست نرم‌افزار کرد به ایشان کرد (مثلاً اینکه نرم‌افزار به چه شکلی تست می‌شود) تا بر آن اساس، دولوپرها شروع به کدنویسی کنند و دغدغه‌های تسترها را در حین کدنویسی مد نظر داشته باشند. -We can take it one step further. As a tester, I can supply most of my testing ideas before the programmers start coding a new feature. When I ask the programmers if they have any suggestions, they almost always provide me with information that helps me with better test coverage, or helps me to avoid spending a lot of time on unnecessary tests. Often we have prevented defects because the tests clarify many of the initial ideas. For example, in one project I was on, the Fit tests I gave the programmers displayed the expected results of a query to respond to a wildcard search. The programmer had fully intended to code only complete word searches. We were able to talk to the customer and determine the correct interpretation before coding started. By collaborating, we prevented the defect, which saved us both a lot of wasted time. +آنچه مسلم است اینکه دولوپرها و تسترها هرگز نباید یکدیگر را «دشمن» تلقی کنند بدین صورت که مثلاً تسترها تمام تلاش خود را به کار بندند تا اپلیکیشنی که توسط همکارانشان کدنویسی شده را هک کنند تا به ایشان ثابت کنند که کار خود را بلد نیستند؛ بلکه هدف ارتقاء کیفیت کار است. -Programmers can collaborate with testers to create successful automation as well. They understand good coding practices and can help testers set up a robust test automation suite that works for the whole team. I have often seen test automation projects fail because the tests are poorly designed. The tests try to test too much or the testers haven't understood enough about the technology to be able to keep tests independent. The testers are often the bottleneck, so it makes sense for programmers to work with them on tasks like automation. Working with the testers to understand what can be tested early, perhaps by providing a simple tool, will give the programmers another cycle of feedback which will help them deliver better code in the long run. - -When testers stop thinking their only job is to break the software and find bugs in the programmers' code, programmers stop thinking that testers are 'out to get them,' and are more open to collaboration. When programmers start realizing they are responsible for building quality into their code, testability of the code is a natural by-product, and the team can automate more of the regression tests together. The magic of successful teamwork begins. - -By [Janet Gregory](http://programmer.97things.oreilly.com/wiki/index.php/Janet_Gregory) \ No newline at end of file +در واقع، از آنجا که هدف اصلی چیزی نیست جز ارائهٔ یک اپلیکیشن باکیفیت به مشتری، این تعامل مابین تک‌تک اعضای تیم به هرچه عملی‌تر شدن این پروسه کمک بیشتری خواهد کرد. From ec29d41b46dbc46055647cdcb2f6204b52947485 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 16:10:05 +0300 Subject: [PATCH 265/290] Added number 93 --- fr-IR/thing_93/README.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/fr-IR/thing_93/README.md b/fr-IR/thing_93/README.md index e4ff8323..79247117 100644 --- a/fr-IR/thing_93/README.md +++ b/fr-IR/thing_93/README.md @@ -1,13 +1,13 @@ -# Write Code as If You Had to Support It for the Rest of Your Life +# طوری کد بزنید که گویی قرار است تا آخر عمر سورس‌کدتان را ساپورت کنید! -You could ask 97 people what every programmer should know and do, and you might hear back 97 distinct answers. This could be both overwhelming and intimidating at the same time. All advice is good, all principles are sound, and all stories are compelling, but where do you start? More important, once you have started, how do you keep up with all the best practices you've learned and how do you make them an integral part of your programming practice? +۹۶ چیزی که در این دورهٔ آموزشی مطرح شده یک طرف، پیاده‌سازی آنچه در ادامه می‌بینید طرف دیگر: -I think the answer lies in your frame of mind or, more plainly, in your attitude. If you don't care about your fellow developers, testers, managers, sales and marketing people, and end users, then you will not be driven to employ Test-Driven Development or write clear comments in your code, for example. I think there is a simple way to adjust your attitude and always be driven to deliver the best quality products: +طوری کد بزنید که گویی قرار است تا آخر عمر سورس‌کدتان را ساپورت کنید! -> *Write code as if you had to support it for the rest of your life.* +در واقع، اگر بتوانیم در حین کد زدن چنین چیزی را رعایت کنیم، اتفاقات بسیار خوبی در انتظار ما خواهد بود. برای روشن‌تر شدن اهمیت این مسأله، اجازه دهید شرایط زیر را مد نظر قرار دهیم. -That's it. If you accept this notion, many wonderful things will happen. If you were to accept that any of your previous or current employers had the right to call you in the middle of the night, asking you to explain the choices you made while writing the fooBar method, you would gradually improve toward becoming an expert programmer. You would naturally want to come up with better variable and method names. You would stay away from blocks of code comprising hundreds of lines. You would seek, learn, and use design patterns. You would write comments, test your code, and refactor continually. Supporting all the code you'd ever written for the rest of your life should also be a scalable endeavor. You would therefore have no choice but to become better, smarter, and more efficient. +فرض کنیم وقتی که با یک شرکت نرم‌افزاری به عنوان دولوپر قرارداد می‌بندیم، کارفرمای ما این اجازه را خواهد داشت که تا ۱۰ سال آینده، در هر ساعت از شبانه‌روز -مثلاً ۳ نیمه‌شب- با ما تماس گرفته و پشتیبانی طلب کند. -If you reflect on it, the code you wrote many years ago still influences your career, whether you like it or not. You leave a trail of your knowledge, attitude, tenacity, professionalism, level of commitment, and degree of enjoyment with every method and class and module you design and write. People will form opinions about you based on the code that they see. If those opinions are constantly negative, you will get less from your career than you hoped. Take care of your career, of your clients, and of your users with every line of code — write code as if you had to support it for the rest of your life. +صرفاً در چنین شرایطی است که ما در انتخاب نام کلاس‌ها، متدها و متغیرها تمام دقت را به خرج خواهیم داد تا نام‌هایی بامسمی انتخاب کنیم، فانکشن‌هایی نخواهیم نوشت که طول آنها صدها خط باشد، از دیزاین پترن‌ها به بهترین شکل ممکن استفاده خواهیم کرد،‌ کامنت‌گذاری اصولی خواهیم داشت و چیزهایی از این دست. -By [Yuriy Zubarev](http://programmer.97things.oreilly.com/wiki/index.php/Yuriy_Zubarev) \ No newline at end of file +به خاطر داشته باشیم کدی که ما به عنوان دولوپر می‌نویسیم، به نوعی جزو رزومهٔ ما محسوب می‌گردد و دیگر دولوپرهایی که با کدهای ما کار خواهند کرد، از روی نحوهٔ کدنویسی ما به میزان حرفه‌ای بودن ما نیز پی خواهند برد و در دراز مدت ایماژی مثبت یا منفی نسبت به ما شکل خواهد گرفت. From 7dd098d4d81e5831accf0ceb97843d01c7ac3f20 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 16:10:42 +0300 Subject: [PATCH 266/290] Added number 94 --- fr-IR/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fr-IR/SUMMARY.md b/fr-IR/SUMMARY.md index cf7484d4..25f9e960 100644 --- a/fr-IR/SUMMARY.md +++ b/fr-IR/SUMMARY.md @@ -94,7 +94,7 @@ 1. [درک تفاوت مفاهیم DRY و WET در کدنویسی بهینه](thing_91/README.md) 1. [زمانی که برنامه نویسان و تسترها با هم همکاری کنند!](thing_92/README.md) 1. [طوری کد بنویسید که انگار باید تا آخر عمر برای آن پشتیبانی بدهید](thing_93/README.md) -1. [Write Small Functions Using Examples](thing_94/README.md) +1. [تا حد ممکن فانکشن‌های کوچک بنویسید](thing_94/README.md) 1. [برای دیگران هم تست بنویسید](thing_95/README.md) 1. [به کدهایتان اهمیت بدهید](thing_96/README.md) 1. [منظور مشتریان شما چیزی نیست که می گویند!](thing_97/README.md) From 5ee451c1d73f86b59d26bbc3236cdc68a54137ab Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 16:11:02 +0300 Subject: [PATCH 267/290] Added number 94 --- fr-IR/thing_94/README.md | 27 ++++----------------------- 1 file changed, 4 insertions(+), 23 deletions(-) diff --git a/fr-IR/thing_94/README.md b/fr-IR/thing_94/README.md index 4b5181cd..04c4f995 100644 --- a/fr-IR/thing_94/README.md +++ b/fr-IR/thing_94/README.md @@ -1,26 +1,7 @@ -# Write Small Functions Using Examples +# تا حد ممکن فانکشن‌های کوچک بنویسید -We would like to write code that is correct, and have evidence on hand that it is correct. It can help with both issues to think about the "size" of a function. Not in the sense of the amount of code that implements a function — although that is interesting — but rather the size of the mathematical function that our code manifests. +وقتی که صحبت از اندازهٔ (Size) یک فانکشن یا تابع به میان می‌آید، منظور هم می‌تواند تعداد خطوطی که داخل فانکشن مد نظر نوشته شده باشد و هم تعداد تَسک‌هایی که آن فانکشن قرار است انجام دهد. -For example, in the game of Go there is a condition called *atari* in which a player's stones may be captured by their opponent: A stone with two or more free spaces adjacent to it (called *liberties*) is not in atari. It can be tricky to count how many liberties a stone has, but determining atari is easy if that is known. We might begin by writing a function like this: +گرچه هر دو موضوع از اهمیت بسزایی برخوردارند، اما تخصصی بودن فانکشن از اهمیت به مراتب بیشتری برخوردار است. در واقع، هرچه ما فانکشن‌هایی که می‌نویسیم تخصصی‌تر باشند، مدیریت سورس‌کد در آینده، خواندن کدها توسط دیگر دولوپرها و به حداقل رساندن وابستگی‌ها در سورس‌کد پروژه‌ٔ خود بیشتر و بیشتر می‌شود. -``` -boolean atari(int libertyCount) - libertyCount < 2 -``` - -This is larger than it looks. A mathematical function can be understood as a set, some subset of the Cartesian product of the sets that are its domain (here, `int`) and range (here, `boolean`). If those sets of values were the same size as in Java then there would be `2L*(Integer.MAX_VALUE+(-1L*Integer.MIN_VALUE)+1L)` or 8,589,934,592 members in the set `int×boolean`. Half of these are members of the subset that is our function, so to provide complete evidence that our function is correct we would need to check around 4.3×109 examples. - -This is the essence of the claim that tests cannot prove the absence of bugs. Tests can demonstrate the presence of features, though. But still we have this issue of size. - -The problem domain helps us out. The nature of Go means that number of liberties of a stone is not any int, but exactly one of {1,2,3,4}. So we could alternatively write: - -``` -LibertyCount = {1,2,3,4} -boolean atari(LibertyCount libertyCount) - libertyCount == 1 -``` - -This is much more tractable: The function computed is now a set with at most eight members. In fact, four checked examples would constitute evidence of complete certainty that the function is correct. This is one reason why it's a good idea to use types closely related to the problem domain to write programs, rather than native types. Using domain–inspired types can often make our functions much smaller. One way to find out what those types should be is to find the examples to check in problem domain terms, before writing the function. - -by [Keith Braithwaite](http://programmer.97things.oreilly.com/wiki/index.php/Keith_Braithwaite) \ No newline at end of file +به عبارت دیگر، هر فانکشن نباید بیش از یک تَسک (کار) را انجام دهد که در چنین حالتی می‌گوییم فانکشن مد نظر دارای قابلیت Single Responsibility است. From b291870f43fa78a5e48db53fe129e7f5e0320a54 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 16:11:34 +0300 Subject: [PATCH 268/290] Added number 95 --- fr-IR/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fr-IR/SUMMARY.md b/fr-IR/SUMMARY.md index 25f9e960..86e5a90c 100644 --- a/fr-IR/SUMMARY.md +++ b/fr-IR/SUMMARY.md @@ -95,6 +95,6 @@ 1. [زمانی که برنامه نویسان و تسترها با هم همکاری کنند!](thing_92/README.md) 1. [طوری کد بنویسید که انگار باید تا آخر عمر برای آن پشتیبانی بدهید](thing_93/README.md) 1. [تا حد ممکن فانکشن‌های کوچک بنویسید](thing_94/README.md) -1. [برای دیگران هم تست بنویسید](thing_95/README.md) +1. [برای دولوپرها تست بنویسید نه برای ماشین‌ها!](thing_95/README.md) 1. [به کدهایتان اهمیت بدهید](thing_96/README.md) 1. [منظور مشتریان شما چیزی نیست که می گویند!](thing_97/README.md) From ef9bea4e4284c90fed3ce569fd4400a81ef47a1a Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 16:12:06 +0300 Subject: [PATCH 269/290] Added number 95 --- fr-IR/thing_95/README.md | 21 ++++++++++++--------- 1 file changed, 12 insertions(+), 9 deletions(-) diff --git a/fr-IR/thing_95/README.md b/fr-IR/thing_95/README.md index 7ba49719..f84f8530 100644 --- a/fr-IR/thing_95/README.md +++ b/fr-IR/thing_95/README.md @@ -1,15 +1,18 @@ -# Write Tests for People +# برای دولوپرها تست بنویسید نه برای ماشین‌ها! +اگر شما جزو دولوپرهایی هستید که در حین پیاده‌سازی پروژه‌های نرم‌افزاری اقدام به نوشتن Automated Test می‌کنید،‌ بایستی بدانید که این کار بسیار روند توسعهٔ نرم‌افزار شما را اثربخش می‌سازد و اگر هم جزو آن دسته از دولوپرهایی هستید که قبل از نوشتن کدهای اصلی، ابتدا به ساکن اقدام به نوشتن تست می‌کنید، بایستی به شما تبریک گفت؛ اما در عین حال سؤال اینجا است که آیا تست‌هایی که می‌نویسید خوب هستند؟ -You are writing automated tests for some or all of your production code. Congratulations! You are writing your tests before you write the code? Even better!! Just doing this makes you one of the early adopters on the leading edge of software engineering practice. But are you writing good tests? How can you tell? One way is to ask "Who am I writing the tests for?" If the answer is "For me, to save me the effort of fixing bugs" or "For the compiler, so they can be executed" then the odds are you aren't writing the best possible tests. So *who* should you be writing the tests for? For the person trying to understand your code. +برای یافتن پاسخ به این سؤال، بایستی از خود بپرسید که «تست‌های نرم‌افزاری برای چه کسی نوشته می‌شوند؟» و چنانچه پاسخ به این سؤال چیزهایی همچون «برای خود دولوپر» یا «برای کامپایلر» باشد، این حاکی از آن است که تست‌های خوبی ننوشته‌اید! -Good tests act as documentation for the code they are testing. They describe how the code works. For each usage scenario the test(s): +در حقیقت، یک تست نرم‌افزاری خوب تستی است که به منزلهٔ مستندات پروژه تلقی می‌گردد و حاکی از آنند که سورس‌کد چگونه کار می‌کند. در واقع تست‌ها: +- نقطهٔ شروع اپلیکیشن را به هر دولوپری نشان می‌دهند. +- کاربرد نرم‌افزار را برای هر دولوپری تشریح می‌کنند. +- نتایج قابل انتظار را به هر دولوپری نشان می‌دهند. -1. Describe the context, starting point, or preconditions that must be satisfied -2. Illustrate how the software is invoked -3. Describe the expected results or postconditions to be verified +بسته به نوع کاربرد، ما نیاز داریم تا تست‌های مختلفی بنویسیم. همچنین دولوپر دیگری که قرار است روی سورس‌کد ما کار کند، بایستی با مد نظر داشتن سه نکتهٔ فوق،‌ بتواند دقیقاً پی به نوع عملکرد نرم‌افزار ببرد. از سوی دیگر، هر تست نرم‌افزاری باید به وضوح رابطهٔ علت-معلولی مابین این سه بخش را شرح دهد. -Different usage scenarios will have slightly different versions of each of these. The person trying to understand your code should be able to look at a few tests and by comparing these three parts of the tests in question, be able to see what causes the software to behave differently. Each test should clearly illustrate the cause and effect relationship between these three parts. This implies that what isn't visible in the test is just as important as what is visible. Too much code in the test distracts the reader with unimportant trivia. Whenever possible hide such trivia behind meaningful method calls — the Extract Method refactoring is your best friend. And make sure you give each test a meaningful name that describes the particular usage scenario so the test reader doesn't have to reverse engineer each test to understand what the various scenarios are. Between them, the names of the test class and class method should include at least the starting point and how the software is being invoked. This allows the test coverage to be verified via a quick scan of the method names. It can also be useful to include the expected results in the test method names as long as this doesn't cause the names to be too long to see or read. +در حین طراحی تست‌های نرم‌افزاری، حتماً اسم‌هایی بامسمی‌ برای آنها در نظر بگیرید؛ از سوی دیگر، کاربرد هر تستی بایستی کاملاً مشخص باشد تا دیگر دولوپرها به منظور درک ماهیت تست، مجبور به مهندسی معکوس کردن نباشند. -It is also a good idea to test your tests. You can verify they detect the errors you think they detect by inserting those errors into the production code (your own private copy that you'll throw away, of course). Make sure they report errors in a helpful and meaningful way. You should also verify that your tests speak clearly to a person trying to understand your code. The only way to do this is to have someone who isn't familiar with your code read your tests and tell you what they learned. Listen carefully to what they say. If they didn't understand something clearly it probably isn't because they aren't very bright. It is more likely that you weren't very clear. (Go ahead and reverse the roles by reading their tests!) +تست کردن تست‌ها +یک راه‌کار خوب برای اطمینان حاصل کردن از این که هم سورس‌کد اصلی و هم تست‌ها به خوبی کار می‌کنند، تست کردن تست‌ها است بدین صورت که از عمد باگ‌هایی در سورس‌کد اصلی پروژه ایجاد کرده و تست‌ها را اجرا کنید تا اطمینان حاصل کنید که باگ‌ها خیلی سریع توسط تست‌ها یافت می‌شوند. -by [Gerard Meszaros](http://programmer.97things.oreilly.com/wiki/index.php/Gerard_Meszaros) +همچنین اطمینان حاصل کنید که اکسپشن‌ها و ارورهای معناداری در معرض دید دولوپر قرار می‌گیرد و دولوپر به سادگی با نگاه کردن به ارور، متوجهٔ ریشهٔ باگ خواهد شد. From d24ddbd4781f0a1909cdc10019caa8e8b9fdf690 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 16:13:07 +0300 Subject: [PATCH 270/290] Added number 96 --- fr-IR/SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fr-IR/SUMMARY.md b/fr-IR/SUMMARY.md index 86e5a90c..647809fb 100644 --- a/fr-IR/SUMMARY.md +++ b/fr-IR/SUMMARY.md @@ -96,5 +96,5 @@ 1. [طوری کد بنویسید که انگار باید تا آخر عمر برای آن پشتیبانی بدهید](thing_93/README.md) 1. [تا حد ممکن فانکشن‌های کوچک بنویسید](thing_94/README.md) 1. [برای دولوپرها تست بنویسید نه برای ماشین‌ها!](thing_95/README.md) -1. [به کدهایتان اهمیت بدهید](thing_96/README.md) +1. [مراقب سورس‌ کد باشید!](thing_96/README.md) 1. [منظور مشتریان شما چیزی نیست که می گویند!](thing_97/README.md) From 99ec8aef565d8d8930a7bf65dc3c52dbb7a2436b Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 16:13:28 +0300 Subject: [PATCH 271/290] Added number 96 --- fr-IR/thing_96/README.md | 24 +++++++++--------------- 1 file changed, 9 insertions(+), 15 deletions(-) diff --git a/fr-IR/thing_96/README.md b/fr-IR/thing_96/README.md index d6cc6dcc..0d62202a 100644 --- a/fr-IR/thing_96/README.md +++ b/fr-IR/thing_96/README.md @@ -1,23 +1,17 @@ -# You Gotta Care about the Code +# مراقب سورس‌کد باشید! -It doesn't take Sherlock Holmes to work out that good programmers write good code. Bad programmers... don't. They produce monstrosities that the rest of us have to clean up. You want to write the good stuff, right? You want to be a good programmer. +بعید به نظر می‌رسد دولوپری را بتوان یافت که دوست نداشته باشد برچسب حرفه‌ای رویش بخورد. به طور کلی، به دولوپری می‌توان لقب حرفه‌ای داد که کدهای حرفه‌ای هم بنویسید؛ اگر هم بخواهیم کدی حرفه‌ای به نظر برسد، باید به نحوهٔ نوشتن آن توجه قابل‌توجهی کرد. -Good code doesn't pop out of thin air. It isn't something that happens by luck when the planets align. To get good code you have to work at it. Hard. And you'll only get good code if you actually care about good code. +کدنویسی حرفه‌ای و اصولی اصلاً ربطی به دانش فنی دولوپر ندارد. بسیار کسانی هستند که می‌توانند الگوریتم‌های بسیار پیچیده‌ای طراحی کنند اما زمانی که پای کدنویسی به میان می‌آید، کدهای بسیار زشتی می‌نویسند. به عبارت دیگر، درک، استفاده و ریفکتور کردن کدهای ایشان بسیار دشوار است. در مقابل، دولوپرهای تازه‌کار و حد متوسطی را هم می‌توان یافت که دانش فنی ایشان اصلاً به پای گروه فوق‌الذکر نمی‌رسد، اما کدهای ایشان در یک کلام عالی است. -Good programming is not born from mere technical competence. I've seen highly intellectual programmers who can produce intense and impressive algorithms, who know their language standard by heart, but who write the most awful code. It's painful to read, painful to use, and painful to modify. I've seen more humble programmers who stick to very simple code, but who write elegant and expressive programs that are a joy to work with. +به نوعی می‌توان گفت که یکی از وجوه تمایز دولوپرهای عالی با سایر دولوپرها،‌ نگرش ایشان به کار است. این گروه از دولوپرها به خوبی با ضرب‌العجل (ددلاین) تحویل پروژه، محدودیت‌های فنی و غیره آشنایی دارند، اما در عین حال تمام تلاش خود را می‌کنند تا بهترین کدی که می‌شود را بنویسند. به طور کلی، اگر قصد دارید حرفه‌ای به نظر برسید، بایستی کدهای حرفه‌ای بنویسید و برای نوشتن کدهای حرفه‌ای هم می‌توانید استراتژی‌های زیر را مد نظر قرار دهید: -Based on my years of experience in the software factory, I've concluded that the real difference between adequate programmers and great programmers is this: *attitude*. Good programming lies in taking a professional approach, and wanting to write the best software you can, within the Real World constraints and pressures of the software factory. +- تحت هر شرایطی، صرفاً به کار کردن کد تحت شرایط عادی رضایت ندهید؛ بلکه تمام تلاش خود را به کار گیرید تا تمامی جوانب کار را بسنجید. در واقع، از سالم بودن کد (قابل اجرا بودن کد تحت هر شرایطی) اطمینان حاصل کنید. -*The code to hell is paved with good intentions.* To be an excellent programmer you have to rise above good intentions, and actually *care* about the code — foster positive perspectives and develop healthy attitudes. Great code is carefully crafted by master artisans, not thoughtlessly hacked out by sloppy programmers or erected mysteriously by self-professed coding gurus. +- کدی بنویسید که از یک سو هر دولوپر دیگری بتواند از آن سر در بیاورد و از سوی دیگر، قابل پشتیبانی و گسترش باشد. -You want to write good code. You want to be a good programmer. So, you care about the code: +- امروزه کمتر دولوپر موفقی را می‌توان یافت که به تنهایی کار کند؛‌ اکثراً یا در شرکت‌های نرم‌افزاری مشغول به کار هستند و یا اگر هم در منزل روی پروژه‌های اپن‌سورس کار می‌کند، با دیگر دولوپرهای سراسر دنیا در تعامل هستند. در همین راستا، روی مهارت‌های ارتباطی خود با دیگر همکاران فنی/غیرفنی نیز کار کنید. -- In any coding situation, you refuse to hack something that only seems to work. You strive to craft elegant code that is clearly correct (and has good tests to show that it is correct). -- You write code that is *discoverable* (that other programmers can easily pick up and understand), that is *maintainable* (that you, or other programmers, will be easily able to modify in the future), and that is correct (you take all steps possible to determine that you have solved the problem, not just made it look like the program works). -- You work well alongside other programmers. No programmer is an island. Few programmers work alone; most work in a team of programmers, either in a company environment or on an open source project. You consider other programmers, and construct code that others can read. You want the team to write the best software possible, rather than to make yourself look clever. -- Any time you touch a piece of code you strive to leave it better than you found it (either better structured, better tested, more understandable...). -- You care about code and about programming, so you are constantly learning new languages, idioms, and techniques. But you only apply them when appropriate. +- هر موقعی که با کدی برخورد کردید، تمام تلاش خود را به کار گیرید تا حتی اگر شده اندکی آن را بهبود بخشید (اگر توانستید که ساختار را بهبود بخشید و اگر امکان‌پذیر نبود، حداقل با کامنت‌گذاری درک آن را بهبود بخشید). -Fortunately, you're reading this collection of advice because you do care about code. It interests you. It's your passion. Have fun programming. Enjoy cutting code to solve tricky problems. Produce software that makes you proud. - -By [Pete Goodliffe](http://programmer.97things.oreilly.com/wiki/index.php/Pete_Goodliffe) \ No newline at end of file +- گرچه دولوپرها همواره در معرض تکنولوژی‌های جدیدی هستند اما این هرگز بدان معنا نیست که در هر پروژه‌ای باید از جدیدترین تکنولوژی‌ها استفاده کنید بلکه بایستی نیاز پروژه را درک کرده و بسته به ماهیت، نیازها و زیرساخت پروژه اقدام به استفاده از زبان‌ برنامه‌نویسی، لایبرری، فریمورک و یا ابزار مناسب کنید. From e41fabbf8e026c58506569181b0ca172673968c0 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 16:14:48 +0300 Subject: [PATCH 272/290] Added number 97! Done! --- fr-IR/thing_97/README.md | 22 +++++++++++++++------- 1 file changed, 15 insertions(+), 7 deletions(-) diff --git a/fr-IR/thing_97/README.md b/fr-IR/thing_97/README.md index 8a812b72..946002d2 100644 --- a/fr-IR/thing_97/README.md +++ b/fr-IR/thing_97/README.md @@ -1,13 +1,21 @@ -# Your Customers Do not Mean What They Say +# منظور مشتریان شما چیزی نیست که می گویند! -I've never met a customer yet that wasn't all too happy to tell me what they wanted — usually in great detail. The problem is that customers don't always tell you the whole truth. They generally don't lie, but they speak in customer speak, not developer speak. They use their terms and their contexts. They leave out significant details. They make assumptions that you've been at their company for 20 years, just like they have. This is compounded by the fact that many customers don't actually know what they want in the first place! Some may have a grasp of the "big picture," but they are rarely able to communicate the details of their vision effectively. Others might be a little lighter on the complete vision, but they know what they don't want. So, how can you possibly deliver a software project to someone who isn't telling you the whole truth about what they want? It's fairly simple. Just interact with them more. +تجربه نشان داده است که مشتریان پروژه‌های نرم‌افزاری هرگز نمی‌دانند که چه می‌خواهند! گرچه گاهی‌اوقات ایشان اصلاً نمی‌دانند که چه می‌خواهند، اما در بیشتر مواقع ایشان می‌دانند که چه چیزی مد نظرشان است اما نمی‌توانند آن را به زبانی که برای دولوپر جماعت قابل‌فهم باشد بیان کنند. -Challenge your customers early and challenge them often. Don't simply restate what they told you they wanted in their words. Remember: They didn't mean what they told you. I often do this by swapping out words in conversation with them and judging their reaction. You'd be amazed how many times the term *customer* has a completely different meaning to the term *client*. Yet the guy telling you what he wants in his software project will use the terms interchangeably and expect you to keep track as to which one he's talking about. You'll get confused and the software you write will suffer. +در واقع، همین که مشتریان جزئیات قابل‌توجهی را در حین مذاکرات با تیم توسعهٔ نرم‌افزار از قلم می‌اندازند، صدمات جبران‌ناپذیری به روند اجرای پروژه می‌زند. به طور مثال، ایشان فرض را بر این می‌گذارند که دولوپر/دولوپرها با ماهیت کاری ایشان، شرکت، نیازها، مخاطبین و چیزهایی از این دست آشنایی دارند. -Discuss topics numerous times with your customers before you decide that you understand what they need. Try restating the problem two or three times with them. Talk to them about the things that happen just before or just after the topic you're talking about to get better context. If at all possible, have multiple people tell you about the same topic in separate conversations. They will almost always tell you different stories, which will uncover separate yet related facts. Two people telling you about the same topic will often contradict each other. Your best chance for success is to hash out the differences before you start your ultra-complex software crafting. +نکتهٔ دیگری که در این رابطه وجود دارد این است که اکثر مشتریان پروژه‌های نرم‌افزاری ابتدا به ساکن نمی‌دانند که چه کاربردهایی از نرم‌افزار مد نظرشان انتظار دارند و به مرور زمان ایده‌های جدیدی به ذهن ایشان می‌رسد. به عبارت دیگر، ایشان به خوبی Big Picture (تصویر کلی) از اپلیکیشنی که می‌خواهند را مد نظر دارند اما وقتی که پای جزئیات به میان می‌آید، هرگز دید روشنی از آنچه می‌خواهند ندارند. -Use visual aids in your conversations. This could be as simple as using a whiteboard in a meeting, as easy as creating a visual mock-up early in the design phase, or as complex as crafting a functional prototype. It is generally known that using visual aids during a conversation helps lengthen our attention span and increases the retention rate of the information. Take advantage of this fact and set your project up for success. +در نقطهٔ مقابل این دست مشتریان، گروهی دیگر از کارفرمایان هستند که می‌دانند چه چیزی نمی‌خواهند! در چنین شرایطی، یک دولوپر چگونه می‌تواند پی به واقعیت ماجرا ببرد تا در نهایت هم مشتری از چگونگی پیاده‌سازی پروژه راضی باشد و هم دولوپر احساس موفقیت پیدا کند؟ -In a past life, I was a "multimedia programmer" on a team who produced glitzy projects. A client of ours described their thoughts on the look and feel of the project in great detail. The general color scheme discussed in the design meetings indicated a black background for the presentation. We thought we had it nailed. Teams of graphic designers began churning out hundreds of layered graphics files. Loads of time was spent molding the end product. A startling revelation was made on the day we showed the client the fruits of our labor. When she saw the product, her exact words about the background color were "When I said black, I meant white." So, you see, it is never as clear as black and white. +در یک کلام، بایستی گفت که تعامل بیشتر با یکدیگر منجر به این خواهد شد تا جزئیات بیشتری مابین کارفرما (مشتری) و مجری (دولوپر) رد و بدل گردد. -By [Nate Jackson](http://programmer.97things.oreilly.com/wiki/index.php/Icnatejackson) \ No newline at end of file +وقتی پای مذاکره با مشتریان به میان می‌آید، همواره این نکته را مد نظر داشته باشید که ممکن است برخی از ایشان اصطلاحاً Technophobia (ترس از تکنولوژی) داشته باشند؛ لذا هرگز از Jargon (اصلاحات فنی) در مکالمه با ایشان استفاده نکنید و سعی کنید به ساده‌ترین شکل ممکن به صحبت با ایشان بپردازید. + +علاوه بر این، همواره این نکته را مد نظر داشته باشید که آنچه مشتری بر زبان می‌آورد، هرگز بدان معنا نیست که دقیقاً همان چیزی است که مد نظرش است! در همین راستا، هرآنچه بر زبان مشتری می‌آید را یک بار با استفاده از واژگان متفاوتی برایش بازگو کنید تا عکس‌العمل وی را جویا شوید. + +همچنین در صورت امکان و چنانچه قرار است برای مجموعه‌ای نرم‌افزار تولید کنید که بزرگ است، سعی کنید مسئله و نیاز آنها را از زبان چند شخص مختلف بشنوید تا از یکسان بودن دیدگاه‌ها و بالتبع پیدا کردن درک صحیحی از نیازهای ایشان اطمینان حاصل کنید (چنانچه چیزی که از زبان چند نفر می‌شنوید با یکدیگر در تضاد بود، شانس این را خواهید داشت تا ایشان را به قول معروف به جان یکدیگر بیندازید تا در نهایت مشخص شود که منظور کدام یک صحیح است). + +علاوه بر این، همواره مد نظر داشته باشید که برای برقراری ارتباطی مؤثر، می‌توانید در طول نشست از وایت‌بورد، نمودار، چارپ و غیره برای نشان دادن بهتر خروجی طرح استفاده کنید. + +تمامی این موارد به کنار، پس از عقد قرارداد دائماً مشتریان را در جریان روند پیشرفت پروژه قرار داده و در صورت امکان خروجی کار را در معرض دید ایشان قرار دهید تا چناچه علیرغم در نظر گرفتن نکات فوق کماکان سوء‌تفاهمی در انتقال نیازها صورت گرفته بود، بتوان قبل از این که خیلی دیر شود، تغییرات مد نظر را اعمال کرد. From 391715d55ca31b872c2518327549c11db8f565f2 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Wed, 17 May 2023 16:17:57 +0300 Subject: [PATCH 273/290] Update README.md --- fr-IR/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fr-IR/README.md b/fr-IR/README.md index f00d4fec..3539d24c 100644 --- a/fr-IR/README.md +++ b/fr-IR/README.md @@ -6,6 +6,6 @@ این یک [گیت بوک](https://www.gitbook.io) بر اساس کتاب [97 Things Every Programmer Should Know project](http://programmer.97things.oreilly.com/wiki/index.php/97_Things_Every_Programmer_Should_Know) است. -[فهرست](fr-IR/SUMMARY.md) +[فهرست کتاب](SUMMARY.md) همه محتوا تحت مجوز [Creative Commons Attribution Non Commercial Share Alike 3.0 license](http://creativecommons.org/licenses/by-nc-sa/3.0/) است. نسخه های چاپی کتاب را میتوانید در [Amazon.com](http://www.amazon.com/Things-Every-Programmer-Should-Know/dp/0596809484) بیابید. From 466f83fa74e5d69253a73360bfea064fdc53efe0 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Thu, 18 May 2023 13:32:44 +0300 Subject: [PATCH 274/290] Updated number 2 --- fr-IR/thing_02/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fr-IR/thing_02/README.md b/fr-IR/thing_02/README.md index 3aefb6d6..6534f4a3 100644 --- a/fr-IR/thing_02/README.md +++ b/fr-IR/thing_02/README.md @@ -1,5 +1,5 @@ # برنامه نویسی تابعی یا Functional Programming -برنامه نویسی تابعی یا Functional Programming در چند سال گذشته طرفداران بسیاری پیدا کرده است. این پارادایم عبارت است از روشی که در آن منطق به کار گرفته شده در برنامه به صورت توابع ریاضیاتی در نظر گرفته می شوند. درک صحیح این نوع پارادایم به طرز قابل توجهی کمک به ارتقاء کیفیت کدی که نوشته می‌شود خواهد کرد و چنانچه شما -به عنوان یک برنامه نویسی- از اصول برنامه نویسی تابعی استفاده کنید، کیفیت برنامه‌ای که می نویسید دوچندان خواهد شد که در نهایت با تعداد خطوط کدی کمتری، نتیجه ای که نیاز دارید را به دست خواهید آورد. +برنامه نویسی تابعی یا Functional Programming در چند سال گذشته طرفداران بسیاری پیدا کرده است. این پارادایم عبارت است از روشی که در آن منطق به کار گرفته شده در برنامه به صورت توابع ریاضیاتی در نظر گرفته می شوند. درک صحیح این نوع پارادایم به طرز قابل توجهی کمک به ارتقاء کیفیت کدی که نوشته می‌شود خواهد کرد و چنانچه شما -به عنوان یک برنامه نویس- از اصول برنامه نویسی تابعی استفاده کنید، کیفیت برنامه‌ای که می نویسید دوچندان خواهد شد که در نهایت با تعداد خطوط کدی کمتری، نتیجه ای که نیاز دارید را به دست خواهید آورد. زمانی که در پروژه های خود از توابع استفاده می کنیم، مسئولیت های خاصی را می‌توان به هر تابع اختصاص داد و توابع با استفاده از آرگومان هایی که می گیرند، می‌توانند خروجی های مختلفی را در اختیار سایر بخش های برنامه قرار دهند. برنامه‌هایی که در آن‌ها از توابع به درستی استفاده شده باشد، نسبت به روش‌های سنتی برنامه نویسی به سادگی قابل Debug کردن هستند. برنامه نویسی تابعی در برنامه نویسی شیئ گرایی به خوبی جواب داده است اما این در حالی است که در تمامی موقعیت ها نمی‌توان از این پارادایم استفاده کرد. From c06118b6274cf834058c8a88cb37f039f82cb1c2 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Thu, 18 May 2023 13:33:58 +0300 Subject: [PATCH 275/290] Updated number 3 --- fr-IR/thing_03/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fr-IR/thing_03/README.md b/fr-IR/thing_03/README.md index ad755174..1b29a3c5 100644 --- a/fr-IR/thing_03/README.md +++ b/fr-IR/thing_03/README.md @@ -6,4 +6,4 @@ برای رفع این مشکل، می بایست از یک کاربر عادی بخواهیم که به تعامل با برنامه، سایت یا اپلیکیشن ما بپردازد و نحوه ارتباط برقرار ساختن وی با نرم‌افزار را به دقت مورد بررسی قرار دهیم. در‌واقع می بایست ببینیم که نیازهای این کاربر چیست، کجاها به مشکل بر می خورد، در کدام بخش‌ها سردرگم می‌شود و … برای روشن شدن این مسأله مثالی می زنیم. زمانی که یک برنامه نویس به عنوان مثال سایتی را کدنویسی می کند، زمانی که در ناحیه کاربری به مشکلی برخورد می‌کند به طور حتم می‌داند که از چه طریق می بایست آن مشکل را رفع کرد اما این مسأله در مورد کابران عادی صدق نمی‌کند و ایشان ممکن است به محض برخورد با کوچک‌ترین مشکل، از هدف خود دست بکشند. نکته دیگری که می بایست همواره مد نظر قرار دهیم این است که در اکثر مواقع مابین آنچه کاربران واقعاً به آن نیاز دارند و آنچه بیان می‌کنند یک شکاف وجود دارد. به عبارت دیگر و به قول مرحوم استیو جابز، این کاربران نیستند که می‌گویند چه می‌خواهند بلکه این شما به عنوان یک طراح هستید که می بایست به نیاز کاربران پی برده و نیاز ایشان را به بهترین شکل به ایشان عرضه کنید. -برای رفع این مشکل، به جای گوش کردن به صحبت‌های کاربران، می بایست به تعامل ایشان با سایت، نرم‌افزار یا اپلیکیشن نگاه کرده و از روی رفتار ایشان با برنامهٔ‌مان، وی را نیاز سنجی کنیم. در یک کلام، اگر چند دقیقه به رفتار یک کاربر با برنامه خود نگاه کنیم، به مراتب مثمرثمر تر از انجام یک مصاحبه چند ساعتی با چندین مخاطب بالقوه در مورد نیازهای ایشان خواهد بود. +برای رفع این مشکل، به جای گوش کردن به صحبت‌های کاربران، می بایست به تعامل ایشان با سایت، نرم‌افزار یا اپلیکیشن نگاه کرده و از روی رفتار ایشان با برنامهٔ‌مان، وی را نیاز سنجی کنیم. در یک کلام، اگر چند دقیقه به رفتار یک کاربر با برنامه خود نگاه کنیم، به مراتب مثمرالثمر تر از انجام یک مصاحبه چند ساعتی با چندین مخاطب بالقوه در مورد نیازهای ایشان خواهد بود. From a1293cd4893583cd6c5c224cd9a1bb2bb82d972e Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Thu, 18 May 2023 13:34:55 +0300 Subject: [PATCH 276/290] Updated number 4 --- fr-IR/thing_04/README.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fr-IR/thing_04/README.md b/fr-IR/thing_04/README.md index 6537744b..9586e719 100644 --- a/fr-IR/thing_04/README.md +++ b/fr-IR/thing_04/README.md @@ -1,4 +1,5 @@ # استاندارهای کدنویسی + استاندارهای کدنویسی یا Coding Standards یکی از چیزهایی است که هر برنامه نویسی که قصد دارد لیبل حرفه‌ای رویش بخورد می بایست دنبال کند. پیروی از استانداردهای کدنویسی کار خیلی آسانی هم نیست و گاهی اوقات خیلی خسته‌کننده می‌شود اما واقعیت امر این است که در پروژه های نسبتاً بزرگ اعضای تیم نیاز دارند تا از یکسری قوانین تبعیت کنند. توجه داشته باشیم زمانی که یک سری قوانین کدنویسی -مثلا تعداد اسپیس هایی که می بایست در کدها استفاده کرد- را وضع می کنیم، تمامی اعضای تیم می بایست قبول کنند که از آن قوانین تبعیت کنند که در غیر این صورت، یک برنامه نویس خاطی می‌تواند هر چه سایر برنامه نویسان رشته کرده‌اند را پنبه کند! برای اعمال استانداردهای کدنویسی می‌توان از یکسری ابزارها هم استفاده کرد که فرایند استاندارد سازی را تا حد قابل توجهی برای برنامه نویس سهل و آسان می سازند که این ابزارها بسته به IDEیی که استفاده می کنیم می توانند از خصوصیات مختلفی برخوردار باشند. @@ -7,7 +8,7 @@ به طور مثال، کدی که در زیر مشاهده می کنید بر اساس استاندارد PSR نوشته شده است: -``` +```php Date: Thu, 18 May 2023 13:37:03 +0300 Subject: [PATCH 277/290] Updated number 5 --- fr-IR/thing_05/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fr-IR/thing_05/README.md b/fr-IR/thing_05/README.md index e76f2cda..8efc1d0e 100644 --- a/fr-IR/thing_05/README.md +++ b/fr-IR/thing_05/README.md @@ -1,7 +1,7 @@ # ساده زیباست -جمله‌ای از افلاطون وجود دارد با این مظمون که «هارمونی، زیبایی ظاهری، ظرافت و موزون بودن همه و همه به سادگی بستگی دارند.» و این جمله اگر توسط برنامه نویسان به کار گرفته شود، مزایای بسیار زیادی برای ایشان در بر خواهد داشت که از آن جمله می‌توان به خوانایی بیشتر کدها، نگهداری راحت‌تر اسکریپت ها، افزایش سرعت کدنویسی و در نهایت کیفیت بالاتر کدهای نوشته شده اشاره کرد و تمامی این موارد -و حتی موارد بیشتر- جز با به کارگیری دیدگاه افلاطون یعنی همان سادگی امکان‌پذیر نیست. +جمله‌ای از افلاطون وجود دارد با این مضمون که «هارمونی، زیبایی ظاهری، ظرافت و موزون بودن همه و همه به سادگی بستگی دارند.» و این جمله اگر توسط برنامه نویسان به کار گرفته شود، مزایای بسیار زیادی برای ایشان در بر خواهد داشت که از آن جمله می‌توان به خوانایی بیشتر کدها، نگهداری راحت‌تر اسکریپت ها، افزایش سرعت کدنویسی و در نهایت کیفیت بالاتر کدهای نوشته شده اشاره کرد و تمامی این موارد -و حتی موارد بیشتر- جز با به کارگیری این دیدگاه افلاطون یعنی همان سادگی امکان‌پذیر نیست. حال می بایست به این سؤال پاسخ دهیم که به چه نوع کدی صفت زیبا اطلاق می گردد. این سؤال بسیار انتزاعی است چرا که مفهوم زیبایی چیزی کاملاً نسبی است. درکی که هنرمندان از زیبایی دارند به مراتب متفاوت تر از مهندسان یا برنامه نویسان است. لذا نیاز است تا مسئله ی زیبایی در برنامه نویسی را کمی بشکافیم! -برای درک بهتر این موضوع، بهتر است سری به گیت هاب زده و برخی اسکریپت های نوشته شده توسط برنامه نویسان از نقاط مختلف جهان را مشاهده کنید. با مقایسه کدهای مختلف متوجه خواهید شد که برخی برنامه نویسان هستند که یکسری قوانین را به خوبی رعایت می‌کنند و همین مسأله منجر می‌گردد تا کدهای نوشته شده توسط ایشان زیبا‌تر به نظر برسد. جالب است بدانیم که هرچه کدی ساده‌تر باشد، در عین حال زیبا‌تر هم به نظر می رسد. اگرچه برخی برنامه‌ها هستند که بسیار پیچیده هستند و کارهای عجیب و غریبی انجام می‌دهند که آدم را به شگفتی وا می دارند، اما اگر همین برنامه‌ها را به بخش‌های کوچک‌تری تقسیم‌بندی کنیم، خواهیم دید که اگر برنامه نویس آن برنامه مد نظر حرفه‌ای بوده باشد و به سادگی در کدنویسی ایمان داشته باشد، بخش‌های کوچک برنامه کاملاً ساده و قابل درک هستند، هر ماژول وظیفه ی مشخصی دارد، بخش‌های مختلف مثل کلاس ها، متدها و متغیرها به خوبی نامگذاری شده‌اند به طوری که اگر سایر برنامه نویسان هم به سورس کد نگاه کنند، به راحتی متوجه وظیفه هر بخش از کد خواهند شد. به طور خلاصه، کد زیبا کدی است که ساده باشد. بخش‌های مختلف نرم‌افزار می بایست دارای روابط ساده‌ای با سایر بخش‌ها بوده و به سادگی قابل درک باشند. +برای درک بهتر این موضوع، بهتر است سری به گیت هاب زده و برخی اسکریپت های نوشته شده توسط برنامه نویسان از نقاط مختلف جهان را مشاهده کنید. با مقایسه کدهای مختلف متوجه خواهید شد که برخی برنامه نویسان هستند که یکسری قوانین را به خوبی رعایت می‌کنند و همین مسأله منجر می‌گردد تا کدهای نوشته شده توسط ایشان زیبا‌تر به نظر برسد. جالب است بدانیم که هرچه کدی ساده‌تر باشد، در عین حال زیبا‌تر هم به نظر می رسد. اگرچه برخی برنامه‌ها هستند که بسیار پیچیده هستند و کارهای عجیب و غریبی انجام می‌دهند که آدمی را به شگفتی وا می دارند، اما اگر همین برنامه‌ها را به بخش‌های کوچک‌تری تقسیم‌بندی کنیم، خواهیم دید که اگر برنامه نویس آن برنامه مد نظر حرفه‌ای بوده باشد و به سادگی در کدنویسی ایمان داشته باشد، بخش‌های کوچک برنامه کاملاً ساده و قابل درک هستند، هر ماژول وظیفه ی مشخصی دارد، بخش‌های مختلف مثل کلاس ها، متدها و متغیرها به خوبی نامگذاری شده‌اند به طوری که اگر سایر برنامه نویسان هم به سورس کد نگاه کنند، به راحتی متوجه وظیفه هر بخش از کد خواهند شد. به طور خلاصه، کد زیبا کدی است که ساده باشد. بخش‌های مختلف نرم‌افزار می بایست دارای روابط ساده‌ای با سایر بخش‌ها بوده و به سادگی قابل درک باشند. From fc0c7fa09bd11f0082bf4ebc513f0f51aa106524 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Thu, 18 May 2023 13:41:19 +0300 Subject: [PATCH 278/290] Updated number 6 --- fr-IR/thing_06/README.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/fr-IR/thing_06/README.md b/fr-IR/thing_06/README.md index 52a1b029..f5d756ab 100644 --- a/fr-IR/thing_06/README.md +++ b/fr-IR/thing_06/README.md @@ -1,15 +1,15 @@ # آشنایی با مفهوم ریفکتورینگ در کدنویسی -کی از چیزهایی که اکثر برنامه نویسان با آن رو به رو می‌شوند مفهومی است تحت عنوان Refactor که به معنی بازنویسی کدهایی است که پیش از این نوشته شده اند. نیاز به توضیح نیست تجربیاتی که یک برنامه نویس پس از چند سال کدنویسی کسب می‌کند قابل مقایسه با زمانی نیست که وی تازه شروع به کار کرده و مسلماً پس از چند صباحی که به کدهای خود نگاه کند، حالش از سبک کدنویسی خود به هم خواهد خورد و تصمیم می‌گیرد تا کدهای نوشته شده ی خود را اصطلاحاً Refactor کند. در این قسمت از آموزش، قصد داریم ببینیم که زمان مناسب برای بازنویسی کدهای پیشین چه موقع است و این در حالی است که اگر بدانیم چرا و چگونه این کار را انجام دهیم، در زمان ما به طرز قابل توجهی صرفه جویی خواهد شد. +یکی از چیزهایی که اکثر برنامه نویسان با آن رو به رو می‌شوند مفهومی است تحت عنوان Refactor که به معنی بازنویسی کدهایی است که پیش از این نوشته شده اند. نیاز به توضیح نیست تجربیاتی که یک برنامه نویس پس از چند سال کدنویسی کسب می‌کند قابل مقایسه با زمانی نیست که وی تازه شروع به کار کرده و مسلماً پس از چند صباحی که به کدهای خود نگاه کند، حالش از سبک کدنویسی خود به هم خواهد خورد و تصمیم می‌گیرد تا کدهای نوشته شده ی خود را اصطلاحاً Refactor کند. در این قسمت از آموزش، قصد داریم ببینیم که زمان مناسب برای بازنویسی کدهای پیشین چه موقع است و این در حالی است که اگر بدانیم چرا و چگونه این کار را انجام دهیم، در زمان ما به طرز قابل توجهی صرفه جویی خواهد شد. پیش از آن که اقدام به بازنویسی کدهای خود کنید، حتماً موارد زیر را مد نظر قرار دهید: همواره یکی از بهترین رویکردها نسبت به این که کدهای خود را بازنویسی کنیم یا نکنیم این است که کدها را با استفاده از تست هایی که برای آن‌ها می نویسیم تست کنیم چرا که با این کار به نقاط ضعف و قوت برنامه خود به خوبی پی برده و زمانی که بخواهیم کدها را Refactor کنیم، بخش‌هایی از کد که دارند به خوبی کار می‌کنند را دست کاری نخواهیم کرد اما در عین حال نقاط ضعف را برطرف خواهیم نمود. برنامه نویس ها همواره فکر می‌کنند که می‌توانند کدی بنویسند که بهتر از کد فعلی کار کند و این همان اشتباهی است که می بایست تا حد ممکن از آن اجتناب کرد. هشدار علاوه بر این، حتماً بایستی مقابل وسوسه بازنویسی هر سورس کدی ایستادگی کرد. همواره به خاطر داشته باشیم که بایستی تا حد ممکن از کدهای قبلی استفاده کنیم حتی اگر کدها تمیز نوشته نشده اند! زمانی که کدهای قبلی را پاک می کنیم، این بدان معنا است که ما ماه ها و یا سال‌ها تلاش و کدنویسی را هدر می دهیم. -در فرایند بازنویسی کد، اعمال چندین تغییر ساختاری کوچک به مراتب بهتر است از یک تغییر عمده است. به عبارت دیگر، تغییرات کوچک این امکان را به شما می‌دهند تا تأثیر آن تغییرات را روی برنامه خود راحت‌تر تست کرده و بازخورد آن‌ها را مشاهده نمایید. +در فرایند بازنویسی کد، اعمال چندین تغییر ساختاری کوچک به مراتب بهتر از یک تغییر عمده است. به عبارت دیگر، تغییرات کوچک این امکان را به شما می‌دهند تا تأثیر آن تغییرات را روی برنامه خود راحت‌تر تست کرده و بازخورد آن‌ها را مشاهده نمایید. پس از تکمیل هر ماژول -یا بهتر بگوییم هر بخش از برنامه- سورس کد ما حتماً بایستی از سد چندین تست عبور کند. به محض این که یک تغییر جدید در کد خود ایجاد می کنید، حتماً تست آن تغییرات را هم بنویسید. در‌ واقع این تست ها عملکردی همچون End User دارند که گویی دارد با برنامه ما کار می‌کند و این اطمینان را حاصل می‌کنند نرم افزاری که به دست مشتری خواهد رسید بدون باگ است. در ضمن، هرگز تست های نرم افزاری قدیمی را پاک نکنید چرا که ممکن است در ماه های گذشته ایده خاصی مد نظر شما بوده که برای تست کردن آن یک Unit Test نوشته‌اید اما اکنون که دارید به بازنویسی کدها می پردازید، فکر شما اصلاً به سمت و سوی آن ایده خاص نرفته است. سعی کنید تا حد ممکن سلایق شخصی را وارد کدنویسی نکنید. اگر بخشی از کد دارد به درستی کار می کند، اصلاً نیازی به بازنویسی آن نیست. اگر کدهایی که نوشته‌اید تمیز نیستند، این اصلاً دلیل خوبی برای بازنویسی آن‌ها نیست. اگر هم کدهای پیش روی شما از برنامه نویس دیگری به شما به ارث رسیده، احتمال این که فکر کنید کدهای شما به مراتب بهتر از برنامه نویسی قبلی خواهد بود زیاد است که این هم اصلاً دلیل موجهی نیست! -استفاده از فناوری های جدید هم اصلاً دلیل مناسبی برای Refactoring نیست. یکی از بدترین دلایلی که یک برنامه نویسی برای بازنویسی کدها می‌تواند بیاورد این است که کدهای برنامه مربوط به فناوری های چندین سال پیش هستند و در حال حاضر نسخه نرم‌افزارها و زبان‌های برنامه نویسی استفاده شده در آن برنامه به‌ خصوص خیلی ارتقاء یافته اند. در چنین مواقعی حتماً می بایست به بررسی دقیق فریم ورک یا زبان برنامه نویسی مد نظر پرداخته تا ببینیم که آیا نسخه های جدید آن واقعاً بهبود یافته‌اند یا خیر. اگر واقعاً کمکی به بهبود عملکرد، نگهداری و راندمان نرم‌افزار می‌کردند که بایستی به بازنویسی کدها پرداخت و در غیر این صورت می بایست کدها را همان‌طور که هستند رها کرد. در پایان هم همواره به خاطر داشته باشید که آدم‌ها همیشه در معرض ارتکاب خطا هستند. بازنویسی کدها اصلاً بدان معنا نیست که کدهای جدید بهتر از کدهای قبلی یا به همان خوبی کدهای قبلی خواهند بود. +استفاده از فناوری های جدید هم اصلاً دلیل مناسبی برای Refactoring نیست. یکی از بدترین دلایلی که یک برنامه نویس برای بازنویسی کدها می‌تواند بیاورد این است که کدهای برنامه مربوط به فناوری های چندین سال پیش هستند و در حال حاضر نسخه نرم‌افزارها و زبان‌های برنامه نویسی استفاده شده در آن برنامه ی به‌ خصوص خیلی ارتقاء یافته اند. در چنین مواقعی حتماً می بایست به بررسی دقیق فریم ورک یا زبان برنامه نویسی مد نظر پرداخته تا ببینیم که آیا نسخه های جدید آن واقعاً بهبود یافته‌اند یا خیر. اگر واقعاً کمکی به بهبود عملکرد، نگهداری و راندمان نرم‌افزار می‌کردند که بایستی به بازنویسی کدها پرداخت و در غیر این صورت می بایست کدها را همان‌طور که هستند رها کرد. در پایان هم همواره به خاطر داشته باشید که آدم‌ها همیشه در معرض ارتکاب خطا هستند. بازنویسی کدها اصلاً بدان معنا نیست که کدهای جدید بهتر از کدهای قبلی یا به همان خوبی کدهای قبلی کار خواهند کرد! From f9cf7035fdf1542bb05233ade106723f706f5a8c Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Thu, 18 May 2023 13:43:30 +0300 Subject: [PATCH 279/290] Updated number 7 --- fr-IR/thing_07/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fr-IR/thing_07/README.md b/fr-IR/thing_07/README.md index 3af487ea..406bce18 100644 --- a/fr-IR/thing_07/README.md +++ b/fr-IR/thing_07/README.md @@ -4,6 +4,6 @@ یک برنامه نویس خوب کسی است که وقتی کدهای یک برنامه نویس دیگر را تحویل می‌گیرد -فارغ از این که برنامه نویس قبلی چه کسی بوده- تمام تلاش خود را به کار خواهد بست تا کدها را بهبود بخشد و این در حالی است که این بهبود کار می‌تواند هم در زمینه بهبود راندمان کدها بوده و یا حتی در زمینه کامنت گذاری باشد. به نظر شما در چنین شرایطی نتیجه نهایی چه خواهد شد؟ -به نظر می‌رسد که اگر برنامه نویسان دنباله رو چنین رویکردی باشند، روز به روز کیفیت کدهایی که نوشته می‌شوند بیشتر خواهد شد تا جایی که وجود باگ در کدها به یک امر انتزاعی مبدل خواهد شد. حال ممکن است این سؤال برای شما پیش بیاید که اگر برنامه نویس قبلی به جای کدنویسی، … بود چه؟ در پاسخ به چنین سؤالی بایستی گفت که اصلاً نیاز نیست تا شما تمامی بخش‌های کد را بهبود ببخشید بلکه صرفاً نیاز است تا هر آنچه که از دست شما بر می‌آید را انجام دهید و یا حداقل کدهایی که به ماژول قبلی می افزایید را سعی کنید تمیز و مرتب بنویسید. این تمیز نویسی کدها می‌تواند به نام گذاری صحیح توابع و متغیرها، رعایت فاصله ها و … ختم گردد. +به نظر می‌رسد که اگر برنامه نویسان دنباله روی چنین رویکردی باشند، روز به روز کیفیت کدهایی که نوشته می‌شوند بیشتر خواهد شد تا جایی که وجود باگ در کدها به یک امر انتزاعی مبدل خواهد شد. حال ممکن است این سؤال برای شما پیش بیاید که اگر برنامه نویس قبلی به جای کدنویس، … بود چه؟ در پاسخ به چنین سؤالی بایستی گفت که اصلاً نیاز نیست تا شما تمامی بخش‌های کد را بهبود ببخشید بلکه صرفاً نیاز است تا هر آنچه که از دست شما بر می‌آید را انجام دهید و یا حداقل کدهایی که به ماژول قبلی می افزایید را سعی کنید تمیز و مرتب بنویسید. این تمیز نویسی کدها می‌تواند به نام گذاری صحیح توابع و متغیرها، رعایت فاصله ها و … ختم گردد. -در تیم های برنامه نویسی می بایست پس از اتخاذ رویکردی همچون آنچه در بالا به آن اشاره شد، فضایی ایجاد گردد که حتی اگر یکی از اعضای تیم خواست تا کدنویسی نامرتبی انجام دهد از سایر اعضای تیم خجالت کشیده و خود را اصلاح کند دقیقاً شبیه به شرایطی که در یک مهمانی مجلل اتفاق می افتد: آیا کسی رویش می‌شود که پس از خوردن خیار، پوست آن را روی پارکت پرتاب کند؟ هرگز. +در تیم های برنامه نویسی می بایست پس از اتخاذ رویکردی همچون آنچه در بالا به آن اشاره شد، فضایی ایجاد گردد که حتی اگر یکی از اعضای تیم خواست تا کدنویسی نامرتبی انجام دهد از سایر اعضای تیم خجالت کشیده و خود را اصلاح کند دقیقاً شبیه به شرایطی که در یک مهمانی مجلل اتفاق می افتد: آیا کسی رویش می‌شود که پس از خوردن خیار، پوست آن را روی پارکت پرتاب کند؟ هرگز! From 9e4f7682e83cce2b1dc40e0a5fd74c33379b498f Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Thu, 18 May 2023 13:47:49 +0300 Subject: [PATCH 280/290] Update number 12 --- fr-IR/thing_12/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fr-IR/thing_12/README.md b/fr-IR/thing_12/README.md index eac01afe..704208ff 100644 --- a/fr-IR/thing_12/README.md +++ b/fr-IR/thing_12/README.md @@ -5,7 +5,7 @@ پویش کدها را ساده تر کنید: فرض کنید تیم شما برنامه ای نوشته است که چندین کلاس مختلف دارد. در هنگام اجرای کلاس های برنامه، برای کامپایلر تفاوتی ندارد که در بدنه ی کلاس ابتدا عناصر public تعریف شده اند یا عناصر private، یا این که ابتدا ثابت ها تعریف شوند یا فیلدها و یا متد ها؛ به عبارت دیگر، ترتیب قرار گرفتن اجزای یک کلاس برای کامپایلر تفاوتی ندارد، اما برای شما چه طور؟ -باید بدانید که افراد غالباً در تطبیق الگوهای بصری خوب هستند، بنابراین یکی از رویکردهایی که می توانید با دنبال کردن آن، مرور کدهای خود را آسان تر کنید این است که الگویی برای قرار دادن عناصر برنامه در کدهای خود تعریف کنید و تمام اعضای تیم در زمان کدنویسی بخش های مختلف برنامه از آن الگو پیروی کنند. به عنوان نمونه، می‌توان زبان برنامه نویسی پی اچ پی را مثال زد. سایتی تحت عنوان php-fig.org استانداردی تحت عنوان PSR که مخفف واژگان PHP Standard Recommendation است را برای برنامه نویسان پی اچ پی طراحی کرده که علاقمندان با استفاده از این استانداردها می توانند از کدهایی برخوردار شوند که سایر برنامه نویسان پی اچ پی با نگاه کردن به کدهای ایشان کمتر دچار سردرگمی شوند (لازم به ذکر است که در کدنویسی سکان آکادمی نیز از این استاندارد استفاده شده است.) +باید بدانید که افراد غالباً در تطبیق الگوهای بصری خوب هستند، بنابراین یکی از رویکردهایی که می توانید با دنبال کردن آن، مرور کدهای خود را آسان تر کنید این است که الگویی برای قرار دادن عناصر برنامه در کدهای خود تعریف کنید و تمام اعضای تیم در زمان کدنویسی بخش های مختلف برنامه از آن الگو پیروی کنند. به عنوان نمونه، می‌توان زبان برنامه نویسی پی اچ پی را مثال زد. سایتی تحت عنوان php-fig.org استانداردی تحت عنوان PSR که مخفف واژگان PHP Standard Recommendation است را برای برنامه نویسان پی اچ پی طراحی کرده که علاقمندان با استفاده از این استانداردها می توانند از کدهایی برخوردار شوند که سایر برنامه نویسان پی اچ پی با نگاه کردن به کدهای ایشان کمتر دچار سردرگمی شوند برای روشن تر شدن این مسئله، از سایر زبان های برنامه نویسی هم چند مثال می زنیم. اکثر برنامه نویسان ++C ابتدا تعریف متدهای public را در بدنه ی کدهای خود قرار می دهند و در زیر آن ها متدهای private را، در حالی که این رویه در کدنویسی به زبان #C کاملاً برعکس است. البته توجه کنید که ما این الگوها را به طور تجربی در زمان یادگیری هر زبان از منابع آموزش دهنده دریافت کرده و ناخواسته از آن ها تبعیت می کنیم و پیروی از آن ها باعث می شود سایر برنامه نویسان هم به راحتی کدهای ما را بخوانند، با این حال شما می توانید استاندارد مخصوصی برای خود تعریف کنید تا تمام اعضای تیم از آن تبعیت کنند. From d8f8a2a27aef738783fd88239da92510101f904c Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Thu, 18 May 2023 13:50:35 +0300 Subject: [PATCH 281/290] Updated number 14 --- fr-IR/thing_14/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fr-IR/thing_14/README.md b/fr-IR/thing_14/README.md index 2799845b..8ec24321 100644 --- a/fr-IR/thing_14/README.md +++ b/fr-IR/thing_14/README.md @@ -5,7 +5,7 @@ بیش تر زبان های برنامه نویسی جدید سطح بالا، ابزارهایی در خود دارند که به خوبی می توانند یک برنامه را مستند سازی کنند. اگرچه استفاده از آن ها یک شروع خوب برای شفاف کردن هدف برنامه است با این وجود قطعاً تمام نیازهای برنامه نویس را رفع نخواهند کرد. مستندسازی باید در سراسر خطوط نوشته شده انجام گیرد تا به وضوح نشان دهد هر قطعه کد چه کاری را انجام خواهد داد. برای آن که بتوانیم توضیحات مناسب را در برنامه ی خود بگنجانیم، باید با شیوه های استاندارد درج کامنت که مشخص می کنند آن ها باید در کدام قسمت از بدنه ی کدها قرار داده شوند و چه اطلاعاتی را در بر داشته باشند آشنا باشیم که در این جا به بعضی از این استایل های استاندارد اشاره می کنیم: توضیحات سرآمد یا Header Comments: -هر برنامه باید با یک توضیح آغازین همراه باشد که به آن "توضیحات سرآمد" می گوییم. این توضیحات باید حاوی اطلاعاتی از این قبیل باشند: نام برنامه نویس، تاریخ، نام فایلی که برنامه در آن ذخیره می شود، توضیحی در مورد برنامه و نحوه ی اجرا و استفاده از آن. یکی از بهترین استراتژی ها برای نوشتن برنامه های بزرگ و پیچیده تقسیم کردن کدهای آن در مجموعه فایل های جداگانه ای به نام ماژول است که این کار بررسی و توسعه ی کدها را راحت تر می کند (به طور مثال، سکان آکادمی از ماژول های Application, Tutorial, Blog, Wiki, Jobs, Forum و ... تشکیل شده است.) در این صورت هر فایل نیاز به توضیحات سرآمد دارد که شامل این اطلاعات می شود: نام برنامه نویس، تاریخ، نام فایلی که کدها در آن ذخیره می شوند. هم چنین در این توضیحات باید نام فایل های دیگری که کدهای ماژول کنونی به آن ها وابسته هستند، مثلاً کلاسی را از فایل دیگری به ارث می برند را هم بیاورید. +هر برنامه باید با یک توضیح آغازین همراه باشد که به آن "توضیحات سرآمد" می گوییم. این توضیحات باید حاوی اطلاعاتی از این قبیل باشند: نام برنامه نویس، تاریخ، نام فایلی که برنامه در آن ذخیره می شود، توضیحی در مورد برنامه و نحوه ی اجرا و استفاده از آن. یکی از بهترین استراتژی ها برای نوشتن برنامه های بزرگ و پیچیده تقسیم کردن کدهای آن در مجموعه فایل های جداگانه ای به نام ماژول است که این کار بررسی و توسعه ی کدها را راحت تر می کند (به طور مثال، یک وبسایت میتواند از ماژول های Application, Tutorial, Blog, Wiki, Jobs, Forum و ... تشکیل شده باشد.) در این صورت هر فایل نیاز به توضیحات سرآمد دارد که شامل این اطلاعات می شود: نام برنامه نویس، تاریخ، نام فایلی که کدها در آن ذخیره می شوند. هم چنین در این توضیحات باید نام فایل های دیگری که کدهای ماژول کنونی به آن ها وابسته هستند، مثلاً کلاسی را از فایل دیگری به ارث می برند را هم بیاورید. توضیحات مربوط به توابع: هر کلاس پیچیده به بخش های کوچک تری تقسیم می شود که به آن ها توابع می گویند و هر تابع مسئول انجام یک وظیفه ی خاص در برنامه است. پیش از معرفی هر تابع، توضیحاتی مربوط به آن نوشته می شود که اطلاعاتی از این قبیل را شامل می شود: تابع قرار است چه کاری را در برنامه انجام دهد، چه ورودی هایی لازم است که به تابع داده شود تا عملیات خود را اجرا کند، و این که تابع در نهایت چه تغییراتی را ایجاد می کند و خروجی آن چه خواهد بود یا اصطلاحاً این تابع چه چیزی را return می کند یا برمی گرداند. From 9cbfbb1a9103b8fd0581b6e4b8df8bd773632b75 Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Thu, 18 May 2023 13:51:20 +0300 Subject: [PATCH 282/290] Updated number 17 --- fr-IR/thing_17/README.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/fr-IR/thing_17/README.md b/fr-IR/thing_17/README.md index ee5e77dc..76141192 100644 --- a/fr-IR/thing_17/README.md +++ b/fr-IR/thing_17/README.md @@ -8,8 +8,7 @@ در این جا قصد داریم بعضی از روش های کاربردی و منابع مفید را به شما معرفی کنیم تا بتوانید با استفاده از آن ها سطح دانش و مهارت خود را به عنوان یک برنامه نویس افزایش دهید. لیست این پیشنهادات به قرار زیر است: -1- کتاب و مجله بخوانید، از پست های وبلاگی، سایت ها، و فیدهای توئیتر که اخبار و موضوعات جدید حوزه ی نرم افزار و آی تی را بررسی می کنند بازدید کنید. سعی کنید پیوسته با جامعه ای از برنامه نویسان در ارتباط باشید. برای مثال طرح موضوعات جدید علمی در تالار گفتگوی سکان آکادمی و بحث و گفتگو با سایر برنامه نویسان در چنین محیط های مجازی می تواند سطح دانش عمومی را بالا ببرد. - +1- کتاب و مجله بخوانید، از پست های وبلاگی، سایت ها، و فیدهای توئیتر که اخبار و موضوعات جدید حوزه ی نرم افزار و آی تی را بررسی می کنند بازدید کنید. سعی کنید پیوسته با جامعه ای از برنامه نویسان در ارتباط باشید. 2- اگر واقعاً می خواهید با یک تکنولوژی جدید آشنا شوید، دست خود را به آن آلوده کنید! شروع به کدنویسی کنید. تلاش کنید با امتحان کردن نرم افزارهای جدید به آن ها مسلط شوید. 3- سعی کنید همیشه با کسانی کار کنید که چیزی بیش تر از شما بدانند، چون کار کردن در کنار افراد با هوش تر و با تجربه تر و نظارت آن ها بر کار شما هم انگیزه ی یادگیری را در شما ایجاد می کند و هم در تعامل با آن ها می توانید درس های زیادی بیاموزید و اطلاعات مفیدی به دست آورید. وقتی شما تنها در کنار افرادی باشید که سطحی پایین تر از شما دارند، هم انگیزه ی رقابتی خود را برای یادگیری از دست می دهید و هم این که احتمالاً تمام وقت خود را باید صرف آموزش به آن ها کنید که به نوعی مانع یادگیری موضوعات جدید خواهد بود. From 53a7a87d2805f06f18d0e7a3167a569e078dc63b Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Thu, 18 May 2023 13:51:59 +0300 Subject: [PATCH 283/290] Updated number 21 --- fr-IR/thing_21/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fr-IR/thing_21/README.md b/fr-IR/thing_21/README.md index 6bda166f..0e6e41ce 100644 --- a/fr-IR/thing_21/README.md +++ b/fr-IR/thing_21/README.md @@ -1,6 +1,6 @@ # تمرین آگاهانه، لازمهٔ حرفه‌ای شدن است! -فرض کنید شما در یک کلاس برنامه نویسی شرکت کرده اید، یا یک دوره ی برنامه نویسی، مانند دوره های آنلاین برنامه نویسی در سکان آکادمی را گذرانده اید. مطمئناً در این دوره ها با مفاهیم زیادی مثل استفاده از شرط ها و حلقه ها، اصول شیء گرایی، مدیریت اکسپشن ها و بسیاری موارد پایه ای دیگر آشنا شده اید. به علاوه در هر کدام از این دوره ها با جزئیات عملی زیادی مثل این که در زبان پایتون برای بلوک بندی قطعه کدها به جای کروشه از تورفتگی استفاده می کنیم، یا این که زبان جاوا نسبت به حالت حروف حساس است آشنا شده اید. +فرض کنید شما در یک کلاس برنامه نویسی شرکت کرده اید، یا یک دوره ی برنامه نویسی را گذرانده اید. مطمئناً در این دوره ها با مفاهیم زیادی مثل استفاده از شرط ها و حلقه ها، اصول شیء گرایی، مدیریت اکسپشن ها و بسیاری موارد پایه ای دیگر آشنا شده اید. به علاوه در هر کدام از این دوره ها با جزئیات عملی زیادی مثل این که در زبان پایتون برای بلوک بندی قطعه کدها به جای کروشه از تورفتگی استفاده می کنیم، یا این که زبان جاوا نسبت به حالت حروف حساس است آشنا شده اید. با وجود آشنایی با تمام این مفاهیم و جزئیات عملی ممکن است شما باز هم نتوانید یک اپلیکیشن خوب توسعه دهید. دلیل این موضوع این است که دانش مفاهیم نظری پایه ی کار برای شروع برنامه نویسی است، با این حال تنها تمرین کردن و تمرین کردن و تمرین کردن در کدنویسی و کسب مهارت است که از شما یک برنامه نویس حرفه ای می سازد. From a265a45392b905d105c5f10f54ea3373895975fb Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Thu, 18 May 2023 13:52:53 +0300 Subject: [PATCH 284/290] Updated number 31 --- fr-IR/thing_31/README.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fr-IR/thing_31/README.md b/fr-IR/thing_31/README.md index 2264b99e..fdeb52de 100644 --- a/fr-IR/thing_31/README.md +++ b/fr-IR/thing_31/README.md @@ -10,7 +10,8 @@ مفهوم Staging: این مرحله از توسعه ی نرم‌افزار که تحت عنوان Integration هم شناخته می شود، مرحله یی است که سایت یا اپلیکیشن در محیطی کاملاً شبیه به محیط Production تست می‌شود و Quality Assurance به معنی «تضمین کیفیت» که به طور خلاصه QA نامیده می‌شود نیز روی آن اعمال می گردد. کانفیگ سروری که برای این مرحله از کار استفاده می شود کاملاً مشابه سرور اصلی است. تیم های توسعه ی نرم‌افزار حرفه یی برای اپلیکیشن هایی که هزاران کاربر دارند را پیش از فرستادن روی سرور اصلی، حتماً روی Staging Server تست می کنند. -مفهوم Production: این محیط که اصطلاحاً محیط Live نامیده می شود، همان سروری است که نرم‌افزار -مثلا وب سایت- روی آن پیاده‌سازی شده و کاربران نهایی می‌توانند از آن استفاده کنند و آخرین مرحله از فرایند توسعه ی نرم‌افزار است (سروری که هم اکنون سکان آکادمی روی آن پیاده سازی شده و شما قادرید این آموزش را مطالعه فرمایید یک محیط Production است.) اپلیکیشن پس از تست و اطمینال حاصل کردن از درست بودن همه چیز و Bug-free بودن آن، روی سرور Production فرستاده می شود. +مفهوم Production: این محیط که اصطلاحاً محیط Live نامیده می شود، همان سروری است که نرم‌افزار -مثلا وب سایت- روی آن پیاده‌سازی شده و کاربران نهایی می‌توانند از آن استفاده کنند و آخرین مرحله از فرایند توسعه ی نرم‌افزار است. +اپلیکیشن پس از تست و اطمینال حاصل کردن از درست بودن همه چیز و Bug-free بودن آن، روی سرور Production فرستاده می شود. نکته توجه داشته باشید که آپدیت کردن اپلیکیشن در مرحله ی Production باید در زمانی صورت گیرد که حداقل تعداد کاربران در حال استفاده از اپلیکیشن -مثلا وب سایت- باشند (مثلا ساعت ۳ نیمه شب). علاوه بر این، زمانی که آخرین تغییرات روی سرور Live اعمال می شوند، باید تمامی اعضای تیم از این قضیه مطلع باشند تا در صورت بروز هرگونه مشکلی، خیلی سریع بتوان آن را مرتفع ساخت. From 4672f6fca4090963ac3067f22b1ce4c63398ed3b Mon Sep 17 00:00:00 2001 From: Ali Dehbansiahkarbon Date: Thu, 18 May 2023 16:31:01 +0300 Subject: [PATCH 285/290] Added fa which is stands for Farsi(Persian) --- LANGS.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/LANGS.md b/LANGS.md index 39848c4c..a57c777f 100644 --- a/LANGS.md +++ b/LANGS.md @@ -1,3 +1,4 @@ * [English](en) * [русский язык](ru) -* [Türkçe](tr) \ No newline at end of file +* [Türkçe](tr) +* [Persian(فارسی)](fa) From d6941c6627b724fcfb2732b2f20970c690d4605a Mon Sep 17 00:00:00 2001 From: AliDehbansiahkarbon Date: Thu, 18 May 2023 16:32:21 +0300 Subject: [PATCH 286/290] Changed the directory name based on ISO 639-1 language codes. --- {fr-IR => fa}/README.md | 0 {fr-IR => fa}/SUMMARY.md | 0 {fr-IR => fa}/thing_01/README.md | 0 {fr-IR => fa}/thing_02/README.md | 0 {fr-IR => fa}/thing_03/README.md | 0 {fr-IR => fa}/thing_04/README.md | 0 {fr-IR => fa}/thing_05/README.md | 0 {fr-IR => fa}/thing_06/README.md | 0 {fr-IR => fa}/thing_07/README.md | 0 {fr-IR => fa}/thing_08/README.md | 0 {fr-IR => fa}/thing_09/README.md | 0 {fr-IR => fa}/thing_10/README.md | 0 {fr-IR => fa}/thing_11/README.md | 0 {fr-IR => fa}/thing_12/README.md | 0 {fr-IR => fa}/thing_13/README.md | 0 {fr-IR => fa}/thing_14/README.md | 0 {fr-IR => fa}/thing_15/README.md | 0 {fr-IR => fa}/thing_16/README.md | 0 {fr-IR => fa}/thing_17/README.md | 0 {fr-IR => fa}/thing_18/README.md | 0 {fr-IR => fa}/thing_19/README.md | 0 {fr-IR => fa}/thing_20/README.md | 0 {fr-IR => fa}/thing_21/README.md | 0 {fr-IR => fa}/thing_22/README.md | 0 {fr-IR => fa}/thing_23/README.md | 0 {fr-IR => fa}/thing_24/README.md | 0 {fr-IR => fa}/thing_25/README.md | 0 {fr-IR => fa}/thing_26/README.md | 0 {fr-IR => fa}/thing_27/README.md | 0 {fr-IR => fa}/thing_28/README.md | 0 {fr-IR => fa}/thing_29/README.md | 0 {fr-IR => fa}/thing_30/README.md | 0 {fr-IR => fa}/thing_31/README.md | 0 {fr-IR => fa}/thing_32/README.md | 0 {fr-IR => fa}/thing_33/README.md | 0 {fr-IR => fa}/thing_34/README.md | 0 {fr-IR => fa}/thing_35/README.md | 0 {fr-IR => fa}/thing_36/README.md | 0 {fr-IR => fa}/thing_37/README.md | 0 {fr-IR => fa}/thing_38/README.md | 0 {fr-IR => fa}/thing_39/README.md | 0 {fr-IR => fa}/thing_40/README.md | 0 {fr-IR => fa}/thing_41/README.md | 0 {fr-IR => fa}/thing_42/README.md | 0 {fr-IR => fa}/thing_43/README.md | 0 {fr-IR => fa}/thing_44/README.md | 0 {fr-IR => fa}/thing_45/README.md | 0 {fr-IR => fa}/thing_46/README.md | 0 {fr-IR => fa}/thing_47/README.md | 0 {fr-IR => fa}/thing_48/README.md | 0 {fr-IR => fa}/thing_49/README.md | 0 {fr-IR => fa}/thing_50/README.md | 0 {fr-IR => fa}/thing_51/README.md | 0 {fr-IR => fa}/thing_52/README.md | 0 {fr-IR => fa}/thing_53/README.md | 0 {fr-IR => fa}/thing_54/README.md | 0 {fr-IR => fa}/thing_55/README.md | 0 {fr-IR => fa}/thing_56/README.md | 0 {fr-IR => fa}/thing_57/README.md | 0 {fr-IR => fa}/thing_58/README.md | 0 {fr-IR => fa}/thing_59/README.md | 0 {fr-IR => fa}/thing_60/README.md | 0 {fr-IR => fa}/thing_61/README.md | 0 {fr-IR => fa}/thing_62/README.md | 0 {fr-IR => fa}/thing_63/README.md | 0 {fr-IR => fa}/thing_64/README.md | 0 {fr-IR => fa}/thing_65/README.md | 0 {fr-IR => fa}/thing_66/README.md | 0 {fr-IR => fa}/thing_67/README.md | 0 {fr-IR => fa}/thing_68/README.md | 0 {fr-IR => fa}/thing_69/README.md | 0 {fr-IR => fa}/thing_70/README.md | 0 {fr-IR => fa}/thing_71/README.md | 0 {fr-IR => fa}/thing_72/README.md | 0 {fr-IR => fa}/thing_73/README.md | 0 {fr-IR => fa}/thing_74/README.md | 0 {fr-IR => fa}/thing_75/README.md | 0 {fr-IR => fa}/thing_76/README.md | 0 {fr-IR => fa}/thing_77/README.md | 0 {fr-IR => fa}/thing_78/README.md | 0 {fr-IR => fa}/thing_79/README.md | 0 {fr-IR => fa}/thing_80/README.md | 0 {fr-IR => fa}/thing_81/README.md | 0 {fr-IR => fa}/thing_82/README.md | 0 {fr-IR => fa}/thing_83/README.md | 0 {fr-IR => fa}/thing_84/README.md | 0 {fr-IR => fa}/thing_85/README.md | 0 {fr-IR => fa}/thing_86/README.md | 0 {fr-IR => fa}/thing_87/README.md | 0 {fr-IR => fa}/thing_88/README.md | 0 {fr-IR => fa}/thing_89/README.md | 0 {fr-IR => fa}/thing_90/README.md | 0 {fr-IR => fa}/thing_91/README.md | 0 {fr-IR => fa}/thing_92/README.md | 0 {fr-IR => fa}/thing_93/README.md | 0 {fr-IR => fa}/thing_94/README.md | 0 {fr-IR => fa}/thing_95/README.md | 0 {fr-IR => fa}/thing_96/README.md | 0 {fr-IR => fa}/thing_97/README.md | 0 99 files changed, 0 insertions(+), 0 deletions(-) rename {fr-IR => fa}/README.md (100%) rename {fr-IR => fa}/SUMMARY.md (100%) rename {fr-IR => fa}/thing_01/README.md (100%) rename {fr-IR => fa}/thing_02/README.md (100%) rename {fr-IR => fa}/thing_03/README.md (100%) rename {fr-IR => fa}/thing_04/README.md (100%) rename {fr-IR => fa}/thing_05/README.md (100%) rename {fr-IR => fa}/thing_06/README.md (100%) rename {fr-IR => fa}/thing_07/README.md (100%) rename {fr-IR => fa}/thing_08/README.md (100%) rename {fr-IR => fa}/thing_09/README.md (100%) rename {fr-IR => fa}/thing_10/README.md (100%) rename {fr-IR => fa}/thing_11/README.md (100%) rename {fr-IR => fa}/thing_12/README.md (100%) rename {fr-IR => fa}/thing_13/README.md (100%) rename {fr-IR => fa}/thing_14/README.md (100%) rename {fr-IR => fa}/thing_15/README.md (100%) rename {fr-IR => fa}/thing_16/README.md (100%) rename {fr-IR => fa}/thing_17/README.md (100%) rename {fr-IR => fa}/thing_18/README.md (100%) rename {fr-IR => fa}/thing_19/README.md (100%) rename {fr-IR => fa}/thing_20/README.md (100%) rename {fr-IR => fa}/thing_21/README.md (100%) rename {fr-IR => fa}/thing_22/README.md (100%) rename {fr-IR => fa}/thing_23/README.md (100%) rename {fr-IR => fa}/thing_24/README.md (100%) rename {fr-IR => fa}/thing_25/README.md (100%) rename {fr-IR => fa}/thing_26/README.md (100%) rename {fr-IR => fa}/thing_27/README.md (100%) rename {fr-IR => fa}/thing_28/README.md (100%) rename {fr-IR => fa}/thing_29/README.md (100%) rename {fr-IR => fa}/thing_30/README.md (100%) rename {fr-IR => fa}/thing_31/README.md (100%) rename {fr-IR => fa}/thing_32/README.md (100%) rename {fr-IR => fa}/thing_33/README.md (100%) rename {fr-IR => fa}/thing_34/README.md (100%) rename {fr-IR => fa}/thing_35/README.md (100%) rename {fr-IR => fa}/thing_36/README.md (100%) rename {fr-IR => fa}/thing_37/README.md (100%) rename {fr-IR => fa}/thing_38/README.md (100%) rename {fr-IR => fa}/thing_39/README.md (100%) rename {fr-IR => fa}/thing_40/README.md (100%) rename {fr-IR => fa}/thing_41/README.md (100%) rename {fr-IR => fa}/thing_42/README.md (100%) rename {fr-IR => fa}/thing_43/README.md (100%) rename {fr-IR => fa}/thing_44/README.md (100%) rename {fr-IR => fa}/thing_45/README.md (100%) rename {fr-IR => fa}/thing_46/README.md (100%) rename {fr-IR => fa}/thing_47/README.md (100%) rename {fr-IR => fa}/thing_48/README.md (100%) rename {fr-IR => fa}/thing_49/README.md (100%) rename {fr-IR => fa}/thing_50/README.md (100%) rename {fr-IR => fa}/thing_51/README.md (100%) rename {fr-IR => fa}/thing_52/README.md (100%) rename {fr-IR => fa}/thing_53/README.md (100%) rename {fr-IR => fa}/thing_54/README.md (100%) rename {fr-IR => fa}/thing_55/README.md (100%) rename {fr-IR => fa}/thing_56/README.md (100%) rename {fr-IR => fa}/thing_57/README.md (100%) rename {fr-IR => fa}/thing_58/README.md (100%) rename {fr-IR => fa}/thing_59/README.md (100%) rename {fr-IR => fa}/thing_60/README.md (100%) rename {fr-IR => fa}/thing_61/README.md (100%) rename {fr-IR => fa}/thing_62/README.md (100%) rename {fr-IR => fa}/thing_63/README.md (100%) rename {fr-IR => fa}/thing_64/README.md (100%) rename {fr-IR => fa}/thing_65/README.md (100%) rename {fr-IR => fa}/thing_66/README.md (100%) rename {fr-IR => fa}/thing_67/README.md (100%) rename {fr-IR => fa}/thing_68/README.md (100%) rename {fr-IR => fa}/thing_69/README.md (100%) rename {fr-IR => fa}/thing_70/README.md (100%) rename {fr-IR => fa}/thing_71/README.md (100%) rename {fr-IR => fa}/thing_72/README.md (100%) rename {fr-IR => fa}/thing_73/README.md (100%) rename {fr-IR => fa}/thing_74/README.md (100%) rename {fr-IR => fa}/thing_75/README.md (100%) rename {fr-IR => fa}/thing_76/README.md (100%) rename {fr-IR => fa}/thing_77/README.md (100%) rename {fr-IR => fa}/thing_78/README.md (100%) rename {fr-IR => fa}/thing_79/README.md (100%) rename {fr-IR => fa}/thing_80/README.md (100%) rename {fr-IR => fa}/thing_81/README.md (100%) rename {fr-IR => fa}/thing_82/README.md (100%) rename {fr-IR => fa}/thing_83/README.md (100%) rename {fr-IR => fa}/thing_84/README.md (100%) rename {fr-IR => fa}/thing_85/README.md (100%) rename {fr-IR => fa}/thing_86/README.md (100%) rename {fr-IR => fa}/thing_87/README.md (100%) rename {fr-IR => fa}/thing_88/README.md (100%) rename {fr-IR => fa}/thing_89/README.md (100%) rename {fr-IR => fa}/thing_90/README.md (100%) rename {fr-IR => fa}/thing_91/README.md (100%) rename {fr-IR => fa}/thing_92/README.md (100%) rename {fr-IR => fa}/thing_93/README.md (100%) rename {fr-IR => fa}/thing_94/README.md (100%) rename {fr-IR => fa}/thing_95/README.md (100%) rename {fr-IR => fa}/thing_96/README.md (100%) rename {fr-IR => fa}/thing_97/README.md (100%) diff --git a/fr-IR/README.md b/fa/README.md similarity index 100% rename from fr-IR/README.md rename to fa/README.md diff --git a/fr-IR/SUMMARY.md b/fa/SUMMARY.md similarity index 100% rename from fr-IR/SUMMARY.md rename to fa/SUMMARY.md diff --git a/fr-IR/thing_01/README.md b/fa/thing_01/README.md similarity index 100% rename from fr-IR/thing_01/README.md rename to fa/thing_01/README.md diff --git a/fr-IR/thing_02/README.md b/fa/thing_02/README.md similarity index 100% rename from fr-IR/thing_02/README.md rename to fa/thing_02/README.md diff --git a/fr-IR/thing_03/README.md b/fa/thing_03/README.md similarity index 100% rename from fr-IR/thing_03/README.md rename to fa/thing_03/README.md diff --git a/fr-IR/thing_04/README.md b/fa/thing_04/README.md similarity index 100% rename from fr-IR/thing_04/README.md rename to fa/thing_04/README.md diff --git a/fr-IR/thing_05/README.md b/fa/thing_05/README.md similarity index 100% rename from fr-IR/thing_05/README.md rename to fa/thing_05/README.md diff --git a/fr-IR/thing_06/README.md b/fa/thing_06/README.md similarity index 100% rename from fr-IR/thing_06/README.md rename to fa/thing_06/README.md diff --git a/fr-IR/thing_07/README.md b/fa/thing_07/README.md similarity index 100% rename from fr-IR/thing_07/README.md rename to fa/thing_07/README.md diff --git a/fr-IR/thing_08/README.md b/fa/thing_08/README.md similarity index 100% rename from fr-IR/thing_08/README.md rename to fa/thing_08/README.md diff --git a/fr-IR/thing_09/README.md b/fa/thing_09/README.md similarity index 100% rename from fr-IR/thing_09/README.md rename to fa/thing_09/README.md diff --git a/fr-IR/thing_10/README.md b/fa/thing_10/README.md similarity index 100% rename from fr-IR/thing_10/README.md rename to fa/thing_10/README.md diff --git a/fr-IR/thing_11/README.md b/fa/thing_11/README.md similarity index 100% rename from fr-IR/thing_11/README.md rename to fa/thing_11/README.md diff --git a/fr-IR/thing_12/README.md b/fa/thing_12/README.md similarity index 100% rename from fr-IR/thing_12/README.md rename to fa/thing_12/README.md diff --git a/fr-IR/thing_13/README.md b/fa/thing_13/README.md similarity index 100% rename from fr-IR/thing_13/README.md rename to fa/thing_13/README.md diff --git a/fr-IR/thing_14/README.md b/fa/thing_14/README.md similarity index 100% rename from fr-IR/thing_14/README.md rename to fa/thing_14/README.md diff --git a/fr-IR/thing_15/README.md b/fa/thing_15/README.md similarity index 100% rename from fr-IR/thing_15/README.md rename to fa/thing_15/README.md diff --git a/fr-IR/thing_16/README.md b/fa/thing_16/README.md similarity index 100% rename from fr-IR/thing_16/README.md rename to fa/thing_16/README.md diff --git a/fr-IR/thing_17/README.md b/fa/thing_17/README.md similarity index 100% rename from fr-IR/thing_17/README.md rename to fa/thing_17/README.md diff --git a/fr-IR/thing_18/README.md b/fa/thing_18/README.md similarity index 100% rename from fr-IR/thing_18/README.md rename to fa/thing_18/README.md diff --git a/fr-IR/thing_19/README.md b/fa/thing_19/README.md similarity index 100% rename from fr-IR/thing_19/README.md rename to fa/thing_19/README.md diff --git a/fr-IR/thing_20/README.md b/fa/thing_20/README.md similarity index 100% rename from fr-IR/thing_20/README.md rename to fa/thing_20/README.md diff --git a/fr-IR/thing_21/README.md b/fa/thing_21/README.md similarity index 100% rename from fr-IR/thing_21/README.md rename to fa/thing_21/README.md diff --git a/fr-IR/thing_22/README.md b/fa/thing_22/README.md similarity index 100% rename from fr-IR/thing_22/README.md rename to fa/thing_22/README.md diff --git a/fr-IR/thing_23/README.md b/fa/thing_23/README.md similarity index 100% rename from fr-IR/thing_23/README.md rename to fa/thing_23/README.md diff --git a/fr-IR/thing_24/README.md b/fa/thing_24/README.md similarity index 100% rename from fr-IR/thing_24/README.md rename to fa/thing_24/README.md diff --git a/fr-IR/thing_25/README.md b/fa/thing_25/README.md similarity index 100% rename from fr-IR/thing_25/README.md rename to fa/thing_25/README.md diff --git a/fr-IR/thing_26/README.md b/fa/thing_26/README.md similarity index 100% rename from fr-IR/thing_26/README.md rename to fa/thing_26/README.md diff --git a/fr-IR/thing_27/README.md b/fa/thing_27/README.md similarity index 100% rename from fr-IR/thing_27/README.md rename to fa/thing_27/README.md diff --git a/fr-IR/thing_28/README.md b/fa/thing_28/README.md similarity index 100% rename from fr-IR/thing_28/README.md rename to fa/thing_28/README.md diff --git a/fr-IR/thing_29/README.md b/fa/thing_29/README.md similarity index 100% rename from fr-IR/thing_29/README.md rename to fa/thing_29/README.md diff --git a/fr-IR/thing_30/README.md b/fa/thing_30/README.md similarity index 100% rename from fr-IR/thing_30/README.md rename to fa/thing_30/README.md diff --git a/fr-IR/thing_31/README.md b/fa/thing_31/README.md similarity index 100% rename from fr-IR/thing_31/README.md rename to fa/thing_31/README.md diff --git a/fr-IR/thing_32/README.md b/fa/thing_32/README.md similarity index 100% rename from fr-IR/thing_32/README.md rename to fa/thing_32/README.md diff --git a/fr-IR/thing_33/README.md b/fa/thing_33/README.md similarity index 100% rename from fr-IR/thing_33/README.md rename to fa/thing_33/README.md diff --git a/fr-IR/thing_34/README.md b/fa/thing_34/README.md similarity index 100% rename from fr-IR/thing_34/README.md rename to fa/thing_34/README.md diff --git a/fr-IR/thing_35/README.md b/fa/thing_35/README.md similarity index 100% rename from fr-IR/thing_35/README.md rename to fa/thing_35/README.md diff --git a/fr-IR/thing_36/README.md b/fa/thing_36/README.md similarity index 100% rename from fr-IR/thing_36/README.md rename to fa/thing_36/README.md diff --git a/fr-IR/thing_37/README.md b/fa/thing_37/README.md similarity index 100% rename from fr-IR/thing_37/README.md rename to fa/thing_37/README.md diff --git a/fr-IR/thing_38/README.md b/fa/thing_38/README.md similarity index 100% rename from fr-IR/thing_38/README.md rename to fa/thing_38/README.md diff --git a/fr-IR/thing_39/README.md b/fa/thing_39/README.md similarity index 100% rename from fr-IR/thing_39/README.md rename to fa/thing_39/README.md diff --git a/fr-IR/thing_40/README.md b/fa/thing_40/README.md similarity index 100% rename from fr-IR/thing_40/README.md rename to fa/thing_40/README.md diff --git a/fr-IR/thing_41/README.md b/fa/thing_41/README.md similarity index 100% rename from fr-IR/thing_41/README.md rename to fa/thing_41/README.md diff --git a/fr-IR/thing_42/README.md b/fa/thing_42/README.md similarity index 100% rename from fr-IR/thing_42/README.md rename to fa/thing_42/README.md diff --git a/fr-IR/thing_43/README.md b/fa/thing_43/README.md similarity index 100% rename from fr-IR/thing_43/README.md rename to fa/thing_43/README.md diff --git a/fr-IR/thing_44/README.md b/fa/thing_44/README.md similarity index 100% rename from fr-IR/thing_44/README.md rename to fa/thing_44/README.md diff --git a/fr-IR/thing_45/README.md b/fa/thing_45/README.md similarity index 100% rename from fr-IR/thing_45/README.md rename to fa/thing_45/README.md diff --git a/fr-IR/thing_46/README.md b/fa/thing_46/README.md similarity index 100% rename from fr-IR/thing_46/README.md rename to fa/thing_46/README.md diff --git a/fr-IR/thing_47/README.md b/fa/thing_47/README.md similarity index 100% rename from fr-IR/thing_47/README.md rename to fa/thing_47/README.md diff --git a/fr-IR/thing_48/README.md b/fa/thing_48/README.md similarity index 100% rename from fr-IR/thing_48/README.md rename to fa/thing_48/README.md diff --git a/fr-IR/thing_49/README.md b/fa/thing_49/README.md similarity index 100% rename from fr-IR/thing_49/README.md rename to fa/thing_49/README.md diff --git a/fr-IR/thing_50/README.md b/fa/thing_50/README.md similarity index 100% rename from fr-IR/thing_50/README.md rename to fa/thing_50/README.md diff --git a/fr-IR/thing_51/README.md b/fa/thing_51/README.md similarity index 100% rename from fr-IR/thing_51/README.md rename to fa/thing_51/README.md diff --git a/fr-IR/thing_52/README.md b/fa/thing_52/README.md similarity index 100% rename from fr-IR/thing_52/README.md rename to fa/thing_52/README.md diff --git a/fr-IR/thing_53/README.md b/fa/thing_53/README.md similarity index 100% rename from fr-IR/thing_53/README.md rename to fa/thing_53/README.md diff --git a/fr-IR/thing_54/README.md b/fa/thing_54/README.md similarity index 100% rename from fr-IR/thing_54/README.md rename to fa/thing_54/README.md diff --git a/fr-IR/thing_55/README.md b/fa/thing_55/README.md similarity index 100% rename from fr-IR/thing_55/README.md rename to fa/thing_55/README.md diff --git a/fr-IR/thing_56/README.md b/fa/thing_56/README.md similarity index 100% rename from fr-IR/thing_56/README.md rename to fa/thing_56/README.md diff --git a/fr-IR/thing_57/README.md b/fa/thing_57/README.md similarity index 100% rename from fr-IR/thing_57/README.md rename to fa/thing_57/README.md diff --git a/fr-IR/thing_58/README.md b/fa/thing_58/README.md similarity index 100% rename from fr-IR/thing_58/README.md rename to fa/thing_58/README.md diff --git a/fr-IR/thing_59/README.md b/fa/thing_59/README.md similarity index 100% rename from fr-IR/thing_59/README.md rename to fa/thing_59/README.md diff --git a/fr-IR/thing_60/README.md b/fa/thing_60/README.md similarity index 100% rename from fr-IR/thing_60/README.md rename to fa/thing_60/README.md diff --git a/fr-IR/thing_61/README.md b/fa/thing_61/README.md similarity index 100% rename from fr-IR/thing_61/README.md rename to fa/thing_61/README.md diff --git a/fr-IR/thing_62/README.md b/fa/thing_62/README.md similarity index 100% rename from fr-IR/thing_62/README.md rename to fa/thing_62/README.md diff --git a/fr-IR/thing_63/README.md b/fa/thing_63/README.md similarity index 100% rename from fr-IR/thing_63/README.md rename to fa/thing_63/README.md diff --git a/fr-IR/thing_64/README.md b/fa/thing_64/README.md similarity index 100% rename from fr-IR/thing_64/README.md rename to fa/thing_64/README.md diff --git a/fr-IR/thing_65/README.md b/fa/thing_65/README.md similarity index 100% rename from fr-IR/thing_65/README.md rename to fa/thing_65/README.md diff --git a/fr-IR/thing_66/README.md b/fa/thing_66/README.md similarity index 100% rename from fr-IR/thing_66/README.md rename to fa/thing_66/README.md diff --git a/fr-IR/thing_67/README.md b/fa/thing_67/README.md similarity index 100% rename from fr-IR/thing_67/README.md rename to fa/thing_67/README.md diff --git a/fr-IR/thing_68/README.md b/fa/thing_68/README.md similarity index 100% rename from fr-IR/thing_68/README.md rename to fa/thing_68/README.md diff --git a/fr-IR/thing_69/README.md b/fa/thing_69/README.md similarity index 100% rename from fr-IR/thing_69/README.md rename to fa/thing_69/README.md diff --git a/fr-IR/thing_70/README.md b/fa/thing_70/README.md similarity index 100% rename from fr-IR/thing_70/README.md rename to fa/thing_70/README.md diff --git a/fr-IR/thing_71/README.md b/fa/thing_71/README.md similarity index 100% rename from fr-IR/thing_71/README.md rename to fa/thing_71/README.md diff --git a/fr-IR/thing_72/README.md b/fa/thing_72/README.md similarity index 100% rename from fr-IR/thing_72/README.md rename to fa/thing_72/README.md diff --git a/fr-IR/thing_73/README.md b/fa/thing_73/README.md similarity index 100% rename from fr-IR/thing_73/README.md rename to fa/thing_73/README.md diff --git a/fr-IR/thing_74/README.md b/fa/thing_74/README.md similarity index 100% rename from fr-IR/thing_74/README.md rename to fa/thing_74/README.md diff --git a/fr-IR/thing_75/README.md b/fa/thing_75/README.md similarity index 100% rename from fr-IR/thing_75/README.md rename to fa/thing_75/README.md diff --git a/fr-IR/thing_76/README.md b/fa/thing_76/README.md similarity index 100% rename from fr-IR/thing_76/README.md rename to fa/thing_76/README.md diff --git a/fr-IR/thing_77/README.md b/fa/thing_77/README.md similarity index 100% rename from fr-IR/thing_77/README.md rename to fa/thing_77/README.md diff --git a/fr-IR/thing_78/README.md b/fa/thing_78/README.md similarity index 100% rename from fr-IR/thing_78/README.md rename to fa/thing_78/README.md diff --git a/fr-IR/thing_79/README.md b/fa/thing_79/README.md similarity index 100% rename from fr-IR/thing_79/README.md rename to fa/thing_79/README.md diff --git a/fr-IR/thing_80/README.md b/fa/thing_80/README.md similarity index 100% rename from fr-IR/thing_80/README.md rename to fa/thing_80/README.md diff --git a/fr-IR/thing_81/README.md b/fa/thing_81/README.md similarity index 100% rename from fr-IR/thing_81/README.md rename to fa/thing_81/README.md diff --git a/fr-IR/thing_82/README.md b/fa/thing_82/README.md similarity index 100% rename from fr-IR/thing_82/README.md rename to fa/thing_82/README.md diff --git a/fr-IR/thing_83/README.md b/fa/thing_83/README.md similarity index 100% rename from fr-IR/thing_83/README.md rename to fa/thing_83/README.md diff --git a/fr-IR/thing_84/README.md b/fa/thing_84/README.md similarity index 100% rename from fr-IR/thing_84/README.md rename to fa/thing_84/README.md diff --git a/fr-IR/thing_85/README.md b/fa/thing_85/README.md similarity index 100% rename from fr-IR/thing_85/README.md rename to fa/thing_85/README.md diff --git a/fr-IR/thing_86/README.md b/fa/thing_86/README.md similarity index 100% rename from fr-IR/thing_86/README.md rename to fa/thing_86/README.md diff --git a/fr-IR/thing_87/README.md b/fa/thing_87/README.md similarity index 100% rename from fr-IR/thing_87/README.md rename to fa/thing_87/README.md diff --git a/fr-IR/thing_88/README.md b/fa/thing_88/README.md similarity index 100% rename from fr-IR/thing_88/README.md rename to fa/thing_88/README.md diff --git a/fr-IR/thing_89/README.md b/fa/thing_89/README.md similarity index 100% rename from fr-IR/thing_89/README.md rename to fa/thing_89/README.md diff --git a/fr-IR/thing_90/README.md b/fa/thing_90/README.md similarity index 100% rename from fr-IR/thing_90/README.md rename to fa/thing_90/README.md diff --git a/fr-IR/thing_91/README.md b/fa/thing_91/README.md similarity index 100% rename from fr-IR/thing_91/README.md rename to fa/thing_91/README.md diff --git a/fr-IR/thing_92/README.md b/fa/thing_92/README.md similarity index 100% rename from fr-IR/thing_92/README.md rename to fa/thing_92/README.md diff --git a/fr-IR/thing_93/README.md b/fa/thing_93/README.md similarity index 100% rename from fr-IR/thing_93/README.md rename to fa/thing_93/README.md diff --git a/fr-IR/thing_94/README.md b/fa/thing_94/README.md similarity index 100% rename from fr-IR/thing_94/README.md rename to fa/thing_94/README.md diff --git a/fr-IR/thing_95/README.md b/fa/thing_95/README.md similarity index 100% rename from fr-IR/thing_95/README.md rename to fa/thing_95/README.md diff --git a/fr-IR/thing_96/README.md b/fa/thing_96/README.md similarity index 100% rename from fr-IR/thing_96/README.md rename to fa/thing_96/README.md diff --git a/fr-IR/thing_97/README.md b/fa/thing_97/README.md similarity index 100% rename from fr-IR/thing_97/README.md rename to fa/thing_97/README.md From 3fe258b0807753605b0e44e6b0f3ad89a26d74be Mon Sep 17 00:00:00 2001 From: Max Coplan Date: Thu, 18 May 2023 17:40:05 -0700 Subject: [PATCH 287/290] fix(grammar): capitalize "about" in chapter name The chapter name is "you gotta care about the code". I believe the correct grammar would be to have "about" be capitalized too. Also, this is the capitalization in the physical book's chapter title --- en/thing_96/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/en/thing_96/README.md b/en/thing_96/README.md index d6cc6dcc..58a880ff 100644 --- a/en/thing_96/README.md +++ b/en/thing_96/README.md @@ -1,4 +1,4 @@ -# You Gotta Care about the Code +# You Gotta Care About the Code It doesn't take Sherlock Holmes to work out that good programmers write good code. Bad programmers... don't. They produce monstrosities that the rest of us have to clean up. You want to write the good stuff, right? You want to be a good programmer. @@ -20,4 +20,4 @@ You want to write good code. You want to be a good programmer. So, you care abou Fortunately, you're reading this collection of advice because you do care about code. It interests you. It's your passion. Have fun programming. Enjoy cutting code to solve tricky problems. Produce software that makes you proud. -By [Pete Goodliffe](http://programmer.97things.oreilly.com/wiki/index.php/Pete_Goodliffe) \ No newline at end of file +By [Pete Goodliffe](http://programmer.97things.oreilly.com/wiki/index.php/Pete_Goodliffe) From 8a0c7dcded63e29403fd280f36a0736db73202c9 Mon Sep 17 00:00:00 2001 From: milad Date: Sat, 4 Nov 2023 16:14:07 +0330 Subject: [PATCH 288/290] fixed spelling issue --- fa/thing_31/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fa/thing_31/README.md b/fa/thing_31/README.md index fdeb52de..b94439d4 100644 --- a/fa/thing_31/README.md +++ b/fa/thing_31/README.md @@ -1,4 +1,4 @@ -# شنایی با مراحل توسعهٔ نرم‌افزار +# آشنایی با مراحل توسعهٔ نرم‌افزار ه طور کلی، فرایند توسعه ی نرم‌افزار به‌خصوص وب اپلیکیشن ها به ۴ دسته ی زیر تقسیم‌بندی می‌شوند که یک توسعه‌دهنده باید به خوبی با ویژگی‌های هر کدام آشنا باشد که در این آموزش، به تفصیل در مورد خصوصیات هر مرحله توضیح خواهیم داد. From ee09a70cf11a39d64b1c6fc74221cf78516e43be Mon Sep 17 00:00:00 2001 From: Dickson Souza Date: Sun, 28 Jan 2024 14:55:56 -0300 Subject: [PATCH 289/290] Fixed some typos in thing_01 version in pt_br and made other minor changes - Those minor changes intend to improve readability in Portuguese (making text a little far from a literal translation) --- pt_br/thing_01/README.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/pt_br/thing_01/README.md b/pt_br/thing_01/README.md index af06397c..d19e8b1e 100644 --- a/pt_br/thing_01/README.md +++ b/pt_br/thing_01/README.md @@ -2,13 +2,13 @@ > *"O que quer que você empreenda, aja com prudência e considere as consequências" Anon* -Não importa o queão confortável um cronograma parece no início de uma iteração, você não pode evitar estar sob pressão algumas vezes.Se vpcê se encontrar tendo que escolher entre "fazer certo" e "fazer rápido" geralmente é mais atraente "fazer rápido" sob o entendimento de que você vai voltar e consertar mais tarde. Quando você faz essa promessa para você mesmo, seu time, e seu cliente, é isso mesmo que você quer dizer. Mas muitas vezes a próxima iteração trás novos problemas e você acaba focando neles. Esse tipo de trabalho adiado é conhecido como débito técnico e não é seu amigo. Especificamente, Martin Fowler chama isso de débito técnico deliberado em sua [taxonomia de débito técnico](http://martinfowler.com/bliki/TechnicalDebtQuadrant.html), que não deve ser confundida com débito técnico inadvertido. +Não importa o quão confortável um cronograma pareça no início de uma iteração, você não pode evitar estar sob pressão algumas vezes. Se você se encontrar tendo que escolher entre "fazer certo" e "fazer rápido" geralmente é mais atraente "fazer rápido" sob o entendimento de que você vai voltar e consertar mais tarde. Quando você faz essa promessa para você mesmo, seu time, e seu cliente, é isso mesmo que você quer dizer. Mas muitas vezes a próxima iteração trás novos problemas e você acaba focando neles. Esse tipo de trabalho adiado é conhecido como débito técnico e não é seu amigo. Especificamente, Martin Fowler chama isso de débito técnico deliberado em sua [taxonomia de débito técnico](http://martinfowler.com/bliki/TechnicalDebtQuadrant.html), que não deve ser confundido com débito técnico inadvertido. -Débito técnico é como um empréstime: Você se beneficia disso no curto prazo, mas você tem que pagar juros sobre ele até que esteja totalmente pago. Atalhos no código tornam difícil de adicionar _features_ ou refatorar seu código. Eles são criadouros para defeitos e testes de caso que quebram fácil. Quanto mais você o mantiver, pior fica. No momento que você começa a realizar a correção original pode haver uma pilha inteira de "não muito corretas" decisões de design em camadas sobre o problema original, tornando o código muito mais difícil de refatorar e corrigir. De fato, muitas vezes apenas quando as coisas ficão tão ruins que você deve consertá-las, é que você realmente volta para consertar. E então muitas vezes é tão difícil corrigir que você realmente não pode pagar pelo tempo ou pelo risco. +Débito técnico é como um empréstimo: Você se beneficia disso no curto prazo, mas você tem que pagar juros sobre ele até que esteja totalmente pago. Atalhos no código tornam difícil de adicionar _features_ ou refatorar seu código. Eles são criadouros para defeitos e testes que falham com frequência. Quanto mais tempo você o mantiver, pior fica. No momento que você começa a realizar a correção original pode haver uma pilha inteira de decisões de design "não muito corretas" em camadas sobre o problema original, tornando o código muito mais difícil de refatorar e corrigir. De fato, muitas vezes apenas quando as coisas ficam tão ruins que você deve consertá-las, é que você realmente volta para consertar. E, então, muitas vezes é tão difícil corrigir que você realmente não pode pagar pelo tempo ou pelo risco. -Existem momentos que você deve incorrer ao débito técnico para cumprir um prazo ou implementar parte de uma _feature_. Tente não estar nessa posição, mas se a situação absolutamente demandar isso, vá em frente. Mas (e isso deve ser um grande MAS) você deve mapear o débito técnico e pagá-lo rapidamente ou as coisas irão rapidamente ladeira a baixo. Assim que você decidir se comprometer, escreva um cartão de tarefa ou registre isso no seu sistema de mapeamento de _issues_ para garantir que não seja esquecido. +Existem momentos que você deve criar débito técnico para cumprir um prazo ou implementar parte de uma _feature_. Tente não estar nessa posição, mas se a situação absolutamente demandar isso, vá em frente. Mas (e isso deve ser um grande MAS) você deve mapear o débito técnico e pagá-lo rapidamente ou as coisas irão rapidamente ladeira abaixo. Assim que você decidir se comprometer, escreva um cartão de tarefa ou registre isso no seu sistema de mapeamento de _issues_ para garantir que não seja esquecido. -Se vpcê programar o pagamento do débito na próxima iteração, o custo será mínimo. Não resolver o débito vai gerar um acúmulo de juros e esses juros devem ser mapeados para tornar o custo visível. Isso enfatizará o efeito sobre o valor de negócio do débito técnico do projeto and permitirá a priorização adequada do pagamento. A escolha de como calcular e mapear os juros vai depender do projeto em particular, mas você deve mapeá-lo. +Se você programar o pagamento do débito na próxima iteração, o custo será mínimo. Não resolver o débito vai gerar um acúmulo de juros e esses juros devem ser mapeados para tornar o custo visível. Isso enfatizará o efeito sobre o valor de negócio do débito técnico do projeto e permitirá a priorização adequada do pagamento. A escolha de como calcular e mapear os juros vai depender do projeto em particular, mas você deve mapeá-lo. Resolva o débito técnico assim que possível. Seria imprudente fazer o contrário. From ea62aa23b685ee29422fd8900d3f1084792a0fa5 Mon Sep 17 00:00:00 2001 From: Dickson Souza Date: Sun, 28 Jan 2024 15:07:15 -0300 Subject: [PATCH 290/290] Fixed link to Seb Rose profile - Former http://programmer.97things.oreilly.com/wiki/index.php/Seb_Rose is not working so I went to his GitHub profile and LinkedIn profile to give him proper credit - Changes were made in all current language files (English, Russian, Turkish and Portuguese - Brazil) --- en/thing_01/README.md | 2 +- pt_br/thing_01/README.md | 2 +- ru/thing_02/README.md | 2 +- tr/thing_01/README.md | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/en/thing_01/README.md b/en/thing_01/README.md index 3604026b..ba22a46c 100644 --- a/en/thing_01/README.md +++ b/en/thing_01/README.md @@ -12,4 +12,4 @@ If you schedule repayment of the debt in the next iteration, the cost will be mi Pay off technical debt as soon as possible. It would be imprudent to do otherwise. -By [Seb Rose](http://programmer.97things.oreilly.com/wiki/index.php/Seb_Rose) \ No newline at end of file +By [Seb Rose's GitHub profile](https://github.com/sebrose) / [Seb Rose's LinkedIn Profile](https://www.linkedin.com/in/sebrose) \ No newline at end of file diff --git a/pt_br/thing_01/README.md b/pt_br/thing_01/README.md index d19e8b1e..19854e37 100644 --- a/pt_br/thing_01/README.md +++ b/pt_br/thing_01/README.md @@ -12,4 +12,4 @@ Se você programar o pagamento do débito na próxima iteração, o custo será Resolva o débito técnico assim que possível. Seria imprudente fazer o contrário. -Por [Seb Rose](http://programmer.97things.oreilly.com/wiki/index.php/Seb_Rose) +Por [Seb Rose's GitHub profile](https://github.com/sebrose) / [Seb Rose's LinkedIn Profile](https://www.linkedin.com/in/sebrose) diff --git a/ru/thing_02/README.md b/ru/thing_02/README.md index d2257822..56a8f64e 100644 --- a/ru/thing_02/README.md +++ b/ru/thing_02/README.md @@ -13,4 +13,4 @@ Оплачивайте технический долг как можно быстрее. Действовать по-другому было бы неосмотрительно. -Автор оригинала - [Seb Rose](http://programmer.97things.oreilly.com/wiki/index.php/Seb_Rose) \ No newline at end of file +Автор оригинала - [Seb Rose's GitHub profile](https://github.com/sebrose) / [Seb Rose's LinkedIn Profile](https://www.linkedin.com/in/sebrose) \ No newline at end of file diff --git a/tr/thing_01/README.md b/tr/thing_01/README.md index cfd646aa..ecb145fb 100644 --- a/tr/thing_01/README.md +++ b/tr/thing_01/README.md @@ -12,4 +12,4 @@ Bir sonraki yinelemede borcun geri ödemesini planlarsanız, maliyet minimum ola Teknik borcu mümkün olan en kısa sürede ödeyin. Aksini yapmak tedbirsizlik olur. -[Seb Rose](http://programmer.97things.oreilly.com/wiki/index.php/Seb_Rose) Tarafından \ No newline at end of file +[Seb Rose's GitHub profile](https://github.com/sebrose) / [Seb Rose's LinkedIn Profile](https://www.linkedin.com/in/sebrose) Tarafından \ No newline at end of file