Привет всем! Довольно часто можно услышать утверждение, что какая-то программа плохо спроектирована. Хочу задать Вам ламерский вопрос: как проектируются программы под Win32? У меня в этом плане серьезный недостаток в знаниях. А ведь мне хотелось бы не держать все устройство программы в памяти, а иметь схему программы, чтобы в случае необходимости можно было увидеть, на что повлияет изменение в одном месте программы. Да и в том случае, если я вернусь к разработке программы после некоторого перерыва (уже забыв ее устройство), мне гораздо проще было бы войти в работу, изучив ее схему, чем, изучая ее код. Единственная статья, которую я когда-то читал по этой теме, была опубликована в ZX-Ревю'92 (был когда-то такой журнал) в рубрике "Профессиональный подход". Там было описано нисходящее проектирование программы с построением блок-схемы программы. Этот метод еще можно применить при проектировании программ для MS-DOS (ну, и кое-где, под Win32). Но у меня не получается применить этот метод проектирования, в Win32. Например, не получается с его помощью описать взаимодействие между потоками или даже просто между обработчиками разных сообщений в оконной процедуре. Приходится держать все в памяти, а это, IMHO, не серьезно. В общем, что вы мне посоветуете? Что можно почитать по этой теме?
Oleg_SK Это слишком общий вопрос. Проектирование под Win32 как само проектирование - слишком специфично. Что касается Общего проектирования, то как обычно: 1. Распределение вида ресурсов определённого вида ведёться одним кодом (который часто носит название ядра или сервера) 2. Множество элементов одного вида называют классом, а сами элементы объектами (ООП) 3. Подсистема обработки ошибок обычно имеет 3 уровня: пользовательский системный, и критический. 4. UI проектируется максимально отделённо от самих компонентов... возможны различные схемы. 5. Компонентный подход неплохо идёт. (имееться ввиду не COM, а сам подход) Что почитать.... Книги есть. Но как бы все они написаны с точки зрения "разговора чашки за чаем"... А вот обучение - нет такой не видел.
Oleg_SK Как это не странно звучит - уменьшение объёма кода защёт создания универсальных подсистем РУЛИТ!!!! Оптимизация по скорости встречаеться редко.
Вопрос между прочем очень актуальный. Практически каждый начинающий программер или кодер спотыкаются об это. Например однажды мне нужно было написать мультитредную программу юзающую сокеты в очень извращенном виде, но сами понимаете блокнот не "трехмерный", пришлось обходится своим мозгом. Скорее всего где-то в инете есть фирма уже создавшая софт, который позволят проектировать средние и большие программы. Но такой программы чтоб она была небольшого размера и со здоровой функциональностью я не встречал. Если кто найдет, то пж-та скажите мне.
NoName В том то и дело. Вот еще одна причина этого: без грамотного проектирования очень трудно дать оценку трудоемкости проекта (особенно если у Вас нет опыта решения аналогичной задачи). А ведь одним из первых вопросов, которые задает Вам работодатель, будет вопрос о времени, которое потребуется для выполнения задачи. У меня был очень печальный опыт, связанный именно с моей неспособностью дать четкий ответ на этот вопрос. Edmond Спасибо.
Oleg_SK > IMHO для правильного ответа на этот вопрос нет необходимости вообще хоть как-то разбираться в программировании. Нужно просто знать что хочет услышать "работодатель": Не совсем по вопросу проектирования (а что это ? =))), но думаю будет полезно: Ален Голуб "ВЕРЕВКА ДОСТАТОЧНОЙ ДЛИНЫ, ЧТОБЫ… ВЫСТРЕЛИТЬ СЕБЕ В НОГУ" (Alen I. Holub. "Enough Rope to Shoot Yourself in the Foot.") - Эдвард Йордан "Смертельный марш" (Edward Yourdon "Death March") ЗЫ: А какой номер ZX-Ревю'92 ?
S_T_A_S_ Я похоже ошибся. Журнал, на самом деле, не за 1992г., а, похоже, за 1991г. Номера не знаю, т.к. у меня распечатка.
Хотя тема очень старая, я все-таки мимо пройти не смог. =) Проектирование программ штука действительно важная. Без проектирования можно писать разве что небольшие программки.И хотя программисты в одиночку пишут либо маленькие либо средние программы, умение проектировать может облегчить жизнь и сэкономить время. Есть книги по технологии программирования - их стоит почитать. Вот книги которые бы я порекомендовал посмотреть Совершенный код. Стива Макконелла - можно найти тут - http://infanata.org, и тут - http://torrents.ru. Иванова С.Г. Технология программирования - http://infanata.org, Этот сайт тоже стоит посмотреть - http://rusdoc.ru, раздел - Управление проектами.
Может быть имеется ввиду "проектирование интерфейсов" ? - это отдельная сущность, не связанная с совершенством кода или методиками управления проектами. Наверняка вам попадались программы, спроектированные плохо - они вроде бы делают то, что надо и ещё много чего, но пользоваться ими или невозможно или не хочется... Например, я на дух не выношу неро и пользуюсь всегда SmallCDWriter-ом. Плохо спроектированная программа - это программа, которая заставляет нажимать кучу кнопок, отвечать на дурацкие вопросы, подтверждать необходимость совершения каких-то действий (создатели таких программ считают пользователей олигофренами по дефолту) и у которых столько "полезных" функций, что добраться до "необходимых" затруднительно.
masm32 Плохо спроектированный интерфейс способен довести до истерики, точно Но это с ТЗ юзера В топике видимо речь идет о ТЗ кодера, то есть плохо спроектированная программа - это такая про которую говорят - "да, неплохо бы добавить то-то и то-то, но трогать страшно" Когда программа пишется у кодера в башке создаются всякие сложные замысловатые неочевидные конструкции с помощью которых он понимает алгоритмы и сценарии работы программы. Потом эти конструкции в башке исчезают, начинается новый проект, а программа остается. И если то что было в башке не выражено ясно и просто в исходнике - всё-приехали, другому кодеру легче заново переписать. Специфика программирования в том что исходник, как его не комментируй, обычно не отражает конструкции в башке, а отражает их голый результат. Я сейчас склонен считать что хорошо спроектированная программа - это что-то очень простенькое типа "хелло ворлд" где можно глядя на исходник сразу реконструировать контекст мозга кодера Все что большое и сложное - или бейте на простые куски (что обычно практически невозможно) или сохраняйте ее кодеров ибо после их ухода проекту конец. С практической ТЗ - для того чтобы себя не материть впоследствии - не ленитесь пишите больше всякой отладочной фигни, логгеры, чекеры, думперы, вспомогательные утилиты - чем больше их, тем опытнее программист.
Разбить на более простые куски (кстати, почему невозможно?) - в этом и есть разрешение проблемы. Объектно-ориентированный подход, но такой при котором "куски" (или классы) можно переносить из проекта в проект.
Monk Это книга к проектированию и системному анализу не имеет практически никакого отношения(за итскючением одной главы), она затрагивает в основном аспекты реализации. По проектированию читайте Г. Буча и К. Пармана, это уже классика. При проектировании часто используется нотация UML, он позволяет описать всё, что требуется. Я с его помощью обычно строю диаграммы классов и диаграммы взаимодействия. Варианты использования и сценарии, в своей небогатой практике в области анализа и проектирования, я пишу просто текстом(хотя UML позволяет описать и это). Для небольшого проекта, примерно до 5-6 тыс. строк, мне хватает простой диаграммы нарисованной на бумаге, главное выделить правильно основные независимые сущности, на них уже нанизывается весь остальной функционал без особых проблем. Здесь часто бывают полезны шаблоны проектирования. Для маленьких проектов вообще ничего не строю, сразу в коде набрасываются интерфейсы классов и всё становится понятно. Вот кстати последним знаменитым примером, который показывает результат пренебрежительного отношению к проектированию, либо вообще отсутствие этого этапа, является QIP 2005(не путать с QIP Infum). Кто не в курсе, автор прекратил его разработку как раз потому, что полученный объём кода уже не поддавался дальнейшему развитию и расширению, о чём автор и заявил:
AsmGuru62 В каких-то случаях это работает, кстати и без всякого ООП. Просто есть такие куски кода которые с минимальными переделками можно таскать из проекта в проект. Но большинство кода в проекте все же уникально.
банально. любая програмка в винде (приложение) - это набор процессов, оные суть - ловцы сообщений системы (если програмка с окошками - опрос сообщений системы и засылку их себе проводишь ручками). типа за классы (ООП) просто куча удобных (самолепных) структур и подпрограмок для работы с оными в виде разнообразных inc-ов с шарами на внешнии функции апосля включаемых библиотек... хотя даж проще тупо с кодом сих "классов".
Начните участвовать в development и design соревнованиях на topcoder.com, и вы поймете как проектируются программы.
