Пишет, что спецификации для хобби проектируют единственный путь к ним, чтобы быть законченными?

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

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

У меня такая же проблема. Одна вещь, которую я заметил, что помогло, - это снижение моих амбиций. как ПУТЬ низко. Написание спецификации - это один из способов сдержать амбиции, если у вас есть какое-то ограничивающее правило для спецификации, например: «Спецификация может быть только одной страницей», или «Спецификация не может быть длиннее 300 слов», или «Укажите только то, что я могу сделать за один день написания кода». Чтобы добиться правильного баланса, потребуется немного практики. Если вы пойдете с последним лимитом, вы можете ввести правило ОБЯЗАТЕЛЬНОГО закрытия проекта, если вы не можете завершить его за один день.

Самое приятное в этом то, что это ограничивает вас достижимыми целями. Поначалу это может показаться действительно глупым или неправильным. Или, может быть, это звучит разумно, но вы просто ничего не можете поделать, вы хотите делать удивительные вещи, а не обычные вещи! неизменно обнаруживается, что они произошли от простая система, которая работала. В обратное предложение также оказывается правда: сложная система, разработанная из царапина никогда не работает и не может быть сделана работать. Вы должны начать все сначала, начиная с рабочего простого система. »

—Джон Галл

НАМНОГО проще осуществить этот амбициозный проект, если у вас уже есть ЗАВЕРШЕННЫЙ и РАБОЧИЙ проект, на котором он будет основан. Тогда «более сложным» МОЖЕТ быть проект, который уместится в один день. Это идеал и философия, над которой я работаю, потому что я думаю, что у нее больше шансов на успех. Если посмотреть на прошлые успешные проекты, то можно сказать, что подавляющее большинство из них развивались таким образом, независимо от того, преднамеренно это было или нет.

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

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

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

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

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

Реальный вопрос: какое у вас хобби? Это завершение проекта или возня. Если пройти последние десять ярдов сложно, вам нужно решить, стоит ли оно того для вас. Написание подробных спецификаций будет работать; так будет и самобичевание, если вы придерживаетесь такого рода самодисциплины. Ничто не упростит задачу, если это противоречит вашему макияжу, поэтому вы должны решить, стоит ли конечная цель чего-нибудь для вас.

И, просто чтобы продемонстрировать, что в этом пункте нет ничего специфичного для программирования, вы можете очень нравится этот парень . Одним из основных моментов в его работе является то, что художники-концептуалисты, такие как Пикассо и Да Винчи, никогда особо не заботились о финальном исполнении - идея была всем, и, утвердив ее,

Да и нет. Я делаю заметки в блокноте, когда думаю об этом, и добавляю их по мере реализации. Этот процесс несколько отличается от рабочих проектов, где кто-то еще может ознакомиться со спецификацией.

Я заканчиваю примерно половину того, что начинаю.

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

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

Я не думаю, что написание спецификаций - это решение вашей проблемы. Ясно, что ваши «хобби-проекты» - это то, что вам нравится. Вы пишете забавные части, но затем избегаете неинтересных частей, которые были бы необходимы для завершения чего-либо.

Если вы просто «программируете для развлечения», тогда хорошо, у вас все получается. Я не думаю, что писать спецификации - это весело.

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

К сожалению, после написания спецификаций для ядра движка DIFL (не трудитесь его искать, так как за пределами моих домашних систем его нет), я все еще не закончил его вверх.

Краткий ответ: разработка спецификаций для хобби-проекта не является ни необходимой, ни достаточной для гарантии завершения.

При этом ...

У меня есть инженерная записная книжка для всех моих личных вещей. проекты. Я использую записную книжку, чтобы записывать самые разные вещи о проектах, над которыми я работаю. Это включает в себя мотивацию проекта, ценные ресурсы, задействованные в ходе проекта, вещи, разработанные в ходе проекта, которые потенциально могут быть повторно использованы позже, полученные ключевые идеи и т. Д. И т. Д. Кроме того, помимо вашего вопроса, сюда входят спецификации для большинства проектов. . Я использую гибкий / бережливый подход для создания этих спецификаций, которые, на мой взгляд, являются убедительными с точки зрения затрат и выгод.

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

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

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

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

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

