Комментарии 117
Вычёркивайте меня из профессионалов: мне стало скучно на 3-4 вопросе, а там их 3 страницы...
Same here. Кроме того вопрос "Какой уровень покрытия кода автоматизированными тестами вы считаете достаточным?" с конкретными вариантами ответа, и отсутствует ответ "никакой". Видимо, Мартина обошли стороной системы с 200% покрытия кода, которые все равно падают с багами.
Еще не надо забывать, что код бывает сильно разный. Бывают одноразовые скрипты, для решения конкретной задачи, которые глупо покрывать тестами даже на 1%, потому что это будет пустая трата времени и денег.
Так как тесты могут работать неправильно, то нужны ещё и тесты на тесты, но и они могут быть некорректными... O shi!
Я молчу про то, что тогда уж нужно покрытие всех веток в логике приложения, что вообще то часто недостижимая задача.
И заметил что после правок в одном модуле тест не падает, хотя точно должен.
По итогу выяснил что (в неявном виде) проверка в конце сводилась к
EXPECT_EQ(calculatedData, calculatedData) (понятно что без дебага теста выяснить что он сравнивает данные сами с собой не удавалось).
Я поправил тест и выяснил что он не работал уже очень давно)
Собственно я к чему. По метрикам — все прекрасно. Покрытие — отличное, все ветки кода выполняются. А по факту да, тест ничего не проверяет кроме того что програма не упала на выполнении)
Добавление мутационных тестов покажет, на сколько юнит тесты написаны качественно.
Но гарантии правильности кода не даст все равно :)
Если тесты не гарантируют надежности кода - значит код или тесты написаны плохо.
Например, на каком-нибудь Yii2 фреймворке, где в каждом втором методе, внутри происходит обращение к глобальному Yii::$app объекту, в котором может быть что угодно - да, обнуляет ценность юнит-тестов.
Только проблема тут не в тестах, а в плохих фреймворках. И как раз написание тестов и стремление к надежному коду - учит отличать хорошие подходы от плохих.
Вот именно по этому я со скепсисом отношусь к методике юнит тестирования и автотестпирования. Тест тоже программа - и она тоже может содержать ошибки и так бывает что содержит.
По этой же причине не могу серьёзно учитывать его мнения в том, кто какой профессионал =)
Вычеркивайте меня тоже. Этот тест никакого отношения к Мартину не имеет.
Легко и просто быть профессионалом в компании других профессионалов.
Но в реальной жизни всегда приходится делать выбор, стоять на месте пока профессионалов подвезут или двигаться вперед. Если профессионализм рассматривать не как цель, а как путь. Тогда да, можно стремиться, но в текущий момент профессионалом тебя назвать будет нельзя.
Неожиданно подумалось, что по форме это практически религия. Не греши и будет тебе царствие. Ну а так как ты все равно грешник испытывай стыд и лучше старайся. А цель все равно будет за горизонтом как ни беги.
Иногда нужно побыть и язвительным душнилой.
Говоришь: "Не стройте мост из этого материала, он развалится". А тебе говорят: "Какой-то вы токсичный, прислушивайтесь к молодым специалистам".
Говоришь: "Не поднимайте голову над окопами, застрелят же". А они всё равно поднимают. Наверное, надо и прикрикнуть в этом случае, нет?
Тест прошёл, но какой блин из меня профессионал, не всегда согласен с мнением автора.
Он оказался из секты тех, кто верит в 100 процентное тестовое покрытие. Это многое говорит и о его профессионализме.
Злые языки говорят, что он открыл компанию, где весь код писался по его принципам. Однако компанию это не спасло от банкротства.
Ну по крайней мере на почве писательства книг мужик явно преуспел.
Ну вообще логика автора достаточно категоричная, но в целом заставляет задуматься:
Профессионал должен отдавать полностью рабочий код, он не должен заранее допускать, что там половина или 30% фич может не работать. Согласны? мне кажется логично...
Как вам гарантировать что функция будет работать? по мнению автора - это только написать автоматизированный тест. Вроде тоже логично, тк ручное тестирование - это долго, субъективно... сначала может и можно что-то протестить руками, но после некоторого времени протестировать руками все затронутые варианты становится просто невозможно
отсюда автор делает вывод, что нужно асимптотически стремиться к 100%... те понятно что 100% вы не получите, но цель ставить - 100%... ставить себе достаточный критерий, например, 70% - по логике автора неправильно
Сразу скажу, что я тут не рву на себе рубашку чтобы защитить точку зрения автора, на моем текущем проекте покрытие чуть более 70%, но фиг знает, может большее покрытие окажется более экономически эффективным.
Вообще у меня знакомый в фейсбуке работает, так у них в команде нет тестеров вообще. Разработчики сами все тестируют и выкатываю в прод. Как они это делают? У них это высокое покрытие кода автотестами + всякие там канареечные релизы. Честно говоря не знаю насколько это распространенная практика в интернет-компаниях, может тут есть кто от туда - поделитесь опытом? Может из гугла кто? или Яндекса? или из еще каких-то ИТ-компаний лидеров есть тут?
Так проблема как раз в категоричности автора, а его пункт про тесты просто наиболее ярко её показывает.
Излишняя категоричность это признак непрофессионализма. Так то.
Нет. Простой пример — у моего кода примерно 150 потребителей. Это разные команды, они используют каждая примерно (циферки условные) 1/5 объема фич кода. Таким образом, если я выпущу новую версию, в которой даже половина фич не работают (но я при этом точно знаю, какие именно), зато остальные скажем стали работать в 10 раз быстрее, то значительная часть потребителей будет весьма довольна, а остальные просто подождут выпуска еще одной версии.
И что может быть лучшим критерием, чем удовлетворенность потребителя? Выбирая между мнением Мартина и потребителя я лично не особо задумаюсь, к кому прислушаться.
А ваш пример про фейсбук вообще не очень удачный. У фейсбука в продакшн грубо говоря, может быть одна версия продукта. А у меня в продакшн условно 20 версий одновременно у 150 потребителей. Наверное, если взять whatsapp, то у них тоже много версий в эксплуатации, и разных потребителей столько, сколько людей с телефонами, так что главное, о чем я говорю — что продукты бывают разные. И критерии к ним применяются тоже разные.
Кроме того, у фейсбука на сайте иногда не работает десятки фич, так что к их мнению я бы, мягко говоря, вообще не очень прислушивался.
Представьте вы решили открыть свой бизнес и вам нужно чтобы вам запили ios приложение. Вы долго думали как вы будете его монетизировать, как привлекать пользователей и тд и тп. Оценили какие фичи вам нужны и когда. Наняли разработчика, он согласился все сделать, вы ему оплатили. А потом в он вам в оговоренную дату приносит приложение, но там 1/3 фич не работает.
А когда вы его спрашиваете - а почему так - он говорит, ну не страшно, подождите следующей версии, я тут решил что часть фич вам не очень нужна...
Не думаю, что вам это очень понравится.
Я понимаю бывают разные ситуации, форс-мажоры, но это исключение, а не правило. Скорее всего в случае форс -мажора я бы предпочел, чтобы разработчик как можно раньше бы рассказал о проблеме и я смог бы что-то предпринять - что-то переиграть, сам придумать какие фичи мне меньше нужны и тд и тп
>продукты бывают разные. И критерии к ним применяются тоже разные.
Если для вашего приложения вам нужны все фичи — у вас другая ситуация, нежели у меня. Из этого ничего ровным счетом не следует по поводу моего профессионализма.
>форс-мажоры, но это исключение, а не правило.
Не вижу причин, почему это исключение? Для продуктов того типа, который я делаю, вполне нормально, что некоторые фичи не работают в некоторых версиях. Почему так? Потому что я знаю, сколько у меня потребителей, и их не бесконечно много, как пользователей у IOS приложения. И это свойство продукта, а не разработчика.
>Не думаю, что вам это очень понравится.
Заказчика устраивает. Вам в данном случае — это заказчику, а не мне как разработчику.
читал, хорошо давайте по вашему примеру
те у вас есть продукт, в котором есть , например, 100 фич
в какой-то момент времени вы с заказчиком принимаете решение, что вам нужно оптимизировать 90 фич - они будут работать быстрее/лучше, но при этом сломаются оставшиеся 10
заказчика и пользователей это устраивает, ок
вы ударили по рукам, вы начинаете работать
скажите, те 90 фич которые вы пообещали сделать, вы должны действительно сделать? или вы допускаете, что когда вы выдадите релиз, то из них процентов 30% могут не работать?
насколько обрадуется заказчик /пользователь, когда они получат от вас релиз и в нем будут работать только 50 фич, а остальные окажутся сломаны?
на самом деле возможно их 5 или 10. т.е. в общем-то я их вполне могу держать в голове, или записать. Я к тому, что тут нет экспоненциального роста сочетаний фич, когда непонятно, работает ли сочетание Ф11 и Ф87.
>скажите, те 90 фич которые вы пообещали сделать, вы должны действительно сделать?
Есть список того, что кто-то хочет. В нем есть приоритеты. Есть размеры команды, т.е. мы не можем делать 100 фич в месяц ну никак. Поэтому вполне вероятно, что какие-то фичи не будут сделаны никогда. Или просто потеряют актуальность, потому что будет найдено другое решение, лучшее. Но это вполне обычно вообще для проектов внутри компании. Делается то что нужнее.
>насколько обрадуется заказчик /пользователь, когда они получат от вас релиз и в нем будут работать только 50 фич, а остальные окажутся сломаны?
Оно на самом деле все-же не так выглядит. Ну вот реальный пример — у меня есть поддержка двух или трех СУБД. И 150 потребителей. Один или два или пять из них говорят — нам нужна вот такая доработка. Это потребители большие и важные, поэтому у доработки приоритет высокий. Они все на MS SQL. Мы им делаем версию, где поддержка оракла просто не тестируется, потому что мы заранее знаем, что не будем ее там внедрять, они ее довольные ставят — и у всех все вообще замечательно. Остальные, которым нужны (потенциально) сломанные фичи, просто не приходит в голову ставить себе эту версию, потому что они ее не заказывали, и не ждут. Ну т.е. оракл может быть даже не сломан — но мы его не проверяем, потому что зачем?
Ну т.е. при условии, что на версии большими буквами написано «на оракле не ставить» — какие вы видите потенциальные проблемы? Ну да, такой процесс годится не везде. Но для определенных проектов вполне себе годен.
Мне кажется то, что вы сейчас описали - это не совсем то о чем мы говорили выше. Мы говорили про то, что фичи которые вы пообещали сделать (или сказали, что сделали) - они должны быть реально сделаны.
Если разработчик говорит, что сделал фичу, а потом оказывается, что она не работает полностью или частично, то это не гуд.
В вашем примере вы в реальности у пользователей оракла ничего не сломали, для них просто релиз еще в работе. Это нормально, мы тоже так делаем - мы например не совсем готовые фичи часто выносим в продакшен, но в скрытом виде...
и сказали, что сделали) — они должны быть реально сделаны.
Сказали, что сделали и обещали в начале цикла — это вообще слегка разные вещи. Должны быть сделаны те, что фактически сделаны, протестированы, и анонсированы в release notes.
>В вашем примере вы в реальности у пользователей оракла ничего не сломали, для них просто релиз еще в работе.
Возможно что и так. Даже скорее всего — но тем не менее, по факту, если оно будет сломано полностью, это не является серьезной проблемой, потому что я точно знаю — кому можно этим пользоваться, а кому нет. В каком-то смысле мы даже можем выпускать экспериментальные вещи, которые работают в каких-то случаях, и не работают в других.
Опять же — на мой взгляд, это особенность проекта, что в нашей ситуации так можно. В другом проекте так скорее всего будет нельзя. Поэтому я и говорю, что продукты и проекты разные, где-то бывает не совсем так, как себе Мартин представляет, и это совершенно не значит что тут непрофессионалы априори. Реально надо смотреть, доволен ли заказчик или потребитель.
ничего принципиально не отличается у вас
ну давайте прямо совсем в лоб
допустим вы знаете что вашему VIP пользователю очень нужны 5 фич, вот позарез и прямо сейчас
вы их делаете и выпускаете в продакшен ( ну или они себе устанавливают)
если вы их реализовали отдали пользователям, то согласны же вы что эти 5 фич должны же работать полностью? а если они не работают, то это для вас должно быть как профессионала некоторым разочарованием?
неужели вы допускаете, что можете отдать пользователям 5 нужных и важных фич и при этом они могут не работать?
>Профессионал должен отдавать полностью рабочий код, он не должен заранее допускать, что там половина или 30% фич может не работать. Согласны?
Речь как раз про заранее, и про то, кто что допускает. Если заказчик или потребитель это решают, и их это устраивает — это одно, если программист по своему усмотрению — это другое. Ну и при этом, заказчика должен устраивать тот темп и качество (которое не только числом фич измеряется, обычно), с которыми реализуется продукт. То есть, вообще, все оценки, хорошо или плохо, они в большей степени должны исходить от заказчика. По сути, число неработающих фич это просто показатель качества. А кому как не заказчику его оценивать?
>а если они не работают, то это для вас должно быть как профессионала некоторым разочарованием?
Конечно. Но этому может быть много разных причин.
Скажем, считается нехорошим тоном тестировать в проме, правда? С другой стороны, в моем случае мои 150 потребителей — это 150 интеграций, с разными системами. И они все 150 существуют только там, в проме. В частности потому, что стенды разработки и тестирования примерно на порядок-другой меньше по всем параметрам. Поэтому 150 живых интеграций на них никогда не было и не будет — никто не готов платить столько денег за второй стенд, идентичный пром, столько же ядер и дисков, и еще 150 стендов для каждой участвующей системы, и кучу лицензий для них всех.
Да даже и не за стенд — я не могу вот себе официально установить где-то Oracle 11g, потому что эта версия уже не поддерживается, при этом промышленные системы на ней никуда не делись. То есть реальные особенности такой системы, когда они вдруг всплывают, я могу воспроизвести только в реальном окружении. Это накладывает свои отпечатки.
Тест прошла, таки 16 лет в индустрии, работодатели не жалуются, сейчас как подтвержу звание разраба. Ага, сейчас! Теория всегда далека от практики, увы
100% покрытия повеселили, как можно покрыть тестами то, что предсказать невозможно?
Пункт про то, что работодатель не должен предоставлять условия для развития, - это вообще прекрасно, старых выбрасываем, набираем новых умных.
Про виноватых вопрос тоже хорош - все косячили, а крайней назначили меня, эй, я программист, я делаю свою работу, я не отвечаю за то, что менеджер идиот, и, кстати, грозил снижением премии за отказ от выполнения ненужной задачи.
Не согласная я, в общем, это все же тест про сферического программиста в вакууме, и даже не разработчика.
>> Пункт про то, что работодатель не должен предоставлять условия для развития, - это вообще прекрасно, старых выбрасываем, набираем новых умных.
эээ ну там все совсем по другому вообще-то, даже есть пояснение в ответах ))
автор считает, что профессионал должен сам держать в руках свою карьеру, а не уповать на дядю, он должен сам стремиться развиваться и изучать то, что он считает правильным... если работодатель помогает, супер, это хорошо
мне кажется тут больше вопрос про пассивную/активную жизненную позицию в вопросе своей карьеры
>> Про виноватых вопрос тоже хорош - все косячили, а крайней назначили меня, эй, я программист, я делаю свою работу, я не отвечаю за то, что менеджер идиот, и, кстати, грозил снижением премии за отказ от выполнения ненужной задачи.
это про черную пятницу?
ну вот я тоже так подумал, что все виноваты кроме я, но с другой стороны... например, заказчик, что он такого сделал? он просто сделал заказ, потом передумал. Все норм, имеет право.
Заказчик говорил, что функциональность будет простой, а потом усложнял и усложнял? Ну это просто классика жанра, такое вообще каждый раз почти происходит. Ошибка в том, что разработчик - соглашался (из лучших побуждений). Я много раз на это попадался но вот, думаю, это не свидетельствовало обо мне как он профессионале...
Автор считает, что разработчик профессионал должен говорить "Да, я успею" только если он действительно понимает что он успеет. Или даже он должен дать вероятностную оценку (об этом в других главах книги). Если он не понимает задачи/рисков, то он должен сказать - "я не знаю". Это будет сигнал для того, чтобы заказчик/менеджер уточнили бы требования и тд и тп.
Самое ужасное, по мнению автора, это то, что разработчик начал ухудшать качество. Тут просто у Р. Мартина есть мнение, что самое быстрое - это двигаться через максимальное качество. Почему - можно в книге почитать.
Кстати, в данном примере заказчик то не пострадал, им приложение и не понадобилось. Больше всего пострадал сам разработчик, который работал по 20 часов впустую.
Вообще прочитайте сами этот кейс в книге - там он анализируется гораздо более глубоко. Плюс почитайте саму реальную ситуацию - http://raptureinvenice.com/is-good-code-impossible/.
Стать профессионалом - это не главная цель в жизни, на мой взгляд. Гораздо важнее научится соблюдать баланс работа/личная жизнь.
Примерно в половине вопросов не было нужного варианта, либо не хватало чекбоксов вместо radio button. Ну и 100% покрытие авто-тестами - это хорошо, это одно может обеспечить работой целые поколения.
Я вот даже поспорил бы с тем, что 100% - это хорошо. На любом крупном проекте (от 100 тыс. строк кода, если взять порог, указанный в одной из книг "дяди Боба") будет такой код, который покрывать тестами нерационально. Например, инфраструктурный/конфигурационный код, или код, который отвечает за интеграцию со сторонней системой (адаптер). Конечно, такие места должны содержать минимум логики, но стремление к 100% покрытию может привести к тестам ради тестов, ценность которых == 0, которые были написаны только для галочки. Отмечу, что эти тесты разработчик пишет в рабочее время, и за это время заплатил бизнес.
Также часто встречается ситуация, когда требования до конца не ясны, но функциональность нужно реализовать уже сейчас. Писать тесты на то, что почти гарантированно будет меняться в ближайшем будущем - тоже нерационально.
Поэтому считаю целевой уровень 70-80% оптимальным, это задаёт высокую планку: почти весь код с бизнес-логикой, скорее всего, будет покрыт тестами, но будет запас для того, чтобы не упарываться с "тестами ради тестов".
Я вот даже поспорил бы с тем, что 100% — это хорошо.
Так это же был явный сарказм
это одно может обеспечить работой целые поколения.
>> Поэтому считаю целевой уровень 70-80% оптимальным, это задаёт высокую планку: почти весь код с бизнес-логикой, скорее всего, будет покрыт тестами, но будет запас для того, чтобы не упарываться с "тестами ради тестов".
расскажите про ваш опыт? какое покрытие на вашем текущем проекте?
удавалось ли вам достигнуть 80%? какие впечатления?
Поработать честных 5-6 часов на проекте и еще поработать 4 часа над над развитием навыков дома, а потом и выходные захватить? Жить когда? Мы работаем чтобы жить, а не живем, чтоб работать. Понятно, что работа тоже в удовольствие. Однако, скажем нет рабовладельцам.
зы: Да и вообще, в 45 на пенсию пора.
По-мнению автора профессионалы оттачивают свои навыки на тренировке, а в ходе проектной деятельности их уже только применяют. Он приводит пример — хотели бы вы лечь к хирургу на операцию, который в ходе операции будет отрабатывать к-н приемы? Музыканты совершенствуют свое мастерство на репетициях, а не на концертах.
Вот только репетиции и отработка операций это часть рабочего времени хирурга и музыканта. И подобных передергов в этом тесте куча.
все равно никак сломатсья не могло
Раз столкнулся с хитрым багом, который пришлось долго выявлять, суть которого оказалась в том, что модель при простом создании и сохранении (без изменений) уже отличалась от изначальной.
По этому, я бы не стал говорить о том, что какой-то код не может сломаться. Практика показывает, что могут сломаться даже элементарные вещи.
сломаться даже элементарные
Может, только скорее всего тесты это не покажут. Например, у нас к каждого data объекта генерировалось автоматически toString для отладки, мы знаем, что программе они никогда не используются и нужны только человеку в debug или логах.
С точки зрения формального 100% покрытия мы должны написать тесты на каждый сгенеренный метод, а потом их постоянно исправлять. Что хуже всего даже если мы добавим новое поле объекта и забудем его добавить в toString, в тестах мы его тоже можем забыть. Поэтому ничего полезного они даже для будущих изменений не несут.
Вообще, нужно понимать, что 100% покрытие тестами и легкость рефакторинга проекта вообще говоря взаимопротивопложенные понятия — если на каждый рефакторинг требуется сделать в 10 раз больше работы по изменению тестов — рефакторинг будет очень тяжелым.
То есть с одной стороны тесты до рефаторинга должны быть, чтобы видеть, что ничего не сломлось, с другой стороны тестов должно быть не очень много и они должны позволять достаточно быстро их поменять, иначе каждый рафакторинг будет огромной траты сил и времени.
Может, только скорее всего тесты это не покажут
Если тесты не показывают ошибки в коде - значит код или тесты написаны плохо.
И как раз тесты в этом плане учат писать надежный код. Например, при написании тестов приходишь к выводу (и не я один), что, например, использовать afterSave()/beforeSave() в моделях Yii2 это плохой подход - потому что эти методы изолированно покрыть тестами нельзя.
Да и вообще, что Yii2 очень плохой фреймворк - потому что внутри методов постоянно встречается обращение к глобальному публичному Yii::$app объекту. Что, опять же, ломает изолированность метода, и, соответственно надежность теста на этот метод.
Прошел всё, но вместо того чтобы нажать на кнопку просмотра результатов случайно перезагрузил страницу. Второй раз проходить лень. Не люблю гуглоопросники.
if(a) b(); else c();
if(d) e(); else f();
if(g) h(); else i();
Сколько надо дать комбинаций входных параметром чтобы пройтись по всем веткам (сделать 100% покрытие)? 2+2+2=6. Но сколько всего возможных комбинаций выполнения веток программы? 2*2*2=8. На любой не тривиальной программе комбинаций запредельно большое количество. Хорошо если вызовы b() c()… stateless, а если stateful?
Если поведение вашего "простого" кода не может быть столь же просто протестировано, то ваш код совсем не простой. Впрочем, Мартин позаботился, и у него есть для вас другая книга "Чистый код".
Справедливости ради. Проектировать нужно так чтобы реализации, конфигурации и абстракции лежали отдельно и не были жёстко связаны. Конкретно в вашем случае нужно стремиться к тому чтобы тесты было возможно независимо реализовать для c f I и отдельно для b e h и тогда ни какие комбинации вам не будут страшны. Удивитесь, но степень покрытия при этом будет те же 100%
чтобы тесты было возможно независимо реализоватьЧто делать со state машиной?
if(a) b(); else c();
fn real_implementation_b()
{ //do some staff }
fn real_implementation_c()
{ //do some staff }
fn stub_implementation_b()
{ //empty }
fn stub_implementation_c()
{ //empty }
fn wrong_way_implementation_b()
{ //throw Exception }
fn wrong_way_implementation_c()
{ //throw Exception }1)unit test for real_implementation_b
2)unit test for real_implementation_c
3)unit test for a == true if(a) stub_implementation_b(); else wrong_way_implementation_c();
4)unit test for a == false if(a) wrong_way_implementation_b(); stub_implementation_c();
Мне однажды пришлось сделать реализацию парсера очень маленького подможества xml (10-20 тегов), но чтобы он работал в т.ч. и на битых данных когда тег может не распознаться. Там такое количество условий в коде вышло что страшно. И несколько разных проходов парсером по данным и все в зависимости от предыдущей ситуации. Собственно говоря после написания и отладки этого кода я и пошел изучать юнит тестирование. (На самом деле получилось проще чем можно подумать, но связанность почти полная)
Честно говоря, мне кажется я не до конца понимаю. Если разговор о том что есть глобальный контекст который неявно влияет на b и с, а так же неявно изменяется внутри то это уже само по себе 'запах' 'не идеального' архетиктурного решения. Если мы говорим что у b и с есть большой набор параметров то это совсем не проблема. Оформите несколько тест кейсов на функции со всеми пограничными условиями и просто проверяйте верное ли состояние у вас будет в результате выполнения.
Грубо говоря, у вас рекурентный алгоритм который на вход получается параметры настроек и предыдущее состояние. Оценить юнит тестами работоспособность такого, как мне кажется, не сложно.
Внутри юнит теста вы можете легко задать начальное состояние системы, выполнить функцию и оценить состояние системы после.
В рамках текущего проекта в интеграционных тестах мы используем in memory db. В базе могут быть десятки различные сетов данных (а могут и не быть например). Этим мы задаём начальное состояние системы. Далее запускаем выполнение некой функции и проверяем конечное состояние в bd. С учётом что есть множество параметров которые для системы в целом могут быть заданы через конфиги и подсасывается например из переменных окружения.
Не совсем понимаю чем мой кейс принципиально отличается от вашего. Разве что уровнем исследуемых абстракций. У вас нужно протестировать функцию изменяющую состояние чего-то. У нас нужно проверить влияние/работу апи многослойного приложения.
Оформите несколько тест кейсов на функции со всеми пограничными условиями и просто проверяйте верное ли состояние у вас будет в результате выполнения.
Проблема, что их будет не несколько. Комбинаторный взрыв же.
Представим, что у нас очень сложная функция, которая зависит от всех аргументов (а их штук 20) и каждый аргумент может принимать, скажем, 10 разных значений (это мы еще сильно ограничили, вещественные вообще имеют бесконечное количество значений). Функция в будущем может поменяться, так что мы не знаем какие значения важны, какие независимы и т.д., то есть для настоящего 100% покрытия нам нужно перебрать все варианты.
Можете подсчитать сколько нужно сделать тест кейсов, чтобы гарантировать, что мы перебрали все комбинации возможных аргументов и их значений? Обратите внимание, это всего лишь одна единственная функция.
Вы описали обычный реквест со стороны фронта к нашему бекенду. Приблизительно 20 параметров с огромным разбросом значений для многих из них. С параметрами пагинации со скрытой зависимостью от конкретного пользователя делающего запрос и общего состояния системы зависящего ещё много от чего.
Никто, находящийся в здравом уме, не будет тестировать каждый реквест для каждого значения входящего int double etc параметров. Вы будете тестировать функцию вычисления чисел Фибоначчи для каждого n ? Ну тогда вы сам себе Злостный Буратино.
Если вы не знаете какие значения важны значит вы не понимаете что делаете. Это часть искусства разработки тестов - умение определять важные пограничные условия.
Вы путаете. Тестирование всех комбинаций параметров и покрытие тестами.
Я не собираюсь гарантировать перебор всех возможных комбинаций потому что это глупость и трата времени. Я желаю гарантировать актуальные для приложения кейсы и дополнять кейсы в случае появления новых (тдд).
Это работа инженера гарантировать что он выполнил работы по внедрению нового функционала без регрессии на имевшийся ранее функционал.
100% покрытия говорит о выполнении всех веток а не всех теоретически возможных комбинаций. Ещё раз, потому что это бессмысленно и бывает только в теории. В крайне редких случаях на практике. Лично я с таким не сталкивался, но не отрицаю возможности таких случаев. Просто для них необходимо разрабатывать соответствующий подход в тестировании. Например крутящиеся вечно мутационные тесты с логированием падений и дальнейшем разборе, фиксации в тестах падающих кейсов. Даже нейронные сети с миллионами параметров умудряются тестировать вероятностными моделями. Ошибки первого/второго рода.
Пишите чистые функции. Детерминируйте состояния. Разбиваете сложные системы на независимые и простые. Разбиваете стейт машины на непересекающиеся простые.
Это все большое имхо, но в мире где 99% новых приложений это spa - аргументы о сложности и принципиальной невозможности покрывать функционал тестами малоубедительны. Ещё раз, это имхо.
Лично я не сторонник тдд и более того во многом его презираю. Особенно прицел на покрытие в 100%. Просто не нужно мешать холодное и мягкое.
Это то что я и имел в виду в первом сообщении. 100% тестирования каждого оператора добиться муторно, а еще это никак не полное тестирование всех граничных условий. И лучше покрыть пару дополнительных случаев чем все геттеры и сеттеры, как пишут выше.
Да конечно, такой код плохой где много параметров еще и которые могут изменится, и мы, программисты, стараемся спроектировать чтобы такого было поменьше, но увы не можем гарантированно исключить такое полностью.
Хаха, 5 правильных ответов. Вычёркивайте меня из профессионалов q(≧▽≦q)
(Видимо, автор книги живёт в своей вселенной с розовыми пони и единорогами)
Безумно повеселил кейс с одноразовым приложением для чёрной пятницы.
Ага, я так и представляю Профессионала, который закатывает истерику по поводу того, что ему не дают для этой фигни полгода разрабатывать архитектуру и обеспечивать 100% покрытие тестами. Как и переносить релиз (зачем бизнес, какой бизнес, у нас тут покрытие не 100%). И тут же утверждения, что надо понимать, что и зачем ты делаешь.
Какой-то тест из Страны Розовых Единорогов.
Быстрое прототипирование никак не противоречит подходу Р. Мартина. Мало того, любимый автором подход XP прямо просто построен на том, чтобы делать маленькие фичи и быстро выпускать их в продакшен и получать обратную связь и тд.
Я как раз недавно читал книгу про Маска/SpaceX и там описано, что они на каждом своем запуске делают небольшие изменения и улучшения и очень много собирают телеметрии. А вы подумайте, сможете ли вы использовать "подход SpaceX" без автотестов? Если вы хотите делать небольшие изменения и выпускать их в продакшен, то вы просто обречены автоматизировать все и вся, в том числе и автотесты.
Кстати вот для SpaceX конкретно, автотесты имеют смысл, они в любом случае много тестируют, и скорее всего вручную, и переложить часть этой работы на машину выглядит неплохой идеей.
>> Посмотрите видео по ссылке, SpaceX потеряли десятки ступеней, прежде чем посадили ступень идеально.
>> Как раз это я и хотел подчеркнуть сравнивая SpaceX и NASA. Вторые стараются сделать всё сразу идеально.
мне кажется мы тут про разное "идеально" говорим. Если SpaceX запускает ракету, то это не значит, что они ее делают тяп ляп... ну, например, плохо болтами двигатель прикручивают ))
если им что-то не известно, то они готовят эксперимент для того, чтобы опровергнуть или подтвердить гипотезу...
при этом если эксперимент в итоге окажется провальным по какой-то глупости или неряшливости (типа сборщик посчитал, что 30% болтов может отвалиться и фиг с ним), то я думаю, что это будет расценено как большой провал и всем мало не покажется )))
Проходишь к Васе с проблемой, а Вася тебе в ответ: я не буду делать костыль и закрывать проблему,
Я тот самый Вася, и сейчас расскажу, почему отказываюсь решать задачи костылями:
У вас, менеджеров, сроки горят всегда. Вам всегда срочно, и что самое главное - этой срочности нельзя угодить: делаешь за месяц - долго, надо за 2 недели. Делаешь за 2 недели - долго, надо за неделю, делаешь за неделю - и опять долго...
Практика показывает, что через год таких вот решений задач через костыли резко вырастает количество багов на проде. А кого будут ругать за это? Правильно, меня, разработчика. И при этом слова "а я весь год работал в сжатых сроках, мне не давали писать код по нормальному" - никого интересовать не будут. Более того, в лицо чаще всего и не говорят, а говорят за спиной "нет, ну вы представляете, какой Вася криворукий программист, наделал столько костылей и багов в коде - как его еще не уволили" - надо ли мне оно? Разумеется нет.
Программист учит менеджеров как им работать с людьми? Нет. Вот и пусть менеджеры не учат программистов, как им писать код.
Вот подпишусь под каждым словом
Руководитель обращает внимание на… проблему… и просит дать перечень конкретных действийПосле пары таких «понятия не имею» будешь крудошлепать или переводить на фортран чужие формулы. Ничего ответственного не доверят, и правильно сделают.
Правильный ответ
Скажу, что не имею понятия в данный момент, что можно сделать и не могу обещать никаких сроков
Руководитель обращает внимание на… проблему… и просит дать перечень конкретных действий по оптимизации уже послезавтра. При этом вы знаете, что сценарий… включает в себя вызов… процедуры СУБД, сопровождением которой занимается Павел.А дожидаясь Павла уже ничего нельзя посмотреть? А может там, грубо говоря, тупо запятая не там стоит, или больше с меньше поменяно? Или, работая совместно с Павлом (достаточно тесно, чтобы звонить ему в отпуске), не удосужился хотя бы чуть разобраться в этой части на уровне «читаю со словарем»? Дожидаться придется и так, но можно чуть пошевелить-то чем-нибудь…
Правильный ответ
Придется дождаться Павла для получения рекомендаций по процедуре. К послезавтра получится подготовить только предложения по оптимизации java-сервиса и формы отображения
Ваша компания получила… контракт на разработку… Вы успеваете к сроку, но Заказчик сообщает, что… он не будет выпускать приложение. Однако работа вам полностью оплачена. Кто в данной ситуации повел себя непрофессионально?А чой-то? Работа выполнена, код попахивает, но вполне рабочий. Дайте время — он и попахивать перестанет. И полностью соблюден принцип «не навреди», ибо некому. И гонорар получен. Мы все-таки работу работать пришли, а не объяснять заказчику, почему он, наваривающийся на черных пятницах и способный выкинуть кучу бабла на неиспользуемый заказ, такой дурак и неудачник.
Правильный ответ
Вы
Менеджер говорит, что фича должна быть готова через два дня и этот дедлайн очень важно выдержать. Вы точно знаете, что этого времени мало. Выберите вариант, который наиболее близко соответствует вашему поведению на реальном проекте.Опять же, после пары таких «настаиваний» не доверят ничего серьезного. И далеко не пару раз было, что выполнял за два дня работу, на которую по хорошему неделю-полторы надо. Честно предупредив, что можно не успеть. Но успевал.
Правильный ответ
Я сообщаю менеджеру, что двух дней мало и настаиваю на том, что работа не будет выполнена к дедлайну
Про 100% покрытие тестами уже только ленивый не сказал. Непрерывный рефакторинг — туда же.
А клятва Гиппократа принципу известного стоика не противоречит ващще никак. Делай, что должно — и не вреди.
>> После пары таких «понятия не имею» будешь крудошлепать или переводить на фортран чужие формулы. Ничего ответственного не доверят, и правильно сделают.
по условию вопроса вы не знаете, что можно сделать, чтобы решить проблему
даже наоборот, вы считаете, что решить ее не удастся
автор считает, что если вы в этом случае руководителю скажете, что вы все же знаете как решить проблему - то вы его просто обманете...звучит логично
ну так все правильно, ровно так Р. Мартин и советует делать
но сначала вы должны сказать, что в данный момент не знаете как ее решить, но дальше уже будете продолжать разговор... предлагать варианты что можно сделать и тд и тп
Я сообщаю менеджеру, что двух дней мало, но так как дедлайн очень важно выдержать, то соглашаюсь попробовать приложить все усилия успеть вовремяvs
Правильный ответПочувствуйте разницу! Представьте, что вы на планерке/митинге/летучке/стендапе/оперативке (нужное подчеркнуть). У вас от силы полчаса на то, чтобы накидать план ближайших действий. «Настаиваю» в упомянутых условиях непременно упирается в «контрНастаиваю» (нет, уж ты непременно сделай!) или в поиск менее «настойчивого» специалиста и с учетом этого занимает минут 20. Вы, как профессионал, настаивать пришли или работать? Я буду ворчать, вонять, всем токсично рассказывать, что так дела не делаются, и я точно сорву сроки, потому что тут не меньше недели надо, но это будет в процессе и после работы.
Я сообщаю менеджеру, что двух дней мало и настаиваю на том, что работа не будет выполнена к дедлайну
Давайте вернемся к любимым Мартином хирургам. Вы бы предпочли, чтоб хирург сказал «неоперабельно, я настаиваю» и ждал уговоров, или все-таки дал шанс выжить и попробовал? В нашей работе встречаются такие «два дня», которые не из-за хотелок заказчика, у которого навар в черную пятницу срывается, а, скажем, всплыл косяк в медицинском приборе или самолете, или АЭС, или еще где. Примеры грубые, но все же.
Не очень давно поругался немного с начальником. Именно такая ситуация — «у тебя 2 дня», а работы недели на полторы. Взялся, сказав, что это вообще не реально. Сделал. За 2 дня. Ругался в процессе и несколько дней после. А потом на «ну ты хоть понимаешь, что тут было не меньше недели работы» получил «а я потому к тебе и подошел, а не пацанам отдал». Может, профессионализм — он ближе сюда?
у Мартина целая глава есть про то, что не надо пытаться...
это разработчик думает, что я сказал попытаюсь, значит он ничего не обещал, а с точки зрения менеджера это часто означает - да я обещаю, что сделаю
конечно, он пишет, что и сам менеджер в этом случае поступает непрофессионально, тк это распространённый косяк
по мнению Мартина лучше исключить всякие недомолвки и сказать четко свою позицию, что-то типа - я не гарантирую выполнение к данному сроку по тому-то и тому-то, наиболее вероятный срок такой-то, пессимистичный срок такой-то... вот что я предлагаю сделать дальше, чтобы внести большую ясность
как вы видите речь вовсе не про "воняние" и неадкват, а просто четко артикулировать положение вещей
Недеяние на самом деле есть именно деяние, притом весьма активное, соответствующее законам природы — соответствующее даоИ все это очень хорошо, и в этом много мудрости и философии, но что вы будете кушать зимой? Пуговицы от штанов? За настаивание на том, что не надо и пытаться и размахивание томиком Мартина зарплатку не платят. Хотя… Вы в этой статье к себе зовете. Если у вас так работают, я бы хотел попробовать :-)
Хотя, делая за 2 дня действительно важную и правда срочную работу, иногда кажется, что все-таки не в одних деньгах дело. Да и уровень будет расти только тогда, когда отодвигаешь границы попыток в область невозможного. Раньше говорили «выше головы не прыгнешь», а Лацискене уже за 2 метра прыгает.
Давайте вернемся к любимым Мартином хирургам. Вы бы предпочли, чтоб хирург сказал «неоперабельно, я настаиваю» и ждал уговоров, или все-таки дал шанс выжить и попробовал?Но при этом негативный исход намного более вероятен (по условиям задачи). Может в такой ситуации всё же можно попробовать консервативное лечение?
Вы цепляетесь к словам в аналогииСовсем нет, я просто продолжаю её. Если вообще без аналогий — у меня в карьере неоднократно случались ситуции, когда лично я говорил «Попробую, но ничего не обещаю», потом тратил полдня-день-два, и действительно ничего не удавалось сделать. Иногда даже приходилось останавливаться совсем и говорить «Тут ничего не поделаешь, данная реализация не позволяет сделать то, что вы хотите».
Итог — время (ресурс невозобновляемый) потеряно на задачу, которая изначально была нерешаема, а другие задачи, решаемые, задерживались. И проект от этого страдал.
я бы даже еще такую аналогию предложил:
вы приходите к хирургу, он видит и понимает, что операцию он сделать не сможет
если он вам прямо скажет об этом, то у вас есть вариант пойти найти другого хирурга, например, или вы можете ообще отказаться от операции и решить что лучше "дожить" так, чем рисковать
если же данный хирург ничего вам не скажет, а просто решит "попытаться", то он лишает вас возможности выбора и не факт, что сделает лучше тем самым
если вернуться к софту, то мне кажется идея Мартина именно в этом - профессионал должен честно дать обратную связь на основе которой менеджер/заказчик могли бы также предпринимать свои шаги
если разработчик просто молча соглашается и не доносит реальной ситуации, то он тем самым может навредить
во всяком случае, я, как менеджер, предпочел бы разработчика, который мне будет говорить "правду"
А возьмите, как менеджер, меня, как программиста, на работу? Я умею профессионально отказываться решать любые задачи на любом языке программирования, профессионально (и аргументированно) настаивать на невозможности их решения и профессионально говорить «правду»…
>> Опять же, после пары таких «настаиваний» не доверят ничего серьезного. И далеко не пару раз было, что выполнял за два дня работу, на которую по хорошему неделю-полторы надо. Честно предупредив, что можно не успеть. Но успевал.
Вот честно предупредив - это и есть "настаивал". Настаивал - это не значит, сел и плакал пока не дадут 2 недели. Это значит, что четко описал риски и диапазон наиболее вероятных сроков и риски. Мне кажется это логично, Заказчику лучше знать риски - так он сможет сам решить что с ними делать, принять или как-то попробовать устранить.
Коллеги, я новичок в IT, занимаюсь разработкой менее 42 лет. Объясните мне, пожалуйста, вот что. Почему мнение Роберта Мартина стоит считать значимым? И еще такой, вопрос, хотели бы вы чтобы он побыл какое-то время вашим ментором? А если не он, то кого из авторов вы бы хотели пригласить к себе в качестве ментора, если бы была такая возможность?
По поводу менторства не знаю, но с удовольствием лично обсудил каждый пункт.
Например непрерывный рефакторинг, вопросы по срокам очень интересны.
Идеальный программист это скорее зло как и идеальный код. Просто нужно понимать почему идешь на компромиссы.
Но, например, ценность непрерывного рефакторинга от меня ускользает. Особенно в крупных кодовых базах с совместным использованием кода.
Если же пишешь код один, то, честно говоря, вообще это все это ерунда. Делаешь как делается. В этом случае ты сам понимаешь что нужно.
А вы как думаете? Инстинкт самовыживания и лень.
Смотрите, человек долго что-то делал, добился "успехов", стал консультантом (не обычным, а международным!).
Собстно, раз он вроде жив, зарабатывает, пишет книги (точно очень умный мужик, правда?), то его модель поведения удачная и вам подсознательно неплохо бы её повторить. Не надо ничего придумывать нового, вот оно, на блюдечке. Только вот закавыка в том, что обстоятельства - другие, люди вокруг - другие, ситуация в мире - другая, время - другое да и в конце-концов вы - другой.
Отсюда вывод, что мода на "истории успеха человека Х" основана на старом-добром инстинкте самовыживания и лени. А по-факту повторить её не представляется возможным ввиду абсолютно другого контекста.
Плохо смотреть такие истории? Не знаю. Но скорее "нет", чем "да". Что-то полезное вы для себя найдёте. Но ломать какие-то свои фундаменты ради следования идеям человека с абсолютно другим контекстом, как по мне, опасно.
Вся история развития человечества основана на принципе увидил-повторил. Вася в условном мезозое животных не убивал сразу, а приводил домой и спаривал. Теперь у Васи есть стадо и он не умрёт с голоду зимой. Перспектива неплоха, согласитесь. Так почему-бы не повторить?
>Почему мнение Роберта Мартина стоит считать значимым?
Я занимаюсь разработкой чуть более 42 лет. И мой ответ простой — никто не знает всех сторон разработки. А их много, и они разные. Более того, он написал множество книг, а мой опыт мне подсказывает, что это такая же работа, как программирование, и она отнимает кучу времени. Вывод — много времени Р. Мартин потратил на написание книг, а не на разработку. Повышалась ли его квалификация, как разработчика, в это время? Очевидного ответа у меня нет. Вы бы хотели, чтобы вашим ментором стал писатель, или разработчик?
Так стоит ли? Простой ответ — стоит попытаться понять, на что он обращает внимание, какие вопросы ставит и как пытается отвечать, особенно если при этом вы, как новичок, их себе даже не задавали еще. Прочитав книги, вы все равно не приобретете авторский 42-летний опыт. И даже что-то возможно просто не получится понять.
Вы бы хотели, чтобы вашим ментором стал писатель, или разработчик?
Хотел бы чтобы им был тот кто может научить). К Мартину бы не пошел, кажется что у него очень «черно-белое» отношение к разработке. А вот к Макконеллу, с удовольствием.
Я занимаюсь разработкой чуть более 42 лет
Это долгий срок, даже дольше чем я живу) Поделитесь, если не секрет, остался ли у вас интерес к профессии или вы продолжаете это дело по инерции? Сейчас тренд на разочарование в IT, многие демостративно уходят.
Интересно узнать мнение человека, который остается.
Интересно, что под "Профессионалом" все (даже Википедия) подразумевают высококлассного специалиста, истинного знатока своего дела, идеал, к которому надо стремиться.
Хотя, имхо, слово "Профессионал" имеет происхождение от слова "Профессия" и подразумевает человека, который достиг такого уровня, что знания в какой-то области позволяют ему зарабатывать, работая только в этой области...
Отчасти вопросы продублированы по сути (например, про отсутствующего коллегу и подобные «дедлайн завтра»- все о том, что не стоит приносить качество в угоду срокам).
Часть вопросов нужно воспринимать в контексте работодателя. Например, о самосовершенствовании — из «правильных» ответов на вопросы следует, что хороший специалист «где-то там, дома сам» будет по 40 часов в неделю повышать свою квалификацию, а потом придет с новым знанием на проект. Нет, нанимателю это удобно: вот мне надо реализовать какой-то протокол, по этой логике я должен перед сном проштудировать RFC, попробовать завести pet-project, где в виде MVP реализую нужное, а потом приду и в рабочие 8 часов Блестяще Решу Задачу.
Пасибки, но нет: свободного времени в сутках — меньше 8 часов, и жизнь конечна. Разумеется, я изучаю что-то по профессии, но из сугубо интересного мне.
Пока существуют плохо поставленные задачи, странные
ошибки и нереалистические расписания машинного времени, будут
находится настоящие программисты, желающие взять на себя и
решить проблему, оставив документацию на потом.
Да здравствует Фортран!
Ерунда какая-то...
У профессионального программиста не бывает семьи, потому что он изучает новые технологии во вне рабочее время.
В смысле я должен испытывать удивление и огорчение, что у меня багу нашли? В моем коде тестировщики находили такие баги, что даже я не догадался бы, что такое возможно, лично написав код. Это может вызывать только восхищение из профессионализмом.
100% покрытия кода тестами - это как достичь скорости света. Уйма энергии в никуда, правило Парето и тут хорошо работает.
Может пускай Павел пишет читабельный код в хранимках? Да и пока я не заглянул в код хранимки - я не могу сказать разберусь иои нет. И вообще, хранимки у нас теперь антипаттерн.
Вопросы про менеджеров - полностью зависит от того, какой человек этот менеждер. Некоторым достаточно сказать «я попробую, но не обещаю», а не стучать на него высшему руководству.
Заголовок провокационный. И в тест включена "дичь", похоже намеренно, чтобы было как можно больше комментариев и обсуждений.
Начинал одно время смотреть видео «дядюшки Боба». Но не зашло — категоричность высказываний по любому поводу сразу отталкивает и настораживает. Хотя человек он очевидно очень умный.
Такой метод довольно удачен при работе на широкую аудиторию:
Внушаемой аудитории транслируются максимы, к которым потом отдельные представители этой аудитории будут стремится.
Критичная аудитория получив набор максим переосмыслит их и применит к себе.
ИМХО, у обсуждаемой книги полное название "Идеальный <сферический> программист <в вакууме>" - недостижимый идеал, который и должен быть сформулирован в категоричной форме.
А вот реальность и путь к этому идеалу у каждого свои.
Надо понимать, что Дядя Боб использует очень популярный в западной мотивирующей литературе принцип авторитетного мнения, когда какой-то подход описывается как единственно верный. Такие, главные секреты успеха. Подобные книги обычно гораздо лучше продаются, потому-что достаточно легко читаются, не заставляют читателя напрягать мозг. Плохо это или хорошо решает каждый для себя. Ценность этого теста минимальна, он больше подходит для развлечения. Тем-не менее, если критически рассматривать его книги, то можно почерпнуть много полезного для себя.
Вообще -то на мой взгляд боб Мартин приводит очень много аргументации и старается насколько возможно обосновывать каждое свое утверждение или приводить ссылки намконкретные ситуации. Авторитетное мнение -это когда он бы говорил вот так правильно те я сказал. Но может я заблуждаюсь. Интересно можете привести примеры где он так говорит?
Я не утверждал, что он пропихивает ничем не подтвержденные тезисы, речь шла только о стиле повествования.
Ну вы пишете что он использует подход авторитетное мнение. Этот подход подразумевает, что автор не аргументирует свою позицию, а обосновывает исключительно своим авторитетом.
Ну ок, я понял. То что он использует провокационные стиль мизлодения - тут соглашусь. Но не вижу в этом ничего такого страшного. Суть от этого не меняется.
Все пропало... столько лет стараний и стертые до крови пальцы... Звание идеального ушло от меня куда в вакуум, осталось довольствоваться скромным титулом реального программиста.
С логикой у Роберта Мартина небольшие проблемы.
1. Если тестировщик находит ошибку в вашем коде, который вы отдали на тестирование, то вы:
Правильный ответ: Испытываете удивление, огорчение
- Но при этом в комментарии пишет "Невозможно полностью избавиться от ошибок, но как профессионал вы должны стремиться к тому, чтобы ошибок не было.".
Что делает правильным ответ "Это нормально, дефекты всегда есть.". Как будто, посчитав нормальным наличие дефектов, разработчик не станет их исправлять. Но нет, надо понимать, что невозможно избавиться от ошибок, но при этом биться в истерике, если вдруг в коде найдена ошибка. Из серии "мудрая неадекватная реакция".
2. “Внесение изменений в код не должно приводить к непомерным затратам” .
Правильный ответ: Пытаться как можно чаще вносить в код изменения и проводить рефакторинги, совершенствующие структуру кода
- Может все таки стоит хорошо распланировать архитектуру? Ведь как раз тогда внесение изменений легко ляжет в общую архитектуру и не приведет к непомерным затратам чего бы то ни было. А как можно частое внесение изменений в код приведет к тому, куча времени будет тратиться на то, чтобы ничего не сломать в непродуманной архитектуре.
3.Постановка задачи делается бизнес аналитиками, так давайте заставим программиста еще в бизнес аналитикой заниматься. А если задачу ставит бухгалтер, то программисту надо пройти бухгалтерские курсы. А чтобы работать в медицинском учреждении, программисту надо получить высшее медицинское образование. Ага, конечно. Бред. Каждый должен делать свою работу и не мешать другим делать свою работу.
4. Когда вы подключились к вашему последнему проекту, то какими были ваши действия по погружению в проект?
Правильный ответ автора: Прочитал пару книжек по предметной области, пообщался с экспертами и с клиентами, изучил ТЗ и имеющиеся спецификации и т.п.
- Ага, а погружаться когда? Так и скажу клиентам "подождите, пожалуйста, пару месяцев, я пока книжки почитаю, с экспертами и клиентами пообщаюсь, и только потом изучу ваше ТЗ и приступлю к работе."
5. Руководитель обращает внимание на явную проблему производительности в одном из сценариев работы пользователя и просит дать перечень конкретных действий по оптимизации уже послезавтра.
Правильный ответ автора: Скажу, что не имею понятия в данный момент, что можно сделать и не могу обещать никаких сроков
- Ага, и руководитель вполне обоснованно спросит "а нафига ты тут тогда нужен? тебе же указывают на ЯВНУЮ проблему, засунь свою уверенность куда подальше и проанализируй код" и руководитель будет прав. Компьютер всегда прав, и если имеется явная проблема с производительностью, значит, в коде какая фигня и мы должны все перепроверить, даже если мы очень уверены, что все нормально.
Ну знаете иногда когда кто-то высказывает точку зрения сильно отличную от вашей и при этом является всемирно признанным экспертом, то очень странно так пренебрежительно отзываться о его логике. Не обязательно , конечно, что он любой кто написал пару тройку супер популярных книг не имеет проблемы с логикой, но я бы использовал этот момент чтобы самому призадуматься, а не отмахиваться… а вдруг это я чего-то не понимаю?
совершенно с вами согласен, поэтому я хорошо призадумался, проанализировал, примерил на свой реальный опыт работы, и только потом написал свое мнение.
Кстати, я расписал по пунктам, с чем именно я не согласен и попробовал обосновать свою точку зрения. Советую вам поступить так же, и обосновать с чем именно вы не согласны в моем сообщении.
Если я не прав, лучше указывать конкретно где и в чем я неправ. Фразы "Борис, ты не прав" недостаточно. :)
Ну знаете иногда когда кто-то высказывает точку зрения сильно отличную от вашей и при этом является всемирно признанным экспертом, то очень странно так пренебрежительно отзываться о его логике.
А что тут странного? С точки зрения науки логики истинность утверждения никак не зависит от персоны утверждающего — от его заслуг, моральных качеств, мировоззрения и т.д.
И если утверждающий допустил ошибки, фактические или логические, то об этом вполне допустимо писать.
PS Но, конечно, согласно той же науке логике, писать об ошибках желательно без перехода на персону утверждающего — а первое предложение предыдущего комментария вполне может быть истолковано именно как переход на личность Р.Мартина. А может — и не быть.
Профессионал ли ты по мнению Роберта “Боба” Мартина?