Как вы переходите от идеи к реализации при разработке классов для других разработчиков в других местах?

Question

Я ищу вдохновение о том, как проектировать классы с нуля в проекте с несколькими разработчиками в разных местах (так что никаких занятий на доске.)

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

Я бы начал с лучшего инструмента: ручка и бумага . Но что тогда? Я хотел бы материализовать свои строки, пузырьки и нотации на моей бумаге на экранах других разработчиков. Является ли лучший способ просто отсканировать и отправить по электронной почте бумагу? Есть ли хорошие шаблоны для записи дизайна в виде текста? Существуют ли онлайн-инструменты, которые могут быстро моделировать дизайн класса? Должен ли я просто написать «скелеты» для классов и попросить обратную связь?

Здесь важно помнить, что единственное доступное общение - это телефон и электронная почта, поскольку разработчики находятся далеко друг от друга.

Answer 1

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

Редактировать: ссылки в виде списка

• Microsoft SharedView
• Adobe ConnectNow
• Skype
• Drop.io
• Google Docs
• Office Live
• Skrbl
• Отзывы о Google Code
• Gliffy

Answer 2

Не продолжайте это в большом сеансе «все или ничего», когда вы пытаетесь спроектировать все классы системы.

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

Если это будет интегрировано с существующим кодом, спросите соответствующих разработчиков, как это влияет на него.

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

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

Другое дело, когда вы распределяете членов команды, работающих в одной и той же части системы, если у вас есть чистый код (и это единственная обратная связь, на которую вы должны обратить внимание), вы сможете продолжить работу с командой и развить код в то, что действительно необходимо реализовать. С этими членами команды вы должны иметь постоянную связь, если различия в часовых поясах мешают вам, по крайней мере, иметь 30-60 минут перекрытия ... вы можете обойтись без, и я справился, но перекрытие действительно окупается.

Ps. Я уже 4 года интенсивно работаю с распределенными командами в обоих случаях, о которых я упоминал выше (разные команды по подсистемам большого проекта, одна команда по определенной подсистеме) и 2 года из тех, что были с глобально распределенными командами.

Answer 3

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

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

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

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

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

На следующий день мы с товарищем по команде начали реализацию кода Proof-Of-Concept, который понадобился бы, чтобы все это заработало. Еще через две недели вся бета-версия была закончена и просто потребовались некоторые настройки. Это было то, что делала остальная часть команды, пока я уезжал в отпуск.

После возвращения из отпуска весь проект оказался очень успешным, и функциональность была очень хорошо воспринята нашими клиентами!

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

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

Answer 4

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

Исходя из этого, используйте любой моделирующий / текстовый редактор в качестве поддержки: Paint, Word, WinDesign, Objecteering и т. Д. Лучший способ общения.

PS: Я согласен, что ручка и бумага - лучшие, но когда это для вас, а не для иностранных разработчиков. Так что забудьте о сканировании и отправке по электронной почте ^^

Answer 5

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

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

Answer 6

Будьте проще с блогом.

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

Если есть клиент, менеджер или другая заинтересованная сторона, они могут видеть, что люди активны и работают над вещами.

Answer 7

SVN или CVS является обязательным , поэтому вы всегда должны получать доступ к деталям ваших коллег и видеть существующие интерфейсы и в описании. Также все люди в команде должны использовать маркеры документов в прототипах для автоматической системы документирования, такой как Doxygen. Так что легко создавать документацию для всех других разработчиков на лету. Эта документация должна быть доступна в хранилище (в основном в папке «doc»), чтобы вы могли каждый день обновлять свою рабочую копию, а также получать обновленную документацию.

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

Поскольку у вас есть описания интерфейса с сгенерированной документацией, создание прототипов не проблема. Из-за карты ума, UML, блок-схемы и т. Д. Вы получаете представление обо всем этом. Маркеры документации должны также включать что-то вроде «@author», чтобы вы могли легко связаться с ними, если вам нужно более подробное описание, если что-то не понятно. Часто это хорошая идея, если люди используют мессенджеры (MSN, ICQ, ...), поэтому вы можете легко связаться с ними. Часто это всего лишь короткий вопрос, поэтому нет необходимости звонить кому-либо или писать по почте (где вы в конечном итоге получите ответ на следующий день)

Быстрое создание прототипов - еще одна вещь в игре. Возникает вопрос, предназначены ли классы для графического интерфейса или это «только» логика программы. Для GUI доступно множество инструментов для каркасов, которые могут генерировать классы, поэтому вам нужно только реализовать внутреннюю логику (обработку событий) и интерфейсы для ваших коллег-классов. Для других частей я предлагаю инструмент UML (в основном вам нужна только диаграмма классов). Есть бесплатные инструменты, такие как ArgoUML, работающие также в Linux. Эти инструменты могут генерировать большую часть дизайна класса также для разных языков (C ++, Java)

Answer 8

• Убедитесь, что у вас есть четко определенные, задокументированные требования.
• Каждый должен ознакомиться с требованиями, чтобы получить обзор. Один человек может отвечать за первоначальный дизайн. Проектный документ может быть как простым, как подробный список того, как требования будут реализованы в вашей системе, так и сложным, как детализированная диаграмма UML, в зависимости от потребностей вашего проекта.
• Используйте конференц-связь, чтобы встретиться и обсудить дизайн.
• Используйте программу мгновенного обмена сообщениями для отправки ссылок, хэширования и, при необходимости, для совместного устранения неполадок.
• В некоторых проектах (особенно с открытым исходным кодом) часто есть IRC-канал, где разработчики и пользователи могут общаться, помогать друг другу и разбираться с вещами.

Answer 9

Вы можете попробовать использовать совместный инструмент картирования разума, например http://mind42.com/ Например, он не предназначен для моделирования диаграмм классов или занятий, но может помочь в сотрудничестве, когда обмен идеями имеет решающее значение.

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

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

Answer 10

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

Пусть вам поможет интерфейс, а не сражайтесь с ним.