Комментарии 50
Сложно будет достигнуть заявленной цели если код на гитхабе в нормально виде даже не выложен. Архив с исходниками, как сейчас, можно выложить на любой хостинг или облако. Сила open source и github в частности при этом ни как не используется. Много-много лет назад исходники и работу над ними могли делать через копирование архивов, но в 2021 году это смотрится очень плохо.
Я ничуть не хочу умалить продленную работу, но она так в таким плохом виде представлена, что уже на фазе просмотра исходников я думаю много кто из перешедших в гитхаб отвалятся.
Создается ощущение, что вы не понимаете его предназначения. Это не хостинг.
Вопрос по теме. Какие готовые решения рассматривались, и рассматривались ли вообще? Что есть в этом проекте, чего нет в то Mattermost, ejabberd или другом схожем ПО?
Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живёте
Я про эти модули. Почему нельзя все то что отвечает за работу с БД вынести в модуль и подключать и использовать только то что нужно? Сделать модели в которых определять структуру таблицы и методы которой модель обладает. Например Комнаты — создать комнату, найти, удалить и т.д. Запрос напрямую писать удобно, но неудобно потом читать. А код читают намного чаще чем пишут. Роутер отделить удобно, всю логику выделить в контроллеры. Так же и с разметкой. Есть же шаблонизаторы (ejs например), что бы не использовать такие конструкции:
ends = parts[parts.length-1].split("\n");
result += "<div class='step step0'><h3>"+head[0]+"</h3><span>"+head[1]+"</span><button class='btn btn-default' onclick='qst($(this),0)'>пройти квест</button></div>"Почитайте шаблоны, книжку посвежее. Мне понравилась Каскиаро «Шаблоны проектирования NodeJS». Да и в 2015 году появилось много синтаксических улучшений языка. const, let вместо var, шаблонные строки, деструктуризация, rest оператор и др. Посмотрите современный Google JavaScript Style Guide
Посмотрел код — созрел вопрос: сколько Вам лет?
Возможно, кто-то обратит внимание на хорошую разработку
На мой (возможно, предвзятый) взгляд назвать это хорошей разработкой никак нельзя.
Отсутствие документации. Хардкод всего подряд. Закомментированный код. Код в одном файле.
Такое ощущение, что вы современных практик не видели.
Если вы считаете нужным запилить документацию по самому движку, то есть по коду, то в принципе я могу ее сделать.
Код сервера не очень большой и я не вижу ничего плохого чтобы держать его отдельно (возможно имеет смысл вынести только конфиги). Вообще меня больше смущает клиентская часть.
Код сервера не очень большой и я не вижу ничего плохого чтобы держать его отдельно
Вы — не видите, да. А для меня это признак плохого кода.
(Там две с половиной тысячи строк кода, это "не очень большой"?)
Поэтому в нём легко разобраться даже новичку
Нет, не просто.
Там только обработка хттп запросов и сообщений от клиентского сокета.
То есть обращений к БД там нет? Работы с файловой системой там нет? Обработки команд там нет?
А так-то любое веб-приложение — это "только обработка хттп-запросов", только это не повод его в один файл класть.
но если вы захотите внести какие-либо правки, вы легко разберетесь
Угу. Я вот зашел в ваш репозиторий и захотел даже не правки внести, а просто запустить локально, чтобы попробовать. Как? Неизвестно.
Угу. "Небольшая". Небольшая выглядит так:
git clonemake buildrun
А у вас — гигантская. Я процитирую кусочки.
поочередно установить все модули используемые в require.
Серьезно? В node нет автоматической установки пакетов? А какие версии ставить? Или пофиг, всегда (не) будет работать?
Особенно это весело, учитывая, что require у вас не в одном месте списочком, а перемешаны с кодом (привет с 330 строки).
Затем надо исправить основые конфигурации в srv.js
Что такое "основные конфигурации", где они расположены, какие значения можно править и какие допустимы?
убедиться, что все патчи в контролерах для upload и uploadone соответствуют расположению корневого каталога чата на сервере
"Все". А как найти "все"? А где конкретно искать контроллеры? А с правами проблем не будет?
И это все при том, что уважающее себя веб-приложение (а) само умеет определять свой путь на сервере (б) всеми силами старается в него не писать.
Затем сгенерируйте https ключи для сайта и укажите путь к ним в том же srv.js
А про https termination вы не слышали?
В общем, да, это readme только подтверждает мои тезисы про качество кода.
… да в принципе одного домена, захардкоженного по всему коду, достаточно, чтобы сказать, что это плохой код.
Но это не значит что код плохой.
Да нет, эти недостатки как раз значат, что код плохой.
Очень жаль, что вы этого не понимаете.
Это просто сайт, который я собрал на коленке под свой сервер.
Я и говорю: "сайт, который собрал на коленке под свой сервер" — это не "хорошая разработка".
А сейчас я надеюсь, что кто-нибудь оценит как там всё устроенно, и продолжит работу над ним.
Так о том и речь, что плохо устроено. Количество усилий на приведение этого в нормальный вид как бы не сопоставимо с написанием с нуля (или, тем паче, использованием готовых решений).
Простой пример: вот захочу я, скажем, чтобы логин интегрировался с соцсетями. Сколько мест придется править?
Но могу сказать что это у меня заняло бы не больше половины рабочего дня.
Возможно. Но сколько мест для этого придется поправить? И насколько сложно это будет для человека, который решил ваш код развернуть у себя на сайте для своих целей?
Ответы на эти вопросы и отличают хорошую разработку от плохой.
Для разворачивания проекта нужно только поправить конфиги и тот путь, который много где повторяется. Да, это небольшой косяк. И еще установить модули из require. Всё это в сумме не должно занять больше часа. Трудности могут возникнуть только у человека, далекого от программирования (но я писал, что готов помочь тем, кому интересно этим заняться)
Ну тут в основном работа по фронтенду. От социальной сети нам надо только название этой сети и ид пользователя внутри нее. В целом регистрация остается той же, кроме добавки двух дополнительных полей в базу данных.
Оу, понятно. Вы, на самом деле, кажется не в курсе, как такая аутентификация внутри устроена.
Для разворачивания проекта нужно только поправить конфиги и тот путь, который много где повторяется. Да, это небольшой косяк. И еще установить модули из require. Всё это в сумме не должно занять больше часа.
Вы не поняли вопроса. Вопрос был: насколько сложно для меня будет добавить аутентификацию через сторонних провайдеров, если я решу форкнуть ваш код для своих целей?
Вы не поняли вопроса. Вопрос был: насколько сложно для меня будет добавить аутентификацию через сторонних провайдеров, если я решу форкнуть ваш код для своих целей?
Ну для ноды есть множество готовых решений для этого, которые избавят Вас от лишних проблем. Но возможно эти нововведения затронут работу капчи. Я ответил на Ваш вопрос?
Если вы не хотите даже понять, почему такой код считается плохим, как вы будете прогрессировать? Огромный кусок на 2K с лишнем строк, сплошные if-else-if-else, смазанные switch-case, огромные функции, все в перемешку. Если пытаться тут что-то улучшать, в какой-то момент вся эта конструкция развалится.
Смысл любых приложений с чатами может и есть в случае
1) мы вернулись в 1995 год
2) мы получили чат готовый к работе который может масштабироваться на миллионы одновременных пользователей.
Все остальное стони раз описано а medium в разных вариациях. Хотя идея с каналами мне например понравилась.
Сайт подбора choosealicense.com
Вам справедливо пишут о недостатках в коде. Посмотрите, например, на строку 2128. Там глубина отступа составляет порядка 15 отступов, хотя рекомендуется не делать глубину более 4-5 отступов. У вас функции по 500 строк длиной, как их читать? Ограничьтесь 30-40 строками на функцию.
То, что у вас — не код, а нечитаемая лапша, где все идет вперемешку, и работа с БД, и формирование ответа. Нужно разбивать код на отдельные действия вроде:
const user = await findUserById(userId);
const json = userToJson(user);Такую функцию на 10 строк будет гораздо легче прочесть, чем 500 строк вашей лапши.
А вы пишете все лапшой, без разбиения на мелкие части. Вы основы яваскрипта изучили, а как делать код читаемым — не изучили. Разбейте код на мелкие функции. Их будет слишком много для одного файла, и скорее всего придется разнести их по нескольким файлам.
Используйте async/await вместо анонимных функций, вложенных друг в друга. Вместо одного обработчика /act с большим switch внутри лучше сделать на каждый случай отдельный обработчик.
Все параметры вроде путей, доменов, паролей надо вынести в отдельный конфиг. Сейчас вроде .env файлы в моде.
В общем, код надо переписывать. Так как читать его тяжело.
Также, на Гитхабе стоит сделать файл README.md в котором кратко описать: что это за проект, как его запустить.
и новости, и чат на одной странице — что-то есть в этом. канал аниме — это типичная имиджборда с элементами дискорда (типа список участников колонкой справа). еще и рисовач есть, как в теплом ламповом ВК, когда еще на стене рисовать можно было.
регистрация просто отстой, переусложнена. но автор в предыдущей статье рассказывает, что она ему очень нравится. и вообще всюду сквозит сельский снобизм автора — эти дрочеры, эти анонимусы, зачем обертки к бд? думаю, это молодость, автору всего 27 — для разработчика это всё еще время становления и экспериментов #сарказм
конечно, не хватает аудитории. причем какой-то такой «своей». ну, т.е. постоянных анимешников или спортклуба какого-то, которые бы общались и мемасились каждый вечер, но это, вероятно, автор задрот сам где-то зависает, идею запилил, а аудиторию не перетащить так просто с насиженной площадки.
код — это просто сплошной «вот так вот не надо», сейчас в тиктоке много видео с этой мелодией, по этому коду в любое место ткни, сними видео и в рекомендованное тиктока зайдешь на ура!
в итоге,
1. автору спасибо, от самих статей куча положительных эмоций (разбирать на мемы-стереотипы про программистов из техана, цитаты из статьи на футболках печатать можно, это прямо хабрастендап какой-то, в комментариях живое юморное общение, автор из образа не выходит — огонь!)
2. идея норм, жаль что не в текущей реализации не взлетит, т.к. автор не подсадит кого-то на регулярное использование кравча (но про это как раз и есть эта статья, не так ли?)
Постараюсь чуть более мягко объяснить позиции комментаторов выше. Open Source хоть и весь такой из себя свободный, но следует определенным принципам, в частности, если хотите, чтобы ваше детище не заглохло, а было подхвачено сообществом, то его необходимо подобающим образом оформить, собственно, даже сам github некоторые советы по этому поводу дает. Не стану высказываться по поводу качества кода — тут уже до меня многие все сказали, да и различных книг по теме архитектуры кодовой базы написано множество, а вот про публикацию кода немного скажу. Дело в том, что, зачастую, оказывается, что подготовить даже нормально написанный код для публикации на girhub может занимать больше времени, чем написание самого кода. Например, необходим нормальный README хотя бы с пояснением сути проекта и основных действий для "пощупать". Пояснительные комментарии к неочевидным частям также необходимы. Неплохо покрыть, хотя бы наиболее важные части кода, автотестами, при этом, прикрутить их к какому-нибудь travis или подобному. В идеале же нужна полноценная документация в виде отдельного сайта или github-pages, шаблоны для разных типов issue, обязательно нужна лицензия (для js-кода лучше подходит, как я считаю, MIT или Apache 2.0). Конечно, нужен как до фронта, так и для бека (могут быть в разных репозиториях проекты), package.json со скриптами для сборки и запуска, потому что нормальное приложение должно запускаться примерно так: git clone && cd <repo_dir> && npm ci && npm run serve. Есть ещё всякие плюшки типа code of conduct, npm audit, swagger и миллион других инструментов, увеличивающих презентабельность проекта в глазах сообщества. Поймите, различных поделок на github миллионы, почему сообщество должно обратить внимание именно на вашу? Напоследок обращу ваше внимание на то, что в рамках README очень полезно описать основные цели проекта, его назначение. Тем самым вы сможете ответить на вопрос — нужен ли он этому миру, да и любой уважающий себя инженер сперва изучает имеющиеся аналоги, а только потом приступает к созданию собственной разработки. Возможно, ответ на последний вопрос и даст вам понять — как же правильно позиционировать и продвигать свое творение. Желаю успехов.
Приведу пример как можно оформлять подобные проекты: pdf2image. Это проект на PHP, но в целом подход для JavaScript под Node.JS будет не сильно отличаться.
По приведенной инструкции человек не программист разворачивал локально на Ununtu 16.04 LTS себе этот проект. Проверено. А вообще в идеале нужно уже в docker упаковать, но в целом это когда-то было тестовое задание и не планировалось как отдельный проект. При этом даже есть работающее демо.
Или такой проект рассчитанный уже на программистов: PHP ОФД SDK. И тут уже упор на тесты, CI, проверку кода. Поэтому прикручен Scrutinizer и Github Actions.
Вот примерно так это должно быть в наше время. Когда индустрия уже наработала достаточное количество готовых сервисов и инструментов для создания продуктов. Подход из нулевых "вот на ftp архив с исходниками, а дальше вы уж сами" закончился чуть больше десяти лет назад.
Чатик с открытым исходным кодом