Чужой код

← →
Megabyte © (2005-10-26 16:36) [0]

Устроился, наконец, на работу в серьезную фирму. Причем по совместительству, на 3 дня в неделю. Т.е. и на учебу с практикой не придеться забивать. Просто лакомый кусочек для студента. :)
Взяли стажером, соответственно испытательный срок - 1 месяц. И самое 1-е задание - разобраться в чужой программе и переделать ее. :(
Самая, по-моему, неблагодарная работа для программиста. А мне надо себя проявить на должном уровне умений в 1-й месяц, чтобы остаться.
Как объяснил директор, чтобы научились разбираться в чужом коде, т.к. в будущем придеться работать в команде.

Причем там по ходу даже комментов нету(уже один стажер-девушка уже получила задание похожее, у нее без комментов).

Мне брат давно и сразу вдолбил: все проги писать с комментариями, иначе даже сам можешь потом забыть, что и для чего писал в данном месте.

Кому как часто приходилось править чужой код и наколько легко это давалось?

з.ы.А то меня уже сейчас сомнения одолевают: разберусь ли самостоятельно там.

← →
Ega23 © (2005-10-26 16:39) [1]

> Кому как часто приходилось править чужой код и наколько
> легко это давалось?

У нас один чувак уволился 2,5 года назад. Оставил "тяжёлое наследство". Коллега всё это время с ним мучается. Уже бы 2 раза успели начисто переписать.

← →
Sandman29 © (2005-10-26 16:40) [2]

А то меня уже сейчас сомнения одолевают: разберусь ли самостоятельно там.

Значит, правильное задание дали. Проверка способностей и умения расти, а не вдолбленных знаний.

Кому как часто приходилось править чужой код и наколько легко это давалось?

После смены работы занимаюсь этим практически постоянно. Нелегко. И это хорошо, конкурентов меньше :)

← →
oldman © (2005-10-26 16:44) [3]

> И самое 1-е задание - разобраться в чужой программе и переделать
> ее. :(

разобраться то за месяц можно (зависит, правда, от ума исходного программиста), а вот "переделать"...

← →
Sandman29 © (2005-10-26 16:44) [4]

Ega23 © (26.10.05 16:39) [1]

Если работник был так плох, почему его раньше не уволили?
Если коллега так плох, почему его еще не уволили? :)

← →
Игорь Шевченко © (2005-10-26 16:49) [5]

"Когда я окончил школу, я считал себя самым лучшим программистом в мире. Я мог написать непобедимую программу игры в крестики-нолики в трехмерном пространстве на пяти различных языках программирования, а также написать программу, состоящую из 1000 строк, которая бы работала. Затем я попал в реальный мир. Моей первой задачей было прочитать и понять фортрановскую программу емкостью 200000 строк, а затем увеличить скорость ее работы в 2 раза. Любой настоящий программист скажет вам, что все структурированное программирование мира не поможет вам решить проблемы вроде этой - решение этой задачи требует настоящего таланта"
(с) "Настоящие программисты не используют паскаль"
http://www.kosha.saits.lv/PAGES/humour_prog_realprog2.htm

← →
Ega23 © (2005-10-26 16:50) [6]

> Если работник был так плох, почему его раньше не уволили?

Там интересная ситуация была. Он был начальником группы. Потом группа серъёзно расширилась и начальником поставили теперешнего. Новый, чувствуя некоторое "смущение" от того, что первого "подсидел", не сильно контролировал то, что тот творит. А чувак этот был весьма забавный: он внедрял в проект любую новую технологию, которая появлялась. COM - есть у него кусок на COM-технологии. .NET? Есть и это. Часть кода на Delphi, часть - на C.
Ужос, одним словом.

← →
Megabyte © (2005-10-26 16:59) [7]

> Sandman29 © (26.10.05 16:40) [2]
> А то меня уже сейчас сомнения одолевают: разберусь ли самостоятельно
> там.
>
> Значит, правильное задание дали. Проверка способностей и
> умения расти, а не вдолбленных знаний.

