Comments 43
грамотные специалисты, рефакторинг кода
рефакторинг на крупных проектах в 90% случаев зло
Смотря что вы понимаете под рефакторингом. Фаулер монимает под ним примерно следующее: Если нужно дабавить новую фишку и небольшое изменение в структуре класса поможет её сделать более правильно или упростит код, то нужно сделать изменение; или ты фиксишь багу в методе и видишь, что он очеь большой, то раздели метод на части. А перелапачивание всего кода — это зло согласно самой же методологии.
Правильно проводимый рефакторинг не может быть злом ни в одном проекте. Он может быть экономически невыгодым при определённых условиях, но пользу всё-равно приносит немалую.
Если рефакторинг проводится небольшими шагами, а проект покрыт тестами то рефаторинг
безопасен.
Если рефакторинг проводится небольшими шагами, а проект покрыт тестами то рефаторинг
безопасен.
именно так!
Ой блин)))) понеслась))) Ну давайте уже хоть обосновывайте Ваши минусы) Я вам говорю про то, что рефакторинг на КРУПНЫХ проектах в большинстве случаев не уместен в силу того, что в КРУПНЫХ компаниях огромная текучка. Допустим, пришел кто-то написал какой-то ответственный кусок кода, и, кроме этого человека никто точно не знает как-там все внутри работает. Многие исходят из того, что «работает и не трогай» и в большинстве случаев они правы, т.к. этому есть несколько обоснований:
1) Экономическое. Рефакторинг очень затратное мероприятие. Вы сами бы стали рефакторить свой работающий на полную мощность проект?
2) Лень программистов. Рефакторинг ОБЫЧНО начинается за здравие, кончается за упокой.
3) Тянучка времени и башорг зависимость. Время в БОЛЬШИНСТВЕ случаев тратится абсолютно не рационально ( в принципе из этого и вытекают первый и второй пункты).
Есть возражения?
1) Экономическое. Рефакторинг очень затратное мероприятие. Вы сами бы стали рефакторить свой работающий на полную мощность проект?
2) Лень программистов. Рефакторинг ОБЫЧНО начинается за здравие, кончается за упокой.
3) Тянучка времени и башорг зависимость. Время в БОЛЬШИНСТВЕ случаев тратится абсолютно не рационально ( в принципе из этого и вытекают первый и второй пункты).
Есть возражения?
есть…
у меня не маленький проект и он рефакторится. Если я могу сделать тоже самое, но новый код будет работать быстрее и лучше, то почему бы этого не сделать?
> 1) Экономическое. Рефакторинг очень затратное мероприятие. Вы сами бы стали рефакторить свой работающий на полную мощность проект?
а никто не говорит, что нужно делать сразу рефакторинг всего проекта. Можно кусками
> 2) Лень программистов. Рефакторинг ОБЫЧНО начинается за здравие, кончается за упокой.
это плохой менеджмент и мотивация работников. это разговор для отдельной темы
> 3) Тянучка времени и башорг зависимость. Время в БОЛЬШИНСТВЕ случаев тратится абсолютно не рационально ( в принципе из этого и вытекают первый и второй пункты).
см ответ на пункт 2
у меня не маленький проект и он рефакторится. Если я могу сделать тоже самое, но новый код будет работать быстрее и лучше, то почему бы этого не сделать?
> 1) Экономическое. Рефакторинг очень затратное мероприятие. Вы сами бы стали рефакторить свой работающий на полную мощность проект?
а никто не говорит, что нужно делать сразу рефакторинг всего проекта. Можно кусками
> 2) Лень программистов. Рефакторинг ОБЫЧНО начинается за здравие, кончается за упокой.
это плохой менеджмент и мотивация работников. это разговор для отдельной темы
> 3) Тянучка времени и башорг зависимость. Время в БОЛЬШИНСТВЕ случаев тратится абсолютно не рационально ( в принципе из этого и вытекают первый и второй пункты).
см ответ на пункт 2
Ё-моё))) Ваш ответ не уместен… Вы единственный разработчик своего проекта, поэтому я согласен с Вашим подходом. Я же говорю про КРУПНЫЕ проекты, где сотни разработчиков или хотя бы десятки. Там лапши из кода гигабайты!!! Я работал во многих крупных проектах и ни один из них не отличался простотой подхода к написанию и про порядок в коде.
Еще раз подчеркиваю, я говорю про бредовость рефакторинга крупных проектов.
Еще раз подчеркиваю, я говорю про бредовость рефакторинга крупных проектов.
помимо всего прочего, клиенты как правило не хотят платить за рефакторинг, многие из них далеки от IT поэтому не понимают зачем нужно что-то делать с рабочим кодом. Поэтому «навязать» нетехнчески-подкованному клиенту рефакторинг достаточно сложно.
вообще сабж конечно не об этом, но если уж на то пошло, то качественный код — это то, что вы должны отдать клиенту как результат работы.
поэтому либо пишите его сразу либо делайте рефакторинг
поэтому либо пишите его сразу либо делайте рефакторинг
>то качественный код — это то, что вы должны отдать клиенту как результат работы.
Безусловно. Но не всегда Вы пишете проект от начало до конца. Даже наоборот построю фразу — в основном вам приходится работать с уже существующим, исторически сложившимся кодом. В большинстве своем деньги сейчас платят за саппорт.
И как правило, именно, проекты, которые существуют продолжительное время нужно рефакторить, скажем из-за увеличения числа пользователей на них, и как следствие старая архитектура не справляется с новой нагрузкой.
Безусловно. Но не всегда Вы пишете проект от начало до конца. Даже наоборот построю фразу — в основном вам приходится работать с уже существующим, исторически сложившимся кодом. В большинстве своем деньги сейчас платят за саппорт.
И как правило, именно, проекты, которые существуют продолжительное время нужно рефакторить, скажем из-за увеличения числа пользователей на них, и как следствие старая архитектура не справляется с новой нагрузкой.
> старая архитектура не справляется с новой нагрузкой.
а вот что до этого, то надо перед тем как браться проанализировать и сказать заказчику:
-хотите качество, то надо менять архитектуру, делать рефакторинг и тд и тп. хотите говно? простите, но мы гавно делать не будет и браться за такой проект тоже
а вот что до этого, то надо перед тем как браться проанализировать и сказать заказчику:
-хотите качество, то надо менять архитектуру, делать рефакторинг и тд и тп. хотите говно? простите, но мы гавно делать не будет и браться за такой проект тоже
Багтрекер (и «фичетрекер»). Хотя, наверняка уже используете.
Ещё можно использовать какие-нибудь средства непрерывной интеграции, которые тоже косвенно могут улучшить качество, вернее облегчить контроль за ним. При автоматической сборке можно запускать автоматизированные тесты, вычислять метрики кода, проверять исходный текст на код стайл.
Есть, например, phpUnderControl облегчающий использование CruiseControl с php:
www.phpundercontrol.org/about.html
Есть, например, phpUnderControl облегчающий использование CruiseControl с php:
www.phpundercontrol.org/about.html
Тут ещё недавно видел презентацию Бергмана о quality assurance. Там он, конечно, рассказывает о своём PHPUnit, его интеграции с Selenium и немного о phpUnderControl.
sebastian-bergmann.de/archives/804-Quality-Assurance-in-PHP-Projects.html
sebastian-bergmann.de/archives/804-Quality-Assurance-in-PHP-Projects.html
Я возможно выскажу странную мысль, но:
«Идеальный код — миф»
Поэтому не совсем понятно, что понимает автор под «повысить качество кода». Данный вопрос нуждается в уточнении.
Повышаем относительно чего? Какая цель? Почему требуется улучшение? Кто в команде разработчиков? Насколько качественный код умеют писать текущие разработчики? Смогут ли они улучшенный код поддерживать также, как и текущий?
На все эти вопросы я пока не нахожу ответа, поэтому нельзя ответить на вопрос о повышении качества кода.
«Идеальный код — миф»
Поэтому не совсем понятно, что понимает автор под «повысить качество кода». Данный вопрос нуждается в уточнении.
Повышаем относительно чего? Какая цель? Почему требуется улучшение? Кто в команде разработчиков? Насколько качественный код умеют писать текущие разработчики? Смогут ли они улучшенный код поддерживать также, как и текущий?
На все эти вопросы я пока не нахожу ответа, поэтому нельзя ответить на вопрос о повышении качества кода.
Хочу еще отметить, что повышение качества кода ради самой идеи — пустой звук. Можно «улучшить» так, что потом только избранные будут понимать, что в нем написано. Лучше всего ориентироваться на принцип KISS.
1. повышаем относительно того, что есть
2. цель — сделать проект быстрее, лучше, оптимизированнее, выбросить лишнее и добавить нужное
3. требуется потому, что в данный момент видны прорехи, в некоторых местах написаны хаки нашими программистами, некоторые куски кода просто лишние
4. в команде разработчиков один тим лидер с хорошей квалификацией, и 2 человека junior developer
5. насколько код качественный? сложно сказать, мерить просто нечем
6. улучшенный код смогут поддерживать, даже если для этого придется поднять квалификацию текущих и нанят еще junior developer :))
2. цель — сделать проект быстрее, лучше, оптимизированнее, выбросить лишнее и добавить нужное
3. требуется потому, что в данный момент видны прорехи, в некоторых местах написаны хаки нашими программистами, некоторые куски кода просто лишние
4. в команде разработчиков один тим лидер с хорошей квалификацией, и 2 человека junior developer
5. насколько код качественный? сложно сказать, мерить просто нечем
6. улучшенный код смогут поддерживать, даже если для этого придется поднять квалификацию текущих и нанят еще junior developer :))
> 1. повышаем относительно того, что есть
А что есть?
>2. цель — сделать проект быстрее, лучше, оптимизированнее, выбросить лишнее и добавить нужное
А вдруг улучшив код, проект станет тормознее? Такое ведь тоже может быть. Например ООП код на пхп на 20% приблизительно работает медленнее аналогичного функционального кода. Однако этим принебрегают для удобства поддержки и дальнейшей разработки. У Вас какой случай? Скорость и удобство разработки проекта — лежат обычно по разным полюсам.
Насчет выбросить лишнее — тоже не совсем понятно, как вы собираетесь определять это самое лишнее?
>3. требуется потому, что в данный момент видны прорехи, в некоторых местах написаны хаки нашими программистами, некоторые куски кода просто лишние
Это как? Как вы определили, что куски кода лишние? Происходит дублирование кода? Или код вообще не используется? Насчет хаков — убрать хаки, сделать нормально, тут ничего другого предложить обычно нечего.
>5. насколько код качественный? сложно сказать, мерить просто нечем
Вот с этого и надо начинать. Тобишь с code review, чтобы определить степень запущенности кода и пути его улучшения. А как можно советовать вам что-то по поводу улучшения кода, если вы даже текущее положение дел не можете оценить (или еще не успели этого сделать?).
А что есть?
>2. цель — сделать проект быстрее, лучше, оптимизированнее, выбросить лишнее и добавить нужное
А вдруг улучшив код, проект станет тормознее? Такое ведь тоже может быть. Например ООП код на пхп на 20% приблизительно работает медленнее аналогичного функционального кода. Однако этим принебрегают для удобства поддержки и дальнейшей разработки. У Вас какой случай? Скорость и удобство разработки проекта — лежат обычно по разным полюсам.
Насчет выбросить лишнее — тоже не совсем понятно, как вы собираетесь определять это самое лишнее?
>3. требуется потому, что в данный момент видны прорехи, в некоторых местах написаны хаки нашими программистами, некоторые куски кода просто лишние
Это как? Как вы определили, что куски кода лишние? Происходит дублирование кода? Или код вообще не используется? Насчет хаков — убрать хаки, сделать нормально, тут ничего другого предложить обычно нечего.
>5. насколько код качественный? сложно сказать, мерить просто нечем
Вот с этого и надо начинать. Тобишь с code review, чтобы определить степень запущенности кода и пути его улучшения. А как можно советовать вам что-то по поводу улучшения кода, если вы даже текущее положение дел не можете оценить (или еще не успели этого сделать?).
> А что есть?
есть текущий работающий проект
> У Вас какой случай?
у нас случай когда нужно найти баланс между скоростью и удобством — вот ищу средства
> Происходит дублирование кода?
иногда, поэтому такое надо выявлять и убирать (иногда пытаются даже 2 инстанса класса приделать)
> Или код вообще не используется?
и такое бывает — тоже нужно искать
> убрать хаки, сделать нормально, тут ничего другого предложить обычно нечего.
само собой — но их же найти еще надо ;)
> Тобишь с code review, чтобы определить степень запущенности кода и пути его улучшения
опять же метрики кода как такой нет, либо я просто не знаю о ней.
да есть архитектура продуманная довольно таки отлично как нам кажется. да есть хорошо написанный код — быстрый и гибкий. но всплывают места где код можно переписать еще быстрее, а можно переделать по-другому и он будет более гибким — вот их и надо найти и улучшить
есть текущий работающий проект
> У Вас какой случай?
у нас случай когда нужно найти баланс между скоростью и удобством — вот ищу средства
> Происходит дублирование кода?
иногда, поэтому такое надо выявлять и убирать (иногда пытаются даже 2 инстанса класса приделать)
> Или код вообще не используется?
и такое бывает — тоже нужно искать
> убрать хаки, сделать нормально, тут ничего другого предложить обычно нечего.
само собой — но их же найти еще надо ;)
> Тобишь с code review, чтобы определить степень запущенности кода и пути его улучшения
опять же метрики кода как такой нет, либо я просто не знаю о ней.
да есть архитектура продуманная довольно таки отлично как нам кажется. да есть хорошо написанный код — быстрый и гибкий. но всплывают места где код можно переписать еще быстрее, а можно переделать по-другому и он будет более гибким — вот их и надо найти и улучшить
> Например ООП код на пхп на 20% приблизительно работает медленнее аналогичного функционального кода.
Поправочка #1: «процедурного», не функционального.
Поправочка #2: откуда данные про 20%?
Поправочка #1: «процедурного», не функционального.
Поправочка #2: откуда данные про 20%?
Ну немножко нечестно сравнивать скорость ООП и процедурного кода. 20% только выглядит серъёзной цифрой. В реальности основную нагрузку дадут тяжёлые вычисления (а они в веб проектах не часто бывают) и, конечно, внешние ресурсы (база данных и т.д.). Ну ещё инклуды зависимых пхп файлов дают самые значительные после БД тормоза (Zend Framework хороший пример). На фоне всего этого разница ООП и процедурного стиля само по себе не может много значить, чтобы оправдывать код, который сложнее поддерживать.
UFO just landed and posted this here
как бы да, но как отличить быдло код от качественного? на субъективной основе? вот это мне нравится, а это нет — значит это хорошее, а то это плохое?
я так понимаю качество кода оценивается по его быстродействию и гибкости. но где критерии? как оценивать?
вот что еще интересует — методики оценивания
я так понимаю качество кода оценивается по его быстродействию и гибкости. но где критерии? как оценивать?
вот что еще интересует — методики оценивания
Только субъективно. Я уже писал — идеального кода — нет. Это миф. Поэтому все понятия о коде — это чисто субъективные вещи. Причем это актуально не только для пхп, но и для других языков…
ну если субъективно то наш код на 80% где то хороший и полностью удовлетворяет нашим потребностям и документам. Осталось 20% «найти и починить»
Я об этом и говорю. Что Вам нужно провести ревью кода и определить проблемные места. Возможно даже каждый разработчик отметит проблемные места на его взгляд и сложением всех мнений в одно — сделать встречу, где и обсудить все, что каждый увидел и таким образом выработать общую стратегию улучшения кода.
Как вариант.
Как вариант.
UFO just landed and posted this here
SimpleTest для тестирования кода.
Как альтернатива траку можно Redmine (http://www.redmine.org/) попробовать. Концептуально они близки (хотя редмайн пофункциональнее «out-of-box»), но редмайн мне удобнее кажется.
Sign up to leave a comment.
SQA в PHP