а зачем подсказывать на собеседовании?

> Юрий Зотов ©   (10.04.17 00:23) [139]

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

> Kilkennycat ©   (10.04.17 00:39) [141]

Костя, а лошади едят траву?
:o)

> ухты ©   (10.04.17 00:35) [140]
>
> а зачем подсказывать на собеседовании?

Чтоб посмотреть на дальнейший ход мысли.

> Юрий Зотов ©   (10.04.17 00:45) [142]
> Костя, а лошади едят траву?

у меня настолько плохая память, что вот помню, что ты такой вопрос задавал, но опять не помню, к чему и почему :(

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

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

на аналитика и многие ко многим надо подсказывать, чтобы поговорит? ))
вообще не уверен стоит ли в принципе подсказывать (вообще звучит странно), а тут еще и такие мелочи.

>Юрий Зотов ©   (10.04.17 00:23) [139]
>Но самая распространенная ошибка студентов - это, наверное, тихое гашение >исключений (это же хорошо, когда программа работает без ошибок).

Почему я люблю Delphi - это как раз реакция на ошибки.
Delphi использует механизм исключений, С-Windows - механизм кодов ошибок.

> насчитает тебе отрицательную зарплату.

Кстати, это не выдумка, а совершенно реальный случай.

Швейное объединение "Сокол", конец 80-х годов. Есть справочник операций. В нем сказано, что операция X стоит Y копеек - и так по всем операциям. Ежедневно в БД забивается, сколько каких операций выполнил работник-сдельщик, а в конце месяца идет расчет зарплаты.

И вдруг месячная зарплата иногда получается отрицательной. Бухгалтерия вопит, что срок прошел, а она не может начислить зарплату сдельщикам (которых сотни). Начальник ВЦ ругается и грозит лишить девчонок-операторш либо премии, либо девственности, либо сразу жизни. Девчонки плачут и клянутся, что все забили правильно.

После долгих разборок и всеобщей нервотрепки выясняется, что виновата действительно программа, а не девчонки. При суммировании происходило переполнение разрядной сетки целого числа, старший бит устанавливался в 1 - и здравствуй, отрицательная зарплата!

Проблема была устранена заменой Integer на Real. Но если бы программа сразу контролировала, что она считает чушь и выдавала ошибку, то все было бы гораздо проще, быстрее и без нервотрепки.

а у мня был обратный случай: бухгалтерия звонит и вопит, что пенсионные отчисления списались дважды, караул! Ну, посмотрел тут же конфиг 1С, всё гуд, дважды невозможно, отчитываюсь: ищите лишнюю проводку. в принципе, рядовая ситуация, когда штат бухгалтерии раздут, главбух как начальник не ахти, кто че делает непонятно, в последний день и т.д.  Одному трижды три сотрудницы начислят, другому ни разу ни одна.
Но главбух вопит: "быть такого не может, мы умные, а ты дурак".
Разумеется, нашли лишнее позжее, свалили на какю-то молодую бухгалтершу, самую безропотную, наверное.
Так что,

> все было бы гораздо проще, быстрее и без нервотрепки.

после первого же случая ошибки, если бы люди (и программисты и пользователи) были разумны, спокойнее и адекватнее,а не вопили "я - самый умный, у меня ошибки быть не может!"

> ухты ©   (10.04.17 02:46) [146]
>
> на аналитика и многие ко многим надо подсказывать, чтобы
> поговорит? ))

А там аналитик был? Тогда хз :)

---
По поводу багов был забавный случай давно. Мы тогда с энергосбытом работали. Внедрялись в маленьком городке Самарской области. Аналитики сначала приехали посмотреть что да как. Выяснили, что у них по тарифам за первые 50кв*ч (цифры условные) пенсионеры платят 50%. Местные бухгалтера решили, что 50% скидка на 50кв*ч - это все равно что 100% скидка на 25кв*ч, ну и считали так. Они были почти правы, но не совсем. Ведь если допустим пенсионер потратил 30кв*ч, то по тарифу должен заплатить как за 15, а по формуле местных бухгалтеров получится только 5.

В общем, интересный был случай. Про нас тогда даже в местной газете писали. Что лишаем пенсионеров льгот :)

