LINUX.ORG.RU

История изменений

Исправление LINUX-ORG-RU, (текущая версия) :

Ниже бред, не читай


А большой это сколько? У меня в игре про ЛОР за 5 дней уже 1200 строк лютого говнокода с 62мя записями FIXME и 12ти XXX , одно рыло и три листа бумажки.

Это я к чему, нокатываешь в vim Plugin 'gilsondev/searchtasks.vim' и дрыгаешь в релизной ветке исходников SearchTasks * Завели баг во вне, примерно прикидывешь где он проявляется, дуешь в код и вхерачиваешь коммент FIXME: БЛАБЛАБЛА когда весь этот мусор в коде будет уже бить по глазам, ты будешь смотреть на релизное окно и плакать выбирая из списка FIXME не то что манагер прописал переслав картинку из своего Jira, а то что реально надо исправлять тутава и сейчас. Плакать, стучать ножками, рвать волосы и исправлять. Ибо завтра Юля из соседней комнаты понапихает в код ещё десять FIXME

Коноечно всё это на уровне шутки, но всё же =)

(типа, чтобы решить проблему тикета А, надо сначала решить проблему в тикете Б).

Тогда надо завести шальную машинистку которая будет упарываться сортируя тикеты вручную составляя карты зависимостей, так как зависимость А от Б может быть техническая и выяснена только в процессе. Или писать тулзу которая по неким хз тегам или типа того будет строить дерево зависомостей отдного от другого и динамически его перестраивать. Тогда надо пилить эту тузлу.

Нужен ПМ, можно apt переделать под тикеты и будет. apt push проблемаСсегфолтом:id256 И разработчику устнавиливается «пакет» он такой apt show last и там список зависимостей тикетов. А ещё нужны маинтейнеры тикетов. В конце будет целая операционная система специального назначения для управления проектами. Целые здания, несколько отделов по разработке, десятки команд, подразделения и деловые связи. Всё для того чтобы не меняющий своего места дислокации Васька на стуле, получил в веб интерфейсе попап «Нада добавить вотета, но перед эти вот это» на что Васька скажет «А то я лять не знаю что для возможности делать SQL запросы надо сначала сам SQL внедрить».

Просто я гляжу и системы управления проектами такие жирные и здоровые что им самим нужна система управления, и это всё надо заполнять, проверять, туда сюда перетаскивать, сортировать, выстривть зависимости, закрывать, открывать, поднимать из архивов. Где-то это необходимо, а где-то порождает бешеное мельчешение, ведь пока там в браузрере некто мышкою правильно всё не перепихает да теги не пропишет, в нужное место не сбросит никто ничего делать не будет.

Разупоролся, простите пожалуйстаАААААААААААААААААААААААААААААААААА

Просто список задач и проблем вручную отсортированных по важности и всё. Идея с зависимостями хорошая, но кто это и как будет отслеживать? Разве что только как выше, засовывать тикет (не целиком конечно) прям в код, тогда они будут удаляться естественным образом. А иначе вручную выискивать уже неактуальные которые были решены в процессе решения других на автомате. Можно неявно добавлять тикет на определённый участок кода, через нашлёпку/оверлей, когда тикет указывает на определённую часть кода, ссылается на него, при этом в теле кода ничего от тикета нету. При изменении учатка кода отвецтвенного, того на который ссылаетя тикет, тикет становится активным или либо требует ревью/проверки либо закрывается.

Исправление LINUX-ORG-RU, :

Ниже бред, не читай


А большой это сколько? У меня в игре про ЛОР за 5 дней уже 1200 строк лютого говнокода с 62мя записями FIXME и 12ти XXX , одно рыло и три листа бумажки.

