Процесс создания алгоритма программы/посоветуйте программу для создания алгоритмов.

Садишься на стул покрепче, открываешь конфлюенс, и пишешь дизайн. Поменьше слов, побольше иллюстраций. Для этого там есть plantuml и draw.io. Всякие сиквенс диаграммы, диаграммы состояний, и т.п. А когда достигнешь ясности, как всё будет работать, кодируешь по дизайну.

Главное сесть поудобнее.

В яндекс картинках нашел фотку вот такой программы которая рисует алгоритмы…

https://avatars.mds.yandex.net/i?id=c81c35a87b4354f7e884c31c081c806d_l-5220492-images-thumbs&n=13

И судя по цвету верхней планки и кнопки закрытия это программа работает под убунтой.. Вопрос, если кто знает как эта программа называется.. Поиск по яндекс фоткам ничего не дал..

Хм, ну на работе обычно на словах объясняют. Бывает рисуют схемы бизнес логики, но редко и схемы эти далеки от реального кода, он гораздо замороченнее. Блок схемы может и рисовал в начале изучения программирования пару раз, но вообще никогда этого не делаю и не видел чтобы кто-то делал.

Несколько полезнее трюк с написанием алгоритма комментарием или псевдокодом, что-то типа:

// Если а больше б
// то прибавляем
// иначе вычитаем

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

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

На эту тему советую почитать «Совершенный код» Стива Макконела http://www.ozon.ru/context/detail/id/4729959/. Книжка старая, но там именно база практической разработки и ответы на многие вопросы новичков

А зачем его держать в голове? Алгоритм же в коде. План для написания текущего файла/класса/функции держу в голове, да.

https://habr.com/ru/companies/retailrocket/articles/431572/

Посоветуйте программу для составления алгоритмов

текстовый редактор и компилятор. если есть - лучше ide.

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

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

Не пойму, тебе редактор блок-схем нужен, или научиться продумывать архитектуру?

Если редактор, то в Dia можно их делать.

Если же…

Хотелось бы услышать опытных программистов как это происходит у них? Неужели весь алгоритм программы они держат в голове? И чтобы при этом не свихнутся… Или сначала чертят графический алгоритм в какой-то программе и затем уже пишут код..?

Я не черчу, и не знаю никого, кто всерьёз бы чертил.

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

Это не требуется. Если программа не примитивная, а просто простая, она делится на примитивные подзадачи — их совокупность можно удержать в голове, а в каждый момент работать над каждой конкретной. Если программа не простая, а сложная, то она делится на простые подзадачи — их совокупность удерживается в голове. При работе над отдельной простой задачей она тоже удерживается в голове, как и одна конкретная примитивная под-под задача. И так далее, для очень сложных программ, состоящих из сложных задач, а также очень-очень сложных программ…

В общем, разделяй и властвуй.

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

Когда ты работаешь над функцией, которая рассчитывает тебе длину отрезка, соединяющего точки с координатами (x1, y1) и (x2, y2), тебе совершенно не нужно держать в голове, что вообще делает вся остальная программа. Ты реализуешь этот рассчёт расстояния. Когда ты её реализовал, то размышляя над тем, как построить алгоритм основной программы, ты располагаешь функцией рассчёта расстояния — принимающей эти координаты и возвращающей расстояние — тебе совершенно не нужно держать в голове, как она реализована внутри — она для тебя теперь «просто есть» и является эдаким кирпичиком алгоритма, внутреннее устройство которого не имеет значения.

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

Если у тебя на каком-то уровне абстракции, какая-то функция стала настолько сложной, что её не удаётся удержать в голове, то тут то ли голова дырявая, то ли надо на более простые части стараться разделить — это почти всегда возможно.

Вы путаете архитектуру с алгоритмом.

Вам не нужны никакие блок-схемы тк они используется для описания архитектуры приложения - взаимодействия её основных частей на верхнем уровне.

