[Arlleex 131]

3 часа назад, Ulkizz сказал:

недавно мне проект передали продолжать. Пришлось день потратить *проект небольшой* выправляя расставленные компоненты, т.к. во многих случаях использовались скопированные откуда-то компоненты, где изменено только поле comment. В итоге BOM собирался криво.

К тому же у некоторых компонентов были неправильные посадочные места.

И о чем мне это должно говорить? Что Ваш бывший коллега - несамоорганизованный рас*издяй? С подходами в стиле надевания трусов через голову он бы и с базой работал так, что вопросов было бы столько же, если не больше.

[Ulkizz 3]

8 hours ago, Arlleex said:

И о чем мне это должно говорить? Что Ваш бывший коллега - несамоорганизованный рас*издяй? С подходами в стиле надевания трусов через голову он бы и с базой работал так, что вопросов было бы столько же, если не больше.

вовсе нет. Ровно то, что уже было сказано: пока проект лично твой - проблем нет. Ну или почти нет. Но практика использования шаблонов вместо компонентов вносит в рабочий процесс больше хаоса, потому что появляется дополнительный шаг разработки. (а то и два) Нравится вам это или нет. 

Из того же примера: я проверил и поправил полупроводники, т.к. их и меньше и проверка сводилась к сверке двух-трёх полей. А пассив пришлось пересчитывать, потому что никаких гарантий, что 10кОм это рассчитанный номинал, а не "скопированный".

Приходилось сталкиваться с тем, что кварц обвешивали 0.1мкФ конденсаторами, потому что забывали изменить шаблон. Также приходилось сталкиваться с несуществующими номиналами.

Монтажники от таких приколов на говно исходят.

[khlenar 5]

Поэтому в любом случае схема проверяется. Без разницы скопирован элемент или взят из библиотеки. По моему здесь все очевидно. Ну пусть кому нравится делает резисторы в библиотеке со всеми номиналами, а потом в схеме ищет нужный номинал. Другой просто запишет нужный номинал. 

[siargy 6]

58 minutes ago, khlenar said:

Другой просто запишет нужный номинал. 

и ручками перебьёт партнумбер для бома)

или так оставит, а потом снабжэние пусть гадает?

[Arlleex 131]

12 часов назад, Ulkizz сказал:

Приходилось сталкиваться с тем, что кварц обвешивали 0.1мкФ конденсаторами, потому что забывали изменить шаблон.

Вытаскивает разработчик на схему из сверхсупервылизанной базы с 100500 типами и номиналами конденсаторов 0.1 мкФ на кварц, т.к. глаз замылился. Дальше что?
 

3 часа назад, siargy сказал:

и ручками перебьёт партнумбер для бома)

Ну да, ну да, а для внесения в базу никаких телодвижений же делать не надо, и правильность внесения данных, ровно как и в целом правильность создаваемого компонента, обеспечивается "каким-то образом сама собою"...

P.S. Косяки, которые все приписывают ручному вбиванию и последующему копированию, они справедливы и для базы. Ровным счетом разработчик может не вытаскивать каждый раз нужный резистор из базы (а я бы ровно так и делал, ибо каждый раз копаться в сотнях резисторов, прокручивая их и имея возможность ткнуть мышой не туда под вечер нет ни малейшего желания), а точно так же вытащить один нужный и потом его копировать куда надо дальше. И если в этом компоненте изначально был баг (а вы думаете, такого не бывает? еще как бывает), вам ни за что его не найти сходу. Например, какая-нибудь фигня, не соответствующая действительности в ТКС резистора, может жить десяток лет в пресловутой и хваленой базе, а потом, когда этот параметр станет критичным, девайс будет глючить, и я уже не говорю, сколько оров и криков будет в сторону составителей священной базы, в которой же "ошибок нет" (с) (а значит ее проверять не надо априори). И вот косяк обнаруживается, компонент не соответствует действительности, идилия о совершенстве базы идет лесом, туда же идет серия потенциально изготовленных плат в пробной партии. И повезло, если этот злощавый параметр не влияет на уже сотни других цепей в других изделиях.

