Мышление письмом по заданию на моделирование из первой главы.
Переделывала объекты и отношения три или четыре раза. В принципе с этой идеей смиряешься, как тесты - red, green, refactoring. Пишем как-то, потом пытаемся это заставить работать, потом наводим порядочек. Сложно по ментальным объектам понять, что это работает. Кажется, что вот же мы с коллегами этими словами разговариваем, вроде понятно. Ключевое слово “вроде”. И там дальше целая цепочка: вроде понятно, вроде описано, вроде работает. Задумалась о том, что стоит хотя бы пытаться думать о том, а что мы такое пытаемся сделать в реальности этими ментальными объектами. Сразу возникают уточняющие вопросы.
Хорошо начинать строить онтологию от индивидуальных объектов.
Это то, как я запомнила. Смысл в том, чтобы вместо категорий объектов, брать максимально конкретные экземпляры объектов. Я склонна оперировать именно категориями, потому что программирую для всех объектов из категории. Понятно, что в конкретный момент алгоритм считает конкретные объекты. Но в целом, у нас таблички в БД это пачка объектов, мы её и описываем, как пачку. Во множественном числе сама таблица называется “events”, а внутри атрибуты/колонки/свойства (name, date, created_at, deleted_at, event_type). Конкретное значение это строка таблицы. Но при построении онтологии оказалось удобно начинать с конкретного объекта. Т.е. как раз с примера этой строки из таблицы. Когда так простраиваешь объекты и связи, вдруг оказывается, что понятная цепочка требует раскрутить её дальше. “Вроде понятно” оказывается “на самом деле непонятно что происходит”.
Жду 4D онтологию в следующих главах. Будем дальше разбираться.
Плоское мышление
Ещё заметила такую штуку с собранностью. Это скорее всего тоже из работы приходит. Читаешь длинное описание и понимаешь его плоско. Максимально буквально. Написано в задаче общей фразой - выключить налоги. Или в задании в курсе “роль коллеги”. Что написано, то и получите. Я шучу иногда “сделано по ТЗ, ничего не работает”. Но в точности по ТЗ. Т.е. как бы надо уточнять чуть ли не каждое слово. Но тут проседает собранность наверно фундаментальная. Я когда в хорошем состоянии, я допытываюсь. И есть ещё момент с разделением ролей, т.е. если мне это кривое описание коллега принёс, я уже устала ему помогать, или сделать и проверять, то косяки идут мимо внимания. Кто писал, к тому и вопросы. Потом конечно может начаться “да вы просто неправильно поняли”. И вот с этой степенью формализма очень большие проблемы в коммуникации. Надо поймать поставщика задачи и вытащить из него “какие именно налоги и где они хотят выключить”, оказывается что не все налоги, а один конкретный тип налога в паре конкретных мероприятий.
К чему это я? Курс надо читать вниманительно. Хотя обратная ситуация тоже бывает, хоть и не у меня. Пытаться добиться формального определения каждого слова не помогает, сделать домашку. Надо делать её из какого-то своего понимания, потом уточнять это понимание.
Наверно так: задание читаем внимательно, пытаемся думать, потом делаем, тоже не засиживаясь. А тексты учебника читаем, пытаемся осмыслить, но это не жёсткие правила оформления таблиц в PostgreSQL версии 15.5. Не сломается ничего от того, что понятно не супер формально. А вот в таблицах в БД сломается, если я вместо create table, напишу creation table.
