Як вчити .NET: детальна інструкція, vol. 2

Усім привіт, мене звати Влад і я займаюсь .NET розробкою понад 10 років. За цей час я встиг попрацювати на десятках проєктів у ролі сеньйор та лід-розробника, також провів велику кількість співбесід на різні рівні. 4 роки тому я написав статтю як вчити .NET, яка стала доволі популярним матеріалом серед початківців, що хочуть вивчати .NET технології. Також доволі корисною була стаття із загальними рекомендаціями для тих, хто тільки починає свій кар’єрний шлях в IT.

Тепер я зробив корективи і деякі поліпшення, щоб адаптувати матеріал до умов сьогодення. У цій статті наголос зроблено на базу мови C# й платформи .NET + на веброзробку. Якщо ви хочете писати для desktop або мобільних — думаю, зможете знайти ці матеріали в інтернеті без проблем.

План для вивчення C#

У цій Гугл-таблиці можна знайти такі вкладки:

  • C# 5 basics — базові теми з синтаксису C#. Пропоную початківцям вивчати базу, разом зі старим синтаксисом включно, щоб ви не губились у коді, написаному давно. Якщо ви зараз не розберетесь у базі добре, то потім навряд матимете на це час. В процесі самонавчання не забувайте про LINQ, варто знати всі методи.
  • C# 6-11 фічі, які були додані в C#, починаючи з 2015 року. У документі я зібрав усі фічі за категоріями й додав посилання, де можна подивитись/ почитати. Рекомендую розглядати нові фічі як «патч» базових знань. Можете вивчити їх стовпчиками послідовно, у рамках якогось контексту, наприклад: сьогодні ви вивчаєте все, що стосується структури програми та using’ів, завтра — все, що стосується структур даних та колекцій. Проте, якщо у вас на проєкті зафіксована не найновіша версія C#, то ви можете сконцентруватись тільки на актуальних для вас фічах. Таким чином за 2-3 тижні ви вивчите всі останні апдейти мови.

Можливості мови, що стосуються некерованого коду, вивчати не обов’язково. Вони мають доволі вузьку нішу застосування і вам це скоріш за все не знадобиться. А якщо знадобиться — знаєте, де шукати інформацію.

  • Базові знання про середовище виконування в .NET CLR (Common language runtime). Власне базові знання про те, як .NET-платформа працює всередині. У таблиці поділені .NET Framework та .NET Core / .NET 5+. З появою нових версій фреймворка та runtime, дещо сильно змінилось, і те, що було актуально для .NET 4.8 вже не актуально для .NET 5 (наприклад, Application Domains).
  • Базові знання бібліотек класів (BCL) — перелік найпопулярніших класів з .NET, які допоможуть вам у рутинній роботі.
  • Патерни проєктування — зібрані найпопулярніші патерни проєктування, які можуть стати вам в пригоді. Деякі з них вже не так актуальні, інші має сенс знати, якщо ви вже не trainee. Пропоную розглядати патерни як ідею, а не як рішення. Патерни — це мова, яка розповідає про імплементацію, але у сучасному C# більша частина патернів вже вбудовані на рівень мови/фреймворків, і імплементувати їх окремо не потрібно. Однак знати про них необхідно, виключно з точки зору термінології. Наприклад, нема сенсу реалізовувати Singleton, коли можна використати Singleton scope у вашого IoC-контейнера. Або, наприклад, патерн Observer/ Iterator вже має мовні засоби в C# у вигляді подій та переліків.
  • Різні корисні посилання і матеріали — сюди я буду додавати різні курси, статті, книги, які мені здалися корисними.

Що змінилося у вимогах для початківців

Знання лише мови C# мало, необхідно також вміння працювати з фреймворками/інфраструктурою. Ваш джентльменський набір може бути таким:

  • ASP.NET Core.
  • EF Core.
  • XUnit або NUnit, розуміння що таке интеграційні/юніт тести, методологія AAA.
  • Базовий SQL: SELECT запити, зміни даних, створення/зміна таблиць.
  • Вміння запускати docker-контейнери та docker-compose файли. Базові навички володіння докером, уміння писати нескладні докерфайли.
  • Базове володіння git’ом.

Зовсім круто буде, якщо ви розберетеся з тим, як реалізовувати розгортання програми за допомогою CI/CD пайплайнів. Можете використовувати Gitlab pipelines / Github actions, або навіть щось із хмар, на кшталт Azure pipelines.

Деплоїти можете в Heroku або налаштувати свою Linux VM з нуля. Найдешевші Linux машинки тут.

Додаткові компетенції

Бази даних

У цьому документі я зібрав необхідний мінімум базових знань з T-SQL / MS SQL Server. Де та як вивчати, вирішувати вам, можу запропонувати такі матеріали:

  • Початковий рівень: непоганий сайт-підручник з основ.
  • Середній рівень: книга з написання запитів на T-SQL.
  • Розвинений рівень: найкращий підручник з базового SQL, на мій погляд.

Однак, останнім часом, особливо з поширенням мікросервісної архітектури, все популярнішим стає MySQL / PostgreSQL. Але вивчивши базу SQL за MS SQL Server, вам буде легше розібратися в будь-якій SQL-подібній мові. Проте не варто гнатися за усіма базами даних, рекомендую спочатку вивчити Microsoft стек.

Розуміння роботи аутентифікації та авторизації

Доволі важливо розуміти, як працює аутентифікація та авторизація, що таке Bearer & JWT токени, які бувають постачальники аутентифікації: asp.net idetntity, Identity Server, 3rd party сервіси.

Непоганий курс на Udemy з теми, проте він не для зовсім початківців.

Контейнеризація

Сучасна розробка практично неможлива без контейнеризації.

По docker та docker-compose можу порекомендувати офіційну документацію:

Або відеокурс з Udemy про docker & docker-compose. Однак, для початківців достатньо розуміти, як запускати/ зупиняти/ збирати Docker-контейнери та Docker-compose файли.

Front-end

Якщо вам подобається front-end й у вас багато вільного часу, то можете базово вивчити якийсь з фреймворків. Для цього підійдуть курси типу цих:

