Чи задумувалися ви над тим, що код, який ми пишемо, повинен бути зручним та зрозумілим не тільки для нас, але й для інших розробників?
Отже, ми провели опитування серед студентів ХНУРЕ, які вже мають досвід роботи в IT-компанії, стосовно цього питання.
«Хаотичність та недотримання чіткого стилю» — це перше враження від написаного кода новачками. Але якщо ми бажаємо випробувати свою удачу в IT-компанії, то доведеться навчитися писати код з дотриманням певних вимог для продуктивної співпраці з іншими розробниками.
— Що це — «зрозумілий код»?
Давид, 2-й курс:
— Код, який є зрозумілим не лише для його творця, а й для інших розробників.
Дмитро, 2й курс
— Читабельність, структурованість за принципами стайлгайдів та розуміння цього коду незалежно від рівня програміста.
Дмитро, 3-й курс:
— Зрозумілий код — це дотримання єдиного стилю коду та практик, використання відомих назв та паттернів, послідовність.
— Які відомі принципи написання коду вважаються необхідними для кожного програміста?
Давид, 2-й курс:
- Один з найголовніших та найвідоміших принципів – DRY (don't repeat yourself). Зменшення кількості повторюваного коду позитивно впливає на його зрозумілість.
Дмитро, 2-й курс:
— Найчастіше використовують: SOLID — п'ять базових принципів об'єктноорієнтованого програмування та дизайну; GRASP — набір шаблонів, що дозволяють розв'язувати проблеми розподілу обов'язків між різними класами; KISS — «Keep It Simple, Stupid», YAGNI — «You Aren't Going to Need It»; та, звичайно ж, DRY.
До речі, для тих, хто бажає розібратися у цих принципах можна порадити такі відомі книги, як «Чистий код» Роберта Мартіна та «Мистецтво автономного тестування» Роя Ошероува.
- Коментарі засмічують код чи необхідні?
Давид, 2й курс:
- Коментарі звичайно необхідні. Легше зрозуміти код, коли ти заздалегідь знаєш, що він робить. Непотрібно здогадуватися та вигадувати способи його використання.
Проте у коментарів є недолік: вони не можуть автоматично оновлюватися. Тому бажано писати коментар вже до готового коду, впевнившись заздалегідь, що надалі функціонал цього коду не буде змінюватися.
Також варто коментувати тільки головне, адже велика кількість пояснень лише заплутає людину.
Дмитро, 3й курс:
- На мою думку, треба писати код, який не треба коментувати. Є гарне відео на цю тему (https://youtu.be/Bf7vDBBOBUA). Приклад випадку, коли коментар потрібен – це пояснення складної формули та «магічних чисел».
— Потрібно шукати оптимальніше розв'язання проблеми чи краще дотримуватися прописаних вимог?
Дмитро, 2-й курс:
— Потрібно завжди дотримуватись заданих вимог, але в критичних ситуаціях, можна шукати оптимальне рішення, узгодивши його з керівництвом.
Дмитро, 3-й курс:
— Якщо є можливість запропонувати своє рішення — це завжди гарно, але сторона бізнесу у питанні завжди виграє і треба її використовувати як аргумент.
— Чи полегшує читання коду використання оголошення змінних: Auto/var та Explanatory variables ?
Давид, 2-й курс:
— Я майже завжди користуюсь «var» у своїй практиці. Це надає змогу не звертати зайвої уваги на тип змінної. А хвилюватися за тип змінної не варто. Правильно написаний код та правильне іменування цієї змінної й так дає логічне пояснення, що в ній зберігається.
Дмитро, 2-й курс:
— Я віддаю перевагу «auto/var», щоб компілятор сам виясняв, який тип даних нам потрібен.
Дмитро, 3-й курс:
— У мові програмування С++ в багатьох випадках використання «auto» дуже полегшує читання та написання коду.
— Синтаксичний цукор — спрощення чи нерозбірливість коду?
Нагадуємо, що за визначенням «Синтаксичний цукор (англ. syntactic sugar) — узагальнена назва, яка позначає доповнення синтаксису мови програмування, які не додають нових можливостей, а роблять використання мови програмування зручнішим для людини».
Давид, 2-й курс:
— В більшості випадків «синтаксичний цукор» є спрощенням коду. Проте є випадки, коли якусь незначну, і так спрощену дрібницю починають спрощувати. У такому разі код стане більш нерозбірливим. Особливо якщо цей «цукор» не увійшов у стандарти використання у коді, а більшість програмістів ще його не знає.
Дмитро, 2-й курс:
— Це дуже велике спрощення коду, бо розробникам не приходиться писати великі, однотипні куски коду.
Хоча ми й розуміємо, що кожна IT-компанія має свої правила для працівників, однак стажисту необхідно мати базові знання про принципи написання коду та вміти пристосовуватись до будь-яких вимог.
Тож, «пишіть професійно, зрозуміло і гарно кожен найменший кусочок коду», практика — наш найкращий помічник у цій справі.
Бажаємо усім нам успіхів!
Марія Дузь