Вы хотите, чтобы закончил их?

Думаю, разумно никогда не заканчивать хобби-проект. Вы можете просто продолжать работать над этим, пока живете. Aciddose работает над его виртуальным инструментом xhip в течение многих лет, упорно никогда не добраться до 1.0, что делает программу бесполезной инструмент пластыри людей от одной версии к другим. Тем не менее, он и пользователи его софтсинта, похоже, отлично проводят время.

Может быть, если вы просто стремитесь «выпустить», а не «закончить», вы будете более удовлетворены. Бета-версии позволяют продолжать мечтать.

Единственное лучшее, что я когда-либо находил, чтобы помочь продвинуться к завершению, - это то, что кто-то другой работает над проектом вместе с вами. Найдите друга (или двух), который заинтересован в одном и том же, и разработайте / закодируйте его вместе с ними. У вас есть не только кто-то, от кого можно оттолкнуть идеи, но и кто-то, кто может вас мотивировать, не говоря уже о том, что прогресс в два раза быстрее, поэтому вы, надеюсь, закончите, прежде чем сдадитесь :)

Конечно, это требует контроля версий, но вы уже использовали это в своих проектах, верно? :)

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

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

Я полагаю, это означает, что независимо от того, есть ли у вас спецификация, она не повлияет на успех проекта так сильно, как другие факторы, такие как наличие времени, мотивации, помощи и уверенности.

Обычно я пишу первый набор спецификаций, когда начинаю.

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

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

Конечно, некоторые из моих хобби-проектов выполняются совместно. В таких случаях я записываю больше спецификаций, чтобы лучше общаться со своей командой, и стараюсь поддерживать такие документы, как диаграммы БД, в актуальном состоянии.

У меня не работает! Фактически, всякий раз, когда я пишу спецификации, я обычно делаю проекты еще крупнее, и вероятность их завершения снижается.

Иногда лучший способ сделать это - просто сделать это.

Зе Франк объясняет это намного лучше. чем я: http://www.zefrank.com/theshow/archives/2006/07/071106.html (ссылка на видео с руганью)

РЕДАКТИРОВАТЬ: Просто добавить. Если вы обнаружите, что хотите отказаться от незавершенного проекта ради новой грандиозной идеи ... сделайте это! Не оглядывайтесь назад!

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

Причина, по которой вы начали, была из-за страсти. Это очень важно. Не стоит заставлять себя «выкладываться» в свободное время. Вы истощите свою страсть, которая является вашим самым важным ресурсом.

Я смог выполнить несколько хобби-проектов и закончить некоторые из их. Я пытаюсь закончить их все, но некоторые просто не могу собрать.

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

Что помогло мне завершить большую часть моих работ, так это то, что они оставалась страстью, пока не были оставлены последние штрихи. Так что я просто пролистал их.

В какой-то степени да поможет спецификация. Они продвигают вас дальше в проект, но почти всегда бывает момент, когда страсть утихает, и вы ищете следующий блестящий объект.

Я только что недавно узнал, что написание спецификаций - это действительно то, что мне нужно для выполнения моих проектов.

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

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

Таким образом, вы можете выполнять только 1 или 2 проекта одновременно, но на самом деле добить их. И, конечно же, у вас есть дополнительный и довольно ценный бонус в виде продолжения работы над проектом, даже если вы не прикасаетесь к нему около месяца или более. Спецификации всегда будут напоминать вам о целях и задачах вашего проекта.

Это всего лишь мой личный опыт, и я считаю, что вам стоит попробовать. Надеюсь, вам это тоже пригодится.

Я не слишком усложняю, но перечисление всех функций и требований, которые вы хотите включить в свое приложение, действительно помогает. Как и в случае с большинством хобби-проектов, вы часто не просто сидите и пишете код в течение 2 месяцев, а затем завершаете их. Здесь час, там два и т. Д. Обычно очень часто забывают, над чем вы работали в последний раз и какова была первоначальная цель этой супер-отличной идеи для приложения.

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

