Удваиваю beastie. Вебом должен заниматься модуль, который отвечает чисто за веб и ничего больше. А у тебя получается как у меня на работе: всё занимаются всем. Просишь того парня, который за dba накатить базу, а он говорит, мол давай сделаю тебе батник, сам накатывай. И я понимаю, что мне придётся решать все проблемы, которые потенциально может вызвать этот батник. У тебя в коде примерно тоже самое и юзер за каким-то чёртом дёргает http.
Я делал на той неделе одну простую штуку на ноде. Она получает запрос по http, делаёт запрос к базе, засовывает результат в кеш на n секунд и отдаёт его. Так вот, чтобы добавить туда метод в api нужно просто дописать в конфиг запрос с параметрами и их типы, потому что я не настолько работяга, чтобы залазить каждый раз в код веб сервера, прописывать туда route, обработчики и т.п. Стремись к тому, чтобы у тебя код не просто делал регистрацию юзеров, а решал общую задачу - получить запрос, преобразовать его в sql, выполнить, попутно дёргая кучку колбеков.
А кто сказал, что комментарии должны плодотворно влиять на разработку? Этот клоун всех заутомил ещё на этапе изобретения своего языка, потом ещё больше заутомил, кудахтая о том, что есть фейл, а что есть вин, и закономерно оказалось, что даже примитивные вещи он реализовать не может. Не в моих интересах чтобы такие люди попадали в погромирование, в Макдональдсах очереди стоят, некому заказ принять, все погромируют
Если твой DBA не хочет делать свою работу и с ним нельзя договориться на взаимовыгодных условиях, то у него есть начальник, который должен по сигналу дать ему пинка.
Дальше твои замечания делятся на две части.
1. Плохая модульность. Согласен. Но надо сначала решить задачу, а потом уже наводить архитектуру. Пока что всё вполне постижимо (мной). А так вообще модули и SOLID в реальной жизни - это не аксиома, а одна из осей инженерного компромисса. У них тоже есть своя цена - увеличение многословности.
2. Ты рекомендуешь data-driven подход. Это хорошо, когда есть эн конфигураций и известны оси, по которым производится их настройка. В моём случае это пока не так, хотя конфиг-файл у меня тоже есть и в нём порядка 10 значений.
2. Если ты залогинен, и тебе пришли деньги, то баланс не обновится до релогина. Даже хуже - у тебя было 100р, тебе пришло 500 - ты не можешь отправить 200р, потому что форма говорит «НЕДОСТАТОЧНО СРЕДСТВ».
Они там что, проверку баланса делают на фронтенде, что ли?
А, ну получается что так :) Причем альтернатив тинькову нет для меня, но их веб меня просто убивает. И я знаю что у других еще хуже.
Но надо сначала решить задачу, а потом уже наводить архитектуру.
Тогда ты будешь решать задачу 2 раза.
Если твой DBA не хочет делать свою работу
Дело в том, что он не dba, а вместо dba. У нас в принципе тут нет такого понятия, как dba. Я не жалуюсь, это - аналогия.
В моём случае это пока не так
У тебя как минимум есть вебсервер, есть запросы, есть их обработчики. В конфиги можно как минимум вынести роутинг, метод обработчика, вьюхи-шаблоны на случаи успеха и провала. В итоге будет конфиг-файл проекта по которому будет понятно кто где и зачем.
Страдает конечно, там же хеша нет. Откуда он будет знать, что там за релиз. Если поставишь хеш код может внезапно перестать собираться. А еще репозитории иногда удаляют. Тупиковый импорт совершенно.
А я не принимаю эту аналогию, потому что дело именно в этом. Когда я пишу что-то в одно лицо, мне проще держать всё в голове, чем развести x10 писанины только ради удовлетворения каких-то заповедей. Когда проект разделён на мельчайшие модули, в которых 90% формы и только 10% содержания, мне настолько тоскливо это видеть, что я не могу себя заставить хоть что-то делать. Это реальная проблема, и я понимаю, что это моя проблема. Но вообще с т.з оптимизации процесса разработки границы модулей должны быть по границе людей, проектов, атомарных команд. Если наблюдается «три единства классицизма», т.е. единство времени, места и действия, то это один модуль. Потому что он загружается в голову целиком и постигается тоже целиком. Я в это верю. Если чел один, то границы модулей - по границе повторного использования. У меня единичный функционал, который я не собираюсь (пока) повторно использовать.
Если ты хочешь сделать что-то повторно используемое, то сразу встаёт вопрос: как переиспользовать, что параметризовать. Это отдельный вопрос и он не простой. Решать его на раннем этапе - это преждевременная оптимизация. Пока у меня задача, если она есть - это сделать конкретное приложение. А модуль аутентификации я начал писать не ради модуля аутентификации, а по той причине, что не нашёл готового. Т.е. я делал его не ради повторного использования, а ради однократного.
Я понимаю, что всё, что я пишу - это ересь и что ни в какой команде меня не поймут. Так, пишу для себя, чтобы хотя бы самому не разубедиться, что я сделал для своих целей правильно :)
В итоге будет конфиг-файл проекта по которому будет понятно кто где и зачем.
Так все мои обработчики помещаются на одной странице текста, откуда можно за одно нажатие кнопки перейти и понять, что они делают. Но не будем спорить, оба подхода имеют право на жизнь. Возможно, для показа твой вариант и лучше.
Там есть ещё вендоринг, т.е. ты копируешь нужные тебе версии в свой репозиторий и дальше не зависишь от сторонних репозиториев. Я только не знаю, сделали ли они, чтобы можно было не патчить исходники, а просто сказать, что «github.com/budden/semdict» - это такая-то директория. Возможно, в статье про это написано - у меня пока руке не дошли.
Как раз есть повод, значит посмотрим:
Как я понял, они вот это сейчас предлагают в качестве решения:
Т.е. подмена модуля происходит на уровне сети, ты скачиваешь зависимости не из интернета, а из «своего интернета». Надо сказать, я бы до такого не додумался. Когда я придумывал библиотеки в Яре, я додумался до наличия в проекте файлика, который разрешал бы имя библиотеки в способ её получения, и давал бы ей имя, локальное в пределах проекта. Поддержка этого файлика - отдельный вопрос, например, можно было бы написать инструмент для этого. В голанге есть неоднозначность, например, errors уже неоднозначен, можно заимпортировать разное и поиметь проблем. Т.е. то, что алиасом библиотеки является одно слово - это будет проблема с масштабированием. По сути, в голанге примерно так же и сделали.
Идея в том, что имя библиотеки привязано к интернету, в целом здравая, т.к. интернет гарантирует глобальную уникальность. приятно ли видеть экспорты в виде такой простыни в каждом исходнике - не факт. Зато система проста и однозначна, а ведь Голанг - это Оберон, так что это вполне в духе языка.
Кстати не, конечно же, они недодумали, т.к. они потом стали вводить url-ы с версиями. Т.к. в принципе возможно применение двух разных версий одной и той же библиотеки в одном проекте. Например, взять какой-нибудь конвертер файлов - там понадобятся разные версии читалки для разных версий формата.
Т.е. подмена модуля происходит на уровне сети, ты скачиваешь зависимости не из интернета, а из «своего интернета»
Но зачем так извращаться? Можно просто скопировать код себе в src/lib/ и делать импорт оттуда.
Идея в том, что имя библиотеки привязано к интернету, в целом здравая
Чем? Гитхаб через n лет закроют и ты будешь бегать править ссыкли по всему проекту?
Ты просто пишешь make и проект просто собирается и всё. Ничего больше не нужно.
var user RegistrationData
user.Nickname = ...
user.Registrationemail = ...
user.Password1 = ...
user.Password2 = ...
if appErr := doRegistrationFormSubmit(...), appErr == nil {
Отвечаю. RegistrationData - это не пользвоатель, а данные, которые аноним ввёл в форме регистрации. Пользователь тоже есть, и это другое - это тот, кто уже зарегистрировался. Так что rd - это название правильное в рамках моей раскладки понятий.
Насчёт if appErr := , - я это где-то подсмотрел и это достаточно популярно. Здесь хорошо то, что appErr определена только в рамках данного if , т.е. можно потом опять писать appErr :=
Но да, в определённых случаях громоздко. В случае, если помещается в одну строку, честно сказать, криминала не вижу.
Насчёт доки ты прав. Но я стараюсь, по «чистому коду», кодировать смысл функции в её названии, а линтер требует документацию для всех экспортов. В таких случаях я и пишу «на отженись». Что посоветуешь?
Можно просто скопировать код себе в src/lib/ и делать импорт оттуда.
Это один из их старых вариантов, вендоринг. Ты копируешь всё в vendor и оттуда берёшь. Но он требует патчить импорты прямо в исходных файлах, что, как ты понимаешь, «очень удобно».
Ничто не мешает иметь прокси, который возьмёт файлы из этой же локальной директории vendor, при этом патчить исходники не придётся. Это решит вопрос и с гроханьем либы.
И я рад, что я запрыгиваю в этот поезд именно тогда, когда эта проблема уже решена, или хотя бы близка к решению. Потому что раньше они делали хрень и пытались всех убедить, что это нормально, а теперь наконец-то дошли до того, чтобы сделать годноту.
Но он требует патчить импорты прямо в исходных файлах, что, как ты понимаешь, «очень удобно»
В ../lib либы. В каждой либе .git/ В чём проблема?
Ничто не мешает иметь прокси
Ты предлагаешь пляски с прокси, но ради чего? Ты можешь сделать просто import "lib/mylib" и всё. Либы сложить в ../lib, в твоём проекте сделать на них ссылку, внутри каждой либы - её git, который ты можешь апдейтить и патчить как хочешь.
Мой проект ссылается на pkg/errors и характеризует его как github.com/pkg/errors. Мой проект использует gin. gin использует github.com/pkg/errors. Дальше что?
Да и это не я предлагаю, а авторы го. Пользователи го не обсуждают авторов го. Они кланяются, читают мантру, перебирают чётки и исполняют. Ну или собираются всем приходом, идут к начальнику авторов го, после чего авторы го получают люлей и переписывают Конфуция.
Ты не видишь, что Registrationemail выбивается из ряда?
А, вот ты про что. Я не заметил. Ну да, можно было бы сделать по-другому.
Ну, пиши 'rd', 'c', 'data' если у тебя так мозг работает. Но я читать такое не буду.
Куда ты денешься? c *gin.Context, t *Testing.T. Это - стиль языка, его придумал не я, но я его, кстати, одобряю. Потому что я читаю код только в IDE, если не понимаю, что происходит, подвожу мышь и вижу типы. Такой код (с выводом типов) и предназначен для чтения в IDE.
А в го нельзя никак делать импорт, кроме как через гитхаб?
Через адрес репозитория в интернете. Есть команда go get ./...
которая автоматически загружает все зависимости, если ты хипстор. Соответственно, при прокси ставишь одну переменную окружения, и работаешь через прокси. Исходники не меняются, версии под контролем. Всё пучком.
Хотя можешь указать просто локальный путь. Как он отличает интернет от локального пути - я не знаю. Видимо, он берёт из интернета только то, что не найдено локально. Я пока хипстор.
Да в том и дело, что уже можно. Я ж хипстор не от души, а потому, что сейчас делаю упражнения. Да и вообще на раннем этапе разработки не страшно качать с гитхаба. А так я проверил (частично с твоей помощью), что годное решение этой проблемы уже сделано.