Не, я пока само задание не видел, только у такого же стажера издалека. :)
Но по словам прога не маленькая. Ладно, по-любому на рользу пойдет...

← →
Sandman29 © (2005-10-26 17:03) [8]

Ega23 © (26.10.05 16:50) [6]

Да, действительно ужас.
У дружественной атмосферы тоже есть свои недостатки.

← →
Ega23 © (2005-10-26 17:04) [9]

> У дружественной атмосферы тоже есть свои недостатки.

Угу. С тех пор всё гораздо строже.

← →
Seg (2005-10-26 17:08) [10]

Самая, по-моему, неблагодарная работа для программиста.

Привыкай, это постоянная работа программиста.

← →
Гаврила © (2005-10-26 17:14) [11]

> Кому как часто приходилось править чужой код

Часто.

> и наколько легко это давалось?

Зависит от качества чужого кода.
Даже не от комментариев, именно от качества

> Уже бы 2 раза успели начисто переписать.

Проблема часто в том, что тех двух месяцев, которые необходимы на полное переписывание, нету.
Все должно работать вчера, и уже с изменениями.
Результирующие затраты времени получаются намного больше, но что делать...

← →
Sandman29 © (2005-10-26 17:23) [12]

>Результирующие затраты времени получаются намного больше, но что делать...

Точно. Напоминает потребительский кредит.

← →
oldman © (2005-10-26 17:28) [13]

> Seg (26.10.05 17:08) [10]
> Привыкай, это постоянная работа программиста.

не вводи студента в заблуждение :)))

← →
Seg (2005-10-26 17:40) [14]

не вводи студента в заблуждение :)))

Разобраться в собственном коде, написанном месяц назад, иногда сложнее, чем в чужом.

← →
Юрий Зотов © (2005-10-26 17:44) [15]

> Seg (26.10.05 17:08) [10]
> Привыкай, это постоянная работа программиста.

Смотря, кто и как проектировал и писал. Разрешите похвастаться - мой код еще ни разу не переделывался, даже и мною самим. Правились мелкие глючки - это было (что естественно), расширялся функционал (причем возможность его расширения была введена заранее) - это тоже было, но чтобы что-то переделывать - такого еще не было.

← →
WondeRu © (2005-10-26 17:44) [16]

В последнее время часто, когда мне отдали чужой проект ... охота было все переписать заново, но сумел разобраться и внедрить дополнения! хотя, переписать все же надо, но это отнимет слишком много времени :(

← →
Юрий Зотов © (2005-10-26 18:07) [17]

> WondeRu © (26.10.05 17:44) [16]

> но это отнимет слишком много времени

"У нас никогда не хватает времени, чтобы сразу сделать работу хорошо, но всегда находится гораздо больше времени, чтобы бесконечно переделывать работу, сделанную изначально плохо".

Не помню, кто из великих это сказал, но полностью с эими словами согласен. Единственное, что добавил бы - "не только времени, но и денег тоже". Поскольку работа, сделанная быстро, но плохо в итоге отнимает не только гораздо больше времени, но и обходится куда дороже, чем работа, сразу сделанная хоть и медленно, но хорошо.

← →
Anatoly Podgoretsky © (2005-10-26 19:41) [18]

Нет времени на переделки и исправления ошибок, поэтому приходится писать сразу правильно.

← →
Sergey Masloff (2005-10-26 21:07) [19]

Megabyte © (26.10.05 16:36)
>Кому как часто приходилось править чужой код и наколько легко это >давалось?

Постоянно

Кстати когда пришел на текущее место работы первое что мне дали это папка (ОДНА) с 80 Мб исходников (штук 10 проектов перекрестно юзающие файлы) причем под разные версии компилятора. Повторю - все это было в ОДНОЙ папке без поддиректорий. И авторы всего этого уволились за полгода до моего прихода. За эти полгода 3 человека пытались это дело править но не выдерживали и уходили поработав по полтора-два месяца.
Когда я сел разбирать это дело приходили чуть ли не экскурсии смотреть как чудик будет это разгребать. Причем проекты были живые и постоянно глючили и нужно было хотя бы минимально жизнь в них поддерживать.

Все закончилось успешно я работаю уже пятый год, вместо всех этих проектов работает один мой (ну вернее 2 на общем ядре) проблем нет на поддержку трачу 1 день в месяц хотя юзеров увеличилось на 2 порядка.
Это не к тому какой я умный а к тому что надо сидеть на ж. ровно и тупо и аккуратно все разбирать и стараться все что можно переписать в понятном виде.

← →
Юрий Зотов © (2005-10-26 21:19) [20]

> Sergey Masloff (26.10.05 21:07) [19]

Снимаю шляпу. Ты гигант и трудяга. Других слов просто нет.

← →
Игорь Шевченко © (2005-10-26 22:01) [21]

Sergey Masloff (26.10.05 21:07) [19]

> ровно и тупо и аккуратно все разбирать и стараться все что
> можно переписать в понятном виде.

Золотые слова ;)

