Объединяйте идеи, не становитесь религиозными, рассказывайте, не спрашивайте и т. Д.

Содержание:

  1. Подумай, прежде чем писать код
  2. Поймите бизнес, стоящий за каждым проектом
  3. Найдите кого-нибудь с другим стилем программирования и обсудите с ним
  4. Не становись религиозным
  5. Учите и читайте на регулярной основе
  6. Копайте глубже, чтобы получить больше знаний
  7. Участвуйте в форумах, обучайте, делитесь знаниями
  8. Будьте готовы переписать свой собственный код, когда узнаете что-то новое
  9. Объединить идеи
  10. Пишите хорошие имена и оставляйте комментарии
  11. Узнать больше языков
  12. "Тестовое задание"
  13. "Шаблоны проектирования"
  14. Разделение проблем
  15. Сведите к минимуму использование« и при описании частей вашего кода»
  16. "Не повторяйся"
  17. Скажи, не спрашивай
  18. Принцип открытости - закрытости (OCP)
  19. Короткие функции
  20. Фреймворки

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

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

Опыт, основанный на знаниях, увеличивается намного быстрее и становится более ценным.

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

1. Подумайте, прежде чем писать код

Написание строк кода не должно занимать 100% вашего времени разработки. 50–60% более чем достаточно. Я видел, как многие программисты пишут быстрее, чем способны думать. Люди не очень подходят для многозадачности. Делайте шаг за шагом и подумайте, прежде чем делать это.

Советы

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

2. Понимайте бизнес, стоящий за каждым проектом

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

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

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

3. Найдите кого-нибудь с совершенно другим стилем программирования и обсудите с ним

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

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

Умение слушать других, а также отстаивать свои идеи - чрезвычайно ценные навыки. Не стоит их недооценивать!

4. Не увлекайтесь религией

Слишком часто мы можем читать технические статьи, восхваляющие одну конкретную технологию и утверждающие, что другие ужасны. Это продолжается и продолжается - реляционные базы данных против noSQL, ООП против функционального программирования, Laravel против Symfony против Nette, VueJs против React против Angular, Nginx против Apache и т. Д. И т. Д.

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

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

5. Учите и читайте на регулярной основе

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

В наши дни учиться новому очень легко. Вы можете найти множество бесплатных материалов на YouTube. Платные каналы, такие как lynda.com, udemy.com или laracast.com (для фреймворка Lavarel), стоят на удивление мало по сравнению с получаемой вами ценностью. Десятки часов учебных материалов для курса от десяти до пятнадцати долларов просто потрясающие. Если вам нужно узнать что-то новое, у вас нет оправдания тому, чтобы этого не делать. Все, что вам нужно, есть где-нибудь в сети. Может быть сложно погрузиться в состояние «незнания». Чем больше у нас опыта в одной области, тем меньше мы хотим двигаться в другом направлении. Однако это важная часть личностного роста и саморазвития.

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

6. Копайте глубже, чтобы узнать больше

Великие разработчики также отличались от среднего уровня знанием технологии, лежащей в основе. Конечно, кодирование в React или VueJs не требует понимания IP-адресов, маршрутизации или систем DNS. Но чем больше мы знаем, тем более сложные проблемы мы можем решить.

Я лично люблю узнавать что-то новое. Я хочу как можно глубже разбираться в технологиях. Вам не обязательно быть похожим на меня, но знание технологии, лежащей в основе, всегда является преимуществом. Великие разработчики не воссоздают колесо. Используйте ресурсы с открытым исходным кодом в дикой природе. Количество материалов с открытым исходным кодом значительно выросло за последние 10 лет.

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

  • Узнай больше о компьютерах. Взгляните на небольшие процессоры и на то, как они обрабатывают данные. Как выглядит Ассемблер и как команды C или C ++ могут быть скомпилированы в Ассемблер. Есть много хороших ресурсов, объясняющих компьютеры на их базовом уровне. Вы найдете один такой канал YouTube здесь.
  • Если вы веб-разработчик, вам обязательно нужно узнать, как хранятся данные и как они перемещаются по миру. Физический уровень, уровень данных, сетевой уровень и т. Д. Это называется модель OSI, источники: 1 или 2.
  • Веб-разработчики должны быть знакомы с архитектурой клиент-сервер. Такие имена, как Apache, Nginx, IIS, Postfix, Node, Composer, должны показаться знакомыми.
  • Облако сегодня очень важно. Azure и AWS - чрезвычайно сложные инструменты. Я не думаю, что вам нужно быть экспертом в этих облачных технологиях, но хотя бы посмотрите, на что они способны. Как веб-разработчик, вы обязательно будете общаться с командой, которая позаботится о хостинге. Всегда полезно понимать друг друга и знать, какие проблемы могут возникнуть.
  • Даже если вы не большой поклонник Linux, как я, выучите хотя бы несколько основных команд. Linux широко используется для веб-серверов, и вам, скорее всего, не избежать этого. Командная строка не всем кажется дружелюбной, но некоторые базовые знания необходимы. Когда вы к этому привыкнете, это станет более естественным, и ваша эффективность повысится.

