Чи важливе грунтовне освоєння теорії у навчанні програмуванню?

Ми продовжуємо публікувати статті курсантів RubyForce. Сьогодні стаття від Іллі Кузьми:

***********************************************************

def method_name
     puts “Can you get what’s going on here?”
end

***********************************************************

PS:
TL;DR
Так – це важливо знати теорію і ні – не потрібно її освоювати

***********************************************************

Спробую розкрити свою думку на прикладі вивчення англійської.

Десять років вивчення мови у школі + 5 у ВУЗі + курси == “Я досі не можу розмовляти”. Це приклад грунтовного освоєння теорії. Думаю, багатьом це знайомо. В якийсь момент я усвідомив скільки часу було невідворотно змарновано. Це був шок.

І я розпочав шукати альтернативні методи вивчення.

В одному з відео я побачив просту таблицю всіх, так званих, “часів”. За півгодини я отримав landscape view всієї мови. Це був ще один шок. Далі я взнав, що немає сенсу вчити окремі слова. Потрібно вчити блоки. Немає сенсу вчити граматичні правила, натомість треба вчити граматичні конструкції (або фрази).

Процес пішов. Не гладко. Але набагато краще ніж до цього. Я не знав яке правило потрібно застосувати, але на слух міг зрозуміти коли говорив неправильно.

Якось я познайомився із Джоном. Він американець та викладав англійську у нас у Львові. Одного разу я запитав Джона: “Що ти думаєш про граматику? Варто її вчити?”. Він сказав: “Так. Звичайно”. Я був, м’яко кажучи, здивований. Як же так?

Кажу: “Поясни”. І він пояснив, що вивчення граматики має відбуватись тоді, коли ти хочеш зрозуміти чому ти говориш так як говориш. Тобто, вивчення стає усвідомленим. Ти відкриваєш правило і “Aha! Makes sense”.

У мене схожа історія також із програмуванням. Я розпочав вивчення JS із фундаментальної книги на 900+ сторінок. Який результат, думаю, ви здогадуєтесь. Коли ж мені знадобився React я пішов на офіційний сайт і за допомогою кількох статей реалізував те що мені було потрібно. В перший же день я почав писати компоненти. Теорія і практика йшли паралельно.

Моя особиста думка, не обов’язково бути філологом щоб розмовляти. Так само, не обов’язково знати всі нюанси мови програмування для того щоб писати код. В якийсь момент захочеться повернутись до === і зрозуміти як же там все влаштовано 🙂

Як проектувати архітектуру на етапі старту проекту?

Рубіфорс продовжує набирати оберти і сьогодні ми публікуємо наступну статтю, Марія Кулакова пише про проектування архітектури на старті проекту.

Однією з найвидатніших пам’яток Італії є Пізанська вежа. Можна багато говорити про її велич і красу. У цій статті я не буду проводити огляд місць, де протягом життя повинен побувати кожен, але, як не дивно, мова йтиме про архітектуру і як правильно її проектувати.

Так от, ціль створення такого дива була в тому, щоб вежа слугувала дзвіницею в місті Піза (це унікальний випадок того, що вежа прославилась саме завдяки своєму нахилу). Але тут питання інакше – коли вона впаде? Отже, як би сумно не було і якою б величною вона не була, рано чи пізно це станеться. Звичайно, влада країни тратить величезні кошти на те, щоб споруда стояла довше. І це дасть свій результат, але на деякий час. А все зводиться до питання: ”Чи достатньо подумав архітектор, перед тим як закладати перші камені в її фундамент?” Напевно, легко провести аналогію зі світом IT. І, мабуть, не один проект є цією вежею. Тому дана стаття про наболіле і про те, як уникнути грабель:)

Дуже часто програміст, на початку створення якогось нового проекту, намагається відразу писати код. В когось, навіть, це виходить, створюється клас за класом і…..приходить усвідомлення: “Що ж це я роблю? Та програма не працює так, як би мала”. Тоді вже написана велика кількість рядків, а найстрашніше попереду – вночі починаються снитися сни, що ти забрів в такі дебрі, що вибратись звідти можна тільки стрибнувши в розпечену лаву. І посеред ночі ти прокидаєшся в холодному поту та приймаєш рішення: “ТРЕБА ВСЕ ПОМІНЯТИ!” Звичайно, можна продовжувати варити макарони, і їх, навіть, можна буде їсти. Але, може, краще було б продумати все наперед?

Як не дивно, але першим і основним правилом для тих, хто починає створювати проект – це сісти, взяти ручку і листочок і почати малювати. Так, саме малювати. Ну якщо говорити більш детально, то ось алгоритм створення проекту:

  • Постановка задачі.
  • Мінімальний функціонал.
  • Інтерфейси.
  • Проектування.
  • Код.

Давайте пройдемося по цьому детальніше.

