ПРОМЫШЛЕННАЯ РАЗРАБОТКА ПО
Лекция 3. Особенности работы п рограммиста.
Часть 2. Совершенный код

О ЧЁМ БУДЕМ ГОВОРИТЬ СЕГОДНЯ?
Основные задачи программиста Специфика крупного проекта
Разработка
Написание
«правильной» Рефакторинг
«правильного» кода
архитектуры
Наиболее ценные навыки программиста
Три ступени роста программиста

ЭТО НУЖНО ЗАПОМНИТЬ!
Код, который пишет программист
• Может использоваться через
десятки лет
• Может использоваться
множеством других
программистов
• Может быть изменѐн до
неузнаваемости в новой
версии
• Может быть выброшен уже в
следующем релизе

НАПИСАНИЕ «ПРАВИЛЬНОГО» КОДА

СОВЕРШЕННЫЙ КОД
«Пишите код так, как будто сопровождать его
будет склонный к насилию психопат, который
знает, где вы живете»
Стив Макконелл

ЗАЧЕМ НУЖЕН ПРАВИЛЬНЫЙ КОД?
• Лѐгкость чтения и
понимания
• Эффективная
локализация ошибок
• Лѐгкое и точечное
добавление функций и
исправление дефектов
• Чѐткая структура кода
сильно влияет на
архитектуру

ПРИНЦИПЫ И ПРИЗНАКИ ХОРОШЕГО КОДА
• Единый стиль кодирования
• Читабельность кода
• Грамотные методы
• Правильные имена классов,
переменных и методов
• Минимально возможный объѐм
ветвлений и вложенности

ЕДИНЫЙ СТИЛЬ
• Договориться, как оформлять
исходный код
• Брать за основу стандарты для
соответствующей технологии
• Следить за отступами
• Договориться о наболевшем:
• Табуляция vs. Пробел
• Скобки на разных строчках
• Именование полей

ЕДИНЫЙ СТИЛЬ: СОВЕТЫ
• Префикс для скрытых полей:
“_”, “m_”,…
• Обязательные фигурные
скобки в ветвлениях и циклах
(даже если команда одна)
• Используйте соглашения даже
при написании «временного»
кода
• Помните, что у всех свои
представления о стиле
кодирования. Кому-то придѐтся
смириться.

ЧИТАБЕЛЬНОСТЬ КОДА
• Код должен читаться как книга
• Логические блоки должны быть
чѐтко выделенными и
понятными
• Названия классов, методов и
переменных должны быть
информативными
• В каждой строке должна быть
одна операция / вызов метода

ЧИТАБЕЛЬНОСТЬ КОДА: СОВЕТЫ
• Не жалейте пустых строк,
пробелов и табуляции
• Лучше, чтобы строчка влезала в
экран (80-90 символов).
• Современные языки
программирования игнорируют
перенос строк. Пользуйтесь этим
• Используйте стандартные отступы
(в ветвлениях, циклах, методах и
т.д.)
• Если у метода много аргументов –
расположите их на разных
строчках

КАЧЕСТВЕННАЯ ДЕКОМПОЗИЦИЯ
• Метод выполняет
единственную задачу
• Идеальный метод занимает не
больше 100 строк. Лучше 50
• Если метод принимает более 7
параметров – с ним что-то не
так
• Метод не меняет значения
входных переменных
• Метод грамотно назван (об
этом – позже)

КАЧЕСТВЕННАЯ ДЕКОМПОЗИЦИЯ: СОВЕТЫ
• Если для понимания кода
нужен комментарий «этот код
делает то-то», вынесите его в
отдельный метод
• Если идеальное имя метода
содержит союз «and», делите
его на два
• Цепочки из 50 вложенных
методов – тоже не слишком
хорошо. Помните про принцип
KISS
• Не нужно «искусственно»
делить метод на части

ПРАВИЛЬНЫЕ ИМЕНА
• Название в точности отражает
сущность
• Класс – существительное,
метод – глагол
• Названия не содержат общих
слов (PerformAction,
ObjectManager, myArray)
• Название не содержит цифр
(Action1, Action2, Action3)
• Называйте переменные
массивов во множественном
числе

ПРАВИЛЬНЫЕ ИМЕНА: СОВЕТЫ
• Если сложно сформулировать
имя для класса или метода,
вероятнее всего, у него слабое
зацепление (low cohesion). Его
нужно делить
• Даже временные переменные
надо называть правильно,
чтобы выработалась привычка
• Называйте переменные
терминами предметной
области
• Адекватная длина имени
переменной – 8-20 символов

МИНИМАЛЬНАЯ ВЛОЖЕННОСТЬ
• Высокая вложенность
затрудняет читабельность и
понимание
• Высокая вложенность говорит
о том, что логические
структуры плохо разделены
• Высокая вложенность и частые
ветвления превращают код в
хаос

МИНИМАЛЬНАЯ ВЛОЖЕННОСТЬ: СОВЕТЫ
• Используйте принципе Return
ASAP
• Не ставьте else, если
предыдущее условие
заканчивается на return
• Не бойтесь прерывать цикл
через break
• Часто имеет смысл вынести
тело цикла в отдельный метод
• Заменяйте ветвления
полиморфизмом

А ИНАЧЕ…

…

НАИБОЛЕЕ ЦЕННЫЕ НАВЫКИ ПРОГРАММИСТА
• Думать прежде, чем сделать
• Писать не код, а систему
• Задавать вопросы, если не
понятно
• Понимать не только
технологию, но и бизнес-
область задачи
• Делать продукт не для себя, а
для пользователей
• Понимать различие между
«идеально» и «качественно»

ВРЕМЯ ЗАДАВАТЬ ВОПРОСЫ