Раджу платні курси на Udemy. Але це не обов’язково, щоб розвиватись як junior .NET. Якщо часу не так багато, то раджу сконцентруватися саме на back-end частині.

Як набувати практичних навичок

Я виокремив такі етапи навчання:

Етап 1. База синтаксису

Тут ваше завдання засвоїти синтаксис мови C# без реальних завдань. Це можна робити, просто реалізуючи кожну фічу в IDE окремо, експериментуючи з поведінкою.

Потім можна братися до складніших завдань.

Я створив документ, де зібрав кілька завдань для самостійного опрацювання. Реалізуйте всі завдання та залийте код на github.

Також можу порекомендувати CodeWars для вправ з кодом.

Ще один сайт, що допомагає вивчати програмування в ігровому стилі, — CodeEasy.

Особисто я вивчав синтаксис, просто експериментуючи в IDE, без сторонніх сервісів, ставлячи собі питання, і знаходячи відповіді в книгах та в офіційних специфікаціях.

Етап 2. База фреймворків

Почати можна з ASP.NET Core та EF Core. Який тип матеріалів використовувати — вирішувати вам.

Це можуть бути як статті з docs.microsoft, так і курси з Udemy або книги. Кожен шукає свою зручну форму самонавчання.

Щодо курсів на Udemy — я б радив шукати курси з найбільшою кількістю покупок + найбільшою тривалістю. Рев’ювери Udemy стежать, щоб структура курсу була максимально зрозуміла для студентів, інформацію можна засвоювати маленькими блоками.

Етап 3. Нескладні завдання на фреймворках

Ось, наприклад, нескладна задачка для проєктування API. Аналогічно можете вигадати й собі проєктування бази даних на Entity Framework з підходом CodeFirst з EF міграціями. Потім реалізувати те саме, але у підході зі створенням бази даних через чистий SQL.

Етап 4. Pet-проєкт

Настав час писати свій проєкт. Завдання: створити закінчений продукт, це в рази більше, ніж лабораторна робота.

Цим продуктом не обов’язково може бути вебдодаток, хоча це було б ще краще. Ви можете реалізувати API для своєї вебпрограми, припускаючи, що під нього можна без проблем реалізувати front-end.

Але головне тут — розділяти етапи розробки, щоб коли ви працюєте над ними, ви чітко розуміли свої завдання, щоб кожне завдання для вас було прозорим.

Наприклад: для початку ви малюєте макети, щоб зрозуміти, як виглядатиме потенційний front-end. Тут вам допоможе Balsamiq, Ninjamock, Axure або будь-які інші засоби, навіть на листочку. Прототипуючи свій проєкт, ви навчитеся бачити користувальницькі кейси цілком і зможете їх явно формалізувати.

Як приклад: можете взяти будь-яку E-commerce систему або клон Instagram, чи й взагалі придумати щось своє. Головне тут — мати розуміння, що це буде і як цим користуватися.

Наступним етапом опишіть бізнес-логіку, тобто, які дані ви виводите на екран, які дані відправляєте на сервер, яка послідовність користування. Розбийте все на сторінки, а сторінки — на окремі фічі (тобто конкретні функції).

Починайте проєктувати API під уявний front-end, емулюючи повернення реальних результатів роботи.

Далі розробляйте схему бази та бізнес-логіку навколо неї. Досить зручно користуватиметься Postman під час розробки. Також можна писати інтеграційні тести в окремому проєкті, щоб проходити ланцюжки типових юз-кейсів.

Етап 4.1. Рефакторинг pet-проєкта

На попередньому етапі головне завдання було зробити так, щоб ваш проєкт просто коректно працював, ми ще не говорили про дизайн коду.

Тепер настав час виправити косяки, показати більш досвідченим товаришам свій код та попросити зворотний зв’язок. А якщо товаришів у вас небагато, то вступайте до мого .NET ком’юніті. Там більш як 1000 .NET розробників, які зможуть відповісти на запитання / допомогти.

Етап 5. Розгортання pet-проєкта

  • Розгорніть ваш проєкт, бази даних на віддаленому сервері.
  • Налагодіть CI/CD, для початку це можна зробити навіть у візуальному дизайнері Azure DevOps, але я б рекомендував навчитись писати YAML скрипти для розгортування.
  • Напишіть інтеграційні тести.

Загальні рекомендації

  • Поки є час — вивчайте мову якісно та глибоко, потім часу не буде.
  • Інтернатура — хороша точка входу, у найкращому випадку, вас потім візьмуть на роботу, в іншому — отримаєте досвід. Моніторьте DOU та інші сайти щодо інтернатур.
  • Безкоштовна/ малооплачувана робота краще безкоштовного неробства, навіть поганий досвід краще ніякого досвіду, але врахуйте, що приходячи на інтерв’ю у велику компанію, у разі вашої невдачі вас навряд повторно запросять у найближчі 6 місяців.
  • У вас має бути ключова компетенція, те, що ви знаєте найкраще. Так, потрібно знати широкий спектр питань, включаючи фреймворки, інфраструктуру тощо, але має бути щось, що ви знаєте найкраще. Для C# програміста це може бути мова C#.

Рекомендації книг та курсів

Синтаксис С#

LINQ:

Поради щодо написання коду:

Ресурси з вивчення C#:

Патерни проєктування:

  • Список патернів, але рекомендую ставитися до патернів не як до фрагментів коду, які «треба» запихувати собі в проєкт, а як до своєрідної ідеї, яка може бути реалізована різними способами. Автор навів свою імплементацію в прикладах, але ваша може бути іншою. Багато патернів уже не варті ручної імплементації. Наприклад, замість Singleton, у нас є Singletone scope у стандартного IoC контейнера в .net core, але в підручнику все ще дається Signleton 10-річної давності з подвійним блокуванням.

Архітектура:

Робота CLR

