Вопросы Теги

Что делает хорошую спецификацию? [закрытый]

Неустранимая ошибка: использование $ this, если не в контексте объекта

$this - специальная переменная в PHP , которая не может быть назначена. Если он доступен в контексте, где он не существует, эта фатальная ошибка указывается.

Эта ошибка может возникнуть:

  1. Если нестатический метод называется статическим , Пример: 
    class Foo {
   protected $var;
   public function __construct($var) {
       $this->var = $var;
   }

   public static function bar () {
       // ^^^^^^
       echo $this->var;
       //   ^^^^^
   }
}

Foo::bar();
    Как исправить: снова просмотрите свой код, $this может использоваться только в контексте объекта и никогда не должен использоваться в статическом методе. Кроме того, статический метод не должен обращаться к нестатистическому свойству. Используйте self::$static_property для доступа к статическому свойству.
  2. Если код из метода класса был скопирован в нормальную функцию или только глобальную область и , сохраняя специальную функцию $this переменная. Как исправить: Просмотрите код и замените $this на другую переменную замещения.

Вопросы, относящиеся:

  1. Вызов нестатический метод как статический: PHP Неустранимая ошибка: использование $ this, если не в объектном контексте
  2. Копировать код: Неустранимая ошибка: использование $ this, если не в объекте context
  3. Все «Использование $ this, если не в контексте объекта» Вопросы по Stackoverflow

38
задан Taryn 11 May 2012 в 11:39
поделиться

11 ответов

Лучшая спецификация является той что:

  1. Существует
  2. , Описывает то, ЧТО, не то, КАК (никакие решения)
  3. Может быть интерпретирован как можно меньшим количеством способов
  4. , широко распределяется
  5. , согласован как являющийся спецификацией всеми участвующими сторонами
  6. , краток
  7. , последователен
  8. , регулярно обновляется, когда требования изменяются
  9. , Описывает такую большую проблему, как возможно, и практичный
  10. тестируемый
54
ответ дан Robert C. Barth 27 November 2019 в 03:20
поделиться

, Что вставить спецификацию

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

аудитория

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

  • бизнес-владелец, кто заканчивает система.

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

  • люди QA, которые имеют к планам теста записи относительно нее.

  • Персонал техобслуживания, желающий понять систему

  • Разработчики или аналитики на других проектах, которые могут хотеть интегрировать другие системы в него.

Требования типичных ключевых игроков:

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

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

    при определении интерфейса между двумя системами это должно быть очень точно.

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

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

  • Интеграторам нужны модель данных и четкие определения любых интерфейсов.

Ключевые компоненты спецификации:

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

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

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

  • Подтверждение правильности данных и Бизнес-правила: , Чем проверки на правильность должны быть быть сделанными на данных и какие вычисления делаются, наряду с определениями. Примеры могут быть довольно полезными здесь.

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

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

Joel ('на программном обеспечении' известность) записал хороший ряд статей на этом названном Безболезненная Функциональная спецификация , к которой я отослал людей в довольно многих случаях. Это - вполне хороший набор статей и определенно стоящий чтения. По-моему, Ваша цель состоит в том, чтобы ясно объяснить, что система, как предполагается, делает способом, который минимизирует неоднозначность. Довольно полезно думать о спецификации как справочном документе - что могло бы различные заинтересованные стороны хотеть быть в состоянии легко искать.

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

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

РЕДАКТИРОВАНИЕ: Это был мой опыт, которые дебатируют о различии между тем, 'как' и 'что' имеет тенденцию быть довольно корыстным. На любом нетривиальном проекте модель данных и пользовательский интерфейс будут иметь несколько заинтересованных сторон, не, все из которых являются разработчиками системы. Работа в организации хранилищ данных даст одной вкус к хаосу, который следует, когда модели данных приложения позволяют стать свободным - для всех, и , PFS должен дать одному чувство для потенциальной группы заинтересованных сторон, которым должна угодить спецификация.

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

14
ответ дан Community 27 November 2019 в 03:20
поделиться

По моему опыту, спецификация будет иметь больше шанса того, чтобы быть считанным, если это будет иметь следующее:

  • Использование схематически изображает, где возможный - изображения стоят 1 000 слов
  • , Имеют титульный лист, который ясно указывает на то, что спецификация описывает
  • , Имеют стиль, который используется всюду по документу. Сделайте все заголовки тем же шрифтом, размером и стилем. Сделайте шрифт тем же полностью через, используйте те же стили маркера и т.д.
  • , не КОЛЕБЛЮТСЯ - Быть ясен краткий и к точке и не добавляют дополнительный хлам для увеличивания документа. Если идея не может объясниться в нескольких строках текста, то, возможно, необходимо повредить его вниз далее

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

11
ответ дан JamesSugrue 27 November 2019 в 03:20
поделиться

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

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

4
ответ дан Dan Vinton 27 November 2019 в 03:20
поделиться

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

2
ответ дан dalesmithtx 27 November 2019 в 03:20
поделиться

Серия Read Joel" Безболезненные Функциональные спецификации " продолжения статьи Joel Test. Они также появляются в "Joel на программном обеспечении" книга.

1
ответ дан Dave Ray 27 November 2019 в 03:20
поделиться

Зависит от того, насколько большой проект и (как все решения архитектуры), каковы ограничения. Хорошее начало

  • краткое описание, "один пейджер"
  • схема контекста - где границы, что взаимодействует с системой?
  • истории случаев/пользователя использования
  • прототип GUI или бумажный прототип, если применимо
  • описание необходимых нефункциональных требований (производительность и т.д.)

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

1
ответ дан Charlie Martin 27 November 2019 в 03:20
поделиться

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

Пример Ваша запись программного обеспечения для измерения "X".

Вместо утверждения: должна быть кнопка запуска и кнопка сохранения.

Использование: пользователь должен быть в состоянии запустить измерение и сохранить его.

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

1
ответ дан Ivo Flipse 27 November 2019 в 03:20
поделиться

Я думаю, пишущий, что "Варианты использования" должны сохранить Вас набор страниц

0
ответ дан Chanakya 27 November 2019 в 03:20
поделиться

+1 KiwiBastard и я добавили бы подобную маркеру запись и сделали бы каждый маркер тестируемым.

0
ответ дан Community 27 November 2019 в 03:20
поделиться

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

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

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

Спецификации не должны быть длинными, они просто должны содержать правильный материал!

(подсказка: если программист не смотрел на ту страницу при кодировании, она, вероятно, не требовалась)

Paul.

0
ответ дан Paul W Homer 27 November 2019 в 03:20
поделиться
Другие вопросы по тегам:

Похожие вопросы: