?

Log in

No account? Create an account
   Journal    Friends    Archive    Profile    Memories
 

Тщательность - morfizm


Oct. 19th, 2009 10:36 pm Тщательность

Меня на работе время от времени хвалят за тщательность (или доскональность - как правильно перевести thoroughness?), и для меня несколько необычно это выслушивать, потому что (а) я не понимаю, как можно иначе, (б) я не прилагаю каких-то дополнительных усилий, чтобы было тщательно. Оно само так получается. Но когда много раз хвалят за одно и тоже, начинаешь верить, будто действительно обладаешь каким-то тайным и полезным знанием, а раз знание тайно, то мне не терпится им поделиться (потому что, на самом деле, оно до смешного простое).

Итак, чтобы объяснить тщательность, для начала нужно хорошо понимать понятие доказательства. Именно здесь инженер может сказать, что ему пригодился школьный курс математики, потому как именно математика (особенно, геометрия) учит проводить доказательства. Доказательство - это не что иное, как рассуждение, которое в рамках строгих логических правил сводит истинность чего-то сложного и неочевидного к совершенно непоколебимым утверждениям, в правильности которых никому не приходится сомневаться (а если приходится, значит, доказательство ещё не закончено!). Чем тщательнее человек подходит к делу, тем меньше существует вещей, в правильности которых он не сомневается, потому его доказательства более длинные. В идеале, доказательства нужно сводить к аксиомам (утверждениям, верность которых принята за данное, и является основой модели или теории), а на практике можно сводить к очень простым теоремам, которые уже много раз были доказаны, и в возможности воспроизвести это доказательство не приходится сомневаться.

Итак, первый принцип тщательности - сомневаться во всём, кроме доказуемого или абсолютно очевидного.

По части программирования, анализа данных и других инженерных задач, можно сформулировать второй базовый принцип тщательности - если не доказано, что решение работает правильно, то оно не работает правильно. Для начинающих подойдёт облегчённая форма этого постулата: "если не доказано, что решение работает правильно, то оно может работать правильно лишь по счастливой случайности". Опытные инженеры понимают, что вероятность таких случайностей близка к вероятности аппаратного сбоя вследствие попадания в процессор альфа-частицы, поэтому ей можно пренебречь. В верности этого принципа не приходится сомневаться. Всем известно, что рецензированный код (прошедший code review) может работать, а может всё ещё содержать баги, но при этом код, не прошедший рецензию, баги содержит почти наверняка.

Собственно, кроме этих двух принципов, для тщательности больше ничего не нужно. Достаточно в них очень сильно верить и соблюдать во всех мелочах. Непосредственным следствием этой веры будет, например, стремление к пониманию, ибо если вы не понимаете, вы не сможете доказать правильность. Если кто-то объясняет тщательному человеку то, что ему нужно понять, и он не понимает, он будет задавать уточняющие вопросы, пока не поймёт, или пока не признает, что понять этого не смог, поэтому нужно поискать другое решение исходной задачи, требующее какого-то другого понимания. Тщательный человек совершенно без зазрения совести может пять раз переспросить одно и тоже разными словами, или попросить повторить помедленнее, или нарисовать у доски своё понимание дела, после чего расспрашивать собеседника, пытаясь доказать себе, что собеседник правильно понял ваше понимание дела. Никакого дискомфорта не возникает перед просьбой дать подумать, просьбой изложить это в e-mail'е или просьбой дать ссылки на источники для самостоятельного изучения. Человек, относящийся к делам поверхностно, может думать, будто бы многократное переспрашивание заставляет его выглядеть глупым или отбирать у людей время. Тщательный человек, наоборот, считает, что это делает его умным: ведь стремление понять (= доказать себе правильность) - это достойное дело. Кроме того, он считает, что необходимыми расспросами он, наоборот, проявляет уважение ко времени собеседника: ведь если он не понял, то всё это объяснение не несло никакого смысла. Если же понял, значит, время прошло результативно!

Такой вот экскурс в "тщательность для начинающих".
Если что-то не понятно, welcome с вопросами.

10 comments - Leave a commentPrevious Entry Share Next Entry

Comments:

From:me_milady
Date:October 20th, 2009 06:36 pm (UTC)
(Link)
ой. я не про тщательность, но спрошу. какие этапы у вас стоят между этапом "написание кода" и "запуск"? ты упоминаешь code review. кто его делает, и сколько раз делается review? а тестирование? кто его делает? что происходит если в твоём коде найден баг?
а про тщательность интересно :) и - это хорошо когда хвалят )
From:dennyrolling
Date:October 20th, 2009 08:04 pm (UTC)
(Link)
я не знаю про многие вопросы (мы уже больше года работаем в разных командах), но к последнему: когда в коде находят баг то его стараются починить.
From:me_milady
Date:October 21st, 2009 07:32 am (UTC)
(Link)
ну конечно стараются починить )))
меня интересовало - не применяются ли штрафные санкции например? у нас босс (вроде шутит) говорит - за каждый баг вычитать $5 из зарплаты. я - на основе литературы - привожу доказательства, что даже в самых лучших компаниях количество багов на строку кода не равно нулю!!! а с учётом того, что у нас пока что нет никакого code review это просто несправедливо
From:dennyrolling
Date:October 21st, 2009 04:58 pm (UTC)
(Link)
а, нет конечно. монетарная мотивация не работает на самом деле - в какой-то момент девелоперы просекают и любой баг пытаются представить либо как фичу, либо как неверный дизайн документ (и тогда вина на пиэме), что только тратит у всех циклы и ухудшает отношения в команде.
From:me_milady
Date:October 21st, 2009 06:04 pm (UTC)
(Link)
спасибо ) точно. я так и подумала, что ни к чему хорошему это не приведёт.
From:morfizm
Date:October 21st, 2009 06:53 pm (UTC)
(Link)
Да, Денни меня опередил, я хотел то же самое сказать.

Кстати, обратная монетарная мотивация тоже не работает. Например, давать по $5 тестеру за каждый обнаруженный баг. Думаю, нет нужды объяснять, почему :)

Что хорошо работает - так это включение времени починки багов во время разработки. Например, на фичу потрачено 20 дней на разработку, плюс 5 дней на расследование и починку багов. Пишем: 25 дней. Плюсы налицо:
1. В следующий раз можно будет зарезервировать на похожу фичу сразу 25 дней, выделив 5 дней bug buffer. Меньше стресса, меньше проблем с расписанием и дедлайнами.
2. Девелоперы, которые быстро пишут говно, а потом долго чинят баги, не будут иметь преимущества перед девелоперами, которые пишут долго, но багов почти не чинят. С другой стороны, будет также очевидно, что если писать супер-долго (чтобы "вообще без багов"), то суммарное время будет значительно больше, чем если писать умеренно долго, но потом всё же починить несколько багов.
From:dennyrolling
Date:October 21st, 2009 09:21 pm (UTC)
(Link)
тема полностью раскрыта в дилберте: I'm gonna write me a new minivan
From:morfizm
Date:October 21st, 2009 07:19 pm (UTC)
(Link)
Кстати, ещё - очень важно, чтобы баги, внесённые Джоном, чинил сам Джон. Во-первых, он сможет чему-то научиться (если он допустил баг, то исправив его, он предотвратит похожий баг в будущем). Во-вторых, у него будет better idea насчёт того, сколько времени заняла его фича в целом, включая баги.
From:morfizm
Date:October 21st, 2009 04:59 am (UTC)
(Link)
Вопрос об этапах слишком общий. Написать подробно - не хватит целого поста, написать коротко - это ни о чём не скажет.

Code review делают другие члены команды. Зачастую более старшие, но это не обязательно. Процедура - посылается e-mail на alias "code review", кто-то отвечает. Иногда подходишь к человеку лично, а потом e-mail посылаешь уже просто FYI. Минимум - это один человек, но где-то половине случаев подключается ещё кто-нибудь. В редких случаях - много людей. Сложные и рискованные изменения рецензируют обязательно несколько человек. В предыдущей группе e-mail'ов не было, просто личное code review 1:1 (или, если изменение рискованное, то ты можешь по своей инициативе попросить кого-то ещё). В Google, я слышал, тендценция обратная: code review делает целая толпа, и пару десятков раундов feedback'а - это нормально. Да, фидбек: тебе присылают фидбек, и ты его incorporate in your change или объясняешь, почему ты делать этого не будешь. Практика показывает, что если изменение не принципиальное, то легче его сделать, чтобы не спорить, даже если не очень согласен, а если принципиальное, то и аргументы в защиту у тебя найдутся правильные. Так что обычно review это довольно безболезненный процесс, войн не ведут :) После подправления своего change list, нужно review'ить заново, и может возникнуть ещё несколько "кругов" фидбека. Когда делаешь code review, нужно понять смысл изменения. Иногда на это уходит несколько часов, даже если изменение небольшое.

Тестирование: unit tests пишут девелоперы (в некоторых группах вместо этого просто проходят новый код под отладчиком), а функциональные end-to-end тесты пишут тестировщики. В некоторых подразделениях у тестировщиков другая линия начальства, вплоть до VP - специально, чтобы не срезали углы.

Что происходит, если в моём коде найден баг: его файлят, иногда заодно пишут письмо или приходят в офис. Прежде, чем найден баг, могут прислать мне письмо с просьбой расследовать ситуацию и понять, в чём проблема (иногда это не баг, а фича; иногда это какой-то сбой, не связанный с нашим продуктом).
From:me_milady
Date:October 21st, 2009 07:33 am (UTC)
(Link)
ого )) интересно ) спасибо (* заставила столько писать)