Книга про все на базовому рівні: мова, бібліотека класів, фреймворки, веб, мобайл, ML:

  • C# 8.0 and .NET Core 3.0 — Modern Cross-Platform Development: Build applications with C#, .NET Core, Entity Framework Core, ASP.NET Core, and ML.NET using Visual Studio Code, 4th Edition 4th Edition.

Скоріше для ознайомлення з різними аспектами розробки.

ASP.NET Core

EF Core

ASP.NET Core MVC

ASP.NET Core 6.0 Course — MVC — Blazor — Razor — EF Core — курс, орієнтований на вивчення серверного Razor, клієнтського Blazor, а також шару даних.

Що змінилося в .NET-розробці та необхідних скілах розробників за останні 10 років

Докладніше ви можете почитати мій торішній матеріал на цю тему, але якщо коротко:

• C# став використовувати більше функціональних прийомів розробки: Pattern matching, Багато LINQ, імутабельність.
• Асинхронний код.
• Стала популярнішою веброзробка.
• Став лаконічнішим API для розробки вебзастосунків.

Як обирати курси з розробки

Загалом на питання йти чи ні на курси маєте відповідати ви самі. Якщо у вас багато часу та мотивації — цілком можете впоратися і самостійно, організувавши навчання та практику. Якщо у вас є основна робота, а часу замало — можна підключити професіоналів, які вам у цьому допоможуть.

Дисклеймер: не запитуйте мене, які курси кращі, я не знаю, тому що ніколи не навчався на курсах. Але я можу дати спільні рекомендації, як обирати курси під себе, ґрунтуючись на досвіді інших людей.

Загальні критерії курсів, на мій погляд, які здатні довести людину до ринкового стану:

  • Розгорнута програма. Вивчення як C#, так і прикладних аспектів: бази даних, веб або інша розробка, фреймворки. Допускається, якщо в рамках центру навчання будуть різні курси, пов’язані між собою загальною послідовністю.
  • Буде добре, якщо вам дадуть якесь розуміння роботи черг, розподілених систем, засобів розробки, якщо напрямок курсів веб.
  • Велика кількість практичних завдань, а також навчальні проєкти. В ідеалі — робота в команді.
  • Тривалість хоч би 4-6 місяців.
  • Постійне спілкування з менторами, отримання зворотного зв’язку. Важливо, щоби ментори мали комерційний досвід розробки.

Результатом закінчених курсів має стати вміння розробки проєктів будь-якої складності end-to-end з розгортанням, без використання складних архітектурних патернів. Питання якості коду і підтримуваності тут другорядне.

Як вивчати англійську швидко

Я нерозривно пов’язую англійську з розробкою, важливо вміти спілкуватися/писати/читати, щоб не залежати від клієнтів на локальному ринку.

Завдання, яке я вирішую своїми наступними рекомендаціями, — це максимально швидка підготовка людини до ринку праці, а не академічність навчання.

Проблема у вивченні англійської досить часто пов’язана з тим, що викладачі англійської вчать, як бути викладачем англійської, завантажуючи вас правилами, але говорити від цього ви не почали. Зазвичай ці люди знають мову вже з дитинства, і ті речі, які видаються вам складними, для них вже очевидні давно.

Я вважаю, що первинна мова — це вербальна. Якщо ви вмієте говорити, то зможете писати. Якщо ви можете тільки писати, говорити не зможете. За розмови відповідають інші зв’язки у мозку.

Мова = слова + шаблони мови + вміння їх слухати та говорити. Правила в мові — це скоріше шаблони, які потрібно завчити, без пошуків зайвих закономірностей. Забудьте про 24 часи. Часів у мові всього 3. Решта — це відтінки сенсу.

В англійській мові зміст частіше передається службовими словами та порядком слів, ніж у нашій. У мові працює лише те, що ви довели до рефлексу. Для створення мовної бази для спілкування потрібно знати багато слів. Вивчати слова логічніше за рівнем їхньої потрібності у мові, тобто за частотним словникам.

Користуватися мнемонічними техніками не можна, треба зубрити. Вчити буде складніше, але так наш мозок навчиться їх діставати швидше, без зайвих адресацій.

Ось декілька частотних словників вартих вашої уваги:

Професійні ж терміни ви можете підхопити з тредів на Stackoverflow або статей на Medium.

Потрібно багато спілкуватися. Мінімум 3 рази на тиждень по 1 годині. Краще більше. Також вам потрібно спілкуватися з собою під час внутрішнього діалогу, навчаючись висловлювати ваші типові смислові конструкції новою мовою. Важливо, щоб викладач не заважав вам, а допомагав, коригуючи, але не перевантажуючи.

Для спілкування краще обирати або дотичні теми або заздалегідь відомі вам. Погано, коли в спікінг-клабах вам нав’язують спочатку особисту або тему «що ви робили вчора ввечері». Якщо ви не хочете це обговорювати — ви думатимете своєю мовою, щоб потім перекладати англійською, і це погано. Результат, який нам потрібен — це думати ВІДРАЗУ англійською. Цей процес нагадує закипання чайника. Потрібно якийсь час прогрівати себе, потім відбудеться кипіння і ви зможете відразу перемикатися на англійську, думаючи вже нею.

Англійську мову найкраще практикувати рано вранці, коли ви не встигли достатньо прокинутися і ваша критична частина свідомості не заважатиме вам.

Не бійтесь виглядати безглуздо під час практики, це не допоможе досягненню результату.

Один з хороших методів на розвиток слухання: слухати дитячі казки англійською. Вони не рясніють надмірно складною граматикою і лексикою, слова в них вимовляють чітко. У своєму навчанні ми повинні пройти умовний шлях дитини, тільки з більшою усвідомленістю, тож проходимо 10 років за 1 рік.

Для прокачування вміння спілкуватися, можна слухати та перекладати подібні відео з субтитрами:

Це дуже схоже на звичайні робочі дзвони.

Щоб розвинути правильний акцент, вам потрібно сформувати «маску» вимови. Не бачу сенсу не вчитися робити це відразу, щодо мови. Логічно вчитися правильно вимовляти слова відразу, ніж потім роками переучувати себе. Бачив багато викладачів, не здатних говорити з правильним акцентом, але наше завдання — не навчати мови, а використовувати її. Ось непоганий мануал з вправами.

