morfizm (morfizm) wrote,
morfizm
morfizm

Путь кинестетика

Напишу про наболевшее. У меня в программировании экспериментальный и итеративный подход. Он как помогает мне, так и мешает мне жить. Помогает он тем, что я с энтузиазмом берусь за задачи, которые непонимаю, как решать - всё, что нужно, выяснится по ходу дела. В принципе это важнейший скилл для корпоративной карьеры инженера для уровня выше джуниора. Мешает мне жить тем, что мне очень трудно делать значимый вклад в design discussions, когда я о проблеме не подумал заранее и не провёл выходные, играясь с прототипами. Когда я работал в относительно слабой или средней группе, мне это не мешало, потому что я успевал "потрогать все руками" и даже написать прототип быстрее, чем остальные успевали придумать хоть что-нибудь. В сильной группе я могу только помогать brainstorm'ить какие-то фичи по уже готовой идее, но вот изначальный каркас - как разбить задачу на абстракции и как организовать dataflow - я не способен придумывать в реальном времени. Вернее так: мои коллеги способны это делать куда чаще, чем я.

Обычно процесс решения задачи у меня протекает так:
1. Понять requirements и изо всех сил постараться их упростить до MVP (minimum viable product). Отбросить все требования по performance, и отбросить/упростить все фичи, которые можно отбросить, чтобы продукт всё ещё мог делать хоть что-нибудь end-to-end. Как правило, начинаю со структур данных и data flow, и упрощаю их.
2. Как можно быстрее написать прототип, работающий end-to-end, написать к нему юнит тесты и end-to-end тесты, и наладить среду разработки так, чтобы можно было очень быстро делать маленькие изменения и отлаживать. Длина итераций критична. В идеале - секунды. Плохо, но терпимо - несколько минут. Неприемлемо - более 5 минут. Т.е. если итерации занимают более 5 минут, я буду всё рефакторить и редизайнить до тех пор, пока не смогу делать изменения быстрее.
3. Уже имея прототип, занимаюсь рефакторингом - делаю много итераций. Зачастую кардинально меняю абстракции, разделение на компоненты, нередко меняются структуры данных и data flow. Обычно это происходят по мере того, как валятся свежие тесты или как обнаруживается неспособность их написать из-за плохого дизайна.
4. Добавляю немножко фич - это всё равно почти MVP, но обычно добавление первых нескольких фич к чему-то уже работающему помогает понять слабые места в дизайне.
5. Уже имея вылизанный и красивый прототип для MVP плюс немного больше, я способен заниматься настоящим дизайном - т.е. рассуждать про requirements в целом, делать какие-то proof of concept, в общем делать какой-то осмысленный дизайн для задачи целиком.

Похоже, что люди, способные генерить дизайн сходу, весь этот процесс проделывают в голове. Мне не очень понятно, как. Ну, наверное, понятно - для несложных задач или для задач, которые я уже делал раньше, или видел код, я могу наваять что-нибудь сходу, но реальные задачи, как правило, сложные. Я не понимаю, как люди могут целый месяц что-то рисовать на доске, не попробовав написать прототип. Мне трудно думать, когда нельзя "пощупать", а "пощупать" это значит "написать и запустить". В общем, кинестетик.

Таким образом, первая проблема - это возможность полноправного участия в design brainstorming на ранних этапах, когда времени на кодинг нет вообще, а задач по дизайну много.

Вторая - это процесс development'а. Для меня куда более естественно добавлять end-to-end вертикали по-простому, а потом постепенно рефакторить. Коллеги, которые лучше подкованы в том, чтобы делать всё в уме, пишут много фидбека, который сводится к тому, что "сделай прямо сейчас то, что ты собирался сделать на 2-й, 3-й и т.д. итерации" (ну, вернее, писали бы, если бы я к ним не подстраивался и делал бы в том порядке, в котором мне комфортнее... конечно же, я подстраиваюсь, чтобы фидбека было мало). При этом итеративный девелопмент, разделённый горизонтально (по комнонентам, когда какие-то компоненты вообще no-op), людьми воспринимается нормально. А вертикальное деление (добавить маленькую фичу, протащив её везде, и зарефакторив) люди не любят. Причём не из-за merge conflict'ов (если изменения небольшие, то merge это ерунда), а именно из-за различий в мышлении, в подходе. Может, у них вызывает отвращение заведомо throw-away код, когда понятно, что вот это уйдёт, когда я добавлю вон то. Может, для них мой подход сложен, примерно так же, как для меня сложен их подход. Точно не знаю причин.

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

Ещё одна проблема - это то, что народ не ценит важность возможности быстрых итераций, поэтому если я своими руками не делаю какие-то улучшения (как в продукте, так и настраивая свой environment, полезные скрипты и прочее), чтобы было быстро, то чьими-то другими руками почти наверняка будет медленно. Будет рождён монстр, который компилируется 10 минут, ещё 10 минут ждать integration test'ов, и ещё минут 5 продираться с помощью десятка third party tools, чтобы собрать всё состояние системы, необходимое, чтобы разобраться, что именно сломалось и почему. Но для большинства это приемлемо, потому что у них натренирован вот этот умственный подход. Они сразу делают всё в уме, или рисуют на доске, и эти эксперименты им вроде как и не нужны.

Есть подозрение, что причина различий ещё в том, что мой подход фундаментально bottom-up, а люди вокруг натренированы использовать в top-down. Я могу воспринимать top-down либо в режиме рефакторинга, либо когда я размышляю вообще очень-очень high-level, либо когда я размышляю только над data flow. А вот в режиме top-down придумывать софтовые абстракции - с этим туго.

У меня вот эта кинестетичность и желание экспериментировать доходит до того, что если я давно не писал код (больше 3-5 дней), у меня вообще пропадает желание работать. Зная это, я придумываю себе coding задачи, которые, может, и не нужны, но помогут мне вернуться в продуктивный режим и держаться в нём.

Расскажите, есть ли у вас похожие проблемы с подходом к дизайну и к решению задач.
Tags: 1, me, polls questions and social games, psychology, software development, work
Subscribe
  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 11 comments