Пользователь
0,1
рейтинг
7 апреля 2014 в 11:16

Разработка → Паралич анализа: вы знаете слишком много, чтобы просто писать код перевод


Это перевод статьи Analysis Paralysis: Over-thinking and Knowing Too Much to Just CODE Скотта Хансельмана за 30 марта.

Прочитал сегодня пост на ArsTechnica «Я знаю слишком много чтобы программировать быстро. Что мне делать?» — это обзор вот этого вопроса на StackOverflow:

Я стал замечать, что чем более опытным я становлюсь, тем больше времени у меня занимает выполнение проектов или задач. Я не теряю квалификацию от возраста, нет. Проблема в том, что я вижу слишком много способов чему-то сломаться. А количество потенциальных ошибок и просто нюансов, о которых мне известно, становится всё больше и больше.

Простой пример: раньше я просто записывал данные в файл. Теперь я думаю о правах доступа, занятии файла другим приложением, многопоточности, атомарных операциях, фреймворках, разных файловых системах, количестве файлов в директории, предсказуемых названиях временных файлов, качестве моего ГПСЧ, отключении электричества во время любой операции, адекватном API для моего кода, нормальной документации и так далее.

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

У меня есть пара собственных проектов, над которыми я работаю на отдыхе и по вечерам, когда все спят. Первый — порт популярного iOS приложения под Windows Phone, второй — стартап с моим другом Грегом, мы пишем iOS приложение с облачным сервисом. Оба проекта начались просто замечательно, но потом обрушилось огромное количество проблем, и разработка заглохла.

Я начинаю реализовывать фичи, а потом забрасываю. Такое чувство, что я «сваплюсь на диск» — провожу больше времени перетасовывая идеи, а не реальзуя их. Я всё ещё достаточно продуктивен в общем, но когда я пишу код, я просто начинаю тормозить.

Я слишком много думаю. «Записать настройки в файл» превращается в путаницу из паранойи о многопоточности или миграции настроек из предыдущих версий приложения (которых ещё не существует, ага), и тогда объём задачи становится слишком большим. Я не боюсь больших проектов; это всё моя архитектурная паранойя. За все годы программирования я узнал о стольких потенциальных багах и проблемах, из-за которых что-то может не работать, что, в конце концов, не работает всё из-за меня.

YAGNI — «вам это не потребуется»


Правильный ответ, говорят, — You Ain't Gonna Need It — вам это не потребуется. «Лучшее — враг хорошего.» Легко сказать, да трудно сделать. Mouviciel со StackOverflow пишет:
Похоже, вы недостаточно опытны.
Следующий ваш урок: выполняйте требования, ничего больше
Я это прекрасно понимаю, но для помощи мне часто нужен ещё один мозг.

Как меньше думать


Я узнал об Agile несколько лет назад. Больше всего из этой техники мне нравится парное программирование. С хорошим напарником получается делать работы в три раза больше, а не в два.

Так вот, я решил проблемы со своими стартапами, найдя напарников. Я не самый лучший программист, но вполне сносный. А когда работаю с напарником, то у обоих получается лучше. С Грегом я работаю над iOS, с Дженом – над другим проектом. Они явно пишут код лучше меня, хотя я тоже полезен. Они внесли в мою жизнь программиста свежий взгляд да привычку говорить YAGNI и просто реализовывать фичи. Ирония в том, что когда меня зовут в какой-то проект, я вношу то же самое.
Моей жене смешно. Старая шутка про отношения: ваш партнёр говорит вам что-то год за годом, а однажды вы спешите домой с работы, чтобы поделиться новой идеей от незнакомца… той самой идеей, о которой вам все эти годы говорил ваш партнёр.
Я работаю удалённо, так что всё моё парное программирование проходит через видеочат и демонстрацию экрана. Я использую Skype, Lync, Join.me, да всё что угодно. Мы с напарником по очереди проходимся по фичам в нашем органайзере, транслируем экран одного из нас другому, разговариваем и пишем код, продумываем и разрабатываем архитектуру, коммитим в Git, синхронизируемся и меняемся местами.

Так мы можем продержаться до трёх часов, затем уже устаём. Однако, чувство удовлетворённости от совместной работы над проблемой прекрасно.