Дуже важливо розуміти, що в англійській язик примикає до піднебіння у стані спокою, деякі звуки вимовляються горлом, наприклад «h». Загалом після кількох тижнів практики можна привчити себе говорити анатомічно правильно, що створить правильні звуки. Найпростіше вибрати якогось персонажа, наприклад ведучого CNN та його копіювати, — це, на мою думку, найшвидший шлях навчання.

Отже, щоб швидко вивчити мову, нам потрібно:

  • Багато нею спілкуватися.
  • Постійно розширювати словниковий запас та використовувати його.
  • Багато читати й слухати.

Вивчення граматики — це лише інструмент ускладнення мови, здатності виражати відтінки сенсу, але не центральний чинник. Однак, якщо ви хочете скласти міжнародні іспити на формальне володіння мовою, вам доведеться добре вивчити і граматику теж.

За рекомендаціями людей, можу порадити декілька сервісів для початку вивчення англійської:

Непогано підходять для зовсім початківців.

Наостанок

Вступайте в .NET ком’юніті, в якому вже понад тисячу учасників. Обговорюються теми з .NET, обговорення різних курсів, більш досвідчені хлопці, серед яких і я, даємо поради початківцям.

Також у мене є закрита спільнота для досвідчених сеньйорів, техлідів і архітекторів, якщо хочете туди потрапити, напишіть мені. Також звертайтесь із запитаннями про .NET на Facebook.­­­

Сподобалась стаття? Натискай «Подобається» внизу. Це допоможе автору виграти подарунок у програмі #ПишуНаDOU

👍ПодобаєтьсяСподобалось56
До обраногоВ обраному36
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

І все це щоб стати джуном на зп $1000 баксів???

Ні, трейні, котрий буде крутити Kubernetes та джейсони ;) . Net/Java розробка — це для своїх (ніхто не дасть пролізти в ентерпрайз-розробку, бо там же одна Иліта)

До 1000 баксов еще дорасти нужно.
Я не так много материала запостил. При желании за пол года изучите.

можно зайти на jooble.pl, ввести слово «elektryk», немножко подофигеть от зп 4500€, а потом узнать что на этого электрика учится в среднем 2 месяца в любом проф-тех-училище, и это не считая курсов в youtube.
Сколько нужно потратить времени и сил, чтоб війти на подобный уровень дохода в ИТ-сфере???

Года 4 думаю, сил не мало.
Но если вы уже нашли свой путь, то удачи в карьере электрика. Жду через 2 месяца статью как вы начали зарабатывать 4500 евро.

Лучше 4500 евро электриком, чем 4 года джуном, за 1000 баксов, в нищите.

чем 4 года джуном, за 1000 баксов

ну то не треба так

для зп скалу нужно учить, там 2,5-3к через год работы. 6к через 3 года. 0,5 кандидата на вакансию.

Сравнили ЗП электрика в Польше и ЗП ждуна в Украине. Это какое-то сравнение теплого с мягким

То не в Польщі, то в Німеччині мабуть

Я тоже хотел, но не нашёл подходящей, поэтому написал свою. Передаю вам эстафету, напишите вы

SOLID та куча патернів для junior, а KISS і DRY для senior? Щось тут не так :) Скоріш навпаки потрібно було бути. Я майже на 100% впевнений, що запитай зараз middle або senior про SOLID більша половина буде щось там мичати, а друга відповість від сили на пару літер і то з прикладами від яких очі будуть текти... junior має вивчити KISS та DRY — хай змалечку привчається писати «чистий» і «простий» код.
А ще мало уваги Unit-тестам, Mock і т.д, рефакторінгу коду.

Вы не поймете KISS & DRY не имея лет 5 опыта. Концепции простые, но их смысл приходит только с опытом. Между спросить и использовать на практике есть разница. А вот паттерны заучить нужно чтобы хотя бы понимать какая проблема и какое решение какие ИМЕНА носят.

Ну Unit-тесты не везде нужны. А там где они нужны уже человек разберется когда прийдет на реальный проект. Мы ж говорим про человека, который обучается чтобы его взяли в компанию.

тобто дублювання і «сходинки» це складно, а SOLID і туча патернів це просто? ну ок... запитайте як-небудь у своіх колег, що вони спершу виправляють на Code Review: solid, pattern чи KISS та DRY?
Я забув ще написати про контейнерізацію. Ось це ну дуже дивно для джуна.

для ясноснти скажите, сколько лет вы разрабатываете ?
Да. KISS и DRY это не так просто понять имея пару лет разработки. Это не паттерны, это принципы. Иногда дублировать код нужно, иногда нет. Единого ответа тут нет, и если обучать джуниоров без опыта этим принципам они их просто извратят.

для ясноснти скажите, сколько лет вы разрабатываете ?

20+

Иногда дублировать код нужно, иногда нет.

теж саме стосується і KISS та патернів :)))

KISS и DRY это не так просто понять имея пару лет разработки. Это не паттерны, это принципы
Список патернів, але рекомендую ставитися до патернів не як до фрагментів коду, які «треба» запихувати собі в проєкт, а як до своєрідної ідеї, яка може бути реалізована різними способами

Тут я трохи завис :) «Ідея» і «принцип» це ж десь поряд?

Идея/принцип это более общее понятие, чем паттерны. Вы не научите джуниора правильному использованию DRY/KISS/YAGNI, для этого нужно какое-то время код пописать. Это абстрактные концепции очень. Вот я к чему. Но если не согласны — велкам, пишите свою статью, если она соберет больше лайков чем моя — признаю вашу правоту.

Вы не научите джуниора правильному использованию DRY/KISS/YAGN

а шо тут вчити? 3-4 перших рев’ю поставлять все на місце якщо людина трохи кумекає, а от SOLID, патерни це дійсно досвід і пописати треба ой як багато, щоб зрозуміти навіщо воно і як використовувати.

