x
 
Фёдор Борщёв
9 июля 2020
Советы почтой каждую неделю
Пожалуйста, получите наше письмо, чтобы подтвердить свой адрес:
Вы подписаны на «Советы за неделю»:

Аккуратный код

В про­шлых сове­тах о чистоте кода мы про­ек­ти­ро­вали бэкенд для системы, кото­рая про­даёт курсы и билеты на веби­нары. Давайте теперь пред­ста­вим, что ста­нет с этой систе­мой через несколько меся­цев суще­ствен­ных дора­бо­ток. Ско­рее всего, за это время мы сде­лаем парочку выгру­зок и печат­ных доку­мен­тов для бух­гал­те­рии, доба­вим рас­чёт сто­и­мо­сти доставки, несколько уров­ней ски­док, уве­дом­ле­ния в Теле­граме о коли­че­стве зака­зов в день и Эпл‑пей. Каж­дая из этих фич, ско­рее всего, оста­вит след в классе заказа, сде­лав его при­мерно таким:

Аккуратный код

Нож «Вик­то­ри­нокс Свис­счемп Икс‑Эй‑Ви‑Ти» с 83 функ­ци­ями. Вики­пе­дия

Одни и те же задачи мы нач­нём решать по два раза. Про­грам­мист, дела­ю­щий выгрузку для бух­гал­те­рии, напи­шет метод для рас­чёта НДС и поло­жит его в класс Order. А его това­рищ, заня­тый инте­гра­цией с логи­сти­че­ским парт­нё­ром, — напи­шет точно такой же метод в своём классе PartnerIntegration, потому что про­сто не уви­дит резуль­тат работы первого.

Этого удастся избе­жать, если исполь­зо­вать прин­цип еди­ной ответственности:

Каж­дый класс дол­жен выпол­нять только одну задачу

Давайте вос­поль­зу­емся ком­по­зи­цией, пусть класс заказа будет всего лишь интер­фей­сом для более спе­ци­а­ли­зи­ро­ван­ных классов:

class Order:
  def __init__(self):
    self.accounting = Accounting(order=self)
    self.payment = PaymentSystem(order=self)
    self.shipment = Shipper(order=self)
    self.notifications = NotificationsDispatcher(order=self)

Мы раз­гра­ни­чили ответ­ствен­ность за раз­ные участки про­граммы между раз­ными клас­сами. Теперь новому про­грам­ми­сту гораздо легче дога­даться, что рас­чёт НДС вызы­ва­ется через order.accounting.get_vat(), а уве­дом­ле­ние в Теле­граме об успеш­ном заказе он сразу поле­зет искать в order.notifications.

Этот приём можно при­ме­нять и к ниже­ле­жа­щим клас­сам. Класс, кото­рый в при­мере выше отве­чает за уве­дом­ле­ния, назы­ва­ется NotificationDispatcher, и сразу понятно, что его задача — рас­сы­лать сиг­налы об изме­не­ниях в осталь­ные части при­ло­же­ния. Можно послать один сиг­нал «заказ создан», чтобы на его основе сде­лали свою работу несколько клас­сов — к при­меру, уве­дом­ля­тель в Теле­граме и при­сы­ла­тель при­вет­ствен­ного письма пользователю.

P. S. Это был совет об управлении разработкой. Хотите больше знать о планировании спринтов, управлении продуктом или о настройке инфраструктуры? Присылайте вопросы.

Поделиться
Отправить

Цель рубрики — обсуждение вопросов дизайна всех видов, текста в дизайне и взаимоотношений дизайнеров с клиентами.

Мы публикуем комментарии, которые добавляют к уже сказанному новые мысли и хорошие примеры. Мы ожидаем, что такие комментарии составят около 20% от общего числа.

Решение о публикации принимается один раз; мы не имеем возможности комментировать или пересматривать свое решение, хотя оно может быть ошибочно. Уже опубликованные комментарии могут быть удалены через некоторое время, если без них обсуждение не становится менее ценным или интересным.

Вот такой веб 2.0.

Как организовать процесс сдачи задачи и код-ревью в рамках спринта? Стоит ли менять работу, если уже порядком поднадоело, но есть новые проекты и в целом хоть какой-то прогресс ощутим? Что такое непрерывная доставка? Как и когда зарождающийся стартап в процессе своего развития должен подходить к вопросу имплементации билинга?




Недавно всплыло

Как правильно защитить свою позицию перед заказчиком, который боится «потерять» клиентов 5 7 Колледж, вуз или Школа бюро, доступный кайф в архитектуре, как устроен Дизайн-буфет, когда откроются продажи Бюросайна 1 2