Веб-разработчики - лучше сделать разработку на Вашей локальной машине или на удаленном хосте?
Я обновил вашу функцию, и она дает ожидаемый результат. Попробуйте следующее:
function array_key_exists_r($needle, $haystack){
$result = array_key_exists($needle, $haystack);
if ($result)
{
foreach ($haystack as $a=>$v)
{
if($needle == $a)
return $haystack[$a];
if (is_array($v)) {
$result = array_key_exists_r($needle, $v);
}
if ($result) return $result;
}
}
foreach ($haystack as $v) {
if (is_array($v)) {
$result = array_key_exists_r($needle, $v);
}
if ($result) return $result;
}
return $result;
};
16 ответов
- Всегда, всегда разрабатывайте на локальной установке.
- Всегда управление исходным кодом использования.
- Всегда подвергает все управлению исходным кодом, включая схему базы данных.
, кажется, существует много людей, которым нравится иметь один центральный сервер, который все используют для разработки - я действительно не понимаю, почему Вы предпочли бы быть в общей среде, где люди, вносящие изменения, могут прервать Ваш процесс разработки.
В моем магазине у всех есть их собственный веб-сервер разработки и их собственная база данных разработки (часто соразмещаемый на той же базе данных сервер , но их собственной базе данных). Тем путем они полностью изолируются от других разработчиков и не могут прервать друг друга.
, Когда они реализуют опцию или исправляют ошибку, они регистрируются в своем коде и схема базы данных соответствия так, чтобы это было доступно другим разработчикам как полная единица. Выпуски к тестовому серверу или серверу развертывания сделаны от маркированной версии в репозитории исходного кода.
Стабильный и нормальный! Я не вижу, почему Вы сделали бы это любой другой путь, когда серверы разработки свободны!
В моей текущей позиции я разрабатываю на своей собственной машине. Для меньших проектов я просто использую легкий веб-сервер, который поставлется с Visual Studio. У меня также есть SQL Server 2005 и 2008, настроенные на моей собственной машине для разработки и начальных целей тестирования.
Это работало хорошо на меня в целом; одна проблема, с которой я столкнулся, (как другие отметили), хранение баз данных в синхронизации является своего рода болью. Я недавно переместился в , мигрант отмечает точкой сеть - в основном.NET берет миграции Ruby on Rails - для хранения local/staging/uat/production баз данных в синхронизации, и это делает мою жизнь намного менее напряженной. Инструмент как это также облегчает работать над базой данных в среде команды, хотя Вы должны дисциплинироваться достаточно для использования его последовательно.
Мои события здесь убедили меня, что локальная разработка, объединенная со своего рода процессом контроля изменений дб, непрерывным сервером интеграции и хорошей системой управления версиями, которая поддерживает слияние (мы используем TFS), является лучшим способом пойти. Это позволяет всем сделать их собственную вещь, не ступая на кого-то еще, но также и удостоверяется, что изменения объединяются правильно.
В моем предыдущем задании мы использовали IIS на наших ПК, объединенных со специализированной базой данных разработки, и это было что-то вроде ЛАВАША - необходимо было быть осторожными для не выполнения любых процессов, которые могли бы удалить базу данных или даже испортить данные, потому что это могло бы повлиять на других разработчиков и IMO, такое побежденное цель наличия DB разработки во-первых.
Я нашел, что разработка кода локальных машин с помощью управления исходным кодом при доступе к централизованному DB разработки работала отлично. При хранении нескольких DB в синхронизации оказался твердым.
Для ситуации как этот я всегда делал его на сервере разработки. С тех пор существуют, не перекомпилировал. Вы могли всегда каждый день получать новый снимок DB и понижать его до Вашей машины. Или просто имейте локальный веб-сервер и укажите на DB на dev поле.
Я - индивидуальный магазин; у меня есть и удаленный сервер и локальный сервер.
я использую локальный сервер для быстрой разработки прототипа и цикла начального развития, где я вношу много изменений и потребности протестировать их быстро. Когда это дойдет до примерно-альфа-стадии, я настрою пользовательский подхост к проекту и развернусь к моему серверу. Существуют определенные функции, которые просто не могут быть протестированы локально - т.е. e-mail-based регистрация пользователя - и таким образом, эти функции разрабатываются на удаленном сервере. Так как это является МОИМ, и не реальное развертывание, это все еще главным образом без задержки. Так как у меня есть VPS, я имею полный контроль над средой разработки на обеих машинах.
Одна проблема с тестированием на localhost состоит в том, что Вы могли бы пропустить вещи, которые являются ссылками на локальные файлы, а не доступный через браузер. Мой родительский элемент всегда помещал ссылки на своем веб-сайте клуба камеры, которые были вещами как 'href = "C:\My Documents\Camera Club\Photos...", и когда я скажу ему, что он был бы farked это, он скажет, что "это работало на меня". Так же в профессиональной среде, у Вас могли бы быть вещи, что Вы забыли зарегистрироваться в управлении исходным кодом, и таким образом, они не будут развернуты на реальном сервере.
Одно компромиссное решение могло бы состоять в том, чтобы иметь VMs, или VirtualBox или VMware или Параллели, так, чтобы можно было разжечь виртуальный Солярис, Windows, поле Mac и/или Linux для тестирования его - который покажет Вам, как Ваши виды сайта в браузерах по умолчанию на каждом, плюс Вы могут удостовериться, вещи на самом деле работают посредством нелокального соединения. Еще лучше мог бы быть должен иметь VM, который Вы развертываете на, и использование что как Ваш веб-сервер для тестирования.
, Если Вашей основной ОС является OpenSolaris, можно даже использовать ZFS и использовать снимки для откатывания VMs назад к их основному состоянию после каждого тестового прогона.
Другая причина работать локально состоит в том, что все работает быстрее. Это переводит в более быструю разработку. Сетевая задержка может быть уничтожителем производительности!
Оба. Сделайте некоторое интеграционное и поблочное тестирование на своем сервере разработки (который, идеально, должен быть максимально подобным Вашему живому серверу, но локальным), затем сделайте некоторые приемочные испытания в среде QA, которая должна или быть той же машиной как Ваш живой сервер, или точно та же установка (аппаратные средства, программное обеспечение, и т.д.) и должна быть удаленной.
Когда дело доходит до части базы данных вопроса, Вы могли также:
- у каждого есть Ваша собственная копия базы данных, ИЛИ
- сохраняют данные/структуру в синхронизации путем выполнения централизованного сценария (возможно, как часть сборки)
Я создавал сайт в Ruby on Rails, и я делал разработку локально, но развертывался к удаленной машине так часто, как я могу. Я читал в Гибкой веб-разработке с направляющими что, чем больше Вы практикуете развертывание, тем лучше, потому что, когда это прибывает время для развертывания к производству - не будет никаких неожиданностей.
FWIW, я упомяну, что наша установка похожа на то, что описал г-н Matt. Каждый dev заставляет его собственную персональную песочницу смешивать с с ее собственным веб-сервером и DB. На грани выпуска управляемый версией код, создают снимки/переходят и перемещенный в сервер подготовки, который, как предполагается, подражает реальной продуктивной среде максимально тесно. Тестирование следует, тогда выпуск сделан к продуктивной среде.
Для моих собственных персональных (non-work-related) проектов, я разрабатываю локально, тогда продвигаю живой. Один или два проекта могут иметь посреднический сервер/среду тестирования между разработкой и общедоступный/живой.
Разработка и 'тестирование' на локальной машине в порядке, но качественное тестирование должно быть выполнено в системе отражения целевая среда, т.е. безо всех средств разработки, и т.д. установленных.
Это поможет избежать, 'хорошо это работает над моей машиной' ситуации.
Я нашел, что выполнение локального веб-сервера, с удаленным DB работает лучше всего. Репликация DB / синхронизация является болью, таким образом, я только работал бы с локальным DB, если бы я действительно имел к.
Работа с локальным веб-сервером, хотя удаляет все раздражение и замедление загрузки страниц / код между изменениями.
Профессионалы к локальному:
- работы, даже если сеть понижается
- , Вы знаете каждый инструмент на машине
Недостатки к локальному:
- должны синхронизировать все с сервером развертывания
- без управления версиями, можно ударить работу других
Профессионалы к центральному:
- у всех есть идентичные инструменты
- всегда работа над "реальным" содержанием
Недостатки к центральному:
- не может работать, если сеть снижается
- , Ваш "любимый" инструмент (инструменты) может отсутствовать
, я уверен, что существует больше, но они приходят на ум сразу же.
Я думаю, лучше иметь локальную установку, которая полностью находится под Вашим контролем во время разработки, чтобы удостовериться, чтобы изменения, внесенные другими разработчиками, не вмешивались в Ваше собственное. У меня есть установка среды разработки и тестовой среды локально, таким образом, я могу выполнить обе задачи, не будучи должен принять других разработчиков во внимание. Я постоянно запускаю свои тесты, поскольку я кодирую автотест использования, подразумевая, что я могу быть уверен, что мой код корректен и удовлетворяет корректную спецификацию.
После того, как кодовая база в порядке, я развертываюсь к серверу подготовки (который является средой, которая является максимально близко к производству), и повторно выполните тесты. Мы также используем наш этап, чтобы выполнить тестирование загрузки и сделать пользователя, тестирующего.
До хранения Вашего DB "в синхронизации", когда другие редактируют его. Один путь вокруг этого состоит в том, чтобы получить Вашу схему DB при управлении версиями. Это не столь просто как подвергание Вашего исходного кода при управлении версиями, и существуют различные способы обработать его.
читает это сообщение при Кодировании Ужаса:
https://blog.codinghorror.com/get-your-database-under-version-control /
Не так само сообщение, но эти шесть статей он связывается с K. Scott Allen.
В основном то, что описано в тех статьях, является методом определения исходного состояния, схема базы данных, регистрируясь в .sql файле той базовой линии, и оттуда на в Вас пишет возрастающим .sql "сценариям изменения" каждый раз, когда Вы изменяете схему. Теперь каждый раз разработчик проверяет или обновляет рабочую копию, любые выдающиеся сценарии изменения будут выполнены. Необходимо будет настроить некоторые сценарии/инструменты, чтобы сделать это сами, если Вы не будете использовать платформу, которая делает это для Вас.
Обычно у Вас был бы локальный сервер разработки, который все совместно используют.