← →
Megabyte © (2005-10-27 13:10) [22]

Ух. Там охрененный пакет проектов(исходников вроде около 50мб). Подгружается куча Bpl. Для начала надо разобраться, где и как к одной формочке подгружаются наколько Bpl(каждая Bpl вносит на форму новый пункт меню-форму, на которой совершаются различные операции), потом сделать свою Bpl и тоже подгрузить.
Ни разу до этого Bpl не делал. Ну думаю, это не главная проблема.
Короче рюхать и рюхать.

← →
Igorek © (2005-10-27 14:09) [23]

> Мне брат давно и сразу вдолбил: все проги писать с комментариями,
> иначе даже сам можешь потом забыть, что и для чего писал
> в данном месте.

Нифига подобного. В хорошем коде не должно быть комментариев.

← →
вразлет © (2005-10-27 14:17) [24]

Чужие проекты по возможности посылаю лесом.

← →
вразлет © (2005-10-27 14:18) [25]

Нифига подобного. В хорошем коде не должно быть комментариев.

Да Винчи, мля.

← →
ZeroDivide © (2005-10-27 14:27) [26]

Разобраться нужно прежде всего с "Зачем это нужно", а уж "Как это работает" можно понять по коду и без комментариев. Любые непонятные ситуации по первому пункту, выясняются вербально, путем задавания вопросов (возможно глупых, в этом деле стесняться не надо) всем причастным лицам, до полного прояснения картины. Шикарно, если по первому пункту есть документация. В хорошей конторе есть документация, по технологиям собственной разработки а-ля
> к одной формочке подгружаются наколько Bpl(каждая Bpl вносит
> на форму новый пункт меню-форму, на которой совершаются
> различные операции)

← →
Jeer © (2005-10-27 14:55) [27]

Никогда не работал с чужими проектами.
Незачем.

← →
Igorek © (2005-10-27 15:17) [28]

> вразлет © (27.10.05 14:18) [25]
> Нифига подобного. В хорошем коде не должно быть комментариев.
> Да Винчи, мля.

Что? Ты бы потрудился изьясняться более четко. Говорят от этого и в голове порядок появляется..

← →
_inic (2005-10-27 18:34) [29]

А еще один минус, встречающийся в жизни, программирование на базе чьей-то платформы. Переделывать ее не надо, но разбираться в ней придется. А если она еще и сырая....

> Igorek
> Нифига подобного. В хорошем коде не должно быть комментариев.

Скорее в идеальном

← →
oldman © (2005-10-27 18:37) [30]

> _inic (27.10.05 18:34) [29]
> Скорее в идеальном

А зачем переделывать идеальный код? :)