7. Участвуйте в форумах, обучайте, делитесь знаниями

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

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

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

8. Будьте готовы переписать свой код, когда узнаете что-то новое

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

Лично я трижды переписывал один из своих проектов с нуля. Я дошел до точки, когда больше не мог принимать оригинальный стиль. Не считаю это пустой тратой времени, потому что это помогло мне быстро получить дополнительный опыт. Само время не помогает. Делать одно и то же снова и снова в течение 10 лет вряд ли лучше, чем интенсивно учиться и практиковаться в течение одного года. Я знаю разработчиков, которые занимаются этим больше десяти лет, но даже не могут использовать команду include для разделения своего кода. Весь их опыт им совсем не помогает.

Как может выглядеть развитие навыков:

  • Изучайте, изучайте передовой опыт, просматривайте чужой код
  • Делайте свои проекты как можно лучше
  • Попросите кого-нибудь еще рассмотреть вашу работу и оставить отзыв
  • Реорганизуйте код лучше или начните все сначала, если необходимо
  • Попросите другого человека еще раз просмотреть ваш код. Собирайте отзывы и узнавайте что-то новое
  • Выберите свой стиль, используя как можно больше лучших практик

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

9. Комбинируйте идеи

Многие программисты склонны выбирать один способ написания кода (ООП, функциональное программирование, процедурное программирование) и хотят придерживаться своего стиля в любой ситуации. Им могут даже не нравиться некоторые подходы и стили, вообще не понимая их. Все стили программирования могут быть полезны при конкретном сценарии.

Другой пример - использование jsons в реляционных базах данных. MySQL 8 имеет качественную поддержку jsons, и нет причин делать ваши базы данных на 100% реляционными. Он может создавать очень сложную структуру таблиц. Мне лично нравится концепция гибридных баз данных.

Вы можете найти бесконечные дискуссии о том, подходит ли монолитное приложение для лучшей концепции, чем микросервисы. Как обычно, мир не является черно-белым, и типичный ответ будет «это зависит». Нет причин избегать гибридной модели. Мы снова в разделе 4: не становитесь слишком религиозными.

10. Пишите хорошие имена и оставляйте комментарии

Именование и аннулирование кеша с юмором считаются самыми сложными частями программирования. И не зря - в именовании есть разница между читаемым и плохо читаемым кодом.

Когда я учился в университете, мы использовали Matlab в качестве основного инструмента программирования. Одна из сильных сторон Matlab - возможность писать все более плотный код. Когда мы начали изучать Matlab, у нас была задача программирования, которую большинство из нас решало стандартным процедурным способом. Затем была поставлена ​​вторая задача: «напишите код в одну строку». Часто это можно сделать в Matlab без особых усилий. Однако чтение может стать поистине адским переживанием. Избегайте чрезмерно плотного кода, например, за исключением случаев, когда это абсолютно необходимо по соображениям производительности. Обычно программисты жертвуют небольшой производительностью ради удобочитаемости. Помните, что через два месяца у вас могут возникнуть трудности с чтением собственного кода. Не саботируй свою будущую работу!

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

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

Сравните эти два примера (код PHP):

if(!preg_match("^[_a-z0–9-]+(\.[_a-z0–9-]+)*@[a-z0–9-]+(\.[a-z0–9-]+)*(\.[a-z]{2,3})$^", $email)) {
   … handling wrong email
}

Or:

if(!$this->isEmailValid($email)) {
   … handling wrong email
}
private function isEmailValid(string $email) 
{
     return preg_match("^[_a-z0–9-]+(\.[_a-z0–9-]+)*@[a-z0–9-]+(\.
            [a-z0–9-]+)*(\.[a-z]{2,3})$^", $email);
}

