Привет. Много думал. Как начинающий спрошу..
Вот приступая к разработке программы, вы ведь обдумываете её функционал, структуру, в конце концов интерфейс. Так вот, в голове постоянно это сложно держать. Ну как бы не сложно..Даже не знаю как сказать.. Вот кто-либо из Вас использует граф.редакторы, тексовые файлы чтоб изложить суть проги, функционал: там хедеров своих и тд. Рисует интерфейс сначала где-то на макете?
Либо просто держит в мыслях?
Кто как вообще приступает к разработке программ?
Поделитесь мнением, поможете и мне, просто как-бы сказать незнаю как это все делают. Мне так, для общего представления..

Спасибо за помощь и понимание. 

Это сообщение отредактировал(а) papochka - 3.12.2009, 20:07

Лучше всего начинать с самого низу, - там где еще не нужно создавать ничего визуального и желательно все вкидывать в классы, затем завязывать их друг за друга поднимаясь вверх, тем самым создавая себе возможность быстрых поправок без переделывания всего кода.
Затем только все завязывать с визуальными компонентами...
В принципе основные принципы будущей программы легко обдумывать прямо в голове, затем при программировании обязательно будут возникать не предвиденные трудности, которые затем возможно даже придется рисовать на бумаге, что бы правильно осмыслить все тонкости определенной задачи...

Проектирование ПО - штука объёмная. В 2-х словах и не раскажешь...

Сам себя часто ловлю, что надо развиваться в этом направлении. Но дефицит времени... 

Итак, если говорить об объектно-ориентированном программировании и одноимённом проектировании, то никакими спец. средствами (как они там "по-умному" называются? CASE?) я лично не пользуюсь. Ибо нафиг надо.  Монструозно-избыточный, тем не менее допускающий неточности и разночтения, UML, простите, "фтопку". Да и вообще, «The code is the design.»  Так на листочке примерно "поднакидать" диаграмки. Прикунуть, что называется "*** к носу".  Понятно для себя чтоб было. 

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

Насчёт интерефейса. Можно, конечно, и на бумаге рисовать. А что, "бумага терпит" (с)  Но если есть редактор графического интерфейса для соотв. каркаса (Qt Designer для Qt, например) - лучше сразу там начинать. Преимущества компьютерной обработки данных (undo/redo против ластика  и т.п.) никто не отменял.  


А это уже, уважаемый, от языка зависит.  По крайней мере количество трудностей и их масштаб... Даёшь холивар!

Это надо обсуждать, я уже показывал как всё это выглядит в диаграммах UML, псеводокодах, XML, графических схемах и т.п. Только что-то мои темы по проектированию ПО не сыскали заслуженной славы.  

Шаблоны проектирования это хорошо, но не совсем. Важны ещё сами задумки необходимые для реализации в программе и способы их упорядочивания.

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

Может мы их и придумываем, но они от этого становятся реальными. Вопрос как наиболее оптимальным способом их преодолеть.

Начинать разработку программы (или модуля большого проекта) нужно с написания функциональных требований. Именно написания, в любом виде. Что должна делать, что не должна. Потом прописать взаимодействие с пользователем. Нарисовать интерфейс, ясно представляя, как оно должно работать с точки зрения полозователя. Потом можно немножко попредставлять дизайн, примерно накидать кто чем рулит. Тоже письменно, т.к. это заставляет оттачивать формулировки, и многое становиться ясным, многие проблемы вылезают. Это все вполне банально и в зубах навязло, но реально помогает. Другое дело, что обычно это делать влом.  Лично я это делаю только для сложных модулей, когда сразц в голове нет ясной картины. Или как спецификацию для других программистов. Спец.средствами (UML и прочая) никогда не пользовалась, хотя изучала и пробовала, но посчитала излишними (для своих задач). 
Т.е. проектирование нужно обязательно, но необязательно формальное.

нет $%#@, сразу сажусь и пишу код  

так то были темы по проектированию ПО?  



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

Это сообщение отредактировал(а) Lazin - 4.12.2009, 10:06

Конечно, иначе с чего бы мне их было создавать, овнокодить я и так умею.  

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

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

Это уже давно известно, что продвинутым прогерам важно то, что хочешь получить, а не то как хочешь это получить, так как второе не вызывает осложнений. Стоит ли говорить о таких банальностях? Стоит, конечно, вот только как я уже сказал, надо не думать, надо прыгать. И опять же, хоть я это и сказал, я понимаю, что меня в полной мере не поймут, те кто не последуют совету. Но если они следуют совету, то и совет им вовсе не нужен, ведь они и так делают, то что нужно.

а я думал ты это не серьезно... так ты это серьезно? шаблоныоттенки создателей и все такое!?!


тебе знакомо слово ирония?

