Как запрограммировать приложение с неизвестными будущими модификациями и функциями?

Question

Справочная информация

Я не новичок в программировании, однако я знаю, что касается работы с клиентами и их потребностями.Вот моя история с моим текущим клиентом: я унаследовал PHP-приложение с завершением 2/3, продолжал доводить его до 100% до тех пор, пока клиент не захотел (основных) функций, которые привели к необходимости переписывания приложения и базы данных.Я потратил две недели на то, чтобы описать, как новое приложение будет работать с новыми изменениями и другими необходимыми функциями, и после одобрения я снова приступил к созданию приложения.Теперь меня просят добавить новые функции, которые не обсуждались до новой сборки, и опять же, они довольно важны.Кроме того, все приложение работает с более чем 300 пользователями, что делает его еще сложнее.

Вопрос

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

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

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

Answer 1

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

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

Многие разработчики программного обеспечения используют такие методы, как Agile Software Development или Extreme Programming или другие итерационные методологии.

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

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

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

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

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

Answer 2

Крючки.

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

Answer 3

В зависимости от потребностей может использоваться модель приложения «plug-in».

Answer 4

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

Шаблоны проектирования: http://en.wikipedia.org/wiki/Design_pattern

Answer 5

Мне приходят в голову два понятия: «тебе это не понадобится» и «будь проще, глупый». То есть, по моему опыту, кодирование будущих функций - это ловушка для создания ужасного кода, и тогда будущее все равно будет другим. Но, возможно, это только я.

Answer 6

Предсказание основных новых функций вряд ли возможно. Однако есть несколько мест, где запланированная гибкость всегда хорошая идея. Прежде всего имеет смысл сохранить абстрактный интерфейс базы данных и расширяемые поля таблицы. Часто это легко сделать с активным шлюзом данных записей или таблиц или аналогичными схемами, иногда может быть достаточно простого $ fieldnames [$ table] = [a, b, c].

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

Если у вас есть существующие пользователи и переделываете работающую систему, это может помочь реализовать представления базы данных (даже версионные?), Сохранить старое приложение и построить новую версию на расширенной схеме хранения. Но на самом деле, это сложно оценить по обобщенному описанию.

Answer 7

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

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

Answer 8

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