← →
Юрий Зотов © (2005-10-27 19:27) [31]

Уря. Мой код близок к идеалу - в нем почти не бывает комментариев.
:о)

← →
Igorek © (2005-10-27 20:16) [32]

> Скорее в идеальном

Идеальный код:
- работает
- работает самым оптимальным образом
- имеет самодокументируемые идентификаторы
- имеет хороший дизайн классов, процедур
- не имеет комментариев вообще
..
- и самое главное - у постороннего вызывает чувство гармонии, радости и прикосновения к прекрасному.. (как картины того же Леонардо) :)

← →
Юрий Зотов © (2005-10-27 20:19) [33]

Еще раз уря. Мой код и правда близок к идеалу.

Особенно - в самом главном.
:о)

← →
Fay © (2005-10-27 23:04) [34]

2 Игорь Шевченко © (26.10.05 16:49) [5]
Сходил по ссылке. Прочитал. Огромное спасибо!!!
Я не настоящий программист, и это замечательно!

← →
Игорь Шевченко © (2005-10-27 23:50) [35]

Igorek © (27.10.05 20:16) [32]

1) Это противоречащие друг другу критерии.
2) Комментарии должны быть. Должен быть, как минимум, один комментарий - нафига этот код вообще написан.

← →
DiamondShark © (2005-10-27 23:54) [36]

> Должен быть, как минимум, один комментарий - нафига этот
> код вообще написан.

Имя метода подойдёт?

← →
Sergey Masloff (2005-10-28 21:29) [37]

DiamondShark © (27.10.05 23:54) [36]
>Имя метода подойдёт?
В теории. Типа круглого коня в вакууме. А на практике - нет

← →
SPeller © (2005-10-29 11:02) [38]

Я когда работал так же, то проблем с пониманием кода особых не возникало - оформление кода было строго декларировано, поэтому разницы, кто писал - не было. А что же касается понимания логики, то мозги + скролл мыши + ctrl-click + F7, и во всём можно разобраться :) Лично для меня тут препятствий не возникало.

Что же касается задания на испытательный срок автору - то это практика стандартная, на сколько я знаю. Мне тоже давали небольшую программку, в которой надо было найти намеренно сделанные баги, и улучшить быстродействие. У автора задача того же принципа. Так что, сложного в этом нет. Работодатель не стал бы давать сверх-сложные задания новичку.

Что же касается комментариев, то у нас на работе их почти небыло (только в каких-то замудрённых случаях). Код благодаря строгости оформления легко читался (после недолгого привыкания) и в голове сразу же выстраивалась логика работы. Поэтому считаю, что комментарии нужны там, где они действительно нужны, т.е. в очень сложных и хитрых алгоритмах. В остальном - не нужны.

Игорь Шевченко © (27.10.05 23:50) [35]
Должен быть, как минимум, один комментарий - нафига этот код вообще написан
У нас это решалось даванием переменным и функциям осмыленных названий. И всё было прекрасно видно, где что и для чего. Или вы о другм?

← →
SPeller © (2005-10-29 11:03) [39]

SPeller © (29.10.05 11:02) [38]
другм
другом

← →
Anatoly Podgoretsky © (2005-10-29 12:19) [40]

Игорь Шевченко © (27.10.05 23:50) [35]
Если внутри длинного блока комментируется субблок, то этот субблок кандидат на осмвсленную процедуру, а комментарием станет ее название.
Комментировать, а точнее по смыслу описывать, стоит алгоритм блока и то если он нетривиальный.

← →
Igorek © (2005-10-29 15:49) [41]

> Игорь Шевченко © (27.10.05 23:50) [35]
> Igorek © (27.10.05 20:16) [32]
> 1) Это противоречащие друг другу критерии.

Интересно..
Критерий i противоречит критерию j, если i<>j ?

← →
BorisMor © (2005-10-30 00:11) [42]