Не нужно выдумывать проблем, т.к. я тоже умею на любое якобы преимущество назвать недостатки. Я прекрасно знаю за недостатки своих методов, не защищаю их ни разу, но в сравнении, приписываемые базе идеалистичные характеристики яростно отрицаю. Да, местами удобно, не спорю, но человеческий фактор присутствует и там.

"Все равно будет второй-третий проверяющий схемы" - в методе с обычным копированием все будет ровно то же самое. А в финале - хоть десять человек пусть проверяют - и все равно не найдут, потому что будут искать, как всегда это и бывает, не там. Первый запаянный образец по финальному BOM выявляет 99.99% проблем и косяков проектирования.

[siargy 6]

2 hours ago, Arlleex said:

Косяки, которые все приписывают ручному вбиванию и последующему копированию, они справедливы и для базы.

 1 раз вбить правильно в базу или 100500 раз вручную править в схеме - где вышэ вероятность накосячить?

[Arlleex 131]

1 минуту назад, siargy сказал:

 1 раз вбить правильно в базу или 100500 раз вручную править в схеме - где вышэ вероятность накосячить?

Осталось выяснить, зачем 100500 раз вбивать вручную на схеме.

[siargy 6]

2 hours ago, Arlleex said:

Не нужно выдумывать проблем, т.к. я тоже умею на любое якобы преимущество назвать недостатки. Я прекрасно знаю за недостатки своих методов, не защищаю их ни разу, но в сравнении, приписываемые базе идеалистичные характеристики яростно отрицаю. Да, местами удобно, не спорю, но человеческий фактор присутствует и там.

я пользовался стандартными библиотеками, потом перешол на БД, и уверен, что многие так поступили. пусть моя база не идеальна и правица, но возвращатся к библиотекам нет смысла.

[Arlleex 131]

Ну то есть "удобно потому что мне удобно". Собственно, вокруг этого все 4 страницы обсуждения.

Без автоматизации процесса, гарантирующего согласованность данных в базе (в идеале через самого производителя компонентов), все эти базы точно так же будут содержать ошибки.

А еще вопрос к тем, кто пользуется БД. Вот, допустим, у меня контрактная разработка. Мне надо заказчику передать и гербера, и проект в альтиуме, и библиотеки компонентов. Я посмотрел на проект и понял, что все компоненты у меня есть в базе (моей личной, которой я не хочу делиться по тем или иным причинам). Я могу как-то вычленить (быстро) нужные мне компоненты из базы и создать подбазу, которую уже смогу передать заказчику? Или это гемор?

[dimka76 42]

On 7/31/2023 at 11:22 AM, Arlleex said:

А еще вопрос к тем, кто пользуется БД. Вот, допустим, у меня контрактная разработка. Мне надо заказчику передать и гербера, и проект в альтиуме, и библиотеки компонентов. Я посмотрел на проект и понял, что все компоненты у меня есть в базе (моей личной, которой я не хочу делиться по тем или иным причинам). Я могу как-то вычленить (быстро) нужные мне компоненты из базы и создать подбазу, которую уже смогу передать заказчику? Или это гемор?

Можно уже из проекта сгенерировать библиотеку

[Ulkizz 3]

13 hours ago, Arlleex said:

Вытаскивает разработчик на схему из сверхсупервылизанной базы с 100500 типами и номиналами конденсаторов 0.1 мкФ на кварц, т.к. глаз замылился. Дальше что?

"глаз замылился" и "забыл" это несколько разные ошибки.

 

13 hours ago, Arlleex said:

P.S. Косяки, которые все приписывают ручному вбиванию и последующему копированию, они справедливы и для базы.

нет несправедливы. Шаблонируя вы гарантируете себе дополнительную процедуру. В дальнейшем, конечно всё очень схоже.

 

