Как проектировать разработку скрипта

Тема в разделе "Как сделать...", создана пользователем QuZ, 15 апр 2012.

  1. QuZ

    QuZ Постоялец

    Регистр.:
    18 июл 2009
    Сообщения:
    74
    Симпатии:
    49
    Добрый день. Долго думал, где разместиь топик. По сути, хотел-бы обсудить кто-как занимается разработкой достаточно сложных скриптов. Какими методами пользуется для составления примерного плана работы и т.д. Вообщем, итересным является сам организационный момент написания скрипта. Не думаю, что люди написав авторизацию, регистрацию, работу с куками сразу начинают писать код, не продумывая как лучше реализовать, тот список вопросов, которые возникают во время продумывания работы, несколько вариантов решения какого-то куска кода... Скорее всего и базу просто так не пишут, на бум, т.к. потом реструктуризацию ее делать постоянно - не лучший вариант.
    Я половину всего это веду в аналоге, записывая на листы, тетради, отдельно описываю структуру базы данных, с описанием, какая колонка за что отвечает.. Но при каких-то изменения приходится сильно переписывать какие-то элементы. Пытаюсь разбить задачу на подзадачи, среднего объема выполняемых элементов, для них беру обычные 12-ти листовые тетради и в них делаю описание работы с начала, а с другой стороны - список вопросов, которые надо решить.. Проблемы возникают, когда несколько вариантов реализации получается и список вопросов или взаимодействий для этих вариантов отличается..
    Программирую на 1с, в нем рисую для общего понимания окна с их взимодействием, как наиболее простой вариант написания примерного гуи, но на вебе не всегда это можно реализовать простым хтмлом, приходится потом задумываться, или перерисовать окна взаимодействий, или использывать жквери, например. Может есть что-то более удобное с точки зрения веба для этих целей, т.к. хочется достаточно подробно и одновременно схемитично реализовать гуи для скрипта.
    Вообщем, может кто опишет свои способы проектирования скриптов, думаю, многим это было-бы интересно, и думаю, что это самая трудная часть в написание скриптов.

    Для списка вопросов использую отдельную тетрадь, в которых ссылаюсь на номер тетради, страницу и саму проблему. Но фильрация потом по этим данным того, что еще актуально и выбранного способа решения задачи - совсем не удобная))
    Спасибо.
     
  2. t3s

    t3s

    Регистр.:
    16 фев 2008
    Сообщения:
    719
    Симпатии:
    290
    наверное, в первую очередь нужно уточнить - что значит "написание скриптов"
    создание веб-проекта? написание парсера? просто потренироваться? что-то другое?
    надеюсь что первое - это самое интересное (имхо), но и самое-сковывающее-руки-определенными-рамками

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

    а по поводу "тетради" вспомнилась старая фраза - "учитесь, други мои, писать алгоритмы на бумаге... и только потом хватайтесь за код"

    зы
    не против что перенес топик? просто данный раздел лучше подходит
     
  3. QuZ

    QuZ Постоялец

    Регистр.:
    18 июл 2009
    Сообщения:
    74
    Симпатии:
    49
    Да. Спасибо. Долго сам думал, в каком разделе это лучше разместить. Думаю - оптимально.. Работа с людьми - это менеджмент. По сути, для любой организации он один и тот-же. Принципы его. Как я понял, у Вас есть опыт написания алгоритмов. Но бумажный носитель не самое же эффективное средство. Или я ошибаюсь? Дизайнеры, СЕОшники, Верстальшики - это те люди, которые подключаются к проекту после создания глобальной его идеи и разработки ТЗ для каждого ( В любой форме).. Но сама основа то?
     
  4. t3s

    t3s

    Регистр.:
    16 фев 2008
    Сообщения:
    719
    Симпатии:
    290
    есть такая штука как система контроля версий (svn) - но это когда проект в стадии работы

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