Понравился хороший анализ внутренностей.
Но не нравится постанова вопроса: какая библиотека лучше. И вот почему: выбор «логера» зависит еще (а на мой взгляд в первую очередь) от того, что вы хотите достичь.
1. Я имею ввиду следующее: лог трассировки это одно — для дебага вполне может подойти те библиотеки о которых вы говорите. Но допустим для аудита (лога безопасности)-нет. Они не ответят быстро на вопрос, а кто имел доступ к определенному объекту (например, запись о клиенте созданная 10 лет назад и редактируемая время от времени), и кто его и почему изменял — для этого лучше, чтобы лог был не в виде «плоского файла» с кучей другого мусора, а в виде структутрированной и нормализированной БД — вряд ли указанные логгеры позволяют делать что-то подобное.
2. А еще событие в трассировочном файле (для программиста, например событие с уровнем Warning) может иметь совершенной другой смысл (и уровень) для администратора (от вообще ничего не значащего, до Error). Аналогично относительно самого сообщения. Для программиста нужно выводить стек ошибки, для администратора — вряд ли. Ему бы лучше описание проблемы и решения.
3. Еще логгеры навязывают свою классификацию уровня сообщений. Мне часто не хватает уровня Success и Fail(типа Info, но с другим «оттенком» — так по логу проще искать удачные и не удачные операции), не хватает дополнительной категоризации — кроме уровня и категории, например название операции; или уникальный номер операции (номер потока не подходит) — приходится придумывать
А вообще это я к чему… На мой взгляд правильнее:
* для себя и команды выработать правила как, что и когда логгировать (я имею ввиду трассировку) и как обрабатывать эти логи
* отталкиваться от требований (какие еще логи нужно вести — для админов, для безопасников...) в каждом конкретном проекте — от этого может поменяться и подход вообще.
* выработать для себя интерфейс с набором удобных методов логгирования
* а потом под этой интерфейс реализовывать что угодно и иметь возможность в любой момент поменять библиотеку на любую другую.
Проблема в том, что люди, которые предлагают ввести новые проверки, почти никогда не задумываются об их стоимости.
Каждая проверка имеет свою стоимость.
В статье мне очень понравились эти два предложения. Простая, очевидная и замечательная мысль.
Спасибо за комментарий.
С разработкой коробочных решений я не сталкивался. А решения, в разработке которых брал участие, — полностью, вместе с исходными кодами, передавалось заказчику. Так что, проблемы раскрытия секретов просто не стоял. Кроме того, предоставлялась последующая гарантийная поддержка. И в этом случае полноценное протоколирование и трассировка просто необходимы как самому заказчику, так и команде сопровождения.
В любом случае очень интересная мысль, — наверное, идея для отдельной статьи :)
В статья написана хорошо, но в данном случае, на мой взгляд, есть некоторые неточности:
1. У заказчика ТЗ требовать безполезно. Максимум, что может предоставить заказчки — это требования, которые нужно переработать и соглдасовать
2. В статье ТЗ оторвано от контекста. Потому как, например по ГОСТ, есть требования, ТЗ, рабочий проект..., которые связаны между собой. И ТЗ — это далеко не первый продукт, с которого начинается разработка.
3. Когда пишется ТЗ нужно думать не как его написать или как создать продукт, а как проверить, что создано то, что требовал заказчик. Люблю приводить ссылку на презентацию Сергея Мартыненко «Написание тестов, как вид тестирования требований» vimeo.com/13803733.
Тогда, в самом начале, при написании требований или ТЗ все (заказчик и исполнитель) зают что в результате получится и какого качества.
Добрый день.
Для начала поблагодарю автора — очень интересный рассказ. Поднял настроение.
К сожалению не все комментарии понравились.
Хочется вставить и свои 5 копеек, т.к. имею отношение и к походам и оценке проектов.
1. Оценку сроков прохождения этого пути сделали люди, которые никогда до этого не ходили (а не то, что не ходили этим маршрутом).
2. Когда планируется поход — скорость оценивается в расчете на 3,5 — 4 км/час ходьбы (и это по дорогам или совсем ровной местности) или 15-25 (ну в крайнем случае 30) км в день, расписываются план прохождение на каждый день, и на каждый день расписываются где будет ночевка и что будем есть. Каждые 3-4 дня дневка — отдых. Если итди напролом по лесу с горами — скрость может быть 5-10 км в сутки.
Предусматриваются аварийные маршруты (для схода или чтобы срезать).
Т.е. если очень грубо считать по этому примеру и этим картинкам, то это холмистая/скалистая месность, особо без дорог, то я бы брал из расчета 15 км/день. Тогда первоначальные 400миль (640 км) проходятся за 43 дня + к этому 11 дней отдыха = 54 дня. Это совсем грубо. Плюс небольшой запас (травмы/болезни, чегото нужно дозакупить и прочее). Кроме того, по карте — рядом лежит дорога — это и есть аварийный маршрут. Например если предположить что ребята по времени не вкладываются, то можно сойти с маршрута и быстро поймать попутку и приехать к друзьям (цель то будет достигнута, но с другими затратами и «некторыми недоработками»).
3. Если попытаться бысто (практически без сна, это тоже в жизни было) 100-120 км за 40 часов, практически налегке, Но после такого марафона дней 5 отходить нужно. Тогда можно попытаться вложиться
4. Ответ на комментарий: "… Пошли в поход — идите себе спокойно, радуйтесь природе..." Опять же для данного примера — а если отпуск заканчивается или ты еды взял в тайгу на 10 дней и транспорт бывает раз в неделю? Куда денешься?
5. Опять же коментарий к придыдущему посту — представь себя на месте заказчика. Например ты хочешь отремонтировать себе квартиру. Ты думаешь в нее вселиться за 2 месяца, нанимаешь рабочих… И тут они тебя начинают разводить на итерации, гибкий подход, вытягивание денег из тебя за свои просчеты и прочее. Они тебе оценивают работу в 10 дней и $500, а потом говорят что это будет 60 дней и $10000. Или говорят ты плати, а мы будем делать. Когда и за сколько сделаем — это как получиться.
Тебе это понравится?
В этом случае ты бы посмотрел на все с другой стороны. Тебе от рабочих нужно точно получить что они справяться за определенное время и определенные деньни ± 20%. Не так ли?
К статье сделал некоторые измения. Похоже скрывались пункты статьи, в которых были вложенные списки. Неправильно отображалась таблица — не показывались работы. И по тексту также не все кусочки, включающие вложенные списки также скрывались.
Относительно коментария: «Соотношение сбора требований к программированию заложено 1 к 25. Это очень подозрительно много»
Это не совсем так. Скорее всего вы не увидели, т.к. таблица отображалась не правильно.
60 часов — это только на встречи, но есть и написание документации, которое сведено в один пункт внизу таблицы. Допустим на первом этапе сбор требований (и другие бумажные работы ) — пятая часть работ по созданию документации — а это (1080 + 320)/5 = 280 часов. Т.е. на этапе анализа и сбора требований будет потрачено 340 часов.
И понятно будут и другие работы — написание ТЗ и архитектуры решения.
Прошу прощения за то, что не вычитал статью после публикации.
Добрый день (доброй ночи).
Ребята, большое спасибо за то, что дочитали статью (эти многа букв и совсем мало картинок) до конца и за комментарии, которые оставили. Я специально не отвечал на каждый конкрентый комментарий, для того, чтобы ответить на все замечаения и предложения сразу.
Как по мне, данное направление (роль архитектора решения) до сих пор освещается очень плохо (по сравнению с разработкой, тестированием, аналитикой, руководством проектами) и поэтому хотелось написать статью, которая хотябы побудит поделиться опытом тех у кого он есть, и поднять эту тему на обсуждение.
Отвечая на вопросы еще раз замечу, что:
Во-первых, рассматривает проекты с фиксированной стоимостью и ни о какой итерационной методологии (типа скрам) и постоянного раскручивания заказчика на деньги тут речи не идет – вот это и особеность наших заказчиков. Идея заключается в другом: при оценке проекта сразу заложить и донести до заказчика число итераций и возможные модификации. Это сразу обезопасит вас и повысит ответственность заказчика.
Во-вторых, по сути – это внутренние оценки, и совсем не все обязательно их в таком виде показывать заказчику. Действительно, за половину работ, которые я узакал, заказчик платить не хочет и не собирается, но вы, внутри команды, компании должны понимать в какие трудозатраты выльется данный проект, т.к. эти работы все равно делать нужно. А заказчику можно показывается другой план, написанный на бизнес-языке, который он понимает и воспринимает.
В третьих, эта статья не является:
• Оценкой сроков проекта
• Оценкой стоимости проекта
• Руководством для продавцов проектов
Кроме того, часть замечаний к статье относится к руководству проектом, а не к его оценке. А это совсем другая тема.
В четвертых, на аналитику не обязательно тратить недели, для того, чтобы сделать оценки. Достаточно провести несколько встреч с бизнес-пользователями, с отделом безопасности и ИТ, для того, чтобы понять объем работ и решить интересно это заказчику и вам или нет. Зачем подписываться на убыточный проект? И получать убытки и гробить команду?
Но не нравится постанова вопроса: какая библиотека лучше. И вот почему: выбор «логера» зависит еще (а на мой взгляд в первую очередь) от того, что вы хотите достичь.
1. Я имею ввиду следующее: лог трассировки это одно — для дебага вполне может подойти те библиотеки о которых вы говорите. Но допустим для аудита (лога безопасности)-нет. Они не ответят быстро на вопрос, а кто имел доступ к определенному объекту (например, запись о клиенте созданная 10 лет назад и редактируемая время от времени), и кто его и почему изменял — для этого лучше, чтобы лог был не в виде «плоского файла» с кучей другого мусора, а в виде структутрированной и нормализированной БД — вряд ли указанные логгеры позволяют делать что-то подобное.
2. А еще событие в трассировочном файле (для программиста, например событие с уровнем Warning) может иметь совершенной другой смысл (и уровень) для администратора (от вообще ничего не значащего, до Error). Аналогично относительно самого сообщения. Для программиста нужно выводить стек ошибки, для администратора — вряд ли. Ему бы лучше описание проблемы и решения.
3. Еще логгеры навязывают свою классификацию уровня сообщений. Мне часто не хватает уровня Success и Fail(типа Info, но с другим «оттенком» — так по логу проще искать удачные и не удачные операции), не хватает дополнительной категоризации — кроме уровня и категории, например название операции; или уникальный номер операции (номер потока не подходит) — приходится придумывать
А вообще это я к чему… На мой взгляд правильнее:
* для себя и команды выработать правила как, что и когда логгировать (я имею ввиду трассировку) и как обрабатывать эти логи
* отталкиваться от требований (какие еще логи нужно вести — для админов, для безопасников...) в каждом конкретном проекте — от этого может поменяться и подход вообще.
* выработать для себя интерфейс с набором удобных методов логгирования
* а потом под этой интерфейс реализовывать что угодно и иметь возможность в любой момент поменять библиотеку на любую другую.
В статье мне очень понравились эти два предложения. Простая, очевидная и замечательная мысль.
С разработкой коробочных решений я не сталкивался. А решения, в разработке которых брал участие, — полностью, вместе с исходными кодами, передавалось заказчику. Так что, проблемы раскрытия секретов просто не стоял. Кроме того, предоставлялась последующая гарантийная поддержка. И в этом случае полноценное протоколирование и трассировка просто необходимы как самому заказчику, так и команде сопровождения.
В любом случае очень интересная мысль, — наверное, идея для отдельной статьи :)
1. У заказчика ТЗ требовать безполезно. Максимум, что может предоставить заказчки — это требования, которые нужно переработать и соглдасовать
2. В статье ТЗ оторвано от контекста. Потому как, например по ГОСТ, есть требования, ТЗ, рабочий проект..., которые связаны между собой. И ТЗ — это далеко не первый продукт, с которого начинается разработка.
3. Когда пишется ТЗ нужно думать не как его написать или как создать продукт, а как проверить, что создано то, что требовал заказчик. Люблю приводить ссылку на презентацию Сергея Мартыненко «Написание тестов, как вид тестирования требований» vimeo.com/13803733.
Тогда, в самом начале, при написании требований или ТЗ все (заказчик и исполнитель) зают что в результате получится и какого качества.
Для начала поблагодарю автора — очень интересный рассказ. Поднял настроение.
К сожалению не все комментарии понравились.
Хочется вставить и свои 5 копеек, т.к. имею отношение и к походам и оценке проектов.
1. Оценку сроков прохождения этого пути сделали люди, которые никогда до этого не ходили (а не то, что не ходили этим маршрутом).
2. Когда планируется поход — скорость оценивается в расчете на 3,5 — 4 км/час ходьбы (и это по дорогам или совсем ровной местности) или 15-25 (ну в крайнем случае 30) км в день, расписываются план прохождение на каждый день, и на каждый день расписываются где будет ночевка и что будем есть. Каждые 3-4 дня дневка — отдых. Если итди напролом по лесу с горами — скрость может быть 5-10 км в сутки.
Предусматриваются аварийные маршруты (для схода или чтобы срезать).
Т.е. если очень грубо считать по этому примеру и этим картинкам, то это холмистая/скалистая месность, особо без дорог, то я бы брал из расчета 15 км/день. Тогда первоначальные 400миль (640 км) проходятся за 43 дня + к этому 11 дней отдыха = 54 дня. Это совсем грубо. Плюс небольшой запас (травмы/болезни, чегото нужно дозакупить и прочее). Кроме того, по карте — рядом лежит дорога — это и есть аварийный маршрут. Например если предположить что ребята по времени не вкладываются, то можно сойти с маршрута и быстро поймать попутку и приехать к друзьям (цель то будет достигнута, но с другими затратами и «некторыми недоработками»).
3. Если попытаться бысто (практически без сна, это тоже в жизни было) 100-120 км за 40 часов, практически налегке, Но после такого марафона дней 5 отходить нужно. Тогда можно попытаться вложиться
4. Ответ на комментарий: "… Пошли в поход — идите себе спокойно, радуйтесь природе..." Опять же для данного примера — а если отпуск заканчивается или ты еды взял в тайгу на 10 дней и транспорт бывает раз в неделю? Куда денешься?
5. Опять же коментарий к придыдущему посту — представь себя на месте заказчика. Например ты хочешь отремонтировать себе квартиру. Ты думаешь в нее вселиться за 2 месяца, нанимаешь рабочих… И тут они тебя начинают разводить на итерации, гибкий подход, вытягивание денег из тебя за свои просчеты и прочее. Они тебе оценивают работу в 10 дней и $500, а потом говорят что это будет 60 дней и $10000. Или говорят ты плати, а мы будем делать. Когда и за сколько сделаем — это как получиться.
Тебе это понравится?
В этом случае ты бы посмотрел на все с другой стороны. Тебе от рабочих нужно точно получить что они справяться за определенное время и определенные деньни ± 20%. Не так ли?
Относительно коментария: «Соотношение сбора требований к программированию заложено 1 к 25. Это очень подозрительно много»
Это не совсем так. Скорее всего вы не увидели, т.к. таблица отображалась не правильно.
60 часов — это только на встречи, но есть и написание документации, которое сведено в один пункт внизу таблицы. Допустим на первом этапе сбор требований (и другие бумажные работы ) — пятая часть работ по созданию документации — а это (1080 + 320)/5 = 280 часов. Т.е. на этапе анализа и сбора требований будет потрачено 340 часов.
И понятно будут и другие работы — написание ТЗ и архитектуры решения.
Прошу прощения за то, что не вычитал статью после публикации.
Ребята, большое спасибо за то, что дочитали статью (эти многа букв и совсем мало картинок) до конца и за комментарии, которые оставили. Я специально не отвечал на каждый конкрентый комментарий, для того, чтобы ответить на все замечаения и предложения сразу.
Как по мне, данное направление (роль архитектора решения) до сих пор освещается очень плохо (по сравнению с разработкой, тестированием, аналитикой, руководством проектами) и поэтому хотелось написать статью, которая хотябы побудит поделиться опытом тех у кого он есть, и поднять эту тему на обсуждение.
Отвечая на вопросы еще раз замечу, что:
Во-первых, рассматривает проекты с фиксированной стоимостью и ни о какой итерационной методологии (типа скрам) и постоянного раскручивания заказчика на деньги тут речи не идет – вот это и особеность наших заказчиков. Идея заключается в другом: при оценке проекта сразу заложить и донести до заказчика число итераций и возможные модификации. Это сразу обезопасит вас и повысит ответственность заказчика.
Во-вторых, по сути – это внутренние оценки, и совсем не все обязательно их в таком виде показывать заказчику. Действительно, за половину работ, которые я узакал, заказчик платить не хочет и не собирается, но вы, внутри команды, компании должны понимать в какие трудозатраты выльется данный проект, т.к. эти работы все равно делать нужно. А заказчику можно показывается другой план, написанный на бизнес-языке, который он понимает и воспринимает.
В третьих, эта статья не является:
• Оценкой сроков проекта
• Оценкой стоимости проекта
• Руководством для продавцов проектов
Кроме того, часть замечаний к статье относится к руководству проектом, а не к его оценке. А это совсем другая тема.
В четвертых, на аналитику не обязательно тратить недели, для того, чтобы сделать оценки. Достаточно провести несколько встреч с бизнес-пользователями, с отделом безопасности и ИТ, для того, чтобы понять объем работ и решить интересно это заказчику и вам или нет. Зачем подписываться на убыточный проект? И получать убытки и гробить команду?