Это я к чему, нокатываешь в vim Plugin 'gilsondev/searchtasks.vim' и дрыгаешь в релизной ветке исходников SearchTasks * Завели баг во вне, примерно прикидывешь где он проявляется, дуешь в код и вхерачиваешь коммент FIXME: БЛАБЛАБЛА когда весь этот мусор в коде будет уже бить по глазам, ты будешь смотреть на релизное окно и плакать выбирая из списка FIXME не то что манагер прописал переслав картинку из своего Jira, а то что реально надо исправлять тутава и сейчас. Плакать, стучать ножками, рвать волосы и исправлять. Ибо завтра Юля из соседней комнаты понапихает в код ещё десять FIXME

Коноечно всё это на уровне шутки, но всё же =)

(типа, чтобы решить проблему тикета А, надо сначала решить проблему в тикете Б).

Тогда надо завести шальную машинистку которая будет упарываться сортируя тикеты вручную составляя карты зависимостей, так как зависимость А от Б может быть техническая и выяснена только в процессе. Или писать тулзу которая по неким хз тегам или типа того будет строить дерево зависомостей отдного от другого и динамически его перестраивать. Тогда надо пилить эту тузлу.

Нужен ПМ, можно apt переделать под тикеты и будет. apt push проблемаСсегфолтом:id256 И разработчику устнавиливается «пакет» он такой apt show last и там список зависимостей тикетов. А ещё нужны маинтейнеры тикетов. В конце будет целая операционная система специального назначения для управления проектами. Целые здания, несколько отделов по разработке, десятки команд, подразделения и деловые связи. Всё для того чтобы не меняющий своего места дислокации Васька на стуле, получил в веб интерфейсе попап «Нада добавить вотета, но перед эти вот это» на что Васька скажет «А то я лять не знаю что для возможности делать SQL запросы надо сначала сам SQL внедрить».

Просто я гляжу и системы управления проектами такие жирные и здоровые что им самим нужна система управления, и это всё надо заполнять, проверять, туда сюда перетаскивать, сортировать, выстривть зависимости, закрывать, открывать, поднимать из архивов. Где-то это необходимо, а где-то порождает бешеное мельчешение, ведь пока там в браузрере некто мышкою правильно всё не перепихает да теги не пропишет, в нужное место не сбросит никто ничего делать не будет.

Разупоролся, простите пожалуйстаАААААААААААААААААААААААААААААААААА

Просто список задач и проблем вручную отсортированных по важности и всё. Идея с зависимостями хорошая, но кто это и как будет отслеживать? Разве что только как выше, засовывать тикет (не целиком конечно) прям в код, тогда они будут удаляться естественным образом. А иначе вручную выискивать уже неактуальные которые были решены в процессе решения других на автомате.

Исправление LINUX-ORG-RU, :

А большой это сколько? У меня в игре про ЛОР за 5 дней уже 1200 строк лютого говнокода с 62мя записями FIXME и 12ти XXX , одно рыло и три листа бумажки.

Это я к чему, нокатываешь в vim Plugin 'gilsondev/searchtasks.vim' и дрыгаешь в релизной ветке исходников SearchTasks * Завели баг во вне, примерно прикидывешь где он проявляется, дуешь в код и вхерачиваешь коммент FIXME: БЛАБЛАБЛА когда весь этот мусор в коде будет уже бить по глазам, ты будешь смотреть на релизное окно и плакать выбирая из списка FIXME не то что манагер прописал переслав картинку из своего Jira, а то что реально надо исправлять тутава и сейчас. Плакать, стучать ножками, рвать волосы и исправлять. Ибо завтра Юля из соседней комнаты понапихает в код ещё десять FIXME

Коноечно всё это на уровне шутки, но всё же =)

(типа, чтобы решить проблему тикета А, надо сначала решить проблему в тикете Б).

Тогда надо завести шальную машинистку которая будет упарываться сортируя тикеты вручную составляя карты зависимостей, так как зависимость А от Б может быть техническая и выяснена только в процессе. Или писать тулзу которая по неким хз тегам или типа того будет строить дерево зависомостей отдного от другого и динамически его перестраивать. Тогда надо пилить эту тузлу.

