@Gagatyn
Самоучка

Как найти проекты или репозитории, где показана правильная разработка?

Здравствуйте!

Вопрос поставлен так, потому что сервис этого требует, чтобы была не просьба, а вопрос.
Количество проектов/репозиториев куча.

Сам вопрос. Подскажите, пожалуйста, проекты или репозитории, где показана правильная разработка?
Правильная означает близка к реальной разработке на каком-нибудь из перечисленных фреймворках. Правильная архитектура, правильно расположенные компоненты, api, локализация и т.д. Это все нужно для того, чтобы влиться/научиться правильной или универсальной идеей ведения разработки.

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

Будет очень интересно увидеть список источников.
Спасибо!
  • Вопрос задан
  • 700 просмотров
Пригласить эксперта
Ответы на вопрос 3
Leo5878
@Leo5878
Улыбчивай, люблю учить и учиться
Ну смотри. Тебе следует почитать о прицнипах ООП, функционального програмирования. Будешь лучше понимать, как правильно писать код, чтобы потом не было с ним проблем.
Читай о патернах, методологий (css). Есть в ООП такое понятие как принцип solid

Вот несколько источников, где можо познакомиться с этим:
https://ru.wikipedia.org/wiki/%D0%A0%D0%B0%D0%B7%D...
https://labs-org.ru/obektno-orientirovannoe-vizual...
https://tproger.ru/translations/10-oop-principles/
https://techrocks.ru/2020/08/26/solid-principles-i...
https://medium.com/webbdev/solid-4ffc018077da

О патернах ООП:
https://habr.com/ru/post/136766/
https://proglib.io/p/learn-oop-patterns/ - более новая статья (патерны те же)
https://ru.wikipedia.org/wiki/%D0%A8%D0%B0%D0%B1%D... - познкомишьс с шаблонном проектированием. Рекомендую в википедии взять их названия познакомиться с ними там на каком-то уровне базовом, а потом гуглить их по отдельности, особенно ООП, потому как js является ООП языком и с функциональном программированием, лишним вообще не разу не будет.

Если будешь гуглить такую тематику, то там будут примеры того, что описывает прицип, так лучше будешь понимать, как надо делать и какие плюсы ты получишь от использования. Ну и желателен наставник, который бы указывал на ошибки. Ну и конечно же побольше писать! Еще научиться проводить рефакторинг кода, это когда ты написал функцию, например, а она у тебя большая, сложная и не понятная, а ты знаешь, что функция у тебя должна выполнять ровно одно действие, вот ты и дробишь ее на несколько мелких, меняшь условия на более логичные, менешь название переменных на более понятные и т.д. Сокращаешь код или делаешь его более локаничым, оставляя функционал тот же и вот ты уже можешь переиспользовать любую из функций, просто дав ей нужные аргументы, а что у тебя в условии понятно с полувзгляда, потому что, например, у тебя функция какая-то проверяет условие, возвращет boolean значение и тебе достаточно в if проверить, что тебе вернулось true или false)

А в репозиториях все, что ты поймешь, так это то-что ничего не понятно)))
Масимум увидешь как можно написать ту или иную вещь. Все! Ты больше ничего там не поймешь. Слишком много кода, для анализа, чтобы учиться на твом уровне
Ответ написан
printf
@printf
Ем детей.
Правильная означает близка к реальной разработке на каком-нибудь из перечисленных фреймворках.

1. «Реальная» разработка часто полный антоним «правильной». Причин тому много: фантастические дедлайны, талантливые сотрудники, проверенный временем легаси код, эффективные менеджеры. Худший код, с которым я сталкивался, был в самых дорогих b2b энтерпрайз решениях — реальнее некуда.

2. Перечисленные фреймворки к вопросу не приложились, но т.к. в тегах жаваскрипт, будем считать, что реакт.

Из последнего, на что натыкался, мне понравился Doctocat — это сделанный в Гитхабе шаблон для Gatsby. На мой взгляд, это реально классный пример интеграции реакт-компонент. Используется в продакшене, так что реальная разработка, все дела.