>Юрий Зотов ©   (09.04.17 20:25) [109]
>А между тем, по-настоящему грамотный разработчик, получив такое ТЗ должен был либо его уточнить (что делать, если X не 0 и не 1 ?)

Разработчик любой грамотности уточняет ТЗ только там где есть противоречия и вариантность.
Если ему дали ТЗ, в котором четко 2 варианта, он его и реализует. Оптимальным образом. Если в итоге выясняется, что это НЕ ТОЛЬКО 2 ВАРИАНТА,
то проблема не в разработчике, а в анализе задачи и продуманности ТЗ. Просто у нас все любят валить на того кто последний в цепочке. Он, дескать
должен за всеми все проверять. А вот нифига не должен. И за этот косяк получить должен был не программист, а тот кто ставил для него задачу.
Программист, особенно в команде, может вообще не знать откуда берутся данные для его куска кода и куда они пойдут дальше. Его дело - решить
поставленную ЕМУ задачу в рамках поставленного ЕМУ ТЗ.
Кстати та же фигня и с INT. Еще на стадии проектирования нужно было иметь ввиду возможность такого косяка. И избежать его В ПРИНЦИПЕ, а не
пытаться делать сотни проверок - не вылетело ли сейчас это из диапазона.
Просто всем и всегда удобно свалить все на этап реализации - мы тут В ЦЕЛОМ подумали, а всякие мелочи, это вы там сами.

> Сергей Суровцев ©   (10.04.17 14:15) [151]

Все верно, но это в теории. А на практике так: "мы тут В ЦЕЛОМ подумали, а всякие мелочи, это вы там сами".

Хорошо вам. Я с 2006 года никаких ТЗ не видел. Agile, все дела... :)

> Kerk ©   (10.04.17 14:31) [153]

Несколько последних лет я их тоже не видел, а только слышал. Постановка задачи "в простой устной форме" или "Agile по-русски". И чуть что - постановщик от своего же косяка отмазывается - мол, "я этого не говорил".

>Юрий Зотов ©   (10.04.17 14:29) [152]

Вот есть, к примеру БД. В ее таблице поле, где теоретически 2 значения 0 и 1. Естественно проверка идет а=1, а=0. Если в таблицу попадет а=3, строка не зацепится никогда.
Смысл в том, чтобы строить проверки подобного не на уровне кода - возможно кто-то когда-то кривыми руками чего внесет, а на уровне периодического теста к БД, и скопом проверять ВСЕ возможные отклонения от нормы и их исправлять.
Именно это нужно было в примере с "х=х-1". То есть подтягивать входные данные к заявленным в ТЗ, а не пытаться в программе предусмотреть ВСЕ возможные неадекватности этих данных. В первом случае задача конечна и решаема, причем единоразово и с гарантией. Во втором задача решается постоянно и в результате лишь приближение к правильности, а гарантии нет никогда.

"а еще боремся за звание дома высокой культуры быта" )

> Сергей Суровцев ©   (10.04.17 14:46) [155]

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

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

Понадобилось как-то раз добавить в таблицу автовычисляемое поле, а по нему - индекс. Месяц доказывал, что это безопасно. Странно, но все-таки доказал. Итог: ускорение в 10 раз.

>Юрий Зотов ©   (10.04.17 15:08) [157]
>Это азбука, и она правильная. А на практике было вот что:

Ну да, это реалии жизни. Поэтому если нет полного контроля над базой, то только периодический тест на ее адекватность. Из недавних примеров: есть база, из нее строится куча отчетов. В основном после ее ежемесячного пополнения. Данные поступают корявые, их правят, но косяки в базу просачиваются. В час Х начинаются строится отчеты и валятся через один. Ищут, исправляют и дальше. Была сделана система тестов для ПРЕДВАРИТЕЛЬНОЙ проверки. В результате все косяковое находится гарантированно и автоматом, правится и вперед с песней к отчетам! Время получения оных сократилось в несколько раз, сложность и нервность процесса вообще испарились.

Сергей Суровцев ©   (10.04.17 15:39) [158]


> Данные поступают корявые, их правят, но косяки в базу просачиваются


Что это у вас за база такая ? Мне право интересно.