Человек — ужасно ленивая зараза. Нет, ну я не о вас, конечно! Ну что вы! Я так, о себе. О 99% человечества. Но не о вас, нет. Вы сами за себя решайте. Но вот те 99%, так уж вышло — ужасно ленивы. Кто-то это отрицает, кто-то мирится, кто-то борется. А лично мне кажется, что это такая же неотъемлемая черта нашего вида, как, например, две руки и две ноги. Можно убиваться, что у нас нет крыльев или жабр — а можно научиться хорошо пользоваться тем, что есть. Так же и с ленью. Зачем её отрицать? Надо её использовать по-полной. И вот тут, поскольку мы с вами имеем кое-какое отношение к ИТ, давайте посмотрим, как с этим обстоит дело в нашей профессии.
Поначалу делу обстояло не важно. Если посмотреть на те технологии, которые были в ходу пару десятков лет назад, можно заметить, что все они были сильно требовательны к человеку. В компьютерах 30-летней давности меня больше всего удивляет не их размер или малая производительность, а то, насколько умным, точным, ответственным и грамотным должен был быть программист тех лет. Лишняя дырочка на перфокарте — и сутки работы на свалку. Читая рассказы Фейнмана о том, как они делали расчёты для Манхэттенского проекта, я поражался, что эти расчеты вообще были сделаны. Мне кажется нынче людей с такой силой воли и ответственностью найти было бы крайне сложно. Лени здесь было не место. Однако, поскольку компьютеров было мало, а инженеров — относительно много, среди них находились достойные.
Время шло. В профессию начало приходить всё больше и больше людей. А откуда? Из тех самых 99%, о которых я писал в начале. Из нас, из ленивых. В некоторых случаях лень сразу работала на результат — приводила к упрощению интерфейсов, унификации протоколов, выбрасывание ненужного. В других случаях лень проводила к провалам проектов. Надо было что-то решать. И тут начали появляться методологии разработки программного обеспечения.
Из подслушанного разговора в курилке
-Любая методология разработки лучше просто «обычного программирования»!
-Нет, потому что если я назову методологией «писать код только ночью голым при луне в лесу на пеньке», то это не лучше просто «обычного программирования»
Сколько всего разного придумано в этой сфере! Вот, к примеру, идея формальной верификации написанного кода. Ну круто же! Взять, и доказать математически, что созданный тобой код идеальный. Мечта. Песня. Но где это нынче используется? В марсоходах? В софте кардиостимуляторов? Всё? Где-то в одном проекте из миллиона. Ну а почему? А вы возьмите и представьте себе программиста, который после написания своего кода, после его успешной компиляции, запуска, smoke-теста и проверки тестировщиком — берёт и садится выводить формальное доказательство корректности кода. Много вы таких не ленивых знаете? Я вот — одного человека на несколько сотен моих знакомых программистов. И «один знакомый на пару сотен» — это еще результат серьёзно выше среднего.
Ну или вот идея водопада. Хорошая же идея. Но тоже уже отживает своё. Теоретики говорят: «Не выдерживает текущей высокой динамики и быстро меняющихся требований». Тьфу, чушь. Всё дело в том, что под «водопадом» лентяи могли месяцами, годами прятаться и ничего не делать. Ну вот хорошо было там прятаться, а на выходе — провал проекта. Современные «гибкие» методологии рекламируют как «удобные для программистов» и «отвечающие сегодняшним реалиям». Снова — тьфу. Просто скрам очень быстро достаёт лентяев из нор, за уши просто вытягивает, ставит в центр комнаты и направляет на них все прожектора. Потому и популярен.
А вот самая касаемо отношения к лени интересная штука — это TDD. Она, на самом деле, исходит из того, с чего я начал эту статью: все люди — лентяи. Однако, у TDD получилось поставить эту лень на службу человечеству в промышленных масштабах. Вот смотрите.
Допустим, вы программируете без TDD. Вы сразу пишете код. Например, какой-то функции. При этом вы ленитесь. Вы не особо думаете над названием функции, именами её аргументов, вы можете забыть проверить входные значения или не поймать какое-то исключение. Можете опечататься или вообще допустить принципиальную ошибку. И это всё можно понять — вы пытаетесь минимизировать количество своей работы, вот прямо сейчас, в эту самую секунду. Да, завтра у вас здесь выскочит ошибка. Или не выскочит. Или не у вас. В любом случае — это будет когда-то потом, потом и будем бороться. Такие мысли расхолаживают, позволяют писать откровенную лажу. Ну а что поделаешь? Минимизируем усилия.
Теперь допустим, что вы программируете с TDD. Вы начинаете с написания тестов. При этом вы, конечно же, тоже ленитесь (а ничего же не изменилось!). Но, внимание: ленитесь вы уже не при написании production-кода, а при написании теста. При этом вот в чём будет выражаться лень:
- Вы напишете тест максимально похожим на то, как будет работать ваш реальный код вызова тестируемого функционала. Ну, чтобы потом скопипастить можно было. Ну или заглянуть, как в документацию. И это отлично — вы протестируете именно то, что нужно, время сэкономите и документацию получите.
- Вы подумаете, а как бы вам хотелось, чтобы назывался тестируемый класс, метод, его аргументы. Нет, вы и при написании этого метода, возможно, об этом подумаете. Но мы ведь помним — там вы будете лениться хорошенько подумать над этим, напишете как-нибудь. А вот при написании тестов объект вашей лени — тест. Тест вы будете пытаться сделать простым и понятным, а значит и название вызываемых методов, и передаваемые им аргументы будут максимально простыми, понятными, ничего лишнего и всё по делу. И реальный код эти свойства тоже автоматом унаследует.
- Лениться при написании тестов очень легко. Тест обычно не очень большой, очень легко его скопироватьвставить и, заменив пару символов, превратить в похожий, но чуть-чуть другой. И потом в еще один. А вот уже написав все эти тесты — вам деваться будет некуда, так или иначе придётся написать код, который через них проходит.
Мораль
Лень всегда была, есть и будет. Мы не можем вот так взять и навсегда от неё избавиться. Но мы можем управлять направлением этой лени, заставить эту лень не вредить, а приносить пользу. Не ленитесь правильно лениться!
Автор: tangro