это основное отличие между профи и любителями, первым важен результат, вторым - процесс
просто там где один разработчик на ваяет сложную архитектуру, с шаблонными методами, синглтонами и абстрактными фабриками, напишет несколько десятков тыс. строк кода в десятках файлов, другой подумает(!!!) до того как писать что-либо и поймет, что здесь по сути должно происходить чтение из файла в такую структуру данных с последующей обработкой и экспортом в определенный формат(к примеру) и сделает минимальную по сложности реализацию из всех возможных, которая на 2х экранах будет помещаться 
вот это, на мой([irony]единственно верный, хочу заметить[/irony]) взгляд и есть правильный подход, так как сделать проще, на самом деле сложнее, и что-бы сделать более простую(а значит, содержащую меньшее количество ошибок и более простую для последующего развития) реализацию, нужно предварительно подумать, куда прыгаешь, прежде чем прыгать 


Это сообщение отредактировал(а) Lazin - 4.12.2009, 11:07

Тега irony на винграде нет. Представь, что ты новичок в программировании. Можешь ли ты сразу написать код хорошо? Да, даже если не новичок. Что важнее, краткость кода или его понятность программистам? Когда уровни абстракций вместо уменьшения количественной и увеличения качественной составляющей начинают действовать наоборот?

Я вот встречал примерно такие ответы, - "Ничто не заменит хороший вкус и что-то там ещё". В общем, всё не так однозначно, и совет подумай так же ценен ("ценен"), как и совет делай.

Добавлено через 2 минуты и 17 секунд
P.S. если бы мы сами ещё следовали своим советам, цены бы нам не было 

Это сообщение отредактировал(а) unicuum - 4.12.2009, 11:18

спасибо Кэп.

когда я был новичком в программировании, я такими вопросами, как ТС, не задавался  

одно с другим связано, разве нет?

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

Добавлено через 2 минуты и 17 секунд
одним словом, преждевременная пессимизация - зло  

Соблазн уж больно велик.  


Да, когда С/С++ разработчики начинают рассуждать о модулях, давиться от смеха становиться трудно.  


Отнюдь. Просто речь идёт о первом этапа разработки ПО - сбор и анализ требований. А мы тут больше как-то  о втором...


  Я в ауте...

kemiisto, вроде Комодератор, а ведешь себя как типичный тролль 

По поводу проектирования интерфейсов есть неплохая книжка Алана Купера "Психбольница в руках пациентов"
Уже одно название доставляет 

Как правило, всё продумать нельзя и на этапе реализации могут появиться новые требования. Некоторые могут быть не совместимы с текущей системой. Как быть, перепроектировать почти с ноля или делать как попало?

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

Вот, к примеру, реализация кода шаблона проектирования Property Container.

Могли бы просто написать функции получить и установить. Но нет, использовали шаблоны C++. Если развивать эту мусль, так можно и индексаторы в свойствах реализовать. Однако вопрос в другом, целесообразно ли? Как определить, что мы перегнули со сложностью?   

В этой ветке по-другому получается редко.  


Стоит читать?

это так, художественная литература
читать можно, когда думать лень

по моему это ерунда какая-то, шаблон property - бесполезен, так как он не позволяет задать свои get/set методы для свойства, поэтому смысла я в нем не вижу, а второй вариант - довольно утомителен, в каждом новом классе писать одно и то-же?
я бы сделал что-то вроде:


что-бы можно было использовать так:

код скорее всего не рабочий, это просто иллюстрация идеи )

с помощью здравого смысла и такой-то матери  

Это сообщение отредактировал(а) Lazin - 4.12.2009, 15:34

Буду судить своей практики.

Проектированием могу заниматься только тогда, когда на это есть время! В рабочем режиме, как правило требуют результат "Димон, уже вчера надо было! У клиентов малвара бабло ворует, а ты тут думаешь!!!".

Одним словом встает ряд вопросов :
1) "Для кого пишется программа ?" 
2) "В каких условиях будет работать программа и всегда ли она будет работать только в этих условиях ?"
3) "Как быстро нужно эту программу написать ?"
4) "Что является самым главным в программе, что принесет заказчику бабло\экономии времени\качество хранения данных ?"
5) И самый главный вопрос, когда принято решение "ПИСАТЬ программу!" , это "Что будет если моя программа откажет ?", т.е. зная каковы последствия будут ожидать нас, мы будем знать как правильно завершится, т.е. что нужно сделать СТОПУДОВО !!!

Как правило клиент заказывает видя для себя мистические выгоды, что будут храниться документы, что программа ему всегда напомнит обо всем. Но он забывает что он может ноутбук\комп выключить или забыть включить! Или же админ почистил комп и с нес с автозагрузки и она у него пропала! Условий работы масса!!!

Первый и главный вопрос, считаю п.1. Потому что если клиент не знает какую выгоду принесет прога, то он будет тебе парить мозг!!! А если он скажет "Знаю что компы посчитают эту хрень за 1 час, а я бы считал за 2 дня" или "Пока эти документы подготовлю, у меня уже пенни по ...., вот если ваша прога в нужный день за эн дней до срока сделает, то.... 
Только зная с кем рабоешь ты будешь четко знать - будет ли он хавать тебе мозг ? Сделанная четко по целям клиента прога дает тебе ФАНАТОВ , а это твои бабки!!!

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

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

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