это потому что программировать вы учились как самоучка
а не в высшем учебном заведении по правильной литературе
и ни дизайн патеррны, ни другие умные книги по правильной декомпозиции не читали
поэтому у вас краш как только много сущностей которые вы не знаете как связать
В ранней юности, начиная более-менее всерьез программировать, писал исключительно "из головы". Если был доступ к машине, то сразу начинал колотить код, если не было — писал на бумаге, потом наколачивал. Разумеется, регулярно вылезали непредусмотренные проблемы (несовместимость, особые случаи, сложности с расширением и т.п.). Иногда приходилось по нескольку раз переписывать изрядную часть кода.
Позже несколько раз пытался, как взрослые, начинать с проектирования. Помогало очень слабо. Общая структура программы, иерархия модулей/классов, их взаимодействие в целом неплохо видны и умозрительно. Если все это оформить в виде схемы или описания на псевдоязыке — выглядит логично и красиво, пока не начинаешь наполнять все это кодом. Почти всегда вылезают те же самые несовместимости, особые случаи, взаимные блокировки параллельных потоков, потеря полезной информации в недрах вложенных вызовов и т.п. Полученное так же приходится изрядно переписывать, плюс добавляется время на само проектирование.
Еще с возрастом усиливается склонность к прокрастинации. Если раньше, когда не было интернета (сперва — никакого, потом — богатого информацией), многое приходилось придумывать самостоятельно и делать с нуля, то теперь все чаще понимаешь, что бОльшая часть нужного уже где-то и как-то сделана, но сразу же встает вопрос, на что потратишь больше ресурсов: на разработку своего, понятного и полностью контролируемого, или на ковыряние в чужом, хождение по скрытым граблям, ожидание исправления багов и прочее. В итоге все больше времени уходит на тягостные раздумья о выборе оптимальных вариантов, а если б то же самое время убить на тупое написание кода, получилось бы не менее (а то и более) эффективно.
Вот сейчас заставил себя взяться за переделку одной из программ, чем собирался заняться уже года три, но в голове никак не складывалась четкая картина того, что должно было получиться в итоге. После нескольких дней наколачивания кода, с периодической переделкой структуры и взаимодействий, стало более-менее понятно, что получится в результате, и в целом уже начало оформляться. На несколько предыдущих попыток, когда пытался заранее спроектировать все красиво и изящно, ушло в разы больше времени — понятно, с нулевым результатом.
О подобных проблемах говорят и писатели: только у гениальных бывает, что текст льется на бумагу/клавиатуру прямо из головы, и потом достаточно лишь внести мелкие правки. Большинство же однозначно утверждает, что нужно тупо фигачить текст в том виде, как он получается прямо сейчас, расставляя метки в сомнительных местах, и заранее понимать, что бОльшую часть придется переписывать еще и еще. Когда я в молодости баловался журналистикой, именно такой подход давал наилучшие результаты. Бывало, наколотив уже половину статьи, понимал, что так выходит полная фигня, и нужно начинать совершенно с другой стороны, в другой последовательности, с другими акцентами и т.п. Иногда достаточно было переставить местами куски и слегка подправить, но приходилось и переписывать почти полностью. Если же силился заранее выстроить полную схему — толком ничего не получалось, пока не начинал писать текст.
Когда читаешь умные книги о разработке ПО, создается впечатление, что люди нашли способы достаточно быстрой и надежной разработки. Когда пытаешься применять это на практике, получается, что многие решения хороши лишь в идеальной среде, а в реальной они не намного лучше наколенных, зато менее очевидны и более сложны.
Кто делает софт в одиночку (хотя бы в объеме отдельных модулей/библиотек) — поделитесь, как у вас организована работа? Сперва тщательно проектируете структуру, интерфейсы, взаимодействие, и потом это чаще всего остается неизменным (хотя бы в целом), или же сразу начинаете делать наиболее явные куски, постепенно заполняя пробелы и подстраивая общую структуру к тому, что получилось? Удается ли выстроить стройную логику взаимодействия в многослойных абстракциях, параллельных потоках и подобном, или везде приходится лепить костыли для неочевидных частных случаев? Насколько сложно заставить себя перестать обдумывать, как сделать лучше, и начать делать хоть как-нибудь?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, gandjustas, Вы писали:
G>>About Face Купера G>>Жемчужины программирования Бентли G>>Pragmatic Programmer Ханта и Томаса
ЕМ>Спасибо, полистал навскидку. Первое — в основном об пользовательском интерфейсе, этого вопроса я даже не поднимал в данной ветке. Второе и третье — самые общие приемы, которые многократно описаны в различной литературе, статьях, гайдлайнах. Мало-мальски опытному программисту многое из этого понятно интуитивно. Так что не нашел там ничего особенного по обсуждаемым здесь вопросам. Если считаете, что я неправ — укажите, пожалуйста, конкретные главы/пункты.
Выглядит как "не читал, но осуждаю". Ну ваше правод.
G>>Любую программу можно описать в терминах функций, принимающих что-то на вход и дающих что-то на выходе. ЕМ>Если свести все к абсурду, то любую программу можно представить, как функцию, на входе которой объект "задача", а на выходе — объект "решение". Но философия мне малоинтересна, интересны конкретные, практические приемы.
Это не абсурд, а самая что ни на есть правда. Вы представляете программу как функцию входных данных и разибваете её на шаги-функции, вызывающие друг друга, которые дают в итоге необходимые выходные данные.
Если у вас на старте нет представления о том, какая функция вам нужна, то программу вы не напишите.
G>>Я вижу проблему в том, что вы не на результате фокусируетесь, а на внутренней структуре программы. ЕМ>Проблемы с видением результата у меня возникают в основном в плане GUI — какой внешний вид придать окнам программы, в каком виде удобнее отображать данные и элементы управления, как организовать структуру меню и т.п. Здесь я этих вопросов не поднимал — речь исключительно о внутренней структуре, которую нужно сделать максимально непротиворечивой, без лишних зависимостей (как статических, так и динамических).
Внутренняя структура зависит от интерфейса программы. Об этому упоминается в about face, которую вы не захотели читать.
ЕМ>>>Во многих случаях у мой софт не взаимодействует с пользователем непосредственно — только через ОС и ее подсистемы. Он вообще не умеет "выглядеть" — умеет только отвечать на запросы и генерить свои. G>>Это мантра, которая вам мешает. ЕМ>Вы представляете, как устроен и работает, например, драйвер устройства?
Да, даже создавал такой драйвер.
ЕМ>Как, с Вашей точки зрения, "выглядят" драйверы дисков, видео- и звуковых адаптеров?
Какое это имеет отношение к осбуждаемой теме?
G>>Не существует ни одно задачи где параллелизм является необходимым для работы. ЕМ>Сильно подозреваю, что Ваш опыт в разработке софта весьма фрагментарен.
Подозреваю что вы тоже не знаете ни одной такой задачи.
Здравствуйте, gandjustas, Вы писали:
G>Это не абсурд, а самая что ни на есть правда. Вы представляете программу как функцию входных данных и разибваете её на шаги-функции, вызывающие друг друга, которые дают в итоге необходимые выходные данные. G>Если у вас на старте нет представления о том, какая функция вам нужна, то программу вы не напишите.
Ну серьезно, это выглядит как ответ программиста из анекдота. Всё правильно, как будто списано с академического пейпера (или статьи по хаскелю), но бесполезно для любой более-менее сложной программы. В качестве упражнения можно описать сайт рсдн как функцию входных данных Получится либо чушь, либо (если у вас нечеловеческий уровень интеллекта) спецификация валидная, но бесполезная без такого же уровня интеллекта.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Когда читаешь умные книги о разработке ПО, создается впечатление, что люди нашли способы достаточно быстрой и надежной разработки. Когда пытаешься применять это на практике, получается, что многие решения хороши лишь в идеальной среде, а в реальной они не намного лучше наколенных, зато менее очевидны и более сложны.
Нашли конечно, только они в других книгах описаны.
ЕМ>Кто делает софт в одиночку (хотя бы в объеме отдельных модулей/библиотек) — поделитесь, как у вас организована работа?
Я иногда делаю pet projects, не связанные с зарабатыванием денег. Много раз уже спотыкался на одном и том же, назову это "проектирование снизу вверх".
Обычно желание делать pet project возникает не из-за реальной потребности, которую надо закрыть, а из того, что ты хочешь попробовать новый подход\язык\технологию. Поэтому начинаешь непосредственно разработку с основной фишки — новой технологии, языка или подхода. Аккуратно воспроизводишь то, что ты видел в статьях, учебных видео или книжках. А потом оказывается что все это не помогает закончить программу. Получив новый опыт ты уходишь на второй круг, но начинаешь с того же места. Далее третий, и так до бесконечности.
Все pet-проекты, которые я довел до конца, были созданы начиная с "интерфейса пользователя", не всегда это был именно GUI, иногда это было просто число возвращаемое функцией в плагине, но я заранее знал какое это должно быть число.
Я даже больше скажу: вообще нет смысла заниматься кодированием пока вы не определите как будет "выглядеть" ваше приложение для "пользователя". Ибо вы не дойдете до конца.
ЕМ>Сперва тщательно проектируете структуру, интерфейсы, взаимодействие, и потом это чаще всего остается неизменным (хотя бы в целом), или же сразу начинаете делать наиболее явные куски, постепенно заполняя пробелы и подстраивая общую структуру к тому, что получилось?
После того как "интерфейс пользователя" готов, то возникают за ним котроллеры\хэндлеры\баттонклики в которых пишется логика. Если логика разрастается сильно, то проводится рефакторинг, выделяются шаблоны итд.
ЕМ>Удается ли выстроить стройную логику взаимодействия в многослойных абстракциях, параллельных потоках и подобном, или везде приходится лепить костыли для неочевидных частных случаев?
Нет, вообще никогда. Начинать всегда стоит с одного слоя. А про параллельные потоки лучше сразу забыть пока у вас не заработает все в одном потоке.
ЕМ>Насколько сложно заставить себя перестать обдумывать, как сделать лучше, и начать делать хоть как-нибудь?
Как-то так https://youtu.be/2RhvJ4VY6Cg
Здравствуйте, Евгений Музыченко, Вы писали:
bnk>>для этого есть область видимости. Ну public/private в смысле
ЕМ>Это само собой. Я про то, что в святцах рекомендуется стремиться к независимости любой функции, а наличие особых условий, в которых она может быть вызвана, объявлено моветоном.
Если смотреть не на мантру, а для чего она была придумана, то это обретает смысл — независимую функцию легче протестировать.
В общем надо сначала согласиться с какой-то базовой системой аксиом, типа "чем раньше находится ошибка — тем дешевле ее починить".
Не думаю что с этим кто-то будет спорить, или?
Как найти ошибку раньше?
Пусть например компилятор их находит, чем больше ошибок найдет компилятор, тем лучше.
Отсюда растет идея юнит-тестов и тестирования программы прямо во время компиляции по сути.
Чтобы юнит-тесты было легко писать, тестируемым функциям лучше быть независимыми.
В общем должна быть какая-то высшая цель в том, чтобы делать функции независимыми.
Если бы полностью независимые функции были на самом деле сильно удобнее, вложенные функции или лямбды например не стали бы так популярны.
Что будет перевешивать — тяжесть последствий от пропущенной ошибки, или же геморрой связанный с поддержкой юнит-тестирования, зависит от конкретного проекта, кмк.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, gandjustas, Вы писали:
G>>Нашли конечно, только они в других книгах описаны. ЕМ>В которых?
About Face Купера
Жемчужины программирования Бентли
Pragmatic Programmer Ханта и Томаса
G>>иногда это было просто число возвращаемое функцией в плагине, но я заранее знал какое это должно быть число.
ЕМ>Если программу можно описать в терминах математических функций, выдающих на выходе состояния, определяемые входами, то никаких сложностей не возникает.
Любую программу можно описать в терминах функций, принимающих что-то на вход и дающих что-то на выходе.
ЕМ>Мне чаще приходится делать софт, получающий множество независимых сигналов/сообщений/запросов с разных сторон, обрабатывающих их все в совокупности, и генерирующий сигналы/сообщения/запросы в адрес других подсистем. Там большое значение имеют синхронизация, взаимные блокировки, режимы, состояния и т.п. По сути, это конечные автоматы с изрядным количеством входов, выходов и промежуточных состояний — например, реализация протоколов взаимодействия.
Я вижу проблему в том, что вы не на результате фокусируетесь, а на внутренней структуре программы. Это прекрасный способ никогда программу не сделать.
G>>вообще нет смысла заниматься кодированием пока вы не определите как будет "выглядеть" ваше приложение для "пользователя". Ибо вы не дойдете до конца. ЕМ>Во многих случаях у мой софт не взаимодействует с пользователем непосредственно — только через ОС и ее подсистемы. Он вообще не умеет "выглядеть" — умеет только отвечать на запросы и генерить свои.
Это мантра, которая вам мешает.
G>>про параллельные потоки лучше сразу забыть пока у вас не заработает все в одном потоке. ЕМ>Забыть можно, когда параллелизм вводится в виде бонуса, для ускорения/сглаживания работы. У меня он чаще всего является необходимым условием функционирования софта. Если где-то синхронизация/взаимоблокировка сделана неправильно, то очень быстро виснет или падает с малопонятными ошибками.
Это тоже мантра, которая вам мешает.
Не существует ни одно задачи где параллелизм является необходимым для работы.
Из всего сказанного могу сделать вывод, что вы программу делаете не для результата, а для того чтобы повозиться с многопоточностью, синхронизацией и блокировками. Вас очевидно привлекает этот процесс. Тут нечего исправлять.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Позже несколько раз пытался, как взрослые, начинать с проектирования. Помогало очень слабо. Общая структура программы, иерархия модулей/классов, их взаимодействие в целом неплохо видны и умозрительно.
Потому что нормальное проектирование это не про это все. Нормальный диздок начинается с параграфа, описывающего что мы собственно делаем, какую проблему решаем. Потом расписываем сценарии. Исходя из сценариев описываем UI или публичное API. А уж затем можно начинать углубляться в реализацию.
А ты все выворачиваешь вверх ногами, начиная проектирование с деталей реализации, а потом удивляешься фиговому результату.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Кто делает софт в одиночку (хотя бы в объеме отдельных модулей/библиотек) — поделитесь, как у вас организована работа? Сперва тщательно проектируете структуру, интерфейсы, взаимодействие, и потом это чаще всего остается неизменным (хотя бы в целом), или же сразу начинаете делать наиболее явные куски, постепенно заполняя пробелы и подстраивая общую структуру к тому, что получилось? Удается ли выстроить стройную логику взаимодействия в многослойных абстракциях, параллельных потоках и подобном, или везде приходится лепить костыли для неочевидных частных случаев? Насколько сложно заставить себя перестать обдумывать, как сделать лучше, и начать делать хоть как-нибудь?
У меня работа организована по шагам.
Причём, есть шаги разной степени по-уровням.
Шаги, где делаются самые мелкие задачи, проде написания той или иной функции.
Есть шаги куда глобальнее — скажем, сделать определённую фичу. Вот исходя из соображений этого шага, я решаю, какие у меня будут более мелкие шаги.
Нет иерархии действий. Т.е. делай раз, делай два, и так, до N. На выходе получается готовая программа.
Нет, я действую итеративно. Сейчас делаем этот шаг, смотрим получается, по результатам добавляем те или иные шаги, что мы будем делать после этого.
Я не пишу сразу весь код, а потом отлаживаю. Я пишу по более-менее законченным кусочкам, и потом отлаживаю этот вот получившийся кусочек. Чтобы у меня достаточно постоянно была определённая точно работающая кодовая база.
Если ты напишешь сразу весь код, по моему опыту знаю, ты утонешь в отладке, просто безвылазно. Тебе так или иначе, всё равно придётся отлаживать по-кускам.
Сразу накатать с первого захода огромное полотно кода, где всё будет прекрасно — это попросту нереально.
Оттого и подход по шагам. Накатали кусочек, посмотрели, как получилось, как стыкуется с остальным телом программы, не надо ли что-то изменить.
Если надо — организуешь шаг "интеграция и рефакторинг".
В пределах написания отдельного куска, скажем, какой-то фичи, я начинаю с общего планирования. На этом шаге, я прикидываю, как примерно будет всё устроено.
И продумываю самые ключевые вопросы, ответы на которые определяют дальнейший облик кода. Т.е. некий фундамент, на котором этот код будет зиждеться. Например, факты из API ОС.
Позволяет ли ОС сделать те или иные вещи? Если не позволяет, то мои планы неосуществимы, и надо искать иные пути.
Ещё, при общем планировании, решается схема работы кода. Т.е. примерно какие будут операции, какие форматы данных, как это всё будет устроено и работать.
Ну а дальше, я приступаю к реализации всех деталей. Для этого, организую соответствующие шаги.
Сделать код, делающий вещь №1. Сделать код, делающий вещь №2. И т.п. Разумеется, все эти шаги включают в себя как написание кода, так и его отладку.
Помимо написания кода, разумеется, я продумываю не только код. Например, тот же формат данных. На соответсвующих шагах, я решаю в подробностях, как будет он устроен. Возможно, потом, на других шагах я его прорефакторю.
Но сейчас будет первая версия.
Есть и другие шаги — интеграция всего кода фичи в единое целое, рефакторинг, интеграция кода фичи в тело программы.
Может быть шаг — написание документации.
В общем, разное бывает.
Бывает и то, что в процессе работы над деталями, выясняется, что возникла некая непреодолимая проблема. И надо временно бросить работу над фичей, и идти её устранять. А это уже совсем другие шаги, и другой уровень "глобальности шага" — устранение этой проблемы.
Т.е. вместо шага "написание фичи", рядом появляется шаг "устранение серьёзной проблемы", у него свои более мелкие подшаги, и я занимаюсь уже ими.
А написание фичи откладывается, ибо её написать нереально сейчас.
Написав фичу, я возвращаюсь к глобальным шагам, смотрю что буду делать дальше, теперь, когда кое-что имею новое. Возможно, я отмечу себе, что надо будет что-то там прорефакторить.
Но не обязательно прям сейчас, а позже. А сейчас, я буду делать ещё одну фичу.
Потом, когда будет накоплен массив фич, можно будет уже гонять то что получилось, как крупную программу.
Можно даже больше — показывать всё это другим людям, собирать feedback. Ну а дальше, планируем новые шаги по результатам.
Т.е. да, какой-то сплав нисходящей и восходящей разработки. И agile разработки. Т.к. долго жить без feedback неразумно.
Вот как организовать коллективную работу над программой — куда интереснее. Ибо когда разные люди одновременно делают разные фичи, а потом объединяют результаты — такое веселье может начаться... Такой рефакторинг...
Когда выясняется, что куча людей повторно делала одну и ту же работу, и образовались дублирующиеся вещи. Или что-то ещё нестыкуется.
А если уж над всем этим дедлайн висит и ограничение по бюджету — так вообще. Веселье по полной программе.
Здравствуйте, Евгений Музыченко, Вы писали:
НС>>Которые для тебя уже кто то спроектировал? ЕМ>Что значит "для меня"? Их спроектировали прежде всего для самой подсистемы.
Ну значит проектирование уже сделано до тебя, все просто.
НС>>Тогда да, проект тебе особо и не нужен, берешь и пилишь. ЕМ>Так я и пилю — получается криво.
Как определил?
ЕМ> Как мне сделать красиво, по заветам столпов от программирования?
Включать моск, как еще? Пиши код так, чтобы его было легко рефакторить, регулярно устраняй техдолг. There is no silver bullet.
Здравствуйте, bnk, Вы писали:
bnk>Имеется в виду, что поток выполнения один
Потоков в общем случае несколько, но есть "нормальные", где можно творить почти все, что хочется, и ограниченные теми самыми условиями на входе.
bnk>то есть выбор стоит между:
В плане выноса кода — примерно так.
bnk>Мне кажется, исполнение этого куска не должно зависеть от приоритетов или блокировок, то есть, технически, bnk>это то же самое (но потенциально есть лишний вызов функции во втором случае)?
Понятно, что сам по себе вынос кода ничего не меняет. Но вынесенный код периодически оказывается кандидатом на вызов из других функций/потоков, которые уже могут выполняться в неподходящих условиях (и это порой вовсе не следует из структуры кода, а выясняется лишь экспериментально, когда все уже переделано и давно работает, но в очередном обновлении винды меняют какую-нибудь внутреннюю логику блокировок, и привет). А выносить код в отдельную функцию, чтобы обвешивать ее грозными комментариями "вызывать только из ..." и проверками, не вызвана ли она в неподходящем контексте — это и есть те самые уродливые костыли.
bnk>Можно и не тестировать (не писать юнит-тесты), это нормально (с) Малышева.jpg
Я их вообще не пишу, ибо геморроя больше, чем эффекта. Только финальные, общие тесты.
Лично я просто пишу как получается. На каком-то этапе обычно всё переписываю с нуля, но переиспользуя куски старого кода, когда станет очевидно, что задуманная изначально архитектура не учитывала определённые вещи. Вероятно мне помогает то, что я использую Java, с которой такие трюки хорошо проходят в силу развитой IDE. Обычно со второго раза получается результат, который меня устраивает. Потом он обрастает дополнительным функционалом, доработками и тд, и в конце концов можно переписать всё ещё раз.
При таком подходе главное стараться писать код максимально изолированно, чтобы при переписывании собственно переписывания было как можно меньше, а было как можно больше переиспользования.
Но такой подход категорически не подойдёт, если разработчиков более одного человека.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Когда такая возможность есть — это просто отлично. Например, типичная интерактивная программа с менюшками и кучей функций, где можно сперва реализовать "Open File", потом "Close File", потом "Copy", "Paste" и т.п. А когда делается расширение какой-нибудь подсистемы, которое на почти любое действие получает от той подсистемы серию запросов, каждый из которых должно обработать полностью и корректно, иначе все упадет — это моя реальность.
Но разве тогда вообще есть выбор?
Если все интерфейсы и протоколы взаимодействия фиксированы, ты можешь контролировать (проектировать) только ту часть, которая связана собственно с функциональностью.
Я бы тогда вообще не парился по этому поводу, а напротив, радовался — за тебя все уже спроектировали, тебе осталось только реализовать как сказано, добавив свой кусочек.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Кто делает софт в одиночку (хотя бы в объеме отдельных модулей/библиотек) — поделитесь, как у вас организована работа?
Всё сложно.
С одной стороны, мне хочется какой-то идеальный фреймворк, в который идеально ляжет моё приложение и всё будет идеально, поддерживаемо, расширяемо и тестируемо.
С другой стороны, время, убитое на попытки сделать единообразно и хорошо, очень существенно превышает время, потраченное на делание велью.
С третей стороны, код, который я реально переиспользовал на практике — это код, который не зависит от остального приложения и библиотек с нестабильным API.
Но с четвертой стороны, чтобы собрать приложение из изолированных модульных кусочков, нужно писать очень много glue code — для интеграции этих кусочков между собой.
И я пока (примерно за 15 лет) не понял, какой путь правильный.
бейсик это уровень написание скриптов на bash
нашли чем гордиться
о том что вы программирование изучали в 80x годах по вашим знаниям и видно
Евгений, прекращайте превращаться обросшего жиром тролля,
какое отношение дедлоки, гонки итд(ваши фантазии) имеют отношение к правильной декомпозиции задач для того что бы не было до черта связей которые вы не можете связать ?
Здравствуйте, gandjustas, Вы писали:
G>Выглядит как "не читал, но осуждаю".
Я ж говорю — пролистал (бегло, но весь текст, не только оглавление). По интерфейсам много дельных мыслей, но сейчас вопрос не в этом. По проектированию их тоже хватает, но в основном из того, что я и так применяю десятки лет. Принципиально нового ничего не увидел.
G>Вы представляете программу как функцию входных данных и разибваете её на шаги-функции, вызывающие друг друга, которые дают в итоге необходимые выходные данные.
Это все прекрасно работает с программами, не имеющими промежуточных внутренних состояний. А у меня они почти все их имеют — более того, они строятся главным образом вокруг состояний, а не данных.
G>Если у вас на старте нет представления о том, какая функция вам нужна, то программу вы не напишите.
Представление о том, что нужно, у меня есть всегда. Вопрос о том, как это сделать, применив наименьшее количество кривых костылей.
G>Внутренняя структура зависит от интерфейса программы.
Еще раз напоминаю: программы, о которых здесь идет речь, вообще не имеют UI, как такового.
ЕМ>>Вы представляете, как устроен и работает, например, драйвер устройства? G>Да, даже создавал такой драйвер.
Каким устройством он управлял? Как Вы организовали хотя бы обработку прерываний без синхронизации с основным кодом?
ЕМ>>Как, с Вашей точки зрения, "выглядят" драйверы дисков, видео- и звуковых адаптеров? G>Какое это имеет отношение к осбуждаемой теме?
Самое непосредственное. По-Вашему, пока разработчик драйвера не представит себе, как тот "выглядит", он не сможет его изготовить.
G>>>Не существует ни одно задачи где параллелизм является необходимым для работы. ЕМ>>Сильно подозреваю, что Ваш опыт в разработке софта весьма фрагментарен. G>Подозреваю что вы тоже не знаете ни одной такой задачи.
Здравствуйте, Sinclair, Вы писали:
S>я начинаю колбасить код, который потом многократно переписывается.
Вот и у меня к успеху приводила только такая тактика. Все попытки сперва создать изящную структуру, а затем наполнить ее работающими кодом, не поломав даже в малости, провалились.
S>А дальше — засада. Потому, что для производительности этой immutable коллекции надо сделать так, чтобы операция Add повторно использовала те же данные, которые уже лежат в существующем списке. И если всё делать через интерфейсы (а вариантность в дотнете работает только через них), то производительность падает на дно. Банальная операция list[x] начинает тормозить, как не в себя (а должна быть не хуже o(log(N)), и с нормальным коэффициентом).
А у меня много мест, где нехватка производительности будет не просто раздражать юзера, а приведет к полной неработоспособности конфигурации, в которой участвует софт и, как следствие, к полному отказу от него. Причем самые большие проблемы возникают даже не со скоростью выполнения "алгоритмического" кода, а с количеством взаимоблокировок потоков и местами их размещения в коде. Предсказать заранее, где именно будет тормозить, а где прокатит, почти никогда не получается — только эмпирически. А чтобы вся эта хрень хотя бы просто зашевелилась, нужно написать бОльшую часть кода, затычки мало где катят. Поэтому и приходится сперва сшивать все на живую нитку, затем приводить в устойчивое состояние, и только после этого пытаться придать стройность той мешанине, что получилась.
Здравствуйте, Евгений Музыченко, Вы писали:
НС>>А ты все выворачиваешь вверх ногами, начиная проектирование с деталей реализации ЕМ>Где Вы у меня такое усмотрели?
Важнее чтоя у тебя не усмотрел — требования, юзкейсы и т.п.
ЕМ> Наоборот, я пытался начинать с общей структуры.
Общая структура это и есть детали реализации, которые, в норме, должны вытекать из сценариев.
ЕМ> Но, пока не углубишься в детали реализации, далеко не всегда ясно, как будут передаваться управление и сообщения между моим кодом и кодом подсистемы, в которую он встраивается.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Проблемы с видением результата у меня возникают в основном в плане GUI — какой внешний вид придать окнам программы, в каком виде удобнее отображать данные и элементы управления, как организовать структуру меню и т.п. Здесь я этих вопросов не поднимал — речь исключительно о внутренней структуре
Есть такой более менее консенсус — софт, взаимодействующий с пользователем, должен проектироваться по принципу frontend first. Т.е. сперва ты проектируешь UX (т.е. внешний вид GUI и его поведение), и только потом реализуешь к нему бек. Если поступить наоборот — скорее всего на выходе получится неудобное пользователям чудище.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>О подобных проблемах говорят и писатели: только у гениальных бывает, что текст льется на бумагу/клавиатуру прямо из головы, и потом достаточно лишь внести мелкие правки.
Это не у гениальных, просто талантливых. Тексты, как известно, диктуются духами, писакам достаточно просто их переносить на бумагу.
Не слышишь голосов в голове — не стоит и тужиться, все равно на выходе будет лажа.
ЕМ>Когда читаешь умные книги о разработке ПО, создается впечатление, что люди нашли способы достаточно быстрой и надежной разработки. Когда пытаешься применять это на практике, получается, что многие решения хороши лишь в идеальной среде, а в реальной они не намного лучше наколенных, зато менее очевидны и более сложны.
ЕМ>Кто делает софт в одиночку (хотя бы в объеме отдельных модулей/библиотек) — поделитесь, как у вас организована работа? Сперва тщательно проектируете структуру, интерфейсы, взаимодействие, и потом это чаще всего остается неизменным (хотя бы в целом), или же сразу начинаете делать наиболее явные куски, постепенно заполняя пробелы и подстраивая общую структуру к тому, что получилось? Удается ли выстроить стройную логику взаимодействия в многослойных абстракциях, параллельных потоках и подобном, или везде приходится лепить костыли для неочевидных частных случаев? Насколько сложно заставить себя перестать обдумывать, как сделать лучше, и начать делать хоть как-нибудь?
Вообще для себя у меня есть как бы трекер задач.
Вот он и вносит какой-то порядок в планирование, приоритизацию, ну и просто чтобы не забыть.
Все спроектировать, а потом генерировать код, пыталась в Rational Rose, сейчас они вроде отдыхают на помоечке.
Предпочитаю начать делать хоть что-нибудь, большие куски, потом детали. Сразу в коде, да.
Свои проекты у меня слишком мелкие (как правило меньше 20к строк), чтобы для них потребовалась реальное проектирование.
Ну вот еще всякие юнит-тесты помогают, позволяют понять и задекларировать,
что вообще требуется и как должно работать, хотя я ни разу не фанат TDD.
А вот в компании, где больше нескольких программистов, доска с квадратиками и стрелками уже работает, обеспечивает общее понимание.
Тут может быть лучше несколько дней потерять на совещаниях и обсуждениях прежде чем начинать что-то пилить.
"Умные книги" зачастую заточены скорее под командную разработку, причем немаленьких систем (ну скажем больше 100к строк кода)
Здравствуйте, vsb, Вы писали:
vsb>При таком подходе главное стараться писать код максимально изолированно
Когда есть возможность оформлять функциональные блоки изолированно, проблем возникает минимум. Самые затыки начинаются, когда нужно делать взаимодействие со внешними подсистемами, которые могу вызывать я, а они — меня. А когда все это еще и асинхронно и многопоточно — вообще вилы. Ближайший пример — фильтры DirectShow.
Здравствуйте, bnk, Вы писали:
bnk>Предпочитаю начать делать хоть что-нибудь, большие куски, потом детали.
Когда такая возможность есть — это просто отлично. Например, типичная интерактивная программа с менюшками и кучей функций, где можно сперва реализовать "Open File", потом "Close File", потом "Copy", "Paste" и т.п. А когда делается расширение какой-нибудь подсистемы, которое на почти любое действие получает от той подсистемы серию запросов, каждый из которых должно обработать полностью и корректно, иначе все упадет — это моя реальность.
Здравствуйте, reversecode, Вы писали:
R>это потому что программировать вы учились как самоучка
Учиться программировать я начинал в школе программистов у Ершова, на приличных языках (слова "фортран" и "бэйсик" там употреблялись наравне с матами), и с профессиональными учителями.
R>а не в высшем учебном заведении по правильной литературе
В высшем учебном заведении я учился во второй половине 80-х, когда в ходу (и в приоритетах) были совсем другие парадигмы. В частности, ООП тогда было сугубой экзотикой, а C++ только народился.
R>и ни дизайн патеррны, ни другие умные книги по правильной декомпозиции не читали
Читал, а толку? В применении к моим задачам это выглядит, как "я знаю самбо, дзюдо, каратэ и еще много страшных слов". Сможете показать, как с помощью дизайн-паттернов и подобных техник заранее (то есть, на этапе проектирования) избежать избыточных зависимостей, дедлоков, гонок, инверсий приоритетов и т.п.?
Здравствуйте, bnk, Вы писали:
bnk>Если все интерфейсы и протоколы взаимодействия фиксированы, ты можешь контролировать (проектировать) только ту часть, которая связана собственно с функциональностью. bnk>Я бы тогда вообще не парился по этому поводу, а напротив, радовался — за тебя все уже спроектировали, тебе осталось только реализовать как сказано, добавив свой кусочек.
Когда надо добавить именно локальный "кусочек" (например, расширение Explorer'а в винде, чтобы показывать свои пункты в контекстных менюшках), то отдельный этап проектирования даже в голову не приходит.
А когда нужно сделать, например, драйвер, который не просто тупо программирует устройство и обслуживает прерывания, но и расширяет его функциональность, гоняя какие-нибудь асинхронные обработки в параллельных потоках, то классическое проектирование мало что дает. Выстраиваешь изящную иерархию и вроде бы корректное взаимодействие, а потом оказывается, что уведомление о каком-нибудь событии присылается в неподходящем контексте. Делаешь, как советует дядя Боб, 100500 мелких функций, вызывающих одна другую в разных комбинациях, а потом выясняется, что эти комбинации должны работать на разных приоритетах, где доступны не все ресурсы и не все возможности API. Делаешь меньше критических секций, используя их для крупных блоков кода — получаешь тормоза, делаешь больше — получаешь дедлоки. Надежных способов бороться со всем этим не придумали — только разнообразные костыли и эмпирика.
А еще, когда делаешь подобные расширения — они часто вообще не заработают, пока не напишешь практически все. Для пресловутого интерактивного приложения, в котором за менюшки дергает только юзер, можно написать функции-затычки — тестировщику этого достаточно. А в сложносвязанной подсистеме нужно написать 80-90% всего когда, чтобы она более-менее зашевелилась. И это тоже сильно напрягает — фигачишь неделю, месяц, и даже не знаешь, будет оно нормально работать в таком виде, или придется переписывать половину. Отсюда и прокрастинация.
Здравствуйте, L.K., Вы писали:
LK>Т.е. сначала должна быть хотя бы "программа-минимум". Как всё должно быть, чтобы всё стало "более-менее удовлетворительно".
С "программой-минимум" как раз проблем нет. То есть, общая структура, функциональные блоки, схема взаимодействия понятны и так, в голове, без отдельного этапа проектирования. Задница начинается, когда уже написана изрядная часть кода, и выясняется, что не учтены нюансы, частные случаи, но их обработка требует или костылей, или изрядной переделки структуры. Чтобы обнаружить это на этапе проектирования, нужно фактически провести почти тот же объем работы, выписав хотя бы все форматы данных, внешние интерфейсы, функции API, наборы параметров и прочее, и уже потом писать со всего этого код. Проще и быстрее сразу начинать писать код.
ЕМ>С "программой-минимум" как раз проблем нет. То есть, общая структура, функциональные блоки
"Программа-минимум" — это не структура и не блоки, а вещи более высокого уровня. Для чего выполняется работа? Что будет в итоге? Куча бабла, мировая известность, спасение человечества?
Если задача не выполняется три года, то, может быть, она не нужна и не важна? А если нужна и важна, то получается, что вместо неё делается что-то менее нужное и важное?
Здравствуйте, L.K., Вы писали:
LK>"Программа-минимум" — это не структура и не блоки, а вещи более высокого уровня. Для чего выполняется работа? Что будет в итоге? Куча бабла, мировая известность, спасение человечества?
Если дать ответы на все эти вопросы, как это поможет лучше выполнить чисто техническую часть?
LK>Если задача не выполняется три года, то, может быть, она не нужна и не важна? А если нужна и важна, то получается, что вместо неё делается что-то менее нужное и важное?
Все, что делается, определенно нужно и важно, но для того, чтобы более-менее объективно определить степень нужности/важности каждого аспекта, нужно проводить отдельные бизнес-исследования. А речь, напомню, о разработчике-одиночке, а не о компании.
Здравствуйте, scf, Вы писали:
scf>время, убитое на попытки сделать единообразно и хорошо, очень существенно превышает время, потраченное на делание велью.
Ладно б только время, убитое на сами попытки сделать. Много времени уходит на мучительные раздумья и попытки хотя бы понять, как лучше делать.
scf>код, который я реально переиспользовал на практике — это код, который не зависит от остального приложения и библиотек с нестабильным API.
Ну да — локальный, изолированный код, вроде набора функций работы со строками (особенно статическими, когда даже динамическую память привлекать не нужно).
scf>чтобы собрать приложение из изолированных модульных кусочков, нужно писать очень много glue code — для интеграции этих кусочков между собой.
Именно. Вот я сейчас наплодил полтора десятка классов, наследующихся один от другого, чтобы точнее отразить иерархию сущностей — объем glue code уже сильно превысил объем кода, потребного для реализации того же самого на пяти-шести классах, с отработкой всех частных случаев.
scf>И я пока (примерно за 15 лет) не понял, какой путь правильный.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Кто делает софт в одиночку (хотя бы в объеме отдельных модулей/библиотек) — поделитесь, как у вас организована работа? Сперва тщательно проектируете структуру, интерфейсы, взаимодействие, и потом это чаще всего остается неизменным (хотя бы в целом), или же сразу начинаете делать наиболее явные куски, постепенно заполняя пробелы и подстраивая общую структуру к тому, что получилось? Удается ли выстроить стройную логику взаимодействия в многослойных абстракциях, параллельных потоках и подобном, или везде приходится лепить костыли для неочевидных частных случаев? Насколько сложно заставить себя перестать обдумывать, как сделать лучше, и начать делать хоть как-нибудь?
Сначала делаю максимально просто, даже если вижу что тут нужно бы сделать более общий вид, потом при добавлении функциональности, начинаю изменять этот простой код под новый сценарий, теперь он покрывает то что было +1 фича, берем следующую фичу и смотрим, не ложится опять переписываем, ложится хорошо, оставляем как есть. Вариант прочитал ТЗ, спроектировал, реализовал сразу под все сценарии не подходит, так как почти в каждом сценарии есть не учтенные нюансы, поэтому делаю максимально просто чтобы потом можно было просто изменить. Из проектирования есть только высокоуровневое разделение ответственности, этот класс/подсистема отвечает за такой то аспект программы, всё, реализуем только там, если получается много, разбиваем на несколько классов чтобы проще было поддерживать, но наружу торчит всё равно один фасад, да оберточного кода без логики, который тупо перекладывает данные или информирует что данные изменились приходится в таком случае писать достаточно много, но потом добавлять что то новое относительно просто.
Здравствуйте, Igore, Вы писали:
I>Сначала делаю максимально просто, даже если вижу что тут нужно бы сделать более общий вид, потом при добавлении функциональности, начинаю изменять этот простой код под новый сценарий, теперь он покрывает то что было +1 фича, берем следующую фичу и смотрим
Такой метод годится только для независимых фич, вроде уже упомянутых операций по инициативе пользователя. К софту, который встраивается в ОС или ее подсистему сразу множеством концов, такое почти не применимо. Это примерно как ставить современный двигатель в автомобиль: нельзя его просто наживить на болты, подключить только трубку с топливом, и сразу запускать. Нужно подключить все трубки, датчики, клапаны и прочее, залить масло, антифриз (или хотя бы воду), и только после этого имеет смысл запускать.
Здравствуйте, gandjustas, Вы писали:
G>Нашли конечно, только они в других книгах описаны.
В которых?
G>иногда это было просто число возвращаемое функцией в плагине, но я заранее знал какое это должно быть число.
Если программу можно описать в терминах математических функций, выдающих на выходе состояния, определяемые входами, то никаких сложностей не возникает. Мне чаще приходится делать софт, получающий множество независимых сигналов/сообщений/запросов с разных сторон, обрабатывающих их все в совокупности, и генерирующий сигналы/сообщения/запросы в адрес других подсистем. Там большое значение имеют синхронизация, взаимные блокировки, режимы, состояния и т.п. По сути, это конечные автоматы с изрядным количеством входов, выходов и промежуточных состояний — например, реализация протоколов взаимодействия.
G>вообще нет смысла заниматься кодированием пока вы не определите как будет "выглядеть" ваше приложение для "пользователя". Ибо вы не дойдете до конца.
Во многих случаях у мой софт не взаимодействует с пользователем непосредственно — только через ОС и ее подсистемы. Он вообще не умеет "выглядеть" — умеет только отвечать на запросы и генерить свои.
G>про параллельные потоки лучше сразу забыть пока у вас не заработает все в одном потоке.
Забыть можно, когда параллелизм вводится в виде бонуса, для ускорения/сглаживания работы. У меня он чаще всего является необходимым условием функционирования софта. Если где-то синхронизация/взаимоблокировка сделана неправильно, то очень быстро виснет или падает с малопонятными ошибками.
Здравствуйте, gandjustas, Вы писали:
G>About Face Купера G>Жемчужины программирования Бентли G>Pragmatic Programmer Ханта и Томаса
Спасибо, полистал навскидку. Первое — в основном об пользовательском интерфейсе, этого вопроса я даже не поднимал в данной ветке. Второе и третье — самые общие приемы, которые многократно описаны в различной литературе, статьях, гайдлайнах. Мало-мальски опытному программисту многое из этого понятно интуитивно. Так что не нашел там ничего особенного по обсуждаемым здесь вопросам. Если считаете, что я неправ — укажите, пожалуйста, конкретные главы/пункты.
G>Любую программу можно описать в терминах функций, принимающих что-то на вход и дающих что-то на выходе.
Если свести все к абсурду, то любую программу можно представить, как функцию, на входе которой объект "задача", а на выходе — объект "решение". Но философия мне малоинтересна, интересны конкретные, практические приемы.
G>Я вижу проблему в том, что вы не на результате фокусируетесь, а на внутренней структуре программы.
Проблемы с видением результата у меня возникают в основном в плане GUI — какой внешний вид придать окнам программы, в каком виде удобнее отображать данные и элементы управления, как организовать структуру меню и т.п. Здесь я этих вопросов не поднимал — речь исключительно о внутренней структуре, которую нужно сделать максимально непротиворечивой, без лишних зависимостей (как статических, так и динамических).
ЕМ>>Во многих случаях у мой софт не взаимодействует с пользователем непосредственно — только через ОС и ее подсистемы. Он вообще не умеет "выглядеть" — умеет только отвечать на запросы и генерить свои. G>Это мантра, которая вам мешает.
Вы представляете, как устроен и работает, например, драйвер устройства? Как, с Вашей точки зрения, "выглядят" драйверы дисков, видео- и звуковых адаптеров?
G>Не существует ни одно задачи где параллелизм является необходимым для работы.
Сильно подозреваю, что Ваш опыт в разработке софта весьма фрагментарен.
G>Из всего сказанного могу сделать вывод, что вы программу делаете не для результата, а для того чтобы повозиться с многопоточностью, синхронизацией и блокировками. Вас очевидно привлекает этот процесс.
Этот вывод следует исключительно из Вашей неосведомленности о вещах, которыми я преимущественно занимаюсь.
Здравствуйте, scf, Вы писали:
scf>Здравствуйте, gandjustas, Вы писали:
G>>Это не абсурд, а самая что ни на есть правда. Вы представляете программу как функцию входных данных и разибваете её на шаги-функции, вызывающие друг друга, которые дают в итоге необходимые выходные данные. G>>Если у вас на старте нет представления о том, какая функция вам нужна, то программу вы не напишите.
scf>Ну серьезно, это выглядит как ответ программиста из анекдота. Всё правильно, как будто списано с академического пейпера (или статьи по хаскелю), но бесполезно для любой более-менее сложной программы. В качестве упражнения можно описать сайт рсдн как функцию входных данных
Берешь UI и каждую функцию в UI описываешь как функцию входных-выходных данных. Это очень помогает не только начать, но и закончить разработку.
Почему вы видите в этом проблему?
scf>Получится либо чушь, либо (если у вас нечеловеческий уровень интеллекта) спецификация валидная, но бесполезная без такого же уровня интеллекта.
А вы хоть раз пробовали так делать? подозреваю что нет.
Это мне напомнило давний спор про оценку размера программы и сроков разработки. Один мой знакомый, хорошо знающий модель COCOMO2, оценил размер будущей программы в строках и во времени разработки. Тимлид с ним спорил, что сейчас языки другие и вообще можно сделать быстрее. В итоге модель разошлась с реальностью не более чем на 10%.
Вообще любая зарекомендовавшая себя практика в ИТ выглядит как нерабочая и бесполезная пока ты ей не занимаешься.
Здравствуйте, Евгений Музыченко, Вы писали:
vsb>>При таком подходе главное стараться писать код максимально изолированно
ЕМ>Когда есть возможность оформлять функциональные блоки изолированно, проблем возникает минимум. Самые затыки начинаются, когда нужно делать взаимодействие со внешними подсистемами, которые могу вызывать я, а они — меня. А когда все это еще и асинхронно и многопоточно — вообще вилы. Ближайший пример — фильтры DirectShow.
На мой взгляд этот вопрос стоило бы проработать подробней. Я не знаю API DirectX, но уверен, что всё можно оформить изолированно, с юнит-тестами и потом всё "сцепить" воедино, если поставить такую задачу. Добавить промежуточные интерфейсы где-то, например. Многопоточность — сложная тема, но и там есть свои паттерны, позволяющие бороться со сложностью и изолировать куски кода. Например когда архитектура построена в виде акторов, с одной стороны каждого актора можно тестировать, как обычный однопоточный объект, с другой стороны фреймворк, который обеспечивает запуск и взаимодействие акторов уже считается достаточно протестированным и обеспечивает многопоточность без багов (ну почти без багов, дедлок скорей всего всё ещё возможен, но всё же многие баги устраняются). Проблемы начинаются, когда потоками рулят вручную, с общим состоянием, ручной синхронизацией на мютексах или подобных примитивах. Такой код действительно не протестировать адекватно, поэтому его нужно по возможности избегать, если взглядом окинуть всё не получается.
Впрочем у тебя своя специфика с реалтаймом. То, о чём я пишу, достигается с некоторым оверхедом, для твоих задач его может быть слишком много, а может быть и не много.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Кто делает софт в одиночку (хотя бы в объеме отдельных модулей/библиотек) — поделитесь, как у вас организована работа? Сперва тщательно проектируете структуру, интерфейсы, взаимодействие, и потом это чаще всего остается неизменным (хотя бы в целом), или же сразу начинаете делать наиболее явные куски, постепенно заполняя пробелы и подстраивая общую структуру к тому, что получилось? Удается ли выстроить стройную логику взаимодействия в многослойных абстракциях, параллельных потоках и подобном, или везде приходится лепить костыли для неочевидных частных случаев? Насколько сложно заставить себя перестать обдумывать, как сделать лучше, и начать делать хоть как-нибудь?
Не, я начинаю колбасить код, который потом многократно переписывается.
Такого счастья, чтобы прямо сходу была готовая модель абстракции — практически не бывает.
Ну, вот недавно делал учебный проект — надо было напилить персистентные (иммутабельные) коллекции с приемлемым быстродействием.
И вот я раза три пытался нарулить такую штуку на системе типов дотнета — и в итоге сдался.
По логике вещей, иммутабл коллекция — она всегда ковариантна. То есть ImmutableList<Derived> можно приводить к ImmutableList<Base>.
В частности, при добавлении элемента Base в ImmutableList<Derived> должен получаться ImmutableList<Base>.
Это в предположении, ессно, что Derived унаследован от Base.
Увы, на C# такое ограничение не компилируется:
public class ImmutableList<T>
{
public ImmutableList<B> Add(B item) where T: B => default;
}
Ну, ок. Можно написать метод-расширение:
public static class ImmutableHelper<T>
{
public static ImmutableList<T> Add<D>(this ImmutableList<D> list, T item) where D: T => default;
}
А дальше — засада. Потому, что для производительности этой immutable коллекции надо сделать так, чтобы операция Add повторно использовала те же данные, которые уже лежат в существующем списке.
И если всё делать через интерфейсы (а вариантность в дотнете работает только через них), то производительность падает на дно. Банальная операция list[x] начинает тормозить, как не в себя (а должна быть не хуже o(log(N)), и с нормальным коэффициентом).
Вот я там код переписывал трижды, в попытках таки написать то, что я хочу.
В итоге вернулся к стандартному интерфейсу иммутабельных коллекций дотнета — там нет никакой вариантности, и в список Derived вы никакой Base не добавите. Только наоборот.
И это у меня ещё была более-менее чёткая задача про то, как должен выглядеть интерфейс модуля.
Обычно же и такого нет, и код пишется, стирается, и снова пишется. Архитектура (если она вообще есть) появляется уже потом, когда решение обретает хоть какие-то черты.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, reversecode, Вы писали:
R>бейсик это уровень написание скриптов на bash R>нашли чем гордиться
Где Вы углядели, чтоб я "гордился" бейсиком? Я его и не знал-то никогда толком.
R>какое отношение дедлоки, гонки итд(ваши фантазии) имеют отношение к правильной декомпозиции задач для того что бы не было до черта связей которые вы не можете связать ?
Если не имеют — покажите, как легко и изящно сделать декомпозицию задач, избавившись от любых неочевидных связей, и не породив при этом дедлоков, гонок и подобного. Судя по Вашему апломбу, для Вас это сущее баловство, такой ерундой Вы явно занимались только в детском саду, прежде чем перейти к действительно сложным задачам.
Здравствуйте, vsb, Вы писали:
vsb>Я не знаю API DirectX, но уверен, что всё можно оформить изолированно, с юнит-тестами и потом всё "сцепить" воедино
API — это для пользовательских приложений, там действительно все довольно просто и ортогонально. А я про фильтры DirectShow, которые "на той стороне" от пользовательских приложений. Каждый фильтр обязан экспортировать кучу интерфейсов, за которые его регулярно и в разной последовательности дергают и клиентские приложения, и сама подсистема управления графом. Пока их все не реализуешь, в динамике (на живых потоках) почти ничего не работает.
Есть стандартный фреймворк Base Classes, где сделана более-менее приличная структура классов, для которых нужно реализовать свои методы. Синхронные фильтры, которые всю обработку делают в момент вызова метода, на них делать достаточно удобно, а с асинхронными, которые работают с устройствами, может быть геморрой, поскольку у фреймворка полно своих объектов синхронизации, у фильтра — своих, управление ходит туда-сюда далеко не очевидными путями, и нарваться на дедлок проще простого.
vsb>Добавить промежуточные интерфейсы где-то, например.
Пробовал. Когда их становится слишком много — начинаешь путаться еще больше.
vsb>Например когда архитектура построена в виде акторов, с одной стороны каждого актора можно тестировать, как обычный однопоточный объект, с другой стороны фреймворк, который обеспечивает запуск и взаимодействие акторов уже считается достаточно протестированным и обеспечивает многопоточность без багов (ну почти без багов, дедлок скорей всего всё ещё возможен, но всё же многие баги устраняются).
В такой структуре часто страдает производительность, поскольку для развязки потоков используются последовательные списки, сводятся к минимуму точки контакта, уменьшается количество объектов синхронизации с одновременным расширением их действия, и т.п.
vsb>Впрочем у тебя своя специфика с реалтаймом. То, о чём я пишу, достигается с некоторым оверхедом
Именно. Для большинства применений можно было бы допустить и оверхед, но есть немало случаев, где даже прилично оптимизированный код работает впритирку. Не хотелось бы потерять эти ниши.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>А ты все выворачиваешь вверх ногами, начиная проектирование с деталей реализации
Где Вы у меня такое усмотрели? Наоборот, я пытался начинать с общей структуры. Но, пока не углубишься в детали реализации, далеко не всегда ясно, как будут передаваться управление и сообщения между моим кодом и кодом подсистемы, в которую он встраивается. А когда до этих деталей дошло, нередко оказывается, что данные и методы, изначально внутри, приходится доставать наружу, создавать лишние зависимости между классами, расширять сферу действия блокировок, чтобы уменьшить вероятность дедлока в цепочке, и вся изящно построенная структура становится все уродливее. В итоге каждый раз возникает вопрос, на кой нужны методы безопасного программирования, требующие лишней писанины, если их все равно приходится регулярно нарушать — снова с дополнительной писаниной в виде assert'ов, вспомогательных переменных/методов, комментариев "а этот костыль нам необходим потому, что ..." и т.п.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Важнее чтоя у тебя не усмотрел — требования, юзкейсы и т.п.
Требования — поддержка всех положенных системных интерфейсов и взаимодействий. Юзкейсы — какие они могут быть у драйвера устройства, фильтра DirectShow и подобного софта?
НС>Общая структура это и есть детали реализации, которые, в норме, должны вытекать из сценариев.
Не понимаю. Деталями реализации я называю уже особенности низкого уровня — например, на каком уровне приоритета приходит запрос от портового драйвера, откуда пришло управление в фильтр и какие объекты синхронизации при этом держит контроллер графа, и т.п. От этого сильно зависит то, какие методы каких классов я могу вызывать у себя для обработки всего этого, какие данные трогать и т.д.
НС>Ну вот в этом и есть твоя ошибка.
Здравствуйте, Евгений Музыченко, Вы писали:
НС>>Важнее чтоя у тебя не усмотрел — требования, юзкейсы и т.п. ЕМ>Требования — поддержка всех положенных системных интерфейсов и взаимодействий.
Которые для тебя уже кто то спроектировал? Тогда да, проект тебе особо и не нужен, берешь и пилишь.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Если дать ответы на все эти вопросы, как это поможет лучше выполнить чисто техническую часть?
Очень просто. Чисто техническая часть не будет содержать лишнего и будет содержать все что нужно. Единственная цель проектирования — добиться нужного результата максимально быстро и максимально качественно. Так вот что такое "нужный" и что такое "качественно" как раз и определяется функциональными и нефункциональными требованиями. Если это не зафиксировано — стихийное проектирование снизу вверх приведет к какому то случайному, не совпадающему полностью с нужным результатом.
Тебя спасает только то, что все публичные API за тебя уже спроектировали, и это держит тебя в жестких рамках.
LK>>Если задача не выполняется три года, то, может быть, она не нужна и не важна? А если нужна и важна, то получается, что вместо неё делается что-то менее нужное и важное? ЕМ>Все, что делается, определенно нужно и важно, но для того, чтобы более-менее объективно определить степень нужности/важности каждого аспекта, нужно проводить отдельные бизнес-исследования.
Да ты прям КО.
ЕМ> А речь, напомню, о разработчике-одиночке, а не о компании.
И что? Одиночка ведь для кого то пишет, не так ли?
Здравствуйте, Ночной Смотрящий, Вы писали:
ЕМ>>Требования — поддержка всех положенных системных интерфейсов и взаимодействий.
НС>Которые для тебя уже кто то спроектировал?
Что значит "для меня"? Их спроектировали прежде всего для самой подсистемы.
НС>Тогда да, проект тебе особо и не нужен, берешь и пилишь.
Так я и пилю — получается криво. Как мне сделать красиво, по заветам столпов от программирования?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Единственная цель проектирования — добиться нужного результата максимально быстро и максимально качественно. Так вот что такое "нужный" и что такое "качественно" как раз и определяется функциональными и нефункциональными требованиями. Если это не зафиксировано — стихийное проектирование снизу вверх приведет к какому то случайному, не совпадающему полностью с нужным результатом.
Функциональные требования просты — чтоб работало, не падало, укладывалось в заданные рамки по ресурсам. Все они полностью выполняются, с этим проблем не возникает. Большинству пользователей и заказчиков результат нравится. Но он не нравится мне, поскольку в ряде мест структура кода выглядит уродливо. Теоретики программирования утверждают, что все это можно сделать красиво. Вот мне и интересно — то ли это исключения, не укладывающиеся в их схемы, то ли это у меня мозгов не хватает.
НС>Тебя спасает только то, что все публичные API за тебя уже спроектировали, и это держит тебя в жестких рамках.
Что Вы называете "публичными API"? А жесткие рамки мне только мешают соблюсти красоту и стройность архитектуры кода.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Есть такой более менее консенсус — софт, взаимодействующий с пользователем, должен проектироваться по принципу frontend first.
Сколько раз еще нужно повторить, что в этой теме вообще не идет речи о взаимодействии с пользователем?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Но он не нравится мне, поскольку в ряде мест структура кода выглядит уродливо. Теоретики программирования утверждают, что все это можно сделать красиво.
Это не задача проектирования, это задача рефакторинга.
НС>>Тебя спасает только то, что все публичные API за тебя уже спроектировали, и это держит тебя в жестких рамках. ЕМ>Что Вы называете "публичными API"?
То, через что твой продукт используют. Внешняя поверхность черного ящика.
Здравствуйте, Евгений Музыченко, Вы писали:
НС>>Есть такой более менее консенсус — софт, взаимодействующий с пользователем, должен проектироваться по принципу frontend first. ЕМ>Сколько раз еще нужно повторить, что в этой теме вообще не идет речи о взаимодействии с пользователем?
Ты сам упомянул GUI, я ответил. Какие ко мне претензии?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Это не задача проектирования, это задача рефакторинга.
Рефакторинг — это переделка [полу]готового, а проектирование — построение исходной структуры. И предлагаемые отцами методы рефакторинга тоже не позволяют обойтись без уродливых костылей.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Ну значит проектирование уже сделано до тебя, все просто.
Проектирование любой ОС тоже сделано до разработки любого стороннего софта для нее. Следует ли из этого, что разработка любого стороннего софта не требует проектирования?
ЕМ>>Так я и пилю — получается криво.
НС>Как определил?
Возникают неустранимые зависимости между классами, который на первый взгляд вроде бы не связаны — как по вызываемым методам, так и по внешним условиям. Портится инкапсуляция — классы верхнего уровня вынуждены излишне много знать о поведении классов нижнего уровня.
НС>Пиши код так, чтобы его было легко рефакторить, регулярно устраняй техдолг.
Да не в этом вопрос. Поскольку меня с самого начала преследует ощущение, что далеко не все поняли, о чем речь, вот аналогия со строительством здания.
Если здание строится на большом свободном участке, к которому можно подвести все необходимые коммуникации, сделать фундамент любой мыслимой прочности, спроектировать здание любой разумной высоты, формы и конфигурации, то нет и проблем со вписыванием туда нужной инфраструктуры. Там можно предусмотреть любое разумное количество лестниц, переходов, технологических помещений, кабелей, водо- и воздуховодов, окон, туалетов, лифтов, вентиляторов, насосов, кондиционеров и прочего. Можно задумать все сколь угодно изящно, стройно, эргономично, экологично и т.п. Если при вводе в эксплуатацию вдруг выясняется, что не хватает сечения кабелей или пропускной способности лифтов, это исключительно вина проектировщиков, а не властей или прежних собственников участка.
Если же здание строится в рамках "точечной застройки", вписываясь в существующую архитектуру и инфраструктуру, то на этапе проектирования необходимо учитывать лимиты размеры, форму, нагрузку на грунт, электрическую мощность, расход воды, и воздуха, емкость парковок и все остальное. А если здание необходимо присоединить к уже существующим, обеспечив определенные условия взаимодействия (например, при строительстве нового корпуса в больничном комплексе), то требования еще больше ужесточаются. И тут уже часто бывает не до заветов Витрувия и Леонардо, и смотреть на получившееся далеко не всегда приятно. Какой рефакторинг можно применить в такой ситуации, чтобы построенное выглядело изящно снаружи, и не нарушало общепринятых технических принципов внутри?
Здравствуйте, Евгений Музыченко, Вы писали:
НС>>Ты сам упомянул GUI ЕМ>Там, где я его упомянул, я сразу же подчеркнул, что здесь это не рассматривается.
Почему?
НС>>Какие ко мне претензии? ЕМ>Невнимательность при чтении?
Больше похоже на то, что, задавая вопрос, ты желаешь услышать какой то конкретный ответ, и любые другие ответы игнорируешь.
Здравствуйте, Евгений Музыченко, Вы писали:
НС>>Ну значит проектирование уже сделано до тебя, все просто. ЕМ>Проектирование любой ОС тоже сделано до разработки любого стороннего софта для нее. Следует ли из этого, что разработка любого стороннего софта не требует проектирования?
Сторонний софт обычно взаимодействует не только и не столько с ОС.
ЕМ>>>Так я и пилю — получается криво. НС>>Как определил? ЕМ>Возникают неустранимые зависимости между классами, который на первый взгляд вроде бы не связаны — как по вызываемым методам, так и по внешним условиям. Портится инкапсуляция — классы верхнего уровня вынуждены излишне много знать о поведении классов нижнего уровня.
Ну значит пора рефакторить. Конкретно в плане неустранимых зависимостей есть такая штука как IoC.
А ты что, всерьез считаешь что можно сразу так спроектировать, чтобы подобных проблем гарантированно не было? У меня для тебя плохая новость — это невозможно даже теоретически.
НС>>Пиши код так, чтобы его было легко рефакторить, регулярно устраняй техдолг. ЕМ>Да не в этом вопрос.
Интересный подход. Задаешь вопрос, получаешь ответ, после чего заявляешь что вопрос не в этом. Очередная демонстрация того, что ответ, похоже, тебе и не нужен.
ЕМ>Поскольку меня с самого начала преследует ощущение, что далеко не все поняли, о чем речь, вот аналогия со строительством здания.
Все аналогии ложны. Попытка дедукции при их помощи логически некорректна.
ЕМ>Какой рефакторинг можно применить в такой ситуации, чтобы построенное выглядело изящно снаружи, и не нарушало общепринятых технических принципов внутри?
где вы в этой теме увидели у автора сомнение ?
если же полистать тему полностью
то можно понять то там ситуация намного печальнее
когда у автора чуть больше чем две сущности
его мозг не может построить нейросеть, нейроны не могут связаться со своими ближайшими соседями
в теме минусиками отметились собратья автора с неспособностью строить в голове любые нейросети
что и не удивительно на почтенный их возраст и отсутствию любой адекватной активности в темах про кодинг
Мы не знаем как правильно программировать (Рич Хикки) это относительно переписывания.
Относительно прокрастинации это из-за отсутствия обратной связи с пользователями.
Здравствуйте, vaa, Вы писали:
vaa>Относительно прокрастинации это из-за отсутствия обратной связи с пользователями.
В тех проектах, о которых я преимущественно в этой теме, обратная связь с пользователями не обязательна — там сперва надобно реализовать все нужные интерфейсы, чтобы оно вообще заработало. А прокрастинация возникает еще на этапе реализации, когда становится видно, что красиво сделать не получится, и начинаются мучительные раздумья о том, в каких местах корежить, а в каких — пытаться сохранить стройность.
После обратной связи с пользователями, кстати, прокрастинация тоже бывает. Хорошо, когда пользователи пишут что-то вроде "так, как у вас сделано, не совсем удобно, было бы лучше сделать вот так", и сам понимаешь, что это действительно удобнее. Но многие пишут "у вас неудобно просто потому, что слишком сложно, не хотим ничего изучать, хотим, чтоб софт сам догадывался, чего мы хотим". И тут начинаются тяжкие раздумья о том, что еще можно попробовать угадать софтом.
Здравствуйте, Ночной Смотрящий, Вы писали:
ЕМ>>Рефакторинг — это переделка [полу]готового, а проектирование — построение исходной структуры.
НС>Почему для тебя этот момент так важен?
Потому, что при мало-мальски серьезной переделке тоже нужно иметь план, структуру, схему и т.п. Локальные способы рефакторинга, вроде выноса части кода в отдельную функцию, озвученных проблем не решают, но нередко создают новые.
ЕМ>> И предлагаемые отцами методы рефакторинга тоже не позволяют обойтись без уродливых костылей.
НС>Почему ты так решил?
Потому, что подходящих методов не предлагается, а предлагаемые не решают проблем.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>Ты сам упомянул GUI ЕМ>>Там, где я его упомянул, я сразу же подчеркнул, что здесь это не рассматривается.
НС>Почему?
Потому, что в этой теме речь не о GUI.
НС>Больше похоже на то, что, задавая вопрос, ты желаешь услышать какой то конкретный ответ, и любые другие ответы игнорируешь.
Я желаю услышать отзывы реальных людей о том, насколько успешно им удается применять методы надежно-безопасного программирования, разработанные корифеями. Несколько человек уже отписалось, их опыт и видение проблем во многом совпадают с моими. Абстрактные глубокомысленные рассуждения неинтересны, я их и сам могу.
Здравствуйте, Евгений Музыченко, Вы писали:
bnk>>Я бы тогда вообще не парился по этому поводу, а напротив, радовался — за тебя все уже спроектировали, тебе осталось только реализовать как сказано, добавив свой кусочек.
ЕМ>. Делаешь, как советует дядя Боб, 100500 мелких функций, вызывающих одна другую в разных комбинациях, а потом выясняется, что эти комбинации должны работать на разных приоритетах, где доступны не все ресурсы и не все возможности API.
Можно пояснить, что имеется в виду под приоритетами?
Смысл разбиения на функции — это чтобы они входили на один экран, чтобы легче было понять что функция делает.
Также чтобы их можно было протестировать независимо друг от друга например. Не очень понятно как это связано с API или приоритетами..
Мне представляется, что если поднимать, какая именно проблема решается тем или подходом проектирования, и как,
то его можно превратить из навязываемой глупости в полезный инструмент.
Чем-то похоже на чтение книг типа "Искусство войны".
Если пытаться применять напрямую, считая сколько дней длится осада крепости, вряд ли сильно полезно. Но общие идеи вполне полезны.
Сейчас вот сверился как решился вопрос с Принцессой Несмеяной — ее рассмешило то, как Сом, Мышка и Жук пытались вызволить мужика, упавшего в грязь. Вот сижу, обдумываю
Здравствуйте, Ночной Смотрящий, Вы писали:
ЕМ>>Проектирование любой ОС тоже сделано до разработки любого стороннего софта для нее. Следует ли из этого, что разработка любого стороннего софта не требует проектирования?
НС>Сторонний софт обычно взаимодействует не только и не столько с ОС.
Ну вот тот же драйвер устройства взаимодействует только с ОС и устройством, с пользователем он в общем случае не взаимодействует никак. Это означает, что разработка любого драйвера устройства не требует проектирования совсем?
НС>А ты что, всерьез считаешь что можно сразу так спроектировать, чтобы подобных проблем гарантированно не было?
Мне любопытно, можно ли хотя бы в конце концов этого добиться, без неадекватных накладных расходов во время выполнения.
НС>Все аналогии ложны.
Что именно ложного в аналогии со вписыванием здания в существующую инфраструктуру? Особенно при том, что там наблюдаются ровно те же проблемы, что и в софте?
ЕМ>>Какой рефакторинг можно применить
НС>Весь доступный.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Потому, что при мало-мальски серьезной переделке тоже нужно иметь план, структуру, схему и т.п.
И? В чем проблема?
ЕМ>>> И предлагаемые отцами методы рефакторинга тоже не позволяют обойтись без уродливых костылей. НС>>Почему ты так решил? ЕМ>Потому, что подходящих методов не предлагается,
Ничего не понял. Что значит методов не предлагается? Ты не умеешь делать рефакторинг и тебе нужны пошаговые руководства для каждой твоей проблемы?
Здравствуйте, Евгений Музыченко, Вы писали:
НС>>Почему? ЕМ>Потому, что в этой теме речь не о GUI.
Что за сталинские замашки? Это публичный форум. Тем более что гуй ты сам упомняул.
НС>>Больше похоже на то, что, задавая вопрос, ты желаешь услышать какой то конкретный ответ, и любые другие ответы игнорируешь. ЕМ>Я желаю услышать отзывы реальных людей
А кто реален ты определяешь по тому что он говорит что тебе нравится? Ну ОК.
ЕМ> о том, насколько успешно им удается применять методы надежно-безопасного программирования, разработанные корифеями.
name it
ЕМ> Несколько человек уже отписалось, их опыт и видение проблем во многом совпадают с моими.
Ага, о чем я и говорил. Ты ждешь строго определенный ответ, совпадающий с твоим.
ЕМ>Абстрактные глубокомысленные рассуждения неинтересны, я их и сам могу.
Тебе вполне конкретные вещи говорят. Но они тебе явно не нравятся.
Здравствуйте, Евгений Музыченко, Вы писали:
НС>>Сторонний софт обычно взаимодействует не только и не столько с ОС. ЕМ>Ну вот тот же драйвер устройства взаимодействует только с ОС и устройством, с пользователем он в общем случае не взаимодействует никак.
Ну вот поэтому драйвер особо проектировать и не нужно. По крайней мере на верхнем уровне. А если внутри драйвера выделяются некие крупные подсистемы, которые уже ты придумал — тогда к ним применяем все о чем я говорил, просто публичным API становится взаимодействие между этими подсистемами.
ЕМ> Это означает, что разработка любого драйвера устройства не требует проектирования совсем?
Пока ты сильно не отходишь от реализации API ОС — нет, не требует, по крайней мере на уровне прям отдельного специального этапа.
НС>>А ты что, всерьез считаешь что можно сразу так спроектировать, чтобы подобных проблем гарантированно не было? ЕМ>Мне любопытно, можно ли хотя бы в конце концов этого добиться, без неадекватных накладных расходов во время выполнения.
Можно. При помощи постоянного рефакторинга. Но тебе этот вариант явно не нравится, и я даже могу предположить почему.
НС>>Все аналогии ложны. ЕМ>Что именно ложного
Все аналогии ложны. Цитата из гугля:
Любая аналогия ложна тем, что она отвлекает от предмета часть признаков и приписывает ему дополнительно другие признаки, к самому предмету не относящиеся.
То есть, вводя аналогию, мы меняем предмет обсуждения на другой, имеющий иной набор признаков, отчасти пересекающийся с набором признаков изначального предмета обсуждения.
ЕМ>>>Какой рефакторинг можно применить НС>>Весь доступный. ЕМ>Спасибо, КО.
Здравствуйте, bnk, Вы писали:
bnk>что имеется в виду под приоритетами?
В ядре NT так называются режимы выполнения кода (execution priority). Самый низкий — у пользовательских потоков, самый высокий — у наиболее важных системных. Помимо количественной разницы (кто кого может вытеснять), есть и качественная: при очередном повышении приоритета код может потерять возможность использования части ядерных API и обращения к части ресурсов. Соответственно, стек вызовов функций/методов должен строиться так, чтобы всё, что ниже, работало либо на том же приоритете, либо на более высоком, и использовало только ресурсы, доступные на соответствующих приоритетах.
Например, один из способов захвата блокировки (spin lock) повышает приоритет потока. Если есть код "захват спинлока — выполнение группы операций — освобождение спинлока", то при выносе каких-либо операций этой группы в отдельные функции/методы необходимо следить за тем, чтобы они вызывались только на определенных приоритетах, а это сразу ограничивает возможности повторного использования кода. И с C++ нет возможности навесить на функции и объекты какие-нибудь атрибуты, чтобы следить, кто кого вызывает и использует. Кое-то проверяют статические анализаторы, но далеко не все.
bnk>Смысл разбиения на функции — это чтобы они входили на один экран, чтобы легче было понять что функция делает.
Это понятно. Я б с удовольствием наделал мелких функций, но в описанных выше условиях отслеживать все возможные пути вызовов очень геморройно, хоть у меня все и утыкано assert'ами.
bnk>Также чтобы их можно было протестировать независимо друг от друга например.
У меня не так много функций, зависимых только от параметров. Большая часть работает с членами классов, и они могут вызываться не только из кода, который полностью контролирую я, но и из запросов, приходящих от системы, а запросы эти могут приходить на разных приоритетах, с разной доступностью ресурсов.
bnk>Чем-то похоже на чтение книг типа "Искусство войны".
Подобные книги в основном описывают стратегию, а у меня весь затык на тактике.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Это понятно. Я б с удовольствием наделал мелких функций, но в описанных выше условиях отслеживать все возможные пути вызовов очень геморройно, хоть у меня все и утыкано assert'ами.
Хотел бы пояснить тут немного.
Имеется в виду, что поток выполнения один, то есть выбор стоит между:
function X {
if (yyy) {
aaa
bbb
ccc
}
}
и
function X
{
if (yyy) {
Z
}
}
function Z {
aaa
bbb
ccc
}
Мне кажется, исполнение этого куска не должно зависеть от приоритетов или блокировок, то есть, технически,
это то же самое (но потенциально есть лишний вызов функции во втором случае)?
Второе решение потенциально улучшает читаемость кода за счет ухудшения его производительности.
Впрочем, практики проектирования вроде вообще все такие — улучшают что-то одно за счет ухудшения чего-то другого.
Вроде как довольно тривиальная вещь, для понимания ценности или использования которой не нужно быть семи пядей во лбу
Так почему бы не использовать подобные приемы в своем коде. То есть, не очень понятно в чем тут упомянутая разница "стратегией" и "тактикой". В данном примере — "разделяй и властвуй"
Речь же просто о наборе практик для создания продукта, который можно будет поддерживать и развивать с меньшими усилиями. Или?
bnk>>Также чтобы их можно было протестировать независимо друг от друга например.
ЕМ>У меня не так много функций, зависимых только от параметров. Большая часть работает с членами классов, и они могут вызываться не только из кода, который полностью контролирую я, но и из запросов, приходящих от системы, а запросы эти могут приходить на разных приоритетах, с разной доступностью ресурсов.
Можно и не тестировать (не писать юнит-тесты), это нормально (с) Малышева.jpg
Зависит от ситуации. Иногда просто хочется писать так, чтобы быть уверенным что на определенных параметрах вызова точно получится определенный результат, а вручную проверить сложно.
К системным вызовам скорее всего неприменимо. Но кроме системных вызовов бывает есть же куча служебных функций (начиная от преобразования строк например) которые являются самодостаточными.
Чем большую часть системы можно так проверить, тем выше уверенность что ничего не сломается при внесении изменений.
bnk>>Чем-то похоже на чтение книг типа "Искусство войны".
ЕМ>Подобные книги в основном описывают стратегию, а у меня весь затык на тактике
У меня наступило просветление когда поработал в достаточно большой компании с кучей говнокода.
Рекомендую, вариант постижения дзена вполне рабочий. Вдруг скучно станет зимой.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ> А выносить код в отдельную функцию, чтобы обвешивать ее грозными комментариями "вызывать только из ..." и проверками, не вызвана ли она в неподходящем контексте — это и есть те самые уродливые костыли.
Cправедливости ради, для этого есть область видимости. Ну public/private в смысле
Здравствуйте, bnk, Вы писали:
bnk>для этого есть область видимости. Ну public/private в смысле
Это само собой. Я про то, что в святцах рекомендуется стремиться к независимости любой функции, а наличие особых условий, в которых она может быть вызвана, объявлено моветоном.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Кто делает софт в одиночку (хотя бы в объеме отдельных модулей/библиотек) — поделитесь, как у вас организована работа?
Для серьезных/объемных вещей/изменений:
— Кража заимствование чужих идей
— Прислушиваюсь к голосу пятой точки
— Предварительные прототипы
— Тесты
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, reversecode, Вы писали:
R>это потому что программировать вы учились как самоучка R>а не в высшем учебном заведении по правильной литературе R>и ни дизайн патеррны, ни другие умные книги по правильной декомпозиции не читали
R>поэтому у вас краш как только много сущностей которые вы не знаете как связать
Как человек, учившийся программировать самостоятельно. А потом, и окончивший соответствующие учебные заведения, могу сообщить: не надо слишком преклоняться перед этим вот образованием.
В конечном итоге, в том же ВУЗе, всё сводится к вам — будете ли вы сами заниматься, читать, практиковаться, учиться.
А лекции будут вам читать во многом по тем же книжкам, что вы и сами можете купить и прочитать как самоучка. Поверьте, там не такие уж светочи сидят, обладающие каким-то исключительным знанием и опытом.
Ну да, что-то такое бывает интересненькое, что в книжках не получится поискать. Но это пойди поищи такой ВУЗ. Я вот мехматовский курс МГУ по программированию видел — там да, интересное, и необычные знания.
А в стандартных ВУЗах, там ничего особенного.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Когда такая возможность есть — это просто отлично. Например, типичная интерактивная программа с менюшками и кучей функций, где можно сперва реализовать "Open File", потом "Close File", потом "Copy", "Paste" и т.п.
Вот это вот, довольно низкий полёт. Тут на сайте уже говорили, что нынче автопилот уровня Бурана, это тема диплома ВУЗа нынче.
Вот это я понимаю, да — круто. И если в ВУЗе этому учат — это крутой вуз и крутое обучение.
Только вот сколько в этом автопилоте от программирования, и сколько от математики?
Ты диплом по какой сфере защищаешь — по математике или программированию?
ЕМ>Чтобы обнаружить это на этапе проектирования, нужно фактически провести почти тот же объем работы, выписав хотя бы все форматы данных, внешние интерфейсы, функции API, наборы параметров и прочее, и уже потом писать со всего этого код. Проще и быстрее сразу начинать писать код.
Ну так можно сразу разбить на какие-то логические блоки, выторчить из каждого интерфейсы. Все внешние зависимости/API засунуть в свои модули. Вот уже будет хороший задел на будущее: в последствии можно менять какой-то модуль/блок по месту локально, не переписывая всю систему.
Ну и ко всему прочему: все-равно постоянно идет какой-то рефакторинг и переписывание каких-то частей системы. Вопрос в том, насколько локализованные части системы это будут и сколько зависимых частей будут затронуты.
