Data Quality

Читаю сейчас Adrenaline Junkies and Template Zombies: Understanding Patterns of Project Behavior. Интересная книга, советую.

Книга

Книга состоит из 86 эссе про хорошие и плохие вещи, повсеместно происходящие на проектах. Это скорее эссе, а не паттерны, к которым мы привыкли по GoF. Точнее мы приближаемся ближе к первоначальному значению слова "паттерн" - в данном контексте нечто повторяющееся от одного проекта к другому, неважно - плохо это или хорошо.

К слову, "плохих" историй больше, чем хороших. Оно и понятно, ведь по Chaos Report, заваленных проектов больше, чем успешных. С хорошими паттернами все ясно - бери и пользуй. Плохие скорее похожи на диагнозы без четко определенного курса лечения. В некоторых случаях прямо в лоб нам сообщают, что не лечится, иногда все же есть анализ и советы, как избежать таких ситуаций. Хотя в большинстве случаев просто объясняются возможные причины - а решение проблемы остается за вами.

Data Quality

Один из (анти)паттернов, очень близкий к моим профессиональным интересам, - Data Quality.

В одно предложение - "Качество данных оставляет желать лучшего, но вместо того, чтобы исправить сами данные, мы сделаем приложение, которое может работать с этими данными, автоматически исправлять, валидировать, пережевывать любые проблемы".

Звучит неплохо, почему бы и нет. Действительно, вместо того, чтобы исправить 5 миллионов неправильных телефонов вручную, проще сделать приложение, которые будет проверять правильность (или корректность номера) и неким образом исправлять ситуацию.

Это сложно

Именно так:
0. Сложно определить - правильные данные или нет
1. Исправить неправильные данные сложно
2. Еще сложнее сделать это автоматически
3. Правильно исправить неправильные данные - совсем тяжело
4. Правильно исправленные данные скоро могут стать неправильными
5. Если вы исправляете данные за ваших поставщиков, поставщики данных поставляют вам все более неправильные данные
6. Если вы исправляете данные в принципе, то все неправильные данные, которые приходят из вашего приложения - это ошибки в вашем приложении

Самое противное - это последние два пункта. По сути, вы снимаете ответственность за правильность данных с поставщика и потребителя и берете эту ответственность на себя. Это бесконечный scope, бесконечный источник багов и уникальная возможность для поставщиков и потребителей свалить на вас их проблемы.

Медвежья услуга

Это похоже на глотание exceptions. Если вы проглотили exception, то вы спрятали ошибку. Ошибка все еще существует. Когда к вам придут и скажут - у вас здесь неправильно, то вы только можете надеяться, что сможете когда-либо выйти на истинную причину ошибки. Ведь вы её сами же маскируете, проглатывая некорректные данные.

Или представьте себе, что вы наняли программиста, который делает ошибки в коде и вам за него надо их исправлять. Возникает два вопроса: почему и доколе. Ответы просты: "потому что за него исправляли ошибки и ранее" и "пока вы будете исправлять за ним ошибки, ничего не изменится". Точнее изменится, но в худшую сторону.

По сути, сами неправильные данные получаются благодаря тому, что данные толерантно воспринимаются потребителями.

Это замкнутый круг, а по-русски - медвежья услуга. Ведь приложения - они как люди, а если человек - тряпка, то все будут понукать им. Так что пишите только дерзкий код. Пусть он лучше дерзит вам прямо в лицо, но говорит только правду.