Я участвовал в разработке ряда систем, от критически важной авионики до одноразовых личных проектов, таких как решатель судоку. Очевидно, что для систем авионики спецификации были критически важны для безопасной работы системы и предотвращения убийства, но я никогда не беспокоился о своих личных проектах.

Я думаю, это потому, что спецификации обычно скучно читать и писать. Джоэл написал интересную статью об этом и о том, как сделать их лучше, если вы их напишете:

Безболезненные функциональные спецификации

К сожалению, у меня еще не хватило смелости попытаться сделать мои спецификации более интересными для чтения на работе.

Может, после написания спецификаций вам стоит попробовать поработать над некоторыми проектами для других людей или вместе с ними? Это могло дать некоторую внешнюю мотивацию. Я занимаюсь веб-разработкой для своего кузена

В качестве дополнительной мысли, если вы хотите быть более явным с вашими сокращениями (если вы делаете аннотацию AST, это может быть удобно), вы можете создать указатели значений стека, а затем самостоятельно обрабатывать значения типов. Очень похоже на скалярные типы с:

struct myScalar {
    union {
        int num;
        char *id;
        char *float_lexeme;
    }payload;

    enum {
        TYPE_NUM,
        TYPE_IDENTIFIER,
        TYPE_FLOAT_CHAR
    } type;
    char *orig_lexeme;
};

И имеют typedef и scalar_val * val для стека.

Когда вы переходите к более сложным интерфейсам компилятора, это может помочь построить ваш AST следующим образом так что при перемещении по дереву у вас будут лучшие метаданные, и вы также можете дополнить перевод переводами для до-семантических типов. Затем все сводится к вашим конечным продуктам, таким как ID, чтобы перетасовать лексему в правильную скалярную полезную нагрузку.

Не полное объяснение, но идею вы поняли. Обратите внимание, что теперь ваша функция сравнения T () имеет члены величин, которые становятся постоянными, и формулу можно упростить до нахождения наибольшего скалярного произведения между вашим тестовым вектором и значениями в базе данных.

Теперь подумайте о новой функции D = расстояние между двумя точками в пространстве 60D. Это классическое расстояние L2 , возьмите разность каждого компонента, возведите каждый в квадрат, сложите все квадраты и извлеките квадратный корень из суммы. D (A, B) = sqrt ((AB) ^ 2), где A и B - каждый по 60 размерных векторов.

Однако это можно расширить до D (A, B) = sqrt (A * A -2 * точка (A, B) + B * B). Значит, А и В - единичная величина. А функция D монотонна, поэтому она не изменит порядок сортировки, если мы удалим sqrt () и посмотрим на квадраты расстояний. Остается только -2 * точка (A, B). Таким образом, расстояние минимизации в точности эквивалентно максимизации скалярного произведения.

Таким образом, исходная метрика классификации T () может быть упрощена до нахождения наивысшего скалярного произведения между норнализованными векторами. И это сравнение показано эквивалентным нахождению ближайших точек к точке выборки в пространстве 60D.

Итак, теперь все, что вам нужно сделать, это решить эквивалентную задачу «с учетом нормализованной точки в 60D. пробел, перечислите 20 точек в базе данных нормализованных векторов выборки, которые являются ближайшими к нему. "

Эта проблема хорошо изучена ... это K ближайших соседей. Есть много алгоритмов решения этой проблемы. Наиболее распространены классические деревья KD. .

Но есть проблема. Деревья KD имеют поведение O (e ^ D) ... высокая размерность быстро становится болезненной. И 60 измерений определенно относятся к этой крайне болезненной категории. Даже не пытайтесь.

Однако есть несколько альтернативных общих методов для ближайшего соседа с высоким D. Эта статья дает ясный метод.

Но на практике есть отличное решение, включающее еще одно преобразование. Если у вас есть метрическое пространство (которое у вас есть, или вы бы не использовали сравнение Танимото), вы можете уменьшить размерность проблемы с помощью поворота на 60 измерений. Это звучит сложно и пугающе, но это очень распространено ... это форма разложения по сингулярным значениям или разложения по собственным значениям. В статистике он известен как Анализ главных компонентов.

