29 декабря 2010 г.

Несколько мыслей о проектировании работы приложений с данными

Совсем недавно писал о решении довольно непростой задачи, связанной с некорректной работой слоя данных. Изменения затронули самое «сердце», фундамент приложения. В связи с этим решил запомнить для себя парочку важных прикладных мыслей относительно работы с хранилищами данных. Ведь, пожалуй, любой IT-проект таковое имеет - поэтому не хочется сталкиваться с подобными проблемами в будущем.

1) Модель данных должна быть предельно простой и лаконичной. Это важно в виду многих причин. Простую модель проще понять и, соответственно, разработчикам проще с ней работать и строить на ее основе необходимую бизнес-логику. С технической точки зрения простая модель проста и в своей реализации. Не нужно рекурсий и сверхглубоких вложений объектов друг в друга. Не нужно обилия связей, особенно это касается связей типа «многий ко многим». Понятно, что не всегда возможно этого избежать. Где-то прикладная область диктует свои правила и создает дополнительные ограничения. Но во всех остальных случаях простота модели вполне достижима.

Почему важна простота реализации? А потому, что в большинстве проектов обязательно используются одни и те же связки уже готовых компонентов для представления слоя данных. Это СУБД плюс какое-нибудь ORM решение, если говорить о разработке с помощью объектно-ориентированной технологии программирования. Иногда эти готовые решения хорошо справляются со сложными взаимоотношениями объектов, но иногда, как показал наш случай, не очень. Когда случится это «не очень» никто не знает. Но с уверенностью можно сказать, что проблемы в этом случае вам обеспечены. Как минимум придется провести N-ое количество часов в попытках понять работу этого черного ящика под названием ORM+СУБД. Или надеяться на помощь со стороны поставщика готового решения. В любом случае все это ставит успешное завершения проекта в срок под угрозу.

14 декабря 2010 г.

Перестраиваем фундамент приложения

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

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

Если проводить аналогии, то эта задача будет похожа на перестройку фундамента жилой многоэтажки. Причем, без эвакуации проживающих в ней людей :-) Того и гляди, кто-нибудь обязательно выпадет из окна. А если не выпадет, до обязательно перепутает свою квартиру и подвал соседа. У кого-то очередная подпорка будет проходить по центру кровати в спальне. Или вообще дом в конце концов будет стоять под углом в 30 градусов к земле (что, само собой, опять же спровоцирует внезапные падения из окон). Тот еще геморрой одним словом.

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

7 декабря 2010 г.

Так возможно ли качественное тестирование силами разработчиков?

Среди множества статей, книг, докладов конференций периодически наталкиваюсь на мысль, что качественное тестирование силами разработчиков невозможно. Мол, программисты не любят тестировать свой код - примите это как аксиому. Поэтому без полноценного отдела тестирования или просто тестировщика вашему проекту крышка. Кроме того, тестирование силами разработчиков еще и дорого. А учитывая неудовлетворительный результат этого тестирования затраты ресурсов будут неэффективными.

Так вот, я с такими утверждениями категорически не согласен. Могу согласиться, разве что, с тем, что время разработчиков действительно может стоить дорого. Но вот остальное, на мой взгляд, очередной миф.

Безусловно, тестирование на проекте должно присутствовать. Но не как отдел или конкретные сотрудники, а как процесс. Если уж бросаться в крайности, то не важно, кто именно занимается тестированием. Важно, что тестированием занимаются в принципе и оно органично вписано в процесс разработки ПО.

1 декабря 2010 г.

Книга месяца: «Психбольница в руках пациентов», Алан Купер

Вот и началась зима - в этом году как никогда по расписанию. Уже два дня назад в Гродно резко выпал снег и столбик термометра упал в чувствительный для организма «минус». Лично у меня зима ассоциируется с таким «основательным» временем года. Когда хочется сесть в теплое кресло, заварить чашку чая и внимательно изучить какую-нибудь новую книжку или разобраться в новой технологии. Другими словами, рабочее настроение улучшается.

Если месяц назад мы рассматривали легкий и до безобразия позитивный «Rework» от основателей 37signals, то в этом месяце, как и полагается зимой, книжка будет более глубокая и требующая внимания. Да-да, и это несмотря на название: «Психбольница в руках пациентов» за авторством Алана Купера, эксперта в области взаимодействия приложений с пользователем.

Эта книга далеко не новинка и пережила уже одно переиздание на русском. Любой, кто интересуется проектированием взаимодействия и юзабилити давным давно ее прочитал. А так ли это? Я, конечно, не эксперт в этих областях. Но в целом они мне достаточно интересны, чтобы покупать и читать книги и статьи других авторов - Стива Круга или Якоба Нильсена. Но, к сожалению, на эту замечательную книгу я обратил внимание только недавно. И причина этому очень проста - убогость дизайна обложки первого русского издания. Именно это оттолкнуло меня от прочтения этой книги раньше, посудите сами и посмотрите на старую обложку под катом.