Подходы к проектированию больших программ - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Пишу (думаю что) грамотно, оптимально. Но именно для того, чтобы этой оптимальности достичь, приходится некоторые функции по несколько (десятков) раз переписывать, по-разному код компоновать, добавлять и удалять переменные.
Это нормально. Так и должно быть.
Ведь при проектировании техники сначала над проектом работают конструкторы, потом технологи, потом непосредственно производство. И здесь, при программировании, хочется всю работу разбить на этапы - сначала написать блоки программы на бумаге, решив, что к чему; какой кусок за что должен отвечать; выстроить все от и до - за что какая функция отвечает, с кем взаимодействует. И только после этого переходить уже непосредственно к реализации всего этого в коде.
Просто мне не верится, что все работают так, что сразу создают новый файл в метаэдиторе и начинают набрасывать код, дополняя и расширяя его так, как в текущий момент сработала фантазия... Хочется поэтапно - сначала спланировать программу от и до, потом писать, как будто автомобиль из конструктора собираешь - все детальки друг к другу подходят и обеспечивают взаимодействие.
Кто сказал что должно быть сначала? Ваши суждения противоречат сами себе. Если Вы еще до момента написания программы уже досканально знаете архитектуру приложения, модули из которых оно состоит, то с чем взаимодействует и пр.пр., то программировать Вам больше нечего, так как приложение по всей видимости уже написано:)
Программирование это не строительство моста по чертежу. Это сам чертеж. Строительством занимается компилятор за пару секунд. Следовательно создавать чертеж для чертежа бессмыслица.
Как я понял, затруднения вызывают большие, трудоемкие разработки. Срок 58 месяцев потрясает. По моим представлениям, такие сроки разработки до ввода в эксплуатацию - что-то из ряда вон. Об организации работ автор не сообщал. Возможно, там и находятся причины затруднений.
Обычно объем работы определяющим образом связан с составом исполнителей и их количеством. Создаваемая для этого организационная структура (необязательно формальная, административная) сама уже облегчает проектирование приложения. В силу специализации членов, собранных для написания программы или программного комплекса, а также ограничений их взаимодействия, возникает деление работы на части, по структуре и по времени. Вплоть до межотраслевых проектов.
Более конкретно сказать нечего, лишь общие соображения, применимые повсюду:
- есть программирование снизу, есть сверху, есть и другие, например, "экстремальное программирование";
- больше 6 человек в непосредственном управлении одного - максимум для этого одного. Если требуется больше занятых в проекте - надо вводить иерархическую структуру их взаимодействия;
- для описания (проектирования и документирования) сложных систем есть зубодробительная по возможному уровню подробности методика, созданная и эксплуатируемая внутри IBM, применявшаяся и в СССР, https://ru.wikipedia.org/wiki/HIPO
Всем привет.
Есть такая проблема. Когда пишу программы, мне сложно определиться с ее конструкцией. Если программы простые - до 1,5-2 тыс. строк - все без проблем рисуется, весь проект держится в голове и на выходе получается хорошая программа. Если же ТЗ требует большей функциональности (появляются панели, интерактивное общение с пользователем, сложные алгоритмы входа и т.д.), то начинаются проблемы. Программу переписываю по несколько раз, меняя функции местами, изменяя функциональность блоков и т.д. до тех пор, пока заказчик не напишет "возвращай деньги, 58 месяцев уже пишешь, ******* "
Искал различный материал по проектированию приложений, много читал - и статей, и книг, но годного материала для себя не нахожу - либо сухая теория, либо не то, что нужно.
В связи с этим вопрос: поделитесь опытом, кто как решает такие проблемы? Как проектировать эти программы?
Дай тех задание посмотреть, которое большое .
Просто мне не верится, что все работают так, что сразу создают новый файл в метаэдиторе и начинают набрасывать код, дополняя и расширяя его так, как в текущий момент сработала фантазия... Хочется поэтапно - сначала спланировать программу от и до, потом писать, как будто автомобиль из конструктора собираешь - все детальки друг к другу подходят и обеспечивают взаимодействие.
Хм... А я вот именно так и делаю. И, на мой взгляд, одно другому не мешает - планирование идет сразу вместе с разработкой.
Имеется давно написанный основной "каркас" советника на основе абстрактных классов-интерфейсов. Если его откомпилировать - получается "пустой" советник, который вызывает процедуру анализа, но ничего в ней не анализирует, и никаких решений не принимает. В этом шаблоне во время инициализации вызывается специальная функция получения объекта, который я называю "фабрика частей эксперта". Функция должна возвратить указатель на объект, у этого объекта есть абстрактные методы, необходимые для принятия решений. Изначально эта функция возвращает NULL, соответственно, функции принятия решений остаются пустыми, решения не принимаются, приказы на сервер не отправляются.
Возникает идея - сразу открываю редактор, создаю новый файл советника, подключаю через #include основной шаблон, и пишу эту самую функцию, которая создает объект фабрики частей эксперта, и возвращает указатель на него. Все. "Советник типа написан". Да, он ничего не делает - потому, что фабрика частей эксперта - пока ничего не возвращает. Основная работа заключается в написании этой самой фабрики, которая будет возвращать генератор входов, определитель ТП-СЛ, менеджера ММ, и так далее.
То есть, я придерживаюсь разработки "от общего к частному". Изначально пустой эксперт постепенно заполняется функциями.
Схемы и описания - у меня появляются вместе с написанными блоками - чаще всего в виде пространных комментариев в тексте программы. Изредка - в виде отдельных Visio-документов.
Хм... А я вот именно так и делаю. И, на мой взгляд, одно другому не мешает - планирование идет сразу вместе с разработкой.
Имеется давно написанный основной "каркас" советника на основе абстрактных классов-интерфейсов. Если его откомпилировать - получается "пустой" советник, который вызывает процедуру анализа, но ничего в ней не анализирует, и никаких решений не принимает. В этом шаблоне во время инициализации вызывается специальная функция получения объекта, который я называю "фабрика частей эксперта". Функция должна возвратить указатель на объект, у этого объекта есть абстрактные методы, необходимые для принятия решений. Изначально эта функция возвращает NULL, соответственно, функции принятия решений остаются пустыми, решения не принимаются, приказы на сервер не отправляются.
Возникает идея - сразу открываю редактор, создаю новый файл советника, подключаю через #include основной шаблон, и пишу эту самую функцию, которая создает объект фабрики частей эксперта, и возвращает указатель на него. Все. "Советник типа написан". Да, он ничего не делает - потому, что фабрика частей эксперта - пока ничего не возвращает. Основная работа заключается в написании этой самой фабрики, которая будет возвращать генератор входов, определитель ТП-СЛ, менеджера ММ, и так далее.
То есть, я придерживаюсь разработки "от общего к частному". Изначально пустой эксперт постепенно заполняется функциями.
Схемы и описания - у меня появляются вместе с написанными блоками - чаще всего в виде пространных комментариев в тексте программы. Изредка - в виде отдельных Visio-документов.
:) Вы используете так называемые шаблоны проектирования.
...
Для топик стартера, вот тут почитайте http://citforum.ru/SE/project/pattern/