На что обратить внимание:

– Собственно компоненты, их композиция.
– Как задается тема (цвета, шрифты), и как это попадает в стили
– Интеграция с third parties: подсветка кода, поиск
– Кастомизация: через shadowing и всякий ad-hoc
– Работа с MDX, реэкспорт layouts и т.п.

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

Ну и да, не бывает идеальной архитектуры, везде свои плюсы и минусы.

С радостью отвечу на вопросы, тут же есть ЛС, правда?

Удачи!
Ответ написан
Jeer
@Jeer
уверенный пользователь
Привет,
Словосочетание "правильная разработка" порождает лишь неразбериху.
К примеру, ты делаешь какой-то компонент на фронте, на бекенде довольно стандартный CRUD. Но ты можешь сделать один метод Edit, а можешь сделать два метода Create и Update. И то и то правильно в зависимости от ситуации. Дальше, к примеру в методе Create у тебя проставляются пользователь, создавший запись и какое-то ещё поле, которое заполняется на бекенде. При этом, можно использовать одну и ту же модель во всех методах, Details/Create/List/Update. При этом, в метод Create попадёт модель с лишними полями, тот же пользователь, создавший запись. Кто-то скажет, это неправильно, нужно под все методы делать свои модели, если поля не используются, не должно быть возможности их передать. А кто-то скажет, неправильно плодить лишние сущности, пусть поле не используется, оно всё равно на бекенде перезаписывается. А кто-то скажет, что вообще не нужна даже одна промежуточная сущность, можно использовать сущность, которая генерится каким-нибудь инструментом с БД, так как проект представляет собой закрытую админку для внутреннего пользования.
Немного сумбурно, но, надеюсь, понятно.
Дальше идёт расхождение в инструментах, к примеру, требуется делать валидацию входящей модели. Можно использовать Fluent валидацию или использовать декларативный синтаксис через Data Annotation. И то правильно и это правильно, в одном проекте, разумеется, должно использоваться что-то одно, но подход и синтаксис различаются очень сильно. Или так же, необходимо использовать IoC/DI, а инструментов под это несколько и все правильные.
Что касается архитектуры. Опять же, есть несколько подходов и несколько стилей. Нельзя сказать, что один из них правильный, а другой неправильный. Я видел несколько отвратительных проектов, написанных в ООП стиле. При этом, не могу сказать. что подход неправильный и нет хороших проектов, написанных по такому принципу. Я видел огромный проект, отлично написанный в процедурном стиле со слоёной архитектурой контроллер/модель/интерфейс/сервис/энтити. Даже представить себе не могу, если бы его попытались сделать в Domain Driven Design или в компонентном стиле, типа микросервисов.
В общем, нет в этом деле серебряной пули.
Что касается основных "правильных" вещей. Есть спецификации языка и им надо следовать. Если взять, к примеру, ангуляр. То в нём есть свои стандарты, есть сайт с документацией, в которой прописаны правила наименований и прочее. Им надо следовать. Если взять .net, то при выходе новой версии, вместе с ней выходит и спецификация на новые фишки. Так же, в нормальных проектах ведётся свой файл со спецификацией, в котором указаны, в каком порядке следует размещать публичные/приватные поля, что один публичный класс должен быть в отдельном файле и имя файла должно совпадать с именем класса. Так же, при выходе новой версии IDE, под .net это visual studio, внутрь уже встраиваются подсказки, например, если ты написал класс с маленькой буквы, студия это подчеркнёт и укажет, что наименование класса должно быть в PascalCase. В общем, этому надо следовать. Могу скинуть свои файлы на почту.
Могу так же скинуть свой проект на гитхабе, но, как я уже говорил, не факт, что архитектура из того проекта подойдёт, когда вы придёте в другую разработку, там архитектор скажет "это неправильно, мы не так делаем"
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы