Что Ваш или процесс программирования Вашей компании? [закрытый]

Question

Что Ваш или процесс программирования Вашей компании? [закрытый]

Вы можете определить контейнер в CustomNavigationPage и использовать его в каждом экземпляре страницы навигации.
public class CustomNavigationPage : NavigationPage
{
   public static IContainer Container;

   public CustomNavigationPage()
   {
       Locator locator = new Locator();
       locator.RegisterTypes();
       Container = locator.Container();
   }
}
Это фиктивный код, о котором я упоминал.

Вы создаете настраиваемую страницу навигации. Так что вы можете использовать это для навигации по своим страницам, например:
CustomNavigationPage.PushASync(new TestPage(Container.Resolve<WardListPage>())):
Если вы используете эту страницу, ваша пользовательская навигационная страница будет разрешать ваши зависимости при каждом вызове.
Для повышения производительности вы можете зарегистрировать свои зависимости с одноэлементным шаблоном. Когда приложение запустится, зависимости будут зарегистрированы. После того, как вы используете эту зарегистрированную зависимость.

Есть улучшение: вы определяете статический локатор с одноэлементным шаблоном, который регистрирует зависимости в app.cs
public sealed class Locator
    {
    private static Locator locator = null;
    private static readonly object padlock = new object();

    Locator()
    {
      //your registries
    }

    public static Locator Locator
    {
    get
    {
    lock (padlock)
    {
    if (locator == null)
    {
    locator = new Locator();
    }
    return locator;
    }
    }
    }
    }
И в ваших app.cs:
 public App()
    {
        InitializeComponent();              
        Locator locator = new Locator();
        Container = locator.Container;
        .
        .
    }

    public static IContainer Container;
[1111 ] Таким образом, вы только один раз регистрируете свои зависимости. Там нет дублирования кода. Будет использован только один экземпляр.

21

workflow process

задан 3 revs, 3 users 100% 27 November 2013 в 14:51

4 ответа

Мы используем Trac в качестве нашей системы слежения ошибки/запроса новых функций
Билеты Trac рассмотрены, изменены, чтобы быть осуществимыми единицами и затем присвоены этапу
trac билеты являются нашими спецификациями, содержа главным образом очень редкую информацию, которая должна быть обсуждена в течение этапа
Нет, но наша группа разработчиков состоит только из двух участников
Да, мы тестируем, и да, TDD помог нам очень. Покрытие приблизительно в 70 процентах (Cobertura)
Нет, мы осуществляем рефакторинг когда соответствующий (во время изменений кода)
Мы документируем только открытые методы и классы, наше максимальное количество строки равняется 40, таким образом, методы являются обычно настолько маленькими для самоописывания (если существует такая вещь ;-)
svn с соединительной линией, дистанционным управлением и стабильными ответвлениями
1. соединительная линия - Разработка новых возможностей, bugfixing более старых функций
2. дистанционное управление - Для в тестировании дома, bugfixes объединяются вниз от соединительной линии
3. стабильный - только bugfixing объединенный вниз от соединительной линии или дистанционного управления

4

ответ дан 29 November 2019 в 21:52

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

http://agilemanifesto.org/

http://www.extremeprogramming.org/

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

В оболочке гайки:

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

1

ответ дан 29 November 2019 в 21:52

Я не уверен, почему за этот вопрос вниз проголосовали. Я думаю, что это - большой вопрос. Это - одна вещь погуглить поиск и считать некоторые случайные веб-сайты, которые много времен пытается продать Вам что-то, а не быть объективным. И именно другой вещью спросить ТАК толпа являются Кормушки разработчиков/IT для совместного использования их событий, и какие работы или не работает на их команды.

Теперь, когда эта точка вне пути. Я уверен, что много разработчиков будет указывать на Вас к "Гибкому" и/или Толпе, иметь в виду, что эти термины часто используются очень свободно особенно Гибкие. Я, вероятно, собираюсь звучать очень спорным путем высказывания этого, которое не является моим намерением, но эти методологии сверхраздуты, особенно Толпа, которая является большим количеством продукта, продаваемого консультантами Scrum, чем "реальная" методология. Однако в конце дня Вы добрались для использования то, что работает лучшее на Вас и Вашу команду, если это является Гибкой/толпой/XP или что бы то ни было, пойдите для него. В то же время необходимо быть гибкими об этом, не становитесь религиозными ни о какой методологии, инструменте или технологии. Если что-то не работает на Вас, или можно стать более эффективными путем изменения чего-то, пойдите для него.

Быть более конкретным относительно Ваших вопросов. Вот основная сводка методов, которые работали на меня (многие из них являются здравым смыслом):

Организуйте все документы и электронные письма, имеющие отношение к определенному проекту, и сделайте его доступным для других через центральное расположение (я использую MS OneNote 2007 и Любовь он для всей моей документации, progess, функций и отслеживания ошибок, и т.д.),
Все встречи (который необходимо попытаться минимизировать) должны сопровождаться деловыми вопросами, где каждый объект присвоен определенному человеку. Любое устное соглашение должно быть помещено в записанный документ. Все документы, добавленные к стройплощадке / репозиторий. (MS OneNote в моем случае)
Прежде, чем запустить любую новую разработку, имейте записанный документ того, что система будет способна к выполнению (и что это привычка делает). Согласитесь на него, но быть гибкими к бизнес-потребностям. Насколько подробный документ должен быть? Подробный достаточно так, чтобы все поняли то, к чему заключительная система будет способна.
Расписания хороши, но быть реалистичными и честными себе и бизнес-пользователям. Основная инструкция, которую я использую: качество выпуска и применимое программное обеспечение, которое испытывает недостаток в некоторых функциях, а не ошибочном программном обеспечении со всеми функциями.
Имейте открытые линии связи среди своей dev. команды и между Вашими разработчиками и деловыми кругами, но в конце дня, один человек (или несколько ключевых людей) должен быть ответственен за принятие ключевых решений.
Модульный тест, где это имеет смысл. Но НЕ становитесь одержимыми этим. 100%-е покрытие кода! = никакие ошибки и программное обеспечение не работают правильно согласно спецификациям.
Действительно имейте стандарты кода и кодируйте обзоры. Придерживайтесь стандартов, но если это не работает на некоторые ситуации, допускают гибкость.
Прокомментируйте свой код особенно трудно, чтобы читать/понимать части, но не превратить его в роман.
Возвратитесь и очистите Вас код если Вы уже работающий над тем классом/методом; реализование новой опции, работа над исправлением ошибки и т.д. Но не осуществляйте рефакторинг его только ради рефакторинга, если у Вас нет ничего иного, чтобы сделать, и Вы скучаете.
И последний и более важный объект: не становитесь религиозными ни о какой определенной методологии или технологии. Одолжите лучшие аспекты от каждого и найдите баланс, который работает на Вас и Вашу команду.

5

ответ дан 29 November 2019 в 21:52

Другие вопросы по тегам:

workflow process

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

score 11 · Accepted Answer

Для моей (небольшой) компании:

Мы разрабатываем UI сначала. Это абсолютно очень важно для наших проектов, поскольку сложный UI будет почти сразу отчуждать потенциальных покупателей. Мы моделируем наши проекты на бумаге, затем поскольку мы выбираем специфические особенности для дизайна, готовим Представление и любой соответствующий код Контроллера для непрерывной интерактивной разработки прототипа наших проектов.
Поскольку мы двигаем приемлемый UI, мы затем пишем бумажную спецификацию для логики рабочего процесса приложения. Бумага является дешевой, и крутящийся посредством проектов гарантирует, что Вы, по крайней мере, потратили небольшое количество времени, думая о реализации вместо того, чтобы кодировать слепой.
Наши спецификации сохранены в управлении версиями наряду с нашим источником. Если мы выбираем изменение или хотим экспериментировать, мы переходим код и СРАЗУ обновляем спецификацию для детализации то, что мы пытаемся выполнить с этим конкретным ответвлением. Модульные тесты на ответвления не требуются; однако, они требуются для чего-либо, что мы хотим включить назад в соединительную линию. Мы нашли, что это поощряет эксперименты.
Спецификации не являются святыми, и при этом они не принадлежат никакому конкретному человеку. Путем передачи спецификации демократической среде управления исходным кодом мы поощряем постоянное экспериментирование и пересмотр - пока это документируется так, мы не говорим "WTF?" позже.
На недавней игре iPhone (еще не опубликованный), мы закончили почти с 500 ответвлениями, которые позже перевели почти в 20 различных функций, огромное количество упрощений понятия ("Касание для Отмены" на индикаторе выполнения вместо отдельной кнопки), много отвергнутых идей и 3 новых проекта. Большой вещью является каждая идея, был зарегистрирован, таким образом, было легко визуализировать, как идея могла изменить продукт.
После каждой основной сборки (что-либо в соединительной линии обновляется с передачей модульных тестов), мы пытаемся иметь по крайней мере 2 человек, проверяют проект. Главным образом мы пытаемся найти людей, у которых есть мало знания компьютеров, поскольку мы нашли, что слишком легко разработать сложность, а не простоту.
Мы используем DOxygen для генерации нашей документации. Нам еще действительно не включили автоматическое поколение в наш процесс сборки, но мы работаем над ним.
Мы не кодируем обзор. Если модульный тест работает, и источник не вызывает проблемы, он, вероятно, в порядке - но это вызвано тем, что мы можем полагаться на качество наших программистов. Это, вероятно, не работало бы во всех средах.
Поблочное тестирование было удачей для наших практик программирования. Так как любой новый код не может быть передан в соединительную линию без соответствующих модульных тестов, мы имеем довольно хорошее покрытие с нашей соединительной линией и модерируем покрытие в наших ответвлениях. Однако это не замена для пользователя, тестирующего - только инструмент для помощи в получении к той точке.
Для отслеживания ошибок мы используем Bugzilla. Нам не нравится он, но это работает на данный момент. Мы, вероятно, скоро или прокрутим наше собственное решение или мигрируем на FogBugz. Наша цель не состоит в том, чтобы выпустить программное обеспечение, пока мы не достигаем 0 известных состояний ошибок. Из-за этой позиции наши обновления наших существующих пакетов кода обычно довольно минимальны.

Так, в основном наш поток обычно выглядит примерно так:

Бумага спецификация UI + планирование» умственного тестирования» шаг 1
Код представления + модульные тесты» пользователь, тестирующий» шаг 1 или 2
Бумажный контроллер и образцовая спецификация + планирование» умственного тестирования» шаг 2 или 3
Модель и код контроллера + модульные тесты» пользователь, тестирующий» шаг 3 или 4
Разветвленная Идея» Спецификация», Кодирующая (никакие модульные тесты)» Умственное Тестирование» Отклонение
Разветвленная Идея» Спецификация», Кодирующая (никакие модульные тесты)» Умственное Тестирование» Принятие» Модульные тесты» Соединительная линия» Шаг 2 или 4
Известные ошибки» шаг 2 или 4» восстановления ошибки» средства отслеживания ошибки
Готовое изделие» отчеты об ошибках» шаг 2 или 4

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