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

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

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

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

Скажите, а как оператор goto (кстати, вполне легальный, чего никак не могут понять составители школьных программ, исповедующие метод copy-paste) может помешать правильному проектированию ПО? Несколько другой уровень "проблемы".

Проектирование ПО - это точно не наука.
Из него пытались сделать ремесло, но что-то явных успехов на этом пути не видно.
Так что пока считается искусством.

PS. А наш народ, который садится за клавиатуру и начинает писать код - на самом деле следует самым модным, самым современным путём - это же так называемое XP, Extreme Programming в чистом виде!
А потом начинается TDD - Test Driven Development, когда всё это тестируют, тестируют, тестируют, тестируют, а оно всё не работает и не работает. Очень современая технология, какие могут быть сомнения?
PPS. Если набрать XP на русском получится ЧЗ - Чёрт Знает что [однако, ©!] или психбольница в руках пациентов.

Оператор GOTO делает программу не читаемой и тяжолой для внесения изменений. В 100% случаях можно обойтись без него (опыт программирования на С под МК 4 года, на С++ под Windows 8 лет и не разу не использовал оператор GOTO).
А разговоры о том что GOTO позволяет код сделать меньшего размера и повысить скорость программы считаю не актуальными. Если вы радиолюбитель, то може для Вас конечно дорогова-то выбрать контроллер с большей производительностью или большим количеством памяти, но в случае серийного производства это не проблема. Цена остается абсолютно не изменной из-за объемов. Так же считаю, что выиграшь от повышения производительности при использование GOTO не соизмерим с потерями читаемости кода.

И вообще вопрос не в этом. Вы можете использовать GOTO, но делать нужно это с умом. Если у Вас продуманная и четко просматриваемая структура программы, то ни кто Вас не у прекнет за использование этого опператора.




Слава богу я не один задумываюсь над этой темой.

Проектирование ПО - это точно не наука. Не согласен. За "бугром" это наука. У моей знакомой (учется в Гамбурге) был даже такой курс.
А как же "SWEBOK: Руководство к своду знаний по программной инженерии"?

Понятно. Очередной флудняк наметилсо

Если не использование оператора goto приводит к необходимости перехода на более мощную платформу, то стоит всерьёз задуматься о том, не начать ли его активно использовать
На самом деле столь глобального изменения размеров и скорости исполнения в грамотно построенной программе не будет.
Читаемость пострадает только если прыгать через десятки строк (что уже не здоровое явление), в нормальном случае ничего страшного не случится.

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


Ну так пятница, вечер...

Дык, "Great mind thinks alike".
Вот и Д. Кнут с нами согласен:
Structured Programming with go to Statement.
Donald E. Knuth, Computing Surveys, Vol. 6, No. 4, December 1974

Вы собираетесь стандартизировать процесс творчества. Ведь задание на программу может быть любое, и алгоритм тоже может быть любой. Пытаться стандартизировать процесс написания читабельной, удобной для модификации и неглючной программы, причем сразу на все случаи жизни, по моему, тоже самое, что пытаться написать пособие для авторов фантастики. Типа "Как написать клевый рассказ и заработать кучу денег". И тогда любой посредственный писака берет чудо пособие и через два дня сдает в редакцию бестселлер. Ну а раз задача стоит в стандартизации процесса работы мозгов. Думаю от них и надо плясать. Поставьте задачу для программиста. А затем... напишите программу, которая сама напишет программу вместо программиста. Вот тогда думаю, сразу станет ясно, как именно работают мозги любого программиста и останется только переложить все выводы на бумагу.
Искуственный интелект, значит создаем... А японцы идиоты, десятки лет рубятся на этом деле.
Все оказывается просто, главное отдел набрать и вперед. Блин.

Тут сложность в том, что сложно передать свой опыт проектирования. Он приходит с годами.

Каждый кто тянется к клавиатуре уже в мыслях строит что нужно написать примерно.

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

Такчто XP рулит О_о

Присоединяйтесь!

The Tao Of Programming

vvvvv, +1
ИМХО, больше всего о том КАК написана программа зудят люди, уже бессильные что-либо делать сами.

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

Очень порочная практика. Знаю по своему горькому опыту. Работал на фирме, где престарелый конструктор, который давно не работал по специальности, обожал давать мне ЦУ. Теперь я там не работаю. Именно по вышеназванным причинам.
Считаю, что каждый должен заниматься своим делом. А критерий оценки работы - результат. Талант руководителя, заключается в том, что бы собрать толковых людей, и организовать работу. Талант программиста, в создании эффективного и безглючного кода. А использовать оператор GOTO или нет, это личное дело программиста.

