Мастерство программирования

Хочу сказать спасибо всем, кто дал отзыв в первой части статьи «Рефакторинг для начинающих». Особенно спасибо Yury Veretelnikov, за его (в большинстве случаев) справедливую критику, которая открыла мне глаза на проблемы в оформлении и написании статьи.

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

Кратко содержание:

• Цель рефакторинга
• Простые и сложные методы рефакторинга
• Когда начинать рефакторинг?
• Как начать рефакторинг?
• Как не поломать рабочий код?
• Когда рефакторинг не нужен?
• Каталог методов рефакторинга и примеры рефакторинга

А теперь кратко по каждому пункту.

Цель рефакторинга

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

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

Простые и сложные методы рефакторинга

Простые методы рефакторинга — это базовые, фундаментальные методы применяемые в рефакторинге. Например это: выделение метода, перемещение поля класса, выделение класса, переименование метода, класса или поля и т.д.

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

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

Когда начинать рефакторинг?

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

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

Применяйте рефакторинг при разборе кода. Разбор кода это хорошая практика, когда в команде разработчиков, разработчики проверяют код друг друга.

Как начать рефакторинг?

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

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

Как не поломать рабочий код?

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

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

Когда рефакторинг не нужен?

Иногда рефакторинг не нужен. Например, когда надо переписать программу с нуля. Иногда имеющийся код настолько запутан, что подвергнуть его рефакторингу, конечно, можно, но проще начат все с самого начала.

Явный признак необходимости переписать код — это его неработоспособность. Это обнаруживается при его тестировании, когда ошибок так много, что сделать код устойчивым не удается.

Другой случай, когда следует воздержаться от рефакторинга, это близость даты завершения. Однако приближение срока окончания работ — единственный случай, когда можно отложить рефакторинг, ссылаясь на недостаток времени.

Каталог методов рефакторинга и примеры рефакторинга

Большой каталог методов рефакторинга можно найти на refactoring.com вместо примеров кода, тут применяются примеры на языке UML.

Также, хороший каталог методов рефакторинга можно найти на wikipeadia, каждый метод снабжен примером на C#.

В заключении

Применение методов рефакторинга требует от вас: хорошего знания ООП, умение писать тесты, быть терпеливым делая рефакторинг небольшими шагами, проверять каждый шаг и постоянно учиться.

Рефакторинг - это реорганизация существующего кода без изменения функциональности.

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

Вот 7 хороших советов для проведения рефакторинга:

1. Всегда выполняйте рефакторинг короткими шагами с перерывом на перекомпиляцию и запуском тестов. Чем меньше ваши шаги, тем лучше вы локализуете потенциальные ошибки и тем быстрее вы их устраните. То, что ошибки будут можно не сомневаться. ;-)
2. Проводите рефакторинг снизу вверх, особенно, если у вас длинная и запутанная цепочка наследования классов. Старайтесь всегда сначала производить изменения в потомственных классах, прежде чем приступать к базовым классам.
3. Вы должны знать основные методы рефакторинга, для этого советую вам купить книгу Мартина Фаулера - “Рефакторинг”.
4. У вас всегда должна быть цель с которой вы производите рефакторинг, не делайте его там где он не нужен или только, если это не первоочередная задача. Чем лучше вы понимаете зачем вы это делаете, тем качественнее будет результат.
5. Не увлекайтесь рефакторингом, рефакторинг не добавляет функционала в программу, поэтому и каких либо видимых результатов вы также не получите. Делайте перерывы для того, чтоб сделать, что то, что можно увидеть и оценить. Тогда ваш начальник будет вами доволен. :)
6. Любой вид рефакторинга можно сделать за 5, 20 минут, максимум за один час. Но в основном рефакторинг является комплексной задачей, которая может выполняться в течении недель или месяцев над действующим проектом. Идея в том, что двигаться нужно постепенно и небольшими шагами, и возможно уделяя этому не больше одного часа в день. Это хороший метод рефакторинга, потому как не занимает много времени и убедить начальство в необходимости будет намного проще, ведь 1 час это так мало, не так ли?
7. В долгосрочной перспективе у вас будет красивый и легко сопровождаемый код, код который написан для людей, а не для машин, код которым вы можете гордиться и показывать в пример, код который работает так как вы этого хотите, и все это за невысокую цену рефакторинга!

Перевод статьи: “14 Ways to Learn From Creative Programmers“
- LifeDev.net

Фото от morganglines

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

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

И вот почему:

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

Программисты должны найти креативное решение задачи, иначе они ее не решат.

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

1. Выучите новый язык

Программисты постоянно учат новые языки, иногда просто ради развлечения, а иногда по надобности. Не ограничивайте себя только тем, что вы сейчас знаете. Развивайте себя и повышайте свои знания.

2. Начните с самого начала

Если вы собираетесь начать писать программное обеспечение, то вы не можете начать с половины проекта. Вы должны начать с самого начала. Иногда начать сначала это лучший путь найти креативное решение проблемы.

3. Спрашивайте про все

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

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

4. Делайте это ради развлечения

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

Постоянное сочетание новых идей и решений, никак не может быть нудной работой.

5. Постоянно проверяйте новые идеи

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

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

6. Найдите страсть

Если вы когда-либо разговаривали в течении нескольких минут с программистом о его работе, то вы наверное очень скоро заметили, что программисты имеют страсть к тому, что они делают.

А у вас есть страсть к вашим идеям и проектам?

7. Мастер своего дела

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

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

8. Начните думать абстрактными ассоциациями

1. Что если использовать компьютер как телефон?
2. Что будет, если использовать веб-сайт как Word процессор?
3. Что если люди будут озабочены тем, что делают сейчас другие люди?

Люди стоящие за Skype, Google и Twitter схожи в одном: Они все использовали абстрактные ассоциации. Предполагая, “что-если”, и тестируя это - лучший способ начать думать по-другому, в более креативном свете.

9. Думайте о границах как о помошнике, а не как о ограничениях

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

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

10. Не начинайте руководить чем либо, пока сами это не попробуете

Ваш учитель был прав: Нет ничего хуже чем глупый вопрос. Если вы будете придерживаться #3 и даже проверите все предположения, то вы все равно не сможете быть уверенными будет это работать или нет, пока сами не попробуете. Как вы узнаете, что это не работает, пока не попробуете? Вы удивитесь! Но, даже если предложенное решение не работает, то это все равно может помочь вам найти правильное решение.

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

11. Всегда, всегда ищите более простое и более элегантное решение

Хороший программист понимает, что поиски простого решения всегда ведут к хорошим результатам. Сложные решения ведут… к сложностям. Применяя это к программированию всегда дает хороший результат в перспективе.

Наши идеи иногда становятся очень сложными. Мы пытаемся схватится за новую идею игнорируя, что она из себя на самом деле представляет. Самое простое решение проблемы, обычно всегда самое лучшее.

12. Не бойтесь использовать чужой код

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

Воплощая новую идею в жизнь, не означает, что вы должны начинать с чистого листа. Используйте существующие идеи и создавайте на их основе что то лучшее. Иногда хорошая идея, это изменение существующей, которая уже была сделана. Gmail хороший тому пример. Они “переизобрели” email добавив удобные возможности к традиционному email.

13. Не бойтесь сотрудничать

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

14. Двигайтесь малыми шагами к большой цели

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