Как реализовать код способом, который уменьшается, возможность полных переделывает [закрытый]
Вы можете сделать это со следующим (спасибо ответ Гжегожа и ответ Матиаса ):
- (void)touchesEnded:(NSSet *)touches withEvent:(UIEvent *)event {
NSInteger previousSelectedSegmentIndex = self.selectedSegmentIndex;
[super touchesEnded:touches withEvent:event];
CGPoint locationPoint = [[touches anyObject] locationInView:self];
CGPoint viewPoint = [self convertPoint:locationPoint fromView:self];
if ([self pointInside:viewPoint withEvent:event] && previousSelectedSegmentIndex == self.selectedSegmentIndex) {
self.selectedSegmentIndex = UISegmentedControlNoSegment;
[self sendActionsForControlEvents:UIControlEventValueChanged];
}
}
Я сделал с открытым исходным кодом (MIT Лицензированный) класс STASegmentedControl (поддерживает iOS 7+), который имеет эту функциональность (и более).
9 ответов
Модульность. Создавайте небольшие блоки кода, которые хорошо выполняют свою работу. Однако это только начало. Обычно это большое сочетание факторов, которые способствуют такому коду, что его нужно полностью переработать. Все: от очень нестабильных требований, плохого дизайна до отсутствия прав собственности на код - список можно продолжать и продолжать.
Дополнение к тому, что подняли другие: СВЯЗЬ.
Общение между вами и клиентом, вами и руководством, вами и другими разработчиками, вами и вашим отделом контроля качества, общение между всеми является ключевым. Убедитесь, что руководство понимает разумные сроки и убедитесь, что и вы, и заказчик точно понимаете, что это за здание.
Найдите время, чтобы поддерживать связь с клиентом, для которого вы создаете продукт. Сделайте вехи и настройте время для отображения проекта заказчику на каждом этапе. Даже если клиент полностью разочарован вехой, когда вы ее показываете, вы можете отбросить то, что у вас есть, и начать с последней вехи. Это также требует, чтобы ваша работа была построена в виде блоков, которые работают независимо друг от друга, как заявил Csunwold.
Очки ...
- Поддерживайте открытое общение
- Будьте открытыми и честными в отношении прогресса продукта
- Будьте готовы ежедневно меняются в соответствии с потребностями бизнеса клиентов и спецификациями для изменения продукта.
Требования к программному обеспечению меняются, и с этим мало что можно сделать, кроме более частого взаимодействия с клиентами.
Однако можно создать код, более устойчивый к изменениям. Это не спасет вас от выброса кода, отвечающего требованиям, которые больше никому не нужны, но может уменьшить влияние таких изменений.
Например, когда это применимо, используйте интерфейсы, а не классы (или эквивалент в вашем language) и избегайте добавления операций в интерфейс, если вы не уверены, что они вам нужны. Создавая свои программы таким образом, вы с меньшей вероятностью будете полагаться на знания о конкретной реализации и с меньшей вероятностью будете реализовывать вещи, которые вам не понадобятся.
Еще одно преимущество этого подхода состоит в том, что вы можете легко заменить одну реализацию на другую. Например, иногда окупается написать самую глупую (по эффективности), но самую быструю для написания и тестирования реализацию для вашего прототипа, и заменять ее чем-то более умным в конце, когда прототип является основой продукта, а производительность на самом деле имеет значение. Я считаю, что это очень эффективный способ избежать преждевременной оптимизации и, следовательно, выбросить ненужные вещи.
Я считаю, что это очень эффективный способ избежать преждевременной оптимизации и, следовательно, выбросить ненужные вещи. Я считаю, что это очень эффективный способ избежать преждевременной оптимизации и, следовательно, выбросить ненужные вещи., как уже было сказано, ответом является модульность. но на практике это может быть трудным ответом. Я предлагаю сосредоточиться на:
- небольших библиотеках, которые хорошо выполняют предопределенные вещи;
- минимальных зависимостях между модулями;
сначала написание интерфейсов - хороший способ достичь обоих (с интерфейсами, используемыми для зависимостей). последующее написание тестов для интерфейсов до написания кода часто подчеркивает немодульные варианты дизайна.
Я не знаю, интенсивно ли ваше приложение использует пользовательский интерфейс; это может затруднить создание модульной системы. обычно это стоит усилий, но если нет, то предположите, что вскоре его выбросят, и следуйте принципу айсберга, что 90% работы не привязано к пользовательскому интерфейсу, и поэтому проще сохранить модульный принцип.
наконец, Я рекомендую "прагматичного программиста" Эндрю Ханта и Дэйва Томаса как полных советов. мой личный фаворит - DRY - "не повторяйся"
Иногда перезапись - лучшее решение!
Если вы пишете программное обеспечение для камеры, вы можете предположить, что следующая версия также будет поддерживать видео, стерео-видео или 3D-лазерное сканирование и включать все крючки для всех этих функций, или вы могли бы написать такую универсальную расширяемую архитектуру астронавтов, которая могла бы справиться со следующей камерой, включая реактивные двигатели, - но это будет стоить столько денег, ресурсов и производительности, что вам, возможно, было бы лучше этого не делать.
Полное изменение новой функциональности в новой роли не всегда плохая идея.
итерация маленькая
итерация часто
проверка между итерациями
получить простой рабочий продукт как можно скорее, чтобы клиент
В основном предполагается, что материал БУДЕТ выброшен, поэтому кодируйте соответствующим образом и не заходите достаточно далеко во что-то, что выбросить его, стоит много времени.
Хотя это не относится напрямую к вашему примеру, при написании кода я стараюсь следить за тем, как я могу увидеть развитие программного обеспечения в будущем.
В основном я пытаюсь предугадать, куда пойдет программа, но критически, я сопротивляюсь искушению реализовать любые вещи, которые я могу себе представить. Все, что мне нужно, это попытаться заставить API и интерфейсы поддерживать возможные варианты будущего без реализации этих функций, в надежде, что эти «возможные сценарии» помогут мне придумать лучший и более надежный интерфейс.
Не конечно всегда работа.
Добрый день,
Просматривая здесь другие ответы, я замечаю, что все упоминают, что делать для вашего следующего проекта.
Одна вещь, которая, кажется, отсутствует, - это наличие смывка, чтобы узнать, почему спец. был рассинхронизирован. с фактическими требованиями, необходимыми заказчику.
Меня беспокоит, что если вы этого не сделаете, независимо от того, какой подход вы выберете для реализации своего следующего проекта, если у вас все еще есть несоответствие между фактическими требованиями и спец. для вашего следующего проекта вы снова окажетесь в той же ситуации.
Это может быть что-то столь же простое, как плохое общение или, возможно, сползание требований клиентов.
Но, по крайней мере, если вы знаете причину и можете попробовать и помочь свести к минимуму вероятность того, что это повторится снова.
Как сказал csunwold, модульность вашего кода очень важна. Напишите это так, чтобы, если в одном элементе возникли ошибки, это не испортило остальную систему. Таким образом, вы можете отлаживать один раздел с ошибками, при этом имея возможность безопасно полагаться на остальные.
Помимо этого, документация является ключевой. Если ваш код аккуратно и четко аннотирован, доработка его в будущем будет бесконечно проще для вас или того, кто занимается отладкой.
Использование системы контроля версий также может быть полезным. Если вы обнаружите, что фрагмент кода работает неправильно, всегда есть возможность вернуться к предыдущей надежной итерации.