Алгоритмы же описывают логику работы каждой этой части программы. То что у вас на скриншоте похоже на обучающую программу для старших классов. Иногда так работают редакторы FSM (автомат конечных состояний), но это не то что вам сейчас нужно.

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

Можно накидать список получившихся частей в виде списка комментариев и затем раскрывать их - писать код под каждым таким комментарием реализуя часть за частью.

С опытом декомпозиция делается автоматически в голове без всяких заметок и сразу пишется код.

Дальше уже подключаются такие вещи как оптимизация, лучшие практики и тд. С опытом эти этапы начинают идти параллельно с декомпозицией.

• codewars.com
• leetcode.com

Практика и еще раз практика.

Если задача сложная, разбиваешь ее на насколько простых задач, функций. Это весь секрет.

Если редактор, то в Dia можно их делать.

Неудобно там как то мышевозить, мне graphviz больше понравился.

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

Но как можно не осознавать архитектуру собственного проекта? Что там за исполинский микроконтроллер такой вытянет кодобазу, сравнимую с браузером или ядром ОС?

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

Именно так устроена вся коммерческая и не только разработка.

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

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

Какой конфлюенс для микроконтроллера AVR?

Ещё один читает жопой.

DRAKON

Algorithm Builder

Скорее всего это ДРАКОН. И да, под AVR там вроде как можно писать.

я ничего не записываю, диаграмм не рисую

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

Имхо, самое адекватное представление алгоритма – это грамотно написанный код.

Вообще, со сложными алгоритмами именно в плане логики (то, что описывается блок-схемами) иметь дело приходится не так часто. Вот протоколы, какими форматами и в каком порядке обмениваются части сложного проекта – такое документировать приходится, да. UML-диаграммы классов бывают полезны.

И да, выше правильно посоветовали: 1) псевдокод по ходу написания текста программы; 2) грамотное разбиение на модули/классы. Большие портянки без декомпозиции очень редко когда оказываются правильным решением.

Да, именно это я и имел в виду: «сложными алгоритмами именно в плане логики».. Как вообще строятся такие сложные логические конструкции..

А где почитать про это разбитие на модули и классы можно для начинающих.. Чтобы грамотно делать..

какой тебе язык нужен?

Неужели весь алгоритм программы они держат в голове? И чтобы при этом не свихнутся…

А кто сказал, что мы нормальные? %)

си

модули содержат классы

об архитектуре как правило думать не надо, так как ее навязывает фреймворк

Главное, паттернов не забыть погуще навернуть, а то не энтерпрайзно выйдет.

Тут всё индивидуально. Мне помогают бумага и карандаш. Садишься и простыми словами пишешь, буквально на уровне «вот программа, она берёт вот это из конфига, а вот это получает из api-запроса. А потом кобинирирует так-то, чтобы получилось вот это …». Звучит несколько туповато, зато хреновина над которой два часа размышлял впустую за 15 минут становится столь ясной и очевидной, что даже стыдно немножко. Потом просто переводишь с русского на компьютерный. Бонусом — можно рисовать диаграммы (или котиков). Лист бумаги вообще довольно гибок.

А вот с компьютерными приблудами такого эффекта нет. Если тот же текст печатать, магии не происходит. Механизм этого явления не ясен, но в моем случае работает.

Благодарю за четкий ответ.. попробуем… Хотелось бы выразить своё мнение.. Некоторые участники форума очень много используют специфического сленга.. Так что ещё надо попробовать разгадать этот сленговый ребус..

Ручку и бумагу уже советовали?

Читать тред пробовал?

Тред не читай, сразу отвечай. Но предположу что советовали в каждом втором сообщении. А в каждом пятом - dia.

они только в яве и более продвинутых заменителях типа сисярпа нужны

На C не пишут Gui. Для этого берут C++/Qt, да и то интерфейсы на QML делают. Там тебе не нужно придумывать архитектуру. Но если хочется именно C, то просто туториал к Gtk почитай. С в основном для CLI используется. ООП удобно для разработки графических приложений, где элементы интерфейса представлены компонентами, а они — классами. В Gtk своеборазная реализация этого самого ООП.

