Каков рабочий процесс, за которым Вы следуете для разработки программного обеспечения, которое Вы собираетесь записать? [закрытый]
Так что, если я вас правильно понимаю, вам просто нужно написать что-то, чтобы объединить фрагменты оператора OR на основе битового массива. Вместо добавления ИЛИ для каждой записи, независимо от того, отмечена она или нет, сделайте что-то вроде
first = true
string orClause = ""
array schoolTypes
array checkedSchoolTypes
for(i = 0; i < checkedSchoolTypes.length; i++)
if(first && checkedSchoolTypes[i])
orClause += "schools.schoolType = " + schoolTypes[i]
first = false
else if(checkedSchoolTypes[i])
orClause += "OR schools.schoolType = " + schoolTypes[i]
query = "This is your query" + orClause + "rest of your query"
* Обратите внимание, что это решение для школьного проекта, а не производственной среды. Если бы вы делали это в производственной среде, в этом случае вы бы хотели передать информацию через параметризованную хранимую процедуру и сгенерировать свое заявление в sql на основе информации, переданной из формы.
Вместо того, чтобы делать или, как вы предлагаете, вы могли бы сделать и оператор IN, поскольку другие предполагают, что код будет в основном таким же с другим форматом. Дайте мне знать, если вам нужны какие-либо разъяснения.
6 ответов
При работе над персональными, средними проектами, что Вы указываете прежде, чем начать кодировать?
Я указываю функциональную спецификацию:
- Я боялся, что могло бы быть слишком легко, если бы я только что начал кодировать (который является, "как"), для упущения то, "почему" и "что" я хотел кодировать (для "довольно сложного" программного обеспечения, за месяцы или годы, которые могло бы потребоваться для разработки).
- Я также хотел понять, более или менее, "объем" того, что я буду разрабатывать: для оценки приблизительно (к порядку величины):
- Насколько большой это будет
- Мог ли я закончить его
- Стоило ли это запустить
- Какое подмножество его может быть разработано сначала
Ради управления рисками я добавлю, что часть из того, что я хотел разработать подразумеваемое использование некоторого программного обеспечения, с которым я не был знаком; для уменьшения риска, связанного с этим, я также сделал немного одноразовой разработки прототипа.
Как?
Я обрисовал в общих чертах функциональную спецификацию, использование сочиняет статью. Часть из того, что я записал, была высоким уровнем (документ "видения" бизнес-уровня), и некоторые были низшего уровня, больше как дизайн (некоторые детали UI). Иногда я остановил и озадачил о том, как организовать его, но затем продолжил, обосновав, что каждая страница более или менее связна о каждой теме, и что я могу озадачить позже о том, как организовать страницы (во многом как Ваша Wiki, возможно).
Я и сделал и не указывал программную архитектуру заранее:
- Я запускаю разработку с базовой архитектуры (несколько маленьких компонентов) в памяти и затем добавляю код; и, поскольку я добавляю код, если какой-либо компонент становится слишком большим и сложным затем, я подразделяю его на несколько меньших компонентов... это - эволюционный процесс..., поскольку он говорит в Systemantics, СЛОЖНАЯ СИСТЕМА, ЧТО РАБОТЫ, КАК НЕИЗМЕННО НАХОДЯТ, РАЗВИЛИСЬ ИЗ ПРОСТОЙ СИСТЕМЫ, КОТОРАЯ РАБОТАЛА.
- Я не документирую архитектуру; или, скорее единственная документация архитектуры является самим кодом: например, путь, которым исходный код расположен в исходные каталоги, пространства имен и DLLs.
У меня действительно есть теоретическое выравнивание для архитектуры, как это теперь, но я не зарегистрировал эти причины:
- Я - единственный разработчик
- Фактическая архитектура документируется кодом
- Причины архитектуры находятся в моей голове и [ре], поддающееся обнаружению вещами как соглашения о присвоении имен в исходном коде и зависимостями различных компонентов
Если (только если) я не был единственным разработчиком, то я мог бы думать это стоящий документирования архитектуру и ее объяснение.
То, что я сказал выше об архитектуре программного обеспечения, также верно для данных который программные процессы.
Что касается тестирования, я кодирую немного и затем тестирую его; или запишите тест и затем кодируйте функциональность, которая пройдет тот тест. Я не делаю "интеграции большого взрыва", т.е. месяцы записи ни без какого тестирования.
Одни из самых больших слабых мест в (или вещь, отсутствующая в), мой процесс оценивает усилие заранее и затем отслеживает реализацию по оценке... это - одно из различий между этим 'персональным' процессом проекта по сравнению с заплаченным проектом, который я сделал бы для кого-то еще коммерчески. Я сомневаюсь, хорошо ли это хотя: если оценка является лучшей практикой коммерчески, то, возможно, я 'должен' делать ее также на персональном проекте.
В основном, экраны. Они - интерфейс между пользователем и программным обеспечением. Таким образом, я пробую к определенному каждый вариант использования (пользователь будет искать мой продукт - пользователь добавит продукт к его кэдди - пользователь проверит его кэдди), и я создаю цепочку экранов для каждого из них.
С наилучшими пожеланиями.
Существуют многие люди с лучшим опытом, чем я помочь Вам со специфическими особенностями здесь, но у меня есть одна точка, я думаю, всегда стоит принять во внимание.
Вы не должны получать его в 100%-й идеальный первый раз. На самом деле при стремлении к этому, Вы, вероятно, даже не закончите. Действительность - Вы, не поймет дизайн полностью, пока Вы не создали систему однажды.
Только запустите, продолжайте продвигать вперед, сохраните сверху покрытия модульного теста, и поскольку Вы понимаете систему, и ее запутанность лучше затем инкрементно осуществляет рефакторинг для улучшения его.
Я нахожу пустой листок бумаги, и перо является лучшей начальной точкой:
- эскиз несколько грубых схем
- кратко запишите некоторые идеи / примечания
- запишите некоторый псевдокод
- продумайте основные примеры использования
- думайте о потенциальных проблемах
Не тратьте больше, чем полчаса на этом и не увязайте в слишком большом количестве документации или первичного дизайна. Начните кодировать, как только у Вас есть смутное представление о том, как Вы хотите сделать это. В то время как Вы продолжаете разрабатывать, Вы получаете ощущение того, достаточно хорош ли код или нет. Если Вы не счастливы, думайте о том, что Вы не любите и запускаете с тех уроков в памяти. Осуществляйте рефакторинг часто и скоро, ранее лучше. Если что-то не "чувствует себя хорошо", это, вероятно, не.
- Потяните экраны
- Потяните отношения данных (rdbms или в оперативной памяти)
- Начните кодировать
- Пена, Промывка, Повторение (или в малопонятном жаргоне программиста GOTO 1)
Я запустил бы с минимальной реализации и добавил бы больше опций в каждом повторении.
- Запишите, что варианты использования как Вы сделали.
- Выберите 1 из случая использования и реализуйте его полностью и не реализуйте ничто иное. Это включает модульные тесты, справку и обработку ошибок - все. Назовите эту версию 1.
- Реализуйте следующий вариант использования. Это может просто добавлять код или может потребовать полной модернизации. Это в порядке, Вы знаете что Ваше выполнение теперь. Сделайте новый выпуск.
- Повторите шаг 3.