Є талмут, яким в цілому і вбити можна, пана Стіва МакКоннела 'Code complete' . має багато невеличких порад, в тому числі про читаймість.. але там є в преамбулі як треба іі читати: не глава за главою як художню, а використовуючи як збірку рецептів в якій є перелінковка певна.
Я думаю багато хто проходив на власній шкурі гадання та інтуїтивні зміни щоб шось полагодити.. просто мали брак знань чи то досвіду щоб трейсити, дебажити, профілювати, моніторити, тестити і якісними характеристиками та цифрами підтверджувати своі 'відчуття'. Але бачу по багатьох кого менторів, що як не питай, як не підказуй, як не кажи тупо що і як зробити - люди мають цей розрив між теорією і практикою подолати власноруч набивши власні гулі..) А ще є оптимізаціі, які тупо треба і необхідно покривати коментарями що є дурним тоном у чистому коді.
В цьому плані треба не забувати що айтішне комьюніті складається в тому числі з закомплексованих задротів.) тому посил на бан в коментарях дійсно правильний, багато суперечок, з особистого досвіду, виникає через нерозуміння іншоі сторони що таке науковий диспут. контраверсіні питання при цьому не тільки можуть виникати, а мусять, бо сумнів в тій чи іншій тезі та твержєенні принесе або нічого, або тільки знайде недолік який треба врахувати. І це навіть критикою важко назвати, але більшість бачить чомусь в цьому особисту образу... І бурно реагує.. тож дякую, спільноту треба виховувати в цьому плані, абсолютно згоден.
о саме читаю її, обговорювані частини мені теж здавались дивними але так як обговорити не було з ким було заключено шо я просто дебіл і не розумію абстракцій але читати і перечитувати потрібно особливо якщо працюєш не на біг брата і вхідний рівень на порядки менший і іноді приходиться пояснювати і битися за банальні речі як от видалення старого коду а не коментування його, то пан Роб розширює поле аргументів на вашу користь
Теж не дочитав до кінця, і не приділив стільки уваги прикладам, а вони і справді жахливі, в цілому із холіваром погоджуюсь. Мені подобається функціональне мислення хлопців. Не забувайте, що дядько Боб якраз і адвокатував до функціонального програмування більшу частину своєї кар'єри) P.S. Як гарно мати паттерн матчинг у голові функції і забути (ну майже) про if/else стейтменти (erlang, Elixir).
З зіставленнями (паттерн метчингом) в Еліксирі теж чимало способів вистрілити собі в ногу. Наприклад класика це натрапляти на unmatched value отримуючи :ok там де патерн очікує лише {:ok, value} чи {:error, msg}, або ж навпаки.
@@rkiyanchuk Звичайно, що у всього є мінуси. Але конкретно у випадку із великою (чи навіть 3) бранчами логіки, як на мене, набагато зрозуміліше бачити декларацію функції три рази, ані ж if else elsif.
unmatched value у першому випадку (якщо це матч локальної змінної) видасть MatchError, а у випадку із функціями FunctionClauseError, так що "нога" повинна залишитись цілою якщо звісно код покритий тестами. Але і в проді такі баги легко виправляти.
@@rkiyanchuk До того ж, "вистрелити" вийде тільки якщо код не протестований) Але навіть у цьому випадку такі баги легко ловляться і швидко виправляються, тому що коли вони відбуваються у рантаймі - знайти їх по помилці дуже легко.
Дякую за подкаст! Наче взяли тай сформували ті думки які виникали у мене при прочитанні Чистого Коду
Що цікаво, дочитати я так і не дочитав 🤪
Є талмут, яким в цілому і вбити можна, пана Стіва МакКоннела 'Code complete' .
має багато невеличких порад, в тому числі про читаймість.. але там є в преамбулі як треба іі читати: не глава за главою як художню, а використовуючи як збірку рецептів в якій є перелінковка певна.
"я відчуваю, коли треба міняти" - вайби інструктора юа
😁
Відчувай!
Я думаю багато хто проходив на власній шкурі гадання та інтуїтивні зміни щоб шось полагодити..
просто мали брак знань чи то досвіду щоб трейсити, дебажити, профілювати, моніторити, тестити і якісними характеристиками та цифрами підтверджувати своі 'відчуття'. Але бачу по багатьох кого менторів, що як не питай, як не підказуй, як не кажи тупо що і як зробити - люди мають цей розрив між теорією і практикою подолати власноруч набивши власні гулі..)
А ще є оптимізаціі, які тупо треба і необхідно покривати коментарями що є дурним тоном у чистому коді.
Вітання пану Руслану 🥳
В цьому плані треба не забувати що айтішне комьюніті складається в тому числі з закомплексованих задротів.) тому посил на бан в коментарях дійсно правильний, багато суперечок, з особистого досвіду, виникає через нерозуміння іншоі сторони що таке науковий диспут. контраверсіні питання при цьому не тільки можуть виникати, а мусять, бо сумнів в тій чи іншій тезі та твержєенні принесе або нічого, або тільки знайде недолік який треба врахувати. І це навіть критикою важко назвати, але більшість бачить чомусь в цьому особисту образу... І бурно реагує.. тож дякую, спільноту треба виховувати в цьому плані, абсолютно згоден.
о саме читаю її, обговорювані частини мені теж здавались дивними але так як обговорити не було з ким було заключено шо я просто дебіл і не розумію абстракцій
але читати і перечитувати потрібно особливо якщо працюєш не на біг брата і вхідний рівень на порядки менший і іноді приходиться пояснювати і битися за банальні речі як от видалення старого коду а не коментування його, то пан Роб розширює поле аргументів на вашу користь
Вітання пану Руслану!
Щиро дякую!
Теж не дочитав до кінця, і не приділив стільки уваги прикладам, а вони і справді жахливі, в цілому із холіваром погоджуюсь. Мені подобається функціональне мислення хлопців. Не забувайте, що дядько Боб якраз і адвокатував до функціонального програмування більшу частину своєї кар'єри)
P.S. Як гарно мати паттерн матчинг у голові функції і забути (ну майже) про if/else стейтменти (erlang, Elixir).
З зіставленнями (паттерн метчингом) в Еліксирі теж чимало способів вистрілити собі в ногу. Наприклад класика це натрапляти на unmatched value отримуючи :ok там де патерн очікує лише {:ok, value} чи {:error, msg}, або ж навпаки.
@@rkiyanchuk Звичайно, що у всього є мінуси. Але конкретно у випадку із великою (чи навіть 3) бранчами логіки, як на мене, набагато зрозуміліше бачити декларацію функції три рази, ані ж if else elsif.
unmatched value у першому випадку (якщо це матч локальної змінної) видасть MatchError, а у випадку із функціями FunctionClauseError, так що "нога" повинна залишитись цілою якщо звісно код покритий тестами. Але і в проді такі баги легко виправляти.
@@rkiyanchuk До того ж, "вистрелити" вийде тільки якщо код не протестований) Але навіть у цьому випадку такі баги легко ловляться і швидко виправляються, тому що коли вони відбуваються у рантаймі - знайти їх по помилці дуже легко.
@@omaslo Інколи не дуже легко, коли там pipeline з 7-10 рівнями вкладеності 😅