что значит написать код
Почему программирование — это не написание кода
Программисты так любят свой код, что совсем забывают, для чего он нужен. Давайте-ка вспомним.
Люди, которые далеки от программирования, думают, что работа программистов заключается в написании кода. И хорош тот программист, который пишет больше кода за меньшее время. Мы можем их простить, потому что сами имеем ошибочное представление о работе других специалистов.
Беда в том, что мы, программисты, думаем о своей работе точно так же.
Давайте разберёмся, чем мы на самом деле должны заниматься и почему кода нужно писать как можно меньше.
Пишет о программировании, в свободное время создает игры. Мечтает открыть свою студию и выпускать ламповые RPG.
Зачем нужны программисты
И код, и любые приложения на самом деле никому не нужны. Что действительно нужно людям — это решение их проблем.
Например, цель компании, которая владеет социальной сетью, — деньги. Чтобы получать больше денег, нужно привлечь больше пользователей. А для этого нужно, чтобы социальная сеть решала какие-то проблемы этих пользователей.
Ни один пользователь не заходит в приложение просто потому, что ему нравится, что оно существует.
Люблю этот набор единиц и нулей в моём вычислительном устройстве!
© Ни один пользователь в мире.
Пользователям не нужно это приложение, они хотят:
Помогает ли код удовлетворить хоть одну из этих потребностей? Сам по себе — нет. Он лишь инструмент в руках программиста. Поэтому программист должен думать не о коде, а о том, как с его помощью решить конкретные проблемы.
Больше кода == больше проблем
Если не думать о конкретных задачах, то кода становится слишком много:
Всё это мешает развивать проект, потому что чем больше кода, тем больше вероятность, что где-то появятся уязвимости и баги. В итоге получается приложение, которое не только не решает прежних проблем, но и создаёт новые.
И наоборот: нацеленность на решение проблем позволяет лучше продумать архитектуру и правильно расставить приоритеты в разработке. Так можно достичь большей эффективности с помощью меньшего объёма кода.
Отсюда следует простое правило:
Если код можно не писать, то его не нужно писать.
Сколько времени нужно писать код
Я считаю, что не стоит заниматься этим больше 4 часов в день. Оставшееся время лучше тратить на планирование архитектуры, изучение потребностей пользователей, ревью существующего кода, составление тестов и документации (этим лучше заниматься заранее).
В пример можно привести эту статью. Мне потребовалось всего полдня, чтобы написать её, но перед этим я несколько недель «варил» её в своей голове. То же самое и с программированием: лучшие решения появляются когда угодно, но не в процессе написания кода.
Конечно, чтобы прийти к этому, нужно овладеть хотя бы одной технологией — тогда вы поймёте, как писать небольшие, но эффективные приложения.
Например, вы можете пройти курс «Профессия С#-разработчик». Там вы изучите язык C#, работая над проектами для компьютеров и веба, что поможет узнать лучшие подходы к разработке.
Профессия С#-разработчик
130 часов — и вы научитесь писать программы на языке, созданном Microsoft. Вы создадите 5 проектов для портфолио, даже если до этого никогда не программировали. После прохождения обучения — помощь в трудоустройстве.
Программирование с нуля
Данная статья описывает основные конструкции в программировании и предназначена для тех, кто хочет в этом разобраться. Но статья не описывает все нюансы, потому что их слишком много. Если описывать их все, будет очень нудно и непонятно.
Использовать будем си-подобный синтаксис, то есть подобный языку си, но не будем вникать в заголовочные файлы, указатели и другие особенности относительно низкоуровневых языков, перейдём на синтаксис более высокоуровневых языков, которые сделают рутинную работу за нас. А конкретно, будем использовать синтаксис языка Java. Добро пожаловать под кат.
Двоичная система счисления
Числа в двоичной системе счисления состоят всего из двух знаков. Нуля и единицы. 00000001 – число один. 00000010 – число два. 00000100 – число 4. Как вы можете заметить, когда единица смещается влево, число увеличивается в два раза. Чтобы получилось число 3, необходимо написать 00000011. Таким образом можно составить все необходимые числа. В данном примере мы использовали двоичное число с восемью знаками, иначе говоря число восьмиразрядное. Чем больше у числа разрядов, тем большее оно может вместить значение. Например, восьмиразрядное число вмещает максимальное значение 255, если считать ноль, тогда 256, а в программировании ноль считается всегда. Если увеличить разряд на один, получится девятиразрядное число и его вместимость увеличится в два раза, то есть станет 512. Но так в программировании никогда не делается и обычно каждая следующая разрядность увеличивается вдвое. Один разряд, потом 2 разряда, потом 4 разряда, потом 8 разрядов, потом 16 разрядов, потом 32 разряда и далее.
Шестнадцатеричная система счисления
Всё аналогично двоичной, только вместо нулей и единиц участвуют цифры от 0 до 15. 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F, где A – 10, B – 11, C – 12, D – 13, E – 14, F – 15.
Знак минус в программировании
Буквы и знаки
Буквы, знаки, смайлики и так далее обозначаются также числами. Буква А может быть числом 00000001 или любым другим, или даже комбинацией чисел в зависимости от кодировки символов. Кодировок много.
Типы данных
В программировании есть типы данных. Числовые, такие как 233, которые разобрали выше. Называются почти везде int, от слова integer. С плавающей запятой, такие как 198,76, называются почти везде float. У букв тип char, у строк тип String. Тип bool имеет два значения – истина (true) и ложь (false). У этого типа реализация в разных языках разная, но самая простая, когда ноль — значит ложь, а любое другое число истину. Нестандартные типы данных, такие как числа с фиксированной запятой, рассматривать не будем.
Применение
Прежде чем использовать числа в программировании их нужно объявить, то есть сказать с помощью языка программирования, что они существуют.
Это стандартное объявление примитивного типа.
Сначала пишем тип, потом имя переменной, то есть нашего числа. Всегда заканчиваем наше выражение, да и любое, точкой с запятой.
Теперь мы можем использовать переменную по её имени.
Здесь мы присвоили переменной значение. В отличии от математики в программировании = значит взять значение справа и присвоить переменной слева. = — это знак/оператор присвоения.
Можно объединить объявление и присвоение, то есть сразу инициализировать переменную.
Буквы выделяются одинарными кавычками, строки выделяются двойными кавычками. Числа типа int не выделяются.
К числам с плавающей запятой одинарной точности в конце добавляется f.
К числам с плавающей запятой двойной точности ничего не добавляется.
Операторы
После того как мы записали наше выражение, например сложения,
получается значение. Но так как оно ни одной переменной не присваивается, оно исчезает. Чтобы присвоить значение переменной используется специальный оператор присвоения, который коротко описан выше.
Повторим ещё раз. Он берёт значение со своей правой стороны и присваивает его переменной в левой стороне. Это оператор =, и он не имеет ничего общего со знаком равно из математики.
Также у нас есть логические операторы, такие как (больше),
Основы программирования: как начать писать код
Окончил курс по языку программирования, но писать код не научился. С подобным сталкиваются многие новички. Пользователи Reddit описывают проблему так:
Разбираемся, в чём может быть проблема и как её решить.
Проблема: искусственная среда программирования
Многие онлайн‑курсы и книги предлагают новичкам работать в искусственной среде программирования, которая сопровождает написание кода различными инструкциями и подсказками. Она не соответствует тому, как в действительности работают разработчики. Когда курс заканчивается и бывший студент пытается совладать с реальной средой программирования, он чувствует себя потерянным, потому как привык к учебным инструментам, которые на каждом шагу предлагают подсказки.
Причина, по которой разработчики онлайн‑курсов пользуются подобными инструментами, заключается в том, что новичкам сложно взаимодействовать с реальными средами разработки. А искусственные платформы хороши тем, что помогают преодолеть первое сопротивление перед написанием кода. В конечном же счёте начинающему программисту всё равно придётся столкнуться с реальной средой разработки.
Проблема: чрезмерные руководства
На курсах программирования и при прочтении учебника ученик получает большое количество инструкций, советов, рекомендаций, что позволяет быстро добиваться успехов в учёбе. В некоторых случая студентам сразу дают ответы или напрямую говорят, как писать код.
По окончании курса новичок оказывается один на один с пустым файлом, без подсказок, и может почувствовать себя в замешательстве.
Проблема здесь — в чрезмерном руководстве. Ученика натаскивают на синтаксис языка, не уделяя при этом должного внимания основным идеям и понятиям программирования.
Синтаксис — это просто набор символов, которые используются для определённого языка программирования. Можно провести параллель с естественными языками: умение написать и произнести фразу на французском “S’il vous plaît” не имеет смысла, если вы не знаете её значения.
Только знание и понимание концепций, которые лежат в основе программирования, позволит понять, как работает код.
Решение 1: использовать реальные среды разработки
Стоит помучиться: установить и настроить реальную среду разработки. Начать можно с обычного текстового блокнота или сразу с редактора кода.
Узнайте, какой редактор чаще всего используют для выбранного вами языка, и установите его. Тщательно изучите его работу: как создать проект, запустить код, какие есть горячие клавиши и сокращения.
Напишите код, сохраните его и запустите — это будет вашим первым серьёзным шагом, ведь именно так работают настоящие разработчики.
Решение 2: писать код с нуля
Достаточно подсказок и инструкций! Начните с пустого файла, в который вы добавите каждую строку кода самостоятельно.
Это трудная задача, в процессе решения которой вы потратите кучу времени на отладку и попытки понять, что написано в сообщениях об ошибках. Но недаром говорят, что хороший программист тот, что умеет пользоваться поисковиком. Воспользуйтесь им по назначению — так вы сможете найти ответы на многие вопросы.
Не копипастите чужой код. Если вы используете работающих чужой код — вы ничему не научитесь. Изучайте чужой код, но не копируйте!
Главное на данном этапе — дойти до решения самостоятельно, а не получить уже готовое. Каждый раз, когда вы ищите и исправляете ошибку, вы получаете реальный опыт программирования.
Решение 3: писать много кода, очень много кода
Программирование — не теоретическая дисциплина: чтения книг, просмотра учебных видео и выполнения тренировочных упражнений недостаточно, чтобы освоить её. Чтобы научить программировать, нужно написать тысячи строк кода.
Ваша первая программа сможет немногое, а в вашем коде будет масса ошибок — но это не столь важно. Главное, сразу не разочаровываться в своих способностях и не бросить всё.
Процесс обучения может выглядеть так: изучаете теорию, ищите советы в поиске, пишите программу и так по кругу.
Решение 4: просить о помощи
Некоторые задачи и ошибки кажутся нерешаемыми: вы бьётесь час, другой, но ничего не приходит в голову. Возможно, пришло время попросить совет.
Сделать это можно на сайтах вопросов и ответов для разработчиков, самый известный — Stackoverflow, который существует в англоязычной и русскоязычной версиях. Не забывайте: хороший программист должен владеть английским языком, ведь это основной язык разработчиков всего мира, и ответ вы быстрее найдёте или получите именно на нём.
Чтобы получить корректный ответ на свой вопрос, стоит научиться правильно составлять запрос:
Программирование — непростое занятие, которое требует реальной заинтересованности и способности часами думать над решением задачи. Если вы воспользуетесь решениями из статьи и не передумаете становиться разработчиком — вы действительно готовы ступить на эту стезю.
Курсы программирования — хороший старт для новичка или человека знающего, которому не хватает системы или у которого возникают сложности при изучении нового языка или технологии. Но не стоит надеяться, что они сразу сделают из вас профи. От вас потребуется настоящая заинтересованность, способность часами думать над решением задачи, искать ошибки и умение учиться самостоятельно.
Программирование для себя: почему всем нужно научиться писать код
Nastya Nikolaeva
Навык программирования может пригодиться не только тем, кто хочет создавать программы или сайты профессионально. О том, как умение писать код может облегчить жизнь, рассказал Илья Щуров, доцент кафедры высшей математики ВШЭ и преподаватель Центра непрерывного образования факультета компьютерных наук НИУ ВШЭ. T&P публикуют конспект его лекции «Программирование как новый английский, или Почему программирование не только для разработчиков».
Илья Щуров
доцент кафедры высшей математики ВШЭ и преподаватель Центра непрерывного образования факультета компьютерных наук НИУ ВШЭ
Можно придумать множество классификаций, но в первую очередь я бы разделил программирование на две большие категории: программирование для кого-то, когда вы пишете программу, которой будут пользоваться люди, и программирование для себя. Профессиональное программирование — это в основном деятельность для других, и я бы не сказал, что она всегда приятна. Вне зависимости от того, заплатили вам за программу или вы пишете свободный софт, которым может пользоваться кто угодно, огромное количество людей предъявит претензии, что у них что-то не работает, и их всегда будет больше, чем тех, кто вас похвалит. А программирование для себя — занятие очень приятное, и сегодня мы обсудим именно его.
Писать код интересно, но, с другой стороны, это испытание. Ты взаимодействуешь с компьютером, и очень часто это взаимодействие, особенно если ты осваиваешь новую технологию, новый язык, выглядит так. Ты пишешь код, считаешь, что написал его верно, а компьютер говорит, что у тебя ошибка синтаксиса. Действительно, забыл точку с запятой, исправил, запустил заново. А компьютер говорит: «Закрой скобку». Через несколько таких итераций программа начинает работать, и становится ясно, кто в доме хозяин. Дело в том, что и у навыка программирования, и у процесса обучения ему есть некоторые побочные (в том числе положительные) эффекты.
1. Экстремальный опыт руководства
Компьютеры по сравнению с людьми очень глупые, они все понимают буквально, и если вы научились управлять машиной, то, скорее всего, вы справитесь с руководством любыми людьми.
2. Новый подход к информации
Вы начинаете по-другому смотреть на обработку информации, организацию информационных потоков и управления. Например, собирая массивы данных, вы уже задумываетесь, чтобы они были пригодны для последующей автоматической обработки. Это очень важно, если у вас большая организация или проект со множеством информационных потоков, с которыми нужно работать эффективно. Если у вас есть опыт автоматизации, вы довольно быстро поймете, в каком виде нужно получать информацию, чтобы потом ее ловко обрабатывать.
3. Профессиональная коммуникация
Если вы научитесь программировать хотя бы чуть-чуть, вам будет гораздо проще общаться с программистами. Полезно хотя бы на базовом уровне понимать, как устроен мир IT, и коммуницировать в этой сфере без посредников. Люди учат языки, чтобы лучше понять другую культуру, а языки программирования — технологии.
Почему уметь программировать может быть опасным? Первая причина — «тыжпрограммист». Если вдруг кто-то узнает, что вы умеете программировать, на вас начинают сыпаться запросы: «Переустанови мне операционную систему, пожалуйста, ты ж программист», «Почини чайник, ты ж программист» и так далее. Это не самая страшная проблема, есть пострашнее. Например, в 2001 году на первом курсе, когда интернет еще был медленным, я решил, что нужно сделать какую-то штуку, чтобы быстрее обмениваться информацией с друзьями. Я подумал: есть почта, и она работает. Тогда я завел отдельный почтовый ящик для нашей тусовки и написал скрипт. Робот заходил в этот ящик, брал письма, которые туда пришли, и пересылал их всем, кто был подписан на эту штуку. Так сейчас работают гугл-группы. Если я хотел написать всем, я отправлял письмо на этот общий ящик; если кто-то хотел ответить, он отвечал на него же, письмо попадало ко всем, и можно было что-то обсуждать.
Но у переполнился ящик, а когда ящик переполняется, почтовый сервер в ответ на любое письмо направляет отлуп, который тоже является письмом. Оно тоже попало в общий ящик, мой скрипт разослал его по всем адресам, в том числе и по тому, который переполнился. Почтовый сервер сгенерировал новый отлуп и так далее. В результате в воскресенье утром меня разбудил звонок моего друга, который аккуратно сказал: «Возможно, там проблема, потому что у меня в почтовом ящике 6 тысяч писем, и их количество увеличивается». Ничего особенно страшного не произошло, но это была проблема. Тогда я понял, что код легко может выйти из-под контроля и натворить бед, поэтому надо действовать аккуратно.
Это история как в «Маленьком принце»: вы в ответе за тех, кого приручили. Люди и процессы зависят от кода, который вы написали. То есть, как только вы делаете что-то полезное для других, цена ошибки возрастает.
Как научиться?
На эту тему есть две противоположные точки зрения. Первая: учиться программированию очень просто, основные команды можно освоить за три дня. Но тут высока вероятность, что, когда человек столкнется с трудностями, он решит, что его обманули и программирование — это не его. Программировать не просто, трудности возникают. Одна из причин этого состоит в том, что, когда вы программируете, вы каждый раз осваиваете новые технологии, а это всегда мучение.
Противоположное мнение заключается в том, что если вы не программируете со школьных лет, то нечего и начинать. Это тоже неправда. Программирование требует усилий, но вход в эту область открыт, даже если вы никогда им не занимались.
Вполне вероятно, что задача, с которой вы столкнулись, уже решена и это решение где-то лежит. Иногда разобраться с тем, как оно работает, сложнее, чем написать заново. Это стандартная программистская проблема, но для этого у нас есть Stack Overflow, одно из главных изобретений человечества в сфере программирования. Это сайт, где разработчики делятся опытом и отвечают на вопросы друг друга. У каждого участника свой уровень репутации, все очень удачно спроектировано, поэтому на простые вопросы можно получить ответ в течение десяти секунд. Это очень помогает. В современном мире вы не просто пишете программу — вы одновременно используете огромное количество программ и инструментов, уже созданных другими людьми.
Хороший способ научиться программировать — поставить перед собой задачу, которой вам было бы интересно заниматься, и потом попытаться ее решить. Конечно, есть множество онлайн-курсов — почитайте отзывы, чтобы выбрать подходящий. Первый язык программирования — это сложно, потому что нужно перестраивать то, как вы взаимодействуете с компьютерами и анализируете процессы. Универсальных ответов нет, все очень индивидуально. Кому-то достаточно почитать документацию, посмотреть примеры кода, и все понятно. В другой ситуации хорошо иметь наставника, который ответил бы на базовые вопросы. Вот несколько советов, которые кажутся мне важными.
1. Самый лучший способ что-то понять — найти работающий кусок кода, начать его модифицировать и изучать, что получится. Это нужно сделать после того, как вы разобрались с базовым синтаксисом. Подгоняйте код под свои задачи или просто экспериментируйте.
2. Если вы только учитесь программированию, не нужно сразу пытаться писать много кода до тех пор, пока вы не сможете корректно объяснять, чего хотите. Это нужно для того, чтобы компьютер выполнял команды четко и маленькими шажками. Всякий раз ваши эксперименты должны заканчиваться не тем, что вы случайно наткнулись на правильное решение, а пониманием, почему и как это работает.
3. Не беспокойтесь по поводу математики. Желательно знать, что такое остаток от деления числа на другое число, но все зависит от задач, которые перед вами стоят. Конечно, если вы хотите хитро обрабатывать данные, то вам нужна математика в том объеме, который нужен для такой обработки.
4. Не бойтесь. Когда вы будете начинать программировать для себя, наверное, вы будете писать не тот код, который понравится профессиональным разработчикам. Они скажут, что так не пишут, что это избыточно, что такой код будет сложно поддерживать, и так далее. Наверное, они будут правы. Но если вы пишете для себя и если вы только начинаете, это нормально, что ваши первые попытки не являются текстами уровня Льва Толстого. Если вы напишете программу, которая будет работать и решать вашу задачу, то это хорошо.
Есть мнение, что на фоне развития искусственного интеллекта и машинного обучения программисты скоро будут не нужны: компьютеры сами научатся себя программировать. Но мне кажется, что это не так. До тех пор, пока есть задачи и пока нужно объяснять, как их решать, программирование будет существовать. Безусловно, программирование сильно эволюционирует, за последние 20 лет оно изменилось очень сильно. Но от того, что компьютеры стали умнее, разработчиков меньше не стало — наоборот, их стало гораздо больше. И мне кажется, что дальше будет происходить то же самое.
9 крышесносных правил для тех, кто хочет писать чистый код
Они взорвали мой мозг, и я мгновенно стал программировать лучше.
Джордж Студенко
(George Studenko)
Разработчик ПО. Увлечён искусственным интеллектом и компьютерным зрением.
Фулстек-разработчик. Любимый стек: Java + Angular, но в хорошей компании готова писать хоть на языке Ада.
Вы слышали про объектную гимнастику (Object Calisthenics)? Если нет, то вам точно стоит её освоить! Тем более что это всего-то девять правил.
Я рассказывал о них многим разработчикам, и все они реагировали схоже. Сначала думали, что это шутка: «Как вообще можно хоть какой-то код написать по этим правилам?» Но, поприменяв их, обычно соглашались, что код и правда становится чище — причём почти мгновенно.
Так что же это?
Применяя объектную гимнастику, можно сделать код:
Считайте это упражнением. Вам нужно научиться выполнять эти правила при кодинге. А вот в повседневном программировании какими-то из них всегда можно пожертвовать — если следовать им слишком сложно или результат того не стоит.
Итак, выберите себе кодерскую задачку, начните её решать и постарайтесь строго следовать этим принципам. Даже если некоторые из них поначалу кажутся глупыми, просто продолжайте.
1. Только один уровень вложенности в каждом методе
То есть одно значение отступа на весь метод. Так его легче будет читать.
Вам придётся извлечь и вынести в отдельные методы некоторые фрагменты кода — например, условия и циклы. Этим новым методам нужно будет дать говорящие имена и вызвать их из исходного метода.
В чём профит
2. Не используйте else
Вложенные условия усложняют код, делают его нелинейным.
Как обойтись без else
Мы решили слегка отойти от оригинальной статьи и добавили пояснения к каждому способу. — Пер.
Например, ваша программа работает с объектами-фруктами: яблоками и грушами. По конвейеру движутся коробки с фруктами. Некоторые коробки подписаны, некоторые — нет. Если коробка не подписана, то вы считаете, что в ней лежат яблоки, — ну, так договорились.
В этом случае вы можете написать что-то вроде:
если коробка подписана, считать, что внутри те фрукты, которые указаны на коробке
иначе считать, что там яблоки
А ещё вы можете по умолчанию считать, что в коробке яблоки, и менять это значение, только если встретите надпись «груши».
Этот способ подойдёт для тривиального случая.
если условие1 выполняй действие1
иначе выполняй действие2
если условие1 выполняй действие1 и вернись
а ниже внутри того же метода расположить обработку второго условия — ведь исполнение дойдёт до него, только если не сработает условие1.
В этом случае методы будут просто вызываться друг за другом, а проверки условий окажутся у них внутри. Если условие не выполнится, программа вернётся на уровень выше и вызовет следующий метод со следующей проверкой.
Полиморфизм — один из столпов ООП. Благодаря ему один и тот же метод может по-разному реализовываться в иерархии классов.
Здесь автор говорит о том, что конструкцию с несколькими условиями иногда бывает уместно заменить вызовом одного метода.
Так получится сделать, если создать систему классов-наследников, в которых по-разному определить этот один метод.
Шаблон проектирования «Состояние» полезен, когда в зависимости от состояния системы одно и то же действие (переход к следующему этапу) должно обрабатываться по-разному.
Например, кофейный автомат сначала ждёт выбора напитка, потом оплаты, а только после этого готовит кофе.
Метод перехода на следующий шаг можно написать с кучей проверок типа «если сейчас я на шаге N, то делай то-то», а можно создать классы для каждого состояния и прописать действия по переходу на следующий шаг в них.
Шаблон проектирования «Стратегия» определяет семейство схожих алгоритмов и помещает каждый из них в отдельный класс.
В вызывающем классе хранится ссылка на стратегию, которую сейчас нужно использовать. Так что вместо множества проверок типа «если. то. » вызывается один метод класса-стратегии.
В чём профит
3. Оборачивайте примитивные типы
Оборачивая примитивные типы в классы, мы инкапсулируем (скрываем) тип. Если позже в ходе рефакторинга мы захотим изменить примитивные типы, это можно будет сделать в одном месте.
А ещё такой код легче воспринимать, ведь по сигнатуре объекта-обёртки сразу ясно, что передавать методу в качестве параметров.
В оригинальной книге правило звучит так: «оборачивайте примитивы и строки».
Например, если метод принимает параметр типа int, это мало о чём говорит. Другое дело, если тип параметра будет, скажем, Hour. Мы оборачиваем целое число (часов) в класс. В тот же класс можно добавить проверку допустимых значений, и тогда никто не сможет передать в метод 36 или другое неподходящее число.
В чём профит
4. По одной точке в строке
Это следствие закона Деметры: «Общайся только с друзьями» (речь об общении между классами с помощью вызова методов друг друга. — Пер.).
Точку вы используете для вызова методов в Java или С#. Вызовы типа object.getProperty().getSubProperty().doSomething() — это очень плохая практика! Классы не должны знать так много деталей реализации других классов.
В чём профит
5. Не сокращайте имена
Вы когда-нибудь встречали странное сокращённое название метода или переменной. Такое, что назначение их без контекста можно понять пятью разными способами?
Если вам приходится сокращать название метода, возможно, этот метод делает больше, чем должен. То есть нарушен принцип единственной ответственности. Поразмыслите над этим.
Поразмыслили? А теперь не сокращайте наименования!
В чём профит
6. Не раздувайте классы
Делайте их небольшими:
В конце концов, если ваш класс специализируется на чём-то одном, он не должен быть большим, верно?
В чём профит
7. Не больше двух переменных экземпляра (instance variable) на класс
Один класс должен иметь дело с одним состоянием, максимум с двумя. Так что, если в классе более двух переменных экземпляра, возможно, он нарушает принцип единственной ответственности.
Переменная экземпляра (instance variable, атрибут) — переменная, которая хранит свойство объекта — экземпляра класса. Этим она отличается от статической переменной (относится к классу, а не к его экземпляру) и от локальной переменной, которая объявляется в членах класса — например, в методах.
Кажется, это требование очень сложно выполнить. Уверен, вы видели классы с десятками параметров в конструкторе, так ведь?
Отлично! Почему бы не сгруппировать их в один объект? Или ещё раз хорошенько подумать о том, точно ли у этого класса идеальная архитектура и не делает ли он слишком много лишнего.
В чём профит
8. Первоклассные коллекции
Это похоже на правило №3, только применительно к коллекциям.
Внутри вашего класса может быть по-прежнему простая коллекция. Но, обернув её в класс, вы в будущем сможете легко провести рефакторинг: например, изменить тип коллекции.
В книге The ThoughtWorks Anthology автор акцентирует внимание на том, что в таком классе — обёртке над коллекцией вообще не должно быть других членов, кроме этой коллекции. Зато туда можно добавить методы фильтрации или добавления/удаления элементов.
В чём профит
9. Никаких геттеров и сеттеров
Не принимайте решений вне класса, позвольте ему самому заниматься своим делом. Иными словами, следуйте принципу «Рассказывай, а не спрашивай».
В чём профит
Что дальше?
Теперь вы знаете всё! Следовать этим принципам сперва будет сложно. Появится искушение всё бросить. Но воспринимайте это как вызов себе — соберитесь и упражняйтесь (никаких оправданий!).
А вот строго выполнять все эти правила в ежедневной разработке вовсе не обязательно. Помните про компромиссные варианты и выбирайте то, что лучше.
обложка: zaidi razak / Shutterstock
Где учиться программированию?
У Skillbox — более 50 крутых курсов по программированию. Разработка на Java, PHP, C#, Python и других языках, Data Science, создание игр на Unity, кибербезопасность, разработка мобильных приложений…
Начать учиться можно сразу, а платить за учёбу — позже. Обучение онлайн, в удобном для вас режиме. А ещё мы помогаем с трудоустройством.
ThoughtWorks — знаменитая американская компания с филиалами в 17 странах. Занимается разработкой ПО и консалтингом. Именно в её недрах родился манифест Agile — методологии гибкой разработки. А ещё там в разное время трудились гуру программирования и авторы книг Мартин Фаулер (Martin Fowler) и Джим Хайсмит (Jim Highsmith)
Объектно-ориентированное программирование (ООП) — парадигма разработки, при которой программы состоят из объектов. Объекты обладают свойствами и с помощью методов реализуют своё поведение.
Принцип единственной ответственности (англ. Single Responsibility Principle, SRP) — один из пяти основных принципов ООП, сформулированных Робертом Мартином. Это программист, консультант и автор многих классических книг о программировании.
Принцип гласит, что у каждого класса должна быть только одна ответственность (обязанность) и она должна быть полностью зашита внутри класса (инкапсулирована). И, конечно, все методы класса должны быть направлены исключительно на реализацию этой ответственности.
Принцип открытости/закрытости говорит, что программные сущности (классы, модули, функции) должны быть открыты для расширения, но закрыты для изменений.
Считается, что у хорошо спроектированной системы сильная связность (high cohesion) и слабое зацепление (low coupling).
Чем сильнее связность, тем лучше программная сущность (например, класс) сфокусирована на выполнении своих задач.
Чем слабее зацепление, тем меньше один модуль программы знает о своих соседях и тем меньше зависимостей между ними.