Нужны комментарии.
Во-первых надо думать о тех кто прейдет за тобой.
Во-вторых с ними проще жить. Я к каждой процедуре/функции/проперти пишу комент. (бывает и алгоритм описываю)
Если что-то надо поменять(даже написанное год назад) мне достаточно пробежать глазами по комментариям что бы вспомнить где как это все реализовано было и что где выполняется.

При этом заметил что когда пишиш комментарий более осмысленно подходишь к процессу программирования. Но это мои интимные ощущения :)

Это все хорошо (отсутствие комментариев), когда в проекта один-два-десяток юнитов.
Когда их несколько сотен, без комментариев труднее.

← →
_inic (2005-10-31 12:58) [45]

комментируя, например, функцию, мы не только передаем смысл ее действий (что часто можно выразить в названии), но и зависимость от других элементов программы, пределы значений, расшифровку возвращаемых значений и т.п. Поэтому imho если предполагается возможное изменение или дополнение нужны или комментарии, или документация для программистов.

ЗЫ Короче зачем-то пережевал жёванное

> [45] _inic (31.10.05 12:58)
> комментируя, например, функцию, мы не только передаем смысл
> ее действий (что часто можно выразить в названии), но и
> зависимость от других элементов программы, пределы значений,
> расшифровку возвращаемых значений и т.п.

1. Зависимость от других элементов программы должна быть сведена к 0.
2. Если таковая зависимость все-же существует, она должна быть недвусмысленным образом обозначена в самом коде:procedure ProcessUserData; begin Assert (Storage.User.YearOfBirth>=1990); ... end;
3. Пределы значений также можно явно обозначить через Assertion и заданием пользовательских типов данных:type TYear = 1990..3000;
или заменой типа данных классом со своей логикой обработки значений.

И комментарии при таком подходе совершенно излишни.

Ку? ;>

Джо © (31.10.05 14:29) [46]

> И комментарии при таком подходе совершенно излишни.

В одной конторе, на вопрос: "А почему у вас комментариев в коде нету" был дан ответ: "Если кто сопрет, пусть помучается".

Вот как ты полагаешь, наверное, придумывать осмысленные имена для переменных, методов и классов стали довольно давно, однако, про необходимость комментариев почему-то пишут практически все гуру программирования. Им-то какой интерес ? :)

придумывать осмысленные имена для переменных,
:)
Венгерская нотация

Ну а с VCL исходниками никто не работает?

Хватит спорить. Комментарии - зло. Точка. Это аксиома. Остальное вторично. Если без них туго - то это проблемы писаки.

[47] Игорь Шевченко © (31.10.05 14:34)
> В одной конторе, на вопрос: "А почему у вас комментариев
> в коде нету" был дан ответ: "Если кто сопрет, пусть помучается".

Это, конечно, мощный аргумент :)

Я в своем посте утрировал слегка, разумеется. Просто достал вот такой код:var A: Integer; B: TDateTime; jkl: TClass1; ... // в B хранится дата рождения работника if B < 1989 then ...
Также достали дикие связи между юнитами, где практически каждый класс творит с другим, что ему пожелается и затем это все многословно комментируется в стиле: "Если в классе A поле B не инициализировано, то это работать не будет"...
Как по мне, в большинстве случаев достаточно комментария в виде "шапки" в модуле с описанием его назначения. Используемые нетривиальные алгоритмы тоже полезно комментировать (лично я, впрочем, предпочитаю в директории с проектом сохранять отдельные файлы .rtf с описание алгоритма, если нужно со схемой, а в коде даю ссылку на него. Придумал относительно недавно -- очень удобно). Ну, и еще полезно комментирование, если на его основе потом автоматически генерируется тех. докумментация. В общем, тезис: умеренность в комментариях, по моему, признак хорошо продуманного кода
Все имхо.

isasa © (31.10.05 14:47) [48]

> Ну а с VCL исходниками никто не работает?

