Назви - це найважливіше з усього, що є у програмуванні. Уявіть поганий код, де все перемішано і викликається невідомо звідки. Якщо при цьому всі назви будуть продумані, осмислені та означатимуть саме те, що вони роблять, то програміст, який читатиме код, усе зрозуміє. Чи цікавить вас тема Чистого коду? Діліться своєю думкою в коментарях чи варто продовжувати цю рубрику👇👇
Зустрічав таку ситуацію коли, на існуйочуму проекті, замовник захотів перейменувати розділ сайту. Розділ це сутність яка має свою модель, класи, методи які до неї відносяться, простір імен. Так ось, на фронтенді назву розділу замінили, а на бекенді залишилось як було. Після того як нові розробники заходили на проект були сильно здивовані що розділ який називається "Call" , на бекенді це Job.
Кожен має свій дискурс і гадає про свій варіант вмісту. Без пояснень тупо не обійтися. Як не намагайся. Людський розум достатньо унікальний, щоб обмежуватися прямо аж усіма порадами.
Дивлюся це відео і розумію наскільки айтішка різна. Я би сказав так: майже з усім погоджуюся, але треба пам'ятати, що в реальному житті неможливо завжди так писати, тому інколи треба покладатися на інтуїцію, досвід щоби зрозуміти яку назву дати
How it will be better according to a clean code? Is it possible to check a value that is going to be returned from a getter and throw an error inside a getter? like this: get pagination() { const result = this.shadowRoot?.querySelector('pagi-nation') as HTMLElement | undefined | null; if (!result) { throw newError("There isn't a pagination."); } } Is it a good idea? Or it will be better to check a value outside.
Не зрозумів, чому приставки Provider, Manager, Processor, Helper, Mapper та інші на -er не можна використовувати? Це якісь вигадки. DataProvider,. TransactionManager, ScanProcessor, HtmlHelper and so on..
Хотілось би побачити чи почути саме про еволюцію від асемблера до інкапсуляції і структуризації в ооп. Бо в асемблері немає функцій, немає лексем з використання адрес. (На кшталт & * *(*) )Натомість є певні інструкції типу lea ld push pop і тому подібне. Ньюб розуміє тільки те що на поверхні - гарна структуризація і атомарність (!) ооп, але не саму її суть. Тобто чому є private i public можифікатори
От для цього ші і створюють, бо як бачте людина має вміти читати😂😂 хоча з другого боку програміст має бачити паттерни, логічні послідовності і таке інше
Панове поправте мене. Чи варто прописувати в readme додаткову інформацію про функції які були використані при роботі на сайті. А тепер людською. Я на сайті додаю до корзини товар і при цьому задіяні 3 функції то чи потрібно прописувати так. Додавання товару > функція 1 > функція 2 > функція 3.(назви функцій використані для прикладу).
.....-*er "класи" - то скоріше процедури. Якщо в коді такого багато - то навіщо вам взагалі ОО-мова? Анемічну доменну модель (якщо коротко - це коли в вас по суті лиш get/set/equals/hc в класі сутності) можна й не на ОО писати. Може вам так навіть зручніше буде. Щодо рефакторингу назв методів - тут можна і трохи прагматичніше бути. Наприклад якщо метод - це частина *публічного API бібліотеки, що використовується багатьма різними проектами* - його краще не перейменовувати, а задеприкейтити. Відрефакторений код перенести в інший метод уже з правильним ім'ям а з старого депрекейтнутого методу - просто викликати новий. І так - не місспельте методи, особливо публічні. Бо самі наражаєте себе на це пекло з деприкацією. Щодо хитрих назв і використання реальних бізнес термінів - ця порада звучить як: "не працюйте на внутрішньому українському ринку". address - це ще й дієслово. Типу: we should address this issue. Хоча так - синонімом замінити можна. Але це вже йде в розріз з "мовою замовника", ubiquitous language, оце все.
А чи може програміст чи команда змусити змінити замовника термін, якщо нададуть йому повну документацію з новою реалізацією? Бо частіше за все, будучи не в темі, замовник сам місспелить усе, а потім пиляй йому франкенштейна намагаючись не втратити здоровий глузд.
@@bidanfullko1 Думаю для того щоб змусити замовника змінити щось, а особливо щось звичне, треба мати communication skills рівня віртуоз. Але з такими скілами у вас вже не замовники будуть, а одні лиш меценати та фанатики.
ну, наприклад вам треба класс, який завантажує якісь дані з зовнішнього ресурсу. Назвати його лоадером - це саме логічне, що може бути. Особливо смішно, що є навіть паттерни креатор, ітератор, декоратор...
@@yaroslavzhurba670 Не дивлячись на те, що вперше більшість людей бачить ці паттерни в книжці GoF, але по суті ООП інструменти для цього не потрібні. Для декоратора потрібне просто посилання на функцію/процедуру. Тобто цей паттерн легко використовується як в хаскелі так і в C. Щодо лоадера, ітератора - ви самі не бачите, що ви виродили об'єкт до однієї єдиної утілітарної функції. Навіщо вам в такому випадку інкапсуляція? Та й предметну область уявити таку, в котрій лоадер моделює реальний об'єкт, а не є просто частиною механізму імпліментації достатньо важко. Скоріше це буде щось типу storage.upload(resource.asStream()) Під креатором ви мали на увазі Builder чи AbstractFactory? Хоча все одно ці речі - просто утілітарні церемонії. Але тут хоча б інкапсуляція потрібна для першого і поліморфізм для другого. Iterator, pointer, controller - туди ж. Нічого з цього не моделює ніякий процес з реального світу, а існує виключно як церемонія. У кращому разі - як клей між змодельованою предметною областю і інфраструктурою. З іншого боку в реальному світі іноді навіть люди зводяться до утілітарної функції. Наприклад коли декоратор може не тільки щось прикрашати, виконуючи роботу, а ще й брати вихідні - то він скоріше підтип працівника (Employee). І тут вже почнеться колізія в іменуванні якщо назви GoF чи інших паттернів використовувати в назвах сутностей.
@@oleksandrsova4803 Лоаадер може багато чого лоадати, тому не одна функція. Стораж у лоадера як раз скоріше повинен бути філдом, інакше ваш стораж стане суперобжектом, та точно не буде відповідати стораджу. Інкапсуляція потрібна для лоадера, бо він інкапсулює сторадж та якісь параметри коннекшену. Та навіть якщо одна функція та ніякої інкапсуляції не потрібно, то що, увесь проєкт тепер робити процедурним? Ми працюємо з абстракціями, а абстракції на те і абстракції, що до реального світу відносяться умовно. Мені дійсно цікаво як буде виглядати ваш код без використання ітераторів. Ну, і робітник нехай і без er, але вочевидь теж від слова робити. програмування це взагалі клей між тим що бажає замовник та виконується девайсом.
@@SerhiiNemchynskyi навіть foobar в певному дискурсі може бути логічною назвою, все залежить від того, що робить і де знаходиться метод. І якщо коли читаєш код метод з назвою foobar() буде читатися найближче до англійської мови, то воно буде зватися foobar і ніхто не зможе суперечити цьому, бо це буде тупо логічно
8:30 - це має сенс в С. Там немає неймспейсів, тому якщо це файл, яких буде відповідати за TCP, всі функції будуть починатись з tcp_ (звичайно, що не всі юзають це правило, але зазвичай цим користуються, щоб не здублювати назву функції якогось іншого файлу) 12:21 - Охохохох, ну тут індустрія з вами б точно не погодилась. Он, в Git з master в main перейменували. Так само як і з інтерфейсом SPI - був Master і Slave, став Controller і Peripheral
До цього ж - хіба abort це нормальне завершення? Нормальне скоріше буде exit (якщо себе) чи terminate (якщо дочірній процес) - хоча, можливо, це локальні традиції всюди свої...
Ось до речі чому я вважаю Го дуже поганою мовою: там обробка помилок робиться через повертання фактично кортежу з функції який неможливо використати потім у виразі й тому там потрібно вводити локальній змінні до кожного виклику функції. У той час як у "нормальних" мовах програмування введення змінної - це осмислений крок, змінна має мати назву, логіку й сенс існування у Го змінні вводяться з нагоди й без. А оскільки змінних багато - то прямо у офіційних гайдах дозволено називати їх однією літерою.
Зазвичай саме це і вважається кіллер-фічею го, ледь не на рівні з горутинами - те, що помилку достатньо складно *не* опрацювати. Ну й змінна дійсно має мати сенс. Навіть якщо це якась проміжна сходинка - у бізнес процесі, що модулює цей код має бути для цієї сходинки назва.
@@oleksandrsova4803 Ця "кіллер-фіча" на фоні Rust де обробка помилок зроблена одночасно й більш зручно й більш надійно виглядає як "фігак-фігак та у продакшен". Але так, після явних обробок помилок які зазначаються у сигнатурі функції повертатися до exceptions не хочеться.
@@oleksandrsova4803 Явне повернення помилки, яке прописане у сигнатурі функції це добре. Але Але у тому ж Rust обробка помилок зроблена й більш зручно й більш надійно одночасно. У Го дизайн мови здається робили за принципом "фігак-фігак та у продакшен".
Пане Сергію, уточню, що init - це не "початковий" від initial, а від initialize - "ініціалізувати", тобто запустити операцію. Тому метод так називався. Ця назва часто зустрічається в таких випадках.
Тут мова не про операційні системи чи драйвери. Тут про ентерпрайз, тому такий контекст не читається за замовчуванням.. Але залежить від розробника. Взагалі цей досвід транслюється в такому ключі, наче не існує дебаггера, щоб відслідкувати виклики об'єктів.
ви об'єм цього коду уявляєте? Там дебажити до того виклика треба було напевно добу :) а коли розкидаєш бряк пойнти, то треба розуміти куди саме треба його поставити
взагалі веселять поради а-ля - ну ти просто почитай код або дебагинг нас спасе, передивись структуру каталогів :))) Одразу розумієш, що люди звичайного ентерпрайз застосунка не бачили. Наприклад саме цей (тільки ця частина) важив 300+ Мб вихідного коду
@@SerhiiNemchynskyi А що не витягувало тоді дебагінг коду? Спроможності заліза? Я розумію контекст(масштабності проекту), і приблизний час коли це було. Але так виходить, що вам тупо не доступний інструмент з ряду причин. Тоді вже треба було б як у всіляких бродилка - малювати карту пройдених об'єктів і класів.. бо це реально нереальний експіріенс - вичитувати в ручну увесь код по кожній сутності(один раз таке було). Програміст має шукати вихід із "дурдому". От я і шукаю... наприклад візуалізацією джерельного коду. Було б таке раніше, і вам би допомогло. Впевнений.
Prompt: You are a signor developer with more than twenty years of commercial development experience. Rewrite this code fragment strictly according to Clean Code rules. Не благодарите!
звісно вміє. Але якщо коду справді богато, то як тільки ви поставили плейсхолдер, то одразу кількість співпадінній зрастаєв разі. Я якщо їх було кілько сотен...
Назви - це найважливіше з усього, що є у програмуванні. Уявіть поганий код, де все перемішано і викликається невідомо звідки. Якщо при цьому всі назви будуть продумані, осмислені та означатимуть саме те, що вони роблять, то програміст, який читатиме код, усе зрозуміє.
Чи цікавить вас тема Чистого коду? Діліться своєю думкою в коментарях чи варто продовжувати цю рубрику👇👇
Просто супер, дякую за україномовний контент!
Зустрічав таку ситуацію коли, на існуйочуму проекті, замовник захотів перейменувати розділ сайту.
Розділ це сутність яка має свою модель, класи, методи які до неї відносяться, простір імен.
Так ось, на фронтенді назву розділу замінили, а на бекенді залишилось як було. Після того як нові розробники заходили на проект були сильно здивовані що розділ який називається "Call" , на бекенді це Job.
Дякую. Чудове відео!
Придумати назву - це найважче, особливо коли твій англійський рівня А2 зі словником 😁
@@EdwardNorthwind Ооо, розумію) Чат gpt це просто маст хев в такій ситуації
В моєму досвіді замовник дуже часто називав одні й ті самі речі різними словами.
Або різні речі одним словом?)
Або змінився менеджер і почав використовувати інші назви))
Треба використовувати найчастішу назву, інші ігнорувати
Щодо класу RUN і подібних геймдеви заперечать! ;))
Там це доводиться активно порушувати, бо це і є "бізнес логіка".
Дякую за пояснення. Чітко, коротко та зрозуміло.
Кожен має свій дискурс і гадає про свій варіант вмісту. Без пояснень тупо не обійтися. Як не намагайся. Людський розум достатньо унікальний, щоб обмежуватися прямо аж усіма порадами.
Чудова українська мова і український контент, дякую! ❤
Дякую, мені цікаво і корисно.
Ми дуже раді, що вам це відео було корисним. 😊
Об'єкт ініціалізується згідно даних з форми. Метод ініціалізації називається init. Я спантеличений? Ні.
це якщо дивитися з боку бека. я якщо дивитися з точки зору фронта - дуже дивно
Дуже добре все розклав, дякую 🙏🏽
😊
Дивлюся це відео і розумію наскільки айтішка різна. Я би сказав так: майже з усім погоджуюся, але треба пам'ятати, що в реальному житті неможливо завжди так писати, тому інколи треба покладатися на інтуїцію, досвід щоби зрозуміти яку назву дати
How it will be better according to a clean code?
Is it possible to check a value that is going to be returned from a getter and throw an error inside a getter? like this:
get pagination() {
const result = this.shadowRoot?.querySelector('pagi-nation') as HTMLElement | undefined | null;
if (!result) {
throw newError("There isn't a pagination.");
}
}
Is it a good idea? Or it will be better to check a value outside.
Ага))) Розкажи про клас Run розробникам Open AI, що так не можна називати, ото вони посміються)))
ну навіть серед відомих розробників не всі розуміються на клин код
Не зрозумів, чому приставки Provider, Manager, Processor, Helper, Mapper та інші на -er не можна використовувати? Це якісь вигадки.
DataProvider,. TransactionManager, ScanProcessor, HtmlHelper and so on..
тому що це непродумані назви і все. Зрозуміло, що вони роблять, але не зрозуміло, чим вони є
Дякую, люблю ваш контент, цікаво спостерігати як ви все впевненіше спілкуєтеся, чекаємо продовження)
Хотілось би побачити чи почути саме про еволюцію від асемблера до інкапсуляції і структуризації в ооп. Бо в асемблері немає функцій, немає лексем з використання адрес. (На кшталт & * *(*) )Натомість є певні інструкції типу lea ld push pop і тому подібне. Ньюб розуміє тільки те що на поверхні - гарна структуризація і атомарність (!) ооп, але не саму її суть. Тобто чому є private i public можифікатори
От для цього ші і створюють, бо як бачте людина має вміти читати😂😂 хоча з другого боку програміст має бачити паттерни, логічні послідовності і таке інше
Панове поправте мене. Чи варто прописувати в readme додаткову інформацію про функції які були використані при роботі на сайті.
А тепер людською. Я на сайті додаю до корзини товар і при цьому задіяні 3 функції то чи потрібно прописувати так.
Додавання товару > функція 1 > функція 2 > функція 3.(назви функцій використані для прикладу).
Працю в IT перший місяць, одна з найактуальніших тем - це назви і їх придумати)
От би круто було одразу показувати на прикладах на лайвкодінгу
Цікава і корисна рубрика, буди чекати на продовження❤
Дякую за крутезний контент та за українську мову!❤
Українська == вподобайка
Top
Клас!!!
.....-*er "класи" - то скоріше процедури. Якщо в коді такого багато - то навіщо вам взагалі ОО-мова? Анемічну доменну модель (якщо коротко - це коли в вас по суті лиш get/set/equals/hc в класі сутності) можна й не на ОО писати. Може вам так навіть зручніше буде.
Щодо рефакторингу назв методів - тут можна і трохи прагматичніше бути. Наприклад якщо метод - це частина *публічного API бібліотеки, що використовується багатьма різними проектами* - його краще не перейменовувати, а задеприкейтити. Відрефакторений код перенести в інший метод уже з правильним ім'ям а з старого депрекейтнутого методу - просто викликати новий. І так - не місспельте методи, особливо публічні. Бо самі наражаєте себе на це пекло з деприкацією.
Щодо хитрих назв і використання реальних бізнес термінів - ця порада звучить як: "не працюйте на внутрішньому українському ринку".
address - це ще й дієслово. Типу: we should address this issue. Хоча так - синонімом замінити можна. Але це вже йде в розріз з "мовою замовника", ubiquitous language, оце все.
А чи може програміст чи команда змусити змінити замовника термін, якщо нададуть йому повну документацію з новою реалізацією?
Бо частіше за все, будучи не в темі, замовник сам місспелить усе, а потім пиляй йому франкенштейна намагаючись не втратити здоровий глузд.
@@bidanfullko1 Думаю для того щоб змусити замовника змінити щось, а особливо щось звичне, треба мати communication skills рівня віртуоз. Але з такими скілами у вас вже не замовники будуть, а одні лиш меценати та фанатики.
ну, наприклад вам треба класс, який завантажує якісь дані з зовнішнього ресурсу. Назвати його лоадером - це саме логічне, що може бути. Особливо смішно, що є навіть паттерни креатор, ітератор, декоратор...
@@yaroslavzhurba670 Не дивлячись на те, що вперше більшість людей бачить ці паттерни в книжці GoF, але по суті ООП інструменти для цього не потрібні. Для декоратора потрібне просто посилання на функцію/процедуру. Тобто цей паттерн легко використовується як в хаскелі так і в C.
Щодо лоадера, ітератора - ви самі не бачите, що ви виродили об'єкт до однієї єдиної утілітарної функції. Навіщо вам в такому випадку інкапсуляція? Та й предметну область уявити таку, в котрій лоадер моделює реальний об'єкт, а не є просто частиною механізму імпліментації достатньо важко. Скоріше це буде щось типу storage.upload(resource.asStream())
Під креатором ви мали на увазі Builder чи AbstractFactory? Хоча все одно ці речі - просто утілітарні церемонії. Але тут хоча б інкапсуляція потрібна для першого і поліморфізм для другого.
Iterator, pointer, controller - туди ж. Нічого з цього не моделює ніякий процес з реального світу, а існує виключно як церемонія. У кращому разі - як клей між змодельованою предметною областю і інфраструктурою.
З іншого боку в реальному світі іноді навіть люди зводяться до утілітарної функції. Наприклад коли декоратор може не тільки щось прикрашати, виконуючи роботу, а ще й брати вихідні - то він скоріше підтип працівника (Employee). І тут вже почнеться колізія в іменуванні якщо назви GoF чи інших паттернів використовувати в назвах сутностей.
@@oleksandrsova4803
Лоаадер може багато чого лоадати, тому не одна функція. Стораж у лоадера як раз скоріше повинен бути філдом, інакше ваш стораж стане суперобжектом, та точно не буде відповідати стораджу. Інкапсуляція потрібна для лоадера, бо він інкапсулює сторадж та якісь параметри коннекшену. Та навіть якщо одна функція та ніякої інкапсуляції не потрібно, то що, увесь проєкт тепер робити процедурним?
Ми працюємо з абстракціями, а абстракції на те і абстракції, що до реального світу відносяться умовно. Мені дійсно цікаво як буде виглядати ваш код без використання ітераторів.
Ну, і робітник нехай і без er, але вочевидь теж від слова робити.
програмування це взагалі клей між тим що бажає замовник та виконується девайсом.
Або розкажи розробникам Laravel, що не можна називати components() назви методів. Вони ще більше будуть ржати.
ну це не робить це гарною назвою. фу так писати
@@SerhiiNemchynskyi навіть foobar в певному дискурсі може бути логічною назвою, все залежить від того, що робить і де знаходиться метод. І якщо коли читаєш код метод з назвою foobar() буде читатися найближче до англійської мови, то воно буде зватися foobar і ніхто не зможе суперечити цьому, бо це буде тупо логічно
8:30 - це має сенс в С. Там немає неймспейсів, тому якщо це файл, яких буде відповідати за TCP, всі функції будуть починатись з tcp_ (звичайно, що не всі юзають це правило, але зазвичай цим користуються, щоб не здублювати назву функції якогось іншого файлу)
12:21 - Охохохох, ну тут індустрія з вами б точно не погодилась. Он, в Git з master в main перейменували. Так само як і з інтерфейсом SPI - був Master і Slave, став Controller і Peripheral
1. С - не ООП мова, так що клин код до неї не зовсім відноситься :)
2. Так. знаю це... і це сумно :)
До цього ж - хіба abort це нормальне завершення? Нормальне скоріше буде exit (якщо себе) чи terminate (якщо дочірній процес) - хоча, можливо, це локальні традиції всюди свої...
Дякую за пояснення, пригодиться
Ось до речі чому я вважаю Го дуже поганою мовою: там обробка помилок робиться через повертання фактично кортежу з функції який неможливо використати потім у виразі й тому там потрібно вводити локальній змінні до кожного виклику функції. У той час як у "нормальних" мовах програмування введення змінної - це осмислений крок, змінна має мати назву, логіку й сенс існування у Го змінні вводяться з нагоди й без. А оскільки змінних багато - то прямо у офіційних гайдах дозволено називати їх однією літерою.
Зазвичай саме це і вважається кіллер-фічею го, ледь не на рівні з горутинами - те, що помилку достатньо складно *не* опрацювати.
Ну й змінна дійсно має мати сенс. Навіть якщо це якась проміжна сходинка - у бізнес процесі, що модулює цей код має бути для цієї сходинки назва.
@@oleksandrsova4803 Ця "кіллер-фіча" на фоні Rust де обробка помилок зроблена одночасно й більш зручно й більш надійно виглядає як "фігак-фігак та у продакшен". Але так, після явних обробок помилок які зазначаються у сигнатурі функції повертатися до exceptions не хочеться.
@@oleksandrsova4803 Явне повернення помилки, яке прописане у сигнатурі функції це добре. Але Але у тому ж Rust обробка помилок зроблена й більш зручно й більш надійно одночасно. У Го дизайн мови здається робили за принципом "фігак-фігак та у продакшен".
++
Пане Сергію, уточню, що init - це не "початковий" від initial, а від initialize - "ініціалізувати", тобто запустити операцію. Тому метод так називався. Ця назва часто зустрічається в таких випадках.
Тут мова не про операційні системи чи драйвери.
Тут про ентерпрайз, тому такий контекст не читається за замовчуванням.. Але залежить від розробника. Взагалі цей досвід транслюється в такому ключі, наче не існує дебаггера, щоб відслідкувати виклики об'єктів.
@@bidanfullko1 ну, на девайсі дебагер не запустиш, треба логи писати
ви об'єм цього коду уявляєте? Там дебажити до того виклика треба було напевно добу :) а коли розкидаєш бряк пойнти, то треба розуміти куди саме треба його поставити
взагалі веселять поради а-ля - ну ти просто почитай код або дебагинг нас спасе, передивись структуру каталогів :))) Одразу розумієш, що люди звичайного ентерпрайз застосунка не бачили. Наприклад саме цей (тільки ця частина) важив 300+ Мб вихідного коду
@@SerhiiNemchynskyi А що не витягувало тоді дебагінг коду? Спроможності заліза? Я розумію контекст(масштабності проекту), і приблизний час коли це було.
Але так виходить, що вам тупо не доступний інструмент з ряду причин.
Тоді вже треба було б як у всіляких бродилка - малювати карту пройдених об'єктів і класів.. бо це реально нереальний експіріенс - вичитувати в ручну увесь код по кожній сутності(один раз таке було).
Програміст має шукати вихід із "дурдому". От я і шукаю... наприклад візуалізацією джерельного коду. Було б таке раніше, і вам би допомогло. Впевнений.
Prompt: You are a signor developer with more than twenty years of commercial development experience. Rewrite this code fragment strictly according to Clean Code rules.
Не благодарите!
ахахаха. Навряд допоможе :)
відеоНаОчахНародилося()
🤩
не понятно, ваши ide не умеют искать середину названия? У меня даюе на андроиде иде ищет с пропувкоом букв
Досвід старої школи)
звісно вміє. Але якщо коду справді богато, то як тільки ви поставили плейсхолдер, то одразу кількість співпадінній зрастаєв разі. Я якщо їх було кілько сотен...
Thanks for this video. The example with the init method at the end of the collection information was very useful. Have a nice day colleague !.