Переосмислення javascript смерть for, savepearlharbor

Цикл for добре послужив нам, але він застарів і повинен поступитися місцем більш новим, функціональним технікам програмування.

На щастя, цей факт не вимагає від вас бути майстром функціонального програмування, більш того, це те, що ви можете використовувати в своїх поточних проектах прямо сьогодні.

Дизайн циклу for підштовхує до мутацій стану (англ. Mutation of state - зміна стану - прим. Перекладача) і застосування сайд ефектів (англ. Side effects - побічні ефекти - прим. Перекладача), які є потенційними джерелами багів і непередбачуваної поведінки коду.

Всі ми чули, що глобальне стан - це погано, і що ми повинні уникати його. Однак, локальне стан розділяє ті ж проблеми що і глобальне. ми просто не стикаємося з ними так часто, адже вони проявляються в менших масштабах. Фактично, ми ніколи не вирішували проблему, а просто зводили її до мінімуму.

Одного разу, використовуючи мутабельном стан (англ. Mutable state - змінне стан - прим. Перекладача), значення випадкової змінної зміниться з невідомої причини, і ви витратите годинник на налагодження і пошук причини зміни. У мене волосся на голові стає дибки, тільки від однієї думки про це.

Я б хотів трохи поговорити про сайд ефекти. Ці слова навіть звучать жахливо, сайд ефекти. Дрянь. Ви хочете щоб у ваших програмах були сайд ефекти? Ні, я не хочу сайд ефектів в моїх програмах!

Але що таке сайд ефекти?

Вважається, що у функції є сайд ефекти якщо вона модифікує щось за межами своєї області видимості. Це може бути зміна змінної, призначений для користувача введення, запит до api, запис даних на диск, лог в консоль і т.д.

Сайд ефекти - дійсно потужний інструмент, але з великою силою приходить велика відповідальність.

Менше слів, більше коду. Давайте подивимося на типовий цикл for. який ви ймовірно бачили сотні разів.

Я збираюся отрефакторіть цей код крок за кроком, щоб ви змогли поспостерігати як легко перетворити ваш власний код в щось більш прекрасне.

По-перше, я витягну умовний вираз в окрему функцію:

Виносити умови - це в цілому хороша практика. Зміна фільтрації з "менше ніж 7 місяців" на "є чи кошеням" - великий крок вперед. Тепер код передає наші наміри набагато краще. Чому ми беремо котів до 7 місяців? Не зовсім зрозуміло. Ми хочемо знайти кошенят, так нехай код говорить про це!

Інша користь в тому, що isKitten тепер можна перевикористати, а всі ми знаємо, перевикористання коду завжди має бути нашою метою.

Наступна зміна - витягти перетворення (або вiдтворення) кота його в ім'я. Ця зміна буде зрозуміліше пізніше, а зараз просто довіртеся мені.

Зверніть увагу, ми позбулися kittens.push (.). Ніяких більше мутацій стану і ніяких var.

Код віддає перевагу const перед var і let виглядає чертовски привабливо

Звичайно, ми могли використовувати const з самого початку, тому що він не робить сам об'єкт іммутабельним (про це більше іншим разом), але це придуманий приклад, що не насідає!

І остання зміна, я б запропонував також витягти фільтрацію і відображення в функцію (для повного перевикористання коду).

Домашнє завдання

Вивчити витяг методів filter і map з їх об'єктів.
Завдання із зірочкою: дослідити композицію функцій.

Що щодо break

висновок