Переезд функциональной диагностики из медицины в программирование.
Термин «Функциональная диагностика» (ФД) родом из медицины. В вольной трактовке означает обследование пациента и постановку диагноза за счет применения всевозможных способов: от лекарств до диагностических операций.
Во время такой диагностики допустимо ухудшение состояния пациента вплоть до критического. ФД применяется в случаях, когда классические методы не позволяют поставить диагноз и, как следствие, назначить лечение.
Вторая особенность — результат непредсказуем до победного момента. Здесь нельзя сказать «через 2 часа (дня) станет известно». Если по предварительному прогнозу для постановки диагноза требуется 1 день, то по прошествии 4 дней остаток времени всё равно 1 день. Даже через 10 дней до результата остается — 1 день. Возможна обратная ситуация — при прогнозе в 5 дней результат появляется через 1 час.
Цифры выше абстрактные, не принимайте их за истину. Они лишь показывают положение дел.
В программировании для нерядовых случаев применяют похожие подходы. Проект целенаправленно ломают, из него «вырывают» отдельные части, в журналы для ошибок закидывают тонны отладочной информации.
В каждый момент времени сказать, сколько еще требуется времени для постановки диагноза, затруднительно.
Происходит даже так, что во время поиска причины поломки вместо прогноза сроков и стоимости работ результатом становится непосредственно исправление ошибок, после чего дополнительные действия уже не требуются.
Когда Вы запрашиваете у разработчика стоимость исправления каких-либо ошибок, относитесь с пониманием, если он не может сразу назвать точные сроки и стоимость. Тем более, если с проектом сталкивается впервые.
Я разбирался с одним проектом, который писали сторонние разработчики 5 лет назад. По-началу его поддерживали, дописывали. В последние 3.5 года только обновляли без доработок. Ко мне обратились с запросом на восстановление отправки писем.
Задача срочная, вчера начал смотреть сразу, как появилась возможность. Сегодня получил напоминание о срочности и повтор просьбы об оценке стоимости. Затратив к этому моменту 2-3 часа чистого времени, оценить еще не мог. Не хватало данных. Однако, спустя полчаса уже появилось понимание требуемого времени, сроков, методов решения.
Соглашусь, что опытный разработчик даже при беглом описании или осмотре проекта чаще и точнее назовет столь ожидаемые Вами цифры. Но, к сожалению, это возможно не в каждом случае. Иногда требуется провести полный комплекс работ для выявления причин и путей решения, сроки и стоимость которого заранее неизвестны.
Давать разработчику добро на исследование или нет, решение за Вами. Нюанс заключается в том, что иногда без исследования задачу не решить. Если же начинающий программист в такой ситуации обещает результат при небольших сроках, это повод задуматься и не начинать с ним работу. Но даже тут встречаются исключения :)
У Вас происходили такие ситуации, в которых требовалось применение методов функциональной диагностики?
#mvoevodskiy #функиональнаядиагностика #программирование #поискошибок #поискбагов #разработка #исследование #диагностика
Термин «Функциональная диагностика» (ФД) родом из медицины. В вольной трактовке означает обследование пациента и постановку диагноза за счет применения всевозможных способов: от лекарств до диагностических операций.
Во время такой диагностики допустимо ухудшение состояния пациента вплоть до критического. ФД применяется в случаях, когда классические методы не позволяют поставить диагноз и, как следствие, назначить лечение.
Вторая особенность — результат непредсказуем до победного момента. Здесь нельзя сказать «через 2 часа (дня) станет известно». Если по предварительному прогнозу для постановки диагноза требуется 1 день, то по прошествии 4 дней остаток времени всё равно 1 день. Даже через 10 дней до результата остается — 1 день. Возможна обратная ситуация — при прогнозе в 5 дней результат появляется через 1 час.
Цифры выше абстрактные, не принимайте их за истину. Они лишь показывают положение дел.
В программировании для нерядовых случаев применяют похожие подходы. Проект целенаправленно ломают, из него «вырывают» отдельные части, в журналы для ошибок закидывают тонны отладочной информации.
В каждый момент времени сказать, сколько еще требуется времени для постановки диагноза, затруднительно.
Происходит даже так, что во время поиска причины поломки вместо прогноза сроков и стоимости работ результатом становится непосредственно исправление ошибок, после чего дополнительные действия уже не требуются.
Когда Вы запрашиваете у разработчика стоимость исправления каких-либо ошибок, относитесь с пониманием, если он не может сразу назвать точные сроки и стоимость. Тем более, если с проектом сталкивается впервые.
Я разбирался с одним проектом, который писали сторонние разработчики 5 лет назад. По-началу его поддерживали, дописывали. В последние 3.5 года только обновляли без доработок. Ко мне обратились с запросом на восстановление отправки писем.
Задача срочная, вчера начал смотреть сразу, как появилась возможность. Сегодня получил напоминание о срочности и повтор просьбы об оценке стоимости. Затратив к этому моменту 2-3 часа чистого времени, оценить еще не мог. Не хватало данных. Однако, спустя полчаса уже появилось понимание требуемого времени, сроков, методов решения.
Соглашусь, что опытный разработчик даже при беглом описании или осмотре проекта чаще и точнее назовет столь ожидаемые Вами цифры. Но, к сожалению, это возможно не в каждом случае. Иногда требуется провести полный комплекс работ для выявления причин и путей решения, сроки и стоимость которого заранее неизвестны.
Давать разработчику добро на исследование или нет, решение за Вами. Нюанс заключается в том, что иногда без исследования задачу не решить. Если же начинающий программист в такой ситуации обещает результат при небольших сроках, это повод задуматься и не начинать с ним работу. Но даже тут встречаются исключения :)
У Вас происходили такие ситуации, в которых требовалось применение методов функциональной диагностики?
#mvoevodskiy #функиональнаядиагностика #программирование #поискошибок #поискбагов #разработка #исследование #диагностика
Moving functional diagnostics from medicine to programming.
The term "Functional Diagnostics" (PD) comes from medicine. In a free interpretation, it means examining a patient and making a diagnosis through the use of various methods: from drugs to diagnostic operations.
During such a diagnosis, a deterioration of the patient's condition is permissible up to a critical one. PD is used in cases when the classical methods do not allow to make a diagnosis and, as a result, to prescribe treatment.
The second feature - the result is unpredictable until the winning moment. Here you cannot say "in 2 hours (days) it will become known." If, according to the preliminary forecast, 1 day is required for diagnosis, then after 4 days the rest of the time is still 1 day. Even after 10 days, 1 day remains before the result. The reverse situation is possible - with a forecast of 5 days, the result appears after 1 hour.
The figures above are abstract, do not take them for truth. They only show the state of affairs.
In programming for non-ordinary cases, similar approaches are used. The project is deliberately broken, separate parts are “pulled out” of it, tons of debugging information are thrown into error logs.
At each point in time, it is difficult to say how much more time is needed to make a diagnosis.
It even happens that during the search for the cause of the breakdown, instead of predicting the timing and cost of the work, the result is directly the correction of errors, after which additional steps are no longer required.
When you ask the developer for the cost of correcting any errors, be sympathetic if he cannot immediately tell the exact time and cost. Especially if you are faced with a project for the first time.
I figured out one project that was written by third-party developers 5 years ago. In the beginning, he was supported, added. In the past 3.5 years, only updated without modifications. I was contacted with a request to restore sending emails.
The task is urgent, yesterday I began to look right away as the opportunity arose. Today I received a reminder of urgency and a repeat request for an estimate of value. Having spent by this moment 2-3 hours of pure time, I could not estimate yet. Not enough data. However, after half an hour, an understanding of the required time, deadlines, and methods of solution had already appeared.
I agree that an experienced developer, even with a cursory description or inspection of the project, will more often and accurately name the numbers you are expecting. But, unfortunately, this is not possible in every case. Sometimes it is necessary to carry out a full range of work to identify the causes and solutions, the timing and cost of which are not known in advance.
Whether or not to give the developer the go-ahead for research, the decision is yours. The nuance is that sometimes without research the problem cannot be solved. If a novice programmer in this situation promises a result with short deadlines, this is an occasion to think and not start working with him. But even here there are exceptions :)
Have you experienced situations in which the use of functional diagnostic methods was required?
#mvoevodskiy #functional diagnostics #programming # search errors # search bugs # development # research # diagnostics
The term "Functional Diagnostics" (PD) comes from medicine. In a free interpretation, it means examining a patient and making a diagnosis through the use of various methods: from drugs to diagnostic operations.
During such a diagnosis, a deterioration of the patient's condition is permissible up to a critical one. PD is used in cases when the classical methods do not allow to make a diagnosis and, as a result, to prescribe treatment.
The second feature - the result is unpredictable until the winning moment. Here you cannot say "in 2 hours (days) it will become known." If, according to the preliminary forecast, 1 day is required for diagnosis, then after 4 days the rest of the time is still 1 day. Even after 10 days, 1 day remains before the result. The reverse situation is possible - with a forecast of 5 days, the result appears after 1 hour.
The figures above are abstract, do not take them for truth. They only show the state of affairs.
In programming for non-ordinary cases, similar approaches are used. The project is deliberately broken, separate parts are “pulled out” of it, tons of debugging information are thrown into error logs.
At each point in time, it is difficult to say how much more time is needed to make a diagnosis.
It even happens that during the search for the cause of the breakdown, instead of predicting the timing and cost of the work, the result is directly the correction of errors, after which additional steps are no longer required.
When you ask the developer for the cost of correcting any errors, be sympathetic if he cannot immediately tell the exact time and cost. Especially if you are faced with a project for the first time.
I figured out one project that was written by third-party developers 5 years ago. In the beginning, he was supported, added. In the past 3.5 years, only updated without modifications. I was contacted with a request to restore sending emails.
The task is urgent, yesterday I began to look right away as the opportunity arose. Today I received a reminder of urgency and a repeat request for an estimate of value. Having spent by this moment 2-3 hours of pure time, I could not estimate yet. Not enough data. However, after half an hour, an understanding of the required time, deadlines, and methods of solution had already appeared.
I agree that an experienced developer, even with a cursory description or inspection of the project, will more often and accurately name the numbers you are expecting. But, unfortunately, this is not possible in every case. Sometimes it is necessary to carry out a full range of work to identify the causes and solutions, the timing and cost of which are not known in advance.
Whether or not to give the developer the go-ahead for research, the decision is yours. The nuance is that sometimes without research the problem cannot be solved. If a novice programmer in this situation promises a result with short deadlines, this is an occasion to think and not start working with him. But even here there are exceptions :)
Have you experienced situations in which the use of functional diagnostic methods was required?
#mvoevodskiy #functional diagnostics #programming # search errors # search bugs # development # research # diagnostics
У записи 8 лайков,
0 репостов,
199 просмотров.
0 репостов,
199 просмотров.
Эту запись оставил(а) на своей стене Михаил Воеводский
