Spell checking, edit non-russian files. Version 04 (#5)

braydie · Jan 7, 2023 · 041b3c6 · 041b3c6
1 parent b8b947e
commit 041b3c6
Show file tree

Hide file tree

Showing 42 changed files with 52 additions and 49 deletions.
diff --git a/LANGS.md b/LANGS.md
@@ -1,3 +1,4 @@
 * [English](en/)
 * [Chinese](zh/)
 * [Japanese](jp/)
+* [Russian](ru/)
diff --git a/README.md b/README.md
@@ -23,7 +23,7 @@ Welcome to the tribe.
 
 ## Contents
 
-**Also available in [Chinese](zh/README.md) and [Japanese](jp/README.md)**
+**Also available in [Chinese](zh/README.md), [Japanese](jp/README.md), and [Russian](ru/README.md)**
 
 1. [Beginner](en/1-Beginner)
 	- Personal Skills

diff --git a/en/7-Contributions.md b/en/7-Contributions.md
@@ -17,6 +17,7 @@ There are a number of ways to contribute to "How to be a Programmer".
 Currently this guide has been translated from English into the following languages:
 
 - Chinese by [ahangchen](https://github.com/ahangchen)
+- Russian by [paveltovchigrechko](https://github.com/paveltovchigrechko)
 
 **If you provide the initial translation of the guide into another language, you become legible to become a contributor on this project to help maintain and review changes made to the translation.**
 

diff --git a/jp/7-Contributions.md b/jp/7-Contributions.md
@@ -17,6 +17,7 @@ There are a number of ways to contribute to "How to be a Programmer".
 Currently this guide has been translated from English into the following languages:
 
 - Chinese by [ahangchen](https://github.com/ahangchen)
+- Russian by [paveltovchigrechko](https://github.com/paveltovchigrechko)
 
 **If you provide the initial translation of the guide into another language, you become legible to become a contributor on this project to help maintain and review changes made to the translation.**
 

diff --git a/ru/1-Beginner/Personal-Skills/01-Learn-To-Debug.md b/ru/1-Beginner/Personal-Skills/01-Learn-To-Debug.md
@@ -1,10 +1,10 @@
 # Научитесь отлаживать
 [//]: # (Version:1.0.0)
-Отладка это краеугольный камень профессии программиста. Основное значение слова "debug" это "устранять ошибки", но значение, которое имеет реальный вес, это "видеть, как исполняется программа, изучая ее код". Программист, который не умеет эффективно отлаживать, слеп.
+Отладка - это краеугольный камень профессии программиста. Основное значение слова "debug" это "устранять ошибки", но значение, которое имеет реальный вес, это "видеть, как исполняется программа, изучая ее код". Программист, который не умеет эффективно отлаживать, слеп.
 
 Те идеалисты, которые считают, что дизайн, анализ, теория сложности вычислений и подобное более фундаментальны, чем отладка, вряд ли являются работающими программистами. Работающий программист не живет в идеальном мире. Даже если вы идеальны, вы окружены и вынуждены работать с кодом, который написан в больших корпорациях, организациях вроде GNU и вашими коллегами. Большая часть этого кода неидеальна, и она неидеально задокументирована. Без способности видеть исполнение этого кода, малейший баг выбьет вас из колеи. Часто увидеть исполнение можно только с помощью эксперимента, то есть, отладки. 
 
-Отладка больше касается исполнения программ, чем самих программ. Если вы купите программное обеспечение от большой компании, то как правило вам не доведется увидеть сам код. Но все равно будут моменты, когда программа не соответствует документации, либо документация просто ничего не говорит о конкретном поведении программы. Распространенный и яркий пример: сбой всей операционной системы во время работы программы. Обычно вы при работе создаете баг, изучаете собственный код и понятия не имеете, как он возник. Неизбежно это ведет к мысли о том, что вы делаете что-то не то, либо возникает некое обстоятельство, которое вы не учитываете в программе. Иногда трюк с изучением исходного кода помогает. Иногда нет, и тогда вы должны перейти к отладке.
+Отладка больше касается исполнения программ, чем самих программ. Если вы купите программное обеспечение от большой компании, то, как правило, вам не доведется увидеть сам код. Но все равно будут моменты, когда программа не соответствует документации, либо документация просто ничего не говорит о конкретном поведении программы. Распространенный и яркий пример: сбой всей операционной системы во время работы программы. Обычно вы при работе создаете баг, изучаете собственный код и понятия не имеете, как он возник. Неизбежно это ведет к мысли о том, что вы делаете что-то не то, либо возникает некое обстоятельство, которое вы не учитываете в программе. Иногда трюк с изучением исходного кода помогает. Иногда нет, и тогда вы должны перейти к отладке.
 
 Чтобы понять, как исполняется программа, вы должны иметь возможность запустить ее и наблюдать за ее ходом исполнения. Иногда баг виден визуально, например, если он отображается на экране или между событиями в программе очевидна непредусмотренная задержка. Во многих других случаях, баг связан с факторами, которые нельзя наблюдать непосредственно, например, с состоянием переменных, конкретными строками кода, исполняющиеся в данный момент, либо с утверждениями внутри сложной структуры данных. Эти скрытые факторы надо выяснить.
 

diff --git a/ru/1-Beginner/Personal-Skills/02-How-to-Debug-by-Splitting-the-Problem-Space.md b/ru/1-Beginner/Personal-Skills/02-How-to-Debug-by-Splitting-the-Problem-Space.md
@@ -6,7 +6,7 @@
 
 Сможете ли вы поставить эксперимент, чтобы увидеть, где вылетает программа? Конечно. Вы можете использовать отладчик или добавить вывод в консоль (либо их эквивалент на вашем языке программирования) после восьмой и девятой инструкций. Когда вы запустите программу снова, пространство проблемы станет еще уже, например, вы увидите, что программа вылетает на девятой инструкции. Я считаю, что помнить о точном определении проблемы помогает сосредоточиться на ее решении. Когда несколько человек работают под давлением и стрессом над задачей, очень легко забыть о том, что в ней является главной проблемой.
 
-Ключ к отладке по принципу "разделяй и властвуй" такой же, как и при разработке алгоритмов. Вы разделяете пространство программы, в котором может быть проблема, напополам. Вам не придется делать это слишком долго, и вы быстро будете продвигаться в отладке. Но что такое то пространство, где находится ошибка и которое следует поделить пополам? Именно здесь на помощь приходят смекалка и опыт.
+Ключ к отладке по принципу "разделяй и властвуй" такой же, как и при разработке алгоритмов. Вы разделяете пространство программы, в котором может быть проблема, пополам. Вам не придется делать это слишком долго, и вы быстро будете продвигаться в отладке. Но что такое то пространство, где находится ошибка и которое следует поделить пополам? Именно здесь на помощь приходят смекалка и опыт.
 
 Начинающим программистам кажется, что ошибка может быть в каждой строке кода. У них еще нет того понимания программы, которое появится позже с опытом. Они не видят все свойства и факторы программы, такие как пространство исполняемого кода, структура данных, управление памятью, взаимодействие с внешним кодом, рискованный код, простой код. Для опытного программиста эти факторы составляют неполную, но крайне полезную модель всего того, что может пойти не так. Наличие такой модели в голове очень эффективно помогает обнаружить точное место проблемы.
 

diff --git a/ru/1-Beginner/Personal-Skills/03-How-to-Remove-an-Error.md b/ru/1-Beginner/Personal-Skills/03-How-to-Remove-an-Error.md
@@ -4,6 +4,6 @@
 
 При исправлении бага важно внести наименьшие изменения, которые его устранят. Вы можете заметить другие места в коде, которые потребуют улучшений, но не вносите их одновременно с исправлением ошибки. Старайтесь применять научный метод: изменять только одно зараз. Лучший способ для этого: воспроизвести баг, внести исправления, затем перезапустить программу и убедиться, что бага больше нет. Конечно, иногда придется менять не одну, а несколько строк кода, но концептуально все равно старайтесь вносить точечные изменения для исправления ошибки.
 
-Иногда в программе присутствует несколько багов, очень похожих друг на друга. Определить их и исправить по одному - это ваша задача. Иногда неясно, что должна делать программа или к чему стремился автор исходного кода. В этом случае, вы должны применить свой опыт и знания и придать свой собственный смысл коду. Решите, что он должен делать, и добавьте комментарии об этом, либо обозначьте это иным способом. Затем исправьте код согласно своему пониманию. Это навык разработчика среднего или продвинутого уровня, и иногда он гораздо сложнее, чем написание оригинальной функции с нулю, но реальный мир часто бывает беспорядочен. Иногда вам придется исправлять системы, которые вы не можете переписать с нуля.
+Иногда в программе присутствует несколько багов, очень похожих друг на друга. Определить их и исправить по одному - это ваша задача. Иногда неясно, что должна делать программа или к чему стремился автор исходного кода. В этом случае вы должны применить свой опыт и знания и придать свой собственный смысл коду. Решите, что он должен делать, и добавьте комментарии об этом, либо обозначьте это иным способом. Затем исправьте код согласно своему пониманию. Это навык разработчика среднего или продвинутого уровня, и иногда он гораздо сложнее, чем написание оригинальной функции с нулю, но реальный мир часто бывает беспорядочен. Иногда вам придется исправлять системы, которые вы не можете переписать с нуля.
 
 Следующее: [Как отлаживать, используя логирование](04-How-to-Debug-Using-a-Log.md)
diff --git a/ru/1-Beginner/Personal-Skills/04-How-to-Debug-Using-a-Log.md b/ru/1-Beginner/Personal-Skills/04-How-to-Debug-Using-a-Log.md
@@ -4,7 +4,7 @@
 
 - Логи могут дать полезную информацию о багах, которые трудно воспроизвести (например, такие, которые воспроизводятся на боевом окружении, но не на тестовом)
 - Логи могут давать статистику и данные о производительности, такие как время между выполнением команд
-- Если логи настраиваемы, то они помогают собрать общую информацию для устранения непредвиденных специфических проблем без необходимости модифицировать или перезапускать код
+- Если логи можно настраивать, то они помогают собрать общую информацию для устранения непредвиденных специфических проблем без необходимости модифицировать или перезапускать код
 
 Количество выводимой в лог информации это всегда компромисс между информативностью и краткостью. Избыток информации сделает лог тяжелым и вызовет *слепоту прокрутки*, усложняя поиск нужного. Недостаток информации может просто сделать лог бесполезным. По этой причине полезно делать логи настраиваемыми. Как правило, каждая запись в логе отображает свое место в исходном коде, исполняющий ее поток, если он есть, точное время исполнения и, обычно, дополнительную информацию вроде значений переменных, объем свободной памяти, число объектов с данными и так далее. Эти записи покрывают весь исходный код, особенно основные функциональные узлы и рискованный код. Записи можно распределять по уровням, и настраивать в конфигурации вывод только записей определенного уровня. Лог следует проектировать таким образом, чтобы его записи помогали решать проблемы программы, которые вы предвидите. Предусматривайте и проблему измерения производительности.