В основном он использует простое линейное вычисление, чтобы определить, в каких направлениях действительно простирается ваша база данных. Вы можете свернуть 60 измерений до меньшего числа, возможно, до 3 или 4, и при этом иметь возможность точно определять ближайших соседей. Для этого существует масса программных библиотек на любом языке, см. здесь , например.

Наконец, вы сделаете классический метод K ближайших соседей, вероятно, только в 3-10 измерениях .. вы можете экспериментировать для лучшего поведения. Для этого есть прекрасная библиотека под названием Ranger , но вы можете использовать и другие библиотеки. Большим дополнительным преимуществом является то, что вам даже больше не нужно хранить все 60 компонентов ваших выборочных данных!

Тяжелый вопрос заключается в том, действительно ли ваши данные могут быть свернуты до более низких измерений без ущерба для точности результатов. На практике разложение PCA может сказать вам максимальную остаточную ошибку для любого выбранного вами предела D, поэтому вы можете быть уверены, что это работает. Поскольку точки сравнения основаны на метрике расстояния, весьма вероятно, что они сильно коррелированы,

Я научился писать свои собственные спецификации для личного использования

-

1. Дайте мне сосредоточиться, чтобы выполнить работу, и не уходите в тупик
2. Напомните мне, над чем я работаю
3. У меня есть отличные идеи до того, как я начну писать код
4. Делать вещи веселее и дольше

Для меня создание собственных спецификаций жизненно важно для выполнения чего-либо!

Вы не начнете бизнес без плана. ты?

Для личных проектов у меня есть тонны книг по молескину, заполненных приблизительными спецификациями и идеями. Когда они созревают, они переходят из записных книжек в настоящие документы, и начинается кодирование.

БОЛЬШОЕ РЕДАКТИРОВАНИЕ : На пути к личной эффективности и для завершения проектов. Я читал «Приводя к делу» ... Несмотря на всю хипповскую чушь про «психику»

Я думаю, что основная проблема заключается не в отсутствии спецификаций, а в том, что доводить что-то (что-либо) сложно .

Это тяжелая работа . Может показаться, что ваша программа выполнена на 90%. Но выполнение этих последних 10% (устранение всех ошибок, повышение качества приложения, написание документации и т. Д.) Требует столько же работы, сколько и первые 90%. И если вы хотите серьезно относиться к маркетингу своей программы, отвечать на электронные письма службы поддержки, исправлять ошибки других людей, это еще больше работы. И, возможно, не та работа, которая вас больше всего интересует.

Это также сложно морально . Незавершенный проект имеет неограниченный потенциал. Это пустой холст, на котором вы можете проецировать свои необузданные амбиции, высокие идеалы и революционные мысли. Как только он будет закончен и станет реальностью, вы должны увидеть, что это такое. Ограниченное. Ошибочный. Никогда не было так красиво, как идея, которая его породила.

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

Несколько советов:

• Убедитесь, что вы действительно хотите , чтобы завершить проект. То есть награда стоит всех упорных усилий. (Если нет, то примите этот факт и оставайтесь счастливым мастером-мастером.)

• Найдите способы мотивировать себя через «скучные» части. Технические характеристики, возможно, если это поможет вам сосредоточиться. Но найдите то, что работает для вас, будь то тиканье заданий, вознаграждение себя печеньем или мечты о славе и богатстве.

• Выпускайте раньше, отпускайте чаще. Чем больше вы откладываете для «большого выпуска», тем больше вероятность того, что этого выпуска никогда не будет.

• Сначала выпустите, затем перепишите. Когда вы чувствуете потребность в серьезном переписывании, сначала сделайте релиз, а затем переписывайте (если вы все еще готовы к этому). Программное обеспечение никогда не бывает идеальным. Если вы стремитесь к совершенству без какого-либо давления, чтобы выпустить свой недоработанный (но существующий) код, то вы никогда не закончите.

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