Скажу как пользователь. Меню ПРОПИСНЫМИ буквами нахожу крайне удобным. Ведь дизайнеры же верещат, что должно быть понятно и удобно, так вот — мне так понятно и удобно. И это главное. Красота? Ну я привык на столько, что по-другому для меня уже немного дико.
Выделили вам как менеджеру большую задачу, а вы уже колупайте её как хотите и раздавайте своим подчиненным. Если у подчиненных есть свои подчиненные, они могут поступать аналогично. Или разбивать задачу на подзадачи чисто для себя и для правильной организации и оценки времени. Не ищите проблем там, где их нет :)
Во-первых, при такой структуре можно посмотреть готовность работы на любом уровне иерархии. Что называется, не вдаваясь в детали. Это очень удобно для менеджеров, которым может нет дела как идут дела с реализацией отдельных функций отдельных программистов, а текущее состояние задач по-крупней. Во-вторых, подзадача не может быть отнесена к двум задачам. Потому что иерархия проекта и иерархия задач — разные вещи совершенно. Хоть и на начальном этапе возможно сходство. Поймите, наконец, что иерархия в задачах — это декомпозиция. Большие задачи разбиваются на мелкие, но это в совокупности одна и та же задача. Это не просто папка для подзадач. Так вы своих пользователей запутаете.
Проект
— Система 1
… — Модуль 11
… — Модуль 12
…… — Решение задачи XXX
…… — Интерфейс
……… — Реализация
……… — Логгирования
…… — Решение задачи YYY
……… — Подготовка данных для исследования
……… — Разработка структуры
и т.д. и т.п.
Если в одном трекере будет это всё валяться сплошняком, будет ад. Теги, связи — конечно хороши, но они не дают надёжную чёткую структуру что из чего состоит, потому что иерархия задач подразумевает: какая работа частью какой работы является. Она может зависеть от других задач, быть с ними связана, укладываться на диаграму, быть триггером для старта/завершении цикла, но она всегда является частью чего-то большего.
В любом случае иерархия есть, как минимум в разрезе Проект — Задачи. По сути проект это и есть одна большая задача. Хотя мне не нравится, когда некоторые разработчики выбирают подход «Всё есть задача». Тоже фейл но в обратном направлении.
Возможно, вы пытаетесь изобрести велосипед. Ничего лучше иерархии нет. Это абстракция понятная каждому. А трудности, которые испытывают пользователи — это проблема плохого дизайна ПО.
Хороший пример с файловой системой. Папки и подпапки — это чрезвычайно удобно. Доказано временем. Хотя это не единственный способ для организации данных.
Просто дайте людям возможность создавать подзадачи. Если они хотят плоский список, пусть не создают подзадач. Какая проблема? Я и правда видел на своём веку людей, которые все свои файлы хранили в одной единственной папке: музыку, документы, картинки и т.д. Но все люди разные, и всё сильно зависит в команде от того, как работает менеджер. Вы его работать по-своему не заставите. Просто дайте инструмент. И сделайте его простым, понятным и очевидным.
Не надо за людей решать: вам не нужны подзадачи (потому что мы не знаем как сделать работу с ними удобной).
Любую задачу можно разбить на несколько более мелких задач. Этот процесс называется декомпозиция. До разумных пределов конечно. Что автор увидел в этом неестественного?
Что мешает совместить barcode с напечатанным кодом?
С другой стороны, простейший ведроид за три копья легко справится с задачей. Не надо ничего выдумывать, считайте что у большинства людей аппарат всегда есть под рукой, осталось поставить туда соответствующий софт. Переписывать карандашиком на бумажку какие-то неудобочитаемые коды в наше время — натуральное издевательство. И бумагу портитить почём зря. Всё правильно там написано. Оправдания админской лени разобраться и найти приемлемое недорогое решение — не принимаются!
Вы понимаете, что иерархия >= плоский список? Не хотите, не пользуйтесь. Но когда понадобиться, должно быть под рукой. То, что вы говорите, якобы иерархия усложняет — чушь. Конечно решение с точки зрения программного кода будет сложнее, это да. Если именно это вызывает у вас сложности, то тогда всё понятно, могли бы сразу сказать, что для вас это сложно, и вы к таким решениям ещё не готовы. А для пользователя сложнее не будет ничуть. Он может просто не создавать подзадачи. И всё. В моих заметках «Покупки», это примерно тоже самое, что крестик на руке. Мне нужно записать какие покупки. И не мне одному, как можете судить по комментариям. В общем, судите сами. Если делаете чисто для себя, так и скажите. Зачем людям голову морочить? «Вот смотрите какой я для себя тулз слабал».
Это не имеет отношения к вашей реальной жизни, контекст конкретно обозначен: PrettyTasks. И глубины там не наблюдается. Между «просто» и «примитивно» существует тонкая, но вполне ощутимая грань. Моё мнение, что ваше решение к «простоте» не имеет отношения, хотя вы именно об этом заявляете. Опровергаю ваше заявление. Ваше решение примитивное и неудобное. Если вы возьмётесь за труд и прошерстите большинство постов, касающихся менеджеров (управлению) задачами, то увидите, что люди в основной массе хотят иерархию. Можете не прислушиваться, имеете полное право послать всех к чертям и делать как считаете нужным :)
Ребята, сварганившие претти таскс, похоже живут в плоской двухмерной жизни. Ибо только они представляют, что такое «Провести совещание», я же не вижу в таком таске ни малейшего смысла хотя бы без пары тройки вопросов, которые надо обсудить. Или это как в бюджетных организациях, посидеть и коллективно поковырять в носу? :) Я часто пользуюсь обычным ежедневником, посмотрел, у меня записаны таски на каждый день, но больше половины состоит из нескольких подпунктов. Как этого можно не понимать? Конечно же, нужно ещё одно плюс сто тысяч пятьсот первое приложение, чтобы запланировать «Поход за колбасой».
В претти таск я забиваю «Подготовиться к выходным на лыжах» — этот таск последовательно состоит из нескольких задач, в числе которых магазин, и список товаров. Куда мне их пихать? В комментарий? Создавать отдельно список? Ни разу не вижу даже намёка на простоту, которой вы так гордитесь. Мне надо быстренько спланировать подготовку. В приложении сделанном для людей я создам таск, и по мере размышлений накидаю подтаски. У подтаска похода в магазин будет еще несколько вложенных тасков с конкретными товарами. Которые куплю — вычеркну, что не куплю, буду искать в других магазинах. Это очень удобно. Никаких концепций списков. Проще — некуда. Но вы как и Remember The Milk навязываете неудобные списки. Которые в целом решают совсем другую задачу: разделение тасков по группам, типа «Семья», «Дом», «Работа» и т.п. У вас же всё перемешалось. И не удобно ни капельки. Если только для совсем плоских задач. Но жизнь не плоская, в независимости от того, как вы на неё смотрите. Прислушайтесь и приделайте иерархию :) Успехов!
Давайте не будем пересаливать мысль убойными трёхбуквенными сокращениями, потому что суть теряется. Что вы хотели сказать лично мне не понятно. Вынес только одно. Есть некие неугодные вам «говнокодеры», а есть DDD, DTO, POCO/POJO, ORM, MVC и «истинно правильное программирование».
Теория автора разбивается о банальный пример. День Рождения. Давайте создадим такой тип, ибо вполне уместно. День Рождения не должен быть ранее, допустим 100 лет от текущей даты и позже текущей даты. И День Рождения не может быть пустым, ибо не бывает таких людей, у которых нет Дня Рождения. Посему должен быть обязательный конструктор в который надо передать Дату, и если что-то с ней не так, выплюнуть исключение. И всё вроде хорошо, и ладушки. Но вот проходит 10 лет со дня выпуска программы. Программа загружает из базы данных Людей их Дни Рождения. 10 лет назад в базу данных была добавлена Старушка, которой было 99 лет. И вот сегодня, программа падает с исключением, так как не бывает таки Дней Рождения, которые датируются ранее 100 годов. Что делать? Завести второй конструктор? Один для актуальных ДР (от сегодняшнего дня), другой для загружаемых? Или проще. Пусть будет один конструктор, в который будет запихиваться ДР и ещё одна дата отсчёта? Класс. И так с каждым доменным типом. Видимое удобство влечёт кучу неочевидных побочных эффектов.
Но и это ещё не все.
Вместо того, чтобы пользоваться атрибутами и прочими «расширяющими дыру» инструментами, будем творить домен на каждый чих. Лично я в таком аду сразу откажусь что-то делать. Надо добавить День Рождения? Таааа-аа-ак, как же он там называется? BirthDay? BirthDate? DateOfBirth?..
Всё должно быть в меру с умом. Нельзя вот так взять и сказать «Атрибуты — зло». Очевидно, что автор этих слов бездумный фанатик, не написавший в своей жизни ни строчки кода для продакшена. Одни только разговоры разговаривать. И сливать этот поток бреда на чьи-нибудь уши на каких-нибудь конфах.
«Атрибут [Required] примитивный и ядовитый хак. Это главная причина того, почему я никогда не буду использовать Entity Framework.» (с) автор
Атрибут [Required] — явное указание, что значение должно быть определено. Для значимых типов, таких как int, атрибут не требуется, так как существует определённая разница между int и int?, которую можно распознать без всяких атрибутов. Для String, который может принимать значение null без подобного атрибута не обойтись. Автор похоже в жизни не писал программного кода, иначе бы не плёл такой бред.
Автор даже не удосужился копнуть глубже. Свойству типа int не нужен атрибут [Required], так как EF поймёт всё правильно и отразит его в поле NOT NULL. Атрибут [Required] требуется, например, для типа String, где нельзя по-другому. Если автор решил, что все String надо оборачивать в идеологически верные доменные структуры, то пошёл он куда по-дальше. Может и красиво, но кашу не сваришь. Надо соблюдать баланс, идеальными бывают только сферические кони в вакууме.
Работать в пользовательском часовом поясе (а не UTC), уметь принимать и отдавать дату/время в UTC+Z.
Ну и работать как с чистой датой (пикер даты), так и со временем (пикер даты + время).
Проект
— Система 1
… — Модуль 11
… — Модуль 12
…… — Решение задачи XXX
…… — Интерфейс
……… — Реализация
……… — Логгирования
…… — Решение задачи YYY
……… — Подготовка данных для исследования
……… — Разработка структуры
и т.д. и т.п.
Если в одном трекере будет это всё валяться сплошняком, будет ад. Теги, связи — конечно хороши, но они не дают надёжную чёткую структуру что из чего состоит, потому что иерархия задач подразумевает: какая работа частью какой работы является. Она может зависеть от других задач, быть с ними связана, укладываться на диаграму, быть триггером для старта/завершении цикла, но она всегда является частью чего-то большего.
В любом случае иерархия есть, как минимум в разрезе Проект — Задачи. По сути проект это и есть одна большая задача. Хотя мне не нравится, когда некоторые разработчики выбирают подход «Всё есть задача». Тоже фейл но в обратном направлении.
Хороший пример с файловой системой. Папки и подпапки — это чрезвычайно удобно. Доказано временем. Хотя это не единственный способ для организации данных.
Просто дайте людям возможность создавать подзадачи. Если они хотят плоский список, пусть не создают подзадач. Какая проблема? Я и правда видел на своём веку людей, которые все свои файлы хранили в одной единственной папке: музыку, документы, картинки и т.д. Но все люди разные, и всё сильно зависит в команде от того, как работает менеджер. Вы его работать по-своему не заставите. Просто дайте инструмент. И сделайте его простым, понятным и очевидным.
Не надо за людей решать: вам не нужны подзадачи (потому что мы не знаем как сделать работу с ними удобной).
С другой стороны, простейший ведроид за три копья легко справится с задачей. Не надо ничего выдумывать, считайте что у большинства людей аппарат всегда есть под рукой, осталось поставить туда соответствующий софт. Переписывать карандашиком на бумажку какие-то неудобочитаемые коды в наше время — натуральное издевательство. И бумагу портитить почём зря. Всё правильно там написано. Оправдания админской лени разобраться и найти приемлемое недорогое решение — не принимаются!
Теория автора разбивается о банальный пример. День Рождения. Давайте создадим такой тип, ибо вполне уместно. День Рождения не должен быть ранее, допустим 100 лет от текущей даты и позже текущей даты. И День Рождения не может быть пустым, ибо не бывает таких людей, у которых нет Дня Рождения. Посему должен быть обязательный конструктор в который надо передать Дату, и если что-то с ней не так, выплюнуть исключение. И всё вроде хорошо, и ладушки. Но вот проходит 10 лет со дня выпуска программы. Программа загружает из базы данных Людей их Дни Рождения. 10 лет назад в базу данных была добавлена Старушка, которой было 99 лет. И вот сегодня, программа падает с исключением, так как не бывает таки Дней Рождения, которые датируются ранее 100 годов. Что делать? Завести второй конструктор? Один для актуальных ДР (от сегодняшнего дня), другой для загружаемых? Или проще. Пусть будет один конструктор, в который будет запихиваться ДР и ещё одна дата отсчёта? Класс. И так с каждым доменным типом. Видимое удобство влечёт кучу неочевидных побочных эффектов.
Но и это ещё не все.
Вместо того, чтобы пользоваться атрибутами и прочими «расширяющими дыру» инструментами, будем творить домен на каждый чих. Лично я в таком аду сразу откажусь что-то делать. Надо добавить День Рождения? Таааа-аа-ак, как же он там называется? BirthDay? BirthDate? DateOfBirth?..
Всё должно быть в меру с умом. Нельзя вот так взять и сказать «Атрибуты — зло». Очевидно, что автор этих слов бездумный фанатик, не написавший в своей жизни ни строчки кода для продакшена. Одни только разговоры разговаривать. И сливать этот поток бреда на чьи-нибудь уши на каких-нибудь конфах.
Атрибут [Required] — явное указание, что значение должно быть определено. Для значимых типов, таких как int, атрибут не требуется, так как существует определённая разница между int и int?, которую можно распознать без всяких атрибутов. Для String, который может принимать значение null без подобного атрибута не обойтись. Автор похоже в жизни не писал программного кода, иначе бы не плёл такой бред.
Ну и работать как с чистой датой (пикер даты), так и со временем (пикер даты + время).