Догматизм це дуже небезпечна річь, якак зустрічається дуже часто, та і по суті догматизм це пряма дорога до зневажливого ставлення будьяких інших ідеї які не співпадают з тим що кажуть, або пишуть лідери думок.
Про якість та те, що якісний код писати швидше і дешевше - це одна із моїх ідей та принципів, котрими я теж керуюсь. Дуже, дуже приємно почути цю думку у вашому відео! Про догматизм та паттерни згадується, що років 12-15 тому на конференціях часто говорили, що Singleton - це антипаттерн. А тепер уявімо DI в OOP та його швидкодію без Singleton. Чи буде це добре працювати і чи має сенс? А можна потренуватись писати stateless код, трохи послухати про функціональні підходи, розділити обробку даних та їх зберігання - і досить швидко вийти на новий для себе рівень.
привіт! цікаве відео, сподіваюсь що на каналі буде ще багато нових. була б цікава твоя думка про різницю між сіньйором, мідлом і джуном, які умови потрібно виконати для себе щоб "підняти ранг" :) так, різні компанії у вакансіях окреслюють типу сіньйор = досвід 5+ років, але ж ми знаємо що пишуть одне, а насправді очікування можуть відрізнятись. а десь 2 роки роботи більш продуктивні і розвиваючі, ніж 5 років в іншій. Тому цікаво, як ти посвячюєш дева в сіньйори)
Дякую! Це цікава тема. Насправді, в тому самому Гуглі не вимагається, щоб розробник ріс вище мідла. Всі мідли, яких я знаю персонально, це 8-12 років досвіду. Сеніор з України з 5 років досвіду часом попадає в Гугл на позицію джуна, але буває, що на джуна потрапляють й після університету. Тобто кількість років досвіду це не те, що забезпечує "ранг"
@@AboutProgramming от і цікаво, як розуміти де ти є і до чого реально/посильно прагнути. Як є у вивченні мов, іспити на рівні В2/С1, тільки для розробників, були б круті) хоча може такі і є, але я про них не чула
@@viktoriia809 Часто в великих компаніях є engineering ladder з описом всіх вимог до кожного рівня. Але зазвичай логіка проста. Чим вищий рівень, тим більший твій імпакт очікується на проект й ти отримуєш задачі з більшим ступенем невизначеності
І догматизм і говнокод це про інтелектуальну лінь. Особисто я можу кілька разів переписати код, поки він мені почне подобатися. Але це все робота головою. Те саме і про догматизм, зазвичай догматики не замислюються чому так. Тому я би узагальнив - треба вмикати голову, робити це постійно і свідомо. :) Але тих хто так роблять зазвичай дуже мало в соціумі взагалі :(
Гарне узагальнення. В цілому згоден. Як кажуть: "в будь-який незрозумілій ситуації - думай". Я спроектував досить багато систем й є багато схожих, але кожен раз доводиться багато чого продумувати по новому :)
Дякую за супер цікавий контент 👍🏻 У мене питання про зіпсутих програмістів. Я багато цустрічав людей які вже мають багато років досвіду (іноді 20+) але відчуття запаху у них відсутнє 😂😂😂 і при цьому вони іноді займали такі самі позиції як і я (у мене майже 10) а іноді і вищі. Можливо вони ніколи не працювали на великих проектах, але мені бувало складно пояснити переваги базових best концепцій (тестування, single responsibility, мовчу про DDD) бо "код і так функціонує" і "який сенс всьго цього оверхеду". Я прийшов до висновку, що можливо вони і праві і для малих проектів це ок, мати низьку якість. Немає сенсу спорічатись з людьми які не хочуть навчатися... Я б дуже хотів працювати з людьми які знають більше (DDD гарний індикатор доречі). Думаєш це можливо тільки в big tech?
Точно не тільки big tech. Відносно питання явного розміру має бути проект, щоб варто було вкладатися в якісь, то зазвичай через пару тижнів говнокоду швидкість сильно уповільнюється. Є стаття цікава на цю тему martinfowler.com/articles/is-quality-worth-cost.html
Я почав читати дуже цікаву книгу "Выход из кризиса" Деминг Эдвардс. Він ставе на перше місце якість. Кажуть що він той самий хто зробив з Японії чудо. Не гроші змінили Японію, а зміна процесів. Ось я хочу перекласти, доказати цю ідею у програмуванні. Дати визначення говнокоду, виміряти говнокод у "попугах".
Є різні метрики складності/якості коду типу McCabe complexity та інші. Й вони можуть показати проблеми з кодом, але не можуть довести, що код якісний (окрім того проблема якості може бути в ідельно написаному коді, який просто не оперує тими самими сутностями, що й бізнес). Це як з тестуванням. Тестуванням можна довести наявність багів, але не можна довести іх відсутність. Й є схожа історія з продуктивністю розробника (martinfowler.com/bliki/CannotMeasureProductivity.html). Тут основна проблема, що як міряєш, то так й пишуть :) Але є ряд показників, який дозволяє оцінити якість коду через якість процесів. Взагалі, цікаво було б побачити якийсь робочий підхід, задача досить складна. За книгу дякую, подивлюся - теж цікаво
@@eolit1o чомусь ютуб вирішив, що коментар схожий на спам й я його тільки зараз побачив. Так, є телеграм канал - t.me/jabascript (в описі каналу є лінк на мій телеграм теж)
Я соло програміст фріланс фул стек 12 років. Php js зараз react більше. Жодної книжки не прочитав. Рейт 100$. Щоб ви могли порекомендувати мені щоб писати кращій код? Топ 1 книжка по проектуванню?
Я не знаю, як ви пишите код, то тут мені складно порекомендувати, що саме треба покращити. Ну й мабуть щось читали за цей час, просто не в форматів книг. На каналі робив одне відео про книги - ua-cam.com/video/p7awmGY9yus/v-deo.htmlsi=UFKe03u0T8h_1ytP Також після DDD Еванса є ще "Implementing Domain-Driven Design" Вернона - доповнює Еванса різними практичним підходами (можно й тільки її). Просто обирайте ту одну, яка виглядає найбільш цікаво й по темі якої найменше знаєте
@@AboutProgramming дякую. Код пишу не дуже, але ті архітектури яки я бачив, мені не подобаються. Думаю що не існує ідеальної. Але краще знати пару для різних випадків. І краще знати гарно пару аніж трішки багато різних. Ви казали що є укорочена версія DDD? Як вона називається? А ще я так і не зрозумів як вивчити глибше то, чим ми вже користуємось, https, linux, node, chrome ітд. І я о думаю, чи не буде таке поглиблення шкідливе, так як технології міняються, і через деякий час те шо ти поглиблювався і зробив висновок що краще писати Б ніж А вже не актуально з 156.2 версії Хрома. Чи не вважаєте ви це розпилюванням уваги?
Є непогане самарі www.infoq.com/minibooks/domain-driven-design-quickly/ й DDD Distilled www.amazon.com/Domain-Driven-Design-Distilled-Vaughn-Vernon/dp/0134434420
Таке враження, що це якась особлива ситуація :) Практично всі проекти запускаються в умовах обмежений ресурсів, навіть в Google. Я запустив більше 50-ти проектів й для стартапів й для великих компаній типу Mercedes/Uber/Pfizer й всі хочуть дива. Відносно якості, то в розробці софта часто якісний код це дешевше й швидше, якщо проект триває більше місяця. Класна стаття була у Фаулера - martinfowler.com/articles/is-quality-worth-cost.html Окрім того, дуже допомогає стандартизація процессів, кодовой бази, архітектури. Робив колись доповідь про стандартну архітектуру - ua-cam.com/video/TjvIEgBCxZo/v-deo.html
Як Ти не гориш? Як грамотно будувати свій графік, щоб знову не попасти в капкан. Наче овертаймів більше нема, наче не стартап, наче є 4 рази зал на тиждень, англійська , але все одно я знову попав в цей стан. Ти його не відчуваєш і не можеш детектувати, а потім бац і він прийшов. Треба якось перемикати мозок...
Насправді, часу постійно на все не вистачає. Й часто графік ломається, особливо в умовах війни. Тому часто доводиться змінювати підходи до роботи. Поки спорт нормально не можу повернути в графік, але це є в планах. Назвати себе експертом в тайм менеджменті не можу)
Ох! Аж попустило. 13 років в девелопменті. Наче сходив до психотерапевта. Незважаючи на те, що я не у веб, а у ембедед С/С++ Дякую! Про моки взагалі. Прошу відео, як не зійти з розуму на проекті з певним достатньо великим досвідом не бажаючи ну ніяк йти у менелжмент роками. Залишаючись людиною, що просто любить писати код
Мені подобається, що в Гуглі менеджмент й інженірінг це 2 окремим вертикалі й можна зростати як individual contributor (IC) не переключаючись в менеджмент. Але немає навіть вимоги, щоб зростати як IC вище L4. Але відносно IC L6+ (staff engineering), то читаю зараз www.amazon.com/Staff-Engineers-Path-Individual-Contributors/dp/1098118731
Все вірно сказано. Важко дається 3-ій пункт. Багато знаю колег хто зневажливо відноситься до інших. Якщо буде можливість і вам буде цікаво, можливо зробити відео як ви дизайните застосунки, можливо мікросервіси. Цікаво дізнатись які техніки solution design ви приміняєте наприклад для комунікації декількох ізольованих компонент. І можна наприклад погратися з типами ізоляції щоб було зрозуміло що для вас є чинниками зміни транспорту комунікації між компонентами. Також було б цікаво більш глибше зануритись у типи даних. Можливо у вас є приклади з життя де можна застосовувати якісь екзотичні структури даних. Дякую за Вашу роботу! Цікаво дивитись!
Пропоную відео про способи покращення якості коду і де шукати якісний код для прикладів або про книжки чи статті, які обовʼязково треба прочитати та зрозуміти
Знаете в тій чи іншій мірі ми всі пишемо говнокод, далекий від ідеалу. Тут на думку спадає реакт роутер коли кожну версію автори казали поперядня то була фігня, а ось теперь ми все зрозуміли познали дзен і ось тепер... потім проходив час і все повторювалося знову. Я до того що майже нереально написати не гвонокод з першого разу, а бо хочаб те що через рік не буде так виглядати для самого автора. Короче дуже тяжко бути перфукціоністом в програмуванні покою не буде ніколи )))
Насправді, це вже про перфекціонизм. Я би не став ділити код на 2 групи - або "ідеальний" , або "говнокод". Є ще багато гарного коду, який існує посередені й не є говнокодом. Й важливо не плутати технічний борг й говонокод - це теж про різне
Акціонери та інвестори завжди хочуть, щоб бізнес приносив гроші. Тобто ціль - робити продукти більш успішними. Відносно захоплення інтернету, то тут скоріше спостерігаю навпаки великі інвестиції для покращення інтернету, його безпеки, але ніяк не намагання взяти інтернет під контроль
Було б круто побачити щось типу лайв-сессії, на якій Ви будуєте щось типу туду-листа (може с авторизацією для невеликого ускладнення) з усіма етапами розробки. Тобто спочатку будуєте архітектуру -- system design, потім етап побудови інфраструктури, реалізація з тестами -- тут цікаво що саме ви б тестували, а що можна пропустити, ну і деплой з тестуванням.
Я колись хотів зробити курс по розробці й показати всі аспекти проектування на прикладі якоїсь системи. Можливо частина курсу попаде на канал просто в форматі окремих відео
Щодо "чи буває швидко-дешево-якісно"? За своє життя жодного разу не бачив такого. Якщо розглядати "дешево", з точки зору подальшої підтримки, то ну може.
Так, передбачається, що програма буде розвиватися певний час. Згадав фразу "Якщо ви думаєте, що гарна архітектура це дорого, то спробуйте погану"). В цілому, є певна межа, з якої внутрішня якість починає себе окуповувати. Є дуже гарна стаття у Фаулера на цю тему - martinfowler.com/articles/is-quality-worth-cost.html яка каже, що внутрішня якість продукту починає себе окуповувати не через місяці, а через тижні. Багато разів бачів, коли низька якість призводили до проблем й значного зростання строків імплементації. Тобто, я не можу сказати, що низькоякісний код це дешевше підтримувати й швидше додавати нові фічі. Скоріше навпаки, якісний код призводить до більше швидкого додавання нових фічей й більше дешевої підтримки
Дякую за відео❤! Іноді галєри спеціально пишуть поганий код щоб його було важко підтримувати час розробки більше отже більше грошей можна стягнути з замовника і навіть якщо він захоче піти то інші команди не зможуть продовжити нормально розробку💩
насправді, за 3 роки, які я працюю з AI я втратив здатність писати придатний до підтримки код це, насамперед, пов'язано з тим, що безліч ідей треба дуже швидко прототипувати. Це біль.
Але тут виріс скілл швидкого прототипування, що якраз й корисно для сфери AI. Й якщо є відчуття того, що певний код не придатний до підтримки, то значить завжди можна відновити навичку написання й коду придатного для підтримки. Оскільки компроміси в якості, при написанні прототипів, це були свідомі рішення. Хоча з часом вони стають й несвідомими, а звичкою... 🤔 Та й на відновлення навички потрібен час
Класне відео. Про догматизм дуже гарно підмічено, деколи навіть ті ж рекомендовані підходи і патерни можуть суперечити один одному. Яскравий приклад для мене Anemic Domain Model який напевно на більшості проектах присутній але тим не менш якось код пишеться і проекти не загинаються. Головне напевно тут систематичний підхід до написання коду і розуміння нашо ти саме цей код пишеш ось так і ось тут.
а як боротись з фразами «історично склалось», «так зробили не чіпай», «зроблю окремим тікетом»? особливо коли ти нова людина, яка наче ще бачить «code smells» і вказує ще як іх змінити… брати перероблювати тихенько і вигоряти, чи тупо іти далі?
Так це стандартна історія. Окремим тікетом не так погано. Тут головне, щоб завести цей тікет в систему й періодично їх переглядати й брати в роботу. Тобто, щоб був свідомий менеджмент технічного боргку. Відносно чи тихенько перероблювати й вигоряти, то тут складне питання. Від говнокоду часто страждують навіть ті, хто його створює. Буває таке, що розробник говнокодить, а потім такий "я не хочу на цьому проекті більше працювати, бо тут суцільний говнокод". Тому тут важливо, щоб всі розуміли цінність від більш якісного коду. Можу сказати, що технічний борг накопичується й в Гуглових проектах, але через певний час всі починають страждати від нього (фічі повільніше додаються й тд) й доводиться цілі спрінти приділяти виправленню проблем в коді. Тобто найперше питання - це питання цінності якісного коду й чи розуміє команда це чи ні. Й з цього я би почав - обговорити з командою, зробити аналіз проекту, зробити план. Ну й часом бувають речі, які вже може бути дуже дорого виправити - або якісь суттєві архітектурні проблеми, або проект весь в такому стані, що там говнокод утрамбований говнокодом :)
Тут двогострий меч - з одного боку дуже хочеться, щоб все що "історично склалось" , "так зробили не чіпай" зробили красіво і "як у людей". А з іншого боку - ви ж це будете робити витрачаючи гроші компанії, не роблячи тих задач, які треба робити. Компанії існують не заради Вашого особистого академічного розвитку в кінці-кінців.
Нет такого понятия говнокод, это все интеллектуальная собственность, там большинство его и писать не научились, а теперь вообще не научатся - все ии будет генерировать... В большинстве случаев, все упирается в технологии, время, финансы, любой код хороший, а если в нехватке времени, написанный на коленке и рабочий, он лучше, чем тот который год делали и не могут запустить прод...
Ідея трохи про інше. Якщо писати говнокод, то це має бути свідома дія, яка передбачає менеджмент технічного боргу. Окрім того найбільша проблема не в реалізації, а в абстракціях. Й нормальні абстракції це не так дорого, вони не сильно змінюють вартість розробки. А от негативний ефект від поганих абстракціій можна відчути зазначай вже через пару тижнів, якщо активно додається функціонал. Й говнокод буває часом по причині строків, а часом по причині ставлення розробника до розробки "бо строки". А часом просто не вистачає досвіду, який не з'являться, бо "я говнокожу бо строки". За одні й ті самі гроші можна отримати зовсім різні результати. Як кажуть про технічний борг "можна взяти в борг, а можна вкрасти" 🙂
Ох, це дуже спеціфічна тема. Особливо коли треба працювати за датами, а не тільки з часом. А коли ще до цього додається бухгалтерія й закриття періодів на певну дату, то ще цікавіше. Також є звіти, які можуть рахуватися за періоди й залежати від часових поясів. Й кожен аспект треба продумвати окрему. Якщо ж просто відображати час на фронті (типу як час коменту на ютубі), то це просто форматування - на бекенді зберігаємо все в UTC, а на фронті просто форматуємо відображення під конкретний часовий пояс
Реально корисні поради. Я помічаю що деградую коли пишу швидко говнокод. Так, це вирішує проблеми бізнесу, але я потім по можливості аналізую що було не так, чисто для себе
Привіт, крута тема та подача! Мені цікаво було б почути, як опанувати кілька стеків та набратись на них комерційного досвіду. Я пишу на php, але вивчаю с#. Як можно залишаючись на одній основній роботі, влаштуватись на іншу з новим стеком. Окрім парт тайм. Може є якісь лайфхаки чи іх досвіду шось підкажеш. Хочу відійти від певного стеку і стати інженером, а не кодером
@@AboutProgramming якщо подивитися основні принципи комунізму, то теж ніби виглядає непогано. Але ось реальність показує дещо інше, ніж ці сферичні коні у вакуумі
@@MasterSergius я про те, що якщо комунізм не працює, то це не значить, що аджайл не працює. Й відповідно приклад з комунізмом не підтверджує, що аджайл не працює й не дає відповіді на питання чому аджайл псує програміста. Й цікаво насправді було б почути, чому таке ставлення до аджайл
Догматизм це дуже небезпечна річь, якак зустрічається дуже часто, та і по суті догматизм це пряма дорога до зневажливого ставлення будьяких інших ідеї які не співпадают з тим що кажуть, або пишуть лідери думок.
Круте відео, дякую вам!
Приємно слухати досвідчену людину, яка говорить про цікаві речі ще й українською)
Той рідкий момент, коли стаття на DOU дала рекомендацій дійсного гарного контенту. Дякую за вашу працю!
Дякую за ваш контент. Круто, що є на кого орієнтуватись в україномовному ІТ просторі.
Гарно сформулював і виразив те, що я довгий час відчував. Круто!
Про якість та те, що якісний код писати швидше і дешевше - це одна із моїх ідей та принципів, котрими я теж керуюсь. Дуже, дуже приємно почути цю думку у вашому відео!
Про догматизм та паттерни згадується, що років 12-15 тому на конференціях часто говорили, що Singleton - це антипаттерн. А тепер уявімо DI в OOP та його швидкодію без Singleton. Чи буде це добре працювати і чи має сенс? А можна потренуватись писати stateless код, трохи послухати про функціональні підходи, розділити обробку даних та їх зберігання - і досить швидко вийти на новий для себе рівень.
Нарешті норм контент українською 🤩
Надихаєшь! Дякую!
Дуже корисні поради * український контент = підписка
Дякую за відео, було цікаво
Кайф, дякую!
Гірше за программіста, що не читав "чистий код", тількі программіст, який щойно прочитав. ))
привіт! цікаве відео, сподіваюсь що на каналі буде ще багато нових. була б цікава твоя думка про різницю між сіньйором, мідлом і джуном, які умови потрібно виконати для себе щоб "підняти ранг" :) так, різні компанії у вакансіях окреслюють типу сіньйор = досвід 5+ років, але ж ми знаємо що пишуть одне, а насправді очікування можуть відрізнятись. а десь 2 роки роботи більш продуктивні і розвиваючі, ніж 5 років в іншій. Тому цікаво, як ти посвячюєш дева в сіньйори)
Дякую! Це цікава тема. Насправді, в тому самому Гуглі не вимагається, щоб розробник ріс вище мідла. Всі мідли, яких я знаю персонально, це 8-12 років досвіду. Сеніор з України з 5 років досвіду часом попадає в Гугл на позицію джуна, але буває, що на джуна потрапляють й після університету. Тобто кількість років досвіду це не те, що забезпечує "ранг"
@@AboutProgramming от і цікаво, як розуміти де ти є і до чого реально/посильно прагнути. Як є у вивченні мов, іспити на рівні В2/С1, тільки для розробників, були б круті) хоча може такі і є, але я про них не чула
@@viktoriia809 Часто в великих компаніях є engineering ladder з описом всіх вимог до кожного рівня. Але зазвичай логіка проста. Чим вищий рівень, тим більший твій імпакт очікується на проект й ти отримуєш задачі з більшим ступенем невизначеності
❤❤❤❤❤❤❤❤
І догматизм і говнокод це про інтелектуальну лінь. Особисто я можу кілька разів переписати код, поки він мені почне подобатися. Але це все робота головою. Те саме і про догматизм, зазвичай догматики не замислюються чому так. Тому я би узагальнив - треба вмикати голову, робити це постійно і свідомо. :) Але тих хто так роблять зазвичай дуже мало в соціумі взагалі :(
Гарне узагальнення. В цілому згоден. Як кажуть: "в будь-який незрозумілій ситуації - думай". Я спроектував досить багато систем й є багато схожих, але кожен раз доводиться багато чого продумувати по новому :)
Дякую за супер цікавий контент 👍🏻 У мене питання про зіпсутих програмістів. Я багато цустрічав людей які вже мають багато років досвіду (іноді 20+) але відчуття запаху у них відсутнє 😂😂😂 і при цьому вони іноді займали такі самі позиції як і я (у мене майже 10) а іноді і вищі. Можливо вони ніколи не працювали на великих проектах, але мені бувало складно пояснити переваги базових best концепцій (тестування, single responsibility, мовчу про DDD) бо "код і так функціонує" і "який сенс всьго цього оверхеду". Я прийшов до висновку, що можливо вони і праві і для малих проектів це ок, мати низьку якість. Немає сенсу спорічатись з людьми які не хочуть навчатися... Я б дуже хотів працювати з людьми які знають більше (DDD гарний індикатор доречі). Думаєш це можливо тільки в big tech?
Точно не тільки big tech. Відносно питання явного розміру має бути проект, щоб варто було вкладатися в якісь, то зазвичай через пару тижнів говнокоду швидкість сильно уповільнюється. Є стаття цікава на цю тему
martinfowler.com/articles/is-quality-worth-cost.html
5:33 що значить "мОкати"?
Від англійського Mock - en.m.wikipedia.org/wiki/Mock_object
Про догматизм прямо в точку
Я почав читати дуже цікаву книгу "Выход из кризиса" Деминг Эдвардс. Він ставе на перше місце якість. Кажуть що він той самий хто зробив з Японії чудо. Не гроші змінили Японію, а зміна процесів.
Ось я хочу перекласти, доказати цю ідею у програмуванні. Дати визначення говнокоду, виміряти говнокод у "попугах".
Є різні метрики складності/якості коду типу McCabe complexity та інші. Й вони можуть показати проблеми з кодом, але не можуть довести, що код якісний (окрім того проблема якості може бути в ідельно написаному коді, який просто не оперує тими самими сутностями, що й бізнес). Це як з тестуванням. Тестуванням можна довести наявність багів, але не можна довести іх відсутність. Й є схожа історія з продуктивністю розробника (martinfowler.com/bliki/CannotMeasureProductivity.html). Тут основна проблема, що як міряєш, то так й пишуть :) Але є ряд показників, який дозволяє оцінити якість коду через якість процесів. Взагалі, цікаво було б побачити якийсь робочий підхід, задача досить складна.
За книгу дякую, подивлюся - теж цікаво
@@AboutProgramming дякую за лінку. А у вас є телеграмм чи якийсь чат?
@@eolit1o чомусь ютуб вирішив, що коментар схожий на спам й я його тільки зараз побачив. Так, є телеграм канал - t.me/jabascript (в описі каналу є лінк на мій телеграм теж)
ахаха, не гроші і не мафія, ага)))
@@ДмитрийХоменко-ш1щ так. Є ще крута книга Японське економічне чудо Чалмерса.
Я соло програміст фріланс фул стек 12 років. Php js зараз react більше. Жодної книжки не прочитав. Рейт 100$. Щоб ви могли порекомендувати мені щоб писати кращій код? Топ 1 книжка по проектуванню?
Я не знаю, як ви пишите код, то тут мені складно порекомендувати, що саме треба покращити. Ну й мабуть щось читали за цей час, просто не в форматів книг. На каналі робив одне відео про книги - ua-cam.com/video/p7awmGY9yus/v-deo.htmlsi=UFKe03u0T8h_1ytP
Також після DDD Еванса є ще "Implementing Domain-Driven Design" Вернона - доповнює Еванса різними практичним підходами (можно й тільки її). Просто обирайте ту одну, яка виглядає найбільш цікаво й по темі якої найменше знаєте
@@AboutProgramming дякую. Код пишу не дуже, але ті архітектури яки я бачив, мені не подобаються. Думаю що не існує ідеальної. Але краще знати пару для різних випадків. І краще знати гарно пару аніж трішки багато різних. Ви казали що є укорочена версія DDD? Як вона називається?
А ще я так і не зрозумів як вивчити глибше то, чим ми вже користуємось, https, linux, node, chrome ітд. І я о думаю, чи не буде таке поглиблення шкідливе, так як технології міняються, і через деякий час те шо ти поглиблювався і зробив висновок що краще писати Б ніж А вже не актуально з 156.2 версії Хрома. Чи не вважаєте ви це розпилюванням уваги?
Є непогане самарі www.infoq.com/minibooks/domain-driven-design-quickly/ й DDD Distilled
www.amazon.com/Domain-Driven-Design-Distilled-Vaughn-Vernon/dp/0134434420
10 год тюрми за гавнокод
Коли у замовника бюджет дві копійки і він хоче готовий проект уже на вчора, про яку якість коду може взагалі йти мова. Автор нуб
Таке враження, що це якась особлива ситуація :) Практично всі проекти запускаються в умовах обмежений ресурсів, навіть в Google. Я запустив більше 50-ти проектів й для стартапів й для великих компаній типу Mercedes/Uber/Pfizer й всі хочуть дива.
Відносно якості, то в розробці софта часто якісний код це дешевше й швидше, якщо проект триває більше місяця. Класна стаття була у Фаулера - martinfowler.com/articles/is-quality-worth-cost.html
Окрім того, дуже допомогає стандартизація процессів, кодовой бази, архітектури. Робив колись доповідь про стандартну архітектуру - ua-cam.com/video/TjvIEgBCxZo/v-deo.html
Як Ти не гориш? Як грамотно будувати свій графік, щоб знову не попасти в капкан. Наче овертаймів більше нема, наче не стартап, наче є 4 рази зал на тиждень, англійська , але все одно я знову попав в цей стан. Ти його не відчуваєш і не можеш детектувати, а потім бац і він прийшов. Треба якось перемикати мозок...
Насправді, часу постійно на все не вистачає. Й часто графік ломається, особливо в умовах війни. Тому часто доводиться змінювати підходи до роботи. Поки спорт нормально не можу повернути в графік, але це є в планах. Назвати себе експертом в тайм менеджменті не можу)
Про допомогу іншим - дуже життєво. Це як інвестиція, яка в перспективі дуже добре окупається❤
Ох! Аж попустило. 13 років в девелопменті. Наче сходив до психотерапевта. Незважаючи на те, що я не у веб, а у ембедед С/С++ Дякую! Про моки взагалі. Прошу відео, як не зійти з розуму на проекті з певним достатньо великим досвідом не бажаючи ну ніяк йти у менелжмент роками. Залишаючись людиною, що просто любить писати код
Мені подобається, що в Гуглі менеджмент й інженірінг це 2 окремим вертикалі й можна зростати як individual contributor (IC) не переключаючись в менеджмент. Але немає навіть вимоги, щоб зростати як IC вище L4. Але відносно IC L6+ (staff engineering), то читаю зараз www.amazon.com/Staff-Engineers-Path-Individual-Contributors/dp/1098118731
@@AboutProgramming Дякую за відповідь та посилання на книгу
Все вірно сказано. Важко дається 3-ій пункт. Багато знаю колег хто зневажливо відноситься до інших. Якщо буде можливість і вам буде цікаво, можливо зробити відео як ви дизайните застосунки, можливо мікросервіси. Цікаво дізнатись які техніки solution design ви приміняєте наприклад для комунікації декількох ізольованих компонент. І можна наприклад погратися з типами ізоляції щоб було зрозуміло що для вас є чинниками зміни транспорту комунікації між компонентами. Також було б цікаво більш глибше зануритись у типи даних. Можливо у вас є приклади з життя де можна застосовувати якісь екзотичні структури даних. Дякую за Вашу роботу! Цікаво дивитись!
Привіт, хотів би почути як ти готувався до проходження інтерв‘ю в Гугл.
Пропоную відео про способи покращення якості коду і де шукати якісний код для прикладів або про книжки чи статті, які обовʼязково треба прочитати та зрозуміти
Знаете в тій чи іншій мірі ми всі пишемо говнокод, далекий від ідеалу. Тут на думку спадає реакт роутер коли кожну версію автори казали поперядня то була фігня, а ось теперь ми все зрозуміли познали дзен і ось тепер... потім проходив час і все повторювалося знову. Я до того що майже нереально написати не гвонокод з першого разу, а бо хочаб те що через рік не буде так виглядати для самого автора. Короче дуже тяжко бути перфукціоністом в програмуванні покою не буде ніколи )))
Насправді, це вже про перфекціонизм. Я би не став ділити код на 2 групи - або "ідеальний" , або "говнокод". Є ще багато гарного коду, який існує посередені й не є говнокодом. Й важливо не плутати технічний борг й говонокод - це теж про різне
@@AboutProgrammingв моєму розумінні гамнокод часто (завжди) призводить до технічного боргу. Банально нову фічу додати займатиме вічність
@@v.ilchenko на практиці технічний борг виникає при написанні будь-якого коду
Дуже цікаво
А чого прагне гугл? Вкурсі його політики розвитку?
Нащо йому захоплювати інтернет?
Акціонери та інвестори завжди хочуть, щоб бізнес приносив гроші. Тобто ціль - робити продукти більш успішними. Відносно захоплення інтернету, то тут скоріше спостерігаю навпаки великі інвестиції для покращення інтернету, його безпеки, але ніяк не намагання взяти інтернет під контроль
- говнокод
- догматизм
- зневажливе ставлення до колег
Нажаль, просто список не розкриває суті
Було б круто побачити щось типу лайв-сессії, на якій Ви будуєте щось типу туду-листа (може с авторизацією для невеликого ускладнення) з усіма етапами розробки.
Тобто спочатку будуєте архітектуру -- system design, потім етап побудови інфраструктури, реалізація з тестами -- тут цікаво що саме ви б тестували, а що можна пропустити, ну і деплой з тестуванням.
Я колись хотів зробити курс по розробці й показати всі аспекти проектування на прикладі якоїсь системи. Можливо частина курсу попаде на канал просто в форматі окремих відео
@@AboutProgramming Пам`ятаю, Ви казали, що хотіли зробити курс, але так і не доходили руки.
То виходить він вийшов?
@@mrart5498 курс ні, а от план для курсу є. Ось якраз хочу взяти з нього теми для відео на канал
@@AboutProgramming Зрозумів! Дякую, будемо чекати :)
Проблема догматизму в реакт, в тому що куди не плюнь в редакс попадеш )))
Дуже часто це не про догматизм, а про зважене рішення (не обовʼязково технічне навіть, моживо чисто бізнесове)
на гівнокоді пів світу тримається
Статистика залежить від того, хто оцінює код - автори коду чи розробникі, які підтримують код після звільнення автора)
Щодо "чи буває швидко-дешево-якісно"? За своє життя жодного разу не бачив такого. Якщо розглядати "дешево", з точки зору подальшої підтримки, то ну може.
Так, передбачається, що програма буде розвиватися певний час. Згадав фразу "Якщо ви думаєте, що гарна архітектура це дорого, то спробуйте погану"). В цілому, є певна межа, з якої внутрішня якість починає себе окуповувати. Є дуже гарна стаття у Фаулера на цю тему - martinfowler.com/articles/is-quality-worth-cost.html яка каже, що внутрішня якість продукту починає себе окуповувати не через місяці, а через тижні. Багато разів бачів, коли низька якість призводили до проблем й значного зростання строків імплементації.
Тобто, я не можу сказати, що низькоякісний код це дешевше підтримувати й швидше додавати нові фічі. Скоріше навпаки, якісний код призводить до більше швидкого додавання нових фічей й більше дешевої підтримки
Дякую за відео❤!
Іноді галєри спеціально пишуть поганий код щоб його було важко підтримувати час розробки більше отже більше грошей можна стягнути з замовника і навіть якщо він захоче піти то інші команди не зможуть продовжити нормально розробку💩
Ніколи не бачив, щоб спеціально ставили задачу розробнику писати поганий код) скоріше не завжди зважають на якість у достатній мірі
насправді, за 3 роки, які я працюю з AI я втратив здатність писати придатний до підтримки код
це, насамперед, пов'язано з тим, що безліч ідей треба дуже швидко прототипувати. Це біль.
Але тут виріс скілл швидкого прототипування, що якраз й корисно для сфери AI. Й якщо є відчуття того, що певний код не придатний до підтримки, то значить завжди можна відновити навичку написання й коду придатного для підтримки. Оскільки компроміси в якості, при написанні прототипів, це були свідомі рішення. Хоча з часом вони стають й несвідомими, а звичкою... 🤔 Та й на відновлення навички потрібен час
Вже досить розуміти про що мова йде в цьому відео і ти вже класний програміст 😅
😄
Класне відео. Про догматизм дуже гарно підмічено, деколи навіть ті ж рекомендовані підходи і патерни можуть суперечити один одному. Яскравий приклад для мене Anemic Domain Model який напевно на більшості проектах присутній але тим не менш якось код пишеться і проекти не загинаються. Головне напевно тут систематичний підхід до написання коду і розуміння нашо ти саме цей код пишеш ось так і ось тут.
Дедлайни > чистий код
Так й є. Але це не значить, що "дедлайни = говнокод" 🙂
+
а як боротись з фразами «історично склалось», «так зробили не чіпай», «зроблю окремим тікетом»? особливо коли ти нова людина, яка наче ще бачить «code smells» і вказує ще як іх змінити… брати перероблювати тихенько і вигоряти, чи тупо іти далі?
Так це стандартна історія. Окремим тікетом не так погано. Тут головне, щоб завести цей тікет в систему й періодично їх переглядати й брати в роботу. Тобто, щоб був свідомий менеджмент технічного боргку. Відносно чи тихенько перероблювати й вигоряти, то тут складне питання. Від говнокоду часто страждують навіть ті, хто його створює. Буває таке, що розробник говнокодить, а потім такий "я не хочу на цьому проекті більше працювати, бо тут суцільний говнокод". Тому тут важливо, щоб всі розуміли цінність від більш якісного коду. Можу сказати, що технічний борг накопичується й в Гуглових проектах, але через певний час всі починають страждати від нього (фічі повільніше додаються й тд) й доводиться цілі спрінти приділяти виправленню проблем в коді. Тобто найперше питання - це питання цінності якісного коду й чи розуміє команда це чи ні. Й з цього я би почав - обговорити з командою, зробити аналіз проекту, зробити план. Ну й часом бувають речі, які вже може бути дуже дорого виправити - або якісь суттєві архітектурні проблеми, або проект весь в такому стані, що там говнокод утрамбований говнокодом :)
Тут двогострий меч - з одного боку дуже хочеться, щоб все що "історично склалось" , "так зробили не чіпай" зробили красіво і "як у людей". А з іншого боку - ви ж це будете робити витрачаючи гроші компанії, не роблячи тих задач, які треба робити. Компанії існують не заради Вашого особистого академічного розвитку в кінці-кінців.
Моя персональна догма: "Ніяких деплоїв в п'ятницю"
Нет такого понятия говнокод, это все интеллектуальная собственность, там большинство его и писать не научились, а теперь вообще не научатся - все ии будет генерировать... В большинстве случаев, все упирается в технологии, время, финансы, любой код хороший, а если в нехватке времени, написанный на коленке и рабочий, он лучше, чем тот который год делали и не могут запустить прод...
Ідея трохи про інше. Якщо писати говнокод, то це має бути свідома дія, яка передбачає менеджмент технічного боргу. Окрім того найбільша проблема не в реалізації, а в абстракціях. Й нормальні абстракції це не так дорого, вони не сильно змінюють вартість розробки. А от негативний ефект від поганих абстракціій можна відчути зазначай вже через пару тижнів, якщо активно додається функціонал. Й говнокод буває часом по причині строків, а часом по причині ставлення розробника до розробки "бо строки". А часом просто не вистачає досвіду, який не з'являться, бо "я говнокожу бо строки". За одні й ті самі гроші можна отримати зовсім різні результати. Як кажуть про технічний борг "можна взяти в борг, а можна вкрасти" 🙂
цікава тема роботи з часовими поясами на фронті, особливо цікавить варіант коли потрібно переводити час в часові пояси які юзер вибирає з ddl
Ох, це дуже спеціфічна тема. Особливо коли треба працювати за датами, а не тільки з часом. А коли ще до цього додається бухгалтерія й закриття періодів на певну дату, то ще цікавіше. Також є звіти, які можуть рахуватися за періоди й залежати від часових поясів. Й кожен аспект треба продумвати окрему. Якщо ж просто відображати час на фронті (типу як час коменту на ютубі), то це просто форматування - на бекенді зберігаємо все в UTC, а на фронті просто форматуємо відображення під конкретний часовий пояс
Хотілося б відео з прикладами говнокода)
Віктор, вітаю із створеннямм свого каналу!
Дякую!
Реально корисні поради. Я помічаю що деградую коли пишу швидко говнокод. Так, це вирішує проблеми бізнесу, але я потім по можливості аналізую що було не так, чисто для себе
Дякую. Все просто але щось нам заважає дотримуватися простих принципів
Привіт, крута тема та подача!
Мені цікаво було б почути, як опанувати кілька стеків та набратись на них комерційного досвіду.
Я пишу на php, але вивчаю с#. Як можно залишаючись на одній основній роботі, влаштуватись на іншу з новим стеком. Окрім парт тайм. Може є якісь лайфхаки чи іх досвіду шось підкажеш. Хочу відійти від певного стеку і стати інженером, а не кодером
Дякую дуже за відео! Було корисно почути, радію що є такі програмісти - людяні та професіонали)
Дякую за подібні відео, одразу підписався ❤
Вікторе, дякую вам за контент.
Душевно.
Насправді, є дві речі, які псують програмістів: аджайл і ефективні менеджери
Ось 12 принципів з аджайл маніфесту agilemanifesto.org/iso/uk/principles.html . Чому це псує програміста?)
@@AboutProgramming якщо подивитися основні принципи комунізму, то теж ніби виглядає непогано. Але ось реальність показує дещо інше, ніж ці сферичні коні у вакуумі
@@MasterSergius тобто аджайл не працює бо комунізм не працює?
@@AboutProgrammingдивний висновок, ну добре, хай буде
@@MasterSergius я про те, що якщо комунізм не працює, то це не значить, що аджайл не працює. Й відповідно приклад з комунізмом не підтверджує, що аджайл не працює й не дає відповіді на питання чому аджайл псує програміста. Й цікаво насправді було б почути, чому таке ставлення до аджайл
Супер контент! Дякую!
Де слова Кент Бека?
А що він казав?)
@@AboutProgramming так у відео ж є про те що він казав що дуже рідко мокає тести. Хотів це показувати фанатам моків 😂
@@nas1k ааа)) Так, серія відео "is TDD dead". Тут посилання на всі частини martinfowler.com/articles/is-tdd-dead/
Най ідуть н🦆й з тими ES модулями. некомпатибільна 🚽
ESM вже норм)