Кто как пишет алгоритмы?

Речь не о коде непосредственно, речь о другом.

Решил я, например, автоматизировать полив огорода. Приблизительно понимаю, что надо в какое-то время включать насос, заливать бочку, открывать краны, etc.
Все это лишь приблизительно.

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

Получается типа такого:



Ну это же, наверно, не правильно? Кто как действует? У кого-нибудь хватает силы воли до конца нарисовать алгоритмы и потом писать код? Как вы это делаете?

 

Я сначала пишу матом по белому, что я хочу получить

 

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

 

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

 

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

 

Я тоже сразу кодю. Когда-то пробовал на бумаге, блок схемами, но всё равно получается if else.… так что теперь время не трачу. Но код собираю маленькими кусками, сначала отлаживаю, потом дальше новых жуков добавляю и снова ловлю. Когда всё готово, переписываю с учетом всех возникших тонкостей, пытаюсь оптимизировать. Помню, когда первый раз пробовал программу писать, карточную игру, на размешивание колоды не смог придумать ничего лучше, как завести 36 переменных и сравнивал их друг с другом (представили, да, код). Вторая версия уместилась в 5 строк. Так был доволен прогрессом

 

У меня в изыде что-то в бекапах, что так в версиях.

 

Лучше (корректнее) писать русским по белому, а не вводить еще один язык (матерный).
Удобно кроме просто слов русского языка ввести свои спец. обозначения для отдельных операций, но нужно обязательно написать, и иметь табличку перевода этих обозначений на русский.
Гляньте про роль алгоритма - http://forum.amperka.ru/threads/Необходима-помощь-в-решении-проблемы-с-alphabot.17854/#post-210633
Про свою систему обозначений: Можно использовать конструкции из языков высокого уровня (присвоение, ветвление...), а можно придумать свои, исходя из специфики исполнительного механизма (что-нить навроде - "разжать захват", "поднять правый манипулятор", "мигнуть фарой"...).
-----
Рисовать блок-схемы ромбиками/квадратиками со стрелочками - тухлая практика.
Вам же этот текст алгоритма предстоит переводить на формальный язык, а текст переводить удобнее, чем картинку! Да, и коментарии для проги уже, считай готовы - не надо ничего выдумывать.
Потом проверяя свою прогу (с коментариями из строк алгоритма) вы себе же пять раз "спасибо" скажете!
-----
Совет: Не используйте в записи алгоритма синтаксис идентификатора, и все, что с ним связано.
Можно только ввести (в начале текста) обозначения/сокращения для длинных понятий (напр. - "Температура за окном" - Ту) и везде далее в тексте использовать принятые (вами) ранее сокращения
Имена переменным/идентификаторам придумает кодировщик (возможно, что использует ваши же сокращения) при переводе вашего текста алгоритма на формальный язык.

 

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

 

Начинаю с распределения пинов. ... сколько нужно на вход и куда какой датчик. Потом выходы ... куда какой исполнительный механизм. На простых скетчах проверяю работоспособность датчиков и исполнительных механизмов. Это важно. Заодно докачиваю или устанавливаю их библиотеки.
По возможности короче и первым делом проверяю самую стрёмную часть идеи проекта. Или ту, в которой плохо разобрался. Как их осилил перехожу к написанию рутины и отладке.

 

Почитал ответы и понял,что все эти подходы полная ерунда. Я до определённой поры делал также"в лоб"
Жизнь заставила переосмыслить. Начальство на пальцах объясняло задачу.Задачу решал. Решение предоставлял. Начальство было недовольно,что сделано не так. Хотя я сделал все так.После этого я изменил
подход. Я писал четкий алгоритм решения поставленной задачи,при помощи квадратиков и ромбиков как
положено классически. Затем предоставлял алгоритм на утверждение. Начальство под алгоритмом расписывалось. Когда я этот алгоритм программно реализовывал и начальство выражало недовольство
реализацией программного решения,я тыкал ему в нос согласованный с ним алгоритм и просил указать
мой неправильный ход программной реализации. И в 100% доказывал не корректность поставленной задачи.
Без четкого алгоритма я бы не смог доказать свою правоту. Потом это вошло в привычку.Неукоснительно
соблюдая алгоритм-избегаем путаницы в реализации программного кода.

 

А в чем квадратики рисуете?

 

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

 

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

 

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

 

Я использую DiagramDesigner