-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Опрос. Насколько вы понимаете код в своих продуктах
- Автор темы Фанат
- Дата начала
jonjonson
Охренеть
В чужом коде нужно копаться и разбираться, даже если вы его не собираетесь использовать.
Так же вспоминаются: 10 способов провалить потенциально успешный проект
Где первым пунктом идёт:
Есть правда конкретно для php другая проблема, а именно низкое качество доступного для использования чужого php кода.
Так же вспоминаются: 10 способов провалить потенциально успешный проект
Где первым пунктом идёт:
Безусловно, что это не прямая ссылка на использование чужого кода. Основой может стать собственный, отлаженный и проверенный временем. И всё же стоит использовать чужой код, а значит разбираться в нём. Причём не только в интерфейсе использования.
Есть правда конкретно для php другая проблема, а именно низкое качество доступного для использования чужого php кода.
Денч
Новичок
Использую один единственный чужой класс, слегка мной подправленный - XTemplate. Все остальное - мое
Ну плюс десятка три каких-то функций, которые надерганы откуда-то. Что-то склеено в "классы", большая часть так просто валяется.
За 2 года научился писать код, который легко читаю и понимаю. Давно не брался за PHP, вот открыл свою маленькую кривенькую цмц-ску, писанную для диплома. Неплохо читается, и понимается
Ну плюс десятка три каких-то функций, которые надерганы откуда-то. Что-то склеено в "классы", большая часть так просто валяется.
За 2 года научился писать код, который легко читаю и понимаю. Давно не брался за PHP, вот открыл свою маленькую кривенькую цмц-ску, писанную для диплома. Неплохо читается, и понимается
MiRacLe
просто Чудо
использую значительное кол-во пакетов PEAR, из них многие даже не пытаюсь понять (SpreadSheet::Writer, Mail::Mime и т.п.) - "чёрный ящик" в случае с незнакомым форматом[протоколом] меня вполне устраивает, т.е. понимание о том, что делает тот или иной объект 3rd-party класса имеется, а в детали его реализации лезу только в случае возникновения непредвиденных проблем(для того чтобы решить сиюминутную проблему и/или написать "грамотный" feedback разработчикам).
Как и Long обычно делаю "обёртки" над "непонятным кодом", чтобы в случае возникновения проблем замена его более понятным/вменяемым/заглушкой (что к счастью встречается не часто) не вызовет глобальных "архитектурных" перестроек.
С чужим кодом, который используется чаще чем раз в месяц знаком досконально (Smarty, отдельно взятые за задницу пакеты из PEAR и т.п.)
А оценить насколько больше/меньше кода написанного самостоятельно(и/или при моём непосредственном участии) сложно просто потому что "объём" PEAR::* + Smarty примерно равен объёму собственного кода, хотя роль последнего существенно важнее, а первый может быть относительно легко заменён другим (быть может более непонятным).
И как постскриптум - считаю изобретение велосипедов недостойным современного разработчика - Write Less, Do more.
Как и Long обычно делаю "обёртки" над "непонятным кодом", чтобы в случае возникновения проблем замена его более понятным/вменяемым/заглушкой (что к счастью встречается не часто) не вызовет глобальных "архитектурных" перестроек.
С чужим кодом, который используется чаще чем раз в месяц знаком досконально (Smarty, отдельно взятые за задницу пакеты из PEAR и т.п.)
А оценить насколько больше/меньше кода написанного самостоятельно(и/или при моём непосредственном участии) сложно просто потому что "объём" PEAR::* + Smarty примерно равен объёму собственного кода, хотя роль последнего существенно важнее, а первый может быть относительно легко заменён другим (быть может более непонятным).
И как постскриптум - считаю изобретение велосипедов недостойным современного разработчика - Write Less, Do more.
boombick
boombick.org
Ну это с какой стороны посмотреть... в ынтерпрайзе несомненно можно и нужно использовать готовый и _проверенный_ чужой код, дабы не отвлекаться на повторную реализацию тривиальных решений...
А вот для повышения собственного уровня профессионализма - велосипеды писать очень хорошо. Приходит понимание. А это главное =) Ведь потом будет легче решать собственные, уже необычные и узкоспециализированные задачи.
Все вышесказанное ИМХО.
Krishna
Продался Java
Фанат
На самом деле, вот это:
Еще точнее - понимать "логику программы" вовсе не означает разбираться в ней до последней строчки. У меня 90% опыта моей работы состояло и состоит в копании в чужом коде. Сначала я тоже ленился разбираться, но обстоятельства заставили. Потом привык и сейчас чтение кода вообще не напрягает, если конечно он не полное говно.
Для меня отладка чужой программы начинается с анализа схемы БД, как модели данных, анализа структуры кода (как правило, несложно читается исходя из файловой структуры исходников). Далее, анализируем стек вызовов от точки входа до собственно выдачи ошибочных данных (тут, при большом объеме кода хорошо помогают ф-ии навроде debug_backtrace() ) локализуем ошибку (смотрим какая ф-ия при верных параметрах возвращает неверные значения) и дело в шляпе. При правильно самодокументированном и структурированном коде это все вовсе несложно (в большинстве случаев), даже на гигантских скриптах.
Я, конечно, извиняюсь, что написал как для детей, но просто, имхо, слова "разбор чужого кода" рождает черезчур жуткие, по сравнению с действительностью, кошмары.
На самом деле, вот это:
крайне спорное утверждение. С моей точки зрения, так вообще абсурдное. Говоря проще - то что ты не умеешь отлаживать чужой код не значит, что это невозможно. Если отладить его без стопроцентного вникания невозможно - зачем тогда все пляски с читаемостью кода, инкапсуляцией, ООП подходом?
Еще точнее - понимать "логику программы" вовсе не означает разбираться в ней до последней строчки. У меня 90% опыта моей работы состояло и состоит в копании в чужом коде. Сначала я тоже ленился разбираться, но обстоятельства заставили. Потом привык и сейчас чтение кода вообще не напрягает, если конечно он не полное говно.
Для меня отладка чужой программы начинается с анализа схемы БД, как модели данных, анализа структуры кода (как правило, несложно читается исходя из файловой структуры исходников). Далее, анализируем стек вызовов от точки входа до собственно выдачи ошибочных данных (тут, при большом объеме кода хорошо помогают ф-ии навроде debug_backtrace() ) локализуем ошибку (смотрим какая ф-ия при верных параметрах возвращает неверные значения) и дело в шляпе. При правильно самодокументированном и структурированном коде это все вовсе несложно (в большинстве случаев), даже на гигантских скриптах.
Я, конечно, извиняюсь, что написал как для детей, но просто, имхо, слова "разбор чужого кода" рождает черезчур жуткие, по сравнению с действительностью, кошмары.
tf
крылья рулят
ручное составление запроса - бр, я конешно понимаю срань, но ведь ее всеже можно привести в ссоответвии стандарту, хотябы по минимуму и для начала и поставить на пятерку - правдо уйдет куча времени на переделку основ генерации xml (надо эту гадость кудато вынести отдельно), вроде вручную nusoap делает (если не изменяет пямять о беглом просмотре exsample), но все в ручную - бр
))
Krishna
Продался Java
Фанат
Ну да, но ты первый начал.
Истина, она где-то посередине и как правило, оптимальный выбор зависит от дополнительных обстоятельств, таких, как качество стороннего кода, объем функционала который надо реализовать и сроков сдачи. Собсно, на чем и закругляюсь по данному вопросу.
Ну да, но ты первый начал.
Истина, она где-то посередине и как правило, оптимальный выбор зависит от дополнительных обстоятельств, таких, как качество стороннего кода, объем функционала который надо реализовать и сроков сдачи. Собсно, на чем и закругляюсь по данному вопросу.
Я вообще ничего не начинал.
Я просто спросил - сколько. И всё.
чтобы было понятно, что я спрашиваю не про свой-чужой, а про знаю-не знаю что внутри, я добавил абзац про отладку. Но обязательно нашелся человек, которому дозарезу надо было доекопаться именно до него.
Я просто спросил - сколько. И всё.
чтобы было понятно, что я спрашиваю не про свой-чужой, а про знаю-не знаю что внутри, я добавил абзац про отладку. Но обязательно нашелся человек, которому дозарезу надо было доекопаться именно до него.
Santiago
Новичок
Фанат
По-возможности стараюсь использовать свои библиотеки и дописывать их по мере надобности/багфиксинга.
При работе в команде процент чужого кода сложно определить, т.к. многое зависит от проекта и от кол-ва участников.
С точки зрения программиста, конечно же, всегда интересней все написать самому. Т.к. процесс создавания чего-то нового и исследования новых технологий должен быть заложен у программиста в крови. Но реальность диктует немного другие условия, поэтому не всегда получается заниматься именно тем, чем ты хочешь и считаешь нужным, а в случае коммерческих проектов вопрос сроков стоит тоже не на последнем плане. Поэтому использовать все самописные решения на данном этапе не предсталвяется возможным. Хотя, я думаю, к этому стоит стремиться.
Положительно, если решения проверены времнем и/или написаны профессиональными разработчиками. Также, одним из условий их пременения является документированность.
Около 10%. В основном это шаблонизаторы, WYSIWYG-редакторы, библиотеки для работы с excel-файлами, phpmailer.
По-возможности стараюсь использовать свои библиотеки и дописывать их по мере надобности/багфиксинга.
При работе в команде процент чужого кода сложно определить, т.к. многое зависит от проекта и от кол-ва участников.
С точки зрения программиста, конечно же, всегда интересней все написать самому. Т.к. процесс создавания чего-то нового и исследования новых технологий должен быть заложен у программиста в крови. Но реальность диктует немного другие условия, поэтому не всегда получается заниматься именно тем, чем ты хочешь и считаешь нужным, а в случае коммерческих проектов вопрос сроков стоит тоже не на последнем плане. Поэтому использовать все самописные решения на данном этапе не предсталвяется возможным. Хотя, я думаю, к этому стоит стремиться.