Прошу оцінити мій код

anonymous 24.08.2022 00:01

Коментар порушує правила спільноти і видалений модераторами.

Sergiy Morenets Java evangelist 06.08.2022 12:36

Коли я бачу список полів, які не розділені рядком, відразу розумію, що писав intern/junior.

private SelectedList(){}
public U Request{get;set;}
public List Items{get;set;}
public int PageQuantity{get;set;}

Відповісти

Підтримати

Максим Касьяненко 06.08.2022 14:36

Я не intern і не junior. Я електромонтер і як раз намагаюсь зрозуміти, чи МІГ БИ я стати intern/junior. Звичайно, я мріяв стати спеціалістом в IT, та поки у мене була робота це було скоріше хоббі. Зараз, коли я вимушений починати життя з нуля, я маю обрати шлях... А ви просто мені у цьому допомагаєте ;-)

Відповісти

Підтримати

Sergiy Morenets

Oleg Kotok Software Engineer в VELOMAT Messelektronik GmbH 24.08.2022 08:24

так їдь закордон, там електромонтери нормально заробляють

Відповісти

Підтримати

Максим Касьяненко

Alexander Milashenko Software Developer в Google 06.08.2022 00:02

Я б ще додав:
1. Намагайтесь бити аппку на рівні (View, Domain, DataLayer).
2. Використання Session та ViewData/ViewBag краще звести до мінімуму (для зберігання корзину можна зберігати в браузері для неавторизованних користувачів та в базі для авторизованних, або обійтися лише базою)
3. Для валідаціі можна використати FluentValidator (справа смаку, але допомагая знемншити кількість кода та винести валідацію в окреме місце)
4. Раджу взяти за звичку писати кастомні Exception-и а не тільки кастомний меседж (так легше наприклад зробити ExceptionFilterAttribute/Middleware та слати 400/500/etc. в залежності від типу Exception-а (можливо там же й логувати))
5. В контроллерах не має бути логіки та View елементів (наприклад тексту для фронту)
6. Місцями моделі мають данні, що їм не притаманні. Наприклад PhoneNumber (номеру телефона не належить інформація щодо власника, радше навпаки)
7. Коли ви визначили що належить до Domain/DataLayer, можно розбити їх на меньші частини.
Для Domain гарно підійде концепція DDD (почитайте частину про BoundedContexts) + бажано відділяти контракти від імплементації (таким чином ви себе спонукаєте не використовувати деталі, лише контракти)
8. IMHO: я б ховав деталі EntityFramework на рівні DataLayer та використовував кастомні репозиторії (та інтерфейси для них) на рівні Domain (таким чином ви не тягаєте зайві dependencies та залишаєте собі якийсь простір для маневру в питанні вибору ORM).
9. В комментарях/error/validation message/etc. краще користуватися тільки англійською.
Інші мови маюсь залишатися на рівні Front-end або в resources для перекладів (але не факт що воно вам наразі потрібно)
10. Робота з датами: завжди порівнюйте дати в UTC (з явним приведенням). Це може здаватися чимось маленьким, але краще візьміть це за звичку одразу.

Взагалі, я б радше радив почитати про DDD, але обережно. Не все звідти потрібно брати для КОЖНОГО проекту, але воно гарно описує як треба підходити до бачення предментої області свого проекту (не знаю як виразити це доречніше).

Ще порадив би знайти когось, хто може приділяти вам декілька годин часу (на тиждень?) щоб зробити code review та порадити що почитати далі.

До CQRS ще порадив би подивитись event sourcing, але (як на мене) CQRS + event sourcing може бути не самою простою темою для розуміння (якщо ви початківець)

Відповісти

Підтримати

anonymous 06.08.2022 01:09

-

Відповісти

Підтримати

Alexander Milashenko

Alexander Milashenko Software Developer в Google 06.08.2022 02:11

частково.
Так буде зайвий boilerplate.
Втрачається потужність ORM — не обов’язково.
Але саме через це, цей пункт це IMHO (ну тобто, це суб’єктивне як на мене)

Відповісти

Підтримати

anonymous

Oleksandr Suvorov https://spgr.org.ua/uk/ в Qualcomm Inc. 05.08.2022 21:39

По C# розказали. Розкажу про комміти. Вони мають відповідати певним крітеріям:
— автономність. Після кожного коміту проект має збиратись.
— атомарність. Не можна змішувати декілька логічно і функціонально різних змін в одному коміті.
— інкрементність. Коміти, що вводять нові сутності, мають бути раніше за код, який їх використовує.
У dfc є коміти, які міняють 10 речей одразу. Це робить підтримку проекта важкою.

Про пусті commit messages вже сказали. Тут непогано описаний загальний принцип написання commit messages:
initialcommit.com/...t-messages-best-practices

Відповісти

Підтримати

Максим Касьяненко 05.08.2022 23:01

Дякую

Відповісти

Підтримати

Oleksandr Suvorov