А ваша программистская жизнь парализуется со временем? Как вы справляетесь с такими проблемами?
Перевод: Scott Hanselman
@a553
карма
51,5
рейтинг 0,1
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (130)

  • +45
    За собой такое давно заметил. Меньше знаешь — крепче спишь )
    • +11
      Давно известно, кстати: "…во многой мудрости много печали; и кто умножает познания, умножает скорбь", – говорил, предположительно, царь Соломон (из книги Екклесиаста 1:17-18).
      • 0
        «Многие знания — многие печали»
      • +2
        Совсем не о программировании, но в тему, как по мне. У Дж. Лондона Волк Ларсен говорил:
        «И в этом его счастье. Он слишком занят жизнью, чтобы думать о ней. Я сделал ошибку, когда впервые
        открыл книгу.»
        • 0
          Смысл жизни открывается только тем, кому не нужно слов (с)
      • 0
        Цитата — отличное название для этой статьи
    • 0
      А я то думал, что просто банально обленился)

      Хотя, когда подходит дедлайн, выясняется, что отлично умею выбрасывать лишнее (если конечно, не использую вариант «Б» — впадание в ступор).
  • +36
    Проблема высвечена очень метко. Как ни странно, о том, что это проблема, я раньше просто не думал. Этим статья и хороша. Однозначно плюс и автору и переводчику.
    • +1
      Та же ерунда. Вот только, не больше, как пару месяцев назад, после очередного размышления взял и резко сам себя оборвал и сделал решение чисто в рамках задачи. Потом повторилось, только оборвать себя получилось раньше. И как-то мне это понравилось.

      Одно боюсь, эта статья — тоже знание, как оно дальше обернётся.
    • +1
      Кстати, о записи в файл очень актуально.
      Вчера писал как раз логгирование для небольшого проекта.
      Первая мысль: 10 минут и закончу. Прошло два часа… И сколько возможных ужасов я себе придумал, которые прилось в итоге решать.
  • +3
    еще это называется «синдром отличника»
    • +7
      «Синдром отличника» — немного другое. Человек тратит огромные усилия, чтобы быть либо впереди всех, либо выше определенного уровня. При нем обычно нет «паралича» действий. А то, что описано выше, именно парализует — ты боишься начать вносить что-то новое.
    • +7
  • +89
    Краткое содержание:
    • –1
      You made my day!))
    • +10
      image
  • +2
    Описание проблемы будто с меня писалось… надеюсь опыт «выхода из кризиса», описанный во второй части поможет решить проблему. Спасибо, что дали мне это понять!
  • +33
    У меня целое кладбище домашних проектов из-за этого. Все они имеют излишне продуманную структуру, с классами, иерархией наследования, кучей интерфейсов, абстракцией на абстракции и шаблонами проектирования. Весь их код относится к взаимодействию между этими абстракциями, но на реализацию полезного функционала, непосредственно реализующего поставленную задачу, уже не было сил. Да и программа получается не гибкой, а совсем наоборот, неповоротливой махиной. Любопытно, что мои относительно работающие проекты (домашние конечно же) писал на новом для себя языке. Лезть сразу в дебри языка страшно, и хотелось только хоть как-нибудь создать прототип.
    В общем, для постройки собачьей конуры вам не нужно целый месяц чертить план и заливать фундамент.
    • +10
      Ну, с другой стороны лично я получаю большое удовольствие от написания личного проекта с очень хорошейтм архитектурой. Иногда это даже самоцель. А одним из таких проектов даже пользуется моя девушка! (разумеется, архитектуры там гораздо больше, чем полезных функций)
      • +3
        Да, мне тоже обычно нравится. Главное, чтобы не кончилась мотивация :)
        • +2
          Вот-вот… Но после очередного AbstractSingletonProxyFactoryBean мотивация заканчивается =(

          Все-таки надо переходить на методологию — «Чик-чик и в продакшен»
    • +2
      Вот для чего нужно много разных языков!
  • +15
    Обычно в описанных случаях я полагаюсь на два принципа:
    1. Сначала делаю, чтобы работало хоть как-то, потом — чтобы работало хорошо. При этом потенциальные проблемы я просто выписываю на листочек, чтобы когда-нибудь потом с ними разобраться (когда они возникнут). Если они так и не возникают — значит, это все бред и ересь, и листочек можно спустить в сортир.
    2. Пытаюсь внести устойчивость к ошибкам туда, где потенциально можно их быстро исправить. Если брать пример из статьи — я просто пишу данные в файл, а вот когда что-то не прочитается, приложение будет пытаться исправлять косяки в данных, задавать какие-то значения по-умолчанию, и т.д.
    • 0
      Как говорится: абсолютно в дырочку! :) Делаю точно также как вы
    • +1
      Сначала делаю, чтобы работало хоть как-то

      Посмотрел я недавно на код 5-летней давности, сделаный по принципу «хоть как то» и понял: Все переписать с нуля.
      • +1
        Ну и правильно, тот код своё уже отработал, позволив переписать «все с нуля».
      • +1
        Есть мнение, что читать код сложнее, чем писать.
        • 0
          Но еще сложнее чем читать код, так это написать код, который легко читать
    • +2
      Полностью согласен. Похожий подход был описан в очень интереной (имхо) статье — Разработка через страдание ( habrahabr.ru/post/155959/ )
    • 0
      я примерно к таким же выводам пришёл с небольшой особенностью.
      1) вначале пишу скелет программы с основным функционалам, все проверки и улучшения записываю на листочек типа «добавить проверку прав доступа при записи в файл».
      2) после окончания работы над скелетом сортирую список в порядке важности начинаю реализовывать по порядку. не всегда доделываю до конца, но по крайней мере на руках уже работающий проект, хоть и не до конца отшлифованный.

      А по поводу разработки архитектуры и тому прочего — собирается совещание и на нем уже обсуждается. фанатизм глобальности поддерживают не все и всё решается самим собой)
    • +3
      А зачем листочек? В самом коде расставлять todo и всё…
      • +1
        … и забыть про них.
        • +4
          Мда? IDE их качественно подсвечивает. Потерять листочек больше шансов.
          Опять же, листочки только у вас, а todo видит любой человек, который работает с кодом.
          • –1
            Подсвечивать-то подсвечивает, но чтобы их увидеть необходимо вспомнить о их существовании. Попросту забудешь что парочка еще осталась где-то там в недрах кода…
            • +3
              В Eclipse, например, есть специальное окно, где выведены все TODO из проекта.
              • 0
                У меня в подобном окне(Web/PHPStorm) обычно сотни todoшек от сторонних либ ака jquery… Хотя не помню, возможно там есть фильтры.
                На данный момент пользуюсь Sublime и Ctrl+Shift+F, а так же все мои todo/fixme выводятся в логе сборки…
          • 0
            Мне, к примеру, тактильно приятнее писать на бумаге, поэтому и всякими степплерами от левенджер обзавёлся и планшетками и ручками разноцветными. Думается как-то легче. А потом в подшиврочку-органайзер.
        • 0
          Если работаю в Notepad++, то пишу «Hack, todo, note», а затем Ctrl+F, очень удобно.
          • +1
            Что только не придкмают, что бы grep и awk не использовать.
      • 0
        Возможно листочек более «гибкий»: приоритеты, цвета/выделение, комментарии, всегда под рукой (для комментариев «под-себя» при решении локальных задач)
        • 0
          К тому же листочков может быть много, и их можно по-хитрому раскладывать и развешивать по доскам согласно различным методологиям agile разработки.
    • +2
      По первому пункту, еще на такой подход часто говорят: Do, do right, do better
      • 0
        Или do never :-)
  • +2
    А я, в добавок к вышеописанному, еще люблю долго пометаться на тему, как переделать только что написанный код, чтобы в будущем он был более поддерживаемым. Иногда тоже очень сильно затягивает процесс. Спасибо за пост!
  • +4
    Автор статьи похоже знает меня лично или как-то залез в мою голову. В любом случае +1 к тем комментам что согласны что это про них. Но в статье прозвучала здравая мысль о напарнике в парном девелопменте. Вот здесь у меня затык, сколько искал для удаленного программирования, но так и не нашел (((. Да и если честно процесс организации такого вида программирования пока дальше Skype не представляю как! Может кто-то уже имеет опыт поиска и использования соответствующих инструментов? Если да, то пусть поделится
    • +1
      Skype позволяет демонстрировать экран, но не печатать напарнику в нём; из того что я знаю, GoToMeeting и TeamViewer позволяют последнее, но оба платные.
      • +3
        TeamViewer бесплатный для частного использования.
        • 0
          Там есть серьёзные ограничения на длительность сессии. Для того, чтобы быстро разобраться в проблеме у юзера и отключиться этого хватает, но не для парного программирования.
      • 0
        Перенес коммент в другую ветку.
        • 0
          В IDEA есть IdeTalk (вроде так) — что-то вроде гибрида аськи с возможностью показывать код.
          У меня запустить не удалось :(
          • 0
            Это обычный Jabber-клиент с поддержкой «макроса», позволяющего отправить ссылку на конкретное место в коде. Этот код должен быть и у второго собеседника.
          • 0
            Запустить не удалось? Это как? Пробовали на самой Идее, или одной из узких типа PhpStorm?
    • 0
      На линуксе возможно удаленно подключаться к работающему сеансу X сервера, правда, точно не знаю как. Что-то там с x11vnc через ssh.
      • 0
        Да, знаю, что там можно и поэтому сейчас штудирую гентушный хендбук в попытках перейти на Linux
        • 0
          Гентушный хендбук — это сурово. Может, для начала что-нибудь попроще? Типа Ubuntu, Debian или какой-нибудь Fedora? Там хотя бы есть гуяшный инсталлятор.
          • –2
            Гентушный хендбук — это сурово.

            habrastorage.org/files/81a/36d/a8a/81a36da8a19c4e4d8d25ca2436ca1e32.jpg

            UPD: извините, не хватает хабракармы для картинок, выложил линк.
          • 0
            Ну а программирование само по себе сурово! Вы только вспомните первые шаги и сколько вопросов. И ничего же! Программируют люди и даже ошибок вида unresolved не боятся! ;) А просто дают по шапке соседу за не залитые файлы ;)
          • 0
            Да ладно, что там сурового. Делаешь все по пунктам и все. Там даже понимать что происходит для успешного завершения процесса не обязательно. Хотя при таком подходе конечно теряется смысл процедуры…
            • +1
              Ну суровость то все-таки есть! ;) К примеру выбор компонентов. Ведь по каждому нужно выбрать один, а если ты не знаком ни с одним, то предстоит по каждому читать мануал и анализировать свои потребности с ограничениями и возможностями каждого. Пока изучаешь можно потерять общее понимание, а куда движемся то? Настройка ядра тоже не простой процесс можно сказать genkernel-у включай по дефолту, а в initramfs включай все что только можно, но это же не создание системы согласно своим потребностям! Пока вот сижу на этапе настройки ядра. Ранее пользовался FreeBSD и она мне кажется более стройной, я открывал GENERIC и удалял не нужные мне драйвера, к примеру raid, usb, сетевые драйвера и др. смотрю в настройку ядра на Linux и понимаю «У меня теперь есть пример как нельзя писать конфиги». Смотрю на initramfs и это тоже не простой процесс для новичка, толи нужен тот или иной компонент на старте, толи нет, толи нужно его вообще как модуль ядра, а может не как модуль и все эти вопросы тоже требуют анализа и четкого понимания что делает ставящий систему, а если он новичок то приходится очень много читать. И это я еще не касаюсь use-флагов, чтобы их настроить надо знать что тебе надо, а ты не знаешь, т.к. опыта использования системы нету! Можно конечно взять флаги от Васи Пупкина, но это же настройка потребностей Васи, а не твоих. Проблема курицы и яйца.Пришел к выводу: пока никаких юз-флагов, потом будет видно что мне надо а что нет
    • 0
      Есть бесплатный UltraVNC.
    • 0
      От платформы зависит. Под Windows есть, помимо скайпа, Microsoft Lync — позволяет делать screen sharing, в т.ч. с передачей управления раб.столом собеседнику.

      В случае *nix — графических средств для screen sharing и передаче контроля над десктопом вроде как нет (известных мне). Тут упоминали удалённый запуск программ и X forwarding — это немного другое: здесь не собеседник видит ваш экран, а вы запускаете графическое приложение на удалённой машине, а окно приложения отображается на вашей.

      Есть классическое решение для текстовой среды — GNU screen, позволяет предоставить свой текстовый терминал другому человеку и дать над ним контроль. Очень не хватает возможности параллельно говорить голосом, как в том же Lync или Skype, но в остальном работает прекрасно. *nix only. Но предположу, что есть порт на Windows, в этом случае решение становится полностью кроссплатформенным.
      • 0
        удалённый запуск программ и X forwarding

        Выше я говорил как раз не про X forwarding, а про удаленное подключение через ssh туннель к уже работающему экземпляру X сервера, под которым залогинен локальный пользователь машины.
        Если интересно, то можно почитать, например, здесь: http://www.umgum.com/xorg-x11vnc
        В результате как раз должен получиться screen sharing. А X forwarding — это когда используется ssh клиент без туннеля, но с опцией -X.
        • 0
          Спасибо, про x11vnc не знал раньше.
          • +12
            В линуксе, как обычно, возможно все, только никто не знает как :)
    • 0
      Попробуйте mikogo. Он бесплатный и кроссплатформенный.
      • 0
        Так он же платный!
        • 0
          Я им пользовался, ничего не заплатив и ничего не взломав.
    • 0
      Некоторое время назад писал об этом (vim/emacs+tmux+ssh).
    • 0
      А вы почитайте другие статьи Хансельмана, он довольно толковый чувак и пишет очень интересные вещи. Можно даже и посмотреть, он много на конференциях выступает.
      • 0
        Это тот что Скотт?
        • 0
          Он самый, который так же автор статьи, и линк на блог которого есть в конце статьи.
  • +3
    В словах автора есть определенная истина. Однако описанные ситуации возникают именно из-за отсутствия анализа требуемого функционала и случаев использования. Опытный кодер пытается сделать свою часть задачи максимально универсально, если его часть находится в отрыве от общего контекста. Отсюда и появляются и корректные блокировки и многопоточность и multicore оптипизация (а вдруг понадобится?) плюс в придачу куча трудноотловимых ошибок. В итоге получается, что джуниор, который этого всего не знает, пишет быстрее и эффективней, чем профессионал.

    Agile для меня эффективен в смысле, что всегда нужно иметь что-то запускающееся. Короткие итерации гораздо лучше, чем длительные «закоды». Парное программирование не пробовал, но полностью против. Чтобы кто-то постоянно стоял над душой, когда хочется спокойно подумать, потестировать пару идей. По-моему лучше метод коротких синхронизаций.
    • 0
      > Опытный кодер пытается сделать свою часть задачи максимально универсально

      Да-да. Навешает фич, потратит неделю на задачу в полчаса, а через две недели этот кусок решат не использовать — на что время ушло.

      Классический пример: нужно сделать окно, выводящее сообщение и кнопку «ок» (в значении «я прочел, спасибо, закройся»). Джуниор пишет просто, опытный прикидывает, что, может код потом будет еще и вопросы задавать («сообщение + кнопки ответов да/нет»), а еще недурно бы выбор иконки на окошке сделать, а еще...". В общем, пишет он свое универсальное окошко долго и упорно, получает комбайн, а в сумме оно даже в проект не входит.

      Так что алгоритм прост: 1) (архитектору) ставить максимально точные задачи и 2) (программеру) выполнять их максимально быстро, как можно проще, и точно в рамках заказанного.
      • +3
        Вот без обид, но у меня иногда сомнение возникает, что «опытный» и «делает свой комбайн там, где можно написать 2 строчки» можно применить в одной фразе. Опытный или сделает максимально просто, или, если ему не хватает данных — задаст дополнительные вопросы.
        • 0
          опытность бывает разного левела )
        • +3
          Опытный кодер задаст огромное число безусловно корректных и необходимых вопросов, ответов на которые он в большинстве случаев так и не дождется. Чтобы ответить на все его вопросы нужно проводить полное исследование предметной области, на которое как правило нет ни средств ни времени. Поэтому опытный кодер, не получив очередной ответ, вполне логично предполагает «худшую» ситуацию и соответственно кодит «с запасом», насилуя код различного рода проверками, синхронизациями и сверхдизайном на все случаи жизни.
      • 0
        Максимально точные задания — это, в том числе, с оценкой перспектив развития/ необходимости поддержки и обоснованием отказа от потенциально возможной крутоты требуемого решения.
  • +3
    Хм… могу предположить что следующим логичным этапом развития должно стать написание библиотеки для решения всех тех проблем который гложут при реализации определенного функционала.

    Ну там, супер мега пупер конфигуратор. сохранятор, загружатор,…
    Хотя правильнее было бы найти уже готовые и изучить его, ну или просто поверить в него.
    • +1
      Поддержу вас.

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

      Все потому что большое количество функционала обернул в некие библиотеки, которые закомитил в гитхаб и при старте нового проекта выкачиваю от туда каркас, с которого начинаю работу.

      При этом в проекте используются как сторонние решения: бутстрап, смарти, jquery само собой, так и своих поделок уже полно.

      У меня другая проблема — внесения каких-то концептуальных изменений в каркасе порой несет изменения в проекте. Т.е. нужно менять код и в уже сделанных проектах. Но если не обновлять на «условно завеошенных» проектах все свои библиотеки и каркас, то можно спать спокойно :)
      • 0
        git submodule вам помогут решить эту проблему.
      • +4
        Советую библиотеки не только закоммитить на Гитхаб, но также и оформить как набор пакетов npm (с перечислением их зависимостей в package.json) и указывать для них версии в формате semver.

        После чего выход новой версии (3.5.0, например) не означает автоматически необходимость обновлять старые проекты, у которых зависимость от старой версии (1.8.4, например) — да и даже когда такая необходимость всё же возникает (например, для употребления новых возможностей), то можно в changelog (а если его нет — то в логах Git или другой системы DVCS; надеюсь, Вы пользуетеся хоть какой-нибудь DVCS, потому что без этого в веборазработке жизнь бывает куда сложнее) можно посмотреть, что именно «ломается» при переходе на новые основные версии (2.0.0 и 3.0.0 в нашем примере) и как к ним приладить существующий код.
        • +4
          Хотя, наверное, речь про DVCS в скобках была излишнею: коль скоро коммитите на GitHub, то тогда, уж конечно, и просто в разработке Git используете, я так надеюсь.
          • 0
            Git использую, про DVCS не слышал. Буду изучать что такое, спасибо за наводку.
            • 0
              Так Git и есть DVCS.
              • 0
                ну я в комменте писал, что в гите все, думал что-то новое :)
                Люди все равно написали много нового для меня, есть что почитать.
            • 0
              DVCS — Distributed version control system.

              Это общее названия для таких систем, как Git.
  • +1
    Ох и знакомо. Сейчас дома пишу небольшую игрушку под iOS, iOS же знаю в совершенстве и дружу с ним со времен 2.2.1, так тоже чуть не начал писать монстра. Потом перешел на чисто процедурный стиль программирования, как у K & R, ну и немножко классов — и вуаля, все понятно!
  • 0
    А кто-нибудь пробовал вместо парного программирования использовать цикл код->рефакторинг->код->рефакторинг таким образом, что пишем код не заморачиваясь, а грядущие и грянувшие архитектурные проблемы выписываем в трекер и решаем в фазе рефакторинга? И, предвосхищая ответ, — что в этой схеме не работает?
    • 0
      Оно как-бы не «вместо» — одно другого не исключает. Можно и парно по этому циклу работать.
      • 0
        Это-то хорошо, но меня интересует именно вопрос работы без парного программирования.
        • +3
          Ну в общем-то, я сам пытаюсь работать по этой схеме. Обычно у меня получается так:
          1. В начале разработки создаются 1-2 версии, которые пишутся с нуля, а затем просто выкидываются. Это позволяет доопределиться с функционалом, архитектурой, используемыми паттернами и т.д.
          2. Далее используется именно цикл код->рефакторинг, причем рефакторинг двух типов — локальный (переделка отдельных функций, классов) и глобальный, сопровождаемый внесением изменений в архитектуру и базовые типы данных.
          3. Если код становится совсем монструозным, цикл прерывается и пишется новая версия с нуля, из старого кода туда переносятся только реализации отдельных функций, алгоритмов, то есть мелкие куски. А архитектура разрабатывается с нуля с учетом опыта предыдущей версии.
  • +2
    Спасибо за статью! Об этом явлении следует вспоминать каждый раз, когда реализация простейшей задумки превращается в нагромождение попыток сделать все в совершенстве. Иногда описанное явление называют также «overengineering».
  • +21
    А у меня кот — напарник. Я ему все рассказываю и показываю, все магическим путем начинает работать, приходят идеи, множество хороших решений. Ему говоришь: «А что если… бла бла бла», он уставится на тебя, а ты «Да точно, ты прав это не проканает ведь бла бла бла».
    • +7
    • +3
      Я как-то бился головой об стенку, не мог найти ошибку в коде. Жена, которая вообще ничего не понимает в программировании, видя мои мучения возьми и брякни: «у тебя ошибка стека в строке 1214». Я вначале завис, во-первых, какой нафиг стек в PHP, потом искал 1214 строку в модуле, в котором было меньше 1000 строк и только потом сообразил, что надо мной нагло издеваются.

      В итоге, кстати, помогло, отвлекся от хождения по кругу и потом махом решил проблему.
  • +14
    На мой взгляд, чем программист более опытен — тем больше у него в запасе качественных и проверенных решений, тем он продуктивней. Стремление довести код до совершенство — это не признак профессионализма, а первый синдром такого понятия как…

    Перфекционизм — в психологии, убеждение, что наилучшего результата можно (или нужно) достичь. В патологической форме — убеждение, что несовершенный результат работы неприемлем. Может быть как «нормальной» характеристикой личности, так и невротическим психическим отклонением.
    • +2
      Да, профессиональный опыт — страшный катализатор перфекционизма.
      • +2
        Только на начальной стадии.

        На этот счёт в 2010 на хабре была хорошая статья Программизм: история одной болезни. Т.е. на самом деле перфекционизмом страдают те, кто таки не эволюционировали в то, что в статье описывается как «Стадия третья. Просветление». Профессионал — это тот, кто делает свою работу быстро и качественно. Всех остальных можно причислять в лучшем случае к «опытным специалистам».
  • 0
    Решение проблемы, посталвенное в топике — сначала решай задачу наиболее простым и легким путем чтобы работало, а уже после того как будет работать делай красиво и хорошо. Во-первых, пока задача уже решена и работает можно многое переосмыслить и прошлое «хорошее» решение уже совсем может не подходить. Во-вторых, такой подход сохраняет энтузиазм, ведь задача уже работает, и есть еще место где развернуться в оптимизации.
  • –9
    По-моему, топик просто про прокрастинацию.
    • +4
      Про перфекционизм, 100%.
      Прокрастинация — это поводы откладывать реализацию. Именно откладывать, а не продумывать, как в топике.
  • +2
    Статья — набор сумбурных мыслей. Я уж думал она про то что написано в заголовке, а она оказалась… ну вобщем ни про что.

    Если говорить про заголовок, то «паралич анализа» происходит лишь от несоответствия знаний умениям. Это означает что человек знает проблемы но не умеет их решать. У того кто умеет решать проблемы этого «паралича» не образуется, так как в его багаже знаний присуствтует и решение.
  • 0
    буду читать комментарии перед отправкой
  • +4
    С хорошим напарником получается делать работы в три раза больше, а не в два
    и тут же
    Они явно пишут код лучше меня
    Ну так понятно, есть еще вариант не мешать людям работать ;)
  • +2
    Из-за такого перфекциониста начальника уволился однажды.

    Чтобы избегать таких ситуаций самому, обычно стараюсь работать с двухнедельными спринтами. Каждую вторую пятницу в альфа должна уходить новая версия, в которой есть хотя бы что-то новое, а не один сплошной рефакторинг и архитектурные изменения. У каждого спринта есть одпределённая цель с определённым функционалом. Если команда успевает допилить раньше, тогда занимаемся улучшениями и переписываниями с нуля.
    • 0
      А если регулярно не успевает допилить — то рефакторинг не наступает никогда?
      • 0
        Тогда стоит пересмотреть срок спринта. Увеличить его, или более реалистично ставить задачи.
  • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    У меня такой проблемы нет, т.к. во мне сохранилось что-то панковское, что позволяет просто наплевать на маловероятные проблемы.

    Если всё-таки что-то появляется цепкое, то я просто нахожу себе более интересную задачу (слава богу с идеями дефицита нет), отвлекаюсь, а когда возвращаюсь, уже как-то проще не делать лишней работы.
  • 0
    Наверно любой программист по ходу профессионального роста сталкивается с такой проблемой. Мне помогают две вещи:
    1. Задачи в трекер кидаются обязательно с приоритетом. В простейшем случае элементарным драг-н-дропом самые важные на текущий момент задачи переносятся наверх и брать на реализацию можно только самую верхнюю (или одну из первых N задач).
    2. Все задачи больше чем на пол дня (можно поменять на 2-3 часа или увеличить на день, но не более) разбиваются рекурсивно на подзадачи. Т. е. для сложных тасков мы выстраиваем иерархию из более простых задач, которые можно сделать за короткое время.
    • +2
      Пункт 2 может уйти в бесконечную рекурсию — когда на то, чтобы разбить задачу на подзадачи, требуется больше, чем полдня (да и после этого правильность разбиения не гарантируется).
      • 0
        Если на то, чтобы просто разбить (вроде бы изначально и так достаточно небольшую, но не вписывающуюся в ограничение «на пол дня») задачу на подзадачи требуется более чем пол дня — значит она скорее всего значительно больше и сложнее, чем казалось на первый взгляд, и очень хорошо, что этот факт всплыл до того, как была написана хоть одна строка кода.
  • 0
    AFAIK, есть устоявшееся название "аналитический паралич".
  • +2
    Я столкнулся с такой проблемой в 10-том классе. Летом между 9 и 10 классами я познакомился с Delphi и рисованием на canvas. За 1 месяц знакомства с Delphi я написал маленькую rpg-игру. За последующие полгода я узнал гораздо больше, и когда весной сгорел жесткий диск и я решил заново написать свою rpg, я не смог. Потратив 2 месяца на движок, анимацию, оптимизацию игры я так и не смог написать той же самой.

    А первая версия игры была вообще смешкая — графика поклеточная, трехслойная (карта+объекты+туман войны). Я не умел создавать простые классы, я все хранил в уродских многмерных массивах.
    • 0
      Послушай постмортемы Джонатана Блоу об игре Braid. Интересно будет. Там и о массивах тоже.
  • +1
    Почему-то никто не написал этого в комментариях, так что напишу я. Проблема, описанная в статье, решается в подавляющем большинстве случаев юнит-тестами (особенно TDD). Ее причина — просто недостаток обратной связи. Эту обратную связь могут дать тесты (или, если есть адекватный человек рядом, — этот человек). Вот так просто, правда.
    • 0
      Применяю, TDD. Оно не спасает. Вернее не от всего, но частично проблему, согласен, снимает
      • +1
        Если TDD не спасает, это может быть признаком того, что зашкаливает ощущение «хрупкости» конструкции. В таком случае помогают, наоборот, интеграционно-дымовые тесты (я особенно люблю phpt, причем даже когда пишу на c++ или python: они получаются грязные-грязные, кривые-кривые, копипастные-копипастные, но зато их можно фигачить по 10-20 штук в час, и они дают замечательно приятное ощущение устойчивости).
        • 0
          Простите, только что увидел Ваш комментарий могли бы, но не могли бы подробнее раскрыть мысль?
    • +1
      Забавно, а ведь и правда. Описать задачу тестами — то же самое, что и рассказать кому-то другому о том, как она работает. Правда, для этого лучше не мелкие юнит-тесты, а покрупнее, спецификации рабочего процесса.

      Наверное, это не столько обратная связь, сколько отсеивание при объяснении или тестировании важных вещей от второстепенной шелухи.
    • 0
      А по-моему, TDD сильно помогает, но не за счет обратной связи, а за счет важного приниципа TDD — сначала надо быстро сделать хоть как-то, а только потом можно заниматься улучшательством.
  • +1
    Вот уж действительно «горе от ума»
  • НЛО прилетело и опубликовало эту надпись здесь
  • +2
    О! Отличная статья, чтобы успокоить себя и других убедить, что я не просто тормоз
  • +3
    я провожу больше времени перетасовывая идеи, а не реальзуя их.

    Ну то есть человек вырос из обычного программиста в архитектора/лидера разработчиков. Почему бы не перевестись на соответствующую должность и продолжать делать то, что лучше получается?
  • 0
    :)
    Я и не задумывался. Но как только я потерял сохранённый файл из-за каких-то глюков, я, прежде чем начать править глючьё, сделал, чтобы файл сохранялся под другим именем и лишь потом переименовывался. Чтобы был ещё один барьер против «всякого такого».
  • 0
    Надо уметь контролировать свой перфекционизм.
  • –1
    Я очень быстро разобрался с такими мыслями. Код я пишу так:

    1. Подумал о правах доступа? — Пишу в комментарии: «Файлы создаются с правами доступа по умолчанию. Желающие изменить права доступа на особые призываются сделать это после вызова данного метода».

    2. Подумал о занятии файла другим приложением? — Пишу в комментарии: «Класс рассчитывает на то, что другие приложения не будут открывать указанный файл во время выполнения данного метода».

    3. Подумал о многопоточности? — Пишу: «Внимание! Класс не thread-safe».

    4. Пришла мысль об атомарных операциях? — См. пункт 3.

    5. О фреймворках? — Завожу тикет в джире на будущий рефакторинг.

    6. О разных файловых системах за меня подумали разработчики виртуальной машины Java.

    7. О количестве файлов в директории пусть думают сисадмины.

    8. О предсказуемых названиях временных файлов я уже заранее подумал, поэтому у меня есть проверенные заготовки.

    9. Появились сомнения качестве моего ГСПЧ? — // TODO использовать безоспасный Random.

    10. Нормальная документация? Да вот же она. Уже готова.

    Данная проблема называется «увеличения скоупа работ». Это стандартный проектный риск. Существует несколько способов управления данным риском. То, что я описал, это самый универсальный метод, остальные желательно согласовывать с заказчиком.
    • 0
      То, что Вы описали — это закапывание проблем.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.