А смысл "семь раз отмерь — один отрежь" — перед тем как писать, нужно подумать. Я говорю не об конструировании иерархии (ибо сам не умею зараннее классы продумывать), а о понимании самой задачи. Непонимание задачи делает бессмысленым любые архитектурные изыски. Если есть сомнения, то сделай прототип(ы). Решение обычно оформляется, когда ты наберёшь некоторую критическую массу знаний, как по самой задаче, так и по технологиям, которые можно применить.
. Когда говорят, если бы было время я бы сделал красиво, а так как его не было, сделал уродливо — не верь. Красивое решение делается за минимальное время и минимальным количеством усилий. Именно по этому оно и красиво. На микроуровне можно пользоваться формальными правилами типа LSP или закона Деметра (есть, кстати, подобные правила для ФЯ?), но макроуровне тебе поможет только твоё чувство прекрасного.
3. Лучшее враг хорошего. Если тебе кажется, что ты придумал ерунду, но незнаешь как сделать лучше, не бойся воплощать решение в жизнь, так как кривое решение лучше чем никакого. Со временем у тебя появятся нужные знания (если ты к ним стремишся, естественно), и ты недопустишь подобных просчетов.
4. Практика — критерий истины. Если думаеш, что ты сделал "красоту", а оно не работает, то меняй своё чувство прекрасного. То биш нужна обратная связь между твоим решением и твоей же думалкой.
5. Одна голова хорошо, а две лучше. Даже если ты архитектор. не стейсняйся спрашивать у простых программистов их мнение. Общайся, сверяй чувство прекрасного у других со своим.
Получается, что все, что нужно это твоя голова. Если её нет, то никакая тулза не поможет Для усовершенствования работы головы есть разные методики, типа ТРИЗа. Другое дело, я не знаю, насколько они помогают Ну, и практика-обратная связь, практика-обратная связь, практика-обратная связь.
Я еще пользуюсь универсальными философскими правилами:
1. Разделяй и властвуй. Следствие из особенности человеческого мозга "7+-2". Поскольку всю архитект`уру в целом тяжело удержать в голове, то задачу бьют на части. Тут нужно читать о функциональной/объектной декомпозиции. Кстати, вывод: чем меньше ответсвенности на классе (или другой единице декомпозиции), и с чем меньшим числом других классов идёт взаимодействие, тем его проще и придумать и реализовать.
2. Стой на плечах у гигантов. Применяй, то что придумали до тебя другие. Есть там правила, типа "Первое правило создания распределённых приложений — не распределяй". Ну, и прочая мудрость, которая поможет тебе не ходить по всеизвестным граблям. Мне, например, нравится ОО: тотальный messaging, рекурсивный дизайн. Постепенно всё идёт, как минимум к тотальному messaging, кроме того есть правила, которые удовлетворяют моему чувству прекрасного. Так что я вижу смысл пользоваться этим прямо сейчас, но я не навязываю
Здравствуйте, FDSC, Вы писали:
FDS>P.S. Опять же, если в фирме начальство строго относится к пиратскому ПО, то просто так не попроектируешь...
Что нормально проектировать можно только в тулах за многие килобаксы?
Нормально проектировать можно и на листочке бумаги.
Если нету светлых мыслей, то никакой тул не поможет.
Уже сколько раз наблюдал, как народ свято верил,
что с появлением крутого тула (вполне хорошего, кстати)
все проблемы со спецификациями, дизайном и пр... уйдут автоматически.
А вот не уходят...
Фигня, поданная на вход самому замечательному тулу, не перестает быть фигней...
Здравствуйте, prVovik, Вы писали:
V>Здравствуйте, FDSC, Вы писали:
FDS>>А чем мерять? В смысле, какие средства при проектировании использовать?
FDS>>P.S. Опять же, если в фирме начальство строго относится к пиратскому ПО, то просто так не попроектируешь...
V>Проектировать — это не значит рисовать что-нибудь в какой-нибудь навороченной рисовалке схем. Можно сказать, что спроектировать — это написть ту же самую программу, но с очень низкой степенью детализации. А уж "программировать" с низкой степенью детализации можно разными способами (ИМХО — в порядке убывания полезности): V>1) Используя привычный язык программирования для описания основных интерфейсов, классов, и, возможно, программного кода, который в очень крупном масштабе записывает самые важные и крупные действия, которые должны происходить в программе.
Угу, только вот почему-то потом эти действия всегда оказываются не такими Да и если записывать такие действия в коде, не видно, кто к кому обращается, очень велик риск потерять информационные связи.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>А смысл "семь раз отмерь — один отрежь" — перед тем как писать, нужно подумать. Я говорю не об конструировании иерархии (ибо сам не умею зараннее классы продумывать), а о понимании самой задачи. Непонимание задачи делает бессмысленым любые архитектурные изыски. Если есть сомнения, то сделай прототип(ы). Решение обычно оформляется, когда ты наберёшь некоторую критическую массу знаний, как по самой задаче, так и по технологиям, которые можно применить.
Не поверишь. Буквально в конце августа я писал одну прогу на C#, смысл которой был в предоставлении интерфейса подключаемым библиотекам и управлении данными этих библиотек (т.е. сохранение доп. информации этих библиотек в том же файле, что и осн. информация).
Ну вроде всё описал. На бумаге (*.txt) столько исписал всего, что даже смотреть страшно. Всё равно, когда я начал кодировать загрузку межбиблиотечных данных (самое последнее, что надо было сделать), оказалось, что я: 1. Не сохранил нужную информацию о обработчике информации 2. Вообще вся необходимая информация находится в другом модуле, является приватной и ещё не загружена 3. При десериализации порядок вызова методов обработчиков информации неправильный и приводит к ошибкам. И вот тут мне было очень плохо
А ведь расписал всё так, казалось, что неожиданностей быть не должно. А вот нет, упустил.
ANS>3. Лучшее враг хорошего. Если тебе кажется, что ты придумал ерунду, но незнаешь как сделать лучше, не бойся воплощать решение в жизнь, так как кривое решение лучше чем никакого. Со временем у тебя появятся нужные знания (если ты к ним стремишся, естественно), и ты недопустишь подобных просчетов.
Только после таких просчётов руки опускаются Особенно, когда пять штук подряд. Тут уже можно и вообще ничего не сделать.
ANS>Получается, что все, что нужно это твоя голова. Если её нет, то никакая тулза не поможет Для усовершенствования работы головы есть разные методики, типа ТРИЗа. Другое дело, я не знаю, насколько они помогают Ну, и практика-обратная связь, практика-обратная связь, практика-обратная связь.
К сожалению, всё это мало помогает. Вопрос ведь не в том, что бы знать эти правила, а в том, чтобы получалось их соблюдать при проектировании. Потому что страешься их соблюдать, а потом оказывается, что не соблюл
Здравствуйте, bkat, Вы писали:
B>Что нормально проектировать можно только в тулах за многие килобаксы? B>Нормально проектировать можно и на листочке бумаги. B>Если нету светлых мыслей, то никакой тул не поможет.
Здравствуйте, FDSC, Вы писали:
FDS>Здравствуйте, bkat, Вы писали:
B>>Что нормально проектировать можно только в тулах за многие килобаксы? B>>Нормально проектировать можно и на листочке бумаги. B>>Если нету светлых мыслей, то никакой тул не поможет.
FDS>Может расскажите, как "нормально проектировать"?
Хм...
Думаешь это влезет в 10 строк сообщения на форуме?
Ты точно так же можешь попросить рассказать о том, как писать хорошие программы.
Советы их книжек ты и сам наверняка знаешь...
А все остальное — это опыт, который ты сам должен получить.
Не думаю, что можно научтися успешно проектировать прочитав какую-нибудь "нужную" книгу либо другой материал по соответствующей тематике.
Литература всего лишь описывает возможные рецепты и модели проектирования, которые были сформулированы и использованы в возможно успешных проектах.
Основной целью подобной литературы являются:
1. Показать как можно это сделать.
2. Указать существующие модели и паттерны.
3. Заставить мозг думать.
Уверен, однако, что как бы внимательно вы не изучали подобную литературу, некоторые моменты вы обязательно упустите или не обратите внимания.
Научиться "нормально проектировать" возможно только путем собственных проб и ошибок, чем больше бы будете пробовать, тем опытнее вы будете.
Здравствуйте, FDSC, Вы писали:
FDS> 1. Не сохранил нужную информацию о обработчике информации
К архитектуре это не имеет отношения.
FDS> 2. Вообще вся необходимая информация находится в другом модуле, является приватной и ещё не загружена
Вот-вот. Этого ты не знал. А мог бы написать тест, который выводил список доступной тебе информации в модуле. Но, опять же, какое влияние на архитектуру.
FDS>3. При десериализации порядок вызова методов обработчиков информации неправильный и приводит к ошибкам. И вот тут мне было очень плохо
Пиши тесты
FDS> К сожалению, всё это мало помогает. Вопрос ведь не в том, что бы знать эти правила, а в том, чтобы получалось их соблюдать при проектировании. Потому что страешься их соблюдать, а потом оказывается, что не соблюл
Работай над собой
Кстати, есть методики позволяющие "менять" себя. Типа всяких "ауто-", НЛП. Так вот, у них у всех есть одна общая черта, перед тем как работать над собой нужно обдумать, что ты хочеш получить (обычно записать на бумаге на бумаге), поработать над собой, записать что получилось. Новый цикл. Только это не проблемы архитектуры.
Здравствуйте, Mirrorer, Вы писали:
IT>>Кстати, один из способов, позволяющих решить эту проблему, это локальные функции. К сожалению, в C# этого нет, и пока, как я понял не планируется.
M>Ну можно это будет лямбдами сэмулировать. Хотя для 3х уровней вложенности это ужастик получится, да.
На каждую такую функцию уморишься делегаты ообъявлять. Короче, лажа это. Без крайней необходимости никто этим пользоваться не будет.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, FDSC, Вы писали:
FDS>> 1. Не сохранил нужную информацию о обработчике информации
ANS>К архитектуре это не имеет отношения.
Как раз имеет. Именно архитектура определяет формат данных в сохраняемом файле и от этого формата (и от того, что сохраняется, а что — нет) очень многое зависит.
FDS>> 2. Вообще вся необходимая информация находится в другом модуле, является приватной и ещё не загружена
ANS>Вот-вот. Этого ты не знал. А мог бы написать тест, который выводил список доступной тебе информации в модуле. Но, опять же, какое влияние на архитектуру.
Какой ещё тест? Я сам проектировал этот модуль, но когда проектировал и писал ещё не знал, что информация этого модуля мне понадобится. Хотя специально смотрел, какая информация понадобится, про эту забыл.
FDS>>3. При десериализации порядок вызова методов обработчиков информации неправильный и приводит к ошибкам. И вот тут мне было очень плохо
ANS>Пиши тесты
Опять же, что же это за тест, который тестирует архитектуру? Я просто взял и так спроектировал программу, что порядок загрузки информации был неправильный. Причём этот порядок определялся именно архитектурой, а не порядком вызова некоторых функций в методе. Для его исправления пришлось довольно много всего писать.
Здравствуйте, FDSC, Вы писали:
FDS>Как раз имеет. Именно архитектура определяет формат данных в сохраняемом файле и от этого формата (и от того, что сохраняется, а что — нет) очень многое зависит.
Моё понимание архитектуры отличается от твоего
А от такой "забывчивости", как ты описал никакой мегатул не спасёт.
Здравствуйте, FDSC, Вы писали:
IT>>Убейте меня застрелите. Я не понимаю как декомпозиция метода позволяет мне глубже осмыслить алгоритм над которым я работаю
FDS> FDS>А вы всегда выписываете алгоритм действий на бумажке? Или хотя бы на псевдокоде? И всегда после этого проверяете соответствие кода тому, что написано на бумажке?
На бумажке уже даже не помню когда писал. Писать начинаю в коде сразу, даже ещё не понимая что получится в результате. Единственное, что я стараюсь делать с самого начала — это писать так, чтобы код работал сразу. Т.е. пусть он ещё делает не всё, но уже делает то, что написано, чтобы это можно было запустить и посмотреть. Дальше по шагам начинаем достраивать алгоритм и с каждым таким кирпичиком проверяем результат. При таком подходе опысываемые тобой ошибки исключены.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Ракопаукодав, Вы писали:
Р>Это советы для кодирования, а спрашивали рекомендации по проектированию
Советую ещё раз внимательно перечитать вопрос.
ЗЫ. Я специально старался опускать вопросы проектирования и архитектуры, т.к. умных общих фраз тут и без меня навыдают. Только, к сожалению, по моим наблюдениям между умением говорить такие банальности и умением их применять лежит огромная пропасть, мостиком через которую как раз и являются практические приёмы и навыки.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[12]: Ошибок не делает тот, кто ничего не делает
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Andrei N.Sobchuck, Вы писали:
AVK>>>А кто сказал, что он уникален?
ANS>>Хорошо. Тогда скажи в каком именно другом месте проблема.
AVK>Место называется GUI
А я как всегда думал что в генах ... Оказывается все простог , виноват противный ГУИ . Зато мне легче стало на душе И я не стану с прохладой относиться к тому что говорят люди запятнавшие себя разработкой Януса !
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[13]: Ошибок не делает тот, кто ничего не делает
Здравствуйте, red_dragon, Вы писали:
_>Здравствуйте, prVovik, Вы писали:
V>>Здравствуйте, red_dragon, Вы писали:
_>>>Проведение рефакторинга системы без юнит-тестов — это bugs*bugs при котором bugs -> infinity
V>>Несмотря на то, что я за юнит тесты, но данное высказывание более чем спорно
_>Делали рефакторинг без юнит-тестов?
_>Я делал В итоге что-бы все заработало как надо, потратил массу времени, ну и чистота кода оставляет желать лучшего
Да слышал я этого шалапина ! Мне рабинович напел , такой акцент ..
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, FDSC, Вы писали:
IT>>>Убейте меня застрелите. Я не понимаю как декомпозиция метода позволяет мне глубже осмыслить алгоритм над которым я работаю
FDS>> FDS>>А вы всегда выписываете алгоритм действий на бумажке? Или хотя бы на псевдокоде? И всегда после этого проверяете соответствие кода тому, что написано на бумажке?
IT>На бумажке уже даже не помню когда писал. Писать начинаю в коде сразу, даже ещё не понимая что получится в результате. Единственное, что я стараюсь делать с самого начала — это писать так, чтобы код работал сразу. Т.е. пусть он ещё делает не всё, но уже делает то, что написано, чтобы это можно было запустить и посмотреть. Дальше по шагам начинаем достраивать алгоритм и с каждым таким кирпичиком проверяем результат.
Вот до этого места я читал с жутким одобрением и думал, что делаю точно так же
IT> При таком подходе опысываемые тобой ошибки исключены.
Здравствуйте, rameel, Вы писали:
R>Здравствуйте, FDSC, Вы писали:
FDS>>Спасибо большое Вот так всегда — не купишь книжку по очередной версии студии и что-нибудь обязательно не заметишь
R>Смарт теги реализованы не только в студии, но и в ворде и т.д., это так к сведению
Для усовершенствования работы головы есть разные методики, типа ТРИЗа. Другое дело, я не знаю, насколько они помогают 
Да и если записывать такие действия в коде, не видно, кто к кому обращается, очень велик риск потерять информационные связи.
Если нам не помогут, то мы тоже никого не пощадим.