Нужен ПМ, можно apt переделать под тикеты и будет. apt push проблемаСсегфолтом:id256 И разработчику устнавиливается «пакет» он такой apt show last и там список зависимостей тикетов. А ещё нужны маинтейнеры тикетов. В конце будет целая операционная система специального назначения для управления проектами. Целые здания, несколько отделов по разработке, десятки команд, подразделения и деловые связи. Всё для того чтобы не меняющий своего места дислокации Васька на стуле, получил в веб интерфейсе попап «Нада добавить вотета, но перед эти вот это» на что Васька скажет «А то я лять не знаю что для возможности делать SQL запросы надо сначала сам SQL внедрить».

Просто я гляжу и системы управления проектами такие жирные и здоровые что им самим нужна система управления, и это всё надо заполнять, проверять, туда сюда перетаскивать, сортировать, выстривть зависимости, закрывать, открывать, поднимать из архивов. Где-то это необходимо, а где-то порождает бешеное мельчешение, ведь пока там в браузрере некто мышкою правильно всё не перепихает да теги не пропишет, в нужное место не сбросит никто ничего делать не будет.

Разупоролся, простите пожалуйстаАААААААААААААААААААААААААААААААААА

Просто список задач и проблем вручную отсортированных по важности и всё. Идея с зависимостями хорошая, но кто это и как будет отслеживать? Разве что только как выше, засовывать тикет (не целиком конечно) прям в код, тогда они будут удаляться естественным образом. А иначе вручную выискивать уже неактуальные которые были решены в процессе решения других на автомате.

Исходная версия LINUX-ORG-RU, :

А большой это сколько? У меня в игре про ЛОР за 5 дней уже 1200 строк лютого говнокода с 62мя записями FIXME и 12ти XXX , одно рыло и три листа бумажки.

Это я к чему, нокатываешь в vim Plugin 'gilsondev/searchtasks.vim' и дрыгаешь в релизной ветке исходников SearchTasks * Завели баг во вне, примерно прикидывешь где он проявляется, дуешь в код и вхерачиваешь коммент FIXME: БЛАБЛАБЛА когда весь этот мусор в коде будет уже бить по глазам, ты будешь смотреть на релизное окно и плакать выбирая из списка FIXME не то что манагер прописал переслав картинку из своего Jira, а то что реально надо исправлять тутава и сейчас. Плакать, стучать ножками, рвать волосы и исправлять. Ибо завтра Юля из соседней комнаты понапихает в код ещё десять FIXME

Коноечно всё это на уровне шутки, но всё же =)

(типа, чтобы решить проблему тикета А, надо сначала решить проблему в тикете Б).

Тогда надо завести шальную машинистку которая будет упарываться сортируя тикеты вручную составляя карты зависимостей, так как зависимость А от Б может быть техническая и выяснена только в процессе. Или писать тулзу которая по неким хз тегам или типа того будет строить дерево зависомостей отдного от другого и динамически его перестраивать. Тогда надо пилить эту тузлу.

Нужен ПМ, можно apt переделать под тикеты и будет. apt push проблемаСсегфолтом:id256 И разработчику устнавиливается «пакет» он такой apt show last и там список зависимостей тикетов. А ещё нужны маинтейнеры тикетов. В конце будет целая операционная система специального назначения для управления проектами. Целые здания, несколько отделов по разработке, десятки команд, подразделения и деловые связи. Всё для того чтобы не меняющий своего места дислокации Васька на стуле, получил в веб интерфейсе попап «Нада добавить вотета, но перед эти вот это» на что Васька скажет «А то я лять не знаю что для возможности делать SQL запросы надо сначала сам SQL внедрить».

Просто я гляжу и системы управления проектами такие жирные и здоровые что им самим нужна система управления, и это всё надо заполнять, проверять, туда сюда перетаскивать, сортировать, выстривть зависимости, закрывать, открывать, поднимать из архивов. Где-то это необходимо, а где-то порождает бешеное мельчешение, ведь пока там в браузрере некто мышкою правильно всё не перепихает да теги не пропишет, в ножное место не сбросит никто ничего делать не будет.

Разупоролся, простите пожалуйстаАААААААААААААААААААААААААААААААААА