Если коротко то твои записи должны охватывать следующие пункты:

• Что я хочу получить;
• Что оно должно делать;
• Как оно должно это делать;
• Детали реализизации;

Или сначала чертят графический алгоритм в какой-то программе и затем уже пишут код..? Если это так, то посоветуйте программу для черчения алгоритмов..

Скорее всего, ты ищешь рисовалку UML-схем. Ошибка рисователей этих алгоритмических схем состоит в том, что рисунок не обеспечивает отображение и сверку результатов работы нарисованной схемы. То есть нарисовал ты схему, выглядит она красиво и «умно», а на деле работать алгоритм не будет. И пока не запрограммируешь эту схему, то не выяснишь что она может быть ошибочной. Время и деньги расходуются напрасно.

Грамотные инженеры используют моделирование + кодогенератор.

Для AVR моделирование например в протеусе или есть ещё варианты? Или моделирование на реальном железе - микроконтроллере? Под кодегенератором что вы подразумеваете.. Можно поподробнее..

На рисование он потратит x100500 больше времени чем на простое текстовое описание.

Подскажите мне пожалуйста вот что… Какое дополнительное расширение поставить для Visual Studio Code сейчас я его использую.. чтобы при написании кода на си для AVR он мне подсказывал возможные варианты кода.. И ещё вопрос.. Вы советуете программу Qt - чем она лучше Visual Studio для AVR ? Может подобные расширения для AVR есть и для Qt..? Как я понимаю это тоже своего рода продвинутый «блокнот» для программирования..

Для AVR моделирование например в протеусе или есть ещё варианты? Или моделирование на реальном железе - микроконтроллере? Под кодегенератором что вы подразумеваете.. Можно поподробнее..

Для начала можно тут посмотреть.

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

Под кодогенерацией вы имеете в виду использование искуственного интелекта? Или какой-то программы?

Или сначала чертят графический алгоритм в какой-то программе

Gimp

А MATLAB ломаный под линукс бывает?

А вот как с более сложными программами?

Сложные программы состоят из примитивных частей, поэтому с ними так же как и с простыми.

Или сначала чертят графический алгоритм в какой-то программе и затем уже пишут код..?

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

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

Видно что ты даже не пытался писать программы, поэтому просто пиши, а вопросы твои не имеют никакого смысла. Точно не нужно пытаться делать «правильно» и заниматься карго культом с UML, моделированием, коньфлюеньсами и прочим дерьмом. Рисуй на бумажке если сильно хочется. «Опытные товарищи» просто берут и пишут код. Заставь их ещё архитектуру подизайнить перед этим…

А за это полагается бан…

Люди этому учатся со школы и до самой старости. Это больше искусство, чем ремесло. Правда попытки превратить в ремесло идут со страшной силой и где-то даже с успехом…

Короче, если тебе нужна программка, то закажи ее - будет проще и надежнее. Если хочешь научиться программированию, то учи его как свою вторую профессию с самых азов. Третьего варианта нет. Хотя вру. Еще есть питон - вот это вариант номер три.

Здесь речь идет о программе на языке си для микроконтроллера AVR.

Для начала конечно, неплохо было бы определится что именно ты хочешь от программы? Что она делать то должна?

А по-поводу алгоритмизации - нет универсального ответа, некоторые люди «визуалисты» - они пока визуально, иногда «перед внутренним взором» общую картину не представят - у них мало чего путного получается и им необходимо рисовать,рисовать,рисовать. Другие наоборот - картинки их только сбивают и они предпочитают сразу набрасывать код, постепенное его дописывая. Ни то, ни другое - ни хуже, ни лучше, просто особенности восприятия - так что пробуй по всякому и смотри как лучше идёт. Хороший критерий для оценки «лучше» - время, засекай сколько ты потратишь на реализацию некоторой задачи если будешь сразу писать код и если сначала нарисуешь блок-схему, а потом по ней напишешь код.

Как-то так.