Тактика развития: циклы разработки Phoenix
Мне было интересно, как вы, ребята, на самом деле разрабатываете большие приложения, когда сами себе босс. Я сам на собственном горьком опыте усвоил необходимость терпения и надежды. Я работал над реализацией приложения (в виде серии скриптов, связанных с базой данных), которое объединяет статьи Википедии в кластеры, используя сочетание знаний о вики-ссылках и текста / содержания статьи. Я занимаюсь этим уже два года; пока результатов нет.
Кажется, я не могу получить никаких результатов, потому что я постоянно реинжинирую свои скрипты и БД из-за изменений либо в сути (псевдопсевдокод, теоретический алгоритм), либо в форме (скрипт, потоки, таблицы БД, практический алгоритм) алгоритма. . По сути, я постоянно учусь на ошибках, которые обнаруживаю при реализации; дьявол кроется в деталях, похоже, ответы тоже.
В любом случае, каждый раз, когда я реинжинирую скрипт, таблицу или что-то еще, мне нужно выбросить всю мою документацию и скрипт. Теперь я могу делать это без страха, но это заставило меня возненавидеть программирование (ненавижу детали).
Я считаю, что реинжиниринг - это правильный путь, поскольку я думаю о долгосрочных перспективах и хочу быстро учиться, но мне интересно, есть ли у вас, ребята, аналогичный опыт программирования, или вам никогда не понадобится или вы не захотите выпустить лучший сценарий смерти последнего (как феникс).
Самая сложная часть для меня - это очистить мою документацию, потому что я трачу больше времени на документирование, чем на кодирование; Я использую документацию как средство для обсуждения проблем и рассмотрения решений; Я использую его для формулирования реализуемых решений. Хотя, если бы это было не для меня, я бы не прочь почистить его, тем не менее я всегда пишу его так, как если бы он был опубликован на следующей неделе, потому что, разрабатывая сценарий, я также стремлюсь развиваться; Я также стараюсь, как и те из вас, кто участвует в этом веб-сайте, делиться своими знаниями или мудростью с другими.
В любом случае, последние 2 месяца я развивался на полной скорости, переделывая бесчисленные эссе, сценарии, таблицы и т. Д .; мое терпение на исходе, я ищу результаты.
Любая тактика, помощь, опыт или анекдоты, которыми вы хотите поделиться?
Ответы 7
Поскольку вы работаете в одиночку, постарайтесь получить обратную связь от кого-то еще, кто знает достаточно, чтобы понять, что вы пытаетесь сделать. Вы будете удивлены тем, что могут придумать другие люди.
Работать за зарплату несколько проще, потому что вы должны получить согласие клиента, это не так открыто, как в вашей текущей ситуации.
вести журнал разработки; это место, где можно обсудить детали с самим собой, решить все на бумаге, набросать документацию, сделать заметки о текущих и будущих проблемах, напомнить себе, что вы пробовали и что вам осталось попробовать, и так далее. Также неплохо всегда отмечать, что «делать дальше», чтобы не тратить время на запоминание / повторение, когда у вас есть время поработать над этим. Дата каждой записи.
Я использовал этот подход в ряде длительных, иногда разочаровывающих, индивидуальных проектов продолжительностью от нескольких месяцев до нескольких лет, и он помогает мне сосредоточиться и помогает мне не попробовать что-то более одного раза.
Это также устранило внутреннее давление по документированию всего, что могло бы принести вам большую пользу.
думайте об этом так: заметки для себя о том, что вы сделали, полезны для вас, но подробная документация, предназначенная для сторонних разработчиков, для кода, который удаляется, - это пустая трата времени.
Возможно, это поможет вашим нейронам документации ОКР заткнуться, чтобы вы могли полностью решить проблему, тогда документирует рабочее решение - вместо того, чтобы постоянно заново документировать последний опытный образец.
Ах да, я чувствую вашу мудрость. Я действительно начну датировать свои записи, потому что моя документация больше похожа на блог разработчиков. Хотя я думаю, что вы правы в том, что мне не следует тратить свое время на совершенствование моей документации, я также вижу, что практика ведет к совершенству; Я хочу улучшить свое письмо.
Тем не менее, это отличный совет; Я постараюсь его усвоить. Спасибо
Я думаю, что самая сложная часть разработки программного обеспечения (не программирования как такового) - это найти правильный баланс между прагматизмом в том, чтобы сделать это СЕЙЧАС и сделать это ПРАВИЛЬНО.
Среди (хороших) программистов есть тенденция всегда разбирать вещи и собирать их вместе - это более аккуратный / крутой / чище / ... способ. Это хорошо ... за исключением тех случаев, когда это означает, что все постоянно разбивается на части, и неуловимая цель создания работающей (и действительно аккуратной) системы отдаляется все дальше.
Что касается меня, я должен заставить себя признать, что что-то не идеально, и согласиться на получение результатов некоторый за короткий период времени. Я считаю, что лучший способ сделать это - установить серию краткосрочных вех, которые приведут к конечной цели. Придерживайтесь основных этапов, даже если какая-то другая часть проекта какое-то время выглядит более заманчиво.
Опять же, я могу коснуться этой потребности сделать его аккуратнее / прохладнее / чище. Я действительно очищаю свой сценарий прямо перед тем, как решаю переделать его суть. Хотя это может быть контрпродуктивным, для тех, кто все еще учится, как я, кажется разумным усовершенствовать форму, если это кажется
чтобы иметь возможность помочь мне изучить или усвоить новую тактику написания сценариев. Но я полагаю, что в конечном итоге мне нужно будет стабилизироваться в том, что мне нужно будет выработать стиль.
Что касается основных этапов; Мне трудно указать что-то большее, чем следующие 1 или 2 вехи, поскольку даже они, вероятно, изменят свою сущность из-за открытия гораздо лучших решений или важных деталей, которые не были рассмотрены.
Хотя я и устанавливаю вехи, я считаю, что лучше держать их абстрактно неоднозначными, чем дальше в будущее они кажутся. Спасибо за мудрость баланса между прагматизмом и результатами! Но что для вас или для вас прагматизм?
@ [Николас Леонард]: нарисуйте свою цель, визуализируйте безумный успех, затем сосредоточьтесь на следующем действии и только на следующем действии. Периодически оценивайте заново.
@ [Стивен А. Лоу]: Визуализируйте безумный успех: иногда мне кажется, что я теряюсь в созерцании своих снов и результатов моего приложения. Как и все остальное, я думаю, это вопрос подбора правильной дозы. Что мне наиболее сложно, так это найти волю и терпение для рефакторинга, реинжиниринга и т. д. Thx
Хороший девиз в программировании: «Будьте готовы и счастливы выбросить все хотя бы один раз», обычно даже больше. В настоящее время я пишу полную оболочку с нуля для новой операционной системы, и я собираюсь полностью отказаться от части дизайна, мне не нравится, как я обрабатываю встроенные команды по сравнению с загружаемыми модульными командами.
Похоже, вы нырнули головой вперед ... взволнованы тем, что написали код. Насколько я понимаю, вы потратили некоторое время на псевдокод (я даже использую большую доску для сухого стирания), чтобы определить структуру вашего кода ... но код не смог пережить радикальные изменения в указанной структуре.
Могут быть веские причины, по которым вы работаете в полной изоляции. Если возможно, как предлагали другие, пригласите кого-нибудь, кто понимает конечный результат, которого вы надеетесь достичь, и разработайте новый дизайн. Имейте в виду, что ваше приложение оказалось довольно нестабильным, новый дизайн не должен заставлять вас отказываться от всего, потому что кое-что изменилось.
Я думаю, что вы тоже становитесь жертвой так называемой преждевременной оптимизации. Попробуйте собрать что-то, что работает, даже если это ужасно неэффективно и неуклюже, а затем действительно потратьте некоторое время на то, чтобы подумать, как это можно улучшить. Этот шаг является почти предшественником нового дизайна, который может пережить радикальные изменения в будущем. Если вы не можете привлечь кого-то еще, модель ваших текущих ошибок за работой почти так же хороша, как и другой соавтор.
О да, это высказывание сильно во мне, потому что я вижу, что для таких, как я, работающих над своим собственным проектом, готовность и способность к реинжинирингу, кажется, обеспечивают приложение с максимальной скоростью развития.
Я счастлив, что вы также отказываетесь от своего кода, чтобы он работал значительно лучше: реинжиниринг. Тем не менее, в отличие от автоматизации (точечная оптимизация), реинжиниринг сопряжен с риском, поскольку нет уверенности в том, что повышение эффективности или результативности будет стоить затраченных усилий (и рисков).
Что касается работы с кем-то, кроме вашего предложения: вы, ребята, убедили меня поработать над этим! Хотя я сомневаюсь, что найду кого-то из своих близких, способного помочь мне с алгоритмом кластеризации (эффектом), я ставлю кого-то на эффективность и прагматизм кода; злодей, которому я доверяю.
Я становлюсь жертвой преждевременной оптимизации, но знаю об этом; Я все еще дочерний разработчик, мне нужно потренироваться и подумать об эффективности (оптимизации), потому что это, скорее всего, потребуется, когда я действительно обработаю все 20 миллионов статей, не говоря уже о триллионе ссылок! Спасибо,
Рассматривали ли вы просто использование одного из дампов базы данных, которые Википедия делает доступными на полурегулярной основе, для тестирования? Это может помочь вам получить основной код там, где он вам нужен, и подумать о том, как вы будете очищать его позже. Я думаю, что как только вы сделаете хотя бы минимальный прототип, вы сможете летать.
@ [tinkertim] Судя по всему, они перестали делать дампы MySQL. Кажется, единственный вариант - разобрать дампы XML. Это боль. Но в настоящее время я занимаюсь рефакторингом своего приложения, чтобы собрать и отсортировать все данные, которые могут мне понадобиться. Это потребует от меня задуматься над частью распознавания образов ...
@ [tinkertim] На самом деле, вы были правы. Википедия по-прежнему предоставляет дампы sql для mySQL. Я был ослеплен, потому что использую PostgreSQL. В любом случае, спасибо!
Заморозка дизайна!
Создавайте замороженный дизайн в крошечных модулях с минимальной связью - модули делают ТОЛЬКО одно. Когда это сработает, вы будете намного умнее исправлять любые недостатки. Минимальное сцепление и максимальная согласованность позволяют легко вырезать дефектные детали. Не выбрасывайте ничего, что работает.
С уважением, Билл Дриссел
В самом деле, я стараюсь разбить на модули таким образом, чтобы максимально увеличить возможность повторного использования кода, его понимание и простоту. Но иногда абстрактный алгоритм так сильно меняется, что мне приходится сильно отказываться от него. Тем не менее, я все еще изучаю это программирование, и мне это очень больно! Я действительно сосредотачиваюсь на возможности повторного использования. Спасибо
I was wondering how you guys actually develop large applications when you are your own boss.
Я начал с написания страниц, страниц и страниц функциональной спецификации ... описывая на различных уровнях детализации (включая пользовательский интерфейс) то, что я хотел, чтобы программа делала.
Я также попытался свести к минимуму риск, написав несколько прототипов программных компонентов, подтверждающих концепцию, с наиболее рискованными или наименее понятными элементами.
Anyway, every time I reengineer a script or a table or something, I need to scrap all ...
Я, конечно, рефакторирую написанное (работаю над этим с 2005 года), но только для того, чтобы добавить новые функции. Обратите внимание, что «рефакторинг» - это технический термин (поищите его: об этом есть книги): заметьте, что «рефакторинг» - это совсем не то же самое, что «отбрасывать» то, что я уже написал (вместо этого я изменяю -it-and-add-to-it).
I have been at it for two years now; no results yet. ... Anyways, I have been developing at full speed these last 2 months ...
Я не знаю, сколько у вас опыта как программиста. Если у вас нет большого опыта, есть несколько вариантов:
Возьмите меньший проект (не ожидайте, что закончите слишком большой проект самостоятельно) ... усилия и навыки для завершения проекта не зависят от его размера (например, проект, который в два раза больше, может быть в пять раз больше сложнее завершить)
Начните, но не ожидайте завершения (это возможность для обучения, на которой вы будете учиться)
Работайте с кем-то другим
Работайте медленнее и методичнее (если вы пробегаете только 100 ярдов, вы можете просто начать бегать, но если вы пробегаете 100 миль, вам нужно подготовить карту и т. д.).
The hardest part for me is scraping my documentation for I spend more time documenting than coding ...
Кто-то (не обязательно я) должен ответить на этот ваш абзац, или, возможно, вы могли бы рассказать о нем больше.
Меня очень интересует эта тема (на самом деле продукт, который я разрабатываю, предназначен для документирования разработки программного обеспечения), но я не знаю, что ответить на этот конкретный ваш абзац.
Ах да, это хороший совет. Я получил диплом по информатике. В отличие от компьютерных инженеров, мои основные усилия направлены на псевдоалгоритм; программирование - это «сделать это возможным». Программирую 5 лет; Я сосредоточился на приложениях на основе баз данных, которые имеют дело с огромными наборами данных.
Я обнаружил необходимость разработки псевдо-алгоритма при разработке фактической реализации; как вы сказали, я также осознаю необходимость быть методичным (терпение и надежда вступают в игру!).
Хотя в основном необходимость знать, как хорошо программировать, мотивирует меня к рефакторингу моего кода и таблиц БД, именно необходимость иметь эффективный алгоритм кластеризации чаще всего вынуждает меня реинжиниринг (отбрасывать большие фрагменты кода, документы и БД). ).
Я документирую по многим причинам. Хотя я называю эту документацию, потому что она действительно объясняет форму приложения, она смешивается с различными обсуждениями и наблюдениями. Я имею дело со сложными алгоритмами; Я считаю, что обсуждение того, что я на самом деле делаю, помогает мне понять или увидеть.
Когда я документирую, я разделю свои обсуждения на разделы, обозначенные заголовком, который может абстрагироваться от важной проблемы, вопроса, беспокойства или элемента приложения (таблица БД, слой и т. Затем в каждом разделе будут обсуждаться проблемы и возможные решения, чтобы сделать вывод, что делать.
Все эти файлы или разделы документации, я стараюсь организовать их иерархически, чтобы они оставались частью единого целого. Я также стараюсь включать много гиперссылок на веб-страницы с ответами или соображениями, а также на другие части моей документации.
Я также часто включаю философские или метафизические соображения и т. д., Потому что, будучи разработчиком, это только часть меня; Я пытаюсь соединить все свои части вместе, чтобы они дополняли друг друга. На мой взгляд, этот мир слишком специализирован; Я пытаюсь соотнести то, что я узнаю, с тем, что я знаю.
Поскольку «комментарии» ограничены 300 символами, это место не поддерживает длинные двусторонние обсуждения. Если вам нужен более длинный диалог (а не только один вопрос-ответ), вы можете разместить свой вопрос на форуме, который поддерживает диалоги, например. обсудить.joelonsoftware.com/?joel
@ [Крис] Разве вы не видите, что это так?
Выпускайте раньше, выпускайте часто.
Интересно. Но что, если вы хотите бросить вызов гиганту? Разве тогда не было бы разумно хранить свой код среди верных друзей? Я читал викиномику; Я знаю ценность коллективного разума, присущего экспертной оценке. Тем не менее, поскольку все вы так сильно в это верите, я пойду на компромисс.
Я спрошу некоторых близких друзей, но не всю Живую паутину; о нет, я думаю, это было бы слишком рискованно. Хотя хорошая ссылка. Спасибо!
Спасибо. Это действительно мудрый совет. В то время как я начал отправлять свои обсуждения моему другу (который работает над созданием psyco для 64-битной версии), я действительно приму ваш совет, попросив его дать обратную связь. Собственно, я также пытаюсь заставить его сосредоточиться на эффективности моего приложения. Спасибо!