Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > C/C++: Общие вопросы > Разработка программ

Автор: papochka 3.12.2009, 19:40

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

Автор: SVN74 4.12.2009, 01:02

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

Автор: kemiisto 4.12.2009, 01:56

Цитата(papochka @  3.12.2009,  20:40 ) Кто как вообще приступает к разработке программ? Проектирование ПО - штука объёмная. В 2-х словах и не раскажешь... Сам себя часто ловлю, что надо развиваться в этом направлении. Но дефицит времени...  Итак, если говорить об объектно-ориентированном программировании и одноимённом проектировании, то никакими спец. средствами (как они там "по-умному" называются? CASE?) я лично не пользуюсь. Ибо нафиг надо.  Монструозно-избыточный, тем не менее допускающий неточности и разночтения, UML, простите, "фтопку". Да и вообще, «The code is the design.»  Так на листочке примерно "поднакидать" диаграмки. Прикунуть, что называется "*** к носу".  Понятно для себя чтоб было.  Полезным может оказаться знание шаблонов (паттернов) проектирования. И антипаттернов тоже.  И опыт нужен. Так как тут область эмпирическая. Чётких законов нет, но есть некий свод удачных и (им в противоположенность) порочных практик. Но всего не опишешь... Насчёт интерефейса. Можно, конечно, и на бумаге рисовать. А что, "бумага терпит" (с)  Но если есть редактор графического интерфейса для соотв. каркаса (Qt Designer для Qt, например) - лучше сразу там начинать. Преимущества компьютерной обработки данных (undo/redo против ластика  и т.п.) никто не отменял.   Цитата(SVN74 @  4.12.2009,  02:02 ) затем при программировании обязательно будут возникать не предвиденные трудности А это уже, уважаемый, от языка зависит.  По крайней мере количество трудностей и их масштаб... Даёшь холивар!

Автор: unicuum 4.12.2009, 05:37

Это надо обсуждать, я уже показывал как всё это выглядит в диаграммах UML, псеводокодах, XML, графических схемах и т.п. Только что-то мои темы по проектированию ПО не сыскали заслуженной славы.   Цитата(kemiisto @  4.12.2009,  01:56 ) Полезным может оказаться знание шаблонов (паттернов) проектирования. И антипаттернов тоже.  И опыт нужен. http://extracoder.com/index.php?q=node/18 это хорошо, но не совсем. Важны ещё сами задумки необходимые для реализации в программе и способы их упорядочивания.

Автор: GremlinProg 4.12.2009, 05:55

Цитата(kemiisto @  4.12.2009,  03:56 ) А это уже, уважаемый, от языка зависит.  По крайней мере количество трудностей и их масштаб... Даёшь холивар! непредвиденные трудности могут и "на спичках" возникнуть, врят ли тут стоит винить какой-то конкретный язык, т.к. все эти трудности мы себе либо придумываем сами, либо наследуем придумки от предков

Автор: unicuum 4.12.2009, 06:07

Цитата(GremlinProg @  4.12.2009,  05:55 ) т.к. все эти трудности мы себе либо придумываем сами, либо наследуем придумки от предков  Может мы их и придумываем, но они от этого становятся реальными. Вопрос как наиболее оптимальным способом их преодолеть.

Автор: Earnest 4.12.2009, 09:19

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

Автор: Lazin 4.12.2009, 10:05

Цитата(papochka @  3.12.2009,  19:40 ) Вот приступая к разработке программы, вы ведь обдумываете её функционал, структуру, в конце концов интерфейс. нет $%#@, сразу сажусь и пишу код   Цитата(unicuum @  4.12.2009,  05:37 ) Это надо обсуждать, я уже показывал как всё это выглядит в диаграммах UML, псеводокодах, XML, графических схемах и т.п. Только что-то мои темы по проектированию ПО не сыскали заслуженной славы так то были темы по проектированию ПО?   Цитата(Earnest @  4.12.2009,  09:19 ) Начинать разработку программы (или модуля большого проекта) нужно с написания функциональных требований. Именно написания, в любом виде. Что должна делать, что не должна. Потом прописать взаимодействие с пользователем. Нарисовать интерфейс, ясно представляя, как оно должно работать с точки зрения полозователя. Потом можно немножко попредставлять дизайн, примерно накидать кто чем рулит. Тоже письменно, т.к. это заставляет оттачивать формулировки, и многое становиться ясным, многие проблемы вылезают. Это все вполне банально и в зубах навязло, но реально помогает. Другое дело, что обычно это делать влом.  Лично я это делаю только для сложных модулей, когда сразц в голове нет ясной картины. Или как спецификацию для других программистов. Спец.средствами (UML и прочая) никогда не пользовалась, хотя изучала и пробовала, но посчитала излишними (для своих задач).  Т.е. проектирование нужно обязательно, но необязательно формальное.  единственный вменяемый комментарий на всю тему  ППКС без сформулированных, хотя-бы частично требований, нечего даже думать об архитектуре тут нужно уметь идти на компромиссы, иногда стоит отказаться от какой либо функции, как сложность проекта падает очень значительно, и наоборот, какая нибудь мелкая функциональность может "не ложиться" на архитектуру приложения и портить жизнь разработчику, да и попросту похоронить проект