13 hours ago, Arlleex said:

 И если в этом компоненте изначально был баг (а вы думаете, такого не бывает? еще как бывает), вам ни за что его не найти сходу. Например, какая-нибудь фигня, не соответствующая действительности в ТКС резистора, может жить десяток лет в пресловутой и хваленой базе, а потом, когда этот параметр станет критичным, девайс будет глючить, и я уже не говорю, сколько оров и криков будет в сторону составителей священной базы, в которой же "ошибок нет" (с) (а значит ее проверять не надо априори). И вот косяк обнаруживается, компонент не соответствует действительности, идилия о совершенстве базы идет лесом, туда же идет серия потенциально изготовленных плат в пробной партии. И повезло, если этот злощавый параметр не влияет на уже сотни других цепей в других изделиях.

Гм. А кто говорит, что в БД не бывает ошибок? Точно таким же образом затесавшаяся ошибка в параметре скопированного компонента будет путешествовать по всему проекту. И далее будет кочевать и в другие проекты. И когда это выяснится, то ошибка может быть в десятке проектов. Как это потом исправлять - совершенно непонятно. 

13 hours ago, Arlleex said:

Не нужно выдумывать проблем, т.к. я тоже умею на любое якобы преимущество назвать недостатки. Я прекрасно знаю за недостатки своих методов, не защищаю их ни разу, но в сравнении, приписываемые базе идеалистичные характеристики яростно отрицаю. Да, местами удобно, не спорю, но человеческий фактор присутствует и там.

а что же мы тогда делаем уже не первый день?) Шутки в сторону. Каждый из подходов имеет право на жизнь. Закидывать нечистотами какой-либо из них я не стал бы.

 

10 hours ago, siargy said:

я пользовался стандартными библиотеками, потом перешол на БД, и уверен, что многие так поступили. пусть моя база не идеальна и правица, но возвращатся к библиотекам нет смысла.

 

не соглашусь. Если вы один единственный разработчик, или если в конторе у вас принято, что кто как хочет так и гм крутится, то особого смысла в БД нет. 

[siargy 6]

8 hours ago, Ulkizz said:

Как это потом исправлять - совершенно непонятно. 

c БД элементарно -команда обновить параметры. с методом копипасты - только вручную перелопачивать.

 

8 hours ago, Ulkizz said:

Если вы один единственный разработчик, или если в конторе у вас принято, что кто как хочет так и гм крутится, то особого смысла в БД нет. 

у руководства вопросов нет, а когда появлялись, то вот команда - создать библиотеку из проекта.

колега подсуетил БД, сначала как непонятная и глючная примочка, потом разобравшись и трижды переделав, принял для себя как очевидно более удобный и полезный инструмент.

[Bad0512 2]

Сам пользуюсь методом "cut&paste" из проекта в проект, было время когда по требованию начальства пользовал и "библиотечный" подход.

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

У этого человека как правило много разных задач от разных разработчиков, соответственно он возможно обладает более глубокими знаниями на тему "как правильно делать компонент", но к сожалению совсем не горит желанием читать даташиты, да и времени у него на это просто нет. Поэтому некоторые тонкие моменты от него ускользают. Кроме того при такой схеме работы возникает эффект "размывания ответственности". Ну то есть при нахождении проблемы в дизайне, порождённой кривым библиотечным компонентом не всегда тривиально найти виновника и как-то замотивировать его провести работу над ошибками. В случае когда важен работоспособный проект ("ехать а не шашечки") такая ситуация может сильно повредить делу.

По поводу возражений о том что в случае либы поменять отдельный параметр на множестве однотипных компонентов значительно быстрее, чем в случае "безбиблиотечного" подхода могу сказать, что с помощью инструмента Find simlair objects подобные задачи решаются ничуть не медленнее, чем при "библиотечном" подходе. А уж какие чудеса умеет творить Smart edit при грамотном использовании...

 

 

[Uladzimir 60]

Цитата

 Библиотечный подход больше подходит для не слишком опытных разработчиков 

Я как раз ровно противоположного мнения.

[Ulkizz 3]

библиотечный подход скорее описывает сложность проекта или задачи, нежели опыт разработчика.