Тактика развития: циклы развития феникса

Question

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

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

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

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

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

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

Любую тактику, любую помощь, любой опыт или анекдоты, которыми вы хотите поделиться?

Спасибо за внимание!

Answer 1

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

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

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

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

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

Answer 2

Выпуск рано, выпуск часто.

Answer 3

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

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

Я также попытался минимизировать риск, написав несколько прототипных программных компонентов, проверяющих концепцию наиболее опасных или наименее понятных битов.

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

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

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

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

• Возьмите меньший проект (не ожидайте, что вы закончите слишком большой проект самостоятельно) ... усилия и умение завершить проект не линейны с размером проекта (например, проект, который вдвое больше) как большой может быть в пять раз сложнее завершить)

• Начните, но не ожидайте окончания (это возможность обучения, из которой вы будете учиться)

• Работа с кем-то еще

• Работайте медленнее и методично (если вы проезжаете всего 100 ярдов, вы можете просто начать бег, но если вы идете 100 миль, вам нужно подготовить карту и т. Д.).

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

Кто-то (не обязательно я) должен ответить на этот ваш абзац, или, возможно, вы могли бы сказать больше об этом.

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

Answer 4

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

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

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

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

Answer 5

Я думаю, что самая сложная часть программной инженерии (не программирование как таковое) - это найти правильный баланс между прагматизмом в том, чтобы сделать это СЕЙЧАС и в выполнении RIgHT.

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

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

Answer 6

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

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

Answer 7

Design Freeze!

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

С уважением, Билл Дриссел