А вот представь, что у тебя vcl.hlp нету. И поработай.

Igorek © (31.10.05 14:47) [49]

Свою цитату сам вспомнишь ?

Джо © (31.10.05 14:56) [50]

> Как по мне, в большинстве случаев достаточно комментария
> в виде "шапки" в модуле с описанием его назначения. Используемые
> нетривиальные алгоритмы тоже полезно комментировать (лично
> я, впрочем, предпочитаю в директории с проектом сохранять
> отдельные файлы .rtf с описание алгоритма, если нужно со
> схемой, а в коде даю ссылку на него. Придумал относительно
> недавно -- очень удобно). Ну, и еще полезно комментирование,
> если на его основе потом автоматически генерируется тех.
> докумментация. В общем, тезис: умеренность в комментариях,
> по моему, признак хорошо продуманного кода

А вот с этим согласен целиком и полностью. Также еще очень полезно отмечать в тех комментариях, какая сволочь и с какой целью что-то меняла в коде.

> Свою цитату сам вспомнишь ?

Какую из? Фразу 2005 года? :)

> Игорь Шевченко © (31.10.05 15:14) [53]

Та дискуссия меня многому научила. :)
Я написал [49] полушутя, после обеда.. Дабы подогреть азарт.. Но если действительно принять [49], то много проясняется. Смысл в том, чтобы писать ясный код без комментариев до тех пор, пока это возможно. А не сразу добавлять простыни прозы. И только когда совсем невмоготу - написать маленький комментарий. Да и то.. часто вспоминать об этом случае потом и спрашивать себя "а нельзя было без комментариев".

Уж то, что код должен быть ясным, надеюсь не вызывает сомнений ни у кого.

как комментарии не пиши все равно многое останется неясно для не сильно продвинутых читателей.

мое имхо такое:
1. шапку модуля (классы, методы и пр.) нужно очень тчательно описывать:
а) семантику методов
б) семантику параметров
в) precondition, postcondition, ограничения
г) с недавших пор взял за моду писать как в java throws. Смысл, конечно не такой немоного - но хотя бы понятно, что вот такие исключения могут быть выброшены.
д) для классов пишу иногда примеры.

2. тело модуля нужно комментировать в расчете на опытного человека.
а) конечно нужно стараться придумывать вменяемые имена идентификаторов.
б) нужно комментировать тонкие элементы бизнес-логики: какой у системы ни будь дизайн от этого не уйти.
г) нужно разделить комантарии на оформительские и собсвенно комментарии. Да, классики говорят, что методы должны быть короткие. Но такое все же УДОБНО не всегда. Поэтому одним типом коментириев (у меня (**)) обозначаю части кода. Ну типа (* Инициализация данных по покупкам *). Другой вид комментирев (у меня //) можно использовать для пояснения логики.

← →
Dmitriy O (2005-10-31 16:18) [56]

Удалено модератором

Удалено модератором
Примечание: Offtopic

Честно говоря не могу понять людей, которые говорят, что комментарии излишни. То ли действительно с большими проектами не сталкивлись(>10 юнитов)... Вы вот говорите про хороший код. Это хорошо, когда код хороший(каламбур получился). В данном случае мне повезло с этим. Но ведь не всегда же вы будете разбираться в идеальном коде. Ну не всегда же программист ВСЕ знает. А с комментами проще разобраться, что эта процедура/функция делает.

1-ю задачу выполнил. :) Свою Bpl-ку сделал подгрузил к основному модулю Как мне сказали, что ближайшая наша работа будет - это написание вот таких модулей(для работы с БД), каждый из которых присоединяется к главному модулю.

> Честно говоря не могу понять людей, которые говорят, что
> комментарии излишни. То ли действительно с большими проектами
> не сталкивлись(>10 юнитов)...

В том то и дело, что сталкивались. И не колличеством юнитов меряется, а строк.

Чужой код Найти похожие ветки