Мнение автора может не совпадать с мнением редакции
Меня зовут Борис и я перфекционист. Для человека, начинающего бизнес это чаще недостаток, чем достоинство. Если вас зовут не Стив. Перфекционизм жрет время - в то время как ты натираешь продукт пастой ГОИ, более расторопные ребята выпускают свой - в разводах и царапинах. Они краснеют от стыда и получают деньги. Ты гордишься собой и сидишь голодный.
Технический прототип - это набросок толстым маркером. Готовое приложение - это чертеж, выполненный аккуратно, с соблюдением всех допусков и ГОСТов. Перфекционисту не нравится рисовать маркером - это слишком неряшливо. Кроме этого, такой набросок никуда не годится, в таком виде он никому не нужен. Кроме самого перфекциониста, который пока об этом не знает. Озарение приходит только тогда, когда, закончив чертить по ГОСТам, перфекционист понимает, что это не тот чертеж.
В процессе работы над моим продуктом для совместного проектирования баз данных я сталкивался с описанной ситуацией дважды. Первый раз был тогда, когда я намеревался реализовать совместную работу пользователей используя алгоритм Operational Transformation, допускающий одновременную правку документа любым количеством пользователей (на нем построен Google Docs). К счастью, тогда я не пожалел времени и разобрался, что это за монстр. О том, что мои предположения относительно его сложности были слегка занижены, говорит эта фраза, которую я прочитал на сайте одной из реализаций OT, Share.js: "I am an ex Google Wave engineer. Wave took 2 years to write and if we rewrote it today, it would take almost as long to write a second time." Хорошенько покопав и не найдя гового решения стоящей передо мной задачи, я героически отступил к более простому варианту: редактирование одним пользователем и почти мгновенная трансляция изменений всем остальным. И ни разу об этом не жалею.
Второе столкновение с айсбергом произошло не так давно. Для отрисовки ER-модели я использовал SVG тулзу. Судя по всему, ее писал один автор, предоставляя коммерческую лицензию за 500 евро. "Отлично", - подумал я, и начал строчить UI. Потихоньку стали проявляться сыроватости - части функциональности не хватало, часть работала с ошибками. Я неистово monkey-патчил и дописывал недостающие детали (при том что JavaScript для меня третий язык после Java и Python, а созданием SVG/Canvas диаграмм я до этого ни разу не занимался). Это отнимало кучу времени, но я все же рисовал достаточно красивые и аккуратные объекты и даже заставлял их вести себя так, как надо. Конец искусству наступил внезапно - я всего лишь отрендерил 100 таблиц по 10 колонок в каждой и с удивлением обнаружил, что начальная загрузка документа в браузере стала занимать минуты(!). Я думал о различных оптимизациях, но упирался в естественное ограничение - как бы я не старался, значительно уменьшить время начальной загрузки (на 1 - 2 порядка) я не мог. Теперь я переключился на другую библиотеку, уже за 2800$, с отделом разработки и поддержки и даже сейлзами! Будет излишним говорить, что недели, потраченные на допиливание старой либы пошли коту под хвост.
Мораль басни в двух словах:
1. Если задача для вас не типична, сделайте прототип, грубо реализовав основные функции системы.
2. Оттестируйте моменты, которые наиболее туманны для вас. О том, как красить квадратики в разные цвета или перехватывать события, сказано в документации; вероятность того, что такие базовые вещи не реализованы или не работают, стремится к нулю. А вот касаемо скорости - темный лес, я это даже примерно прикинуть не мог.
3. Если что-то не устраивает - поищите другое решение. Если не нашли подходящего решения задачи, попробуйте упростить саму задачу (как у меня со стратегиями редактирования документа). Вообще, совет про упрощение задач можно смело скопировать в пункт 0 - особенно перфекционистам - для них это единственная возможность закончить проект не изменив своим принципам (полностью не изменив).
Кстати, хорошая (хоть и местами скучноватая) книга для выздоравливающих: Тал Бен-Шахар "Парадокс перфекциониста".
Технический прототип - это набросок толстым маркером. Готовое приложение - это чертеж, выполненный аккуратно, с соблюдением всех допусков и ГОСТов. Перфекционисту не нравится рисовать маркером - это слишком неряшливо. Кроме этого, такой набросок никуда не годится, в таком виде он никому не нужен. Кроме самого перфекциониста, который пока об этом не знает. Озарение приходит только тогда, когда, закончив чертить по ГОСТам, перфекционист понимает, что это не тот чертеж.
В процессе работы над моим продуктом для совместного проектирования баз данных я сталкивался с описанной ситуацией дважды. Первый раз был тогда, когда я намеревался реализовать совместную работу пользователей используя алгоритм Operational Transformation, допускающий одновременную правку документа любым количеством пользователей (на нем построен Google Docs). К счастью, тогда я не пожалел времени и разобрался, что это за монстр. О том, что мои предположения относительно его сложности были слегка занижены, говорит эта фраза, которую я прочитал на сайте одной из реализаций OT, Share.js: "I am an ex Google Wave engineer. Wave took 2 years to write and if we rewrote it today, it would take almost as long to write a second time." Хорошенько покопав и не найдя гового решения стоящей передо мной задачи, я героически отступил к более простому варианту: редактирование одним пользователем и почти мгновенная трансляция изменений всем остальным. И ни разу об этом не жалею.
Второе столкновение с айсбергом произошло не так давно. Для отрисовки ER-модели я использовал SVG тулзу. Судя по всему, ее писал один автор, предоставляя коммерческую лицензию за 500 евро. "Отлично", - подумал я, и начал строчить UI. Потихоньку стали проявляться сыроватости - части функциональности не хватало, часть работала с ошибками. Я неистово monkey-патчил и дописывал недостающие детали (при том что JavaScript для меня третий язык после Java и Python, а созданием SVG/Canvas диаграмм я до этого ни разу не занимался). Это отнимало кучу времени, но я все же рисовал достаточно красивые и аккуратные объекты и даже заставлял их вести себя так, как надо. Конец искусству наступил внезапно - я всего лишь отрендерил 100 таблиц по 10 колонок в каждой и с удивлением обнаружил, что начальная загрузка документа в браузере стала занимать минуты(!). Я думал о различных оптимизациях, но упирался в естественное ограничение - как бы я не старался, значительно уменьшить время начальной загрузки (на 1 - 2 порядка) я не мог. Теперь я переключился на другую библиотеку, уже за 2800$, с отделом разработки и поддержки и даже сейлзами! Будет излишним говорить, что недели, потраченные на допиливание старой либы пошли коту под хвост.
Мораль басни в двух словах:
1. Если задача для вас не типична, сделайте прототип, грубо реализовав основные функции системы.
2. Оттестируйте моменты, которые наиболее туманны для вас. О том, как красить квадратики в разные цвета или перехватывать события, сказано в документации; вероятность того, что такие базовые вещи не реализованы или не работают, стремится к нулю. А вот касаемо скорости - темный лес, я это даже примерно прикинуть не мог.
3. Если что-то не устраивает - поищите другое решение. Если не нашли подходящего решения задачи, попробуйте упростить саму задачу (как у меня со стратегиями редактирования документа). Вообще, совет про упрощение задач можно смело скопировать в пункт 0 - особенно перфекционистам - для них это единственная возможность закончить проект не изменив своим принципам (полностью не изменив).
Кстати, хорошая (хоть и местами скучноватая) книга для выздоравливающих: Тал Бен-Шахар "Парадокс перфекциониста".
0
