Да, это вопрос хороший, но, по моему мнению, он является следствием из того «что он должен делать?», Ведь, для того чтобы что-то делать нужно что-то знать. Хотя верно и обратное, не нужно чего-то знать чтобы что-то делать. Начинающие разработчики могут путать цели класса и его знания пытаясь запихнуть дополнительные знания в класс не сообразующиеся с его назначением.
Цель данной статьи было не перечисление антипаттернов, а пресечение их возникновения. Для того чтобы понять систему шаблонов проектирования нужно уже освоить базу языка. Так, как это более высокий уровень абстракции. Но несколько простых вопросов могут помочь в критической оценке создаваемого дизайна без знания всех паттернов и антипаттернов.
Для познания возможностей языка программирования нужно минимум 3 года, для познания паттернов и особенностей их применения еще 2 года. Таким образом, я хороший специалист с навыками проектирования должен иметь стаж не менее 5 лет. И то, если его кто-то наставлял на путь истинный.
Коллега, какие более быстрые способы обучения навыкам хорошего проектирования с нуля Вы знаете?
«Цель-3» она про внедрение ERP, мне показалась не такой интересной, хотя и раскрывает вопрос «сколько денег принесет внедрение?». А вот «Новая Цель» сильно лучше. Однако проработка решений лучше видна в книжке «Выбор».
Список литературы я специально не стал полным делать, чтобы задать ключи для поиска, так как литературы много и она разная.
Концепция CxxTest для которого предназначен CxxMock, не позволяет делать зависимость от дополнительных библиотек. А потом и смысла нет, добавлять целую библиотеку ради кода на ~30 строк (примерный размер решения для выполнения метода).
Не совсем важно, как именно человек раньше работал. Важно как надо работать сейчас… В общении, люди не склонны переспрашивать собеседника «все ли понятно?», потому что ожидают что, то что они говорят должно быть всем понятно, что со временем приводит к синдрому «ежупы» («и ежу понятно»). Или, в свою очередь, делаются неверные выводы на основе неверных предпосылок
Навык переспрашивания «А правильно ли я понял что....?» развивается дополнительно, но как правило только у манагеров и бизнес-аналитиков. А рядовые сотрудники как правило до этого ДАО не дорастают, ибо не требуется.
На собеседовании обычно проверяется необходимый технический скилл, а не образ постановки задач в предыдущей компании.
1. Да. позволяет. И только этот режим поддерживается.
2. Передаются и сохраняются. главное чтобы указатель не умер в процессе теста. Проверяются значения указателей. Если хочется как-то по другому, то нужно писать свой перегруженный CxxTest::equals() который проверит значения по указателю.
3. Потокобезопасности нет, не было необходимости. Обычно модульные тесты выполняются в одном потоке. Если для теста требуется стросс-тестирование на потоках, то тут лучше делать ручной мок-объект, потому что иначе поведение будет не предсказуемое и CxxMock будет генерить ошибки через один из-за нарушения последовательности вызовов. Второй аргумент отсутствия — платформозависимость, CxxTest платформонезависим., поэтому CxxMock также следует этому принципу кроме требований к RTTI.
Тогда дело скорее всего кроется в том, что он НЕ ХОЧЕТ брать ответственность на себя. Возможно здесь имеет смысл выяснить почему он не хочет брать ответственность на себя и что с этим можно сделать проработав дерево текущей реальности (еще один инструмент ТОС). Очень интересно с помощью инструментов ТОС моделировать переговоры.
Заказчик не любит думать об информационной системе которую ему надо, у него всяких других дел как правило выше крыши. Вот представь что нужно одновременно контролировать поставки, контракты, сроки заключения договоров, обязательства… а тут приходишь ты и начинаешь спрашивать какие-то вопросы о которых надо подумать… Ну нафиг! «у меня нет времени об этом думать» будет самый простой выход и ситуации.
Я в таких случаях, прорабатываю 2 наиболее вероятных варианта понимания требований заказчика и задаю вопрос в виде: А правильно ли я понял что нужно «решение А» или вы имели ввиду «решение Б»? Тут сильно думать уже не так требуется, нужно выбрать один из двух вариантов, если они подходят, или Заказчику придется сделать поправку «Нет, я не это имел в виду....» и тогда он уточнит что же он имел ввиду. и после проработки и анализа новых данных повторяем. Но следует учесть, что если заказчик изначально отказывается то и в подходе с согласованием из вариантов нужно на него не сильно давить, и возможно пакетировать все вопросы требующие решений в 2-3 встречи.
Хороший вопрос содержит 90% ответа (с) народная мудрость.
Если возникает конфликт между желанием заказчика добавить фичу и сложностью ее внедрения или не пониманием целесообразности, то тут также может помочь проработка дерева будущей реальности. С выяснением ответов на вопрос «К чему приведет внедрение этой фичи?» и «Какие реальные потребности клиента/пользователя решит новая фича?».
Результатом проработки этих сценариев и последствий будет или согласие по необходимости внедрения или иное, альтернативное решение. Вполне возможно, что то нужно клиенту это не совсем то что он просит сделать в системе.
За ссылку спасибо, не знал что такое есть, и в итоге сделал свой инструмент как раз чтобы работать по описанной методике.
О календарном планировании, можете пример привести на какие вопросы он лучше отвечает и в какой ситуации? Или это про конфликт ресурсов и связанное с ним изменение очередности выполнения работ на ресурсе?
Я вижу, что при рассмотрении детального плана можно учитывать риски каждой задачи, что в случае неоднородных проектов (производство, разработка ПО, поставка и другие) будет иметь смысл ибо неоднородность проекта приводит неоднородности рисков. Но в таком случае, я бы развел на отдельные этапы работ с независимым расчетом, что приводит опять к простому сценарию для каждого этапа.
Напомните, о каких колбасках идет речь? Если диаграмма критической цепи с учетом буферов (БДР, БСП), то я считаю что настолько детальное планирование имеет смысл только при очень большой конкуренции за ресурсы и сильных рисках именно на доступности ресурса.
Но если буфера на цепи упрощать, то мы получим буфер проекта который отслеживается весьма просто. Но он больше отвечает на вопрос о здоровье проекта, а не предполагаемых затратах.
Для познания возможностей языка программирования нужно минимум 3 года, для познания паттернов и особенностей их применения еще 2 года. Таким образом, я хороший специалист с навыками проектирования должен иметь стаж не менее 5 лет. И то, если его кто-то наставлял на путь истинный.
Коллега, какие более быстрые способы обучения навыкам хорошего проектирования с нуля Вы знаете?
Список литературы я специально не стал полным делать, чтобы задать ключи для поиска, так как литературы много и она разная.
Навык переспрашивания «А правильно ли я понял что....?» развивается дополнительно, но как правило только у манагеров и бизнес-аналитиков. А рядовые сотрудники как правило до этого ДАО не дорастают, ибо не требуется.
На собеседовании обычно проверяется необходимый технический скилл, а не образ постановки задач в предыдущей компании.
2. Передаются и сохраняются. главное чтобы указатель не умер в процессе теста. Проверяются значения указателей. Если хочется как-то по другому, то нужно писать свой перегруженный CxxTest::equals() который проверит значения по указателю.
3. Потокобезопасности нет, не было необходимости. Обычно модульные тесты выполняются в одном потоке. Если для теста требуется стросс-тестирование на потоках, то тут лучше делать ручной мок-объект, потому что иначе поведение будет не предсказуемое и CxxMock будет генерить ошибки через один из-за нарушения последовательности вызовов. Второй аргумент отсутствия — платформозависимость, CxxTest платформонезависим., поэтому CxxMock также следует этому принципу кроме требований к RTTI.
Или ты уже это пробовал?
Я в таких случаях, прорабатываю 2 наиболее вероятных варианта понимания требований заказчика и задаю вопрос в виде: А правильно ли я понял что нужно «решение А» или вы имели ввиду «решение Б»? Тут сильно думать уже не так требуется, нужно выбрать один из двух вариантов, если они подходят, или Заказчику придется сделать поправку «Нет, я не это имел в виду....» и тогда он уточнит что же он имел ввиду. и после проработки и анализа новых данных повторяем. Но следует учесть, что если заказчик изначально отказывается то и в подходе с согласованием из вариантов нужно на него не сильно давить, и возможно пакетировать все вопросы требующие решений в 2-3 встречи.
Хороший вопрос содержит 90% ответа (с) народная мудрость.
Результатом проработки этих сценариев и последствий будет или согласие по необходимости внедрения или иное, альтернативное решение. Вполне возможно, что то нужно клиенту это не совсем то что он просит сделать в системе.
О календарном планировании, можете пример привести на какие вопросы он лучше отвечает и в какой ситуации? Или это про конфликт ресурсов и связанное с ним изменение очередности выполнения работ на ресурсе?
Я вижу, что при рассмотрении детального плана можно учитывать риски каждой задачи, что в случае неоднородных проектов (производство, разработка ПО, поставка и другие) будет иметь смысл ибо неоднородность проекта приводит неоднородности рисков. Но в таком случае, я бы развел на отдельные этапы работ с независимым расчетом, что приводит опять к простому сценарию для каждого этапа.
Но если буфера на цепи упрощать, то мы получим буфер проекта который отслеживается весьма просто. Но он больше отвечает на вопрос о здоровье проекта, а не предполагаемых затратах.