Как Вы разрабатываете, делаете набросок и копируете сложную часть программного обеспечения? Каковы некоторые рабочие процессы или инструменты, которые могут использоваться, чтобы сделать так? [закрытый]

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

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

В зависимости от размера моделируемой проблемы может оказаться полезным использование инструмента UML. Но обычно они очень строгие и негибкие. Особенно, когда я решаю изменить дизайн своего кода, мои диаграммы UML очень быстро теряют синхронизацию.Что мне действительно нравится, так это конструктор классов Visual Studio, потому что он работает наоборот: я могу поместить на него свой код, и он генерирует его визуальное (простое UML) представление.

Мой "пошаговый" процесс был бы таким:

1. Создайте прототип. Он не должен делать много, во многих случаях достаточно перетащить несколько элементов управления в дизайнере формы. Затем пройдитесь по прототипу с клиентом/конечным пользователем. (Это важная часть - если вы просто создадите прототип и бросите его на стену, толку от него не будет). Объясните, как, по вашему мнению, будет работать программа, когда вы показываете прототип и послушайте, что говорит заказчик. Опять же, слушать важнее, чем объяснять. После этого у вас должно быть твердое понимание того, что нужно заказчику.
2. Теперь я обычно беру бумагу и карандаш и начинаю набрасывать высокоуровневую структуру модуля. Возможно, также важные классы, но не все до последней детали реализации. После этого шага я знаю, какие модули мне нужны, какова ответственность каждого модуля, как я могу протестировать каждый модуль.
3. Реализация выполняется так, как вы знаете (по крайней мере, я делаю это более или менее так, как вы описали). Но сначала вы реализуете только основную базовую функциональность. В противном случае вы пропустите критически важную функциональность, потому что будете слишком заняты добавлением колокольчиков и свистков.
4. Повторяйте и повторяйте: теперь у вас есть программа с ограниченной функциональностью, вернитесь к своему заказчику, покажите ее, дайте им поиграть с ней. Посмотрите, как они пытаются ее использовать: Где они терпят неудачу? Что они ищут и не могут найти?

Книжный совет: Release It

Как насчет этого?

http://borkware.com/quickies/single?id=73

или этого

http://www.cs.utah.edu/dept/old/texinfo/emacs19/emacs_26.html#SEC184

$msg = 
   chr(0x20) // Size = 32 (4+1*28)
  . chr(0x1) // Type = 1
  . chr(0x0) // ReqI=0
  . chr(0x1) // NumC=1
    . chr(0x1) . chr(0x0) // node=1
    . chr(0x2) . chr(0x0)  // lap=2
    . chr(0x3) // puid=3
    . chr(0x5) // pos=5
    . chr(0x10) // info=16
    . chr(0x0) //sp3=0
    . chr(0x0) . chr(0x0) . chr(0x1) . chr(0x0) // x=65536
    . chr(0x0) . chr(0x0) . chr(0x2) . chr(0x0) // y=65536*2
    . chr(0x0) . chr(0x0) . chr(0x3) . chr(0x0)  // z=65536*3
    . chr(0x0) . chr(0x20) // speed=8192
    . chr(0x0) . chr(0x10) // dir=4096
    . chr(0x0) . chr(0x8) // heading=2048
    . chr(0x0) . chr(0x4) // AngVel=1024
;

$IS_MCI = unpack('CSize', $msg);
if ( strlen($msg) < $IS_MCI['Size'] ) {
  die("not enough data");
}
$IS_MCI += unpack('CType/CReqI/CNumC', substr($msg, 1));
$IS_MCI['Info'] = array();

for($i=0; $i<$IS_MCI['NumC']; $i++) {
  $data = substr($msg, 4+($i*28), 28);
  $IS_MCI['Info'][] = unpack('vNode/vLap/CPLID/CPosition/CInfo/CSp3/lX/lY/lZ/vSpeed/vDirection/vHeading/sAngVel', $data);
}
print_r($IS_MCI);

печатает

Array
(
    [Size] => 32
    [Type] => 1
    [ReqI] => 0
    [NumC] => 1
    [Info] => Array
        (
            [0] => Array
                (
                    [Node] => 1
                    [Lap] => 2
                    [PLID] => 3
                    [Position] => 5
                    [Info] => 16
                    [Sp3] => 0
                    [X] => 65536
                    [Y] => 131072
                    [Z] => 196608
                    [Speed] => 8192
                    [Direction] => 4096
                    [Heading] => 2048
                    [AngVel] => 1024
                )

        )

)

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

• Предполагается, что пакет ($ msg) был полностью прочитан до запуска кода. Может потребоваться считывание только тех частей, которые в настоящее время необходимы (тогда не требуется использование substr ()). Или, по крайней мере, будьте готовы к тому, что сообщение может прибыть несколькими порциями.
• Он также воспринимает параметры размера/количества как само собой разумеющиеся, т.е. не проверяет, являются ли значения допустимыми и достаточно ли данных доступно. Это определенно то, что ты должен изменить. Размер должен быть между 0... 228, NumC должен быть между 0... 8 и оба значения должны соответствовать друг другу и так далее.
• Также ознакомьтесь с идентификаторами формата, которые я использовал при распаковке (). Для слова я использовал v , которое означает "беззнаковый короткий (всегда 16 бит, маленький порядковый номер байта ). Но для int я использовал l : «signed long (always 32 bit, machine byte order )». Это нормально на моей машине. Но найдите в документации протокола полноту данных.