Автор: unicuum 4.12.2009, 10:27

Цитата(Lazin @  4.12.2009,  10:05 ) так то были темы по проектированию ПО?  Конечно, иначе с чего бы мне их было создавать, овнокодить я и так умею.   Цитата(Lazin @  4.12.2009,  10:05 ) нет $%#@, сразу сажусь и пишу код  Тоже интересный подход. Сколь много у программиста играет уверенность и положительный настрой. Даже если нет знаний это может сильно помочь. При содействии же последних производительность будет очень неплохой. Вот представьте, что за годы программирования вы изучили большое количество разнообразных техник проектирования ПО. Вроде всё ясно, что и как делать, однако при этом они не применяются. Повторение же снова и снова, как же это хорошо использовать вот ту технику проектирования не приводит к результату по понятным причинам. А если пытаться объяснить другим, как проектировать, то вероятно многое останется за кадром. Программист часто имеет в виду больше, чем говорит. Цитата(Lazin @  4.12.2009,  10:05 ) без сформулированных, хотя-бы частично требований, нечего даже думать об архитектуре Это уже давно известно, что продвинутым прогерам важно то, что хочешь получить, а не то как хочешь это получить, так как второе не вызывает осложнений. Стоит ли говорить о таких банальностях? Стоит, конечно, вот только как я уже сказал, надо не думать, надо прыгать. И опять же, хоть я это и сказал, я понимаю, что меня в полной мере не поймут, те кто не последуют совету. Но если они следуют совету, то и совет им вовсе не нужен, ведь они и так делают, то что нужно.

Автор: Lazin 4.12.2009, 11:07

Цитата(unicuum @  4.12.2009,  10:27 ) Конечно, иначе с чего бы мне их было создавать, овнокодить я и так умею а я думал ты это не серьезно... так ты это серьезно? шаблоныоттенки создателей и все такое!?! Цитата(unicuum @  4.12.2009,  10:27 ) Тоже интересный подход. тебе знакомо слово ирония? Цитата(unicuum @  4.12.2009,  10:27 ) Это уже давно известно, что продвинутым прогерам важно то, что хочешь получить, а не то как хочешь это получить, так как второе не вызывает осложнений. Стоит ли говорить о таких банальностях? Стоит, конечно, вот только как я уже сказал, надо не думать, надо прыгать. И опять же, хоть я это и сказал, я понимаю, что меня в полной мере не поймут, те кто не последуют совету. Но если они следуют совету, то и совет им вовсе не нужен, ведь они и так делают, то что нужно.  это основное отличие между профи и любителями, первым важен результат, вторым - процесс просто там где один разработчик на ваяет сложную архитектуру, с шаблонными методами, синглтонами и абстрактными фабриками, напишет несколько десятков тыс. строк кода в десятках файлов, другой подумает(!!!) до того как писать что-либо и поймет, что здесь по сути должно происходить чтение из файла в такую структуру данных с последующей обработкой и экспортом в определенный формат(к примеру) и сделает минимальную по сложности реализацию из всех возможных, которая на 2х экранах будет помещаться  вот это, на мой([irony]единственно верный, хочу заметить[/irony]) взгляд и есть правильный подход, так как сделать проще, на самом деле сложнее, и что-бы сделать более простую(а значит, содержащую меньшее количество ошибок и более простую для последующего развития) реализацию, нужно предварительно подумать, куда прыгаешь, прежде чем прыгать

Автор: unicuum 4.12.2009, 11:17