Чи не найголовніше завдання, яке стоїть перед програмістом – це розуміння цілі виконання даного завдання, для яких потреб воно створюється і які проблеми буде вирішувати. Тільки після чіткого усвідомлення цілей можна приступати до наступного – детально прописати всі функції, які виконуватиме програма. Можливо на даному етапі ви не знаєте, як реалізувати функцію, але то нормально. Це робиться для того, щоб було зрозуміло, які функцї є зайвими, а які потрібно додати. Інтерфейси… ні, це не ті інтерфейси, які програмісти використовують разом з класами. До написання коду ще далеко. Це користувацькі інтерфейси. Точніше те, як користувач буде взаємодіяти з програмою. Якщо це, до прикладу, сайт чи десктопна аплікація, то промалювати віконечка, текстові поля і т.д. І після того, як ви зрозуміли, як буде працювати програма з точки зору користувача, можна переходити до вияснення того, як це все буде виглядати з точки зору програміста. Отже, проектування.

Є дуже багато підходів до проектування, про які написано безліч книжок. В їхній основі лежить правило декомпозиції або “розділяй і володарюй”. Суть полягає в тому, що потрібно нашу програму розбити на такі модулі, щоб при потребі щось змінити в одній частині програми, це майже не повпливало на решту коду. Так, це звучить як суха теорія. Ну якшо говорити про практичну сторону, то це можна реалізувати з допомогою діаграм і звязків. Промалювати які будуть класи і як вони мають взаємодіяти між собою. Насправді,немає чіткого рецепту як правильніше спроектувати архітектуру, але в даному питанні більшу роль відіграє досвід проектування і чим свіжіша голова над цим працює, тим краще.

Аж тут можна починати писати код. Ну нарешті!

Не знаю, в якому стані були архітектори, які проектували Пізанську вежу, але краще буду схилятись до думки, що це сталося через брак часу. Тому завдяки їм, ми маємо чудову ілюстрацію того, як не потрібно проектувати архітектуру. А для простих смертних це є ще однією локацією в списку запланованих подорожей:)

Особливості мови Рубі для тих, хто починає її вчити

Сьогодні починається другий тиждень навчання.  Підсумовуючи перший тиждень, публікуємо допис від Олександра Ткачика, який описав свої перші враження від роботи з Ruby.

Гайд по Рубі для Newbie, очима Newbie

Рубі. Рубі це мова. Це мова програмування. Та ще й об’єктно-орієнтована. Настільки об’єктно-орієнтована, що там все є об’єктом. Навіть число 5 — і те є об’єктом. Константи в Рубі не є константними. Їх спокійно можна змінити і програма не впаде (хоча і виведе повідомлення, а-ля “дядя, ты шо тугой?”). В Рубі є блоки і вони є дуже поширені, тому роботу із ними необхідно добре опанувати, або застрелитись, щоби відчути зручність написання програм. Приватні методи в класах є приватними, але не зовсім. Їх можна неявно викликати. (run, Forrest, RUN!!!).

Такі факти можуть викликати певний дисонанс. Ще би — як можна змінювати константи?! Але те, що їх можна змінювати — не означає що це треба робити, чи не так? 😉 Тому, деякі, здавалось би, недоліки можна перетворити на переваги. Просто необхідно трішки попрацювати на Рубі та вивчити її особливості.

Тепер поговоримо про комфорт.

Отже, Рубі. Це проста для розуміння, але потужна мова програмування, створена японцем Юкіхіро Мацумото. Він хотів сумістити простоту і швидкість написання коду із читабельністю. І йому це вдалось, адже на Рубі програміст може писати дуже короткий, при цьому неймовірно функціональний код, який можна би було легко читати (навіть тим, хто раніше не бачив цієї мови програмування).

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

Сильним козирем Рубі є простота та швидкість розробки проектів. Недарма величезна кількість стартапів реалізується саме на Рубі. Той самий Twitter був розроблений за допомогою Рубі.

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

Ще одним плюсом є наявність gem`ів — готових бібліотек, які дуже полегшують життя розробникам. Наприклад, замість того, щоби створювати власний клас конвертації валюти — можна підключити відповідну бібліотеку money, коротко прочитати документацію і все, конвертація валюти відбувається одним простим рухом!

Фреймворки у Рубі також добре розвинені. Найпотужнішим є Ruby On Rails, який реалізує шаблон MVC. Розібравшись із ним, можна за день написати та запустити невеликий блог, власну сторінку чи інші прості аплікації. Окрім Ruby On Rails існує багато інших фреймворків — Sinatra, Hanami, NYNY, Cuba та інші.

Окремої уваги заслуговує інтерактивна консоль irb — програма, яка дозволяє виконувати команди Рубі в режимі реального часу. З її допомогою можна швидко протестувати частину реалізації. Існує цілий сайт, який дозволяє пройти основи Рубі, використовуючи irb.

Отже… Незважаючи на дивакуватість, ця мова має потужні козирі — простоту та швидкість розробки проектів завдяки чудовим фреймворкам, зручні, якісні та готові бібліотеки, легкий синтаксис та можливість “адаптувати” мову під себе.

P.S. return в Рубі теж необов’язковий 😀

 

P.S. Картинку (з невеликими модифікаціями) взяли тут: https://www.sketchport.com/drawing/5684872177778688/doge