fix some orthography errors

Author: dvorovenko

README.md

@@ -42,7 +42,7 @@ you shout when reading code](https://www.osnews.com/images/comics/wtfm.jpg)
 
 И еще одна вещь: знание этих принципов не делает вас сразу лучшим разработчиком ПО, а их использование в
 течение многих лет не гарантирует, что вы не будете совершать ошибки. Каждый кусок кода начинается как
-черновик, как мокрый кусок глины который только постеменно приобретает свою форму. Не упрекайте себя при
+черновик, как мокрый кусок глины который только постепенно приобретает свою форму. Не упрекайте себя при
 первых набросках кода, которые нуждаются в улучшении. Улучшайте код вместо этого!
 
 **[⬆ Вернуться в начало](#содержание)**
@@ -118,8 +118,8 @@ function getUser(): User;
 
 ### Используйте имена, доступные для поиска 
 
-Мы читаем больще кода, чем пишем. Это важно чтобы код, который мы пишем, был читаемым и достумным для поиска.
-Не называйте переменные, которые в конечном итое имеют смысл только для наших программ мы вредим нашим читателям.
+Мы читаем больше кода, чем пишем. Это важно чтобы код, который мы пишем, был читаемым и доступным для поиска.
+Не называйте переменные, которые в конечном итоге имеют смысл только для наших программ мы вредим нашим читателям.
 Делайте ваши имена доступными для поиска.
 Такие инструменты, как [TSLint](https://palantir.github.io/tslint/rules/no-magic-numbers/) и [ESLint](https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/docs/rules/no-magic-numbers.md)
 могут помочь идентифицировать не названные константы.
@@ -191,7 +191,7 @@ const transaction = charge(user, subscription);
 
 ### Не добавляйте не нужный контекст
 
-Если имя вашего класса/типа/объекта говорит само за себя, не повторяйте его в вашем именни переменной.
+Если имя вашего класса/типа/объекта говорит само за себя, не повторяйте его в вашем имени переменной.
 
 **Плохо:**
 
@@ -303,12 +303,12 @@ class Projector {
 
 ### Аргументы функции (идеально два или меньше)
 
-Ограничение колличества парамметров функции невероятно важно, потому что это делает тестирование ваших
+Ограничение количества параметров функции невероятно важно, потому что это делает тестирование ваших
 функций проще. Наличие более 3-х аргументов приводит к комбинаторному взрыву, где вы должны протестировать
 множество вариантов с каждым отдельным аргументом
 
 Один или два аргумента это идеальный случай, а три и более следует избегать, если это возможно.
-Большое колличество аргументов лучше объеденять. Обычно если вы используете более двух аргументов, то ваша функция пытается
+Большое количество аргументов лучше объеденять. Обычно если вы используете более двух аргументов, то ваша функция пытается
 делать слишком много. В случаях когда это не так, то лучше использовать объект верхнего уровня. 
 
 Подумайте о том чтобы использовать объектные литералы, если вам необходимо много аргументов.
@@ -375,7 +375,7 @@ createMenu({
 Это одно из самых важных правил в разработке ПО. Когда функции решают больше одной задачи,
 их труднее объеденять, тестировать. Если вы сможете изолировать функцию так чтобы она выполняла только одну задачу,
   в дальнейшем она может быть легко переработана, а ваш код будет чище. Если вы запомните только это правило из этого
-  руководства, то вы уже будете лучще многих разработчиков.
+  руководства, то вы уже будете лучше многих разработчиков.
 
 **Плохо:**
 
@@ -555,7 +555,7 @@ function showManagerList(managers: Manager[]) {
 }
 ```
 
-**Хорощо:**
+**Хорошо:**
 
 ```ts
 class Developer {
@@ -595,7 +595,7 @@ function showEmployeeList(employee: Developer | Manager) {
 
 Вы должны критически относиться к дублированию кода. Иногда существует компромисс между дублированием кода и увеличением
 сложности, вводя новую абстракцию. Когда две реализации из двух разных модулей выглядят одинаково, но существуют в разных
-доменах, дублирование может быть приемлемым и предпочтительным вариантом, нежели объеденений в общий код. Перенос логики
+доменах, дублирование может быть приемлемым и предпочтительным вариантом, нежели объединений в общий код. Перенос логики
 в общий код, вводит косвенную зависимость между двумя модулями.
 
 **[⬆ back to top](#содержание)**
@@ -737,16 +737,16 @@ console.log(name);
 
 В JavaScript примитивы передаются по значению, а объекты и массивы передаются по ссылке. В случае объектов или массивов,
 если ваша функция вносит изменения в корзину покупок(массив), например при добавлении элемента в массив, то любая другая
-функция использующаяя `корзину` массив будет зависеть от этого добавления. Это может быть как хорошо, так и плохо. Давайте
+функция использующая `корзину` массив будет зависеть от этого добавления. Это может быть как хорошо, так и плохо. Давайте
 представим плохую ситуации:
 
-Пользователь нажимает кнопку "Купить" вызывующюю функцию `purchase` которая делает сетевой запрос и отправляет `корзину`
+Пользователь нажимает кнопку "Купить" вызывающую функцию `purchase` которая делает сетевой запрос и отправляет `корзину`
 массив на сервер. Если происходит плохое подключение к сети функция должна отправить повторный запрос. Теперь, если пользователь
 случайно нажимает на кнопку "Добавить в корзину", но пока не хочет покупать товар? Если это произойдет и в этот момент начнется
 запрос на сервер, то функция purchase отправит случайно добавленный элемент, так как он имеет ссылку на корзину покупок,
 котора была изменена функцией `addItemToCart`. Путем добавления нежелательного элемента.
 
-Хорошим бы рещением было бы что бы функция `addItemToCart` всегда клонировала бы массив `cart` редактировала его и
+Хорошим бы решением было бы что бы функция `addItemToCart` всегда клонировала бы массив `cart` редактировала его и
 возвращала клон. Это бы гарантировало, что никакие другие функции, использующие ссылку на массив корзины покупок,
 не будут затронуты какими-либо изменениями.  
 
@@ -928,7 +928,7 @@ if (!isEmailUsed(node)) {
 
 Эта задача кажется невозможной. Большинство людей, впервые услышав это, говорят, "как я должен делать что-либо без
 выражения `if`?". Ответ заключается в том, что во многих случаях для достижения тех же целей можно использовать
-полиморфизм. Второй вопро обычно, "хорошо, замечательно, но почему я должен их избегать?" Ответ, предыдущая концепция
+полиморфизм. Второй вопрос обычно, "хорошо, замечательно, но почему я должен их избегать?" Ответ, предыдущая концепция
 чистого кода, которую вы узнали: функция должна выполнять только одну задачу. Когда у вас есть классы и функции,
 содержащие конструкцию `if`, вы говорите своему пользователю, что ваша функция выполняет больше одной задачи.
 Запомните, делать только одну задачу.
@@ -1563,7 +1563,7 @@ class UserNotifier {
 
 ### Предпочитайте композицию наследованию
 
-Как сказано в  [Design Patterns](https://en.wikipedia.org/wiki/Design_Patterns) от банды черытех вы должны
+Как сказано в  [Design Patterns](https://en.wikipedia.org/wiki/Design_Patterns) от банды четырех вы должны
 *Предпочитать композицию наследованию* где можете. Есть много веских причин использовать наследование и много хороших
 причин использовать композицию. Суть этого принципа в том, что если ваш ум инстинктивно идет на наследование,
 попробуйте подумать, может ли композиция лучше смоделировать вашу проблему. В некоторых случаях может.  
@@ -2561,7 +2561,7 @@ try {
 
 Форматирование носит субъективный характер. Как и во многом собранном здесь, в вопросе форматирования нет жестких правил, которым вы обязаны следовать. Главное - *НЕ СПОРИТЬ* по поводу форматирования. Есть множество инструментов для автоматизации этого. Используйте один! Это трата времени и денег когда инженеры спорят о форматировании. Общее правило, которому стоит следовать *соблюдайте правила форматирования принятые в команде*  
 
-Для TypeScript есть мощный инструмент под названием [TSLint](https://palantir.github.io/tslint/). Это статический анализ инструмент, который может помочь вам значительно улучшить читаемость и поддерживаемость вашего кода. Но лучще используйте [ESLint](https://github.com/typescript-eslint/typescript-eslint), так как TSLint больше не поддерживается.
+Для TypeScript есть мощный инструмент под названием [TSLint](https://palantir.github.io/tslint/). Это статический анализ инструмент, который может помочь вам значительно улучшить читаемость и поддерживаемость вашего кода. Но лучше используйте [ESLint](https://github.com/typescript-eslint/typescript-eslint), так как TSLint больше не поддерживается.
 Есть готовые к использованию конфигурации TSLint и ESLint, на которые вы можете ссылаться в своих проектах:
 
 - [TSLint Config Standard](https://www.npmjs.com/package/tslint-config-standard) - стандартный набор правил
@@ -2845,7 +2845,7 @@ type User = {
 
 ### Не заводите журнальных комментариев
 
-Не забывайте использовать системы контроля версий! Нет необходимости в мертвом коде, закоментированном коде и особенно в
+Не забывайте использовать системы контроля версий! Нет необходимости в мертвом коде, закомментированом коде и особенно в
 журнальных комментариях. Используйте `git log`, чтобы получить историю!
 
 **Плохо:**