Действительно, есть такая хорошая практика "не смешивать технический и бизнес код". В своём примере я намеренно его нарушил, добавив конвертацию типов. Чуть ниже опишу причину.
Также вы упомянули про MVC шаблон, где пользователь взаимодействует с Controller и меняет модель (через слои Service + Repository, которого в примере у меня нет), а потом изменяет View (для бекенда - это просто вернуть ответ UI приложению)
Дополнительно, мне очень понравилось про инфраструктурную роль. Ранее мне не доводилось слышать о таком подходе применимо к классам. Это интересно. Спасибо, что поделились.
Но в итоге я понял, что мне нужно пояснить, что я имел ввиду под "образовательная цель примера".
Возможно, многие опытные специалисты, которые оставляли критические комментарии, к примеру, уже подзабыли, когда делали свои первые шаги в программировании и какие именно программы им давали писать учителя.
Статья в первую очередь направлена на начинающих специалистов и тех, кто только делает первые шаги в программировании. И если накрутить все-все хорошие практики, то фокус у обучаемого может сместиться или более того, структура приложения может оказаться слишком сложной для их восприятия и осознания.
Поэтому у меня были следующие задачи перед написанием примера:
Стартовый код примера должен умещаться в 1 класс и желательно в 1 метод
Бизнес-логика кода должна быть максимально простой, сходу понятной и не требующего погружения в предметную область
Количество операций в стартовом коде приложения не должно быть больше 3-5.
Исходя из этих задач, я выбрал максимально простой сервис: математические операции. Ведь математика - это предметная область, знакомая любому человеку, который ходил в школу. Но бизнес-код оказался настолько простой, что пришлось добавить преобразование типов, также это позволило абстрагироваться от логики UI и просто написать, что UI пришлёт текст, как его ввёл пользователь.
Подведу итог:
Образовательный пример - это не production-ready код. Он может нарушать некоторые хорошие практики, принятые в профессии, в угоду образовательной цели.
Постараюсь вам показать разницу в категориях мышления.
Процедурное мышление чем-то напоминает подход code first при проектировании API. Где сначала создаётся реализация, а затем разработчик смотрит на то, что у него по итогу получилось и описывает интерфейсы. И если на этом этапе приходит понимание, что получилось не очень удобная реализация, то начинается рефакторинг.
И при процедурном мышлении получается примерно также. Сначала код пишется в лоб, где фокус на реализацию алгоритма задачи. А затем разработчик смотрит на то, что получилось и как этим в дальнейшем пользоваться, то как правило это заканчивается рефакторигном (вынесение в классы, группировки в отдельные методы и т.п.), потому что фокус у него был другой (на реализацию алгоритма)
Мышление объектами напоминает подход contract first при проектировании API. Где сначала проектируются интерфейсы, а затем под них уже выполняется реализации.
Разработчик в этом случае выступает в роли архитектора, только не на уровне информационной системы (ИС) в целом, а на уровне приложения. Для такого разработчика программа - миниатюрная ИС со своими микросервисами и отношениями между ними. И микросервисы в данном случае выступают классы. Такой разработчик оперирует сущностями и контрактами между ними. Алгоритм реализации - это уже следующий этап, когда будут сформированы сущности и связи между ними. А количество строчек кода вообще перестаёт играть какое-либо значение.
Резюме:
И получается достаточно интересная ситуация. С точки зрения процедурного мышления - ваши претензии вполне оправданы, т.к. группировка кода (именно так рассматриваются методы в этой категории мышления) из одной строчки не имеет смысла. А с точки зрения мышления объектами, важна архитектура приложения (сущности и их отношения), а количество строчек кода вообще не имеет никакого значения.
Я не призываю вас принять не свойственную вам точку зрения. Просто хочу показать, что на один и тот же предмет можно смотреть под разными углами.
P.S. В заключении скажу, что я понимаю ваши вопросы, т.к. всех программистов обучают писать код императивным стилем. А такой стиль кодирования формирует процедурное мышление. Я пришёл к мышлению объектами (сущностями, если быть более точным), когда стал изучать функциональное программирование. По началу, мне оно показалось полным бредом, пока я не начал сквозь боль и неприятие учиться этим пользоваться. И после этого у меня началась формироваться новая категория мышления, т.к. я осознал, что в этом есть определённый смысл.
Класс, который следует концепции Rich объект (в терминах DDD) представляет собой класс-гибрид (я упоминал об этом в статье). Он сочетает в себе сразу несколько типов. В основе Rich объекта лежит Дата-класс, в который добавляется, как минимум Класс-исполнитель.
Уместность зависит от категории мышления программиста.
Программист, который думает процедурно, то он будет писать код примерно, как в этом примере:
public class MathService {
public String multiply(String strNumber1, String strNumber2) {
int num1 = Integer.parseInt(strNumber1);
int num2 = Integer.parseInt(strNumber2);
int result = num1 * num2;
String strResult = new Integer(result).toString();
return strResult;
}
}
Фокус в процедруном мышлении на строчки кода. Весь код приложения воспринимается, как длинная программа поделенная на классы по большей части для удобства ориентации в ней и использования. Другими словами, классы и методы нужны только для того, чтобы объединять код (в процедуры и функции) с возможностью его где-то переиспользовать.
Программист, который думает объектами, то он будет писать код примерно, как в этом примере:
public class MathWebService {
private final NumberConverter numberConverter = new NumberConverter(); // для простоты DI не буду использовать в примере.
private final MathOperations mathOperations = new MathOperations(); // для простоты DI не буду использовать в примере.
public String multiplyFeature(String strNumber1, String strNumber2) {
int num1 = numberConverter.toInt(strNumber1);
int num2 = numberConverter.toInt(strNumber2);
int result = mathOperations.multiply(num1, num2);
String strResult = numberConverter.toString(result);
return strResult;
}
}
Фокус на объектах и отношениях между ними. Для такого разработчика программа воспринимается как организация со своей иерархией, должностями и должностными инструкциями. Классы - это должности (роли) в организации, а методы - это выполняемые действия в соответствии с должностной инструкцией. Количество строк кода в должностной инструкции в этом случае играет второстепенную роль.
Если программист тяготеет к процедурному мышлению. То он вполне естественно испытывает диссонанс, увидев метод из одной строчки кода, т.к. в его категории мышления - группировка кода из одного метода лишена здравого смысла.
Такое может быть. Например, в интеграционных-сервисах, которые обогащают DTO данными, полученных из других источников, прежде чем прокинуть DTO дальше другому сервису.
Насчёт примера. Цель моего примера исключительно образовательная: показать работу принципов. Всё, что не касается этой цели было намерено убрано или упрощено.
Согласен, простота написания юнит-теста - это хороший сигнал к тому, что код перегружен в классах-исполнителях. Но если делить код по принципу "лишь бы юнит-тест было просто написать", то классы, как правило, получаются со множеством ролей, а в совсем запущенных случаях и со множеством доменов. Такой код в дальнейшем сложно поддерживать и расширять.
Также отмечу, что юнит-тест на метод класс-управленец априори будет состоять только из одних моков, т.к. класс-управленец ничего не делает сам, а только делегирует выполнение работы другим классам.
>Хотя некоторая трава, на вкус, слишком яркой стала
Цветовую палитру брал с имперской травы :-) Поэтому визуально цветовая гамма эльфийской травы в игре смотрится гармонично с окружением. А в целом, цвета могут казаться слишком яркими на фоне тёмных в видео. Рекомендую, посмотреть в самой игре, если у вас есть такая возможность.
Прежде чем ответить на ваши вопросы, проговорю один момент: если смотреть строго с позиции исправления технических ошибок, то большая часть изменений в моде попадают под категорию вкусовых улучшений. Например, чёрные текстуры, маленькие юниты и отсутствие освещения на 3d объектах в тёмное время суток - это тоже своего вкусовые улучшения, т.к. в логах игры нет никаких ошибок (текстовых строчек помеченных как [EE]). Т.е. технически игра отрисовала всё корректно - ошибок нет.
Поэтому: что считать полезным улучшением, а что вкусовым - это очень дискуссионный вопрос, и у каждого человека может быть своё видение.
Поясню почему были внесены мной изменения, которые вызвали у вас вопросы.
>чем обосновывается смена цвета травы?
Красный цвет забирал на себя много зрительного внимания при игре. Плюс обилие красного цвета в кадре (особенно на вечерней сцене) лично у меня вызывал жуткий зрительный дискомфорт при игре.
>Или убирание огня с юнитов демонов за появившиеся камни?
Значительно активная анимация забирала внимание от юнита, который должен быть центральным объектом в сцене. Другими словами, по задумке юнит должен владеть зрительным вниманием игрока, а волей-неволей глаза всё-равно фокусируются на огоньки под ногами. Я их убрал и сцена стала казаться пустой. Я добавил 3d объект в сцену и огни слева и справа на заднем плане.
>Или статическая камера вместо динамической?
Честно признаюсь, что в главном меню меня подташнивает от кругового движения камеры. Словно я надел VR-шлем и сел на аттракцион. В столицах убрал потому, что там, как я предполагаю, есть баг. Как я понял, по задумке должно было быть так: в начале "обзорная камера панорамы столицы с медленной скоростью", а затем "камера с более быстрой скоростью движется от объекта к объекту столицы". Но баг заключается в том, что проигрывание камеры не сбрасывается при выходе из экрана столицы, а воспроизведение продолжается на том моменте, когда ты закрыл окно столицы. И каждый раз открывая экран столицы у тебя там постоянно какая-то движуха, зрительно не формируется образ столицы, как целостный предмет. Плюс ты открываешь, например, окно магазина, а на заднем плане у тебя карусель. Зрительные ощущения на любителя.
>Или окно навыков -- у юнитов выглядит красивше с изображением (неужели фон нельзя было оставить?)
Фон пришлось убрать, т.к. новое положение элементов окна закрывали бы персонажа. Я одно время работал дизайнером и в общем, так делать не очень хорошо. По крайней мере, в такой ситуации. Представьте, что кто-то вас фотографирует, а какой-то человек решил пробежать и в итоге часть вашего тела закрыта.
>или у лидеров в оригинале больше направлений развития?
Всё верно, вариативность направлений пришлось поубавить, т.к. место под навыки стало значительно меньше. Плюс было желание сделать, чтобы у древа навыков юнита и лидера было какое-то общее ядро. И в моде ядро такое: у юнитов одна полоса с навыками без возможности вариации. А у лидеров та же полоса, но есть ещё две параллельные, на которые можно переключать в некоторых местах.
>Было бы неплохо, если бы каждое такое изменение можно было включать отдельно
К сожалению, игра не предоставляет такой возможности. Но лицензия мода позволяет делать ответвления (fork). Поэтому вы можете сделать форк мода и в своей версии удалить не понравившиеся вам фичи или добавить свои.
Судя по вашим формулировкам и вопросам, вы привыкли оперировать категориями. Мышление категориями - это полезный инструмент, сам им пользуюсь довольно часто, но к сожалению, у него есть недостаток: категории - это очень относительное понятие. И чертить границы категорий можно как угодно в зависимости от ситуации и задачи. Поясню на примере:
Представьте себе руководителя проекта (РП). Он привык работать с проектами, срок которых от полугода до 2-х лет. Исходя из его опыта, у такого человека вычерчивается допустим следующие категории размеров проектов: маленький (6 - месяцев), средний (12 месяцев), крупный (24 месяца). Теперь представьте себе руководителя разработки. Он привык работать не с проектами, а фичами. Сделать фичу в продукте - это проект для руководителя разработки. Исходя из его опыта, у такого человека категории размеров его проектов (сделать фичу) отличаются от аналогичных категорий РП. Для него маленький проект - 1 месяц, средний - 3 месяца, крупный - 6 месяцев.
Поэтому ваш первый вопрос не понятен, если вы не указываете объект с позиции которого будет даваться определение.
По второму вопросу, если кратко, то сложность в том, что типизация - не работает. Каждая задача уникальна и со своим контекстом. Да, можно группировать проекты в условно "типовые", чтобы например, определить стек технологий. Но из своего опыта скажу, что даже типовые задачи делаются по-разному. Например, типовая задача мониторинга в одном проекте, может быть реализована, совершенно по-другому в другом проекте. Другая реализация -> следовательно, другие трудозатраты и оценка.
Спасибо за ваш развёрнутый комментарий. С интересом почитал.
Могу только его дополнить тем, что модель работы, которую вы описываете в промышленности в ИТ называется Водопад. Она широко была популярна где-то до начала 2000-х годов. И сейчас считается неэффективной, т.к. в ИТ сейчас чертежи деталей могут меняться каждый месяц, оборудование на котором вытачиваются детали (пишут код) тоже постоянно меняется и оборудование очень сложное, в котором сотни тысяч, а в некоторых и миллионы маленьких деталей разработанных огромным количеством, зачастую, никак не связанных друг с другом людей.
Другими словами, сейчас на производстве в ИТ нет ничего фиксированного, всё может поменяться буквально через месяц-два, а бывает и чаще. И в такой среде традиционные способы оказываются мало эффективны, т.к. они рассчитаны на статическую среду, когда изменения происходят неспешно и измеряются годами, а не месяцами или неделями, как это сейчас происходит в ИТ.
С статистической точки зрения, вы абсолютно правы. Поэтому математически, демонстрация всего одного примера не может служить прочным доказательством того, что на множестве других задач он будет выполняться тоже.
С другой стороны, я не могу приложить в статью все примеры из своей практики. Статья и так получилась объёмная. И новые примеры раздули бы её ещё больше. Скажу только то, что за 4 года использования этой методикой оценки - она давала очень хороший результат. И за это время я сдал все свои проекты в срок.
Цель моей статьи: донести идею и свой опыт решения проблемы с точной оценкой задач. А применять ли эту методику на практике или нет - решать уже вам.
Я хотел лишь донести до вас мысль, что всё зависит от контекста.
В контексте коммерческой разработки: представленный пример однозначно потребуется доработать и точно учесть те предложения, что вы описали выше.
В контексте обучения: перегруженный и накрученный различными практиками пример будет только отвлекать обучаемого от основной темы.
Вы упомянули несколько хороших практик.
Действительно, есть такая хорошая практика "не смешивать технический и бизнес код". В своём примере я намеренно его нарушил, добавив конвертацию типов. Чуть ниже опишу причину.
Также вы упомянули про MVC шаблон, где пользователь взаимодействует с Controller и меняет модель (через слои Service + Repository, которого в примере у меня нет), а потом изменяет View (для бекенда - это просто вернуть ответ UI приложению)
Дополнительно, мне очень понравилось про инфраструктурную роль. Ранее мне не доводилось слышать о таком подходе применимо к классам. Это интересно. Спасибо, что поделились.
Но в итоге я понял, что мне нужно пояснить, что я имел ввиду под "образовательная цель примера".
Возможно, многие опытные специалисты, которые оставляли критические комментарии, к примеру, уже подзабыли, когда делали свои первые шаги в программировании и какие именно программы им давали писать учителя.
Статья в первую очередь направлена на начинающих специалистов и тех, кто только делает первые шаги в программировании. И если накрутить все-все хорошие практики, то фокус у обучаемого может сместиться или более того, структура приложения может оказаться слишком сложной для их восприятия и осознания.
Поэтому у меня были следующие задачи перед написанием примера:
Стартовый код примера должен умещаться в 1 класс и желательно в 1 метод
Бизнес-логика кода должна быть максимально простой, сходу понятной и не требующего погружения в предметную область
Количество операций в стартовом коде приложения не должно быть больше 3-5.
Исходя из этих задач, я выбрал максимально простой сервис: математические операции. Ведь математика - это предметная область, знакомая любому человеку, который ходил в школу. Но бизнес-код оказался настолько простой, что пришлось добавить преобразование типов, также это позволило абстрагироваться от логики UI и просто написать, что UI пришлёт текст, как его ввёл пользователь.
Подведу итог:
Образовательный пример - это не production-ready код. Он может нарушать некоторые хорошие практики, принятые в профессии, в угоду образовательной цели.
Постараюсь вам показать разницу в категориях мышления.
Процедурное мышление чем-то напоминает подход code first при проектировании API. Где сначала создаётся реализация, а затем разработчик смотрит на то, что у него по итогу получилось и описывает интерфейсы. И если на этом этапе приходит понимание, что получилось не очень удобная реализация, то начинается рефакторинг.
И при процедурном мышлении получается примерно также. Сначала код пишется в лоб, где фокус на реализацию алгоритма задачи. А затем разработчик смотрит на то, что получилось и как этим в дальнейшем пользоваться, то как правило это заканчивается рефакторигном (вынесение в классы, группировки в отдельные методы и т.п.), потому что фокус у него был другой (на реализацию алгоритма)
Мышление объектами напоминает подход contract first при проектировании API. Где сначала проектируются интерфейсы, а затем под них уже выполняется реализации.
Разработчик в этом случае выступает в роли архитектора, только не на уровне информационной системы (ИС) в целом, а на уровне приложения. Для такого разработчика программа - миниатюрная ИС со своими микросервисами и отношениями между ними. И микросервисы в данном случае выступают классы. Такой разработчик оперирует сущностями и контрактами между ними. Алгоритм реализации - это уже следующий этап, когда будут сформированы сущности и связи между ними. А количество строчек кода вообще перестаёт играть какое-либо значение.
Резюме:
И получается достаточно интересная ситуация. С точки зрения процедурного мышления - ваши претензии вполне оправданы, т.к. группировка кода (именно так рассматриваются методы в этой категории мышления) из одной строчки не имеет смысла. А с точки зрения мышления объектами, важна архитектура приложения (сущности и их отношения), а количество строчек кода вообще не имеет никакого значения.
Я не призываю вас принять не свойственную вам точку зрения. Просто хочу показать, что на один и тот же предмет можно смотреть под разными углами.
P.S.
В заключении скажу, что я понимаю ваши вопросы, т.к. всех программистов обучают писать код императивным стилем. А такой стиль кодирования формирует процедурное мышление. Я пришёл к мышлению объектами (сущностями, если быть более точным), когда стал изучать функциональное программирование. По началу, мне оно показалось полным бредом, пока я не начал сквозь боль и неприятие учиться этим пользоваться. И после этого у меня началась формироваться новая категория мышления, т.к. я осознал, что в этом есть определённый смысл.
Класс, который следует концепции Rich объект (в терминах DDD) представляет собой класс-гибрид (я упоминал об этом в статье). Он сочетает в себе сразу несколько типов. В основе Rich объекта лежит Дата-класс, в который добавляется, как минимум Класс-исполнитель.
Уместность зависит от категории мышления программиста.
Программист, который думает процедурно, то он будет писать код примерно, как в этом примере:
Фокус в процедруном мышлении на строчки кода. Весь код приложения воспринимается, как длинная программа поделенная на классы по большей части для удобства ориентации в ней и использования. Другими словами, классы и методы нужны только для того, чтобы объединять код (в процедуры и функции) с возможностью его где-то переиспользовать.
Программист, который думает объектами, то он будет писать код примерно, как в этом примере:
Фокус на объектах и отношениях между ними. Для такого разработчика программа воспринимается как организация со своей иерархией, должностями и должностными инструкциями. Классы - это должности (роли) в организации, а методы - это выполняемые действия в соответствии с должностной инструкцией. Количество строк кода в должностной инструкции в этом случае играет второстепенную роль.
Если программист тяготеет к процедурному мышлению. То он вполне естественно испытывает диссонанс, увидев метод из одной строчки кода, т.к. в его категории мышления - группировка кода из одного метода лишена здравого смысла.
Обычно ментор = наставник.
Более подробно с описанием из разных толковых словарей можно посмотреть здесь: https://gufo.me/dict/kuznetsov/ментор
Насчёт примера.
Цель моего примера исключительно образовательная: показать работу принципов. Всё, что не касается этой цели было намерено убрано или упрощено.
Такое может быть. Например, в интеграционных-сервисах, которые обогащают DTO данными, полученных из других источников, прежде чем прокинуть DTO дальше другому сервису.
Насчёт примера.
Цель моего примера исключительно образовательная: показать работу принципов. Всё, что не касается этой цели было намерено убрано или упрощено.
Согласен, простота написания юнит-теста - это хороший сигнал к тому, что код перегружен в классах-исполнителях. Но если делить код по принципу "лишь бы юнит-тест было просто написать", то классы, как правило, получаются со множеством ролей, а в совсем запущенных случаях и со множеством доменов. Такой код в дальнейшем сложно поддерживать и расширять.
Также отмечу, что юнит-тест на метод класс-управленец априори будет состоять только из одних моков, т.к. класс-управленец ничего не делает сам, а только делегирует выполнение работы другим классам.
Rogue Lords тоже стоит в wishlist'е. А вот ArtStation, к сожалению, у меня не открылся. Видимо нужен впн...
Попробуйте, возможно, ваше мнение изменится.
Я в пятых героев тоже наиграл не мало часов. Но Герои и Disciples хоть и близкие по жанру игры, но по механикам игры довольно разные.
Кампанию можно проходить с модом. Я сейчас так и делаю :-)
Приятной вам игры. Если будет возможность, поделитесь своими впечатлениями после игры.
>Хотя некоторая трава, на вкус, слишком яркой стала
Цветовую палитру брал с имперской травы :-) Поэтому визуально цветовая гамма эльфийской травы в игре смотрится гармонично с окружением. А в целом, цвета могут казаться слишком яркими на фоне тёмных в видео. Рекомендую, посмотреть в самой игре, если у вас есть такая возможность.
Спасибо за ваш комментарий. С интересом почитал.
Iratus у меня в желаемом в Steam, но поиграть руки пока не дошли. А про Легенды Эйзенвальда вообще не слышал. Спасибо за рекомендацию.
Прежде чем ответить на ваши вопросы, проговорю один момент: если смотреть строго с позиции исправления технических ошибок, то большая часть изменений в моде попадают под категорию вкусовых улучшений. Например, чёрные текстуры, маленькие юниты и отсутствие освещения на 3d объектах в тёмное время суток - это тоже своего вкусовые улучшения, т.к. в логах игры нет никаких ошибок (текстовых строчек помеченных как [EE]). Т.е. технически игра отрисовала всё корректно - ошибок нет.
Поэтому: что считать полезным улучшением, а что вкусовым - это очень дискуссионный вопрос, и у каждого человека может быть своё видение.
Поясню почему были внесены мной изменения, которые вызвали у вас вопросы.
>чем обосновывается смена цвета травы?
Красный цвет забирал на себя много зрительного внимания при игре. Плюс обилие красного цвета в кадре (особенно на вечерней сцене) лично у меня вызывал жуткий зрительный дискомфорт при игре.
>Или убирание огня с юнитов демонов за появившиеся камни?
Значительно активная анимация забирала внимание от юнита, который должен быть центральным объектом в сцене. Другими словами, по задумке юнит должен владеть зрительным вниманием игрока, а волей-неволей глаза всё-равно фокусируются на огоньки под ногами. Я их убрал и сцена стала казаться пустой. Я добавил 3d объект в сцену и огни слева и справа на заднем плане.
>Или статическая камера вместо динамической?
Честно признаюсь, что в главном меню меня подташнивает от кругового движения камеры. Словно я надел VR-шлем и сел на аттракцион. В столицах убрал потому, что там, как я предполагаю, есть баг. Как я понял, по задумке должно было быть так: в начале "обзорная камера панорамы столицы с медленной скоростью", а затем "камера с более быстрой скоростью движется от объекта к объекту столицы". Но баг заключается в том, что проигрывание камеры не сбрасывается при выходе из экрана столицы, а воспроизведение продолжается на том моменте, когда ты закрыл окно столицы. И каждый раз открывая экран столицы у тебя там постоянно какая-то движуха, зрительно не формируется образ столицы, как целостный предмет. Плюс ты открываешь, например, окно магазина, а на заднем плане у тебя карусель. Зрительные ощущения на любителя.
>Или окно навыков -- у юнитов выглядит красивше с изображением (неужели фон нельзя было оставить?)
Фон пришлось убрать, т.к. новое положение элементов окна закрывали бы персонажа. Я одно время работал дизайнером и в общем, так делать не очень хорошо. По крайней мере, в такой ситуации. Представьте, что кто-то вас фотографирует, а какой-то человек решил пробежать и в итоге часть вашего тела закрыта.
>или у лидеров в оригинале больше направлений развития?
Всё верно, вариативность направлений пришлось поубавить, т.к. место под навыки стало значительно меньше. Плюс было желание сделать, чтобы у древа навыков юнита и лидера было какое-то общее ядро. И в моде ядро такое: у юнитов одна полоса с навыками без возможности вариации. А у лидеров та же полоса, но есть ещё две параллельные, на которые можно переключать в некоторых местах.
>Было бы неплохо, если бы каждое такое изменение можно было включать отдельно
К сожалению, игра не предоставляет такой возможности. Но лицензия мода позволяет делать ответвления (fork). Поэтому вы можете сделать форк мода и в своей версии удалить не понравившиеся вам фичи или добавить свои.
Судя по вашим формулировкам и вопросам, вы привыкли оперировать категориями. Мышление категориями - это полезный инструмент, сам им пользуюсь довольно часто, но к сожалению, у него есть недостаток: категории - это очень относительное понятие. И чертить границы категорий можно как угодно в зависимости от ситуации и задачи. Поясню на примере:
Представьте себе руководителя проекта (РП). Он привык работать с проектами, срок которых от полугода до 2-х лет. Исходя из его опыта, у такого человека вычерчивается допустим следующие категории размеров проектов: маленький (6 - месяцев), средний (12 месяцев), крупный (24 месяца). Теперь представьте себе руководителя разработки. Он привык работать не с проектами, а фичами. Сделать фичу в продукте - это проект для руководителя разработки. Исходя из его опыта, у такого человека категории размеров его проектов (сделать фичу) отличаются от аналогичных категорий РП. Для него маленький проект - 1 месяц, средний - 3 месяца, крупный - 6 месяцев.
Поэтому ваш первый вопрос не понятен, если вы не указываете объект с позиции которого будет даваться определение.
По второму вопросу, если кратко, то сложность в том, что типизация - не работает. Каждая задача уникальна и со своим контекстом. Да, можно группировать проекты в условно "типовые", чтобы например, определить стек технологий. Но из своего опыта скажу, что даже типовые задачи делаются по-разному. Например, типовая задача мониторинга в одном проекте, может быть реализована, совершенно по-другому в другом проекте. Другая реализация -> следовательно, другие трудозатраты и оценка.
Спасибо за ваш развёрнутый комментарий. С интересом почитал.
Могу только его дополнить тем, что модель работы, которую вы описываете в промышленности в ИТ называется Водопад. Она широко была популярна где-то до начала 2000-х годов. И сейчас считается неэффективной, т.к. в ИТ сейчас чертежи деталей могут меняться каждый месяц, оборудование на котором вытачиваются детали (пишут код) тоже постоянно меняется и оборудование очень сложное, в котором сотни тысяч, а в некоторых и миллионы маленьких деталей разработанных огромным количеством, зачастую, никак не связанных друг с другом людей.
Другими словами, сейчас на производстве в ИТ нет ничего фиксированного, всё может поменяться буквально через месяц-два, а бывает и чаще. И в такой среде традиционные способы оказываются мало эффективны, т.к. они рассчитаны на статическую среду, когда изменения происходят неспешно и измеряются годами, а не месяцами или неделями, как это сейчас происходит в ИТ.
С статистической точки зрения, вы абсолютно правы. Поэтому математически, демонстрация всего одного примера не может служить прочным доказательством того, что на множестве других задач он будет выполняться тоже.
С другой стороны, я не могу приложить в статью все примеры из своей практики. Статья и так получилась объёмная. И новые примеры раздули бы её ещё больше. Скажу только то, что за 4 года использования этой методикой оценки - она давала очень хороший результат. И за это время я сдал все свои проекты в срок.
Цель моей статьи: донести идею и свой опыт решения проблемы с точной оценкой задач. А применять ли эту методику на практике или нет - решать уже вам.
Про пи и e, к сожалению, не слышал. Слышал про формулу длины дуги, её частный вывод, как раз и использовал в статье.
Спасибо, что поделились своей историей.