20+ лет программирования - ассемблеры (разных платформ, +разработка железа), pascal, delphi, perl, c#, java. Большие проекты.

Наибольший вклад в теги

Все теги (5)

Лучшие ответы пользователя

Все ответы (3)
  • Как писать большие проекты?

    @islk
    20+ лет программирования
    Вообще говоря, проектирование больших систем - это целый большой раздел науки/технологии программирования, который довольно отчетливо выделяется из программирования вообще, мало зависит от других разделов и интенсивно развивается. Существуют разные подходы и разные более-менее устоявшиеся технологии, даже стандартные технологические процессы. Используются специальные интеллектуальные инструменты (см. напр. UML) и соответствующие программные инструменты. Существует, активно используется и развивается множество типовых проектных решений для разных случаев жизни - шаблоны (aka паттерны) проектирования, знание и использование которых которых ускоряет процесс и снижает вероятность неудачных решений - см. напр. Гамма, Хелм и др. - "Приемы объектно-ориентированного проектирования - паттерны проектирования". Существуют различные подходы в организации самого процесса проектирования. Эта наука (проектирование программ) близко лежит к организации бизнеса, используется много общих подходов (в частности, в проектировании бизнес-процессов используется BPML - родной брат UML)
    Так что в два слова ответить на ваш вопрос трудно. Думайте, рисуйте схемы, погуглите, почитайте что-то по этим темам (хоть с википедии начните - https://ru.wikipedia.org/wiki/UML), пытайтесь что-то хотя бы частично в своей работе использовать.
    С этими темами познакомиться хотя бы поверхностно следует любому программисту, ну а если вы планируете профессиональную карьеру - так более-менее хорошо их знать - просто обязательно.
    Ответ написан
    Комментировать
  • С чего начать разработку приложения для работы с БД?

    @islk
    20+ лет программирования
    Разобраться в сущностях предметной области - с чем мы имеем дело. Какие у них, у сущностей, есть свойства, какие из них для нас важны, а какие нет. Как эти сущности связаны друг с другом. Концептуальная модель предметной области, по-хорошему оформляется графической схемой с пояснениями. Потом разобрать по возможности все варианты использования - кто будет использовать, зачем, какая информация должна быть получена и какие изменения в данных должны произойти . Use cases называется. Потом уже исходя из этого всё остальное, что здесь сказано.
    Если этот этап пропустить, то за день до сдачи запросто можно обнаружить, что имеющаяся структура БД в принципе не позволяет решить ту задачу, которая для заказчика важнее всего, и что структуру данных надо переделывать, а весь написанный под нее код - переписывать с нуля.
    Ответ написан
    Комментировать