Здравствуйте, 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>>Чем-то похоже на чтение книг типа "Искусство войны".
ЕМ>Подобные книги в основном описывают стратегию, а у меня весь затык на тактике
У меня наступило просветление когда поработал в достаточно большой компании с кучей говнокода.
Рекомендую, вариант постижения дзена вполне рабочий. Вдруг скучно станет зимой.
Здравствуйте, bnk, Вы писали:
bnk>Имеется в виду, что поток выполнения один
Потоков в общем случае несколько, но есть "нормальные", где можно творить почти все, что хочется, и ограниченные теми самыми условиями на входе.
bnk>то есть выбор стоит между:
В плане выноса кода — примерно так.
bnk>Мне кажется, исполнение этого куска не должно зависеть от приоритетов или блокировок, то есть, технически, bnk>это то же самое (но потенциально есть лишний вызов функции во втором случае)?
Понятно, что сам по себе вынос кода ничего не меняет. Но вынесенный код периодически оказывается кандидатом на вызов из других функций/потоков, которые уже могут выполняться в неподходящих условиях (и это порой вовсе не следует из структуры кода, а выясняется лишь экспериментально, когда все уже переделано и давно работает, но в очередном обновлении винды меняют какую-нибудь внутреннюю логику блокировок, и привет). А выносить код в отдельную функцию, чтобы обвешивать ее грозными комментариями "вызывать только из ..." и проверками, не вызвана ли она в неподходящем контексте — это и есть те самые уродливые костыли.
bnk>Можно и не тестировать (не писать юнит-тесты), это нормально (с) Малышева.jpg
Я их вообще не пишу, ибо геморроя больше, чем эффекта. Только финальные, общие тесты.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ> А выносить код в отдельную функцию, чтобы обвешивать ее грозными комментариями "вызывать только из ..." и проверками, не вызвана ли она в неподходящем контексте — это и есть те самые уродливые костыли.
Cправедливости ради, для этого есть область видимости. Ну public/private в смысле
Здравствуйте, bnk, Вы писали:
bnk>для этого есть область видимости. Ну public/private в смысле
Это само собой. Я про то, что в святцах рекомендуется стремиться к независимости любой функции, а наличие особых условий, в которых она может быть вызвана, объявлено моветоном.
Здравствуйте, Евгений Музыченко, Вы писали:
bnk>>для этого есть область видимости. Ну public/private в смысле
ЕМ>Это само собой. Я про то, что в святцах рекомендуется стремиться к независимости любой функции, а наличие особых условий, в которых она может быть вызвана, объявлено моветоном.
Если смотреть не на мантру, а для чего она была придумана, то это обретает смысл — независимую функцию легче протестировать.
В общем надо сначала согласиться с какой-то базовой системой аксиом, типа "чем раньше находится ошибка — тем дешевле ее починить".
Не думаю что с этим кто-то будет спорить, или?
Как найти ошибку раньше?
Пусть например компилятор их находит, чем больше ошибок найдет компилятор, тем лучше.
Отсюда растет идея юнит-тестов и тестирования программы прямо во время компиляции по сути.
Чтобы юнит-тесты было легко писать, тестируемым функциям лучше быть независимыми.
В общем должна быть какая-то высшая цель в том, чтобы делать функции независимыми.
Если бы полностью независимые функции были на самом деле сильно удобнее, вложенные функции или лямбды например не стали бы так популярны.
Что будет перевешивать — тяжесть последствий от пропущенной ошибки, или же геморрой связанный с поддержкой юнит-тестирования, зависит от конкретного проекта, кмк.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Кто делает софт в одиночку (хотя бы в объеме отдельных модулей/библиотек) — поделитесь, как у вас организована работа?
Для серьезных/объемных вещей/изменений:
— Кража заимствование чужих идей
— Прислушиваюсь к голосу пятой точки
— Предварительные прототипы
— Тесты
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Кто делает софт в одиночку (хотя бы в объеме отдельных модулей/библиотек) — поделитесь, как у вас организована работа? Сперва тщательно проектируете структуру, интерфейсы, взаимодействие, и потом это чаще всего остается неизменным (хотя бы в целом), или же сразу начинаете делать наиболее явные куски, постепенно заполняя пробелы и подстраивая общую структуру к тому, что получилось? Удается ли выстроить стройную логику взаимодействия в многослойных абстракциях, параллельных потоках и подобном, или везде приходится лепить костыли для неочевидных частных случаев? Насколько сложно заставить себя перестать обдумывать, как сделать лучше, и начать делать хоть как-нибудь?
У меня работа организована по шагам.
Причём, есть шаги разной степени по-уровням.
Шаги, где делаются самые мелкие задачи, проде написания той или иной функции.
Есть шаги куда глобальнее — скажем, сделать определённую фичу. Вот исходя из соображений этого шага, я решаю, какие у меня будут более мелкие шаги.
Нет иерархии действий. Т.е. делай раз, делай два, и так, до N. На выходе получается готовая программа.
Нет, я действую итеративно. Сейчас делаем этот шаг, смотрим получается, по результатам добавляем те или иные шаги, что мы будем делать после этого.
Я не пишу сразу весь код, а потом отлаживаю. Я пишу по более-менее законченным кусочкам, и потом отлаживаю этот вот получившийся кусочек. Чтобы у меня достаточно постоянно была определённая точно работающая кодовая база.
Если ты напишешь сразу весь код, по моему опыту знаю, ты утонешь в отладке, просто безвылазно. Тебе так или иначе, всё равно придётся отлаживать по-кускам.
Сразу накатать с первого захода огромное полотно кода, где всё будет прекрасно — это попросту нереально.
Оттого и подход по шагам. Накатали кусочек, посмотрели, как получилось, как стыкуется с остальным телом программы, не надо ли что-то изменить.
Если надо — организуешь шаг "интеграция и рефакторинг".
В пределах написания отдельного куска, скажем, какой-то фичи, я начинаю с общего планирования. На этом шаге, я прикидываю, как примерно будет всё устроено.
И продумываю самые ключевые вопросы, ответы на которые определяют дальнейший облик кода. Т.е. некий фундамент, на котором этот код будет зиждеться. Например, факты из API ОС.
Позволяет ли ОС сделать те или иные вещи? Если не позволяет, то мои планы неосуществимы, и надо искать иные пути.
Ещё, при общем планировании, решается схема работы кода. Т.е. примерно какие будут операции, какие форматы данных, как это всё будет устроено и работать.
Ну а дальше, я приступаю к реализации всех деталей. Для этого, организую соответствующие шаги.
Сделать код, делающий вещь №1. Сделать код, делающий вещь №2. И т.п. Разумеется, все эти шаги включают в себя как написание кода, так и его отладку.
Помимо написания кода, разумеется, я продумываю не только код. Например, тот же формат данных. На соответсвующих шагах, я решаю в подробностях, как будет он устроен. Возможно, потом, на других шагах я его прорефакторю.
Но сейчас будет первая версия.
Есть и другие шаги — интеграция всего кода фичи в единое целое, рефакторинг, интеграция кода фичи в тело программы.
Может быть шаг — написание документации.
В общем, разное бывает.
Бывает и то, что в процессе работы над деталями, выясняется, что возникла некая непреодолимая проблема. И надо временно бросить работу над фичей, и идти её устранять. А это уже совсем другие шаги, и другой уровень "глобальности шага" — устранение этой проблемы.
Т.е. вместо шага "написание фичи", рядом появляется шаг "устранение серьёзной проблемы", у него свои более мелкие подшаги, и я занимаюсь уже ими.
А написание фичи откладывается, ибо её написать нереально сейчас.
Написав фичу, я возвращаюсь к глобальным шагам, смотрю что буду делать дальше, теперь, когда кое-что имею новое. Возможно, я отмечу себе, что надо будет что-то там прорефакторить.
Но не обязательно прям сейчас, а позже. А сейчас, я буду делать ещё одну фичу.
Потом, когда будет накоплен массив фич, можно будет уже гонять то что получилось, как крупную программу.
Можно даже больше — показывать всё это другим людям, собирать feedback. Ну а дальше, планируем новые шаги по результатам.
Т.е. да, какой-то сплав нисходящей и восходящей разработки. И agile разработки. Т.к. долго жить без feedback неразумно.
Вот как организовать коллективную работу над программой — куда интереснее. Ибо когда разные люди одновременно делают разные фичи, а потом объединяют результаты — такое веселье может начаться... Такой рефакторинг...
Когда выясняется, что куча людей повторно делала одну и ту же работу, и образовались дублирующиеся вещи. Или что-то ещё нестыкуется.
А если уж над всем этим дедлайн висит и ограничение по бюджету — так вообще. Веселье по полной программе.
Здравствуйте, reversecode, Вы писали:
R>это потому что программировать вы учились как самоучка R>а не в высшем учебном заведении по правильной литературе R>и ни дизайн патеррны, ни другие умные книги по правильной декомпозиции не читали
R>поэтому у вас краш как только много сущностей которые вы не знаете как связать
Как человек, учившийся программировать самостоятельно. А потом, и окончивший соответствующие учебные заведения, могу сообщить: не надо слишком преклоняться перед этим вот образованием.
В конечном итоге, в том же ВУЗе, всё сводится к вам — будете ли вы сами заниматься, читать, практиковаться, учиться.
А лекции будут вам читать во многом по тем же книжкам, что вы и сами можете купить и прочитать как самоучка. Поверьте, там не такие уж светочи сидят, обладающие каким-то исключительным знанием и опытом.
Ну да, что-то такое бывает интересненькое, что в книжках не получится поискать. Но это пойди поищи такой ВУЗ. Я вот мехматовский курс МГУ по программированию видел — там да, интересное, и необычные знания.
А в стандартных ВУЗах, там ничего особенного.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Когда такая возможность есть — это просто отлично. Например, типичная интерактивная программа с менюшками и кучей функций, где можно сперва реализовать "Open File", потом "Close File", потом "Copy", "Paste" и т.п.
Вот это вот, довольно низкий полёт. Тут на сайте уже говорили, что нынче автопилот уровня Бурана, это тема диплома ВУЗа нынче.
Вот это я понимаю, да — круто. И если в ВУЗе этому учат — это крутой вуз и крутое обучение.
Только вот сколько в этом автопилоте от программирования, и сколько от математики?
Ты диплом по какой сфере защищаешь — по математике или программированию?
А прокрастинация возникает еще на этапе реализации, когда становится видно, что красиво сделать не получится, и начинаются мучительные раздумья о том, в каких местах корежить, а в каких — пытаться сохранить стройность.