следовать каким-то из SOLID-принципов в целом можно, но иногда это требует переписывания большого количества кода. Зато есть конкретная идея.

KISS & YAGNI это не только про написание кода. Это про инфраструктуру, выбор средств, фреймворки.

Вот попробуйте весь код писать используя Single Responsibility & Open/Close, это крайне не просто и часто не нужно, тут нужен опыт. Паттерны куда проще применять, ведь название паттерна СЛЕДУЕТ из решенной проблемы, а не наоборот.

Следовательно паттерны носят реактивный характер в мышлении, а принципы — проактивный, если вы поняли о чем я.

следовать каким-то из SOLID-принципов в целом можно, но иногда это требует переписывания большого количества кода. Зато есть конкретная идея.

Навіщо це джуну?

KISS & YAGNI это не только про написание кода. Это про инфраструктуру, выбор средств, фреймворки

Ну я про це www.c-sharpcorner.com/...​rinciples-dry-kiss-yagni
Можливо ви бачите це ширше. Тоді сорян.

Навіщо це джуну?

для того, чтобы у него была осознанная практика. Когда закладываешь человеку мысли и какое-то понимание изначально, то получая опыт человек пропускает его через фильтр своего же знания и таким образом учится.

Ключове слово — досвід. у джуна його немає і забивати йому мізки SOLID і патернами непотрібно. Це прийде, але пізніше, коли він натре мозолі на простих задачах. Доречі написати простий UT дуже допомагає «в’їхати» в код і отримати необхідний досвід.

Дело в том, что это нужно не ему, а его лиду. Чтобы не ревьювить каждый коммит по 20 раз.

Навіщо це джуну?
Дело в том, что это нужно не ему, а его лиду.

Я завис другий раз :)

Запускайте режим реального времени для ядра )
Я имел ввиду что это нужно чтобы лиду было удобней с человеком работать.

Ну це вже задача ліда, щоб джун навчився цьому. Лід має менторити, давати напрямок на рев’ю, вести джуна. Звичано класно коли прийшов джун і знає SOLID, патерни та легко пише простий код, але на моїй практиці це нереально навіть з сенйорами, не кажучи вже про мідлів і тим паче джунів.

Угадайте какого джуна я выберу как лид.

Если джун знает теорию — ему меньше потом надо будет объяснять вот и все.

Я на своїй практиці сенйорів мало бачив які знають терію SOLID, патерни, а ви хочете це від джуна :) Або мені не везло, або у нас різне відношення до знаю/розумію.

Короче, изучить теорию это не сложно. Принципы довольно хорошо описаны в любой литературе.
Для джуна знать как это технически вполне достаточно.
Далее на практике применение — тут надо лет 10 программировать чтобы понять как это действительно работает.

Далее на практике применение — тут надо лет 10 программировать чтобы понять как это действительно работает.

Це мені нагадає таку аналогію. Першоклашкам дають почитати інтеграли, ліміти, а років через 10 вони зрозуміють навіщо вони це прочитали в першому класі :)))

Я на своїй практиці сенйорів мало бачив які знають терію SOLID, патерни

Этому есть крайне рациональное объснение. Синиор никогда не станет городить на проекте солид и паттерны. В адекватном проекте (даже очень большом) от силы применяется 1-2 паттерна. Никто на проекте не будет часами въезжать в чужую гениальную иерархию наследования (нет), а просто впишет свою строчку кода и пойдет за другой задачей.

статья наипсана так, чтобы гарантировать человеку трудоустройство при удачном стечении обстоятельств и он был в топ 10% по знаниям среди таких же как он.

гарантировать человеку трудоустройство
при удачном стечении обстоятельств

це дві протилежні обставини. чи не так?

З приводу SOLID і патернів та

он был в топ 10% по знаниям среди таких же как он.

Я всього декілька разів зустрічав на співбесідах сінйорів з якими про це можна було вільно поспілкуватись (про джунів та мідлів мова навіть не йде). Не теорія і зазубрені речення, а вільна розмова з прикладами, які співрозмовник легко формулює і не плутає терміни. І це все рівно не гарантувало їм працевлаштування.
Нерозумію навіщо мучати джунів цими питаннями. Він все рівно не буде це використовувати наближчий рік чи півтора, а то і більше, а розуміти ще довше. Набагато краще, щоб джун знав мову(синтаксис та база ООП), IDE і слухав ліда і поменше бажання писати новий «фейсбук», а займатися рутиною, де набивати практику.

це дві протилежні обставини. чи не так?

Не так. Вы сейчас семантические противоречия ищите как человек, всю жизнь писавший код. А я предлагаю в саму суть взглянуть: мы можем только максимизировать вероятность на дистанции. Сколько вы людей менторили и довели до найма ?

Не пам’ятаю точно, але десь більше 100

А что тогда из моих слов вам не понятно :))?

не розумію ваше питання. я ж написав

А я не понимаю цель вашего спора, я даю цельную систему как прийти из точки а в точку б. Так же даю методические рекомендации, материалы. Если есть что по делу написать — давайте. Если не нравится материал — велкам, пишите свой.

Моя ціль: розказати джунам, що все набагато простіше. І не варто витрачати час на те, що вони не будуть найближчим часом використовувати. Якщо ціль клієнта набрати програмістів зі знаннями SOLID і патернів і назвати їх «джунами», то ок. Але так і потрібно це називати.

Disagree

Для трейни может и да. Но хороший джуниор это условный миддл по теоретическим знаниям, но не имеющий достаточно опыта.
Жду от вас статью с разоблачением :)

дла вас писати мені лінь, а всі свої думки я тут виклав — якщо джуни з мізками, вони почитають і приймуть рішення.

И потом это чудо будет пытаться лепить эти паттерны во все места в течении следующих трех лет на всех местах работы где успеет побывать. И только потом дойдет, что весь этот FizzBuzzEnterprise не способен выжить за пределами FizzBuzzEnterprise. Но будет поздно. Время будет просрано на булшит, а куча проектов загажено текучими абстракциями. Поразительно тупо сидеть надрачивать на паттерны, когда в то же время знания СУБД и ее возможностей околонулевые.

