-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Опять про поддержку чужого кода
- Автор темы Духовность™
- Дата начала
Много времени, нет сил - подходишь и говоришь, эта работа стоит больше на 1000 у.е., мне нужна премия и сроки. А потом пойдешь и отдохнешь))
Причина тут одна - не достаточность знаний или нежелание работать (или отсутствие отпуска например). Извиняюсь, если конечно что-то не так сказал, или грубо, то это IMHO.
> Вот, есть потребность добавить модуль в систему. Для
> этого в системе предусмотрен якобы какой-то функционал,
А посмотреть в аналогичных модулях (других). Если есть API, то оно будет там использваться. Копи паст -замена под нужны и не вдумываться как там что работает писать следующую строчку.
Если нужно написать модуль, берешь модуль, копируешь, переименовывешь и переделывашь, не задумываясь о том, как там в системе все устроено.
У системы (будь это говоногод или еще что-нибудь) есть всего три задачи - обработать полученные данные, связаться с бд, отдасть контент.
А значит из всей системы тебе будут нужны функции обработки вх. данных, функции БД, шаблонизатор, остальное - дело системы.
Система передает вх. данные - ты их берешь, далее обрабатывашь (любым способом, можно и не используя API), работаешь с базой данных (не понятно как - берешь логин и пароль из конфигов и через стандарные функции или свои классы делаешь запросы), шаблонизатору передаешь переменные, а дальше - не твоя проблема, а верстальщика.
Есть вопрос по правам (например), ищишь по тексту, где употребляется таблица "users" и смотришь API. Начинаешь писать, проблема - поиск по файлам. Мне способом "аналогии" хватает часа, для того, что бы уже начать писать, во время написания - поиск в сорцах по названием таблиц - спасает много времени и нервов.
Изучить структуры БД - нужно до приступания к кодингу.
>Я бы начал с поиска автора кода
Зачем? Морду ему набить? )) Он не будет ничего объяснять (а там пояснять нужно долго т.е. тратить время, за которое можно деньги заработать) и тем более делать работу за других.
Разок (месяца 4 назад) вообще как-то платили 200 штук за то, что бы доработать проект одного хорошего (т.е. расскрученного) интерент магазина (убрать дикие тормаза сайта и часть глюков). Поставил счетчик запросов и ужаснулся - 700 запросов к бд на один товар, пошарился в коде - жесть. HTML в PHP, одни функции ни каких классов, SQL иньекции на каждом шагу, да еще и Registr Global On и т.п., открыл план работ, окна нет - отказался. Как выяснилось проект писало 5-человек по очереди. Такой п...ц был. Но как это работает я все таки изучил. Предложил им все сначала писать в нормальной фирме без участия студентов. Если у тебя что-нибудь подобное - не берись на доработку, поставь в известность руководство, обоснуй, нарисуй график работы и скажи, что бы этот проект предовали другим и все.
Причина тут одна - не достаточность знаний или нежелание работать (или отсутствие отпуска например). Извиняюсь, если конечно что-то не так сказал, или грубо, то это IMHO.
> Вот, есть потребность добавить модуль в систему. Для
> этого в системе предусмотрен якобы какой-то функционал,
А посмотреть в аналогичных модулях (других). Если есть API, то оно будет там использваться. Копи паст -замена под нужны и не вдумываться как там что работает писать следующую строчку.
Если нужно написать модуль, берешь модуль, копируешь, переименовывешь и переделывашь, не задумываясь о том, как там в системе все устроено.
У системы (будь это говоногод или еще что-нибудь) есть всего три задачи - обработать полученные данные, связаться с бд, отдасть контент.
А значит из всей системы тебе будут нужны функции обработки вх. данных, функции БД, шаблонизатор, остальное - дело системы.
Система передает вх. данные - ты их берешь, далее обрабатывашь (любым способом, можно и не используя API), работаешь с базой данных (не понятно как - берешь логин и пароль из конфигов и через стандарные функции или свои классы делаешь запросы), шаблонизатору передаешь переменные, а дальше - не твоя проблема, а верстальщика.
Есть вопрос по правам (например), ищишь по тексту, где употребляется таблица "users" и смотришь API. Начинаешь писать, проблема - поиск по файлам. Мне способом "аналогии" хватает часа, для того, что бы уже начать писать, во время написания - поиск в сорцах по названием таблиц - спасает много времени и нервов.
Изучить структуры БД - нужно до приступания к кодингу.
>Я бы начал с поиска автора кода
Зачем? Морду ему набить? )) Он не будет ничего объяснять (а там пояснять нужно долго т.е. тратить время, за которое можно деньги заработать) и тем более делать работу за других.
Разок (месяца 4 назад) вообще как-то платили 200 штук за то, что бы доработать проект одного хорошего (т.е. расскрученного) интерент магазина (убрать дикие тормаза сайта и часть глюков). Поставил счетчик запросов и ужаснулся - 700 запросов к бд на один товар, пошарился в коде - жесть. HTML в PHP, одни функции ни каких классов, SQL иньекции на каждом шагу, да еще и Registr Global On и т.п., открыл план работ, окна нет - отказался. Как выяснилось проект писало 5-человек по очереди. Такой п...ц был. Но как это работает я все таки изучил. Предложил им все сначала писать в нормальной фирме без участия студентов. Если у тебя что-нибудь подобное - не берись на доработку, поставь в известность руководство, обоснуй, нарисуй график работы и скажи, что бы этот проект предовали другим и все.
Wicked
Новичок
whirlwind
http://cachegrindvisualizer.googlecode.com/files/symfony_graph-gc1-ru-0.5.2.png - по-моему вполне должно давать представление
http://cachegrindvisualizer.googlecode.com/files/symfony_graph-gc1-ru-0.5.2.png - по-моему вполне должно давать представление
>>Изучить структуры БД - нужно до приступания к кодингу.
помогал недавно одной компании подобрать разработчика, в тестовом задании требовалось создать базу данных, а после поиск по ней.
ни одного претендента с правильно спроектированой бд не было.
сейчас все повёрнуты, на шаблонах, mvc и прочих паттернах, в итоге рождается заумный код, но при этом неудобный и глючный, соответственно невероятно трудный в поддержке и расширении.
-~{}~ 11.10.08 19:05:
Wicked
спасибо, интересная прога, обязательно попробую. по красоте графа можно судить о красоте кода.
помогал недавно одной компании подобрать разработчика, в тестовом задании требовалось создать базу данных, а после поиск по ней.
ни одного претендента с правильно спроектированой бд не было.
сейчас все повёрнуты, на шаблонах, mvc и прочих паттернах, в итоге рождается заумный код, но при этом неудобный и глючный, соответственно невероятно трудный в поддержке и расширении.
-~{}~ 11.10.08 19:05:
Wicked
спасибо, интересная прога, обязательно попробую. по красоте графа можно судить о красоте кода.
Angerslave
Новичок
Кстати, на хабре не так давно были несколько таких графиков - каждого фреймворка. Все, кроме ZF показали стройные деревья, у одного ZF это какая-то скорее паутина.
Вообще, мне эта прога не понравилась. Слишком узкое применение. Работает дольше всяких CacheGrind'ов, постоянно надо пересоздавать изображения, в общем постоянно профайлить по ней то ещё удовольствие. Зато очень чётко даёт понять, как устроена программа и где узкие места(хотя это даёт понять любой профайлер).
Вообще, мне эта прога не понравилась. Слишком узкое применение. Работает дольше всяких CacheGrind'ов, постоянно надо пересоздавать изображения, в общем постоянно профайлить по ней то ещё удовольствие. Зато очень чётко даёт понять, как устроена программа и где узкие места(хотя это даёт понять любой профайлер).
Baranov_Dron
Новичок
AmdY
"сейчас все повёрнуты, на шаблонах, mvc и прочих паттернах, в итоге рождается заумный код, но при этом неудобный и глючный, соответственно невероятно трудный в поддержке и расширении."
Ты так говоришь "повёрнуты", как будто это плохо. И почему, если применяется ООП, то сразу получается заумный, неудобный и глючный код?!
Заумный - вообще к коду мало применимо
Глючный - эту проблему должно устранить нормальные юнит и функциональные тесты.
Неудобный можно получить как с применением ООП, так и без.
"невероятно трудный в поддержке и расширении" - как раз таки одна из главных задач ООП сделать легко расширяемый(а нафига ещё наследование и полиморфизм нужны?!) и поддерживаемый код!
К сожалению я пока не вижу никакой моды к ООП в php, а ой как жаль...
"сейчас все повёрнуты, на шаблонах, mvc и прочих паттернах, в итоге рождается заумный код, но при этом неудобный и глючный, соответственно невероятно трудный в поддержке и расширении."
Ты так говоришь "повёрнуты", как будто это плохо. И почему, если применяется ООП, то сразу получается заумный, неудобный и глючный код?!
Заумный - вообще к коду мало применимо
Глючный - эту проблему должно устранить нормальные юнит и функциональные тесты.
Неудобный можно получить как с применением ООП, так и без.
"невероятно трудный в поддержке и расширении" - как раз таки одна из главных задач ООП сделать легко расширяемый(а нафига ещё наследование и полиморфизм нужны?!) и поддерживаемый код!
К сожалению я пока не вижу никакой моды к ООП в php, а ой как жаль...
>в итоге рождается заумный код, но при этом неудобный и глючный, соответственно невероятно трудный в поддержке и расширении
это как раз когда не ооп, а говно расфасованное по классам.
есть такое когда начитаются книжек и пихают паттерны абы было, не понимая зачем.
тут просто нужен опыт и понимание.
-~{}~ 11.10.08 20:45:
а, ну еще так может сказать человек привыкший говнокодить годами, мышление надо перестраивать это да =)
это как раз когда не ооп, а говно расфасованное по классам.
есть такое когда начитаются книжек и пихают паттерны абы было, не понимая зачем.
тут просто нужен опыт и понимание.
-~{}~ 11.10.08 20:45:
а, ну еще так может сказать человек привыкший говнокодить годами, мышление надо перестраивать это да =)
Baranov_Dron
Новичок
fixxxer согласен с твоей мессагой во всём.
Я при изучение различных фрэймворков бесился стандартам, которые они диктуют. Например расположение файлов. А потом понял, что у них есть свои весомые аргументы, которые сильнее моего гнева
Тоесть правила которые они диктуют и советуют в своих мануалах весьма правильны.
Тоесть если им следовать, то код даже в худшем случае будет понятен(хотя... опять же зависит от кривости рук программера). Может всё же правильно использовать фрэймворки(а они как правило поддерживают ООП технологию) и следовать их "правилам"?
Я при изучение различных фрэймворков бесился стандартам, которые они диктуют. Например расположение файлов. А потом понял, что у них есть свои весомые аргументы, которые сильнее моего гнева
Тоесть правила которые они диктуют и советуют в своих мануалах весьма правильны. Тоесть если им следовать, то код даже в худшем случае будет понятен(хотя... опять же зависит от кривости рук программера). Может всё же правильно использовать фрэймворки(а они как правило поддерживают ООП технологию) и следовать их "правилам"?
Baranov_Dron
Новичок
AmdY
Что именно поддерживать легче(в случае как у ТС кривого кода) - вопрос вообще спорный, да и есть ли смысл об этом спорить? Думаю нет.
Но ведь в ранних версиях всех языков(например язык старичок С) существовал только процедурный стиль. И потом только с течением времени и эволюции возник ООП. Может эволюция зря совершилась, раз есть люди которые считают, что это не нужно, так как сложно?!
Почему ООП код получается у новичков хуже, чем процедурный, да наверное потому, что сложнее и в процедурном стиле, говоря уже о PHP, дофига информации пережёванно по сотне раз. А о ООП информации куда меньше.
Но ООП призван делать понятный, легко расширяемый код. А такие техники программирования, как TDD должны обеспечить этому подходу устойчивый от ошибок код.
А кривые программисты(как и кривые строители, учители, доктора и т.д.) были, есть и будут всегда. От одного такого программиста и пострадал ТС.
Что именно поддерживать легче(в случае как у ТС кривого кода) - вопрос вообще спорный, да и есть ли смысл об этом спорить? Думаю нет.
Но ведь в ранних версиях всех языков(например язык старичок С) существовал только процедурный стиль. И потом только с течением времени и эволюции возник ООП. Может эволюция зря совершилась, раз есть люди которые считают, что это не нужно, так как сложно?!
Почему ООП код получается у новичков хуже, чем процедурный, да наверное потому, что сложнее и в процедурном стиле, говоря уже о PHP, дофига информации пережёванно по сотне раз. А о ООП информации куда меньше.
Но ООП призван делать понятный, легко расширяемый код. А такие техники программирования, как TDD должны обеспечить этому подходу устойчивый от ошибок код.
А кривые программисты(как и кривые строители, учители, доктора и т.д.) были, есть и будут всегда. От одного такого программиста и пострадал ТС.
С.
Продвинутый новичок
В веб программировании есть свои особенности по сравнению с десктопным приложении. Программа живет лишь доли секунд и выполняет за время своей жизни крохотную операцию. Поднимать весь комплекс объектов и связи между ними из которых реально будет использовано лишь 1% может оказаться просто глупо.
Baranov_Dron
перенося на врачей скажи, кого ты больше боялся бы:
плохого лора, который лечил бы слух
или плохого хирурга, делающего аперацию на сердце?
Здесь недавно пилот 911 вылаживал свой код, посмотри какие узоры понаплёл на ООП, но это ещё далеко не самый худший случай.
перенося на врачей скажи, кого ты больше боялся бы:
плохого лора, который лечил бы слух
или плохого хирурга, делающего аперацию на сердце?
Здесь недавно пилот 911 вылаживал свой код, посмотри какие узоры понаплёл на ООП, но это ещё далеко не самый худший случай.
