![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
eldhennВсе.
Нет, здесь в общем-то неплохо, но мне начинает казаться, что два обхода и одно копирование - это общепринятая практика выборки данных из базы. Главное чего я не понимаю - ради чего делать библиотечную функцию, которая не делает совершенно ничего, помимо fetchall_arrayref? Какие детали она скрывает? Как она может помочь в случае изменения бэкенда? А если это действительно так важно - допустим, у нас источник данных может быть не только РСУБД, но и скажем XML, или веб-сервис, или ещё какая-то НЁХ. Ну так в этом случае всё делается совсем иначе! В функцию передаётся хэндлер, указатель на обработчик, и этот обработчик вызывается для каждой полученной записи. Но если функция может работать с различными источниками данных, зачем ей sql-запрос? Передавай ей курсор тогда уж...
Дальше идём. Есть скрипт. Примитивный - делает выборку по параметрам и формирует из этой выборки csv-таблицу. Я бы вообще сделал это на голом PL/SQL, ну да ладно. У скрипта есть параметры, передаются в командной строке. Открытие первое - чтение этих параметров происходит в библиотечной функции! Вы спросите, что такого, ну передадим мы туда ссылку на \@ARGV, пусть читает, всё в порядке. Нет! Туда ничего не передаётся! Она читает глобальный @ARGV, от вызывающего скрипта! Комментариев, как именно используются параметры, конечно же нет, поэтому очень весело разбирать, как же эта дрянь работает. Но и это ещё не всё! Обращение к параметрам идёт по НОМЕРАМ! Я ещё десять лет назад знал про Getopt и Getopt::Long. Об этом ещё в Cookbook лохматого года написано! А они вызывают их номерами. И попробуй впихни туда ещё один параметр! Придётся использовать грязный хак - разбирать $0.
Дали почитать ТЗ. Вот мол система, разработчик увольняется, поддерживать будешь ты. Ок, читаю. Товарищи, я на 102,4% уверен, что я напишу ТЗ не худшего качества. Даже без опыта. Когда я увидел, что в разделе "цель" написано "целью данного документа является", мне захотелось громко завыть. Это не цель документа! Это цель разрабатываемой системы, мать вашу! Цель документа "техническое задание" написана в ГОСТ-е, и её не нужно переписывать в каждом техзадании! Мне пришлось пять раз прочитать ТЗ, прежде чем я понял, ЧТО разрабатывается! И ещё пару раз - чтобы понять, ЗАЧЕМ оно разрабатывается.
Скажите, это только мне так везёт? Что я вокруг вижу в основном придурков и результаты их работы? При этом придурки зачастую зарабатывают больше меня?
Нет, здесь в общем-то неплохо, но мне начинает казаться, что два обхода и одно копирование - это общепринятая практика выборки данных из базы. Главное чего я не понимаю - ради чего делать библиотечную функцию, которая не делает совершенно ничего, помимо fetchall_arrayref? Какие детали она скрывает? Как она может помочь в случае изменения бэкенда? А если это действительно так важно - допустим, у нас источник данных может быть не только РСУБД, но и скажем XML, или веб-сервис, или ещё какая-то НЁХ. Ну так в этом случае всё делается совсем иначе! В функцию передаётся хэндлер, указатель на обработчик, и этот обработчик вызывается для каждой полученной записи. Но если функция может работать с различными источниками данных, зачем ей sql-запрос? Передавай ей курсор тогда уж...
Дальше идём. Есть скрипт. Примитивный - делает выборку по параметрам и формирует из этой выборки csv-таблицу. Я бы вообще сделал это на голом PL/SQL, ну да ладно. У скрипта есть параметры, передаются в командной строке. Открытие первое - чтение этих параметров происходит в библиотечной функции! Вы спросите, что такого, ну передадим мы туда ссылку на \@ARGV, пусть читает, всё в порядке. Нет! Туда ничего не передаётся! Она читает глобальный @ARGV, от вызывающего скрипта! Комментариев, как именно используются параметры, конечно же нет, поэтому очень весело разбирать, как же эта дрянь работает. Но и это ещё не всё! Обращение к параметрам идёт по НОМЕРАМ! Я ещё десять лет назад знал про Getopt и Getopt::Long. Об этом ещё в Cookbook лохматого года написано! А они вызывают их номерами. И попробуй впихни туда ещё один параметр! Придётся использовать грязный хак - разбирать $0.
Дали почитать ТЗ. Вот мол система, разработчик увольняется, поддерживать будешь ты. Ок, читаю. Товарищи, я на 102,4% уверен, что я напишу ТЗ не худшего качества. Даже без опыта. Когда я увидел, что в разделе "цель" написано "целью данного документа является", мне захотелось громко завыть. Это не цель документа! Это цель разрабатываемой системы, мать вашу! Цель документа "техническое задание" написана в ГОСТ-е, и её не нужно переписывать в каждом техзадании! Мне пришлось пять раз прочитать ТЗ, прежде чем я понял, ЧТО разрабатывается! И ещё пару раз - чтобы понять, ЗАЧЕМ оно разрабатывается.
Скажите, это только мне так везёт? Что я вокруг вижу в основном придурков и результаты их работы? При этом придурки зачастую зарабатывают больше меня?
no subject
Date: 17 Nov 2010 18:23 (UTC)no subject
Date: 17 Nov 2010 18:29 (UTC)Но всё это НЕ ПОМЕШАЕТ ОБРАЩАТЬСЯ К ПАРАМЕТРАМ ПО ИХ НОМЕРАМ И ВЫЗЫВАТЬ @ARGV ИЗ БИБЛИОТЕКИ!!!1111
no subject
Date: 17 Nov 2010 18:52 (UTC)Надо не изобретать технологии очистки говна, а просто не срать.