(доклад для конференции CodeFest 2011г)
Этот доклад будет интересен широкому кругу специалистов: от инженеров-программистов и программных архитекторов, интересующихся, как ещё улучшить качество кода и облегчить работу с ним себе и своим коллегам, до менеджеров проектов и других менеджеров, желающих лучше понять своих подопечных.
В докладе указывается, что на ряду с общеизвестными формальными подходами повышения качества кода и эффективности работы группы программистов существует ещё один подход, основанный на «встраивании» правильных убеждений каждому разработчику в рамках проекта — Правильных Убеждений касательно конструирования кода.
Правильные Убеждения должны следовать архитектуре продукта и поддерживать её. Они могут не разделяться всеми членами команды, но вытекающие из них преимущества должны быть очевидны всем. Убеждения подобно паттернам проектирования могут иметь короткие запоминающиеся имена, с тем чтобы разработчики могли аппелировать к ним во время технических обсуждений.
В докладе с примерами приложения описаны пять таких Правильных Убеждений, транслируя которые, автор достаточно комфортно себя чувствует, успешно координируя процесс разработки в условиях постоянно изменяющихся требований к продукту и отсутствия достаточных ресурсов на работу с проектной документацией.
Вот эти простые убеждения:
«Правило прикрытой жопы»;
«Безобразно, но единообразно»;
«Разделяй и властвуй»;
«Будь проще»;
«Зачем?».
9. * убеждения
Почему хорошо?
Меньше кода → проще менять → гибкость
Почему хорошо?
Меньше кода → проще менять → гибкость
Цели Архитектуры:
стабильность, гибкость
Цели Архитектуры:
стабильность, гибкость
Что хорошо?
Меньше кода — хорошо!
Проще читать — супер!
Что хорошо?
Меньше кода — хорошо!
Проще читать — супер!
Проблема некоторых проектов - это то, что при их старте никто не знает, что получится в конечном итоге: то ли загородная дача, то ли многоэтажный бизнес центр.
Нередко получается, что через пять лет после выхода в свет имеем домик в деревне, из палисадника которого периодически стартует баллистическая ракета, хотя изначально закладывался ночной клуб.
В таких условиях понятия «правильной» с начала и до конца актуальной архитектуры ввиде строгого плана работ и чертежей не существует.
В такой ситуации, каждый разработчик должен быть максимально автономен в плане принятия решений.
Для этого необходимо, чтобы принимаемые им решения хотя бы не противоречили с такими же решениями коллег.
Этому может способствовать общий взгляд на архитектуру, который в свою очередь может поддерживаться общими ценностями и убеждениями.
Для таких непростых проектов характерны следующие явления:
Код очень сложно поддаётся восприятию
Часто возникают споры между разработчиками о целесообразности применения того или иного подхода
Код быстро захламляется «важными» функциями и методами, которые могут даже дублировать друг друга.
Для начала определимся с терминами.
Что будет считаться Убеждением в данном докладе.
Ценности постулируются Архитектурой.
Для Архитектуры ценно то, что позволяет удовлетворить определённым критериям качества. (Ценностные убеждения)
Одному и тому же критерию можно удовлетворить с использованием разных подходов. Архитектура постулирует, какие из этих подходов «Правильные». (Методологические убеждения)
«Методологические убеждения» поддерживаются посредством «Причинно-следственных Убеждений» с «Ценностными Убеждениями».
***
Убеждение должно имень наименование короткое, либо эмоционально окрашенное, с тем чтобы быстрее «усваиваться»
Для начала определимся с терминами.
Что будет считаться Убеждением в данном докладе.
Иногда случается, что разработчики начинают страдать острой степенью паранойи и манией преследования.
Вместо того, чтобы вызвать некоторую и просто воспользоваться его плодами, они начинают окружать её различными видами проверок, тем самым увеличивая количество бесполезного чтива..
«Правило Прикрытой Жопы» гласит:
Ожидайте от вызываемого вами кода того возвращаемого значения, которое декларируется его разработчиком.
Если вызываемый код возвращает не декларированное значение : удостоверьтесь, что этот код будет исправлен.
«Антиправило Прикрытой Жопы» гласит:
Попробуйте интерпретировать все значения, которые может вернуть вызываемый код, и преобразовать их в «правильные».
В будущем это замаскирует возможную ошибку и захламит код не постижимыми человеческим разумом проверками.
Пример на следующем слайде.
Единый Coding Style в рамках одного проекта:
Код проще для восприятия
Меньше времени тратится на прочтение
Единый подход к решению определённого класса задач.
Общее квадратное колесо используемое везде, где требуется колесо в проекте, сокращает время на поддержку овальных, круглых и пр. колёс, которые могли бы существовать в проекте — сокращаем базу кода, а, следовательно, повышаем гибкость и устойчивость продукта к ошибкам программирования.
Одинаковые команды «Левой, левой, раз два три»
Человеку свойственно наделять слова неким смыслом исходя из своего прежнего опыта.
Чем лучше слово подкреплено предыдущим успешным опытом, тем проще человеку читать — не приходится задумываться о значении каждого слова.
Так и при конструировании кода: каждое слово должно встречаться в единственном свойственном только ему контексте. Тогда программисты быстрее усваивают, что оно означает, и на чтение кода начинает уходить меньше кода.
Примеры: именование переменных, методы именования классов, функций и т.д.
Один из способов сохранять готовность к модификации — это разделить систему на относительно независимые подсистемы
Не всегда удаётся удержать границы между подсистемами.
Искусственные границы помогут отцу русской демократии:
Интерфейсы, псевдоязыки, физическое разделение.
Разные разработчики на смежных подсистемах.
Искусственные границы дают минимальную гарантию, что подсистемы не диффундируют друг в друга и будут оставаться относительно независимыми, а следовательно не будут сильно зависеть от других подсистем и их изменениями.
В "грязном" коде кто-то может увидеть:
Большую гибкость и, следовательно, возможность лучше подстроиться под нужды заказчика.
Возможность сделать фичу быстрее, чем если бы вы пытались сделать её по Феншуй
Возможность реализовать решение в парадигме отличной от ООП
Если в вашем замечательном проекте ещё нет "грязного" кода и прочих ugly hacks - непременно предусмотрите места для них, пока они не стали появляться спонтанно в неожиданных местах.
Это Убеждение естественно вытекает из предыдущего.
Одна из заповедей скаута: Скаут — Друг Природы!
Это значит, что скаут после привала оставит лесную полянку чище, чем до привала.
NOTE: Впрочем, это совсем не значит, что нужно останавливаться только на самых грязных полянках.