СКАНИРОВАНИЕ ПОРТОВ
Всем нам приходится сталкиваться с теми, кто даже не пытается найти ответа на вопрос до тех пор, пока не получит всей необходимой информации. Такие люди хотят, чтобы их оставили в покое, и не очень-то стремятся оперативно обрабатывать новые данные по мере их поступления. Но, перефразируя высказывание гуру управления Питера Друкера, можно однозначно сказать: откладывать принятие решения до получения полной информации - ужасная ошибка. Эффективным можно назвать только такого ответственного работника, который при нехватке данных или их противоречивости способен делать правильные выводы гораздо чаще, чем неправильные.
Пришло время применить критерий Друкера и к информационным технологиям, причем для оценки не только квалификации менеджеров ИТ, но и алгоритмов, с помощью которых приводятся в движение корпоративные системы.
В повседневной практике программирования выбор алгоритма, как правило, производится, исходя из наличия всех необходимых составляющих. Считается, что техника должна вступать в дело лишь после того, как собран полный комплект данных. Однако наиболее важные системы получают сегодня информацию из множества самых разных мест, а сетевые подключения, по которым она поступает, сильно различаются и по скорости, и по качеству работы. В результате при решении многих критичных задач, включая планирование рабочего процесса и оценку риска транзакций, крайне важно четко определить, когда переходить из режима ожидания к выполнению самого процесса, даже если данных для обработки все еще недостаточно.
Способы определения такого момента уже названы "онлайновым алгоритмом". Этот термин говорит сам за себя. Если при традиционном подходе учитываются только предварительно накопленные данные, а все остальное отбрасывается, то здесь информация обрабатывается по мере ее поступления в систему.
| При решении многих критичных задач крайне важно четко определить, когда переходить из режима ожидания к выполнению самого процесса. |
Подход типа "подождите, я подумаю" чреват многими нехорошими вещами. Прежде всего, он лишает интерактивного пользователя возможности пересмотреть свой вопрос, не дожидаясь ненужного ему больше ответа. Я, скажем, слышу много жалоб на то, что простая опечатка в запросе к базе данных или в адресе URL вызывает длительный простой системы, которая пытается найти ответ на непонятный вопрос. А прервать этот процесс и ввести правильные данные пользователь не в силах. Сейчас немало говорят о многопоточности, и я считаю, что она пойдет на пользу даже небольшим приложениям. Надо только, чтобы один из потоков постоянно был нацелен на восприятие пользовательского ввода, а его пересылка на обработку и сама обработка производились другими потоками.
Крайнее проявление принципа "не тронь меня" хорошо описано в фантастическом рассказе Дугласа Адамса "Хитчхайкер". Придуманный автором компьютер под выразительным названием "Глубокомысленный" готов ответить на любые вопросы о жизни, о вселенной, да и обо всем прочем, но требует на это ни много ни мало семь с половиной миллионов лет. А по истечении этого срока выдает краткий ответ: "сорок два", например. Насколько было бы лучше видеть промежуточные результаты! Если бы через миллион лет или около того компьютер сообщил, что результат "лежит между 32 и 64", человечество едва ли стало бы дожидаться окончательного ответа, а пересмотрело бы условия задачи.
Взглянув на алгоритм с онлайновой точки зрения, разработчик поневоле изменит свой подход к доработке кода. При традиционной методике мы оцениваем временной промежуток между моментом готовности данных и получением конечного результата. Но при онлайновом подходе начальная точка отсчета времени сдвигается назад, к тому моменту, когда мы задаем вопрос либо происходит какое-то другое исходное событие. А останавливается таймер после того, как будет найден более-менее приемлемый ответ. Это может быть, скажем, момент, когда дальнейшее уточнение уже не в состоянии изменить решение пользователя.
Но как оптимизировать онлайновый алгоритм? Для этого требуются другие эмпирические данные или другие положения, полученные практическим путем. Только в этом случае можно будет определить границы изменяемости параметров и выделить данные, которые следует обновлять в первую очередь. Лишь практика позволит спрогнозировать, какие данные придут последними, чтобы сосредоточить основные усилия на оценке недостающих звеньев.
Это значит, что для выработки онлайнового подхода разработчику приложений необходимо как можно ближе познакомиться с проблемами бизнеса и его средой. Другими словами, он должен превратиться из "чистого" компьютерщика и хранителя корпоративных ИТ в специалиста по решению корпоративных проблем. Вот и мне не нужно никаких дополнительных данных, чтобы увериться в справедливости такого мнения.
Пишите Питеру Коффи по адресу: peter_coffee@ziffdavis.com.
