суббота, 24 сентября 2011 г.

Стандарты именования объектов БД

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

По своему личному опыту могу точно утверждать, что единообразие наименований объектов в БД очень часто существенно экономит время . Преимущественно речь идет о времени на написание SQL-запросов особенно, когда приходится их писать сотнями в день и когда имеешь дело с большой разветвленной БД, где десятки а иногда и сотни таблиц. В этом случае все названия запомнить , конечно же , нереально, но если ты заранее знаешь , что имеешь дело со словарной таблицей и у нее обязательно есть mnemonic , и description, то это существенно облегчает жизнь. Если же проектировщики и разработчики задумывали и создавали БД "кто в лес, кто по дрова", то ты заранее не знаешь, description там или же desc, а может descr или вообще поле с опечаткой.. В итоге запрос с первого раза не пишется, надо смотреть описание таблицы - в общем, делать лишние движения. Они небольшие, но их много и вообще , как в песне поется, "не думай о секундах свысока"...
С экономией времени на составлении запросов вроде бы все ясно, потому что явно. Есть и другие менее явные положительные эффекты от единой стратегии именования.
Буквально на днях сталкивался с конкретной задачей автоматизации, которая решалась бы гораздо меньшими усилиями и существенно меньшим количеством строк кода, если бы не винегрет в названии одинаковых по смыслу полей в разных таблицах. То есть и в направлении автоматизации тестирования возможна экономия сил , нервов и средств при минимально едином подходе.
Еще один положительный эффект - новички ( и разработчики , и тестировщики ) гораздо быстрее осваивают систему, если при ее проектировании и разработке применяются единые правила наименований объектов. Быстрее осваивают - читай, быстрее начинают приносить реальную пользу.

В общем, везет тем , кто везет. А что делать если приходится работать с тем, что есть? Если , к примеру, схема БД росла и множилась годами, накопила кучу болячек, пережила не одну текучку кадров и к стандартизации нотации объектов в этой БД относились "с прохладцей"? Конечно же, не надо посыпать себе и тем более другим голову пеплом , не надо искать виноватых и жаловаться всем на всех.. Просто старайтесь конструктивно доводить до ответственных лиц необходимость рефакторинга схемы БД , если такого осознания у них нет. Если же это осознание уже есть, то готовьте тесты , проверяющие, что в результате рефакторинга система дает конечному пользователю как минимум то же самое, что и до него ))

Полезная информация по теме:
[1] Форумы на sql.ru - искать по "правила именования объектов базы данных" - тут знающий народ, решающий реальные задачи. Много хороших и дельных советов и практик.
[2] Хорошая книга как раз о рефакторинге уже существующей БД: Refactoring Databases: Evolutionary Database Design (Addison-Wesley Signature Series)
Scott W. Ambler, Pramodkumar J. Sadalage

среда, 14 сентября 2011 г.

Результаты опроса: "Какую систему контроля версий Вы используете"..



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

Системы контроля версий
Небольшие комментарии по результатам:
Лидерство Subversion предсказуемо. Как говорится - "сложилось исторически". Для меня наиболее интересен был "спор" Git и Mercurial. Git действительно более раскручен (чего стоит только один github), хотя особых преимуществ в функциональном плане не дает. Остается интересным и открытым вопрос, что кроется за словом "Другая" - там точно есть TFS, bazaar и многие другие... Удивила CVS - судя по всему , эта система скоро станет экзотикой - мир не стоит на месте...

воскресенье, 11 сентября 2011 г.

Небольшой оффтоп: возвращаем в жизни роутер

Несколько дней назад внезапно из строя вышел мой домашний WiFi-роутер Asus Wl=500G Premium.   Симптомы: невозможно достучаться даже по проводу ни по одному из протоколов, горят все лампочки, выключение , сброс настроек ни к чему не приводят. Обращение к знакомым обладателям подобных устройств и поисковой выдаче гугла выявило, что "слабым" местом этого девайса является его блок питания. Симптомы при выходе его из строя похожи. Вскрываю БП и действительно вижу слегка вздутый конденсатор. Радуюсь, что как правило в двух местах сразу такие вещи не ломаются и причина скорее всего в этом. У меня полетел конденсатор на 1200микрофарад, 10 вольтовый. В "Чипидип"е , что на Проспекте Мира куплена замена : радиальный , 1000 микрофарад (на 1200 найти не удалость), 10 вольтовый. Старый выпаян, новый впаян и, ура, в каждом уголке моей квартиры снова появился его величество Интернет =)

Конечно же, можно было просто купить новый БП. Но как-то это не интересно, что ли.

В общем, небольшой крюк в электронный магазин по дороге с работы домой , 20 минут на разбор корпуса БП (та еще нервотрепка) и 10 минут пайки неопытными в этом деле руками. В итоге все работает отлично.
Надеюсь, кому-нибудь, приведенная информация будет полезна.