сподіваюсь у цього джуна буде адекватний лід, який за 2-3 ревью вкаже йому необхідний шлях.

А ще, SOLID та патерни — то два різних напрямки думки. Кожен вважає себе єдиним правильним та не зважає на іншого.

SOLID — це Design Principles

то два різних напрямки думки

First we will examine
the principles, and then the techniques, or design patterns, that help maintain the
dependency architecture of an application.
web.archive.org/...​inciples_and_Patterns.pdf

Я геть не певен, що його принципи працюють.
А от патерни — працюють.
Було б цікаво десь побачити статтю, як саме той SOLID втілений в класичних архітектурних патернах, на зразок Pipes and Filters, Half-Sync/Half-Async, Proactor, Blackboard, Ports and Adapters, Microservices. Бо може виявитись, що ця класика імплементить якусь 1-2 літери з абревіатури, а на інші — геть забиває. Бо патерни взагалі до того соліду ортогональні. І при цьому, патерни — це практика, а солід — це теорія. Така ж, як і те, що в функції чи методі має відбуватись близько 7 дій.

«нічого не зрозуміло, але дуже цікаво» © :)

«нічого не зрозуміло, але дуже цікаво»

Пояснюю на прикладі з життя.
Ось треба туалет полагодити, бо протікає.
Викликаєте майстра, й починаєте йому розповідати за сопромат.
А він виймає з чемоданчика інструменти, й працює.
За 5 хвилин унітаз залатали, а лекція про сопромат ще на середині.

От солід — це сопромат. Патерни — це інструменти з чемоданчика.

І оті принципи про розширюваність класів нікому нафіг не здалися, бо класи з бізнес-логікою пишуться один раз, ніколи не реюзаються і не наслідуються. Бо prefer composition over inheritance (GoF).

Все верно , бизнес логику удобней писать используя функциональные подходы. Однако, так не всегда. Бывает проект выходит за рамки крудов. Наследование решает свою задачу — сильного связывания, а не переиспользования кода

Наследование решает свою задачу — сильного связывания, а не переиспользования кода

Наследование интерфейсов? Тогда оно никак не соотносится с open-closed principle.

BTW на С++ бизнес логика вполне нормально пишется и быстро работает.

Наследование интерфейсов тут не причем. Я говорил про наследования классов.

Связывание — это coupling или cohesion?
И как наследование классов решает любую из них лучше, чем композиция?

cohesion

Наследование — есть инструмент фиксации дизайна и отношения классов. То, что будет сложно сломать.
Для всего остального подходит лучше агрегация, а не композиция. Композицию я бы вообще редко использовал.

Наследование — есть инструмент фиксации дизайна и отношения классов. То, что будет сложно сломать.

Часто бизнес логика не требует наследования. В том же DDD будет упор на правила взаимодействия объектов. В паттернах — неглубокое наследование обычно.

Поэтому, я бы не считал наследование важной частью высокоуровневой архитектуры. Намного важнее процессы/потоки и живущие в них модули.

Потом, неправильное наследование еще надо уметь распутать en.wikipedia.org/...​ki/Circle—ellipse_problem а вы хотите его фиксировать сразу.

Для всего остального подходит лучше агрегация, а не композиция. Композицию я бы вообще редко использовал.

Композиция быстрее работает, и не приводит к утечкам ресурсов ithare.com/...​t-punishment-for-failure

Разные проекты бывают. Если вы пишите на С++ то в C# все немного иначе, и бизнес-задачи другие.
Ну у вас в проектах часто не требовало, а если это системы где пару сотен человек работают большой сложности, там всякое бывает.
В целом согласен что много где не нужно решать задачи наследованием, но бывает что и надо.
Насчет скорости работы — это вторичная вещь для энтерпрайза на C# или джавы, в сишарпе не особо парятся с утечками ресурсов, есть сборщик мусора и рекоммендации по написанию кода.

Сборщик мусора не разрулит необнуленные указатели — не замечали, как использование памяти растет со временем работы программы? Об этом и статья. Когда композиция — меньше указателей (ссылок), и тяжелее утечь памяти.

В C# не думают ни об указателях ни об сборщике мусора

Да, и получают увеличение потребления памяти при длительной работе программы.

Меня улыбает забота об утечках памяти в сишарпе, когда в то же время каждый первый дотнет дев настолько неумело использует ентити фреймворк что ttfb запросов по 5-10 секунд.

Два лайки! А ще дехто примудрюється написати алгоритм складность н в кубі...

В C# не думают ни об указателях ни об сборщике мусора

Аха, і потім отримують меморі ліки. Взагалі непогане питання для співбесіди, візьму на озброєння під назвою «питання Фурдака»))

Ну есть несколько принципов как писать код чтобы небыло ликов
Но это не про указатели

Ну есть несколько принципов как писать код чтобы небыло ликов
Но это не про указатели

Але про гарбейдж коллектор. І думати про нього треба) Хоча б із розрахунку перфоменса)
Хоча вказівники теж зустрічаються, але не у типових задачах. Інтероп і все таке інше...

хіба для гарбедж колектора є різниця між вказівником та референсом?

In managed applications memory leaks are a bit trickier. Since the runtime can track references to resources automatically, it can also understand when a resource (an object) is no longer referenced by any active part of the application (there is no chain of references from a stack frame to that resource on any thread) and thus the runtime can understand when is safe to collect the objects no longer references by the application. So in managed world a a ’leak’ would occur when you believe that the applicaiton no longer references an object (and thus it can be collected by the runtime) but in fact, through some chain of references, you do have a reference to it and thus it cannot be collected.
(stackoverflow)

хіба для гарбедж колектора є різниця між вказівником та референсом?

Я дещо про інше писав, про те, що вказівники теж зустрічаються у .net world
Й означив це окремою фразою, але, мабуть недостатньо distinctive)

Пояснюю на прикладі з життя.
Ось треба туалет полагодити, бо протікає.
Викликаєте майстра, й починаєте йому розповідати за сопромат.
А він виймає з чемоданчика інструменти, й працює.
За 5 хвилин унітаз залатали, а лекція про сопромат ще на середині.

