Факт 3 Если проект не укладывается в сроки, то добавление рабоочей силы задержит его еще больше. Обсуждение Это один из классических фактов программирования. На самом деле это больше чем факт - это закон, «закон Брукса» [Brooks, 1995]. Интуиция подсказывает, что если проект отстает от графика, то нужно увеличить людские ресурсы, чтобы наверстать упущенное. Но, как говорит данный факт, здесь интуиции доверять нельзя. Беда в том, что люди, начиная работать в новом проекте, какое-то время «разгоняются». Они должны многое узнать, прежде чем станут приносить пользу. Но еще важнее, что эти знания им приходится получать от других участников проекта. Поэтому новые члены команды очень нескоро становятся эффективными работниками, а до тех пор они расходуют время своих коллег и отвлекают их. Более того, чем больше людей занято в проекте, тем сложнее им общаться между собой. И поэтому добавление новых кадров задерживает проект еще больше. А как Вы сичтаете? С точки зрения разработчика? С точки зрения менеджера? Обсудить это можно на форуме
Понравилась статья? Добавь в социальные закладки!
Факт 2 По результатам исследования персональных отличий лучшие программисты до 28 раз превосходят слабейших. Если учесть, что оплата их труда никогда не бывает соразмерной, то лучший программист и есть самое выгодное приобретение в индустрии ПО. Обсуждение Суть предыдущего факта состояла в том, что люди имеют значение в построении ПО. Суть данного факта в том, что они значат очень много! Это еще один постулат, такой же старый, как и сама отрасль ПО. Источники, которые я здесь цитирую, датируются в основном 1968-1978гг. Такое ощущение, что этот фундаментальный факт известен нам так хорошо и так давно, что как бы ускользает из нашей памяти без всяких усилий. Но это факт чрезвычайной важности. Если учесть, насколько лучше некоторые программисты, чем другие (а речь идет о 5 — 28-кратном превосходстве), то станет совершенно очевидно, что поддержка лучших кадров и забота о них есть задача первостепенной важности для менеджера. Именно самые лучшие, в 28 раз, (которым платят значительно меньше, чем вдвое, по сравнению с их посредственными коллегами) представляют собой самое выгодное вложение в сфере программирования. (Если уж на то пошло, то и о тех, кто лучше в 5 раз, можно сказать то же самое.) Беда в том (и, конечно, реальная, раз уж мы не руководствуемся этим фактом в своей деятельности), что мы не знаем, как определить этих лучших сотрудников. Мы годами бились, устраивая тесты профессиональной пригодности программистов, сертификационные экзамены по вычислительным системам и внедряя программы самотестирования ACM (Association for Computing Machinery), и в итоге, пролив над ними моря крови, пота и, пожалуй, даже слез, мы увидели, что корреляция между результатами тестов и показателями на рабочем месте равна нулю. (Огорчительные результаты, не так ли? Примерно тогда же выяснилось, что корреляция между оценками по курсу информатики и производительностью труда тоже ужасна [Sackman, 1968].) А как Вы к этому относитесь? С точки зрения программиста? С точки зрения работодателя? Обсудить это можно на форумеПонравилась статья? Добавь в социальные закладки!
Факт 1Самый важный фактор в разработке ПО — это не методы и средства, применяемые программистами, а сами программисты.ОбсуждениеВ создании ПО важен человеческий фактор. Именно эта мысль главная в данном конкретном факте. Свою роль играют инструментальные средства. Важны и методы. И процессы. Но роль людей намного более значима.Идея эта стара, как сама компьютерная индустрия. Она вышла из столь многочисленных научных исследований и докладов за прошедшие годы (она там встречается и сейчас), что к настоящему моменту должна быть одной из самых важных «вечных истин». Но в индустрии ПО о ней по-прежнему забывают. Мы считаем Процесс альфой и омегой разработки ПО. Мы выдвигаем инструментальные средства на роль волшебных палочек, усиливающих нашу способность создавать ПО. Мы собираем вместе разношерстные методы, называем результат методологией и требуем, чтобы тысячи программистов читали о ней, посещали курсы по ней, отполировывали знания путем зубрежки и упражнений и затем применяли ее в ответственных проектах. И все это от имени средств, методов, Процесса, стоящих над людьми.Мы даже порой возвращаемся к бесчеловечным подходам. Мы обращаемся с людьми, как с взаимозаменяемыми шестеренками на конвейере. Мы требуем, чтобы люди, поставленные в рамки слишком жестких сроков и ограничительных условий, работали лучше. Мы отказываем нашим программистам даже в самых базовых элементах доверия, а потом ждем от них доверия к нам, когда мы им говорим, что делать.В данной связи интересно рассмотреть Институт инженерии ПО (Software Engineering Institute, SEI) и его процесс разработки ПО, модель развития функциональных возможностей (Capability Maturity Model - СММ). Фундаментальное положение модели СММ состоит в том, что хороший процесс - это ключ к хорошему ПО. Основываясь на этом постулате, СММ определяет массу ключевых участков процесса и последовательность ступеней, через которые должны пройти организации-разработчики ПО. Особенно интересной СММ делает тот факт, что SEI занялся кадровым вопросом и заинтересовался ролью человеческого фактора в построении ПО лишь после того, как эта модель просуществовала несколько лет, и благодаря министерству обороны США ей был придан полуофициальный статус способа усовершенствования организаций, производящих ПО, и после того, как образ действия министерства обороны был скопирован другими организациями. Так появилась модель развития кадровых возможностей (People Capability Maturity Model - P-CMM) института SEI. Но она гораздо менее известна, и применяется намного меньше, чем модель СММ, ориентированная на процесс. Скажу еще раз, что многие профессионалы программирования по-прежнему считают, что Процесс важнее, чем люди, подчас поразительно, насколько важнее. Кажется, что мы никогда не сделаем нужных выводов.А как Вы относитесь к этому факту. С точки зрения программиста?, работодателя? Обсудить можно на форумеПонравилась статья? Добавь в социальные закладки!
ообще-то первая книга Роберта Гласса, которую я прочитал - это "Руководство по надежному программированию" (Software Reliability Guidebook - 1979). Это было в 1982 году. Юмор и здравый смысл Роберта Гласса перевернул тогда мои мозги. Например: "Уважаемые члены комиссии по расследованию, всю неделю самолет был исправен. Просто в середине Индийского океана на три минуты прекратилась подача топлива. Предполетную проверку самолет прошел в полном объеме". Как часто мне заказчики говорят: "Ну наша-то база данных работает отлично. Она уже несколько лет работает". Просто в один прекрасный момент они получат неверные данные, на основании которых людям испортят жизнь. Потом были и другие книги, как например, "Сопровождение программного обеспечения". Но когда в издательство "Символ" вышла его книга "Факты и заблуждения профессионального программирования" я был просто в восторге. Настолько она актуальная, настолько срывает всякие рекламные плакаты, что захотелось ее обсудить здесь Каждый факт кричит о глупости менеджмента и заказчиков. НО! Не хотят эти выпускники MBA читать эти книги. Понравилась статья? Добавь в социальные закладки!
Долго сопротивлялся. Количество идиотов, которые даже через форму обратной связи шлют спам, думая что он сразу появиться на сайте, переходит всякие границы. С другой стороны, я всегда был сторонником статических сайтов. Особенно после того как РБК-ностинг, обидевшись на критику (а точнее на предьявленные доказательства что они рассылают спам на профессиональной основе, просто закрыли мой сайт. Что такое статический сайт? Это набор файлов, только для чтения, которые не требуют никаких серверных функций. Особенно если он написан как позиционно-независимый, то он будет работать хоть на CD, хоть на HDD. И самое главное - ЭТАЛОН НАХОДИТСЯ У МЕНЯ!!!! Как только я разрешаю, кому либо что-то менять на сайте, то ЭТАЛОН НАХОДИТСЯ У ХОСТЕРА. Я попробовал использовать Joomle и WordPress - гемороя больше чем достоинств. Практически не работают структуры на фреймах. Верстка либо примитивная, либо все строится как карточный домик, который рушится при первом неверном движении. Создать "резиновый" дизайн - это чудеса эквилибристики. А смотреть сайт шириной 800px на экране шириной 1650px уже надоело. Наконец, попробовал популярный форум phpBB 3.0 - вроде как понравилось. 1) Встал с "пол-оборота", без какого-либо гемороя. 2) функций немного, но они работают четко. Управление понятно. 3) Потратил неделю, но все-таки сделал его во фреймах. Правда штатные шаблоны при этом не работают. И все-таки отдельные фреймы не всегда обновляются. В остальном посмотрим, как это будет работать. Понравилась статья? Добавь в социальные закладки!
Все началось достаточно банально.Я ищу интересный проект, в котором мог бы применить свои разработки и заработать на "хлеб насущный". А так как мое резюме разборосано на различных HR-сайтах, то на меня вышел директор фирмы KV-Expert - Володин Владимир Евгеньевич.При чтении документации с сайта сложилось достаточно благоприятное впечатление. Конечно по интрефейсу системы было уже видно, что система содержит архитектурные ошибки. Но в разговоре с Владимиром Евгеньевичем сложилось впечатление, что он понимает эти проблемы, что он готов к их решению, что именно мне он хочет поручить их решение и т.д. Демонстрация системы разработки в офисе показала, что в ней есть интересные идеи, и в общем хотелось поскорей посмотреть на систему изнутри.Несколько насторожило постоянное подчеркивание что это секретная информация, что многие дадут много денег "за любой файл с этого компьютера" и т.д. и т.п.Я обещал не раскрывать структуру БД и не буду этого делать. Но начало работы было в том, чтобы задокументировать существующую БД. А для этого мне нужна была сама БД. Мне ее выдали. БД была в формате Firebird. Т.е. я имел меньше того, что имел любой заказчик. На перевод БД в читабельный скрипт потребовалось 22 часа чистого рабочего времени (скрипт записан в MS Word и содержит 865 страниц, 56889 строк, 1624761 символов). Это показывает цену секретности. Еще бы некоторое время и скрипт был бы рабочим, с которым можно делать все что угодно.Что при этом получилось:- количество таблиц - 54- представления - 0- триггеры - 112- процедуры - 586
- генераторы - 84- роли - 0!!!
- индексы всего - 261
-- Primary key - 48
-- Foreign key - 0!!!-- Unique key - 1!!!
Что поразило прежде всего - полное отсутствие ролей, связей и определения уникальности.
Когда начал разбираться - определилась основная архитектура этой системы. Основой служит список текстовых строк, в который входят названия документов, названия товаров, адреса, ФИО, названия форм интерфейса и т.д. Все это лежит в одном столбце и следовательно каким-либо образом идентифицировать товар или наименование фирмы в принципе невозможно. По определению возможны повторения, поэтому Uniqeu key невозможен. Для ккждой строки указывается ряд констант которые формируются процедурами по каким-то правилам. Вся логика управления производством (а представлена эта БД была как ERP-система) лежит на процедурах, порой достаточно сложных и изощренных. Например, в одной процедуре достаточно большой блок анализирует адрес и разбирает его на части по коду ОКАТО используя какие-то умолчания на длину строки и ее отдельных частей. Другая процедура вычисляет когда последний раз вводился курс валюты и вычисляет на его основе необходимый курс для инвойса. Вместо этого можно было просто ввести таблицу курсов валют без промежутков по датам и конвертацию делать прямо в запросе.
И так для чего же нужна была СУБД Firebird?
- управление пользователями осуществляется процедурами
- управление непротиворечивостью данных осуществляется процедурами
- управление уникальностью не осуществляется никем и ничем
- управление целостностью не осуществляется никем и ничем.
Т.е. СУБД Firebird нужна была только для хранения данных в таблицах и выполнения процедур.
Такие системы безграмотные студенты писали в 1994 году на Clarion. С таким же успехом в качестве базы данных можно было взять текстовый файл (или несколько файлов), а процедуры написать на Бейсике. Так например была пострена СУБД RISS 1987 года.
Обидно было то, что в разговоре Володин В.Е. вроде как понимал ошибки баз данных, про которые я ему рассказывал, и на каждую утверждал, что "его-то база данных написана правильно и без ошибок".
В общем хуже базы данных я не видел. Это даже нельзя назвать базой данных. Про методы учета я уже не говорю. Доказать их правильность невозможно, потому что они построены на цепочках алгоритмов, а не на структурах данных.
Понятно когда руководитель фирмы "разводит лоха на деньги" чтобы получить прибыль, но разводить своего будущего разработчика - это нонсенс.
Обидно было настолько, что несколько дней не было слов для того чтобы что-то написать.
Понравилась статья? Добавь в социальные закладки!
Я начал дискуссию под этим названием на сервисе "Мой круг" и вот что из этого получилось Вопросы: Кто и как тестирует БД - поделитесь опытом. Что тестируется? Как тестируется? Какие инструменты и технологии используются?
Всказывайте свой опыт, а не ссылки в Google или ЯндексеСветлана Ефимова автоматизация производства А зачем отдельно тестировать базу данных? Если она построена с использованием 3-й нормальной формы, то насколько мне известно, MSSQL сервер сам проверит соблюдение основных правил построения и выскажется, если найдет что-то не верным. Да и ErWin на эту тему тоже подсказки выдает, по-моему.
И потом сейчас есть много методик тестирования программного обеспечения. Александр Лещинский Quis custodiet ipsos custodes? Re: Светлана Ефимова
Нормализовать все-таки - до 4... И 3НФ - не цель, а средство, и кроме отнормализованной базы важны (иногда - жизненно) еще и индексы. И, скажу по секрету, работа базы на 100 записей с 10 транзациями в минуту сиьно отличается от нее же - но с 100 лямами записей и 10 транзакций в секунду. Иногда и денормализовывать приходится... И не пользоваться МСовским ужасом, летящим на крыльях ночи. Да и база это не только таблицы,это еще и сторедки, и вьюхи, которые (криво сделанные) могут убить все остальное правильное Светлана Ефимова автоматизация производства Re: Александр Лещинский
Конечно, конечно. И индексы, и хранимые процедуры, и представления - это все я для себя включаю в базу данных. И сейчас работаю с базами, занимающими от 30Гб и выше. Та что с этими проблемами сталкивалась лично. Да, наверно, Oracle лучше, чем MS, но он значительно дешевле и на мой взгляд, проще в использовании. И выбирать SQL-сервер надо, конечно, по потребностям пользователя.
Иногда и денормализация нужна, но в этом случае мне кажется, лучше OLAP-кубы использовать. Или что-нибудь подобное. Александр Лещинский Quis custodiet ipsos custodes? Да, я забыл ответить на вопрос
Тестирование - глазами... а потом - стресс-текст на тушке предполагаемого объема и интенсивности пользования Андрей Архангельский Программист, разработчик БД Re: Светлана Ефимова И потом сейчас есть много методик тестирования программного обеспечения. Вы уже много раз пишите эту фразу.
В данном конкретном случае можно привести те, которые Вы используете?
Только напомню - тестируем не программное обеспечение, а БД.
Светлана Ефимова автоматизация производства Re: Андрей Архангельский
Я использую для тестирования собственно базы данных:
сначала визуальная проверка корректности всех отношений,
а потом после создания базы данных - ввод данных причем и последовательный (начиная со справочников и заканчивая оперативными данными) и наоборот, ввожу заведомо некорректные оперативные данные и проверяю все ли ссылки у меня правильно работают.
Для проверки скорости работы при больших объемах - надо ввести как минимум 1000 записей в таблицы с оперативными данными.
А разве в инете нет методик тестирования программного обеспечения? Составление TEST-Case и отработка по ним всех веточек работы ПО. Андрей Архангельский Программист, разработчик БД Re: Светлана Ефимова а потом после создания базы данных - ввод данных
Сколько, какие, сколько человек это делает, какое у них образование? ввожу заведомо некорректные оперативные данные
Как узнать какие данные некоректные? Для проверки скорости работы при больших объемах - надо ввести как минимум 1000 записей в таблицы с оперативными данными.
У меня минимальный размер транзакции - 100000 записей. А ввожу 2-3 млн. записей. Измерением скорости занимается сама БД (есть встроенные таблицы) А разве в инете нет методик тестирования программного обеспечения? Составление TEST-Case и отработка по ним всех веточек работы ПО.
Еще раз повторяю! Как тестировать ПО я знаю. Я говорю о тестированиее БД.
Я ведь не только здесь этот вопрос задаю. На нескольких специализированных форумах за 2 недели ни одного ответа.
Светлана Ефимова автоматизация производства Re: Андрей Архангельский
Данные для меня некорректны
1. неверные ссылки на справочники. Если можно ввести неверное значение в поле ссылки (если быть точной, то значение отсутствует в справочнике и может быть введено в ссылке). Значит отсутствует ссылочная целостность.
2. нет проверки на типы данных.
3. неверно обрабатывается 0 и пусто
4. Если должны быть ограничения по вводу данных (например, нельзя вводить в заданное поле отрицательных значений), это тоже должно быть проверено. Правда обычно такие вещи сейчас на базу не вешают.
5. Проверка на обязательность заполнения.
6. Проверка на уникальность индексов (если у вас в базе должны быть уникальные индексы)
Хватит?
Диана Рысина неотразимый программист-психоаналитик Господа, вы все намешали в кучу. Что именно обсуждаем: выбор СУБД; адекватность построения Инфологической модели; достаточную степень нормализации или оптимизация физической модели?
"Котлеты отдельно, мухи отдельно..." (с) Путин В.В.
Александр Лещинский Quis custodiet ipsos custodes? Re: Диана Рысина
Мы обсуждаем "Как проверить, что все работает как надо" Диана Рысина неотразимый программист-психоаналитик Re: Александр Лещинский
Видимо, уже никому не надо... Андрей Архангельский Программист, разработчик БД Re: Диана Рысина
Никто ничего не мешает.
Придумали БД. Сделали БД. Хотим убедится что БД выполняет свои функции.
Главная функция БД - если кто-то внес в БД данные, то мы должны найти их унифицированным для ЭТОЙ БД способом. ВСЕ!
Все остальные мухи и котлеты отдельно.
Как говорил мой хороший знакомый Кушниренко Анатолий Георгиевич (из МГУ) "Бессмысленно обсуждать производительность неработающей программы".
Точно также бессмысленно тестировать БД на производительность, если внесенные данные "пропадают в туне" и через год работы количество "мусора" в БД достигает 50%. Андрей Архангельский Программист, разработчик БД Re: Светлана Ефимова
Мне кажется у Вас идеальная БД. Могу ли я ознакомится со структурой этой БД и тогда в моей книге появится единственный пример правильно спроектированной БД.
Судя по Вашим высказываниям у Вас суперинструменты для разработки, которые могут создавать любые отчеты. У меня этих инструментов нет. Поэтому буду благодарен, если Вы покажете мне структуру Вашей БД и ответите на возможные впоследствие вопросы.
P.S. Ответа на эту просьбу не последовало Дискуссия на форумах sql.ru, ibase.ru, source.ru и др. были еще короче!!!
Понравилась статья? Добавь в социальные закладки!
"Абстракция исполнения лежит в основе всего понятия "алгоритма" настолько глубоко, что обычно ее считают само собой разумеющейся и оставляют без внимания. Ее назначение в том, чтобы сопоставлять между собой различные вычисления. Иначе говоря, она предоставляет нам способ осмысливания конкретного вычисления как элемента большого класса различных вычислений; мы можем отвлечься от взаимных отличий элементов такого класса и, руководствуясь определением класса в целом, высказывать утверждения, применимые к каждому его элементу, а следовательно, справедливые и для конкретного вычисления, которое мы хотим рассматривать. Чтобы разъяснить, что подразумевается под "вычислением", я опишу сейчас невычислительную конструкцию "получения" (я преднамеренно не употребляю термина "вычисление"), например, наибольшего общего делителя чисел 111 и 259. Она состоит из двух картонных карточек, расположенных одна поверх другой. На верхней карточке написан текст "НОД(111,259) =". Чтобы получить от конструкции ответ, мы поднимаем верхнюю карточку и кладем ее слева от нижней, на которой теперь можно прочесть текст "37". Простота карточной конструкции является большим достоинством, но она омрачается двумя недостатками — мелким и крупным. Мелкий недостаток состоит в том, что хотя эту конструкцию можно в самом деле использовать для получения наибольшего общего делителя чисел 111 и 259, но помимо этого она мало на что пригодна. Однако крупный недостаток в том, что, как бы тщательно мы ни проверяли устройство конструкции, наша вера в то, что она вырабатывает правильный ответ, может основываться только на нашем доверии к ее создателю: он мог ошибиться либо при проектировании своей машины, либо при изготовлении нашего конкретного экземпляра." Эдгар Дейкстра "Дисциплина программирования" Гениальные слова! Для молодых программистов, которые не то что книги этой не читали, но и имени такого не слышали, даю бесплатный совет — прочитайте их ещё раз. Не грех читать их каждый день на ночь, особенно когда появляется желание "срубить денег по легкому" и "сварганить проект за пару дней, где-нибудь в гараже". Сколько раз мои заказчики (часто будучи сами программистами) говорили мне "Разработай структуру и клиентское приложение, а данные набьют девочки". Они даже не задумывались о тестировании базы данных. Для них важнее был дизайн интерфейса клиентского приложения, чем правильность базы данных. Некоторые, особенно продвинутые, используют различного рода генераторы для создания большого объема данных, на которых они якобы тестируют базу данных. Такого рода испытания могут проверить в лучшем случае производительность базы данных, но ничего не говорят о достоверности данных в ней. Но, как говорил Кушниренко Анатолий Георгиевич: "бессмысленно говорить о производительности НЕРАБОТАЮЩЕЙ программы". В случае баз данных если выдаваемые данные неверные, например "Иванов Анастасия Георгиевич", или известно, что данные есть, но найти их невозможно, то можно говорить, что база данных "не работает" или "не выполняет своих функций". Кто-то скажет — это пользователь ввел всякую ерунду, причем здесь программист. На самом деле, в подавляющем большинстве случаев именно программист где-то упростив, где-то сократив, где-то чего-то не учел, где-то не разьяснив как поступать в конкретной ситуации дал возможность пользователю ввести в базу данных НЕПРАВИЛЬНЫЕ данные. В качестве простых примеров: БД "ГИБДД Москвы 2002г." — всего 4451000 записей. 1) Дата рождения указана как 00000 или 000037 (или т.п.) — 50487 записей. Ошибки по другим полям также исчисляются тысячами. 2) Имя "Александр" введено 153-мя способами, отчество "Владимирович" — 117-ю способами, и т.д. БД "ГИБДД Москвы 2005г." — всего 8366000 записей по автомобилям. 1) Автомобилей "ВАЗ-2109" в г.Москве всего 4 штуки!!! Остальные нужно искать как модель="ВАЗ", марка="2109" 2) Для автомобилей "ВАЗ" формально правильных VIN-кодов всего 12 штук. Остальные записаны РУССКИМИ буквами. Хотя стандарт по VIN-кодам начинается с описания символов, которые можно использовать для обозначения. Исключены такие символы как O, I и др., которые можно спутать с цифрами. Функция, которая позволяет вводить правильный VIN-код при любой раскадке клавиатуры занимает 30 строк текста и пишется за 10 минут. БД "Прописка Москвы и МО 2005г." - всего 23 млн. записей. 1) В БД не менее 20% записей являются мусором, т.е. для одного человека существует более одной записи. Рекорд — 1536 записей для одного человека. Какая из них верная? 2) Примерно 2% адресов представляют собой набор из нескольких различных адресов. Такие примеры можно приводить до бесконечности. "Быстренько сварганенная" база данных очень скоро превращается в кучу мусора, занимая место на диске, расходуя ресурсы процессора и работников. База Данных (БД) — это прежде всего данные. Только реальные данные и в достаточном (реальном) количестве подтверждают ваши теории и предположения относительно структуры и алгоритмов. Выборка из таблицы в 10 записей и таблицы в 10 миллионов записей требует совершенно разных подходов как к структуре БД, так и к интерфейсу пользователя. Насколько это затратно можно оценить на следующем примере: Создавая банковскую систему, которая должна выдавать кредиты жителям г.Москвы и Московской области, необходимо наполнить ее 25 миллионами достоверных реальных записей (число жителей в г.Москве и Московской области) или хотя бы приблизится по порядку к ней. И тестируется в данном случае не производительность системы, а возможность спутать одного кредитора с другим. Стоимость одной ошибки здесь равна размеру кредита плюс репутация банка. Программисты, которые разрабатывали эти БД сдали на отлично экзамен как минимум по одному современному языку программирования. Они будут жонглировать нормальными формами и достоинствами таких чудо-технологий как .NET и Web-сервисы. Но ошибки, которые пользователи внесли в эти БД, лежат в архитектуре БД и неумении разработчиков применять самые элементарные понятия програмирования. Понравилась статья? Добавь в социальные закладки!
|
|