Цитата(Lazin @  4.12.2009,  11:07 ) вот это, на мой([irony]единственно верный, хочу заметить[/irony]) взгляд и есть правильный подход, так как сделать проще, на самом деле сложнее, и что-бы сделать более простую(а значит, содержащую меньшее количество ошибок и более простую для последующего развития) реализацию, нужно предварительно подумать, куда прыгаешь, прежде чем прыгать  Тега irony на винграде нет. Представь, что ты новичок в программировании. Можешь ли ты сразу написать код хорошо? Да, даже если не новичок. Что важнее, краткость кода или его понятность программистам? Когда уровни абстракций вместо уменьшения количественной и увеличения качественной составляющей начинают действовать наоборот? Я вот встречал примерно такие ответы, - "Ничто не заменит хороший вкус и что-то там ещё". В общем, всё не так однозначно, и совет подумай так же ценен ("ценен"), как и совет делай. Добавлено через 2 минуты и 17 секунд P.S. если бы мы сами ещё следовали своим советам, цены бы нам не было

Автор: Lazin 4.12.2009, 11:35

Цитата(unicuum @  4.12.2009,  11:17 ) Тега irony на винграде нет. спасибо Кэп. Цитата(unicuum @  4.12.2009,  11:17 ) Представь, что ты новичок в программировании. Можешь ли ты сразу написать код хорошо? когда я был новичком в программировании, я такими вопросами, как ТС, не задавался   Цитата(unicuum @  4.12.2009,  11:17 ) Да, даже если не новичок. Что важнее, краткость кода или его понятность программистам? одно с другим связано, разве нет? Цитата(unicuum @  4.12.2009,  11:17 ) Когда уровни абстракций вместо уменьшения количественной и увеличения качественной составляющей начинают действовать наоборот? уровни абстракции должны выполнять одну простую функцию - уменьшения связности и как следствие сложности, поэтому, прежде чем вводить новый уровень абстракции, нужно подумать, нужен-ли он на самом деле, или без него можно обойтись вроде-бы простая вещь, но многие не понимают, часто программист не может объяснить, зачем он ввел ту или иную сущность, увеличив тем самым сложность, зачастую это происходит из-за того, что программист не понимает как в дальнейшем будет использоваться его код, поэтому делает максимально обобщенно/абстрактно, хотя на самом деле все можно было сделать просто поэтому очень важно правильное проектирование, не имея big picture, невозможно судить о том, как будет использоваться тот или иной класс, должен-ли он быть абстрактным так как в будущем появятся новые реализации, либо будет всегда использоваться одна и та-же реализация (это был пример)  Добавлено через 2 минуты и 17 секунд одним словом, преждевременная пессимизация - зло

Автор: kemiisto 4.12.2009, 12:20

Цитата(GremlinProg @  4.12.2009,  06:55 ) врят ли тут стоит винить какой-то конкретный язык Соблазн уж больно велик.   Цитата(Earnest @  4.12.2009,  10:19 ) или модуля большого проекта Да, когда С/С++ разработчики начинают рассуждать о модулях, давиться от смеха становиться трудно.   Цитата(Lazin @  4.12.2009,  11:05 ) единственный вменяемый комментарий на всю тему Отнюдь. Просто речь идёт о первом этапа разработки ПО - сбор и анализ требований. А мы тут больше как-то  о втором... Цитата(Lazin @  4.12.2009,  11:05 ) так то были темы по проектированию ПО?     Я в ауте...

Автор: Alek86 4.12.2009, 12:39

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

Автор: Леопольд 4.12.2009, 13:26

Цитата(Lazin @  4.12.2009,  10:05 ) без сформулированных, хотя-бы частично требований, нечего даже думать об архитектуре Как правило, всё продумать нельзя и на этапе реализации могут появиться новые требования. Некоторые могут быть не совместимы с текущей системой. Как быть, перепроектировать почти с ноля или делать как попало?

Автор: Lazin 4.12.2009, 14:39

Цитата(Леопольд @  4.12.2009,  13:26 ) Как правило, всё продумать нельзя и на этапе реализации могут появиться новые требования. Некоторые могут быть не совместимы с текущей системой. Как быть, перепроектировать почти с ноля или делать как попало?  тут все не так печально, как кажется, обычно бывает понятно, какие требования могут быть изменены заказчиком в последствии, по крайней мере там где я работаю, это так просто закладываем в архитектуру "точки роста", в нужных местах в любом случае, это всегда баланс между гибкостью и сложностью

Автор: unicuum 4.12.2009, 15:02

