Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Важнее чтоя у тебя не усмотрел — требования, юзкейсы и т.п.
Требования — поддержка всех положенных системных интерфейсов и взаимодействий. Юзкейсы — какие они могут быть у драйвера устройства, фильтра DirectShow и подобного софта?
НС>Общая структура это и есть детали реализации, которые, в норме, должны вытекать из сценариев.
Не понимаю. Деталями реализации я называю уже особенности низкого уровня — например, на каком уровне приоритета приходит запрос от портового драйвера, откуда пришло управление в фильтр и какие объекты синхронизации при этом держит контроллер графа, и т.п. От этого сильно зависит то, какие методы каких классов я могу вызывать у себя для обработки всего этого, какие данные трогать и т.д.
НС>Ну вот в этом и есть твоя ошибка.
Здравствуйте, Евгений Музыченко, Вы писали:
НС>>Важнее чтоя у тебя не усмотрел — требования, юзкейсы и т.п. ЕМ>Требования — поддержка всех положенных системных интерфейсов и взаимодействий.
Которые для тебя уже кто то спроектировал? Тогда да, проект тебе особо и не нужен, берешь и пилишь.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Если дать ответы на все эти вопросы, как это поможет лучше выполнить чисто техническую часть?
Очень просто. Чисто техническая часть не будет содержать лишнего и будет содержать все что нужно. Единственная цель проектирования — добиться нужного результата максимально быстро и максимально качественно. Так вот что такое "нужный" и что такое "качественно" как раз и определяется функциональными и нефункциональными требованиями. Если это не зафиксировано — стихийное проектирование снизу вверх приведет к какому то случайному, не совпадающему полностью с нужным результатом.
Тебя спасает только то, что все публичные API за тебя уже спроектировали, и это держит тебя в жестких рамках.
LK>>Если задача не выполняется три года, то, может быть, она не нужна и не важна? А если нужна и важна, то получается, что вместо неё делается что-то менее нужное и важное? ЕМ>Все, что делается, определенно нужно и важно, но для того, чтобы более-менее объективно определить степень нужности/важности каждого аспекта, нужно проводить отдельные бизнес-исследования.
Да ты прям КО.
ЕМ> А речь, напомню, о разработчике-одиночке, а не о компании.
И что? Одиночка ведь для кого то пишет, не так ли?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Проблемы с видением результата у меня возникают в основном в плане GUI — какой внешний вид придать окнам программы, в каком виде удобнее отображать данные и элементы управления, как организовать структуру меню и т.п. Здесь я этих вопросов не поднимал — речь исключительно о внутренней структуре
Есть такой более менее консенсус — софт, взаимодействующий с пользователем, должен проектироваться по принципу frontend first. Т.е. сперва ты проектируешь UX (т.е. внешний вид GUI и его поведение), и только потом реализуешь к нему бек. Если поступить наоборот — скорее всего на выходе получится неудобное пользователям чудище.
Здравствуйте, Ночной Смотрящий, Вы писали:
ЕМ>>Требования — поддержка всех положенных системных интерфейсов и взаимодействий.
НС>Которые для тебя уже кто то спроектировал?
Что значит "для меня"? Их спроектировали прежде всего для самой подсистемы.
НС>Тогда да, проект тебе особо и не нужен, берешь и пилишь.
Так я и пилю — получается криво. Как мне сделать красиво, по заветам столпов от программирования?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Единственная цель проектирования — добиться нужного результата максимально быстро и максимально качественно. Так вот что такое "нужный" и что такое "качественно" как раз и определяется функциональными и нефункциональными требованиями. Если это не зафиксировано — стихийное проектирование снизу вверх приведет к какому то случайному, не совпадающему полностью с нужным результатом.
Функциональные требования просты — чтоб работало, не падало, укладывалось в заданные рамки по ресурсам. Все они полностью выполняются, с этим проблем не возникает. Большинству пользователей и заказчиков результат нравится. Но он не нравится мне, поскольку в ряде мест структура кода выглядит уродливо. Теоретики программирования утверждают, что все это можно сделать красиво. Вот мне и интересно — то ли это исключения, не укладывающиеся в их схемы, то ли это у меня мозгов не хватает.
НС>Тебя спасает только то, что все публичные API за тебя уже спроектировали, и это держит тебя в жестких рамках.
Что Вы называете "публичными API"? А жесткие рамки мне только мешают соблюсти красоту и стройность архитектуры кода.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Есть такой более менее консенсус — софт, взаимодействующий с пользователем, должен проектироваться по принципу frontend first.
Сколько раз еще нужно повторить, что в этой теме вообще не идет речи о взаимодействии с пользователем?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Но он не нравится мне, поскольку в ряде мест структура кода выглядит уродливо. Теоретики программирования утверждают, что все это можно сделать красиво.
Это не задача проектирования, это задача рефакторинга.
НС>>Тебя спасает только то, что все публичные API за тебя уже спроектировали, и это держит тебя в жестких рамках. ЕМ>Что Вы называете "публичными API"?
То, через что твой продукт используют. Внешняя поверхность черного ящика.
Здравствуйте, Евгений Музыченко, Вы писали:
НС>>Есть такой более менее консенсус — софт, взаимодействующий с пользователем, должен проектироваться по принципу frontend first. ЕМ>Сколько раз еще нужно повторить, что в этой теме вообще не идет речи о взаимодействии с пользователем?
Ты сам упомянул GUI, я ответил. Какие ко мне претензии?
Здравствуйте, Евгений Музыченко, Вы писали:
НС>>Которые для тебя уже кто то спроектировал? ЕМ>Что значит "для меня"? Их спроектировали прежде всего для самой подсистемы.
Ну значит проектирование уже сделано до тебя, все просто.
НС>>Тогда да, проект тебе особо и не нужен, берешь и пилишь. ЕМ>Так я и пилю — получается криво.
Как определил?
ЕМ> Как мне сделать красиво, по заветам столпов от программирования?
Включать моск, как еще? Пиши код так, чтобы его было легко рефакторить, регулярно устраняй техдолг. There is no silver bullet.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Это не задача проектирования, это задача рефакторинга.
Рефакторинг — это переделка [полу]готового, а проектирование — построение исходной структуры. И предлагаемые отцами методы рефакторинга тоже не позволяют обойтись без уродливых костылей.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Ну значит проектирование уже сделано до тебя, все просто.
Проектирование любой ОС тоже сделано до разработки любого стороннего софта для нее. Следует ли из этого, что разработка любого стороннего софта не требует проектирования?
ЕМ>>Так я и пилю — получается криво.
НС>Как определил?
Возникают неустранимые зависимости между классами, который на первый взгляд вроде бы не связаны — как по вызываемым методам, так и по внешним условиям. Портится инкапсуляция — классы верхнего уровня вынуждены излишне много знать о поведении классов нижнего уровня.
НС>Пиши код так, чтобы его было легко рефакторить, регулярно устраняй техдолг.
Да не в этом вопрос. Поскольку меня с самого начала преследует ощущение, что далеко не все поняли, о чем речь, вот аналогия со строительством здания.
Если здание строится на большом свободном участке, к которому можно подвести все необходимые коммуникации, сделать фундамент любой мыслимой прочности, спроектировать здание любой разумной высоты, формы и конфигурации, то нет и проблем со вписыванием туда нужной инфраструктуры. Там можно предусмотреть любое разумное количество лестниц, переходов, технологических помещений, кабелей, водо- и воздуховодов, окон, туалетов, лифтов, вентиляторов, насосов, кондиционеров и прочего. Можно задумать все сколь угодно изящно, стройно, эргономично, экологично и т.п. Если при вводе в эксплуатацию вдруг выясняется, что не хватает сечения кабелей или пропускной способности лифтов, это исключительно вина проектировщиков, а не властей или прежних собственников участка.
Если же здание строится в рамках "точечной застройки", вписываясь в существующую архитектуру и инфраструктуру, то на этапе проектирования необходимо учитывать лимиты размеры, форму, нагрузку на грунт, электрическую мощность, расход воды, и воздуха, емкость парковок и все остальное. А если здание необходимо присоединить к уже существующим, обеспечив определенные условия взаимодействия (например, при строительстве нового корпуса в больничном комплексе), то требования еще больше ужесточаются. И тут уже часто бывает не до заветов Витрувия и Леонардо, и смотреть на получившееся далеко не всегда приятно. Какой рефакторинг можно применить в такой ситуации, чтобы построенное выглядело изящно снаружи, и не нарушало общепринятых технических принципов внутри?
Здравствуйте, Евгений Музыченко, Вы писали:
НС>>Ты сам упомянул GUI ЕМ>Там, где я его упомянул, я сразу же подчеркнул, что здесь это не рассматривается.
Почему?
НС>>Какие ко мне претензии? ЕМ>Невнимательность при чтении?
Больше похоже на то, что, задавая вопрос, ты желаешь услышать какой то конкретный ответ, и любые другие ответы игнорируешь.
Здравствуйте, Евгений Музыченко, Вы писали:
НС>>Ну значит проектирование уже сделано до тебя, все просто. ЕМ>Проектирование любой ОС тоже сделано до разработки любого стороннего софта для нее. Следует ли из этого, что разработка любого стороннего софта не требует проектирования?
Сторонний софт обычно взаимодействует не только и не столько с ОС.
ЕМ>>>Так я и пилю — получается криво. НС>>Как определил? ЕМ>Возникают неустранимые зависимости между классами, который на первый взгляд вроде бы не связаны — как по вызываемым методам, так и по внешним условиям. Портится инкапсуляция — классы верхнего уровня вынуждены излишне много знать о поведении классов нижнего уровня.
Ну значит пора рефакторить. Конкретно в плане неустранимых зависимостей есть такая штука как IoC.
А ты что, всерьез считаешь что можно сразу так спроектировать, чтобы подобных проблем гарантированно не было? У меня для тебя плохая новость — это невозможно даже теоретически.
НС>>Пиши код так, чтобы его было легко рефакторить, регулярно устраняй техдолг. ЕМ>Да не в этом вопрос.
Интересный подход. Задаешь вопрос, получаешь ответ, после чего заявляешь что вопрос не в этом. Очередная демонстрация того, что ответ, похоже, тебе и не нужен.
ЕМ>Поскольку меня с самого начала преследует ощущение, что далеко не все поняли, о чем речь, вот аналогия со строительством здания.
Все аналогии ложны. Попытка дедукции при их помощи логически некорректна.
ЕМ>Какой рефакторинг можно применить в такой ситуации, чтобы построенное выглядело изящно снаружи, и не нарушало общепринятых технических принципов внутри?
где вы в этой теме увидели у автора сомнение ?
если же полистать тему полностью
то можно понять то там ситуация намного печальнее
когда у автора чуть больше чем две сущности
его мозг не может построить нейросеть, нейроны не могут связаться со своими ближайшими соседями
в теме минусиками отметились собратья автора с неспособностью строить в голове любые нейросети
что и не удивительно на почтенный их возраст и отсутствию любой адекватной активности в темах про кодинг
Мы не знаем как правильно программировать (Рич Хикки) это относительно переписывания.
Относительно прокрастинации это из-за отсутствия обратной связи с пользователями.
