Balu
Администратор
euseller, Прочитал Ваше ТЗ.
Видно что время потратили, спасибо, но в таком виде работа передаваться программистам не может. Невозможно реализовать нормальную систему по этому описанию, у разработчиков возникнет около 50-70 (на глаз) встречных вопросов по ее работе и нюансам.
И вот почему:
ТЗ должно либо только описывать что нам нужно и как (внешне) это должно работать либо к этому добавляется детальнейшее описание внутренней части (эти данные пишем в такую-то переменную такой-то таблицы такого-то типа). Либо либо. Разбавлять первый вариант парой технических указаний нельзя, т.к. вполне может быть что это = сподвигнуть программистов изобретать велосипед. Может там все решается в два шага не черед div, но раз написан div - будут мучаться, делая через него, поскольку был такой заказ. Требования к ОС и железу - это тоже ко второму варианту, в первом случае какая система нужна под данную задачу сообщат разработчики.
Более того, даже если удастся ее реализовать в описанном виде, она неприемлема для этого форума.
Причины:
1. Непонятно почему выбрано название "благодарность" вместо "репутации", к которой здесь все привыкли.
2. Данная система кардинально по механизму отличается от старой. Нет общей суммы балов у конкретного участника, только сколько выдал и сколько отдал благодарностей. Можно только получать и раздавать благодарности.
3. В благодарностях НЕТ комментариев. Значит все тёплые слова, которые сказали участники друг другу за прошедшие несколько лет идут под нож. Многие реально обидятся на администрацию за такое. И заслуженно, так нельзя поступать с людьми, это неуважение. Отсутствует "минус" и его аналог, а значит все старые минусы тоже пропали. Т.к. этот механизм не предусматривает наличия суммарных баллов у участника, то они тоже идут в мусорку, зря копили получается.
4. Не указано: как данная система должна взаимодействовать со старыми данными по репе. Впрочем, учитывая п.3. портировать вообще нечего, всё накопленное теряется, максимум что можно перенести это количество выданных и полученных плюсов.
5. Не указан механизм расчета репы. А это самое ядро, которое должно быть прописано детальнейшим образом с формулами.
В разделе Механизм, Принцип работы явно не прописано: вычитается ли балл, когда отдаешь благодарность или просто плюсуется к своим выданным. Непонятно почему статистика выдачи репутации не является частью системы. Является и являлась в старой. В старой были дробные баллы, возникнет вопрос как быть тут. Юзеры будут спрашивать почему нельзя поставить 0.5 баллов, вместо 1.
6. В пункте про защиту от накруток написано "необходимо серьезней продумать защиту от накруток" - это не пункт ТЗ, а заметка на листочке, которую себе делает разработчик этого ТЗ при его составлении. В ТЗ такого быть не должно. Это то же самое что писать дизайнеру "нарисуй что-нибудь красиво".
Судя по описанию, благодарности можно раздавать сколько угодно, т.к. блок стоит только на выдачу одному и тому же пользователю. Т.е. парочка умников могут за час-другой нескольким тысячам юзеров накидать плюсов, набрав себе т.о. наикрутейший рейтинг (ratio) и дискредитировав т.о. ценность 1 благодарности. Ведь в ТЗ с помощью ратио защищаетесь от "жадных" юзеров, опираясь на минимальное значение ратио, но не рассматривается вариант слишком "щедрого" юзера, когда ратио будет зашкаливать.
7. В прежнем варианте репа увеличивалась от постов, срока пребывания на форуме. И если + ставил более авторитетный участник, то получатель получал большее количество баллов по определенному коэффициенту. Это вполне себе альтернативный способ набора репы, когда писать громадные посты нет возможности, но есть, например, желание отвечать на конкретные вопросы конкретных людей. В системе с благодарностями, этого баланса нет. Она скорее заточена на написание громадных постов-обзоров, когда за один пост можно получить много +. Когда отвечаешь на конкретный вопрос человека, скорее всего + будет один или два-три.
Резюмируя: описанная система имеет меньший функционал, чем прежняя. Весь накопленный материал из старой системы практически полностью уничтожается.
Мог бы написать еще, но думаю этого достаточно. Всё-таки анализ чужого ТЗ и систематизация выводов требует много времени.
p.s. Тем не менее, как единственному, ответившему на вызов с ТЗ - зачет! :good:
Видно что время потратили, спасибо, но в таком виде работа передаваться программистам не может. Невозможно реализовать нормальную систему по этому описанию, у разработчиков возникнет около 50-70 (на глаз) встречных вопросов по ее работе и нюансам.
И вот почему:
ТЗ должно либо только описывать что нам нужно и как (внешне) это должно работать либо к этому добавляется детальнейшее описание внутренней части (эти данные пишем в такую-то переменную такой-то таблицы такого-то типа). Либо либо. Разбавлять первый вариант парой технических указаний нельзя, т.к. вполне может быть что это = сподвигнуть программистов изобретать велосипед. Может там все решается в два шага не черед div, но раз написан div - будут мучаться, делая через него, поскольку был такой заказ. Требования к ОС и железу - это тоже ко второму варианту, в первом случае какая система нужна под данную задачу сообщат разработчики.
Более того, даже если удастся ее реализовать в описанном виде, она неприемлема для этого форума.
Причины:
1. Непонятно почему выбрано название "благодарность" вместо "репутации", к которой здесь все привыкли.
2. Данная система кардинально по механизму отличается от старой. Нет общей суммы балов у конкретного участника, только сколько выдал и сколько отдал благодарностей. Можно только получать и раздавать благодарности.
3. В благодарностях НЕТ комментариев. Значит все тёплые слова, которые сказали участники друг другу за прошедшие несколько лет идут под нож. Многие реально обидятся на администрацию за такое. И заслуженно, так нельзя поступать с людьми, это неуважение. Отсутствует "минус" и его аналог, а значит все старые минусы тоже пропали. Т.к. этот механизм не предусматривает наличия суммарных баллов у участника, то они тоже идут в мусорку, зря копили получается.
4. Не указано: как данная система должна взаимодействовать со старыми данными по репе. Впрочем, учитывая п.3. портировать вообще нечего, всё накопленное теряется, максимум что можно перенести это количество выданных и полученных плюсов.
5. Не указан механизм расчета репы. А это самое ядро, которое должно быть прописано детальнейшим образом с формулами.
В разделе Механизм, Принцип работы явно не прописано: вычитается ли балл, когда отдаешь благодарность или просто плюсуется к своим выданным. Непонятно почему статистика выдачи репутации не является частью системы. Является и являлась в старой. В старой были дробные баллы, возникнет вопрос как быть тут. Юзеры будут спрашивать почему нельзя поставить 0.5 баллов, вместо 1.
6. В пункте про защиту от накруток написано "необходимо серьезней продумать защиту от накруток" - это не пункт ТЗ, а заметка на листочке, которую себе делает разработчик этого ТЗ при его составлении. В ТЗ такого быть не должно. Это то же самое что писать дизайнеру "нарисуй что-нибудь красиво".
Судя по описанию, благодарности можно раздавать сколько угодно, т.к. блок стоит только на выдачу одному и тому же пользователю. Т.е. парочка умников могут за час-другой нескольким тысячам юзеров накидать плюсов, набрав себе т.о. наикрутейший рейтинг (ratio) и дискредитировав т.о. ценность 1 благодарности. Ведь в ТЗ с помощью ратио защищаетесь от "жадных" юзеров, опираясь на минимальное значение ратио, но не рассматривается вариант слишком "щедрого" юзера, когда ратио будет зашкаливать.
7. В прежнем варианте репа увеличивалась от постов, срока пребывания на форуме. И если + ставил более авторитетный участник, то получатель получал большее количество баллов по определенному коэффициенту. Это вполне себе альтернативный способ набора репы, когда писать громадные посты нет возможности, но есть, например, желание отвечать на конкретные вопросы конкретных людей. В системе с благодарностями, этого баланса нет. Она скорее заточена на написание громадных постов-обзоров, когда за один пост можно получить много +. Когда отвечаешь на конкретный вопрос человека, скорее всего + будет один или два-три.
Резюмируя: описанная система имеет меньший функционал, чем прежняя. Весь накопленный материал из старой системы практически полностью уничтожается.
Мог бы написать еще, но думаю этого достаточно. Всё-таки анализ чужого ТЗ и систематизация выводов требует много времени.
p.s. Тем не менее, как единственному, ответившему на вызов с ТЗ - зачет! :good:
P)) ведь. Ну это конечно не полноценное ТЗ, естественно, но и мы с вами не КИС разрабатываем. С такого ТЗ мне данный модуль фрилансер бы написал, ну с вопросами конечно по ходу дела.
