Помогите научиться поддерживать сторонний код

[Духовность™]

Моя беда жизни в том, что я патологически боюсь больших объемов кода, особенно если это opensource или что-то ещё. Я не знаю, в чем кроется причина моего поведения, но я не умею работать с конечным продуктом. Сейчас мне нужно будет идти работать с magento. Я открываю код, я его свободно читаю, но я не могу настроить себя - мне кажется, быстро понять работоспособность такой большой системы - нереально!

Объясните, как научиться работать с большими объемами стороннего кода? На что смотреть при изучении кода - только на интерфейс класса или на тело методов тоже? Поделитесь, пожалуйста, методиками. Или, может, кто-то из классиков описывал как эффективно врубаться в сторонний код?

 

[Adelf]

Или, может, кто-то из классиков описывал как эффективно врубаться в сторонний код?

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

 

[craz]

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

P.s. я бы вот не стал в период поиска работы такие темы создавать) мало ли кто из той компании присутствует на этом портале)

 

[Mols]

Духовность™
Ох и паникер же Вы)))
Успокойтесь и разбирайтесь.
Всё будет нормально.
Только гоните от себя мысли типа "блин тут всё надо переделать" и "дайте мне пистолет, я застрелю того, кто это сделал".
Иногда действительно бывает надо переделать, но постоянно об этом думать - деструктивно.
Если уж совсем ппц попадается, то заводите список доработок и по мере изучения проекта список дополняете и систематизируете.
И если по прошествии времени не станет понятно, почему именно такие решения (не правильные на Ваш взгляд) были применены, и при этом Вы увидите какие решение надо внедрить для улучшения - можно поговорить об этом с коллегами или заказчиком.
Это и Вам сэкономит силы, и выглядеть будет прилично (в том смысле, что за Вашими предложениями будет видна реальная систематическая работа).

 

[craz]

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

при этом мегента опенсурс можно и разработчикам отправить.

 

[atv]

На что смотреть при изучении кода

Если фрэймворк, то на базовые вещи: работа с базой, файлами, данными запроса и т.д. Если конечное приложение, то только на то, что требуется в рамках задачи. Принципы в большинстве случаев одинаковы, отличия только в деталях. И используй IDE, которая умеет анализировать код и быстро переходить к нужному методу в коде. Тогда ты сможешь быстро перемещаться по коду и не терять нить рассуждений.

 

[Духовность™]

Только гоните от себя мысли типа "блин тут всё надо переделать"

у меня нет таких мыслей.

Успокойтесь и разбирайтесь.
Всё будет нормально.

Вот в том то и вопрос - как правильно разбираться? Допустим, есть задача в контексте большой системы. Её нужно решить, это понятно. Но решение задачи требует понимания того, как эту задачу решать. Ведь что бы починить двигатель у автомобиля, надо знать, как он работает, т.е. потратить время на изучение устройства. В контексте профессии программиста и основываясь на своем опыте, зачастую времени на изучение просто НЕТ. И выходит, что нужно что-то делать без понимания того, как это работает, на какой архитектуре.

 

[Adelf]

Духовность™
Никто тебя не посадить за совершенно незнакомую систему и не станет требовать решение задач за короткие сроки. Адекватный заказчик понимает такие вещи. Все будет ок.

 

[tz-lom]

Как работать с чужими библиотеками:
0- документация.
1- примеры. Обычно они таки есть,если нету,но библиотека используется в каком - то опенсорсе, можно лезть туда за примерами.
2- интерфейсы. Публичные методы, функции и комментарии -- единственное что вас должно интересовать, остальное позволяет понять как работает библиотека но не как с ней работать.
3- мелкими шажками. Написать всё сразу и чтобы завелось - нереально, надо отталкиваться от чего то (пускай даже от пустого файла) и делать маленькое изменение которое чуть-чуть приближает к результату,и контролировать что получается. То же и с непонятным модулем, если неизвестно как им воспользоваться то лучше написать какой нибудь тест как он работает, чем сразу пытаться его использовать.

 

[iceman]

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

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

надеюсь тебе повезет больше, если там хотябы предназначение библиотеки комментируют и не шпигуют все в одну либу - типа utils xDDD у нас тут вообще голый текст, понимаешь суть работы по рассказам людей которые разрабатывали изначально эту систему.

самое главное начать )

 

[iceman]

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

 

[AmdY]

http://devconf.ru/offers/56
вот презенташка от lang-a, к сожалению это немного не твой случай, когда есть коробка

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

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

 

[Духовность™]

СТОП СТОП СТОП!

Я не говорил про какой-то код, который пишут в фирме "рога и копыта". Я вообще говоритл о коде, об opensource, например. Вот мне mangeto нужно осваивать будет, а я не знаю, с какого бока начать - она десятки мегов весит!

 

[AmdY]

Духовность™
бери и ковыряй ГОТОВЫЕ модули из дистрибутива + скачай генератор модулей с оф сайта.

 

[A1x]

я с этого начинал - http://www.magentocommerce.com/design_guide
потом это - http://www.magentocommerce.com/wiki/5_-_modules_and_development/0_-_module_development_in_magento/custom_module_with_custom_database_table