Testdata в $ msg был взят из результата

__declspec(align(1)) struct CompCar // Car info in 28 bytes - there is an array of these in the MCI (below)
{
    word    Node;       // current path node
    word    Lap;        // current lap
    byte    PLID;       // player's unique id
    byte    Position;   // current race position : 0 = unknown, 1 = leader, etc...
    byte    Info;       // flags and other info - see below
    byte    Sp3;
    int     X;          // X map (65536 = 1 metre)
    int     Y;          // Y map (65536 = 1 metre)
    int     Z;          // Z alt (65536 = 1 metre)
    word    Speed;      // speed (32768 = 100 m/s)
    word    Direction;  // direction of car's motion : 0 = world y direction, 32768 = 180 deg
    word    Heading;    // direction of forward axis : 0 = world y direction, 32768 = 180 deg
    short   AngVel;     // signed, rate of change of heading : (16384 = 360 deg/s)
};

__declspec(align(1)) struct IS_MCI // Multi Car Info - if more than 8 in race then more than one of these is sent
{
    byte    Size;       // 4 + NumC * 28
    byte    Type;       // ISP_MCI
    byte    ReqI;       // 0 unless this is a reply to an TINY_MCI request
    byte    NumC;       // number of valid CompCar structs in this packet

    CompCar Info[1];    // example: one element, fixed
};

int _tmain(int argc, _TCHAR* argv[])
{
  struct IS_MCI mci = {
    32, 1, 0, 1,
    { 1, 2, 3, 5, 16, 0, 65536, 65536*2, 65536*3, 8192, 4096, 2048, 1024 }
  };

  WSADATA wsaData;
  WORD wVersionRequested = MAKEWORD( 2, 2 );
   int err = WSAStartup( wVersionRequested, &wsaData );
  if ( err != 0 ) {
      /* Tell the user that we could not find a usable */
      /* WinSock DLL.                                  */
      return 1;
  }

  SOCKET s = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
  sockaddr_in addr; 
  addr.sin_family = AF_INET;
  addr.sin_addr.s_addr = inet_addr( "127.0.0.1" );
  addr.sin_port = htons( 8081 );
  if ( 0!=connect( s, (SOCKADDR*) &addr, sizeof(addr) ) ) {
    printf("%X ", WSAGetLastError());
    return 0;
  }
  send(s, (const char*)&mci, sizeof(mci), 0);
  shutdown(s, SD_BOTH);
  closesocket(s);
  return 0;
}

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

Другие ответы уже дали некоторые намеки на этот счет; Однако важным аспектом, которым не следует пренебрегать, является то, что перед началом проектирования вы должны фактически записать то, что ваше программное обеспечение должно делать в форме спецификации требований к программному обеспечению :

Спецификация требований к программному обеспечению является полным описанием поведение системы, которая должна быть разработан. Он включает в себя набор использования случаи, которые описывают все взаимодействия, которые пользователи будут иметь с программное обеспечение. Также известны сценарии использования в качестве функциональных требований. В в дополнение к сценариям использования, SRS также содержит нефункциональные (или дополнительные) требования. Нефункциональные требования: требования, накладывающие ограничения о разработке или осуществлении (например, как разработка исполнений требования, стандарты качества или зависимости проектирования).

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

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

Это потому, что во многих областях есть точное знание заранее. Что нужно делать, какие правила, какие законы физики, какие нормы нужно учитывать. Именно поэтому можно спроектировать все до последнего гвоздя.

С программным обеспечением все совсем по-другому. Вы можете делать все, что хотите. Вы можете достичь чего угодно, и никто не сможет сказать вам, что это хорошо или плохо. Потому что нет никаких стандартов. Только субъективное мнение.

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

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

Мне не нужны мнения.

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

Я бы хотел чего-то конкретного: Диаграммы? Карты? Инструменты? Техники? Пошаговый процесс?

Что сработало для большинства, так это:

1. Вовлекайте пользователей с самого начала в ваш проект. Регулярно собирайте обратную связь, чтобы корректировать свой курс.

2. Будьте проворными и следуйте некоему итерационному процессу. Сначала вы делаете набросок пользовательского интерфейса. Получите обратную связь. Затем вы реализуете общую функциональность. Получите обратную связь. Скорректируйте свой курс. Реализуете еще несколько функций. И так далее. Рано или поздно будет достаточно мяса для v.1.

Если вам совершенно необходимы строгие указания, то используйте UML (Unified Modeling Language) для графиков и диаграмм и примите RUP (Rational Unified Process) или его аналоги. Вы можете следовать Scrum, в нем также задействованы некоторые организационные мероприятия.