От солід — це сопромат. Патерни — це інструменти з чемоданчика.

І оті принципи про розширюваність класів нікому нафіг не здалися, бо класи з бізнес-логікою пишуться один раз, ніколи не реюзаються і не наслідуються. Бо prefer composition over inheritance (GoF).

Принципи (SOLID):
Кожна людина має ходити до туалету, іншому випадку буде бо-бо.
Патерн:
Туалет може бути коробкою з диркою внизу.

Те що ви описали, показує, що дійсно прості задачі можна вирішувати швидко і в якійсь мірі якісно, навіть не розуміючи як воно працює. Якщо ціль життя ремонтувати туалети — то ок, але якщо будувати мости, хмарочоси, запускати кораблі до космосу — то вивчити і застосовувати знання сопромату прийдеться.
Так багато програмістів і живуть. Це не погано і не добре. Так є. Вибір за людиною.

SOLID — це принципи побудови кладних системи, патерни — це досвід, щоб не придумувати знову колесо, а взяти те що є і працює і піти далі: швидше і якісніше. В свою чергу патерни допомагають вирішити деякі принципи SOLID. І тому писати, що:

Незнание SOLID не несет последствий. Значит, SOLID бесполезен по сравнению с паттернами.

Вибачте — дурня. Це просто різні речі.

Але питання так і залишилось без відповіді:

Навіщо це джуну?

Пускай на вопросы ответит тот, кому адресованы, но вставлю свои пять копеек: джун это такой же профессионал, способный решать задачи. Ему тоже неплохо знать инженерные практики.

Дивіться. Джун — це першоклашка. Буде він знати інженерну практику, чи буде він професіоналом — залежить звичайно від нього, його бажання, від ліда, від обставин та часу та ще багато чого. Дати йому зазубрити SOLID та патерни, а потім пройтися щоб він це зачитав? І що? він зразу почне приймати архітектурні рішнення, чи він зможе це ефективно використовувати? Який сенс на це витрачати час і зусилля джуна? Він плутається у overload/override, а ви йому розкажи про Ліскова та як ти це будеш вирішувати :) Мені шкода ваших джунів...

Некоторые концепции проще чем кажутся если их расскажет опытный человек. Но чтобы они лягли в понимание — нужно их хотя бы зазубрить как подают учебники.

overload/override

Сорри, но это трейни, а не джун.

нужно их хотя бы зазубрить как подают учебники.

зазубрив першоклашка інтеграли і ліміти, ви зразу йому дасте вирішити диф. рівнання?
Чи може джуну дасте писати критичний код?

Сорри, но это трейни, а не джун.

А якщо він не знає SOLID та патернів? Також трейні? :)))

Для этого читайте мою доку и переставайте )

А синиор это, человек который сознательно не использует в своем коде

overload/override
SOLID — це принципи побудови кладних системи, патерни — це досвід, щоб не придумувати знову колесо

 От я не бачу, щоб «принципи» втілювалися в «досвіді» побудови класних систем. Може, принципи штучні?

Може, принципи штучні?

Якщо ви не знаєте як працюють принципи або не вмієте їх використовувати, то це не доводить що їх немає або вони штучні. Коли почали вивчати сопромат? А коли почали будувати мости, будинки?

Можете, замість тверджень, що опонент щось там недовчив, довести, що SOLID є основою архітектурних патернів?

Бо ж поки з вашого боку лише аксіоматичні вислови та спроби з’їхати з теми. Можете показати, що патерни грунтуються на SOLID — покажіть. Не можете — визнайте, що або ви самі не достатньо добре розумієте тему, або що архітектурні патерни не грунтуються на SOLID.

Моя особиста думка, що SOLID є якоюсь підмножиною архітектурних принципів, і може бути шкідливо звертати увагу лише на цю підмножину.

мені лінь вам писати те що давно все розжували і написали в інеті. Читайте:
stackoverflow.com/a/31318178
там же
stackoverflow.com/a/54086063

мені лінь вам писати те що давно все розжували і написали в інеті. Читайте:
stackoverflow.com/a/31318178
там же
stackoverflow.com/a/54086063

Там нічого корисного. Ліньки доводити — не сперечайтесь, ніби маєте докази. Також, не плутайте архітектурні патерни та дизайн патерни.

Там нічого корисного.

Ну нічого так нічого :) «Сопромату не існує» :)

Також, не плутайте архітектурні патерни та дизайн патерни.

про архітектурні мова навіть не йде. я про них не писав.

про архітектурні мова навіть не йде. я про них не писав.

А я весь час пишу про архітектурні — передивіться коментарі.

І якщо ви пишете про дизайн патерни, а не про архітектурні, то чому? Вважаєте, що дизайн патерни ближче до базових принципів (сопромату), ніж архітектурні? Чи вважаєте, що SOLID настільки не корелює з цими базовими принципами, що він не має бути їх підгрунтям?

передивіться коментарі.

от і почніть з себе :) я вже писав у цій гілці (яку я створив) чому я вважаю що джун повинен знати KISS та DRY.

І якщо ви пишете про дизайн патерни, а не про архітектурні, то чому?

тому що тема про джунів :) їм до архітектури як до Києва рачки.

Архитектурные паттерны вами описанные это лишь способ организации кода высокоуровневый в рамках одного сервиса. SOLID это о другом, это принципы проектирования, на которые можно опираться в любой имплементации.

Архитектурные паттерны вами описанные это лишь способ организации кода высокоуровневый в рамках одного сервиса. SOLID это о другом, это принципы проектирования, на которые можно опираться в любой имплементации.

Вы смогли применить SOLID между сервисами? Расскажите.

Или покажите применение SOLID к CQRS, и как из него следуют Enterprise Integration Patterns, или там оркестратор с хореографией.

Иначе получается, что про SOLID можно много говорить, а как к делу — то нам нужны вообще другие вещи.

Вы смогли применить SOLID между сервисами? Расскажите.

