🇺🇦 Технічно-популярний подкаст «Шо по коду?» про програмну інженерію та технології. Ділимось досвідом, розповідаємо байки та обговорюємо цікаві теми та новини інформаційного світу.
Ведучі:
‣ пан Ігор → twitter.com/ikalnytskyi ‣ пан Роман → twitter.com/rpodoliaka ‣ пан Руслан → twitter.com/rkiyanchuk
Є талмут, яким в цілому і вбити можна, пана Стіва МакКоннела 'Code complete' . має багато невеличких порад, в тому числі про читаймість.. але там є в преамбулі як треба іі читати: не глава за главою як художню, а використовуючи як збірку рецептів в якій є перелінковка певна.
В цьому плані треба не забувати що айтішне комьюніті складається в тому числі з закомплексованих задротів.) тому посил на бан в коментарях дійсно правильний, багато суперечок, з особистого досвіду, виникає через нерозуміння іншоі сторони що таке науковий диспут. контраверсіні питання при цьому не тільки можуть виникати, а мусять, бо сумнів в тій чи іншій тезі та твержєенні принесе або нічого, або тільки знайде недолік який треба врахувати. І це навіть критикою важко назвати, але більшість бачить чомусь в цьому особисту образу... І бурно реагує.. тож дякую, спільноту треба виховувати в цьому плані, абсолютно згоден.
о саме читаю її, обговорювані частини мені теж здавались дивними але так як обговорити не було з ким було заключено шо я просто дебіл і не розумію абстракцій але читати і перечитувати потрібно особливо якщо працюєш не на біг брата і вхідний рівень на порядки менший і іноді приходиться пояснювати і битися за банальні речі як от видалення старого коду а не коментування його, то пан Роб розширює поле аргументів на вашу користь
UPDATE: все ж таки важливо самому читати книжки! ;) 35:02 -- в книжці не >add<FirstName, а -- >addr<FirstName, тобто не контекст операції, а контекст структури даних. Суть запропонованого дядьком Бобом (та Tim-ом Ottinger-ом) рефакторингу в першому прикладі саме і полягає в тому, що вони виносять змінні number, verb та pluralModifier разом із логікою побудови самого повідомлення в окремий клас GuessStatisticsMessage, а метод printGuessStatistics перероблють відповідним чином: private void printGuessStatistics(char candidate, int count) { String guessMessage = new GuessStatisticsMessage().make(candidate, count); print(guessMessage); } Якщо читати книжку, то це виглядає доволі логічним, ведучі самі ж пропонували зробити структуру -- от її і зробили. _____________________________________________________________________________ Мені здається, що у дядька Боба просто приклад не дуже вдало підібраний. В першому прикладі з книжки маємо три блокі обчислень, які пов'язані з контектом обчислення тільки через умову. Реафкторінг нам пропонує додати ще один зв'язок із контекстом через ім'я функції. А те, що це довелося робити через мутабільний стан екземпляру класу -- то це вже специфіка Java. Тобто, якщо відкинути "другорядні", з т.з. розділу Книги, претензії щодо: - складності розрахунку (обчислюємо частини повідомлення, а потім його будуємо, в очевидь більш правильно одразу будувати) - мутабільності стану -- це спеціфіка Java - порушення розділення відповідальності (не виводимо в консоль результат) то буде виглядати, логічно. Той самий приклад на TS виглядав би якось так: { // before refactoring const guessStatisticsMessage = (candidate: string, count: number): string => count === 0 ? `There is no ${candidate}` : count === 1 ? `There is 1 ${candidate}` : `There are ${count} ${candidate}s`; } { // after refactoring const noLetterMessage = (candidate: string) => `There is no ${candidate}`; const singleLetterMessage = (candidate: string) => `There is 1 ${candidate}`; const manyLettersMessage = (candidate: string, count: number) => `There are ${count} ${candidate}s`; const guessStatisticsMessage = (candidate: string, count: number): string => count === 0 ? noLetterMessage(candidate) : count === 1 ? singleLetterMessage(candidate) : manyLettersMessage(candidate, count); } чи мав би сенс такий рефакторінг? А чому б ні? Особливо, якщо припустити, що треба додати категорію часу ) Але як би там не було, ви дуже класний висновок зробили: краще читати вчасно ;)
Я думаю багато хто проходив на власній шкурі гадання та інтуїтивні зміни щоб шось полагодити.. просто мали брак знань чи то досвіду щоб трейсити, дебажити, профілювати, моніторити, тестити і якісними характеристиками та цифрами підтверджувати своі 'відчуття'. Але бачу по багатьох кого менторів, що як не питай, як не підказуй, як не кажи тупо що і як зробити - люди мають цей розрив між теорією і практикою подолати власноруч набивши власні гулі..) А ще є оптимізаціі, які тупо треба і необхідно покривати коментарями що є дурним тоном у чистому коді.
Теж не дочитав до кінця, і не приділив стільки уваги прикладам, а вони і справді жахливі, в цілому із холіваром погоджуюсь. Мені подобається функціональне мислення хлопців. Не забувайте, що дядько Боб якраз і адвокатував до функціонального програмування більшу частину своєї кар'єри) P.S. Як гарно мати паттерн матчинг у голові функції і забути (ну майже) про if/else стейтменти (erlang, Elixir).
З зіставленнями (паттерн метчингом) в Еліксирі теж чимало способів вистрілити собі в ногу. Наприклад класика це натрапляти на unmatched value отримуючи :ok там де патерн очікує лише {:ok, value} чи {:error, msg}, або ж навпаки.
@@rkiyanchuk Звичайно, що у всього є мінуси. Але конкретно у випадку із великою (чи навіть 3) бранчами логіки, як на мене, набагато зрозуміліше бачити декларацію функції три рази, ані ж if else elsif.
unmatched value у першому випадку (якщо це матч локальної змінної) видасть MatchError, а у випадку із функціями FunctionClauseError, так що "нога" повинна залишитись цілою якщо звісно код покритий тестами. Але і в проді такі баги легко виправляти.
@@rkiyanchuk До того ж, "вистрелити" вийде тільки якщо код не протестований) Але навіть у цьому випадку такі баги легко ловляться і швидко виправляються, тому що коли вони відбуваються у рантаймі - знайти їх по помилці дуже легко.
коментар про Італію і сири... цей пан схоже взагалі не усвідомлює, в якій реальності живуть люди і на яку аудиторію він вєщає. Краще зам"ютитись - від цього подкаст тільки виграє. Бо ці постійні перебивання і думки ні про що - ну таке собі, замало знань, порівняно з іншими учасниками подкасту. Ігорю і Роману величезний лайк. Дякую, що ділитесь досвідом, завжди з задоволенням дивлюся випуски, де ви вдвох, чи то розмовні, чи то парне програмування. Гість теж красавчик, скромно, все по ділу 👍
Ви якщо вже використовуєте дурнуваті правила з "Правопису 2019", то може тоді вже і базові правила української мови треба також не забувати? До прикладу: питання не задають, а ставлять. У вас така шалена кількість банальних помилок, проте "в етері". Як в анекдоті: "або хрестик зніми, або труси надягни".
я не маковод, лише лінуксоїд =) пане Ігор, без сумніву робіть обов'язково відос по тому як загалом весь лінукс працює, буде і самому подивитися корисно, та й іншим поширити
Цікавий подкаст, дякую! Спробую зробити чей челендж на С++. Послухав ваші інші подкасти і помітив, що "покажчик" трохи ріже вухо, здаєтьбся по значенню, більше підходить "вказівник". Покажчик - це щось, що показує, наприклад, якусь цифру (покажчик оборотоів двигуна, покажчик температури), а вказівник - це стрілка, яка вказує на щось (на адресу в пам'яті).
Дуже цікаво, дякую. Особливо хочу зробити акцент на словах пана Ігоря, що треба, щоб компілятор вимагав, а не optional. Бо зараз на проекті, де тільки у одному з 40 пакетів є 200+ варнінгів. Трошки неприкольно фіксить сегфолти потім. Запропонував їм переписати на Раст, а вони відмовились чомусь😁
Mono для запуску C# вже давно не потрібен. Наприклад, ми розробляємо свої сервіси на вінді, а хостимо в AWS в докері під лінуксом, в продакшені. Інколи я дістаю мак і працюю на ньому використовуючи Rider (або VS Code).
Про MS SQL Server. Так як це сервер в якому можна виконувати декларативний код, то у нього є доволі складна система, парсер, аналізатор, оптимізатори для вибір стратегії реалізації запиту, які індекси використовувати, в якому порядку джоінити, яким методом джоінити. В процесі експлуатації виявляється що іноді сервер неоптимально вираховує вибір індекса або метода джоіна, або якась інша оптимізація робить погано в якомусь іншому кейсі. з одного боку частину таких перемикачів можна винести в конфігурацію, але деякі перемикачі функціональності повинні працювати в скопі не всіх процесів всього сервера, а в контексті однієї сесії, чи навіть конкретного запита одного процеса. деяку зміну поведінки дозволяють робити звичайним непривелегійованим користувачам, і в ms sql це set-інструкції, наприклад зміна рівня ізоляції транзакції, або зміна поведінки роботи з NULL, або trailing spaces, форматування чисел та дат. є перемикачі які вмикають-вимикають функціональність в контексті бази, це робиться alter database .. set somefunc = ON. Є аналогічні перемикачі рівня таблиці або індекса - наприклад стиснення даних. Чи рівень запитів - хінти, як то вказати який саме індекс потрібно використати, або який метод джоіна використати. але є і такі хінти як: FORCE_LEGACY_CARDINALITY_ESTIMATION . яка кричуща назва. але справжня система схованих від користувачив перемикачів це трейсфлаги learn.microsoft.com/en-us/sql/t-sql/database-console-commands/dbcc-traceon-trace-flags-transact-sql. і часто це зміна поведінки або вимкнення оптимізації. Як приклад флагу 13116 який Disables the fix for bug 13685819.
