Tags: программирование

(no subject)

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

Управление задачами в Дагеробазе

Сука, я уже третью неделю пишу этот фрагмент кода, и чем больше пишу, тем глубже зарываюсь. Тяжело писать геном организма компании.

Были сначала поля у класса:
id
name
start­­­_date
red_line
dead_line

Сегодня уже расползлось до:
class Task {
public $id;
public $author_id;
public $recipient_id;
public $batch_id;
public $birth_date;
public $rise_date;
public $red_line;
public $dead_line;
public $is_active;
public $subject;
public $phase_id;
public $condition;

Теперь вот всплыло, что задачи-то имеют некоторое подчинение. Помимо того, что все они могут принадлежать определённому пучку задач batch­_id. (Классический пучок задач - фотосъёмка.) Так теперь ещё и внутри пучка одни задачи имеют rise_date функцией от даты исполнения иных задач.
Иными словами устанавливать дату актуальности задачи "опубликовать съёмку" до того как задача "обработать съёмку" была исполнена - неверно.

А всё от чего эти беды у меня? От кустарщины, правильно! Нормальные люди пишут сначала схему всей архитектуры. Потом правда всё равно всё переписывают, но зато есть возможность попинать тех, кто схему писал.

Приснилось ночью

Оказывается, деятельность любой компании можно разбить на задачи сколь угодно малого дискрета. Стало кристально видно, как именно наконец перевести чек-листы в электронный вид, не прибегая при этом к тупому копированию того, что работает сегодня на бумаге.

Съёмка под таким углом обзора оказывается, так сказать, пучком задач. Чек-лист - пучок задач. Приём сотрудника на работу: пучок задач. Увольнение - пучок задач.

Расписание фотосъёмок на конкретного фотографа - листинг задач с фильтром по объекту задачи (фотосъёмка) и субъекту задачи (фотограф). Ура! Всё складывается!