Несколько советов по именованию классов / методов / переменных:

  • По возможности избегайте слов «менеджмент» или «менеджер». Почему? Потому что почти все может быть менеджером - им быстро начнут злоупотреблять.
  • Последовательно используйте порядок глаголов и существительных. Например, emailValidation или validateEmail оба подходят. Просто выберите один стиль и придерживайтесь его.
  • Если возможно, укажите, что возвращает метод. Мне нравится использовать «is» для логических возвращаемых типов. Например, я думаю, что isEmailValid - лучшее имя, чем emailValidation. Вы сразу узнаете, что «is» в начале имени означает возвращаемый тип true / false. Точно так же has или contains может указывать на логический тип возвращаемого значения.
  • Если возможно, не повторяйтесь. Один из примеров - использование классов. Рассмотрим $user класс. Имена методов без слова «user» - это нормально. Понятно, что метод касается пользователя. $user->getFullName() или $user->getAddress() лучше, чем $user->getUserFullName() или
    $user->getUserAddress().
  • Если нет веских причин поступать иначе, следуйте общепринятым соглашениям. Например, в PHP имена переменных имеют стиль camelCase . Имена столбцов SQL записываются в snake_case. Классы и объекты используют PascalCase.
  • В некоторых языках, например в JavaScript, можно использовать знак $ как обычный символ, как и любую другую букву. В PHP знак $ - это специальный символ, но его нет в JS. Итак, вы можете назвать свою переменную var user или var $user. Однако знак $ может разделять специальные переменные. Когда вы присоединяетесь к новому проекту JS, спросите архитектора программного обеспечения, как его использовать. Например, в VueJs переменные, начинающиеся с $, указывают на специальные объекты, предоставляемые самим Vue. Например, this.$route или this.$store. Опять же, какие бы обозначения вы ни использовали, оставайтесь последовательными.
  • Подобно предыдущему пункту, иногда _ используется для частных переменных, особенно в JavaScript. Некоторым разработчикам это нравится, некоторым это не нравится. Вы знаете, как оно есть. Просто будьте последовательны.

11. Узнать больше о языках

Если вы профессиональный программист, обязательно учите больше языков. По крайней мере, полезен некоторый более широкий опыт. Например, подход Matlab / R к программированию полностью отличается от подхода C. Объектно-ориентированный подход C ++ отличается от C или Basic. Программирование для Windows с использованием C # требует другого подхода, чем создание консольной программы на C. Затем есть несколько новых, таких как Go, Rust или Swift.

Разные языки решают одни и те же проблемы по-разному. Их изучение значительно улучшит ваши навыки решения проблем.

12. Тест

Тестирование - неотъемлемая часть написания любого кода. Существует целый подход, основанный на тестировании, который называется Test-Driven Development (сокращенно TDD). При таком подходе вы сначала пишете тесты для новых объектов, а затем заполняете классы бизнес-логикой. У этого есть несколько преимуществ:

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

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

Большая роль в тестировании - это возможность провести рефакторинг и убедиться, что все по-прежнему работает должным образом. Трудно достичь этого состояния при избытке модульных тестов, поэтому следует изучить комбинацию модульных тестов и компонентных тестов. В компонентных тестах N-единицы взаимодействуют друг с другом. Кроме того, клиенты ценят тесты e2e (сквозные), которые гарантируют, что опыт клиента останется прежним после выхода новой версии. Для веб-приложения существует несколько популярных инструментов, таких как Cypress, TestCafe или Selenium (Selenium vs. Cypress).

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

13. Шаблоны дизайна

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

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

  • Наблюдатель
  • Фабрика
  • Строитель
  • Синглтон
  • Декоратор

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

Еще одна исключительно важная часть знаний - это знание анти-паттернов (1). Антишаблоны - это концепции, которые приводят к проблемам, но чрезвычайно типичны для многих программ. Вот несколько примеров:

  • Бог возражает
  • Изобретая колесо
  • Швейцарский армейский нож
  • Код спагетти
  • Поток лавы

14. Разделение проблем

Один из самых действенных принципов программирования - разделение проблем (SoC). Правило простое: каждый класс или функция должны выполнять простую задачу. Классы, в которых много разных методов, довольно сложно поддерживать и расширять. Отсюда и пошли анекдоты про бананы и гориллы: «Вы хотели банан, но получили гориллу, держащую банан и все джунгли». Не позволяйте вашим классам и методам слишком сильно разрастаться. Следующее правило поможет вам не сбиться с пути.

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

Очень хороший пример разделения - это разработка HTML. Когда начинался HTML, CSS не было. Если нужен был конкретный шрифт, для него был тег:

<font color="red" face="Verdana, Geneva, sans-serif" size="+1">My text in red and Verdana font</font>

Веб-структура, ее содержание и ее стили были тесно связаны друг с другом. CSS позволяет разделять стили и веб-структуру. Внезапно появилась возможность обновлять стили, не касаясь самого HTML-кода.

15. Сведите к минимуму использование «и» при описании частей вашего кода.

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

Пример неоптимального класса: переносит данные пользователя, проверяет входные данные и сохраняет данные в БД.

16. Не повторяйся

Не повторяйся (СУХОЙ)! Это чрезвычайно важное правило, которое должен помнить каждый. Каждый раз, когда вы используете копирование и вставку, просто прекратите это делать и заново продумайте то, что вы делаете. Вам действительно нужно скопировать некоторые части кода? Нельзя ли изменить его для повторного использования кода?

