как построить алгоритм работы?

[dub]

как построить алгоритм работы?

Вобщем есть код поточный(в перемешку html,javaScript, php + include - ды) с вкраплениями классов и sql. Работает, но как? Документации нет. коментов почти тоже, не считая таких "// вот тут мне на сегодня надоело писать пошол я пиво пить... "
Есть ли алгоритм разбора чужого кода?
Просто интересно как можна в кратчайшие сроки разобрать чужой код с целью понятия и последующей доработки?
Как я конечно понимаю - брать и разбирать. Но вермя...
Просто интерсно мнение других по этому вопросу....

 

[Panchous]

видимо, за пивом с тем самым, кто забывал про комменты...

 

[dub]

Автор оригинала: Panchous

видимо, за пивом с тем самым, кто забывал про комменты...

Его давным давно уволили. И правильно сделали . Жалко только что через чур много написал собака...

 

[magic]

Тебе сюда

 

[dub]

magic
не совсем. там обсуждается как сделать так чтоб было приятно работать и не сделать себе какую нибудь ж.. на будущее.
Это все мне не надо, мы и так почти внедрили, документирование, общие стандарты, cvs и тд.. вобщем колектив сейчас друг друга понимает, опять же общее владение кодом тоже есть.
Мне больше интересно как можн разобрать код, который один нехороший человек писал 2 года до этого сам? может у кого опыт есть? Вобщем вопрос из ряда философских

 

[baev]

Не, никакой философии — «тупо» дебажишь и всё.

Иногда дедовского способа хватает: вставляешь везде отладочную печать, и сразу понятно — какая функция чего делает.

 

[dub]

baev
Дык так и делаю... Другого способа пока не нашол... Убивает осознание монотонности и неинтересности подобного занятия.

 

[StUV]

dub
для каждой операции в системе распиши на бумажке (или в какой-нить uml-среде) последовательность использования конструкций кода

далее, можно будет последовательно переписать кривой код и закаментить нормальный.

-~{}~ 09.06.06 11:05:

зы: переписывание будет не в ущерб скорости разработки - а в процессе багфиксинга и добавления новых фич
постепенно скорость разработки наоборот увеличится

если же сроки не поджимают, или есть резерв "человеко-ресурсов" - то советую переписать все с нуля =)

 

[Фанат]

возьми, да напиши заново

 

[antivir]

dub
никак. если код не особо большой, то можно пытаться разобрать.
если код - куча тяп-ляпов, тупо внедрённых готовых решений и т.д., то тут остаётся лишь _поддерживать_ код.

 

[StUV]

antivir
и сюда забрался
надо открыть раздел "вредные советы" и сделать тебя модером =)

то тут остаётся лишь _поддерживать_ код

сколько лет поддерживать ? =)

 

[antivir]

сколько лет поддерживать ? =)

пока умные люди код не напишут, хорошо документированный и понятный.

 

[Turist]

Насколько я понимаю варианта два:
1) рефакторинг
2) переписование всего с нюля

 

[chisto_tolyan]

хорошо документированный это по 40 строк комментов на функцию?)а чтоб понятный был - можно имена переменных и функций русскими буквами писать)

 

[Фанат]

завязываем с обсуждением 40 комментов

 

[dub]

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

 

[Develar]

В закрытой теме о "О наболевшем" itprog упомянул книгу "Совершенный код. Макконнелл". Книга из разряда must have. Когда прочтете - вопрос будет исчерпан.

 

[dub]

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

 

[baev]

Убивает осознание монотонности и неинтересности подобного занятия.

Дык, блин, меняйте «осознание».

Вообще-то, это и есть реальное «хакерство» — не программа «взламывается», а воспроизводится ход мыслей создателя программы.

 

[dub]

Дык, блин, меняйте «осознание».
Вообще-то, это и есть реальное «хакерство» — не программа «взламывается», а воспроизводится ход мыслей создателя программы.

Да уж хакнуть php код ... что-то влом мне воспроизводить чьи-то глупые мысли. Намного проще помоему все же переписать самому, просто выборочно. Вся суть, как я понял, сведется к рефракторингу того что можна, а что слишком муторно прийдется переделать. Опять таки уделив большое внимание правильности, документированию итд. итп.