Этого я не писал. SOLID — принципы проектирования кода в рамках одного сервиса(приложения).

Или покажите применение SOLID к CQRS

CQRS — это конкретный паттерн хранения и обработки данных. SOLID это общие рекоммендации по дизайну. Проектируя обвертки для CQRS вы можете прибегать к принципам SOLID если вам нужно будет.

Ну тогда объясните разницу между:

Архитектурные паттерны вами описанные это лишь способ организации кода высокоуровневый в рамках одного сервиса. SOLID это о другом, это принципы проектирования, на которые можно опираться в любой имплементации.

и

Этого я не писал. SOLID — принципы проектирования кода в рамках одного сервиса(приложения).

Итого, вы имеете в виду, что солид применим между сервисами, или он применим только в рамках одного сервиса?

CQRS — это конкретный паттерн хранения и обработки данных.

Скорее, паттерн system architecture, который разделяет базу на read-only OLAP и write-enabled OLTP сервисы, что приводит к переосмыслению архитектуры, вплоть до того, что для OLAP выставляется пользователю голый SQL без DAO.
medium.com/...​rchitectures-5d41e359768c
И вот тут вопрос: если солид — это такая базовая теория, очень нужная всем, то как из нее следуют CQRS с разделение базы и микросервисы. А если из нее такие нужные вещи не следуют, как и другие паттерны не следуют, то нафиг надо теория, не описывающая практику?

Блин, я ж пишу солид это дизайн-принципы организации кода. Я ничего не писал про другие сервисы или их взаимодействиею.

Скорее, паттерн system architecture, который разделяет базу на read-only OLAP и write-enabled OLTP сервисы, что приводит к переосмыслению архитектуры, вплоть до того, что для OLAP выставляется пользователю голый SQL без DAO.

Молодец пять)

то как из нее следуют CQRS с разделение базы и микросервисы.

Никак.

то нафиг надо теория, не описывающая практику

Перечитайте SOLID, там про дизайн/имплементацию, что есть частью прктики.

Зайдем с еще одной стороны.

Нарушение CQRS грозит тем, что наша система не справится с нагрузкой, и прийдется половину кода переписывать нафиг, разделяя доступ к базе.

Нарушение модульности грозит скатыванием в monolithic hell, и очень медленной разработкой.

Неправильный дизайн по многопоточности приведет к неотлаживаемому коду и невозможности выполнить нефункциональные требования.

К чему приведет нарушение солид?

Нарушение CQRS

Я бы не вводил формулировки нарушением CQRS. Вы когда проектируете систему есть NFR определенные. Прежде чем релизить вы проверяете способности написанного кода на разных серверах.CQRS — это лишь идея, имплементаций миллион.

К чему приведет нарушение солид

SOLID нельзя нарушать, потому что это рекоммендации, а не жесткие нормы написания кода. Вы можете пользоваться, а можете нет отдельными принципами. Но в целом мы решаем проблему снижения технического долга, декомпозиции, повышения уровня абстракции, короче, если принципы использовать где это уместно это упростит жизнь потом. Вы можете не называть это solid, а назвать просто адекватностью.

Прежде чем релизить вы проверяете способности написанного кода на разных серверах.

И вот тут обнаруживается, что сервера не хватает, а надо релизить, а чтобы хватало сервера надо разносить OLAP и OLTP, а это — еще год работы, а надо релизить. Цена ошибки — потеря рынка.

CQRS — это лишь идея, имплементаций миллион.

Да, CQRS — это архитектурный паттерн, применимый в определенных условиях, и нарушение его может убить проект.

Но в целом мы решаем проблему снижения технического долга, декомпозиции, повышения уровня абстракции, короче, если принципы использовать где это уместно это упростит жизнь потом.

И вот тут у нас сравнение риска для жизнеспособности проекта под нагрузкой (NFR) против «снижения технического долга» или «упростит жизнь потом». Что важнее?

Вот мы и пришли к разговорам о сопромате против чемоданчика с инструментами для починки унитаза.

И вот тут обнаруживается, что сервера не хватает, а надо релизить, а чтобы хватало сервера надо разносить OLAP и OLTP, а это — еще год работы, а надо релизить. Цена ошибки — потеря рынка.

Что-то вы сгущаете краски) Значит думать надо на этапе проектирования.

И вот тут у нас сравнение риска для жизнеспособности проекта под нагрузкой (NFR) против «снижения технического долга» или «упростит жизнь потом». Что важнее?

Вы что-то сравниваете ложку с бананом. Не понял мысли, сорри.

Мысль о том, что незнание паттернов завалит NFR вместе с проектом. Или будет vendor lock-in. Или еще 100500 граблей разной степени тяжести. Незнание SOLID не несет последствий. Значит, SOLID бесполезен по сравнению с паттернами.

Не вижу логики в вашем утверждении. Одно из друого не вытекает.

Не вижу логики в вашем утверждении. Одно из друого не вытекает.

Ну, воспаление легких можно лечить антибиотиками или гомеопатией. Только если не лечить антибиотиками — то хороший шанс окочуриться. Но из этого не следует, что гомеопатия бесполезна для лечения.
Да?

Я не понимаю, в чем вам концепции солид противоречат? Принципы I & O конечно не всегда применимы

Меня раздражает, что с этим SOLID много бегают и шумят, прямо как со SCRUM. А реального толку намного меньше, чем рекламы. Зато создает иллюзию всезнания.

Так не бегайте и не шумите
Хорошие принципы

Про CQRS мав нагоду поспілкуватися з Грегом Янгом — ніби він це придумав. В нього дуже здоровий підхід — починати з функціональної декомпозиції.

Але ж чомусь не з SOLID починає?

Фейсбук також варто написати. Ніколи не шкодував про написане. Тільки про ненаписане...

Так, сам таким страдав, але вдома, а не на роботі, коли потрібно вирішити задачу/проблему зараз, а не через місяць.

Круто все написано, особливо про англ мову

дякую, потихеньку пишу свій pet project, і ваша стаття стала в пригоді

Підписатись на коментарі