Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 130
За собой такое давно заметил. Меньше знаешь — крепче спишь )
А я то думал, что просто банально обленился)
Хотя, когда подходит дедлайн, выясняется, что отлично умею выбрасывать лишнее (если конечно, не использую вариант «Б» — впадание в ступор).
Хотя, когда подходит дедлайн, выясняется, что отлично умею выбрасывать лишнее (если конечно, не использую вариант «Б» — впадание в ступор).
Проблема высвечена очень метко. Как ни странно, о том, что это проблема, я раньше просто не думал. Этим статья и хороша. Однозначно плюс и автору и переводчику.
Та же ерунда. Вот только, не больше, как пару месяцев назад, после очередного размышления взял и резко сам себя оборвал и сделал решение чисто в рамках задачи. Потом повторилось, только оборвать себя получилось раньше. И как-то мне это понравилось.
Одно боюсь, эта статья — тоже знание, как оно дальше обернётся.
Одно боюсь, эта статья — тоже знание, как оно дальше обернётся.
Кстати, о записи в файл очень актуально.
Вчера писал как раз логгирование для небольшого проекта.
Первая мысль: 10 минут и закончу. Прошло два часа… И сколько возможных ужасов я себе придумал, которые прилось в итоге решать.
Вчера писал как раз логгирование для небольшого проекта.
Первая мысль: 10 минут и закончу. Прошло два часа… И сколько возможных ужасов я себе придумал, которые прилось в итоге решать.
еще это называется «синдром отличника»
«Синдром отличника» — немного другое. Человек тратит огромные усилия, чтобы быть либо впереди всех, либо выше определенного уровня. При нем обычно нет «паралича» действий. А то, что описано выше, именно парализует — ты боишься начать вносить что-то новое.
Это Перфекционизм
Краткое содержание:
Описание проблемы будто с меня писалось… надеюсь опыт «выхода из кризиса», описанный во второй части поможет решить проблему. Спасибо, что дали мне это понять!
У меня целое кладбище домашних проектов из-за этого. Все они имеют излишне продуманную структуру, с классами, иерархией наследования, кучей интерфейсов, абстракцией на абстракции и шаблонами проектирования. Весь их код относится к взаимодействию между этими абстракциями, но на реализацию полезного функционала, непосредственно реализующего поставленную задачу, уже не было сил. Да и программа получается не гибкой, а совсем наоборот, неповоротливой махиной. Любопытно, что мои относительно работающие проекты (домашние конечно же) писал на новом для себя языке. Лезть сразу в дебри языка страшно, и хотелось только хоть как-нибудь создать прототип.
В общем, для постройки собачьей конуры вам не нужно целый месяц чертить план и заливать фундамент.
В общем, для постройки собачьей конуры вам не нужно целый месяц чертить план и заливать фундамент.
Ну, с другой стороны лично я получаю большое удовольствие от написания личного проекта с очень хорошейтм архитектурой. Иногда это даже самоцель. А одним из таких проектов даже пользуется моя девушка! (разумеется, архитектуры там гораздо больше, чем полезных функций)
Да, мне тоже обычно нравится. Главное, чтобы не кончилась мотивация :)
Вот-вот… Но после очередного AbstractSingletonProxyFactoryBean мотивация заканчивается =(
Все-таки надо переходить на методологию — «Чик-чик и в продакшен»
Все-таки надо переходить на методологию — «Чик-чик и в продакшен»
Вот для чего нужно много разных языков!
Обычно в описанных случаях я полагаюсь на два принципа:
1. Сначала делаю, чтобы работало хоть как-то, потом — чтобы работало хорошо. При этом потенциальные проблемы я просто выписываю на листочек, чтобы когда-нибудь потом с ними разобраться (когда они возникнут). Если они так и не возникают — значит, это все бред и ересь, и листочек можно спустить в сортир.
2. Пытаюсь внести устойчивость к ошибкам туда, где потенциально можно их быстро исправить. Если брать пример из статьи — я просто пишу данные в файл, а вот когда что-то не прочитается, приложение будет пытаться исправлять косяки в данных, задавать какие-то значения по-умолчанию, и т.д.
1. Сначала делаю, чтобы работало хоть как-то, потом — чтобы работало хорошо. При этом потенциальные проблемы я просто выписываю на листочек, чтобы когда-нибудь потом с ними разобраться (когда они возникнут). Если они так и не возникают — значит, это все бред и ересь, и листочек можно спустить в сортир.
2. Пытаюсь внести устойчивость к ошибкам туда, где потенциально можно их быстро исправить. Если брать пример из статьи — я просто пишу данные в файл, а вот когда что-то не прочитается, приложение будет пытаться исправлять косяки в данных, задавать какие-то значения по-умолчанию, и т.д.
Как говорится: абсолютно в дырочку! :) Делаю точно также как вы
Сначала делаю, чтобы работало хоть как-то
Посмотрел я недавно на код 5-летней давности, сделаный по принципу «хоть как то» и понял: Все переписать с нуля.
Ну и правильно, тот код своё уже отработал, позволив переписать «все с нуля».
Есть мнение, что читать код сложнее, чем писать.
я примерно к таким же выводам пришёл с небольшой особенностью.
1) вначале пишу скелет программы с основным функционалам, все проверки и улучшения записываю на листочек типа «добавить проверку прав доступа при записи в файл».
2) после окончания работы над скелетом сортирую список в порядке важности начинаю реализовывать по порядку. не всегда доделываю до конца, но по крайней мере на руках уже работающий проект, хоть и не до конца отшлифованный.
А по поводу разработки архитектуры и тому прочего — собирается совещание и на нем уже обсуждается. фанатизм глобальности поддерживают не все и всё решается самим собой)
1) вначале пишу скелет программы с основным функционалам, все проверки и улучшения записываю на листочек типа «добавить проверку прав доступа при записи в файл».
2) после окончания работы над скелетом сортирую список в порядке важности начинаю реализовывать по порядку. не всегда доделываю до конца, но по крайней мере на руках уже работающий проект, хоть и не до конца отшлифованный.
А по поводу разработки архитектуры и тому прочего — собирается совещание и на нем уже обсуждается. фанатизм глобальности поддерживают не все и всё решается самим собой)
А зачем листочек? В самом коде расставлять todo и всё…
… и забыть про них.
Мда? IDE их качественно подсвечивает. Потерять листочек больше шансов.
Опять же, листочки только у вас, а todo видит любой человек, который работает с кодом.
Опять же, листочки только у вас, а todo видит любой человек, который работает с кодом.
Подсвечивать-то подсвечивает, но чтобы их увидеть необходимо вспомнить о их существовании. Попросту забудешь что парочка еще осталась где-то там в недрах кода…
Мне, к примеру, тактильно приятнее писать на бумаге, поэтому и всякими степплерами от левенджер обзавёлся и планшетками и ручками разноцветными. Думается как-то легче. А потом в подшиврочку-органайзер.
Если работаю в Notepad++, то пишу «Hack, todo, note», а затем Ctrl+F, очень удобно.
Возможно листочек более «гибкий»: приоритеты, цвета/выделение, комментарии, всегда под рукой (для комментариев «под-себя» при решении локальных задач)
По первому пункту, еще на такой подход часто говорят: Do, do right, do better
А я, в добавок к вышеописанному, еще люблю долго пометаться на тему, как переделать только что написанный код, чтобы в будущем он был более поддерживаемым. Иногда тоже очень сильно затягивает процесс. Спасибо за пост!
Автор статьи похоже знает меня лично или как-то залез в мою голову. В любом случае +1 к тем комментам что согласны что это про них. Но в статье прозвучала здравая мысль о напарнике в парном девелопменте. Вот здесь у меня затык, сколько искал для удаленного программирования, но так и не нашел (((. Да и если честно процесс организации такого вида программирования пока дальше Skype не представляю как! Может кто-то уже имеет опыт поиска и использования соответствующих инструментов? Если да, то пусть поделится
Skype позволяет демонстрировать экран, но не печатать напарнику в нём; из того что я знаю, GoToMeeting и TeamViewer позволяют последнее, но оба платные.
На линуксе возможно удаленно подключаться к работающему сеансу X сервера, правда, точно не знаю как. Что-то там с x11vnc через ssh.
Да, знаю, что там можно и поэтому сейчас штудирую гентушный хендбук в попытках перейти на Linux
Гентушный хендбук — это сурово. Может, для начала что-нибудь попроще? Типа Ubuntu, Debian или какой-нибудь Fedora? Там хотя бы есть гуяшный инсталлятор.
Гентушный хендбук — это сурово.
habrastorage.org/files/81a/36d/a8a/81a36da8a19c4e4d8d25ca2436ca1e32.jpg
UPD: извините, не хватает хабракармы для картинок, выложил линк.
habrastorage.org/files/81a/36d/a8a/81a36da8a19c4e4d8d25ca2436ca1e32.jpg
UPD: извините, не хватает хабракармы для картинок, выложил линк.
Ну а программирование само по себе сурово! Вы только вспомните первые шаги и сколько вопросов. И ничего же! Программируют люди и даже ошибок вида unresolved не боятся! ;) А просто дают по шапке соседу за не залитые файлы ;)
Да ладно, что там сурового. Делаешь все по пунктам и все. Там даже понимать что происходит для успешного завершения процесса не обязательно. Хотя при таком подходе конечно теряется смысл процедуры…
Ну суровость то все-таки есть! ;) К примеру выбор компонентов. Ведь по каждому нужно выбрать один, а если ты не знаком ни с одним, то предстоит по каждому читать мануал и анализировать свои потребности с ограничениями и возможностями каждого. Пока изучаешь можно потерять общее понимание, а куда движемся то? Настройка ядра тоже не простой процесс можно сказать genkernel-у включай по дефолту, а в initramfs включай все что только можно, но это же не создание системы согласно своим потребностям! Пока вот сижу на этапе настройки ядра. Ранее пользовался FreeBSD и она мне кажется более стройной, я открывал GENERIC и удалял не нужные мне драйвера, к примеру raid, usb, сетевые драйвера и др. смотрю в настройку ядра на Linux и понимаю «У меня теперь есть пример как нельзя писать конфиги». Смотрю на initramfs и это тоже не простой процесс для новичка, толи нужен тот или иной компонент на старте, толи нет, толи нужно его вообще как модуль ядра, а может не как модуль и все эти вопросы тоже требуют анализа и четкого понимания что делает ставящий систему, а если он новичок то приходится очень много читать. И это я еще не касаюсь use-флагов, чтобы их настроить надо знать что тебе надо, а ты не знаешь, т.к. опыта использования системы нету! Можно конечно взять флаги от Васи Пупкина, но это же настройка потребностей Васи, а не твоих. Проблема курицы и яйца.Пришел к выводу: пока никаких юз-флагов, потом будет видно что мне надо а что нет
Есть бесплатный UltraVNC.
От платформы зависит. Под Windows есть, помимо скайпа, Microsoft Lync — позволяет делать screen sharing, в т.ч. с передачей управления раб.столом собеседнику.
В случае *nix — графических средств для screen sharing и передаче контроля над десктопом вроде как нет (известных мне). Тут упоминали удалённый запуск программ и X forwarding — это немного другое: здесь не собеседник видит ваш экран, а вы запускаете графическое приложение на удалённой машине, а окно приложения отображается на вашей.
Есть классическое решение для текстовой среды — GNU screen, позволяет предоставить свой текстовый терминал другому человеку и дать над ним контроль. Очень не хватает возможности параллельно говорить голосом, как в том же Lync или Skype, но в остальном работает прекрасно. *nix only. Но предположу, что есть порт на Windows, в этом случае решение становится полностью кроссплатформенным.
В случае *nix — графических средств для screen sharing и передаче контроля над десктопом вроде как нет (известных мне). Тут упоминали удалённый запуск программ и X forwarding — это немного другое: здесь не собеседник видит ваш экран, а вы запускаете графическое приложение на удалённой машине, а окно приложения отображается на вашей.
Есть классическое решение для текстовой среды — GNU screen, позволяет предоставить свой текстовый терминал другому человеку и дать над ним контроль. Очень не хватает возможности параллельно говорить голосом, как в том же Lync или Skype, но в остальном работает прекрасно. *nix only. Но предположу, что есть порт на Windows, в этом случае решение становится полностью кроссплатформенным.
удалённый запуск программ и X forwarding
Выше я говорил как раз не про X forwarding, а про удаленное подключение через ssh туннель к уже работающему экземпляру X сервера, под которым залогинен локальный пользователь машины.
Если интересно, то можно почитать, например, здесь: http://www.umgum.com/xorg-x11vnc
В результате как раз должен получиться screen sharing. А X forwarding — это когда используется ssh клиент без туннеля, но с опцией -X.
Попробуйте mikogo. Он бесплатный и кроссплатформенный.
Некоторое время назад писал об этом (vim/emacs+tmux+ssh).
А вы почитайте другие статьи Хансельмана, он довольно толковый чувак и пишет очень интересные вещи. Можно даже и посмотреть, он много на конференциях выступает.
В словах автора есть определенная истина. Однако описанные ситуации возникают именно из-за отсутствия анализа требуемого функционала и случаев использования. Опытный кодер пытается сделать свою часть задачи максимально универсально, если его часть находится в отрыве от общего контекста. Отсюда и появляются и корректные блокировки и многопоточность и multicore оптипизация (а вдруг понадобится?) плюс в придачу куча трудноотловимых ошибок. В итоге получается, что джуниор, который этого всего не знает, пишет быстрее и эффективней, чем профессионал.
Agile для меня эффективен в смысле, что всегда нужно иметь что-то запускающееся. Короткие итерации гораздо лучше, чем длительные «закоды». Парное программирование не пробовал, но полностью против. Чтобы кто-то постоянно стоял над душой, когда хочется спокойно подумать, потестировать пару идей. По-моему лучше метод коротких синхронизаций.
Agile для меня эффективен в смысле, что всегда нужно иметь что-то запускающееся. Короткие итерации гораздо лучше, чем длительные «закоды». Парное программирование не пробовал, но полностью против. Чтобы кто-то постоянно стоял над душой, когда хочется спокойно подумать, потестировать пару идей. По-моему лучше метод коротких синхронизаций.
> Опытный кодер пытается сделать свою часть задачи максимально универсально
Да-да. Навешает фич, потратит неделю на задачу в полчаса, а через две недели этот кусок решат не использовать — на что время ушло.
Классический пример: нужно сделать окно, выводящее сообщение и кнопку «ок» (в значении «я прочел, спасибо, закройся»). Джуниор пишет просто, опытный прикидывает, что, может код потом будет еще и вопросы задавать («сообщение + кнопки ответов да/нет»), а еще недурно бы выбор иконки на окошке сделать, а еще...". В общем, пишет он свое универсальное окошко долго и упорно, получает комбайн, а в сумме оно даже в проект не входит.
Так что алгоритм прост: 1) (архитектору) ставить максимально точные задачи и 2) (программеру) выполнять их максимально быстро, как можно проще, и точно в рамках заказанного.
Да-да. Навешает фич, потратит неделю на задачу в полчаса, а через две недели этот кусок решат не использовать — на что время ушло.
Классический пример: нужно сделать окно, выводящее сообщение и кнопку «ок» (в значении «я прочел, спасибо, закройся»). Джуниор пишет просто, опытный прикидывает, что, может код потом будет еще и вопросы задавать («сообщение + кнопки ответов да/нет»), а еще недурно бы выбор иконки на окошке сделать, а еще...". В общем, пишет он свое универсальное окошко долго и упорно, получает комбайн, а в сумме оно даже в проект не входит.
Так что алгоритм прост: 1) (архитектору) ставить максимально точные задачи и 2) (программеру) выполнять их максимально быстро, как можно проще, и точно в рамках заказанного.
Вот без обид, но у меня иногда сомнение возникает, что «опытный» и «делает свой комбайн там, где можно написать 2 строчки» можно применить в одной фразе. Опытный или сделает максимально просто, или, если ему не хватает данных — задаст дополнительные вопросы.
опытность бывает разного левела )
Опытный кодер задаст огромное число безусловно корректных и необходимых вопросов, ответов на которые он в большинстве случаев так и не дождется. Чтобы ответить на все его вопросы нужно проводить полное исследование предметной области, на которое как правило нет ни средств ни времени. Поэтому опытный кодер, не получив очередной ответ, вполне логично предполагает «худшую» ситуацию и соответственно кодит «с запасом», насилуя код различного рода проверками, синхронизациями и сверхдизайном на все случаи жизни.
Максимально точные задания — это, в том числе, с оценкой перспектив развития/ необходимости поддержки и обоснованием отказа от потенциально возможной крутоты требуемого решения.
Хм… могу предположить что следующим логичным этапом развития должно стать написание библиотеки для решения всех тех проблем который гложут при реализации определенного функционала.
Ну там, супер мега пупер конфигуратор. сохранятор, загружатор,…
Хотя правильнее было бы найти уже готовые и изучить его, ну или просто поверить в него.
Ну там, супер мега пупер конфигуратор. сохранятор, загружатор,…
Хотя правильнее было бы найти уже готовые и изучить его, ну или просто поверить в него.
Поддержу вас.
Из моего опыта: раньше я успевал делать только мини-сайты за день два, теперь успеваю сделать сайт с логином, авторизацией, комментариями, разными страницами, новостями и акциями если нужны, загрузками фотографий, удобной админкой для всего этого и прочими прелестями.
Все потому что большое количество функционала обернул в некие библиотеки, которые закомитил в гитхаб и при старте нового проекта выкачиваю от туда каркас, с которого начинаю работу.
При этом в проекте используются как сторонние решения: бутстрап, смарти, jquery само собой, так и своих поделок уже полно.
У меня другая проблема — внесения каких-то концептуальных изменений в каркасе порой несет изменения в проекте. Т.е. нужно менять код и в уже сделанных проектах. Но если не обновлять на «условно завеошенных» проектах все свои библиотеки и каркас, то можно спать спокойно :)
Из моего опыта: раньше я успевал делать только мини-сайты за день два, теперь успеваю сделать сайт с логином, авторизацией, комментариями, разными страницами, новостями и акциями если нужны, загрузками фотографий, удобной админкой для всего этого и прочими прелестями.
Все потому что большое количество функционала обернул в некие библиотеки, которые закомитил в гитхаб и при старте нового проекта выкачиваю от туда каркас, с которого начинаю работу.
При этом в проекте используются как сторонние решения: бутстрап, смарти, jquery само собой, так и своих поделок уже полно.
У меня другая проблема — внесения каких-то концептуальных изменений в каркасе порой несет изменения в проекте. Т.е. нужно менять код и в уже сделанных проектах. Но если не обновлять на «условно завеошенных» проектах все свои библиотеки и каркас, то можно спать спокойно :)
git submodule вам помогут решить эту проблему.
Советую библиотеки не только закоммитить на Гитхаб, но также и оформить как набор пакетов npm (с перечислением их зависимостей в package.json) и указывать для них версии в формате semver.
После чего выход новой версии (3.5.0, например) не означает автоматически необходимость обновлять старые проекты, у которых зависимость от старой версии (1.8.4,например) — да и даже когда такая необходимость всё же возникает (например, для употребления новых возможностей), то можно в changelog (а если его нет — то в логах Git или другой системы DVCS; надеюсь, Вы пользуетеся хоть какой-нибудь DVCS, потому что без этого в веборазработке жизнь бывает куда сложнее) можно посмотреть, что именно «ломается» при переходе на новые основные версии (2.0.0 и 3.0.0 в нашем примере) и как к ним приладить существующий код.
После чего выход новой версии (3.5.0, например) не означает автоматически необходимость обновлять старые проекты, у которых зависимость от старой версии (1.8.4,
Ох и знакомо. Сейчас дома пишу небольшую игрушку под iOS, iOS же знаю в совершенстве и дружу с ним со времен 2.2.1, так тоже чуть не начал писать монстра. Потом перешел на чисто процедурный стиль программирования, как у K & R, ну и немножко классов — и вуаля, все понятно!
А кто-нибудь пробовал вместо парного программирования использовать цикл код->рефакторинг->код->рефакторинг таким образом, что пишем код не заморачиваясь, а грядущие и грянувшие архитектурные проблемы выписываем в трекер и решаем в фазе рефакторинга? И, предвосхищая ответ, — что в этой схеме не работает?
Оно как-бы не «вместо» — одно другого не исключает. Можно и парно по этому циклу работать.
Это-то хорошо, но меня интересует именно вопрос работы без парного программирования.
Ну в общем-то, я сам пытаюсь работать по этой схеме. Обычно у меня получается так:
1. В начале разработки создаются 1-2 версии, которые пишутся с нуля, а затем просто выкидываются. Это позволяет доопределиться с функционалом, архитектурой, используемыми паттернами и т.д.
2. Далее используется именно цикл код->рефакторинг, причем рефакторинг двух типов — локальный (переделка отдельных функций, классов) и глобальный, сопровождаемый внесением изменений в архитектуру и базовые типы данных.
3. Если код становится совсем монструозным, цикл прерывается и пишется новая версия с нуля, из старого кода туда переносятся только реализации отдельных функций, алгоритмов, то есть мелкие куски. А архитектура разрабатывается с нуля с учетом опыта предыдущей версии.
1. В начале разработки создаются 1-2 версии, которые пишутся с нуля, а затем просто выкидываются. Это позволяет доопределиться с функционалом, архитектурой, используемыми паттернами и т.д.
2. Далее используется именно цикл код->рефакторинг, причем рефакторинг двух типов — локальный (переделка отдельных функций, классов) и глобальный, сопровождаемый внесением изменений в архитектуру и базовые типы данных.
3. Если код становится совсем монструозным, цикл прерывается и пишется новая версия с нуля, из старого кода туда переносятся только реализации отдельных функций, алгоритмов, то есть мелкие куски. А архитектура разрабатывается с нуля с учетом опыта предыдущей версии.
Спасибо за статью! Об этом явлении следует вспоминать каждый раз, когда реализация простейшей задумки превращается в нагромождение попыток сделать все в совершенстве. Иногда описанное явление называют также «overengineering».
А у меня кот — напарник. Я ему все рассказываю и показываю, все магическим путем начинает работать, приходят идеи, множество хороших решений. Ему говоришь: «А что если… бла бла бла», он уставится на тебя, а ты «Да точно, ты прав это не проканает ведь бла бла бла».
Я как-то бился головой об стенку, не мог найти ошибку в коде. Жена, которая вообще ничего не понимает в программировании, видя мои мучения возьми и брякни: «у тебя ошибка стека в строке 1214». Я вначале завис, во-первых, какой нафиг стек в PHP, потом искал 1214 строку в модуле, в котором было меньше 1000 строк и только потом сообразил, что надо мной нагло издеваются.
В итоге, кстати, помогло, отвлекся от хождения по кругу и потом махом решил проблему.
В итоге, кстати, помогло, отвлекся от хождения по кругу и потом махом решил проблему.
На мой взгляд, чем программист более опытен — тем больше у него в запасе качественных и проверенных решений, тем он продуктивней. Стремление довести код до совершенство — это не признак профессионализма, а первый синдром такого понятия как…
Перфекционизм — в психологии, убеждение, что наилучшего результата можно (или нужно) достичь. В патологической форме — убеждение, что несовершенный результат работы неприемлем. Может быть как «нормальной» характеристикой личности, так и невротическим психическим отклонением.
Перфекционизм — в психологии, убеждение, что наилучшего результата можно (или нужно) достичь. В патологической форме — убеждение, что несовершенный результат работы неприемлем. Может быть как «нормальной» характеристикой личности, так и невротическим психическим отклонением.
Да, профессиональный опыт — страшный катализатор перфекционизма.
Только на начальной стадии.
На этот счёт в 2010 на хабре была хорошая статья Программизм: история одной болезни. Т.е. на самом деле перфекционизмом страдают те, кто таки не эволюционировали в то, что в статье описывается как «Стадия третья. Просветление». Профессионал — это тот, кто делает свою работу быстро и качественно. Всех остальных можно причислять в лучшем случае к «опытным специалистам».
На этот счёт в 2010 на хабре была хорошая статья Программизм: история одной болезни. Т.е. на самом деле перфекционизмом страдают те, кто таки не эволюционировали в то, что в статье описывается как «Стадия третья. Просветление». Профессионал — это тот, кто делает свою работу быстро и качественно. Всех остальных можно причислять в лучшем случае к «опытным специалистам».
Решение проблемы, посталвенное в топике — сначала решай задачу наиболее простым и легким путем чтобы работало, а уже после того как будет работать делай красиво и хорошо. Во-первых, пока задача уже решена и работает можно многое переосмыслить и прошлое «хорошее» решение уже совсем может не подходить. Во-вторых, такой подход сохраняет энтузиазм, ведь задача уже работает, и есть еще место где развернуться в оптимизации.
По-моему, топик просто про прокрастинацию.
Статья — набор сумбурных мыслей. Я уж думал она про то что написано в заголовке, а она оказалась… ну вобщем ни про что.
Если говорить про заголовок, то «паралич анализа» происходит лишь от несоответствия знаний умениям. Это означает что человек знает проблемы но не умеет их решать. У того кто умеет решать проблемы этого «паралича» не образуется, так как в его багаже знаний присуствтует и решение.
Если говорить про заголовок, то «паралич анализа» происходит лишь от несоответствия знаний умениям. Это означает что человек знает проблемы но не умеет их решать. У того кто умеет решать проблемы этого «паралича» не образуется, так как в его багаже знаний присуствтует и решение.
буду читать комментарии перед отправкой
С хорошим напарником получается делать работы в три раза больше, а не в дваи тут же
Они явно пишут код лучше меняНу так понятно, есть еще вариант не мешать людям работать ;)
Из-за такого перфекциониста начальника уволился однажды.
Чтобы избегать таких ситуаций самому, обычно стараюсь работать с двухнедельными спринтами. Каждую вторую пятницу в альфа должна уходить новая версия, в которой есть хотя бы что-то новое, а не один сплошной рефакторинг и архитектурные изменения. У каждого спринта есть одпределённая цель с определённым функционалом. Если команда успевает допилить раньше, тогда занимаемся улучшениями и переписываниями с нуля.
Чтобы избегать таких ситуаций самому, обычно стараюсь работать с двухнедельными спринтами. Каждую вторую пятницу в альфа должна уходить новая версия, в которой есть хотя бы что-то новое, а не один сплошной рефакторинг и архитектурные изменения. У каждого спринта есть одпределённая цель с определённым функционалом. Если команда успевает допилить раньше, тогда занимаемся улучшениями и переписываниями с нуля.
У меня такой проблемы нет, т.к. во мне сохранилось что-то панковское, что позволяет просто наплевать на маловероятные проблемы.
Если всё-таки что-то появляется цепкое, то я просто нахожу себе более интересную задачу (слава богу с идеями дефицита нет), отвлекаюсь, а когда возвращаюсь, уже как-то проще не делать лишней работы.
Если всё-таки что-то появляется цепкое, то я просто нахожу себе более интересную задачу (слава богу с идеями дефицита нет), отвлекаюсь, а когда возвращаюсь, уже как-то проще не делать лишней работы.
Наверно любой программист по ходу профессионального роста сталкивается с такой проблемой. Мне помогают две вещи:
1. Задачи в трекер кидаются обязательно с приоритетом. В простейшем случае элементарным драг-н-дропом самые важные на текущий момент задачи переносятся наверх и брать на реализацию можно только самую верхнюю (или одну из первых N задач).
2. Все задачи больше чем на пол дня (можно поменять на 2-3 часа или увеличить на день, но не более) разбиваются рекурсивно на подзадачи. Т. е. для сложных тасков мы выстраиваем иерархию из более простых задач, которые можно сделать за короткое время.
1. Задачи в трекер кидаются обязательно с приоритетом. В простейшем случае элементарным драг-н-дропом самые важные на текущий момент задачи переносятся наверх и брать на реализацию можно только самую верхнюю (или одну из первых N задач).
2. Все задачи больше чем на пол дня (можно поменять на 2-3 часа или увеличить на день, но не более) разбиваются рекурсивно на подзадачи. Т. е. для сложных тасков мы выстраиваем иерархию из более простых задач, которые можно сделать за короткое время.
Пункт 2 может уйти в бесконечную рекурсию — когда на то, чтобы разбить задачу на подзадачи, требуется больше, чем полдня (да и после этого правильность разбиения не гарантируется).
Если на то, чтобы просто разбить (вроде бы изначально и так достаточно небольшую, но не вписывающуюся в ограничение «на пол дня») задачу на подзадачи требуется более чем пол дня — значит она скорее всего значительно больше и сложнее, чем казалось на первый взгляд, и очень хорошо, что этот факт всплыл до того, как была написана хоть одна строка кода.
AFAIK, есть устоявшееся название "аналитический паралич".
Я столкнулся с такой проблемой в 10-том классе. Летом между 9 и 10 классами я познакомился с Delphi и рисованием на canvas. За 1 месяц знакомства с Delphi я написал маленькую rpg-игру. За последующие полгода я узнал гораздо больше, и когда весной сгорел жесткий диск и я решил заново написать свою rpg, я не смог. Потратив 2 месяца на движок, анимацию, оптимизацию игры я так и не смог написать той же самой.
А первая версия игры была вообще смешкая — графика поклеточная, трехслойная (карта+объекты+туман войны). Я не умел создавать простые классы, я все хранил в уродских многмерных массивах.
А первая версия игры была вообще смешкая — графика поклеточная, трехслойная (карта+объекты+туман войны). Я не умел создавать простые классы, я все хранил в уродских многмерных массивах.
Послушай постмортемы Джонатана Блоу об игре Braid. Интересно будет. Там и о массивах тоже.
Спасибо за интереснейшую наводку.
Почему-то никто не написал этого в комментариях, так что напишу я. Проблема, описанная в статье, решается в подавляющем большинстве случаев юнит-тестами (особенно TDD). Ее причина — просто недостаток обратной связи. Эту обратную связь могут дать тесты (или, если есть адекватный человек рядом, — этот человек). Вот так просто, правда.
Применяю, TDD. Оно не спасает. Вернее не от всего, но частично проблему, согласен, снимает
Если TDD не спасает, это может быть признаком того, что зашкаливает ощущение «хрупкости» конструкции. В таком случае помогают, наоборот, интеграционно-дымовые тесты (я особенно люблю phpt, причем даже когда пишу на c++ или python: они получаются грязные-грязные, кривые-кривые, копипастные-копипастные, но зато их можно фигачить по 10-20 штук в час, и они дают замечательно приятное ощущение устойчивости).
Забавно, а ведь и правда. Описать задачу тестами — то же самое, что и рассказать кому-то другому о том, как она работает. Правда, для этого лучше не мелкие юнит-тесты, а покрупнее, спецификации рабочего процесса.
Наверное, это не столько обратная связь, сколько отсеивание при объяснении или тестировании важных вещей от второстепенной шелухи.
Наверное, это не столько обратная связь, сколько отсеивание при объяснении или тестировании важных вещей от второстепенной шелухи.
А по-моему, TDD сильно помогает, но не за счет обратной связи, а за счет важного приниципа TDD — сначала надо быстро сделать хоть как-то, а только потом можно заниматься улучшательством.
Вот уж действительно «горе от ума»
О! Отличная статья, чтобы успокоить себя и других убедить, что я не просто тормоз
я провожу больше времени перетасовывая идеи, а не реальзуя их.
Ну то есть человек вырос из обычного программиста в архитектора/лидера разработчиков. Почему бы не перевестись на соответствующую должность и продолжать делать то, что лучше получается?
:)
Я и не задумывался. Но как только я потерял сохранённый файл из-за каких-то глюков, я, прежде чем начать править глючьё, сделал, чтобы файл сохранялся под другим именем и лишь потом переименовывался. Чтобы был ещё один барьер против «всякого такого».
Я и не задумывался. Но как только я потерял сохранённый файл из-за каких-то глюков, я, прежде чем начать править глючьё, сделал, чтобы файл сохранялся под другим именем и лишь потом переименовывался. Чтобы был ещё один барьер против «всякого такого».
Надо уметь контролировать свой перфекционизм.
Я очень быстро разобрался с такими мыслями. Код я пишу так:
1. Подумал о правах доступа? — Пишу в комментарии: «Файлы создаются с правами доступа по умолчанию. Желающие изменить права доступа на особые призываются сделать это после вызова данного метода».
2. Подумал о занятии файла другим приложением? — Пишу в комментарии: «Класс рассчитывает на то, что другие приложения не будут открывать указанный файл во время выполнения данного метода».
3. Подумал о многопоточности? — Пишу: «Внимание! Класс не thread-safe».
4. Пришла мысль об атомарных операциях? — См. пункт 3.
5. О фреймворках? — Завожу тикет в джире на будущий рефакторинг.
6. О разных файловых системах за меня подумали разработчики виртуальной машины Java.
7. О количестве файлов в директории пусть думают сисадмины.
8. О предсказуемых названиях временных файлов я уже заранее подумал, поэтому у меня есть проверенные заготовки.
9. Появились сомнения качестве моего ГСПЧ? — // TODO использовать безоспасный Random.
10. Нормальная документация? Да вот же она. Уже готова.
Данная проблема называется «увеличения скоупа работ». Это стандартный проектный риск. Существует несколько способов управления данным риском. То, что я описал, это самый универсальный метод, остальные желательно согласовывать с заказчиком.
1. Подумал о правах доступа? — Пишу в комментарии: «Файлы создаются с правами доступа по умолчанию. Желающие изменить права доступа на особые призываются сделать это после вызова данного метода».
2. Подумал о занятии файла другим приложением? — Пишу в комментарии: «Класс рассчитывает на то, что другие приложения не будут открывать указанный файл во время выполнения данного метода».
3. Подумал о многопоточности? — Пишу: «Внимание! Класс не thread-safe».
4. Пришла мысль об атомарных операциях? — См. пункт 3.
5. О фреймворках? — Завожу тикет в джире на будущий рефакторинг.
6. О разных файловых системах за меня подумали разработчики виртуальной машины Java.
7. О количестве файлов в директории пусть думают сисадмины.
8. О предсказуемых названиях временных файлов я уже заранее подумал, поэтому у меня есть проверенные заготовки.
9. Появились сомнения качестве моего ГСПЧ? — // TODO использовать безоспасный Random.
10. Нормальная документация? Да вот же она. Уже готова.
Данная проблема называется «увеличения скоупа работ». Это стандартный проектный риск. Существует несколько способов управления данным риском. То, что я описал, это самый универсальный метод, остальные желательно согласовывать с заказчиком.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Паралич анализа: вы знаете слишком много, чтобы просто писать код