В какой-то момент я стал замечать, что пишу более качественный: оптимальный, логичный и читаемый код, но пишу его медленно. По крайней мере, куда медленнее, чем лет 15 назад. Да, на старый код без слёз не взглянешь: всё можно сделать оптимальнее и, по крайней мере, читабельнее. Но код был написан быстро.
Проблема в контроле. Я стал жестче и глубже контролировать процесс разработки и… стал тратить на этот контроль слишком много ресурсов.
Основной принцип прост. Если контролю подлежит 10-20% случаев, то на контроль надо тратить… 0% ресурсов. Баги и переписывания всё равно будут.
Немного теории и аналогий
Выдающийся психолог Лев Семёнович Выго́тский, показал, что действия человека итерационны. И состоят из его действия, контроля над этим действием и исправления ошибок.
Например. Когда ребенок тянется рукой к игрушке – это происходит за несколько итераций:
- Выдвинуть руку вперед
- Оценить расстояние до игрушки
- Еще выдвинуть
- Проверить тактильный контакт
- Дать команду пальцам на сближение.
- И т.д.
Для взрослых пример – движение мышки. Когда мы «тыкаем» в ссылку, то первым быстрым движением подводим курсор в область ссылки, оцениваем положение курсора и доводим до движение конца. Либо дополнительным быстрым рывком, либо чуть менее быстро и более плавно, чем в начале движения. Это получается настолько быстро и привычно, что движение кажется слитным.
Наработка автоматизма – это отключение контроля. Или перевод его в более оптимальные, подсознательные формы.
- Контроль по реперным точкам – пример с мышкой. Мы не контролируем движение курсора всегда, мы контролируем его в одной контрольной точке рядом с целью. Мы делаем это очень быстро и на автомате, поэтому движение выглядит слитным.
- Подсознательный контроль. Если на раздражитель есть стандартная реакция, то быстро нарабатывается подсознательный ответ. Когда мы промахиваемся по ссылке, мы не останавливаемся и не начинаем анализировать «кто виноват и что делать?». У подсознания достаточно информации, чтобы рассчитать завершающую фазу движения в фоновом режиме (и сразу же отправить на исполнение).
- Контроль по прерыванию. Когда движение «набито до автоматизма», то контроль включается, если что-то идёт не так. Например, заглючил драйвер мышки или комп подвис. Расчёт траектории стал сложен. В этом случае мы, включаем речевой аппарат для «слива» эмоций и несколькими _сознательными_ итерациями доводим мышь. Поскольку драйвер глючит редко (а колесики с намотанным на них мусором уже почти история), то и контроль нужен редко.
Цена вопроса
В книге Суворова-Резуна Аквариум упоминаетcя различие в подготовке спецназовцев и цироквых артистов.
«Я уже грамотен и понимаю, что человек может ходить и по телеграфному проводу над бездонной пропастью. Все дело в психологической закалке. Человек должен быть уверен, что ничего плохого не случится, и тогда все будет нормально. Цирковые артисты тратят годы на элементарные вещи. Они ошибаются. У них нет научного подхода. Они базируют свою подготовку на физических упражнениях, не уделяя достаточно внимания психологии. Они тренируются много, но не любят смерть, боятся ее…»
Автор сгущает краски. Но смысл понятен – спецназовцы отказываются от контроля (я не могу упасть), а цирковые развивают контроль до совершенства (я могу упасть, но почти в любой момент могут исправить ситуацию, поэтому я должен контролировать почти любой момент)
Технология удержании равновесия проста (пусть не на проволоке, где специфичные движения, а, скажем, по узенькой доске). Нужно идти с постоянной скоростью четко ставя ноги. Небольшая ошибка в постановке ноги или отклонении корпуса не страшна. Страшно её исправление. Попытка восстановить якобы потерянное равновесие, приводит к резонансу, когда каждая новая попытка раскачивает ещё сильнее. А чем выше доска, тем выше цена ошибки, и тем раньше включается контроль, и, соответственно, опасная «работа над ошибками».
Итак нам нужно две вещи. Не реагировать на небольшие отклонения. Поступательное движение само их сгладит. И уметь чётко, не входя в резонанс исправлять ошибки большие.
Спецназовцы ходят над пропастью не каждый день, скорее по особым случаям (по крайней мере без страховки). Посему достаточно научить их не бояться ошибок на высоте и, следовательно, самой высоты. Отсутствие работы над ошибками (или ограниченный вариант – противодействие порывам ветра) будет выливать в смертельные случаи слишком редко (тренированный человек редко фатально ошибается, плюс есть страховка). И не стоит тратить годы на выработку «контррефлексов» на каждый возможный случай.
Для цирковых, такая парадигма в прямом смысле фатальна. Они слишком часто ходят по проволоке, часто без страховки, и не только ходят. Танцуют, жонглируют, прыгают, что повышает вероятность нештатной ситуации. Если не наработан контроль и работа над ошибками, то в один не очень прекрасный день в цирке будут плакать дети, а артист этого не увидит.
Как писать код, зная всё это?
С теоретической частью закончено. Давайте, не расслабляясь, к практике.
Главное из чего мы должны исходить – в нашем коде меньше ошибок, чем нам кажется. Более того, в процессе кодирования мы должны вообще не отвлекаться на то, что мы возможно можем ошибаться.
Да, мы можем, и будем ошибаться, но заострять на этом внимание стоит лишь в процессе тестирования и отладки. Мы не должны заранее предвидеть неудачи и закладываться на них.
Мы просто выделим достаточно времени для отладки. А если его окажется слишком много, то с чистой совестью почитаем Хабр.
Дисклаймер
Эти рекомендации относятся к опытным программистам. Если вы только начинаете карьеру, пренебрегать контролем нельзя ни в коем случае.
Чем тщательнее вы себя контролируете, тем быстрее нарабатывает автоматизм. По сути именно для этого контроль и нужен… для более эффективной наработки автоматизма, притом на любой стадии развития. Когда же доберётесь до задач, где ваш автоматизм начнёт пасовать и захотите проверяться на каждом шагу… вспомните эту статью. Возможно, она небесполезна.
Итак…
Работайте большими итерациями
Разделяйте фазы написания, проверки и отладки. Считайте, что вы не ошибаетесь в коде. По крайней мере пока его пишите, вы не может ошибаться. Вообще.
Старайтесь написать как можно больше кода не останавливаясь (по крайней мере закончить функциональный блок). Остановка для проверки и отладки кода – это переключение контекста, на которое тратятся ресурсы и сбивается ритм. Проверку кода можно и нужно вынести в отдельную фазу перед отладкой. А отладку начать «сверху вниз». Начните так делать, и вы удивитесь, как часто код может заработать сразу или сразу после исправления синтаксических ошибок.
Главное, не останавливайтесь для проверок. Не надо проверять порядок аргументов вызова функции по справочнику, если мы его примерно представляем. Это можно будет сделать потом (а возможно и не придется никогда).
Не останавливайтесь для проверки небольшого фрагмента кода. Предположите, что он работоспособен и идите дальше.
Если нужно использовать несколько однотипных блоков (а вы не уверены, что они работоспособны) не надо проверять первый блок, как мы обычно делаем. Просто напишите, как вам кажется правильным или вынесите блок в функцию. Поправить несколько блоков в последствие выгоднее, чем терять темп и мысль.
Перед запуском большого куска кода «пробегитесь» по нему. Во-первых, можно проверить правильность написания идиом или вызовов функций/методов. По крайней мере, запомнить места, за которыми надо слазать в справочник. Во-вторых, явные ошибки сразу бросятся в глаза, и их можно быстро и безболезненно поправить по горячим следам. В-третьих, так мы ещё раз просмотрим и лучше запомним наше решение, и сразу отметим проблемные места, которые желательно протестировать. В- четвертых, нам всё равно придется это делать, зачем терять время?
Впрочем, если есть уверенность, что всё написано правильно, нужно сразу запускать код на исполнение. Как я упоминал, вы будете поражены, как часто он работает как и задумано с первой попытки. Чем больше контроля – тем больше неуверенности и больше вероятностей сделать не так.
Однако если что-то пошло не так, то…
Не спешите с отладкой
Итак, Хьюстон, у нас проблемы.
Втыкаем брек пойнт или отладочный вывод в код и на исполнение? Стоп!
Что нам этот метод даст? Вариантов два. Первый, мы убеждаемся, что ошибки здесь нет и начинаем проверять другое место. Второй, мы убеждаемся, что ошибка тут и радостно лезем её чинить.
Отличный метод. Позволяет «эффективно» потратить рабочее время с чистой совестью. Мы ж не на хабре сидим – мы отлаживаемся.
На самом деле, когда мы выбрали точку для отладки – мы сделали 60% работы. Давайте сделаем оставшиеся 40. Ну, или хотя бы 30, а 10% оставим на вероятность эпик фейла.
Всё что нам нужно – это сделать шаг назад. Назад по коду. Мы ждем, что в этом месте будут проблемы. Почему именно здесь, что здесь может быть не так? Часто достаточно посмотреть код, чтобы это увидеть. Но нам зачем-то нужно убедиться, что данный код не будет работать. А это лишнее, если он не работает. Вспоминаем доктора хауса и сразу тащим больного на операцию без лишних анализов.
А если мы ничего не нашли «методом пристального взгляда»? Эээ… Вы по-прежнему уверены, что репер надо поставить именно в этом месте?
Если нужна точка для диагностики проблем, то, по крайней мере, эффективно использовать двоичное деление. Давайте сразу проверим, есть ли ошибка в середине функционального блока, а не в его начале или конце?
Нет, мы всё-таки хотим плясать от консерватории. Ладно. Но вот в чём проблема. Если ошибка есть в данном фрагменте, будем ли мы «копать глубже», то есть писать ещё какой-то отладочный вывод, позволяющий более чётко идентифицировать ошибку. Будем? Так давайте сразу его и напишем. Зачем запускать программу два раза. Возможно, до этого и не дойдёт, потому, что подумав какая именно дополнительная информация нам нужна, мы часто сразу поймем где затыка.
По той же логике имеет смысл проверить ещё одну-две реперные точки сразу. 80% ошибок – это отсутствие сигнала (действия, результата), а не его искажение. Более того, искажение результата – это, скорее всего, его отсутствие на предыдущем этапе. Расставляя несколько реперных точек, мы ещё раз волей-не волей просматриваем программу. И «волшебным образом» находим ошибки, до начала отладки.
Не бойтесь поднимать глаза и смотреть на код выше предполагаемого места сбоя, очень часто там уже поставлена табличка «Я здесь! Люблю, жду! Твоя ошибка».
Не придумывайте себе проблемы заранее
Известный (возможно самый известный) игрок в покер Дойл Брансон, знаменитый весьма агрессивной игрой, говорил (не ручаюсь за достоверность цитаты), «Когда меня спрашивают, что я буду делать, если соперник поднимет мою ставку, я отвечаю: Не знаю, но пусть он сперва поднимет. А вот потом уже я буду думать над этим»
Вспомним «комплекс непрофессионала», когда профессионал зная, что проблема не решаемая и даже почему не решаемая, отказывается даже начинать работу. Новичок, не обладая таими знаниями, начинает делать работу и … делает.
На самом деле, это происходит не так чтобы часто и часто не совсем так. Профессионал знает, что написав 300 строк кода из, скажем, требуемых 400, он столкнётся с проблемой. Он не начинает писать код, а пытается сразу найти решение будущей проблемы. Находит решение (если профи не STFW, то он не профи, так ведь?), но выясняется что это решение неполное и у него есть недостатки. Которые можно исправить, если найти решение для вот этого проблемного участка… И такое решение находится, только вот,… есть нюанс…
Как вы догадываетесь – это прямой путь в депрессию. Хабр, баш, анекдоты, новости, ЖЖ и даже порносайты политические дебаты. Депрессия конечно отступит, но работа стоит. Что же делать?
Прыгать. Надо прыгать. То есть писать ту часть кода, в которой проблем нет. Когда мы дойдём до страшной проблемы, которую мы, в силу своей опытности, заметили заранее… Может выясниться, что она решается простым путём, её можно обойти или вообще такой функционал уже не нужен.
Например, часто придумывание проблем связанно с эргономикой. Хочется сделать такой удобный контрол, чтобы «сразу вот». Сразу в лес. По убеждению некоторых программистов пользователи должны гореть в аду. Вот пусть сразу и начинают мучиться. От неудобного интерфейса.
Если всё остальное будет работать как часы, то в аду будет гореть ваш начальник, который не нанял специалиста именно по интерфейсам или специалист, который с этой задачей не справился.
Также в лес проблемы связанные с производительностью. Я как-то поймал себя на том, что пытаюсь более оптимально переписать цикл на 1000 итераций. Вроде дело полезное. Но я перед этим разбираю мегабайтный JSON файл в памяти. Кого волнует, что я вложенность временного хэша снижу на уровень. Пользователь и так секунду ждёт. Ему 20 миллисекунд погоду сделают?
Да-да, производительность тоже в лес, а лес в топку. Если у нас сейчас тысяча пользователей, не надо писать приложение, которое потянет миллион. Плохо конечно писать приложение только на 1000 пользователей, но и перезакладываться более чем на порядок – мягко говоря, не оптимально. Всё равно с ростом «клиентуры» придется менять и функционал и возможно движок. И зачем лишний контроль за идеальностью кода, который будем переписывать?
Да, если есть возможность, сразу сделать приложение (то есть сразу сесть и писать) с большим запасом производительности, то надо именно так и сделать. Но если есть возможность сделать приложение только на три, две ну или хотя бы на полторы тысячи (да чёрт с ним, на текущую) тысячу, то всё равно надо садиться и писать именно такое приложение. А уж потом попытаться его обточить напильником. Разогнать готовое приложение, с которым ясно как оно работает и почему работает медленно проще, чем с нуля сделать мощный движок. (Если вы мне не верите, вы не прочитали дисклаймер).
Просто садитесь, и пишите код. Пусть не и идеальный. Я верю, что вы его доведёте в процессе.
Не спешите искать новую лопату
Помню, как меня не по детски бесил Python после Perl. Такое впечатление, что гонщика заставили сесть в трамвай. Да трамвай скоростной, а рельсы гладкие и блестящие, и скорости почти те же, но… Там где я привык осознанно использовать умолчания, Python выкидывал Exception. Вдруг я не знаю, что такого элемента в хэше может и не быть. Это ж катастрофа!
Меня стали контролировать, я стал злиться и терять время. Терять время и злиться. Мне показалось, что лучшее решение это Ruby.
С одной стороны хорошо. Разобрался пусть и «на пальцах» с рельсами. Заодно лучше понял, как работает перловый Catalyst. С другой забросил проект, который сейчас обратно пишу на питоне.
На самом деле, на питоне надо писать «pythonic», а не пытаться применять перловую парадигму: беспорядок в источниках – управляемый беспорядок в памяти – порядок на выходе.
Вывод из вышеприведенного сумбура сделать сложно. Но он есть. Не спешите менять средство разработки или библиотеки.
Идеальных средств разработки не бывает. У новой лопаты штык изогнут под более удобным углом. Но вот ручка,… сильно непривычная и норовит ударить сами знаете куда.
Проблема в выборе инструмента – это опять же путь к депресии. Нет уверенности в том, что новый инструмент подойдёт. А время на его изучение придется тратить. Делать тесты и набивать шишки. Набитые шишки – это скатывание к всё более мелким и мелким операциям, а стало быть терять инерции и скорость.
Прежде чем метаться между инструментами, разберитесь с текущим, который хорошо знаете. Вполне вероятно, вы его знаете не достаточно хорошо. Более чем вероятно, копнув глубже, вы поймёте, что же именно вам нужно. И вы не потратите время на то чтобы перепробовать кучу новых инструментов вслепую. Вы либо сядете и быстренько обработаете лопату напильником, либо пойдёте на рынок и купите именно ту лопату, которая вам нужна.
Не бойтесь выкидывать
Я не помнил точно фамилию психолога, на которого ссылался в начале статьи. Если бы я не нашёл в своём бардаке «Введение в психологию» Б.Ю. Гиппенрейтер, то я бы просто удалил этот абзац, чтобы не откладывать публикацию. Я в черновую вычистил статью от ошибок, но их осталась пачка. Я чувствую. Не могу понять только где ;)
Но если вам нравится статья – то ошибки фактор маловажный. А если не нравится,… то ещё более маловажный.
Если хотите что ли сделать, делайте сразу. И публикуйте сразу.
Не бойтесь конкурентов. Если вы что-то не доделали, то конкуренты, скорее всего тоже не доделают. Причём именно то, что не доделали вы. Им же надо спешить, чтобы подвинуть вас с рынка. А когда они повторят ваши ошибки, вы уже выйдете с новой версией на новом белом коне… с семью ногами.
Отполировать бархоткой можно в процессе. Есть продукты эппла. Где немалая часть цены – технологическая эстетика. Но… в них просто пожертвовано было другое. Например, первый макинтош ради законченности корпуса был лишен слотов для плат расширения, что стало одним из факторов его проигрыша IBM PC (по крайней мере, по объему продаж).
Да, Джобс рискнул отказаться от ненужного. И пусть он, возможно, проиграл ту битву, но сосредоточившись на сильной стороне – дизайне, в итоге сделал Apple, нынешним Apple.
Отказывайтесь от того, что не потянете или что мешает выходу прямо сейчас. Не бойтесь выдавать пользователям обрезанные беты.
Большинство изящных решений находится именно в процессе эксплуатации. Главное её начать.
Шлите на…
Если кто-то говорит, что ваша работа не нужна, что она сделана плохо, что сейчас придет кто-то и сделает лучше… В общем, любой неконструктив.
Шлите его на… Сразу. Без интеллигентостей и попыток объяснить, почему вы сделали именно так. Ну, если он конечно не ваш начальник. В этом случае… я пару раз рисковал послать начальника. И в итоге выигрывал я, особенно если менял начальника.
Если вы что и сделали плохо, то это только повод сделать следующую работу лучше. Или сильно лучше. Главное не останавливаться, не оглядываться и не смотреть вниз.
Вы что-то сделали. Вы получили опыт. Вы получили удовольствие от сделанной (по крайней мере доведённой до конца) работы.
А неконструктивные критики… Эта система контроля. Используемая в 10% случаем. А, следовательно, не нужная.
И самое главное
Делайте, что хочется и что следует и как можно реже оглядывайтесь. Не надо лишний раз проверять себя.
Всё идёт хорошо.
Автор: mclander
