какие знаете принципы программирования
Восемь принципов программирования, которые могут облегчить вам жизнь
Одна из главных проблем в разработке программного обеспечения – борьба с возрастающей сложностью системы. Решением этой проблемы занимаются с времен появления первых программ. Результатами являются языки, всё более упрощающие взаимодействие с машиной, парадигмы программирования вроде ООП, паттерны. В этой статье будут рассмотрены принципы программирования, позволяющие уменьшить сложность и облегчить сопровождение системы.
1. Инкапсулируйте то, что изменяется.
Это основа всего ООП. Надо выделить компоненты, которые могут измениться, и отделить их от части системы, которая останется неизменной. Инкапсуляция позволит изменить или расширить выделенные компоненты без изменения остальной части системы. Основная проблема здесь в том, как лучше всего разделить приложение на части. Все паттерны проектирования занимаются ответом на этот вопрос.
2. Предпочитайте композицию наследованию.
При композиции поведение не наследуется, а предоставляется для использования правильно выбранным объектом. Так же композиция позволяет изменить поведение объекта, если он подключен не напрямую, а через интерфейс (см. след. принцип). Естественно, везде фанатично применять композицию и совсем отказаться от наследования было бы неразумно.
3. Код должен зависеть от абстракций, а не от конкретных реализаций.
Высокоуровневые компоненты не должны зависеть от низкоуровневых, и те и другие должны зависеть от абстракций. Авторы этой книги называют его принципом инверсии зависимостей (Inversion of Control, IoC). Лучше выделить контракт класса в интерфейс, а затем реализовать его. Например вместо:
private ArrayList String > someList = new ArrayList String > ();
private List String > someList= new ArrayList String >();
Соответственно, в аксессорах, в вызовах методов должны использоваться абстракции, а не реализации. Теперь при необходимости изменить поведение списка на двусвязный достаточно поменять только одну строку:
private List String > someList= new LinkedList String >();
4. Стремитесь к слабой связности взаимодействующих объектов.
Чем меньше объекты знают друг о друге, тем гибче система. Одному компоненту нет необходимости знать о внутреннем устройстве другого.
5. Классы должны быть открыты для расширения, но закрыты для изменения.
Это так называемый принцип «Открытости/закрытости». В разные периоды времени его реализовывали разным образом. Бертран Мейер предлагал в своей книге не изменять созданную реализацию класса, а при необходимости внесения изменений расширять класс посредством создания наследников. Позже была выдвинута идея использовать интерфейсы, реализации которых могут быть полиморфно заменены одна на другую при необходимости.
6. Взаимодействуйте только с близкими друзьями.
Это принцип минимальной информированности. При проектировании класса надо обращать внимание на количество классов, с которыми будет происходить его взаимодействие. Чем меньше таких классов, тем гибче система.
7. Не вызывайте нас – мы сами вас вызовем.
Или голливудский принцип. По Фаулеру – это синоним принципа IoC. Согласно идеи, компоненты высокого уровня (например, интерфейсы) определяют за компоненты низкого уровня (реализации), как и когда им подключаться к системе. Авторы Head First Design Patterns допускают, что согласно этому принципу компоненты низкого уровня могут участвовать в вычислениях без формирования зависимостей с компонентами высокого уровня, и в этом состоит отличие от более жесткого IoC.
8. Класс (или метод) должен иметь только одну причину для изменения.
Это так называемый «принцип одной обязанности». Чем больше причин для изменения, тем больше вероятность изменения. А изменение – причина массы проблем. Принцип указывает на то, что классу (как и методу) должна быть выделена только одна обязанность. Например, в хорошо спроектированной системе с трехслойной архитектурой: один метод DAO делает ровно один запрос в базу, один метод сервиса выполняет ровно одну задачу бизнес-логики, один метод контроллера вызывает сервис ровно один раз.
Практически все принципы пересекаются друг с другом, у всех задача одна и та же – уменьшение сложности системы и, как следствие, жизни программистов. Хочется верить, что чья-то жизнь станет легче после прочтения =)
Общие принципы разработки ПО и их основоположники. Коротко о главном
Нужно понимать, что все принципы — это не волшебная палочка, которая способна ваш «спагетти-код» превратить в понятное и рабочее состояние. Это лишь подсказки, которые могут облегчить ваш труд.
Основные принципы программирования
Видов и методов программирования большое множество. Часто их выбор зависит от того:
что нужно будет разрабатывать,
какая команда в этом будет задействована,
какое финансирование у проекта,
сколько времени есть на разработку,
Но какой бы метод или вид разработки н и был выбран, всех их объединяют основные принципы эффективной разработки.
Не повторяй себя! — DRY (Don ‘ t Repeat You r self)
Вам нужно внести исправление в этот повторяющийся кусок скрипта. В таком случае вам придется проконтролировать все места, где используется этот самый скрипт, чтобы ничего не пропустить. А это дополнительные затраты времени и энергии.
Процесс внесения изменений в повторяющийся код может быть осложнен тем, что исправления нужно вносить в чужой код, который вам незнаком. Тогда времени на всю процедуру будет потрачено еще больше.
Поэтому рекомендуется следующее: если хотя бы в 2-х местах нужно повториться со скриптом, тогда лучше такой скрипт вывести в отдельный метод.
Делать проще! — KISS (Keep It Simple Stupid)
Изначально нужно писать максимально просто, насколько это возможно. Не нужно придумывать каких-то сложных подходов или конструкций для решения простых задач. Это существенно облегчает дальнейшую поддержку и отладку вашей программы. Плюс может так случиться, что вас заменит другой программист (или вы кого-то замените!). Чтобы ему (или вам в чужом коде!) было легче разобраться, код должен быть максимально простым и понятным.
Бритва Оккама — OR (Occam ‘ s Razor)
Этот принцип схож с предыдущим, но имеет немного другой смысл. Суть в том, что не нужно создавать лишние методы, классы и переменные, если в них нет нужды. Перед созданием любого класса или метода нужно задуматься, а действительно ли это действие облегчит разработку и упростит код?
Этот принцип пришел из английской философии и назван в честь монаха Уильяма из Оккама. В философии этот принцип звучит так: «Не нужно приумножать сущее, если в этом нет острой нужды». Программисты адаптировали этот принцип к своей сфере и активно его применяют при эффективной и понятной разработке.
Вы в этом не нуждаетесь! — YAGNI (You Aren ‘ t Gonna Need It)
Данный принцип учит вести свою разработку последовательно и разрабатывать только то, что нужно здесь и сейчас. И только потом по мере необходимости наращивать функциональность вашей программы, приступать к дальнейшей разработке.
Многие программисты, особенно с небольшим опытом, сталкиваются с этой проблемой. Они начинают сразу разрабатывать весь функционал будущей программы. Для этого они создают необходимые методы и классы, которые в дальнейшем могу т попросту забыться или даже не пригодиться.
Вначале масштабное проектирование — BDUF (Big Design Up Front)
На первый взгляд может показаться, что этот принцип противоположен предыдущему. Но это не совсем так. Согласно этому принципу, перед стартом большой работы нужно спланировать весь будущий процесс разработки до мельчайших деталей. Должно быть известно:
что после чего будет программироваться;
кто будет отвечать за части разрабатываемой программы;
сколько времени нужно на разработку всей программы и/или ее частей;
Не нужно делать преждевременную оптимизацию — APO (Avoid Premature Optimization)
Принцип наи меньшего удивления — POLA (Princip l e Of Least Astonishment)
Не заставляйте удивляться других программистов вашему коду. Нужно программировать просто, понятно и очевидно, чтобы любой другой специалист мог прочитать ваше творение. Имена и названия методов и классов должны нести информативность и быть лаконичными. Вызываемый метод должен соответствовать тому, для чего он вызывается и как он называется.
Условно: если метод называется «Добавить сахар», а при этом добавляется соль, то это как минимум неправильный подход к названию метода.
Закон Дем ет ры — LOD (Law of Demeter)
Данный принцип определяет гибкость и понятность вашего приложения. Основная цель этого принципа — нужно разделять области ответственности среди всех используемых классов. То есть любой класс должен стремиться к собственной самостоятельности, но при этом он должен легко взаимодействовать с другими классами, когда это нужно. Приветствуется иерархия классов.
Заключение
Но все должно быть сбалансировано, даже применение этих принципов. Чувство баланса в коде приходит только с опытом. Поэтому больше практикуйтесь, не впадайте из крайности в крайность, следуйте этим принципам программирования и создавайте свои, о которых тоже можно будет написать статью.
Мы будем очень благодарны
если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.
Принципы программирования: расшифровываем аббревиатуры
Перевод статьи «10 Coding principles and acronyms demystified!».
Если говорить об аббревиатурах, в индустрии разработки программ вы их встретите в больших количествах. Тут KISS (англ. «поцелуй»), там SLAP (англ. «шлепок») — названия интригующие, но какие-то бессмысленные. Если вы только начинаете изучать программирование, подобные словечки, проскальзывающие в пояснениях, могут здорово раздражать. Особенно, если вы не знаете, что они означают! Если это как раз ваш случай, этот пост — для вас!
В этой статье мы разберем различные принципы программирования со странными названиями-аббревиатурами. Некоторые из них широко известны, другие встречаются в текстах пореже. Их сложность для понимания и применения тоже варьируется. Поэтому я постараюсь поподробнее объяснить теорию, стоящую за каждым из этих принципов. А самую интересную часть — их реализацию — я оставляю вам.
Начнем с самых популярных. Keep It Stupid Simple («Придерживайся простоты», аббревиатура KISSв качестве отдельного слова означает «поцелуй») это один из самых известных принципов программирования. Значение его довольно понятное, хотя и очень широкое.
Как не сложно догадаться, этот принцип велит вам следить за тем, чтобы код оставался как можно более простым. Чем код проще, тем легче в нем разобраться, как вам, так и другим людям, занимающимся его поддержкой. Под простотой главным образом имеется в виду отказ от использования хитроумных приемов и ненужного усложнения.
В качестве примеров нарушения этого принципа можно назвать написание отдельной функции только лишь для осуществления операции сложения или использование побитового оператора (right shift >> 1) для деления целых чисел на 2. Последнее, безусловно, более эффективно, чем обычное (/2), но при этом очень сильно снижается понятность кода. Применяя такой подход, вы осуществляете clever coding («заумный» кодинг») и over-optimization (чрезмерную оптимизацию). И то, и другое в долгосрочной перспективе не слишком хорошо сказывается на здоровье вашего кода.
Принцип Don’t Repeat Yourself («Не повторяйся», аббревиатура DRYв качестве отдельного слова означает «сухой») по своей природе очень похож на принцип KISS. Он тоже имеет довольно простое, но широкое значение.
Многим разработчикам случается делать копипаст и дублирование фрагментов собственного кода. В общем, в этом нет ничего плохого. У всех порой возникает необходимость быстро проверить что-нибудь (ожидаемое поведение или что другое), чтобы определить, стоит ли это писать (т. е., писать правильно). А вот выпуск такого скопированного кода в производство неприемлем.
DRY напоминает нам, что каждое повторяемое поведение в коде следует обособлять (например, выделять в отдельную функцию) для возможности многократного использования. Когда у вас в кодовой базе есть два совершенно одинаковых фрагмента кода, это не хорошо. Это часто приводит к рассинхронизации и прочим багам, не говоря уже о том, что от этого увеличивается размер программы.
YAGNI
YAGNI это определенно самая длинная аббревиатура в нашем списке. Принцип You Aren’t Gonna Need It («Тебе это не понадобится», YAGNI) может противоречить точке зрения некоторых программистов.
Готовность к будущему обычно считается делом хорошим, но не в программировании. Оставлять любой код, предназначенный только для расширяемости программы в будущем, это неправильно. Но если это противоречит вашим убеждениям, давайте разберем подробнее.
Проекты программного обеспечения не имеют четкого конца. Если только создатель проекта не забрасывает свою идею вообще (и при этом даже не передает ее кому-то еще), проект, по сути, постоянно развивается. Но при этом нет никакой точки, где можно было бы признать проект «достаточно хорошим» и остановиться. Всегда будет возможность что-то улучшить.
Пытаться спрогнозировать будущее и представлять, как должен выглядеть ваш код, это не плохо. Но нежелательно оставлять в продакшене «точки расширения» (места, предназначенные только для того, чтобы позволить вам в будущем легко добавить новый функционал). Конечно, мы не говорим о случаях, когда речь идет об уже заказанном функционале. Такие точки расширения вносят ненужную сложность и увеличивают размер вашей кодовой базы. Если задуматься, это также противоречит описанному выше принципу KISS.
Только представьте: код можно не только поцеловать (KISS) и высушить (DRY), но также и шлепнуть (SLAP)!
Single Level of Abstraction Principle («Принцип единого уровня абстракций», SLAP) диктует нам, как мы должны организовывать свой код (в частности, функции), чтобы он оставался поддерживаемым.
С длинными и сложными функциями тяжело ужиться. В них сложно разобраться непосвященному человеку, их тяжело тестировать и, зачастую, даже чтобы их увидеть полностью, приходится пользоваться прокруткой. Если у вас возникают подобные проблемы, следует немедленно задуматься о реструктуризации функции и создании вместо нее нескольких функций поменьше. Помните, что
«Функции должны выполнять только одно действие, но выполнять его хорошо» (Роберт Мартин).
Но как именно следует организовывать эти более мелкие функции? Какое именно «одно действие» должна выполнять каждая из них? Ну, когда вы приобретете больше опыта в программировании, вы начнете чувствовать, где и что следует располагать, а SLAP поможет вам в этом.
Ваши функции должны делать что-то одно или, если применять принцип SLAP, они должны иметь единый уровень абстракции. Скажем, функция, читающая input, не должна также обрабатывать полученные данные. Для этого она должна задействовать отдельную функцию, находящуюся на другом, более низком уровне абстракции. Чем более общей является функция и чем больше других функций она использует, тем выше она располагается в абстракционной иерархии.
Single Responsibility Principle («Принцип единой ответственности», SRP) в чем-то похож на SLAP, но направлен на объектно-ориентированное программирование. Этот принцип гласит, что объекты и классы (а также функции и методы) нужно организовывать так, чтобы каждый из них имел только одну зону ответственности.
Ответственность объектов и классов легко организовывать, когда они отражают более «жизненные» объекты. Но когда мы имеем дело с сущностями, имеющими в названии слова «контроллер» или «сервис», ситуация усложняется. Эти высокоуровневые модули тяжело организовывать, поскольку, теоретически, в них можно поместить что угодно. При этом число ответственностей таких сущностей стремительно растет, а в результате весь код становится более сложным и непонятным.
Как справиться с этой проблемой? Скажем, наш контроллер отвечает за компьютер. Он должен контролировать температуру CPU, скорость вентилятора, дисковое пространство, внешние устройства и т. п. вещи. Имейте в виду, что это означает не только свойства, но и методы, с которыми мы взаимодействуем. Как насчет того, чтобы создать несколько классов вместо того чтобы хранить все напрямую в одном классе? Так у нас появляются DevicesController, DiskSpaceController и т. д. А после мы можем использовать все эти классы, чтобы составить высокоуровневый класс Controller, который теперь будет куда проще поддерживать. Конечно, в реальности подобный код потребует куда большей организации, но, я надеюсь, идею вы уловили.
Мы уже говорили о расширяемости кода, когда обсуждали YAGNI. Open-Closed Principle («Принцип открытости-закрытости», OCP) некоторым образом связан с предыдущим правилом, но представляет собой другой взгляд на вещи.
OCP требует, чтобы код был открыт для новых, будущих дополнений, и чтобы при их добавлении не приходилось изменять уже написанный код. Этот принцип в большей степени затрагивает вопросы архитектуры, чем кода как такового.
Получается, OCP конфликтует с YAGNI? Ведь это две противоположные точки зрения на будущее нашего кода! Нет, это не так.
YAGNI предполагает отказ от добавления кода, который не используется в настоящее время. А OCP затрагивает более глубокие вещи, саму архитектуру вашего кода. Следование принципу OCP не означает, что вы должны писать бесполезный в настоящее время код, который может пригодиться в будущем. Речь идет о проектировании всей кодовой базы таким образом, чтобы она могла легко расширяться.
Вы делаете ваше «ядро» расширяемым, строите на его основе функционал, необходимый в настоящее время, и вместе с тем сохраняете архитектуру, готовую для внесения изменений в будущем. Все это не предполагает написания мертвого кода.
Liskov Substitution Principle («Принцип подстановки Барбары Лисков», LSP) назван в честь его автора, Барбары Лисков. Это принцип объектно-ориентированного программирования, касающийся классов, интерфейсов, типов и подтипов.
Само по себе это правило довольно простое и логичное, но поначалу его может быть трудно применять на практике. Суть его в том, что каждый подтип должен дополнять, а не заменять базовый тип. Проще всего понять это, разобрав пример (обычно для иллюстрации принципа используется проблема квадрата и прямоугольника).
Interface Segregation Principle («Принцип разделения интерфейса», ISP) это еще один принцип, затрагивающий тему организации кода. Он главным образом касается интерфейсов и статически типизированных языков программирования. Т.е., люди, пишущие код на JavaScript, не часто будут сталкиваться с применением этого принципа на практике. Тем не менее, знание этого принципа в любом случае способствует улучшению кода.
Интерфейсы помогают работать скорее с формой данных, а не с данными как таковыми. Правильное их написание и организация дают прекрасную возможность улучшить поддерживаемость вашего кода без потерь производительности.
Принцип ISP затрагивает именно эту сферу — использования интерфейсов для обособления кода и одновременно организации самих интерфейсов. Возьмем, к примеру, наследование классов. Возможно, вам не важны определенные методы или свойства базового класса и вы хотели бы их «пропустить»? Простой интерфейс может помочь вам в этом! В компилируемых и статически типизированных языках это также дает вам более чистую область видимости и более быструю компиляцию (если изменятся свойства родительского класса, не касающиеся данного интерфейса, подклассы не нужно будет перекомпилировать).
Как и OCP, Dependency Inversion Principle («Принцип инверсии зависимостей», DIP) в большей степени касается общей архитектуры вашего кода. Фактически, это один из самых важных принципов проектирования архитектуры кода.
Принцип DIP немного сложноват, но чтобы его придерживаться, нужно усвоить лишь две вещи. Во-первых, ваш код должен быть написан так, чтобы детали реализации (например, пользовательский интерфейс или база данных) зависели от основной логики (правил бизнеса), а не наоборот.
Во-вторых, все эти зависимости не должны быть прямыми. Их нужно абстрагировать при помощи интерфейсов, чтобы ваша основная логика работала со всем, что бы вы ей ни передали, требуя для этого только какой-нибудь простой «мост».
SOLID
Пять принципов, которые мы уже обсудили — SRP, OCP, LSP, ISP, DIP — вместе составляют набор принципов SOLID, описанный Робертом Мартином. Эти принципы способствуют созданию хорошего объектно-ориентированного (и не только) кода.
Надеюсь, я раскрыл эту тему достаточно, чтобы начинающие разработчики познакомились с основными принципами мира программирования. Но если хотите копнуть глубже, стоит поискать материалы в интернете. Я приложу лишь несколько источников:
10 базовых принципов программирования
Каждый может написать код, скажете вы. А хороший код? Вот здесь начинаются трудности. Мы все слышали эти страшные истории про невероятные цепочки из if-else, программы, которые падают при изменении всего лишь одной переменной, непонятные методы и так далее.
Так бывает при создании продукта, когда за плечами лишь полгода обучения. Не ставьте своей целью написать код, который будет просто работать. Целью должно быть написание кода, который может быть обновлен и изменен – даже если эти изменения будет вносить другой человек. Важно понимать и применять следующие принципы в программировании:
1. KISS
Принцип «простоты» (“keep it simple, stupid” principle) особенно важен для проектов средней сложности. Если вы думаете, что упростили достаточно, упростите код еще на один уровень, но не забывайте начинать с малого, чтобы не создать целую гору проблем.
Когда вы начали писать код, старайтесь делать его максимально простым и читаемым. Написание более сложного кода займет больше времени, а также такой код более подвержен к появлению багов и ошибок, его будет намного сложнее изменить в будущем. Мудрые словах Антуана де Сент-Экзюпери:
«Совершенство достигнуто не тогда, когда нечего добавить, а тогда, когда нечего отнять.»
2. DRY
Принцип „отсутствия повторов” (“don’t repeat yourself” principle) имеет решающее значение при написании чистого и легко изменяемого кода. При написании кода следует избегать дублирования данных и логики. Если вы заметили, что один и тот же фрагмент кода написан снова и снова, принцип был нарушен.
Противоположностью DRY-кода является WET код: «дублируйте». Один из лучших способов диагностики WET-кода – спросить себя: чтобы каким-то образом изменить поведение программы, сколько областей кода нужно было бы изменить?
3. Open/Closed
Код должен быть открытым для внедрения новых областей, но закрытым для изменений, не зависимо от того, пишете вы объекты на Java или модули на Python. Это относится ко всем видам проектов, но этот принцип особенно важен при выпуске библиотек или структур, предназначенных для использования другими пользователями.
4. Принцип единой ответственности
В принципе единой ответственности говорится, что каждый класс или модуль в программе должен заниматься только одним набором конкретных функций.
Классы и модули создаются по этому принципу, но поскольку расширяется функционал, они превращаются с течением времени в классы и модули, которые „могут все” и занимают сотни или даже тысячи строк кода. Если такое произошло, нужно разбить их на более мелкие классы и модули.
6. Разделение интересов
Принцип разделения интересов – это принцип единой ответственности, но на более абстрактном уровне. По сути, программа должна быть спроектирована таким образом, чтобы она имела много разных не перекрывающихся инкапсуляций, и эти инкапсуляции не должны взаимодействовать друг с другом.
Известным примером данного принципа является парадигма model-view-controller (MVC), которая разделяет программу на три различные области: данные («модель»), логика и то, что видит конечный пользователь. Например, код, который обрабатывает загрузку и сохранение данных в базе данных, не должен отвечать за то, как отображать эти данные в Интернете. Данный принцип упрощает техническое обслуживание. И в будущем, если вам когда-нибудь понадобится переписать весь код, вы можете сделать это, не беспокоясь о том, как же данные будут сохранены или как будет обработана логика.
7. YAGNI
Принцип основывается на том, что вам никогда не нужно реализовывать какую-либо функциональность, которая возможно вам понадобится в будущем. Скорее всего, вам это не понадобится, и это будет пустая трата времени, это также усложнит ваш код.
Часто неопытные программисты пытаются написать наиболее абстрактный и общий код, чтобы избежать WET код, но слишком большая абстракция заканчивается тем, что его невозможно поддерживать в будущем. Хитрость заключается в том, чтобы применять принцип DRY только тогда, когда вам нужно.
8. Избежание преждевременной оптимизации
Принцип избежания преждевременной оптимизации не похож на принцип YAGNI. Разница в том, что YAGNI предотвращает внедрение функций до того, как они понадобятся, в то время как принцип избежания преждевременной оптимизации направлен на предотвращение оптимизации работы алгоритмов, прежде чем это будет необходимо.
Проблема с преждевременной оптимизацией заключается в том, что вы никогда не сможете узнать, где будут проблемы в программе до тех пор, пока они не проявятся. Разумеется, вы можете догадаться, и иногда вы даже можете быть правы. Но чаще всего вы будете тратить драгоценное время, пытаясь ускорить процессы, которые не так уж и медленны, как вы думаете.
9. Рефакторинг, рефакторинг и ещё раз рефакторинг
Одна из самых сложных истин для неопытного программиста заключается в том, что очень редко с первого раза все заработает. Вы можете подумать, что написали идеальный код, реализуя определенную функцию, но по мере того, как ваша программа будет усложняться, написание будущих функций может быть довольно сложным, так как вы реализовали определенную функцию на ранней стадии.
Кодовые базы постоянно развиваются. Совершенно нормально пересматривать, переписывать или даже перепроектировать целые фрагменты кода – и это не просто нормально, это правильно. Ведь позже вы будете знать больше о специфике вашего проекта, чем в начале его создания, поэтому вы должны постоянно реорганизовывать свой старый код.
И не откладывайте это место на потом. Как только вы поняли, что где-то есть ошибка, не откладывайте ее исправление. Если вам когда-нибудь понадобится проверить или исправить старый код, постарайтесь улучшить его и сделать более чистым и аккуратным.
10. Чистый код > Умный код
Говоря о чистом коде, оставьте где-то далеко своё этот „умный” код. Под умным кодом подразумевается тип кода, который больше похож на загадку, чем на решение, и существует только для того, чтобы показать, насколько вы умны. На самом деле, никого это не волнует.
Примером „умного кода” будет вместить как можно больше логики в одну строку. Другим примером является использование специфических особенностей языка для написания странных, но работающих операций. Примером умного кода будет все то, что может заставить кого-то сказать «Погоди, что это?» при просмотре вашего кода.
Хороший программист и читаемый код идут рука об руку. Делайте комментарии при такой необходимости. Придерживайтесь определенного стиля, независимо от того, диктуется ли он языком (например, Python) или компанией (например, Google). Наблюдайте за языковыми идиомами и прекратите писать Java-код на Python или наоборот. См. Нашу статью о советах по написанию более чистого кода.
Что делает программиста эффективным?
Спросите пять человек, и вы получите 10 абсолютно разных ответов. Для меня хорошим программистом является тот, кто понимает, что написание кода должно в конечном итоге принести пользу конечному пользователю, с хорошим программистом легко работать в команде, ведь он заканчивает свои проекты со всеми спецификациями вовремя.
Если вы только начинаете, не думайте об этом слишком много. Сосредоточьтесь на том, как писать код без стресса. Если вы чувствуете, что застряли на каком-то участке кода, есть некоторые решения, но с ними вы можете ознакомиться здесь. И если вы просто не довольны своей работой, прочитайте нашу статью о знаках, которые говорят, что программирование – это не ваше.
Если у вас есть мечта стать разработчиком программного обеспечения и вы хотите пройти самый прямой путь к достижению этой цели, определенно стоит пойти на курсы программирования в Минске.