Мне кажется, что бодание вокруг goto сродни религиозным войнам средних веков. На самом деле, если посмотреть, как обрабатываются исключения в ЯВУ (хоть в том же C++), станет ясно, что неявно там goto присутствует, только запрятан в стандартные процедуры обработчика. И никого это, вроде бы, не напрягает... Так что, если для существенного упрощения и уменьшения кода надо сделать пару-тройку прямых переходов - да кто же будет против? Чаще всего это применяют для обработки ошибок оборудования, а возможность ошибки или сбоя оборудования ДОЛЖНА предусматриваться в любой промышленной системе. И, соответственно, учитываться в ПО. Другое дело, что стиль Фортрана на сегодняшний день врядли кого вдохновит. А значит, и основная программа, и обработчики особых ситуаций должны писаться структурно - хотя бы для удобства чтения/модификации программы.
Что касается особенностей программирования микроконтроллеров - да, тут есть проблемы уровня реализации - как правило, приходится программировать многозадачную систему реального времени с контролем сбоев и отказов оборудования в условиях недостатка памяти (цена процессора!) и тактовой частоты (потребление!). Почти всегда такая система должна быть самовосстанавливающейся при сбоях, да еще и вести журналы данных, событий и ошибок. Но для проектирования ПО таких систем разработаны технические приемы программирования (обработчик реального времени, switch-программирование и т.д.). Насчет утверждения автора темы, что проще взять более мощный процессор для облегчения программирования при серийном производстве - тут большой вопрос, на самом деле автор занимался серийным выпуском? Мой личный опыт говорит, что заказчик готов выкручивать руки за доли цента, а за 10 лишних центов готов убить разработчика... И действительно, при выпуске 20..100 тысяч изделий эти центы выливаются в большие затраты.

Я прихожу к выводу, что действительно развитие программирования под МК сильно отстает от развития программирования для ПК.

По поводу XP (экстремального программирования). Очень ошибочное представление о этом методе. В этом методе как ни в каком другом присутствует проектирование ПО. Как я понял большинство считает, что это один программер садится за комп и начинает "педалить", перед этим получив задание. Но кто так считает, тот очень сильно ошибается. XP подразумевает командное программирование. И очень большая нагрузка ложится на project manager'a. Он составляет структурную схему приложения, дробит ее на модули и подмодули, планирует сроки и раздает задания программистам.

Почему этот метод называется экстремальным? Потому что главная цель выполннить задачу в самые крайчайшие сроки.

Любители экстремального программирования, почитайте хотя бы на http://ru.wikipedia.org что это такое.

Я заметил, что большинство программистов считает что код это их интелектуальная собственность и очень неадекватно реагируют на какие-либо попытки проникновения в него. Ребята, Вы очень заблуждаетесь!!! Код принадлежит не только Вам. По мимо Вас код принадлежит еще и Вашему начальнику. Начальнику, которого будут драть, а не Вас, за Ваши bag'i.


По поводу фразы: "На самом деле столь глобального изменения размеров и скорости исполнения в грамотно построенной программе не будет." Проверено лично. Мне пришлось переписывать программу товарища который очень любил GOTO (по этому-то и пришлось переписовать - внести изменения туда было не реально).В итоге мой код весит (hex) 32 567кБ а его 48 752 кБ. Есть разница? При этом я еще модернизировал протокол обмена с ПК и немного его "навернул".

Есть ли у меня опыт серийного производства? Есть. Серии от 100 изд в месяц до 10000 изд в месяц.
Что я имел по поводу стоимости контроллера? Если вы покупаете на базаре 10 контроллеров, то это одна цена, а если вы покупаете у официального поставщика 10000 контроллеров, то это совсем другая цена. Встречал разницу в 3-4 раза.

Ну, по закону, програмист имеет личное право авторства, право на имя, право на неприкосновенность (целостность) программы и право на обнародование программы. Вы, как работтодатель, получающий продукт интеллектуального труда программиста, имеете исключительное право воспроизведения, распространения и модификации программы. Так что, обе стороны имеют свои права...

Поясню по поводу цен на комплектующие. Я. естественно, имел в виду оптовые цены производителей. Однако в своей практике что-то не встречал, чтобы цена на процессор с 16 КБ программной памяти равнялась цене процессора с 32 КБ. Как правило, они весьма отличаются. И выход за границы существующей памяти программы болезненно воспринимается заказчиком. А при разработке серийного прибора переход с OTP процессора ценой $0.5 на процессор ценой $0.6 вызывает вообще панику...