Цитата(Lazin @  4.12.2009,  14:39 ) в любом случае, это всегда баланс между гибкостью и сложностью  Вот, к примеру, реализация кода шаблона проектирования http://en.wikipedia.org/wiki/Property_%28programming%29. Код #include <iostream> template <typename T> class property {         T value;     public:         T & operator = (const T &i) {             ::std::cout << i << ::std::endl;             return value = i;         }         // This template class member function template serves the purpose to make         // typing more strict. Assignment to this is only possible with exact identical         // types.         template <typename T2> T2 & operator = (const T2 &i) {             ::std::cout << "T2: " << i << ::std::endl;             T2 &guard = value;             throw guard; // Never reached.         }         operator T const & () const {             return value;         } }; struct Foo {     // Properties using unnamed classes.     class {             int value;         public:             int & operator = (const int &i) { return value = i; }             operator int () const { return value; }     } alpha;     class {             float value;         public:             float & operator = (const float &f) { return value = f; }             operator float () const { return value; }     } bravo; }; struct Bar {     // Using the property<>-template.     property <bool> alpha;     property <unsigned int> bravo; }; int main () {     Foo foo;     foo.alpha = 5;     foo.bravo = 5.132f;     Bar bar;     bar.alpha = true;     //bar.bravo = true; // This line will yield a compile time error                       // due to the guard template member function.     ::std::cout << foo.alpha << ", "                 << foo.bravo << ", "                 << bar.alpha << ", "                 << bar.bravo                 << ::std::endl; } Могли бы просто написать функции получить и установить. Но нет, использовали шаблоны C++. Если развивать эту мусль, так можно и индексаторы в свойствах реализовать. Однако вопрос в другом, целесообразно ли? Как определить, что мы перегнули со сложностью?

Автор: kemiisto 4.12.2009, 15:28

Цитата(Alek86 @  4.12.2009,  13:39 ) kemiisto, вроде Комодератор, а ведешь себя как типичный тролль В этой ветке по-другому получается редко.   Цитата(Alek86 @  4.12.2009,  13:39 ) По поводу проектирования интерфейсов есть неплохая книжка Алана Купера "Психбольница в руках пациентов" Стоит читать?

Автор: Alek86 4.12.2009, 15:30

Цитата(kemiisto @  4.12.2009,  15:28 ) Стоит читать? это так, художественная литература читать можно, когда думать лень

Автор: Lazin 4.12.2009, 15:32

Цитата(unicuum @  4.12.2009,  15:02 ) Могли бы просто написать функции получить и установить. Но нет, использовали шаблоны C++.  по моему это ерунда какая-то, шаблон property - бесполезен, так как он не позволяет задать свои get/set методы для свойства, поэтому смысла я в нем не вижу, а второй вариант - довольно утомителен, в каждом новом классе писать одно и то-же? я бы сделал что-то вроде: Код template     < T (Foo::*Get) ()     , void (Foo::*Set) (T const&) > class Property {     Foo& owner_; public:     Property(Foo& o) : owner_(o) {}          opertor T()     {         return (owner_.*Get)();     }     Property& operator = (T const& value)     {         (owner_.*Set)(value);     } }; что-бы можно было использовать так: Код class Foo{ ... Property<&Foo::get, &Foo::set> myValue; Foo()   : myValue(this) { } int get() {     return 42; } void set(int a) { } ... } foo.myValue = ...; // вызов set код скорее всего не рабочий, это просто иллюстрация идеи ) Цитата(unicuum @  4.12.2009,  15:02 ) Как определить, что мы перегнули со сложностью? с помощью здравого смысла и такой-то матери

Автор: EvilsInterrupt 4.12.2009, 22:30

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

Автор: nerezus 4.12.2009, 22:41

Цитата Проектированием могу заниматься только тогда, когда на это есть время!   А когда нет времени - то проектированию надо уделить гораздо больше времени, чем когда оно есть ;) К сожалению ихз реальной жизни. Естественно никто не будет ничего проектировать для продукта <$1k, но мелкие продукты без посл. доработки и не требовательны к проектированию.

Автор: Lazin 4.12.2009, 23:48

Цитата(EvilsInterrupt @  4.12.2009,  22:30 ) Проектированием могу заниматься только тогда, когда на это есть время! В рабочем режиме, как правило требуют результат фишка в том, что без анализа требований непонятно когда программу можно считать законченой   обычно, программист видит недостатки своих программ и стремиться сделать "лучше", но клиент это не всегда может оценить, а требования позволяют четко, дерзко, определить, что именно должно быть сделано хорошо, а на чем можно не заморачиваться и когда собственно нужно остановиться

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)