Здравствуйте, AndrewVK, Вы писали:
D>> Именно. Тогда придется писать кучу смартпойнтеров для каждого типа, или извращаться.
AVK>Ну зачем так жестоко? Можно создать базовый класс и написать для него смартпоинтер, а потом все управляемые классы наследовать от него.
Не всегда это возможно, к сожалению... А так да.
D>>Лучше тогда вообще их не писать...
AVK>Ну это уже другой вопрос. Главное что смартпоинтеры отсутствуют прежде всего из-за отсутствия автоматичиеских деструкторов.
Здравствуйте, Demiurg, Вы писали:
AVK>>Ну зачем так жестоко? Можно создать базовый класс и написать для него смартпоинтер, а потом все управляемые классы наследовать от него.
D> Не всегда это возможно, к сожалению... А так да.
Ну так народ тут уверял что в Дельфи интерфейсы есть. Вот как раз в данном случае самое оно.
Здравствуйте, AndrewVK, Вы писали:
D>> Не всегда это возможно, к сожалению... А так да.
AVK>Ну так народ тут уверял что в Дельфи интерфейсы есть. Вот как раз в данном случае самое оно.
Интерфейсы есть. Дело не в том, что я не могу сам свои классы унаследовать от одного базового или интерфейса, а в том, что есть уже (допустим) огромная куча чужих классов, и хотелось бы с ними работать через смартпойнтеры. При написании своей программы с нуля эта проблема снимается.
Здравствуйте, Demiurg, Вы писали:
D>Здравствуйте, George Seryakov, Вы писали:
GS>>Здравствуйте, Demiurg, Вы писали:
D>>>... Тешу себя мыслей, что хоть мой код привносит немного света в беспроглядную тьму...
GS>> А твой код еще не переписывали? Типа — сделал все чистенько: классы, смартпойнтеры, QWAN.
D> В Дельфе нет шаблонов, так что обходимся без смартпойнтеров Как же я ее ненавижу... крик души...
GS>> А потом заходишь в архив и видишь правку — кто-то убрал смартпойнтеры, понапихал глобальных переменных, испортил логику и т.п. И все просто потому, что не понимал, что написано.
D> Со мной, слава б-гу, такого не было (только зачастую мой код к своему страшному стилю приводят), а вот с коллегой как-то ужас такой произошел... Именно из-за непонимания кода, все убрали, по-своему написали (неправильно), пришлось с нуля все переписывать, месяц загублен...
как же так? в проекте нет контроля версии?! Нонсенс.
GS> и мантру русского программиста — "Все это надо переписать"
Да, кто-то из Великих утверждал, что переписывание чужого кода есть явный признак immature программера. По мне так быстро разбираться в чужом коде не более, чем дело привычки. Надо просто набить руку.
Здравствуйте, George Seryakov, Вы писали:
GS>Здравствуйте, Advanced_User, Вы писали:
A_U>>Насколько я себе представляю,если я участвую в разработке какого-то проекта, то всегда могу лично пообщаться с другими его участниками. Кроме того, мне, по всей видимости, известен общий дизайн проекта (структура классов, возможно, UML — диаграммы.)
GS>Не знаю как за опенсорец, но в коммерческих разработках типическая ситуация — куча мутно написанного кода, не со всеми разработчиками можно пообщаться, а с некоторыми и не хочется, структура классов ничего не отражает, дизайна нет, а проектная документация ничему не соответствует. И в этой ситуации нужно исправить ошибку, подавить утечку памяти, впарить новую фичу, отпортировать проект на другую операционку/базу данных, довести сырой код до ума и т.д. и т.п. Да, и мантру русского программиста — "Все это надо переписать" — разрешается произносить только про себя.
GS>Вот так и разбираешься в чужом коде. Причем с годами приходит тонкое исскуство разбираться только в том чужом коде, что нужно, и ни строкой больше.
Интересно, а как Microsoft разработчики в Windows исходниках разбираются
GS> А твой код еще не переписывали? Типа — сделал все чистенько: классы, смартпойнтеры, QWAN. А потом заходишь в архив и видишь правку — кто-то убрал смартпойнтеры, понапихал глобальных переменных, испортил логику и т.п. И все просто потому, что не понимал, что написано.
Чтобы такого не било, надо поддерживать свои классы самому и не кому не довать
делать в них изменения. А если находится ошибка или надо чего нибудь
изменит, то не делать это самому, а поручать это дело самому разработчику класса.
Время — денги, потому нету смысла тратить время на понимание чужих исходников.
ИМХО самое главное надо знать API
Здравствуйте, Advanced_User, Вы писали:
A_U>Какие будут ваши рекомендации ?
Есть неплохой метод. Допустим надо разобраться в чужом страшном коде.
Попробуй спроектировать систему сам. Процесс итеративен. При попытке это сделать, ты будешь регулярно выяснять:
1) что у тебя не хватает знаний о том, что должна делать программа, и ты не можешь ее дальше проектировать . Что важно, при попытке дизайнить ты выяснишь конкретно, каких знаний тебе не хватает, и сможешь ликвидировать их недостаток. Пополни свои знания, и повтори попытку.
2) что налицо техническая проблема, которая может быть решена рядом способов. Отлично! Теперь ты будешь не просто глазеть на код, а изучать его на предмет выяснения, какой из вариантов выбрали разработчики. А это уже задача попроще — ты примерно знаешь, что ты должен увидеть. Смотрим в код, качаем головой, говорим "однако!", продолжаем дизайнить.
3) Что тебе это в общих чертах удалось. Здорово. Открывай код. Смотри. Если ты не узнаешь в нем ничего из своего дизайна, это будет конечно проблема. Но это крайне маловероятно. В любом случае, ты будешь уже знаком с проблематикой, и ты будешь способен отличить главное от второстепенного. А это самое важное.
Итак, что в этом деле самое важное? Нет, не знать на что смотреть. Гораздо важнее знать, на что смотреть не надо. Кода много. Весь не прочитаешь — получишь взыв мозга. Читать надо немного кода, и избирательно, проверяя свои гипотезы о дизайне софтины. Правило просто — ни в коем случае не пялится на код просто так, а искать в нем ответы на конкретно поставленные вопросы по дизайну. Постигнешь это ДАО, будет тебе щастье.
Здравствуйте, George Seryakov, Вы писали:
GS>Здравствуйте, Advanced_User, Вы писали:
A_U>>Насколько я себе представляю,если я участвую в разработке какого-то проекта, то всегда могу лично пообщаться с другими его участниками. Кроме того, мне, по всей видимости, известен общий дизайн проекта (структура классов, возможно, UML — диаграммы.)
GS>Не знаю как за опенсорец, но в коммерческих разработках типическая ситуация — куча мутно написанного кода, не со всеми разработчиками можно пообщаться, а с некоторыми и не хочется, структура классов ничего не отражает, дизайна нет, а проектная документация ничему не соответствует. И в этой ситуации нужно исправить ошибку, подавить утечку памяти, впарить новую фичу, отпортировать проект на другую операционку/базу данных, довести сырой код до ума и т.д. и т.п.
GS>Да, и мантру русского программиста — [b]"Все это надо переписать" — разрешается произносить только про себя.[/b]
Я произносил вслух -- жив остался.
GS>Вот так и разбираешься в чужом коде. Причем с годами приходит тонкое исскуство разбираться только в том чужом коде, что нужно, и ни строкой больше.
Здравствуйте, Demiurg, Вы писали:
D> Пример из практики — этими разработчиками была написана своя версия функции регистрации COM-сервера, просто потому, что они не знали, что есть стандартная.
я один раз столкнулся со случаем, когда чел написал вызов методов интерфейсов COM полностью вручную, через IDispatch. Налопатил целую кучу оберток.
Просто он никогда не слышал про #import
Здравствуйте, bkat, Вы писали:
B>SNiFF очень неплох для навигации и поиску по коду. B>Он позволяет настроить себя так, что ты из всей массы B>файлов будешь видеть только то, что нужно тебе.
Зашел на сайт где sniff этот лежит ...
мне показалось, или он действительно стоит 2 с чем-то
штуки баксов ?
Здравствуйте, Advanced_User, Вы писали:
A_U>Но КАК можно в ЭТОМ всём разобраться, ведь там же ТОЛЬКО исходники
Задача сама по себе довольно сложная и не только для малоопытных специалистов... Сплошь и рядом встреяается необходимость разбираться в чужом коде, причём чаще в коммерческом, чем в открытом. В открытом коде ты может быть захочешь покопаться для себя, для самообразования, а в коммерческом приходится разбираться по долгу службы. Причём код не просто стар, а написан неизвестно по какой спецификации, разными людьми и с ошибками
Короче, это всё лирика, вот какой рецепт понимания чужого кода я для себя с годами выработал, теперь и другим рекомендую:
Научится компилить этот код. Без этого никуда.
Научится дебагать этот код. Т.е. настроить дебаггер и научится этим старьём пользоваться, потому как если кто думает, что всё на свете написано на VS, то он... ошибается.
Экспериментировать. Т.е. что-то менять, компилить, смотреть что получится, если получилось не то, что хотел — дебагать.
Зациклившись на третьем пункте, ты будешь со временем всё лучше и лучше знать нужный тебе код или — что важно — необходимую тебе его часть.
Здравствуйте, pivoo, Вы писали:
P>Здравствуйте, bkat, Вы писали:
B>>SNiFF очень неплох для навигации и поиску по коду. B>>Он позволяет настроить себя так, что ты из всей массы B>>файлов будешь видеть только то, что нужно тебе.
P>Зашел на сайт где sniff этот лежит ... P>мне показалось, или он действительно стоит 2 с чем-то P>штуки баксов ?
Да, он недешев.
Но чем больше я с ним работаю, тем больше он мне нравится
Впрочем это всего лишь один из многих тулов...
Не факт, что тебе он понравится.
Здравствуйте, Demiurg, Вы писали:
D> Интерфейсы есть. Дело не в том, что я не могу сам свои классы унаследовать от одного базового или интерфейса, а в том, что есть уже (допустим) огромная куча чужих классов, и хотелось бы с ними работать через смартпойнтеры. При написании своей программы с нуля эта проблема снимается.
А разве те классы не наследуют от общего TObject?
Здравствуйте, Шахтер, Вы писали:
GS>>Да, и мантру русского программиста — "Все это надо переписать" — разрешается произносить только про себя.
Ш>Я произносил вслух -- жив остался.
Обычно коммерческий код не переписывается (не поддается переписыванию) потому, что в процессе писания переговорено с тучей разных людей, а переписывать — говорить все эти разговоры по новой.
Но, однако, бывают варианты. Вот сейчас мы наконец домучиваем набор автоматизированных тестов, хорошо покрывающий систему, так я теперь, пожалуй, и начану потихоньку переписывать наиболее одиозные вещи — поскольку любое изменение смогу прогнать по тестам вместо того, чтобы релизить, получать критику и долго обсуждать с кем-то кто знает бизнес — как же все это должно работать. И то — бизнес-логику трогать не хочется, а вот всякие архитектурные ошибки можно и попробовать. То есть не переписывание, а рефакторинг.
Здравствуйте, Mystic, Вы писали:
M>Здравствуйте, Advanced_User, Вы писали:
A_U>>Какие будут ваши рекомендации ?
M>
M>repeat
M> View;
M> Edit;
M> if Need then Undo;
M> if Vagueness then WriteUnitTest;
M>until False;
M>
Ну и что? Разберись с тем, что делает данный блок, для чего он в приницпе нужен. Дай в шапке комментарий ко всему блоку. Изредка адвай комменатрии на строках справа (особенно если длинный if...else). Комментарии другие разработчики вряд ли будут стирать, да и табу это вообще, комментарии текстовые стирать — это ж не закоменченный код, как ни как...
Рано или поздно другие разработчики (не такие трудолюбивые в плане писать комментарии, как ты ) поймут, что писать комментарии — это хорошо, может даже научатся писать их правильно... просто делай свое дело хорошо, оставайся самим собой и все будет хорошо
Принципиальный вопрос, понимаю 
Налопатил целую кучу оберток.
