Комментарии 72
Супер-круто написанный код по всем правилам и канонам, в котором потом сложно разобраться новоприбывшим на проект - зло... Лучше пусть будет не так круто, зато просто и понятно.
Дык может новоприбывшие еще неопытны, мало кода читали, и им почти все сложно. Не только от кода зависит, так что не только он может быть злом
А я бы как новоприбывший предпочёл работать на проекте, который написан по всем канонам. Кривая обучения более крутая, но в итоге я буду уметь писать по всем канонам и когда приду на другой проект написанный по канонам сразу пойму что и где.
Да и пишется он по канонам не просто так, а значит, что сложность проекта и требования к его поддержке требуют применения этих самых канонов.
It depends. Иногда важнее качество, скорость, надёжность.
А если скорость работы и надёжность кода не так уж и критичны, тогда важнее, чтобы человек со стороны мог быстро врубиться. Бизнесу выгодно сократить издержки на обучение персонала да и чтобы сам персонал был попроще.
Ведь голубая мечта любого бизнеса организовать процессы так, чтобы работу работали низкоквалифицированные и легко заменяемые кадры, как кассиры в Пятёрочке.
Супер-круто написанный код по всем правилам и канонам, в котором потом сложно разобраться новоприбывшим на проект - зло
Это по-моему не зло, а оксюморон
Хочется добавить сюда ещё бесконечные важные споры о том, что же использовать: табы, 2 пробела или 4; максимальное кол-во символов в строке или имени метода/класса, максимальная длина сообщения для коммита и прочие очень важные вещи для закрытой кодовой базы. (работал когда-то в комманде, где 2 лида и архитектор буквально 3 часа рабочего времени спорили по поводу длины названия метода)
Согласен с автором, что писать нужно в первую очередь понятно - пусть лучше будет не 72 символа в сообщении коммита, а 75, зато будет понятно - иногда просто не получается сказать короче просто из-за длины слов.
Пусть лучше я немного подвину горизонтальной прокруткой или сделаю перенос, но зато код будет сразу понятным
Ограничивают не длину сообщения коммита, а только его заголовок. Детали можно вынести в тело сообщения, зачем пытаться впихнуть невпихуемое в название коммита?
Как я уже написал выше, речь не идёт о том, чтобы намного превышать лимит заголовка. Детали коммита больше нужны, чтобы объяснить зачем и почему сделанно именно так, а не только что.
Между понятностью и религиозным ограничением на символы, я выберу первое. Считаю, что лучше превысить лимит на пару символов и написать понятно, чем сидеть и думать "как же это всё так перефразировать, чтобы не дай бог не превысить лимит" и в итоге написать так, чтобы для понимания, что же именно коммит изменил, нужно было идти в его детали.
Я согласен, что нужно тренировать лаконичность и в большинстве случаев заголовок возможно сформулировать в 50-60 символов, однако, если мне для описания изменений приходится использовать длинные английские слова и ничего из фразы выкинуть не получается, то делать из этого смертный грех не вижу смысла.
Людей очень часто учат писать коротко, но вот над понятностью почему-то никто не трясётся с такой же обеспокоенностью. В итоге, пытаешься найти в каком же коммите появился баг, а там целый набор абстрактных заголовков. Зато коротко. Пример взят из опыта многих проектов.
А вам не жаль того человека. который вынужден будет читать эту портянку, которую расколбасило при выводе git log или в интерфейсе GitHub? Ведь эти рекомендации не с потолка придуманы а являются следствием опыта старших товарищей.
Делайте как угодно, я лишь попросил не путать понятия. Длину сообщения никто не ограничивает.
Во-первых, я считаю, что достаточно перевирать мои слова. По-моему, я достаточно исчерпывающе объяснил в предыдущем комменте что я имел ввиду и в каких случаях считаю, что условное ограничение можно нарушить. Если 72 символа - это не портянка, а 75 или даже 80 - портянка и дополнительное английское слово настолько усложняет чтение, то стоит задуматься, может дело не в дополнительных символах?
Во-вторых, касательно git log - если разработчик использует консоль/терминал, где максимальная длина вывода 80 символов и он предпочитает страдать с переносами вместо того, чтобы что-то изменить, то да, мне таких людей жаль. Ведь дело не только в том, что на такой маленькой консоли неудобно читать git log - я бы сказал, что лог любой программы так читать неудобно.
В-третьих, "эти рекомендации не с потолка придуманы" - да, не с потолка, а со времён, когда разрешение экрана измерялось в символах, а потом укрепилось во времена 640х480. Я не понимаю как в 2021 с нашими офигевшими технологиями, где 2к уже в мобилку пихают, а 4к в ноуты, можно вообще поднимать тему кол-ва символов в строке. Разве что, это единственная проблема на вашем проекте - в таком случае я по-доброму завидую вам.
При этом никакого поиска по этой таблице не происходит, только вставка и обновление данных.
Интересно, а как находить и обновлять нужную запись, если на ней нет первичного ключа?
А если ссылочная целость чего-то нам не дает сделать, что значит мы пытаемся что-то сделать не так, как это планировалось при проектировании, а это скорее всего ошибка с нашей стороны. А без нее (целостности) все так прекрасно работает и ошибок не выдает (хотя они есть, но их никто не видит, до поры до времени).
Интересно, а как находить и обновлять нужную запись, если на ней нет первичного ключа?
Например, так:
UPDATE settings SET value="true" WHERE key="debug"
Поздравляю, вы изобрели NoSQL.
Как вы думаете, что происходит когда вы пишете WHERE key="debug"?
Правильный ответ, сюрприз, база данных ищет данные. а быстрее всего она их ищет, когда есть индекс для поиска, одна из функций первичного ключа.
Для этого, внезапно, нет необходимости создавать первичный ключ - достаточно создать индекс. О чем и говорится в статье. И даже индекс необязателен - в случае небольших таблиц, разницы в скорости не будет.
Представим у нас есть 3 записи с полями descr, amount, key:
1) key=debug, amount=10, descr='колбаса'
2) key=debug, amount=20, descr='колбаса'
3) key=info, amount=25, descr='масло'
Мне нужно обновить вторую запись, поменяв сумму с 20 на 30. Условия "WHERE key="debug"" будет явно недостаточно. И даже добавление условия "descr='колбаса'" тоже будет не достаточным. А если у нас есть 2 абсолютно одинаковые записи, например добавим 4-ю запись:
4) key=debug, amount=20, descr='колбаса'
А мне по прежнему нужно обновить вторую запись, при этом не затронув 4-ю. То я уже это просто не смогу сделать, т.к. нет критерия однозначного определения нужной записи.
Т.е. для обновления/удаления записей нам де факто просто необходим первичный ключ, даже если мы его явно не определяем для таблицы, а держим только у себя в голове.
Зачем вы приводите надуманные, не существующие в реальности примеры? Естественно, что для подобной структуры необходим первичный ключ. Можно создать таблицу для хранения key-value значений, и первичный ключ тут не будет обязательным. Достаточно будет добавить индекс для быстрого поиска
Почему же такой пример не имеет право на жизнь?
Представим, что это некий буффер продаж за день, где key - это продавец, descr - это товар, а amount - это цена, за которую он ее продал.
За один день продавец debug продал 3 колбасы, но в какой-то момент вспомнил, что вторую колбасу он продал не за 20, а за 30 у.е. и захотел это исправить. Но при такой структуре у него это уже не получится сделать.
Можно создать таблицу для хранения key-value значений, и первичный ключ тут не будет обязательным.
Так ведь ваше key в данном случае и является первичным ключом, разница лишь в том, что вы не указали это явно при создании таблицы, а держите это только у себя в голове, зная, что по заданному key вы однозначно определите нужную запись. Так что говорить, что тут нет первичного ключа от части совсем, ихмо, будет неправильно.
но в какой-то момент вспомнил, что вторую колбасу он продал не за 20, а за 30 у.е. и захотел это исправить. Но при такой структуре у него это уже не получится сделать.
Как человек, который писал реально работающие подобные системы скажу: и не должен иметь такой возможности ни в коем случае! Все коррекции - отдельной строкой и выполняет их только специально уполномоченный человек/роль.
Но даже этому специально уполномоченному человеку нужен будет уникальный идентификатор строки.
Не обязательно. И даже вредно - ролей-то у него может быть много => много строк в таблице прав.
Вообще реализовывать реляционные связи "через код" (i.e. слабое связывание) - это не плохая (и не хорошая) практика, а архитектурный выбор.
Причём тут таблица прав и реляционные связи, когда мы про буфер продаж за день говорим?
Ну вас же: "специально уполномоченному человеку нужен будет уникальный идентификатор строки".
Уникальность как предполагали обеспечивать без внешней таблицы с уникальным ключём? Вот вам и таблица ролей с правами и реляционная связь. Так что минусик - возвращайте обратно :)
Э-э-э, а как внешняя таблица поможет вам обеспечить уникальный ключ для строки? И причём тут вообще таблица прав?
Э-э-э, а как внешняя таблица поможет вам обеспечить уникальный ключ для строки?
Foreign Key. Слышали о таком? Иначе у вас, где "key - это продавец <...> ваше key в данном случае и является первичным ключом" - этот продавец больше одного товара в день не продаст. Просто по определению ключа (он должен быть уникальным во всей таблице (по всем строкам))
И причём тут вообще таблица прав?
В простейшем наивном случае - именно там хранятся пользователи заодно с правами (на проводку той же коррекции)
Мы с вами явно друг друга не конца понимаем. Это не повод реагировать эмоционально. Это повод более чётко изложить свою позицию.
Напоминаю задачу.
У вас есть таблица, с атрибутами key, amount и descr. Ни один атрибут не является уникальным, так же как и ни одна комбинация атрибутов. Вам нужно обновить одну из строк этой таблицы, так как она содержит ошибочные данные.
Как вам поможет в этой задаче внешний ключ на таблицу прав пользователей?
Теперь я понял, что именно вы не поняли )) Выражайтесь яснее в следующий раз.
По сути:
С каких это пор в такой таблице разрешено вообще что-либо обновлять?
Просто добавляется транзакция:
key=corrector, amount=10, descr='колбаса'
(или -10, если надо скорректировать в другую сторону,)
Для биг-даты и сведения балансов (а для чего ещё эта таблица сойдёт?) этого достаточно. Зато сразу понятно какая смена чаще косячет.
Задумку понял. Но неужели вот прямо совсем-совсем никому не интересно какая именно запись была скорректирована? Не верю.
Как специалист сразу задам вопрос: а в каком бизнес-процессе вы эту информацию используете? Какое решение на её основе примите? Ни в каком? Никакое? (чаще всего так и есть: для продавца единицы товара как электроны - неразличимы) Тогда зачем тратить ресурсы (программистов и системы)!
Просто любопытство - не основание.
А в реальных системах - там обычно идёт номер чека, уникальный в течении дня. Его можно в descr запихнуть.
С каких это пор в такой таблице разрешено вообще что-либо обновлять?
Ваш подход понятен - запрет на обновление записей, корректировки - это просто новые записи. И соглашусь, в большинстве реализаций подобных систем он будет применим, оправдан и целесообразен.
Но так ведь весь сыр-бор в этой ветке я начал с цитаты из статьи:
При этом никакого поиска по этой таблице не происходит, только вставка и обновление данных.
Акцепт на "обновление данных", а это подразумевает и поиск и однозначную идентификацию записи, а для этого необходим первичный ключ (не обязательно суррогатный, но хотя бы нативный быть должон). Его можно конечно не объявлять первичным ключом, но уникальность по нему должна обеспечиваться.
Ну... Например, он запустит MysqlWorkbench, сделает select * from .... where amount=20 and descr='колбаса' и исправит вторую запись. Ай, нет - без первичного ключа воркбенч править не будет...
На самом деле, наличие первичного ключа не есть наличие соответствующего индекса. Это зачастую зависит от реализации СУБД. Т.е. теоретически, ничто не мешает нам создать первичный ключ и не использовать соответствующий индекс.
Просто, в таком случае, проверка уникальности первичного ключа и поиск по нему будет более трудозатратной для СУБД.
Интересно, а как находить и обновлять нужную запись, если на ней нет первичного ключа?Насколько я понял автора, в его случае править в той таблице ничего не было нужно: она использовалась чисто как очередь сообщений, которые впоследствии асинхронно отправлялись на серевер.
Недооценённый совет про избегание дубляжей.
Многие вдохновляются принципом DRY, и обобщают любой похожий код.
Но проблема в том, что в разных местах проекта одинаковый код может служить разным целям и иметь разный смысл.
Обычно это выясняется с течением проекта, когда функции обрастают флажками, а структуры приобретают поля, не нужные части потребителей.
Разделять такое сложно
Более того, до абсурда доходит, когда методы отличаются совсем чуть-чуть и начинается переинженирование с вынесением общих частей, да так, что в результате код становится в несколько раз сложнее для поддержки и чтения
Вот тоже не понимаю этой какой-то привычки чисто экономить место на диске )
Тут важно понимать что дубликат_кода !== дубликат_функционала
И во многих частях проекта может быть дублирующийся одинаковый код служащий разным целям и выносить его в отдельный хелпер - усложнять себе рефакторинг в будущем из-за высокой связности.
Сколько таких Легаси проектов повидал, где почти каждый компонент зависит от пачки из ./Utils/ которые в свою очередь юзают ./Helpers , а тебе надо этот функционал плавно на новый фреймворк перетащить, частями, без переписывания с нуля, и никак не получается вытащить из проекта самодостаточный модуль не потянув за собой все зависимости
Поддерживаю.
Как говорил один мой старший коллега - лишние стрелочки намного хуже лишнего кода.
Т.е. DRY драем, но не в ущерб разделению ответственности и логическому делению кода.
Именно это, кстати то, что является скрытой угрозой во всяких пакетах или, ещё хуже, статических классах Util, с "общими" алгоритмами. Сам такое люблю и сам много раз "обжигался". Общий алгоритм должен быть ну очень универсальным, а такие чаще всего уже есть в стандартных библиотеках.
Через пять лет произвели реорганизацию, и появилась возможность того, что один сотрудник будет числится в нескольких подразделениях.
Преждевременная оптимизация тоже зло.
Вдобавок зачем ссылаться много записей. Через 5 лет добавить отдельную таблицу, где будет множество строк с "user" - "department ". Но если это не нужно сейчас, то не нужно. Иначе можно к любой информации так относиться, и будет тысячи таблиц, которые может быть будут использованы через 5 лет, а может и нет.
А тут никогда не угадаешь, если система не спроектирована жёстко заранее. DRY приводит к ошибкам вида god objects, не-DRY -- к ошибкам "в двух местах поменял, в третьем забыл". С таблицами та же фигня - то на каждый чих три таблицы вместо одной, то в одном поле хранится десяток значений в json или через запятую..
То есть не угадаешь? Ты же видишь по какие задачи пишется система. Если это простой сайт с простым магазином, который пишет единственный разработчик - то через год, если бизнес успешный, можно нанять трех разработчиков, которые напишут с нуля уже с учетом годовалого опыта работы.
Именно такое я и вижу, когда автор приводит пример в виде пользователей и департаментов в небольшой компании, для личных нужд. Была бы компания побольше, использовали бы какую-нить готовую ITIL или ServiceDesk или что там систему.
Гадать есть смысл пока "это условно можно переписать за человекогод".
И добавляя кучу "но". Не вполне обязательно, чтобы армия сотрудников смогла переписать "человекогод" хотя бы за год.
Например если единственный разработчик случайно оказался бесконтрольным полубогом и внезапно у вас realtime schemaless бесконечно радующий клиентов... А ваша проблема - как сделать сервис подешевле и попроще в поддержке, не потеряв клиентов.
Проблема в требованиях, которые могут меняться или дополняться по ходу разработки. Если система пишется не за пару месяцев, то будет гарантированный аджайл!
Это называется KISS.
Что для Вас хуже - наличие несвязанных записей в базе или непрерывные звонки от пользователей
Остановите самолёт, я слезу. Оба варианта плохие. Что-то идёт не так, но вы не можете с этим ничего поделать.
Внешние ключи — зло
Это, пожалуй, единственное в тексте, с чем я не согласен категорически (остальное обсуждаемо).
Точнее, я бы, может, и согласился, если бы это относилось исключительно к полям, по которым никто и никогда не будет искать.
А вот для поиска и фильтрации нужно соблюдать порядок.
Потому как в свое время (больше 20 лет назад), столкнулся с переносом данных о квартирах в фирме по торговле недвижимостью из плоской таблицы на Paradox в полноценую БД в почти что 3-й нормальной форме,, сделанную на полноценном SQL-сервере (Interbase).
Основная причина нормализации была в том, чтобы по полям БД можно было бы эффективно искать и ставить на них фильтры.
В процессе подготовки переноса данных (которым я, в основном тогда занимался) были обнаружены удивительные факты. Например, вариантов написания названия станции метро «Преображенская площадь» в базе было на момент переноса аж 22 штуки.
А поскольку поиск по станции (или нескольким близлежащим станциям) метро был одним из востребованных запросов клиентов (в те времена запросы шли к девочкам на телефоне), то заставлять девочек ставить ради одной станции 22 галочки в фильтре выглядело как-то, даже не то, что негуманным, а просто снижающим производительность оператора, т.е. потерей денег.
А без внешних ключей обеспечить консистентность справочников — оно никак.
А потом у фирмы ещё и появился сайт, сделанный по последнему слову тогдашних технологий: динамический (на Perl через CGI), с фильтрацией информации по квартирам по параметрам согласно выбранных элементов справочников, и даже с картой метро (на Java applet), игравшей роль интерфейса для выбора этих самых станций метро из соответствующего справочника. Данные в БД сайта гнались практически напрямую из основной БД, и я даже не представляю, что было бы с посетителями сайта, если бы в ней по прежнему оставались 22 варинта названий станции метро.
PS И ещё.
можно обойтись файловой СУБД
Файловая СУБД — палка о двух концах. С одной стороны просто, с другой — она может порушиться при зависании — нет, не сервера, а клиентского компьютера. И требовать восстановления в монопольном режиме. Когда пользователей немного, несколько человек — это терпимо, но когда базой пользуется вся фирма (как упомянутой базой квартир на Paradox) — то процесс ее восстановления требует проворства и сноровки.
Я несколько раз наблюдал за слаженной работой специалистов по восстановлению этой базы в четыре руки: один за консолью Netware смотрел, когда отсоединятся все пользователи (и побуждал отсоединяться тех, кто не отсоединялся), а второй по сигналу первого захватывал базу в монопольный режим и запускал восстановление.
Всегда приятно смотреть как люди работают.
Простите, а при чём здесь внешние ключи? Здесь все решается просто за счёт нормализации данных, вынесения названий станций в отдельную таблицу. Ссылки на эту таблицу по логике, конечно, являются внешними ключами, но совершенно не обязательно должны быть так объявлены.
А если нагрузку на СУБД требуется снизить, то приходится в основной таблице хранить сами значения, чтобы запрос не лазил по справочникам. Правда лично я с такой нуждой сталкивался во времена, когда БД писали на Clipper, но тем не менее.
Всё так, но внешние ключи имеют свои недостатки, не только преимущества.
Навскидку -- их использование предполагает, что записи удаляются, а не "помечаются как удалённые", и если БД уже спроектирована с ними, то на уровне простого разработчика это будет уже неисправимо.
Второе - когда две таблицы ссылаются друг на друга, дропнуть их просто так не получится, ключи необходимо будет сначала отключить... Вроде элементарно, но неочевидно. Плюс всегда мелкие проблемы с несовпадением типов ключей.. в общем, почему-то работать с ними довольно неудобно.
Хотя где-то, где они необходимы и полностью соответствуют логике -- да, берут на себя часть рутинных задач и некоторую целостность.
Автор, а вы не путаете понятие первичного ключа и синтетического ключа? Первичным ключом может быть любая коллекция полей в которых отсутствует null и записи которые уникальные.
Иногда странно смотреть когда добавляют синтетический ключ для вспомогательной таблицы при описании отношений N:M. Но при этом первичный ключ там нужен на паре FK.
Также есть конструкции SQL как ON UPDATE CASCADE / ON DELETE CASCADE они помогают изменять и удалять записи при наличии FK. Или можно использовать ON DELETE SET NULL.
И не надо забывать про код пишется не для компьютера, я для тех программистов кто будет работать с ним после вас. Выбор VBA для маленькой задачи, при условии что разработка ведётся на C# приведёт к тому что этот код перепишут т.к. некому будет его поддерживать.
Если нет полной уверенности, что отношения «один-много» будет достаточно для любого случая, лучше делать «много-много» через промежуточную таблицу. На всякий случай.
Дело пахнет связкой один ко многим и таблицей истории изменений, по которой а) можно будет строить исторические отчеты б) ловить за руку «я ничего не делала, это у вас программа неправильно работает». Для чего в таблице должны быть оба id, дата-время изменения и какой-то user_id (username, role, что-то свое — по вкусу).
Не нужно сбрасывать атомную бомбу на курятник, чтобы пожарить яичницу
Доля правды в этом «вредном» совете есть. Нынче модны-популярны всякие браузеры, которые ну очень активно косят под нативные приложения. Да, Electron и иже с ним. Вот их, пожалуйста, не надо использовать. Особенно в софте, который разрабатывается для десктопа и планируется к публикации в открытом доступе. Teams, Slack и прочие — отличный пример того, как делать не надо. Просто попробуйте поменять размер окна и вы всё поймёте. Discord — хороший пример, но шанс на то, что вы сделаете так же, стремится к нулю.
Хоть название статьи и не предполагает серьезного отношения, но всё же.
Лишняя таблица не лишняя
https://ru.wikipedia.org/wiki/YAGNI
Лишний код не лишний
https://refactoring.guru/ru/refactoring/smells/change-preventers
Инструкция не комикс
Это, конечно, да. Но сможете ли вы на одной странице "памятки" понятно описать правила работы с вашей программой? Особенно это касается программ для внутреннего использования, при разработке которых обычно фокусируются на функционале, а не на UI. Классика: «Программисты (...) много работают, чтобы сделать свои программы легкими в использовании. К сожалению, судят они по себе...» А.Купер.
Будьте проще
Этот очень хороший пункт противоречит многим местам в вашей же статье.
После универа поработал "карманным" программистом в ООО на 20 человек. К сожалению если не работать на работе и после работы на фрилансе, то даже через 20 лет не дотянешь до мидла галеры в СНГ. Бесконечные лендинги и дотнет тулзы по тз "нужны кнопка которая нажимала бы три для манагера" оставляют скилл на уровне стажера.
Не соглашусь, после 5 с небольшим лет фултайма устроился на работу в российскую продуктовую компанию федерального уровня, в которой вообще все хорошо кроме легаси и несколько переусложненного workflow. И то эти 5 лет были долгим путём без компаса)
Искренне не понимаю ребят, работающие в аутсорсе, на галерах. Нужно такое счастье…
Если в полночь на экране появился Segmentation Fault.
Ты не бойся, первым делом сделай из осины кол.
Забивать его не надо, в злых поступках мало толку.
Этой палкой надо просто нацарапать надпись LOL.
Где вы в последний раз видели рекомендацию использовать Delphi? Здесь это упоминание не уместно и выглядит не более чем негативное отношение к языку.
В современных реалиях логично было написать: "следует забыть про Java - Python Ваше всё!". Это недоразумение сейчас из каждого угла лезет.
KISS бьёт DRY
Читаю статью и не могу понять в чём подвох. Обещали вредные советы, но все утверждения выглядят очень даже дельными.
Как человек с примерно таким же опытом, не согласен с двумя тезисами - о первичных ключах и о файловых СУБД или Excel, ибо в процессе работы столько раз маленькая програмка на 3-5 таблиц и десяток справочников вырастала постепенно в полноценную базу данных, связанную с другими системами, что теперь всё, что попадает в разработку, пишется в SQL.
Принимаю эстафету и предлагаю вниманию свою подборку вредных советов: 60 антипаттернов для С++ программиста.
Вредные советы программистам