Существует такая наука как проектирование ПО. У нас она не очень развита (мое мнение), тем более для микроконтроллеров. Наш народ садится за клавиатуру и начинает писать код. Видел я много не продуманных программ. Было очень много срывов сроков проекта из-за того что нужно внести изменение в программу (незначительное), а программист мне говорит типа это сложно, из-за этого нужно переделать то-то и то-то. Особенно тяжело с людьми которые ранее писали на Ассемблере и их заставили писать на С. Оператор GOTO они наверно не забудут никогда.

К чему это я все? У меня есть практика программирования как для ПК так и для МК. Я 6,5 лет отсидел на студенческой скамье. И я себя считаю не плохим программистом. Я задался целью найти литературу или статьи по архитектуре ПО для МК. Согласитесь программирование под МК имеет свою специфику. В результате поисков я ничего не смог найти, даже малейших намеков.

Мне кажется это серьезная проблема. В данный момент я набираю людей в отдел. И на вопрос: "Что такое архитектура ПО?" я в 100% собеседований слышу мычание.

Уважаемые коллеги, скажите может я ошибаюсь и эта архитектура вовсе не нужна (ведь оно и так все работает)? А может кто чего-нибудь подскажет?

Если говорить об первоначальной теме топика, не углубляясь в личные предпочтения каждого программиста (кому-то удобнее писать используя одни функции языка, другому - другие, программы обоих могут быть одинаково эффективны). Я так понимаю, автора интересовал вопрос о грамотном написании встраиваемого ПО. Чтож, о том, что эта область не затрагивается - убеждение ошибочное, просто она не столь широко освещается. В общем и целом проектирование ПО для МК аналогично тому же для ПК, с некоторыми исключениями, например необходимостью учитывать особенности аппаратной платформы и т.п. Есть и литература по данному вопросу, первое что пришло на ум - Ален И. Голуб, у него есть несколько работ по данной тематике, но к топику наиболее подходит его книга "Веревка достаточной длинны, чтобы... выстрелить себе в ногу" (и название говорящее...).
Тут кто-то сказал, что печально слышать от программиста: "это очень сложно" и "этого в ТЗ небыло", а программисту по-вашему приятно слышать "о а давай-ка мы тут новую штуку добавим" или "ну мы думали что будет нормально, а нам не подходит - надо переделать". Вот строите вы дом, а к вам подходит заказчик и говорит: "Гм... что-то не то... а давайте мы вот тут на первом этаже дырку в стене прорубим и поставим большое окно!" сделать можно что угодно, вот только дом потом развалится. Тогда уже вопрос не в проектировании ПО а в управлении проектом в целом.
Возвращаясь к теме: сложно дать конкретную доктрину по проектированию ПО для МК, тем более не ясно какой именно аспект этого проектирования Вас интересует. Единственное что можно посоветовать: ищите, ищите и еще раз ищите. А лучше поучится у тех у кого большой опыт ведения проектов по разработке встраиваемых систем.

Вообще-то этот топик не про оператор goto, а про проектирование ПО. Оператор goto ни как не относится к пректированию, он больше относится больше к реализации. Я этим оператором никогда не пользовался, потому что еще в институте меня учили, что это правило плохого тона, а я этого понять не мог (почему плохого?). Смысл всего этого я понял намного позже, когда начал разбираться с чужой программой, которая была усыпана goto. Оператор goto снижает видимость кода, мысли частенько начинают теряться, если код большой, метка и оператор находятся далеко друг от друга. При исследовании такого кода крышу слегка срывает. Ну и с переносимостью такого кода тоже возникают проблемы. Хотя можно и на ООП написать так, что ни чего ни куда не перенесешь. Все зависит от опыта программиста... Руки у всех разные.

А вы вместо notepad-а попробуйте применить Understand и его автоматический генератор диаграмм для анализа исходников, и неожиданно увидите что с goto понятнее получается чем с теми же косвенными переходами.

Прочитал весь топик (типа читал пэйджер - много думал). Как то грустно и смешно (простите).
Народ, а чего Вы повелись то? Автор топика возможно неплохой программист, но как организатор - в начале пути.
Речь свелась к технике. И ещё круче к несчастному оператору (не буду тут его в суе) При чём тут вообще это то?
Лично знаю более 10 языков, из них только азмы вызывают теплоту в душе. Наверное благодаря принципу - что сделано, сам дурак. И как то филолетово
кол-во чего то там. Есть красивые решения в технике программирования - вот их и применять нужно.
И КАЖДЫЙ язык имеет свои СИЛЬНЫЕ стороны и КРАСИВЫЕ решения.
И из каждого можно сделать на несколько метров портянки блевотной массы. И чего?

А по теме:
Автор - не там ищите.
Я более того скажу - Вы задали вопрос который можно сформулировать немного по другому:
где взять технологию перехода(оптимального, менее затратного в ресурсах и т.д.) от пользовательской задачи к коду.
И так как это _технология_ то согласитесь - тут говорить о языке(оси, железе), мягко говоря - глупо.
какая технология - читайте популярную литературу. как говорится - всё придумано до нас

автору удачи - она Вам потребуется
(круглый)

Вообще-то на эту тему есть даже международные и отраслевые стандарты (поэтому это не наука, а технология производства), например прогуглите "ISO Standart for software life-cycle proces" или "DOD-STD-2167"

Эта штука хорошо сделана у буржуев, некий конвеер, которому все равно, чего разрабатывать. Для понимания, зачем надо и что получается, можно почитать "Совершенный код", Стив Мак-Коннел. Или поработать в конторе с CMMI-3 и выше

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

100%

to Dog Pawlowa: наверное здесь "КРАСИВЫЕ" = "НЕСТАНДАРТНЫЕ", "ЭФФЕКТИВНЫЕ"
P.S. Иногда гвозди затупляют именно для ЭФФЕКТИВНОГО забивания

Сообщение отредактировал forever_student - Mar 30 2010, 17:04

Тут все зависит от количества гвоздей. Если задача хорошо продумано и найдено красивое решение, то "гвоздей" много меньше понадобится. И опять же, если всегда просто "тупо забивать гвозди", то красивые решения можно искать очень долго. Но если постоянно стремится к поиску красивых решений, то они находятся достаточно быстро. Мозги постоянно тренировать нужно. Или нет?