Это может показаться очевидным, но если мы, программисты, забываем думать и просто продолжаем писать новые строки кода, может быть сложно следовать этому правилу. Я видел код, в котором каждая из 30 HTML-страниц имела свой собственный заголовок. Нет include файла заголовка. Если заказчик решил изменить значок, программистам потребуется обновить 30 страниц. Настоящий кошмар.

17. Расскажите, не спрашивайте

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

Примеры

Нарушение принципа Говори, не спрашивай:

class User {
    public $firstName;
    public $lastName;
    public $fullName;
    public $myValue = 0;
}
$user = new User();
$user->fullName = $user->firstName . '' . $user->lastName;
$user->myValue = $user->myValue++;

Лучший код:

class User {
    public $firstName;
    public $lastName;
    private $myValue = 0;
    public function getFullName() {
       return $this->firstName . ‘ ‘ . $this->lastName;
    }
    public function incrementMyValue() {
        $this->$myValue ++;
    }
}
$user = new User();
$fullName = $user->getFullName();

18. Принцип открытости - закрытости (OCP)

При программировании следует следовать передовым методикам и определенным правилам, таким как SOLID, который улучшает код, упрощая поддержку, чтение и повторное использование. Однако в какой-то момент каждый программист должен решить, где провести грань между хорошим и чрезмерно оптимизированным кодом. Если довести какое-либо правило до крайности, результат не будет оптимальным. В этом прелесть программирования - никогда не бывает одного правильного ответа. Принцип Open-Closed - один из тех, которые всегда требуют компромисса между скоростью программирования, длиной кода, количеством классов, удобочитаемостью, возможностью повторного использования и т. Д. На мой взгляд, это один из самых сложных правила для реального применения в реальном кодировании. Давайте объясним это немного на примерах.

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

Как вы распознаете, что в вашем коде могут быть нарушены OCP? Типичный сценарий предполагает использование нескольких элементов одного и того же типа, например файлов разных типов. Вам может понадобиться обработчик и модель для каждого типа файла (jpg, png, doc, pdf и т. Д.). Простое решение может включать в себя блок if / elseif или длинный переключатель, например следующий:

public function getHandler(string $fileType){
    switch ($fileType) {
        case “jpg” : 
             return new JpgHandler();
             break;
        case “doc” : 
             return new DocHandler();
             break;
        case “pdf” :
             return new PdfHandler();
             break;
    }
}

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

Решение, которое мне нравится использовать, - это реализация регистров. Каждый раз, когда вам нужен новый обработчик, вы просто регистрируете его. В Laravel это можно сделать в AppServiceProvider, который обрабатывает привязку в контейнере.

Пример

class FilesRegistry
{
    private $handlers = [];
    public function addFileHandler(Handler $handler){
        $this->handlers[$handler->getExtension()] = $handler;
    }
    public function getHandler(string $extension) {
        return $this->handlers[$extension];
    }
}

В AppServiceProvider (или другом методе регистрации контейнера внедрения зависимостей) мы имеем:

$filesRegistry = new FilesRegistry();
$jpgHandler = new JpgHandler();
$filesRegistry->addFileHandler($jpgHandler);
$docHandler = new DocHandler();
$filesRegistry->addFileHandler($docHandler);

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

19. Краткие функции

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

Длинные функции всегда должны включать красный свет как запах кода. Они часто содержат слишком много вложенных блоков if / else / for / while, которые чрезвычайно трудно читать. Имейте в виду, что ваш код будет читать кто-то другой. Даже вам через два-три месяца будет сложно понять, что делают ваши сумасшедшие функции и почему вы реализовали их так запутанно.

Есть несколько методов сокращения функций. Вот несколько примеров:

  • Уменьшите использование if / else
if($var === 1) {
    return true;
}
else {
    return false;
}

заменить:

return $var === 1;
  • foreach обычно можно эффективно заменить функциями массива:
$result = 0;
foreach($numbers as $number) { /* $number is a class */
    $result += number.value;
}

Заменить:

$result = array_reduce($numbers, “sumNumberValues”);

Где sumNumberValues определяется отдельно как:

sumNumberValues ($total, $number){
    return total + $number->value;
}

20. фреймворки

В настоящее время для большинства популярных языков программирования доступно несколько фреймворков. Фреймворк - это не только набор функций / классов / инструментов, но и подход к написанию кода. Это поможет вам соответствовать вашему стилю кодирования. Кроме того, все типичные задачи, с которыми приходится сталкиваться каждой сети, уже решены и хорошо протестированы. - например, маршрутизация, проверка данных, обмен данными с базами данных, манипуляции с коллекциями и массивами и т. Д. Не пытайтесь изобретать велосипед!

Обсуждение

Каковы ваши советы, как стать лучшим программистом? Пожалуйста, поделитесь в комментариях!