как начать писать код / TeachMePlease
Окончил курс по языку программирования, но писать код не научился. С подобным сталкиваются многие новички. Пользователи Reddit описывают проблему так:
- Я прошёл онлайн‑курс по Python, но всё равно не знаю, как написать полноценную программу.
- Я знаю теорию, но не могу применить её на практике.
- Я знаю, что такое цикл while, но не знаю, как и в каких случаях использовать его.
Разбираемся, в чём может быть проблема и как её решить.
Проблема: искусственная среда программирования
Многие онлайн‑курсы и книги предлагают новичкам работать в искусственной среде программирования, которая сопровождает написание кода различными инструкциями и подсказками. Она не соответствует тому, как в действительности работают разработчики. Когда курс заканчивается и бывший студент пытается совладать с реальной средой программирования, он чувствует себя потерянным, потому как привык к учебным инструментам, которые на каждом шагу предлагают подсказки.
Причина, по которой разработчики онлайн‑курсов пользуются подобными инструментами, заключается в том, что новичкам сложно взаимодействовать с реальными средами разработки. А искусственные платформы хороши тем, что помогают преодолеть первое сопротивление перед написанием кода. В конечном же счёте начинающему программисту всё равно придётся столкнуться с реальной средой разработки.
Проблема: чрезмерные руководства
На курсах программирования и при прочтении учебника ученик получает большое количество инструкций, советов, рекомендаций, что позволяет быстро добиваться успехов в учёбе. В некоторых случая студентам сразу дают ответы или напрямую говорят, как писать код.
По окончании курса новичок оказывается один на один с пустым файлом, без подсказок, и может почувствовать себя в замешательстве.
Проблема здесь — в чрезмерном руководстве. Ученика натаскивают на синтаксис языка, не уделяя при этом должного внимания основным идеям и понятиям программирования.
Синтаксис — это просто набор символов, которые используются для определённого языка программирования. Можно провести параллель с естественными языками: умение написать и произнести фразу на французском “S’il vous plaît” не имеет смысла, если вы не знаете её значения.
Только знание и понимание концепций, которые лежат в основе программирования, позволит понять, как работает код.
Решение 1: использовать реальные среды разработки
Стоит помучиться: установить и настроить реальную среду разработки. Начать можно с обычного текстового блокнота или сразу с редактора кода.
Узнайте, какой редактор чаще всего используют для выбранного вами языка, и установите его. Тщательно изучите его работу: как создать проект, запустить код, какие есть горячие клавиши и сокращения.
Напишите код, сохраните его и запустите — это будет вашим первым серьёзным шагом, ведь именно так работают настоящие разработчики.
Решение 2: писать код с нуля
Достаточно подсказок и инструкций! Начните с пустого файла, в который вы добавите каждую строку кода самостоятельно.
Это трудная задача, в процессе решения которой вы потратите кучу времени на отладку и попытки понять, что написано в сообщениях об ошибках. Но недаром говорят, что хороший программист тот, что умеет пользоваться поисковиком. Воспользуйтесь им по назначению — так вы сможете найти ответы на многие вопросы.
Не копипастите чужой код. Если вы используете работающих чужой код — вы ничему не научитесь. Изучайте чужой код, но не копируйте!
Главное на данном этапе — дойти до решения самостоятельно, а не получить уже готовое. Каждый раз, когда вы ищите и исправляете ошибку, вы получаете реальный опыт программирования.
Решение 3: писать много кода, очень много кода
Программирование — не теоретическая дисциплина: чтения книг, просмотра учебных видео и выполнения тренировочных упражнений недостаточно, чтобы освоить её. Чтобы научить программировать, нужно написать тысячи строк кода.
Ваша первая программа сможет немногое, а в вашем коде будет масса ошибок — но это не столь важно. Главное, сразу не разочаровываться в своих способностях и не бросить всё.
Процесс обучения может выглядеть так: изучаете теорию, ищите советы в поиске, пишите программу и так по кругу.
Решение 4: просить о помощи
Некоторые задачи и ошибки кажутся нерешаемыми: вы бьётесь час, другой, но ничего не приходит в голову. Возможно, пришло время попросить совет.
Сделать это можно на сайтах вопросов и ответов для разработчиков, самый известный — Stackoverflow, который существует в англоязычной и русскоязычной версиях. Не забывайте: хороший программист должен владеть английским языком, ведь это основной язык разработчиков всего мира, и ответ вы быстрее найдёте или получите именно на нём.
Чтобы получить корректный ответ на свой вопрос, стоит научиться правильно составлять запрос:
- Скопируйте сообщение об ошибке, которое выводится в редакторе и укажите его в вопросе.
- Нет сообщения об ошибке, объясните, какого результата вы ожидаете от работы программы, и что происходит при её запуске на самом деле.
- Вставьте фрагмент кода, укажите код полностью в посте, если он небольшой. Если большой — используйте Github Gist или Pastebin и укажите ссылку на код.
- Отформатируйте код. Не вставляйте его обычным текстом, используйте редактор кода.
- Напишите, что вы уже пытались сделать с кодом.
- Используйте корректную терминологию — в этом вам поможет изучение теории.
Программирование — непростое занятие, которое требует реальной заинтересованности и способности часами думать над решением задачи. Если вы воспользуетесь решениями из статьи и не передумаете становиться разработчиком — вы действительно готовы ступить на эту стезю.
Курсы программирования — хороший старт для новичка или человека знающего, которому не хватает системы или у которого возникают сложности при изучении нового языка или технологии. Но не стоит надеяться, что они сразу сделают из вас профи. От вас потребуется настоящая заинтересованность, способность часами думать над решением задачи, искать ошибки и умение учиться самостоятельно.
Источник: When You Know the Basics, but You Still Can’t Code
blog.teachmeplease.ru
Как писать чистый и красивый код
Роберту Мартину удалось идеально описать измерение качества кода кода:
Единственным ценным измерением качества кода является WTF/мин.
Объясню чуть подробнее. Когда я провожу code review, у меня бывает только три эмоции:
- WTF (с отвращением) — этот код не нужен.
- WTF (с восхищением) — этот человек умен.
- WTF (раздраженно) — эту ерунду невозможно разобрать.
Что же влияет на нас первым делом, когда мы видим любой код? Это чистота и красота его написания. Создание чистого и красивого кода — это знак отличного мастера.
В изучении этого ремесла есть два направления: знание и работа. Знание учит вас шаблонам, принципам и методам, которые вам нужны для того, чтобы стать лучше в профессии. Но это знание нужно применять на постоянной практике и в упорной работе.
Вот несколько способов, которые могут помочь вам в искусстве написания чистого и красивого кода.
Начните с имени
Кендрик Ламар отлично сказал:
Если я захочу рассказать реальную историю, то я начну со своего имени.
Названия находятся в программе повсеместно. Мы называем наши функции, классы, аргументы и много других вещей. Мы называем файлы с исходниками, директории и всё, что внутри них. Мы постоянно придумываем новые имена, пока они не начинают засорять наш чистый код.
Название должно показывать намерение. Выбор хороших названий требует времени, но в итоге сохраняет его вам в будущем. Поэтому думайте о названиях и изменяйте их, если вдруг вы придумали имя получше. Помните, что название каждой переменной, функции или класса должно отвечать на три вопроса: почему оно существует, что оно делает и для чего используется.
Это требует не только хороших навыков описания, но и широкого культурного бэкграунда, и этому можете научиться только вы сами.
Функции должны делать одну вещь
Луис Салливан однажды сказал:
Форма следует за функцией.
Каждая система создается на основе предметно-ориентированного языка, который создан программистами для возможности точного описания. Функции являются глаголами этого языка, а классы — существительными. Функции должны быть первыми в очередь на организацию в любом языке программирования, и создание хороших функций — это суть написания хорошего кода.
Существует только два золотых правила создания чистых функций:
- Они должны быть небольшими
- Они должны делать одну вещь и делать ее хорошо
Это означает, что в вашей функции не должно содержаться вложенных структур. Таким образом, уровень отступа в функции не должен быть больше, чем один или два. Этот метод делает код проще для чтения и понимания. В дополнение к этому, нам нужно убедиться, что утверждения в нашей функции находятся на одном уровне абстракции. Смешивание уровней абстракции в функции приводит к коду, который нельзя будет исправить. Мастера-программисты думают о функциях, как об историях, которые нужно рассказать, а не как о коде, который нужно написать.
Они используют удобства выбранного языка, чтобы создавать выразительный и чистый блок кода, который будет хорошо рассказывать нужную историю.
Комментарии не исправят плохой код
Винус Уильямс заметила:
Каждый оставляет свои комментарии. Так рождаются слухи.
Комментарии — это обоюдоострый нож. Хорошо размещенный комментарий может быть очень полезен. Но с другой стороны, ничего так не засорит код, как бесполезные комментарии. И ничего не может так распространять дезинформацию, как комментарии.
Так что комментарии — это необходимое зло. Не всегда, но в большинстве случаев. Чем старше комментарий, тем сложнее становится его поддерживать, и многие программисты не выравнивают комментарии со своим кодом. Код двигается и развивается. Части кода перемещаются туда и сюда, а комментарии — нет, и это становится проблемой.
Григорий Петров: Зачем в коде комментарии
Всегда помните, что чистый и выразительный код с несколькими комментариями лучше, чем засоренный и сложный код с множеством комментариев. Не тратьте время на объяснение созданного беспорядка, лучше уберите его.
Форматирование кода — всегда приоритет
Форматирование кода — это коммуникация, а коммуникация — это приоритет для профессионального разработчика, — отмечает Роберт Мартин.
Отформатированный код — это окно в ваш разум. Мы хотим, чтобы люди были впечатлены нашим стремлением к порядку, вниманием к деталям и ясностью мысли. Но если они увидят непонятную массу кода без выраженного начала или окончания, это несомненно пошатнет вашу репутацию.
Если вы думаете, что главное, чтобы все работало, вы не правы. Функциональность, которую вы создаете сегодня, могут заменить в следующем релизе, но читаемость вашего кода не изменится.
Всегда знайте, что вас будут помнить за стиль и дисциплину, а не за ваш код. Поэтому вы должны позаботиться о том, чтобы ваш код был хорошо отформатирован и чтобы он подчинялся простым правилам, которые понимают все члены вашей команды.
Сначала напишите try-catch-finally
Жорж Кангилем правильно сказал:
Ошибаться — это по-человечески, постоянно ошибаться — это бесчеловечно.
Программисты постоянно справляются с ошибками. Входные данные могут быть ненормальными, и устройства могут выходить из строя. Как разработчики, мы должны убедиться, что код делает то, что ожидается. Однако проблема заключается не в обработке ошибки, проблема заключается в обработке ошибки с сохранением чистого читаемого вида.
Часто исправление ошибок сильно меняет код. Все становится таким разрозненным, что понять цель и логику главного кода становится сложно. Это неправильно. Код должен быть чистым и надежным, а ошибки должны быть исправлены с грацией и стилем. Это признак мастера в разработке.
Один из способов добиться этого — правильное размещение всех ошибок в блоках try-catch. Эти блоки определяют объем вашего кода. Когда вы выполняете часть кода в части try, вы утверждаете, что это выполнение может прерваться в любой момент времени и продолжиться в catch.
Поэтому, когда вы пишете код, хорошей практикой будет начать с утверждения try-catch-finally. Это поможет вам определить, чего ожидает пользователь, независимо от того, что произойдет неправильно с кодом в секции try.
Помните, что для каждого исключения вы должны описать достаточно контекста для того, чтобы определить источник и место ошибки. Творческие информативные сообщения об ошибках запомнятся надолго после того, как код был написан, а программисты ушли из организации.
Заключение
Каким словом можно обобщить все сказанное здесь?
Это чувство кода, аналог здравого смысла в программном обеспечении.
Согласно Роберту Мартину, «написание чистого кода требует дисциплинированного использования мириад маленьких техник, примененных для ощущения чистоты. Эти маленькие методы вместе образуют чувство кода».
Некоторые из нас рождаются с ним, а некоторые упорно приобретают его через практику. Это чувство кода не только помогает нам различать хороший и плохой код, но и позволяет нам формировать стратегии трансформации плохого кода в хороший. Чувство кода помогает программисту выбирать лучшие инструменты из доступных, чтобы создавать ценный, чистый и красивый код.
Подвести итог можно словами Гарольда Абельсона:
Если вы нашли опечатку — выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать [email protected].Программы должны быть написаны прежде всего для людей, которые будут их читать, и только потом для машин, которые будут их выполнять.
apptractor.ru
Как писать чистый и красивый код / RUVDS.com corporate blog / Habr
Каким должен быть качественный код? Роберт Мартин выразил это невероятно точно, когда сказал: «Единственная адекватная мера качества кода — это количество восклицаний «какого чёрта!» в минуту».
Позвольте мне пояснить эту идею.
Каждый раз, когда я читаю чужой код, вот какие мысли приходят мне в голову:
- Какого чёрта! (с отвращением) — когда в некоем фрагменте кода нет необходимости.
- Какого чёрта! (с восхищением) — когда программист сделал что-то очень удачное.
- Какого чёрта! (с раздражением) — когда я не могу понять тот ужас, который находится у меня перед глазами.
Итак, что формирует первое впечатление от кода? Это то, насколько он чист и красив. Подобный код является признаком высокого профессионализма того, кто его написал.
Путь к мастерству кодирования идёт через две важные вехи. Это — знания и труд. Знания дают шаблоны, принципы, практические приёмы, эвристические правила, которые нужны для профессионального роста. Но эти знания нужно закреплять. Тут в дело вступает механическая и зрительная память, знания должны прочно обосноваться у вас внутри через постоянную практику и упорный труд.
Короче говоря, обучение написанию чистого кода — это тяжёлая работа. Вы должны вложить в неё немало сил. Вам нужна практика. Причём, на этом пути будут моменты, когда дело стопорится, когда ничего не получается, но это вас останавливать не должно — шаг за шагом вы будете приближаться к совершенству, повторять всё снова и снова до тех пор пока всё не окажется таким, каким должно быть. Обходных путей здесь нет.
Вот несколько идей, руководствуясь которыми вы сможете продвинуться на пути освоения искусства написания чистого и красивого кода.
Имена
Кендрик Ламар как-то сказал: «Если я соберусь рассказать настоящую историю, я начну её с моего имени».
В мире программ мы встречаем имена буквально повсюду. Мы даём имена функциям, классам, аргументам, пакетам, да чему угодно. Имена придумывают для файлов с программным кодом, для папок, и для всего, что в них находится. Мы постоянно изобретаем имена, и поэтому имена часто становятся тем, что загрязняет код.
Имя, которое вы даёте сущности, должно раскрывать её предназначение, намерение, с которым вы её используете. Выбор хороших имён требует времени, но позволяет сэкономить гораздо больше времени, когда страсти накаляются. Поэтому уделяйте внимание именам, а если вам удаётся найти имя, которое лучше справляется с возложенной на него задачей — замените им то, что вы уже используете. Любой, кто читает ваш код, будет вам благодарен за ваше внимательное отношение к именам.
Всегда помните, что имя любой переменной, функции или класса, должно отвечать на три главных вопроса о некоей сущности: почему она существует, какие функции она выполняет, и как она используется.
Для того чтобы придумывать хорошие имена, нужно не только умение подыскивать подходящие слова. Тут требуется знакомство с общим для программистов всей Земли культурным контекстом, для которого не существует границ. Этому нельзя научить — каждый осваивает всё это самостоятельно, например — читая качественный код других людей.
Одна функция — одна задача
Луис Салливан однажды сказал замечательную вещь: «Форма следует функции».
Каждая система построена на основе языка, предназначенного для конкретной предметной области, который спроектирован программистами для точного описания этой области. Функции — глаголы этого языка, а классы — это имена существительные. Функции обычно являются первой линией организации любого языка программирования, и их качественное написание — это суть создания хорошего кода.
Есть всего два правила написания чистых функций:
- Они должны быть маленькими.
- Они должны решать лишь одну задачу и должны делать это хорошо.
Это означает, что функция не должна быть слишком большой, она не должна содержать вложенные структуры. Таким образом, если говорить об отступах при форматировании кода, их не должно быть больше, чем один-два. Такой подход упрощает чтение функций, их понимание и практическое применение. В дополнение к этому, мы, кроме того, должны обеспечить то, чтобы все выражения в функции находились на одном и том же уровне абстракции.
Смешивание уровней абстракции в функции всегда сильно сбивает с толку и ведёт, со временем, к появлению кода, которым невозможно нормально управлять. Опытные программисты видят в функциях нечто вроде историй, которые они рассказывают, нежели код, который они пишут.
Они используют механизмы выбранного ими языка программирования для создания чистых, выразительных, обладающих широкими возможностями блоков кода, которые, и правда, могут быть отличными рассказчиками историй.
Код и комментарии
Вот интересное наблюдение, которое сделала Винус Уильямс: «Все делают собственные комментарии. Так рождаются слухи».
Комментарии в коде напоминают обоюдоострый нож. Ничто не может быть более полезным, чем комментарий, сделанный к месту. С другой стороны, ничто не может захламить код сильнее, чем пустые, бесполезные комментарии, которые просто занимают пространство на экране. И ничто не может быть более разрушительным, чем комментарии, распространяющие дезинформацию и ложь.
Комментарии, в лучшем случае — это необходимое зло. Почему? Они не всегда — зло, но в большинстве случаев это так. Чем старше комментарии — тем сложнее становится поддерживать их в актуальном состоянии. Многие программисты запятнали свою репутацию тем, что их комментарии, в ходе развития проектов, перестали согласовываться с кодом.
Код меняется и развивается. Блоки кода перемещаются. А комментарии остаются неизменными. Это — уже проблема.
Всегда помните о том, что чистый и выразительный код с минимумом комментариев гораздо лучше запутанного и сложного текста программы, в котором имеется множество пояснений. Не тратьте время на то, чтобы объяснить созданный вами беспорядок, лучше уделите время наведению порядка в коде.
Важность форматирования
Роберт Мартин однажды очень точно подметил: «Форматирование кода направлено на передачу информации, а передача информации является первоочередной задачей профессионального разработчика».
Полагаю, нельзя недооценивать эту идею. Внимание к форматированию кода — это одна из важнейших характеристик по-настоящему хорошего программирования.
Отформатированный код — это окно в ваш разум. Мы хотим впечатлять других людей нашей аккуратностью, вниманием к деталям и ясностью мысли. Но если тот, кто читает код, видит беспорядочные нагромождения конструкций, мешанину, у которой нет ни начала, ни конца, это немедленно бросает тень на репутацию автора кода. В этом нет никаких сомнений.
Если вы думаете, что самое главное для профессионального разработчика — это «сделать так, чтобы программа заработала», это значит, что вы очень далеки от истины. Функционал, созданный сегодня, вполне может измениться в следующем релизе программы, но читаемость кода — это то, что оказывает воздействие на всё то, что с ним происходит, с самого начала его существования.
Стиль программирования и удобочитаемость кода продолжают влиять на сопровождаемость программы и после того, как её первоначальный облик был преобразован до неузнаваемости.
Учитывайте то, что вы запомнитесь тем, кто читает тексты ваших программ, по вашему стилю и аккуратности, и очень редко — по функционалу, реализованного в коде. Поэтому уделяйте внимание форматированию, например, придерживаясь правил, которые приняты в вашей организации.
Сначала — try-catch-finally, потом — всё остальное
Жорж Кангилем сделал верное наблюдение, когда сказал: «Человеку свойственно ошибаться, упорствовать в ошибке — дело дьявола».
Обработкой ошибок занимаются все программисты. Откуда берутся ошибки? В систему могут поступить аномальные входные данные, устройства могут давать сбои… От разработчиков ждут, чтобы они обеспечивали правильную работу созданных ими программ. Однако проблема заключается не в самой обработке ошибок. Проблема заключается в том, чтобы обрабатывать ошибки, не нарушая при этом читаемость и чистоту основного кода.
Многие программы сверх меры перегружены конструкциями обработки ошибок. В результате полезный код оказывается беспорядочно разбросанным по этим конструкциям. Подобное ведёт к тому, что то, что составляет цель программы, практически невозможно понять. Это — совершенно неправильно. Код должен быть чистым и надёжным, а ошибки надо обрабатывать изящно и со вкусом. Подобный подход к обработке ошибок — признак программиста, отлично знающего своё дело.
Один из способов качественной обработки ошибок заключается в правильном использовании блоков try-catch-finally. В них включают потенциально сбойные места, и с их помощью организуют перехват и обработку ошибок. Эти блоки можно представить себе как выделение изолированных областей видимости в коде. Когда код выполняется в блоке try, это указывает тому, кто читает код, на то, что выполнение в любой момент может прерваться, а затем продолжиться в блоке catch.
Поэтому рекомендуется выделять блоки try-catch-finally в самом начале работы над программой. Это, в частности, поможет вам определить, чего от кода может ждать тот, кто будет его читать, при этом неважно, выполнится ли код без ошибки, или во фрагменте, заключённом в блок try, произойдёт сбой.
Кроме того, всегда стремитесь к тому, чтобы каждое выданное вашей программой исключение обязательно содержало бы достаточно контекстной информации для определения источника ошибки и того места в коде, где она произошла. Конструктивные и информативные сообщения об ошибках — это то, что помнят о программисте даже после того, как он перешёл на новое место работы.
Итоги
Как выразить, буквально в двух словах, всё то, о чём мы говорили? Ответ на это вопрос — термин «чувство кода». Это, в мире программирования, эквивалент здравого смысла.
Вот что говорит об этом Роберт Мартин: «Чтобы написать чистый код, необходимо сознательно применять множество приёмов, руководствуясь приобретённым усердным трудом чувством «чистоты». Ключевую роль здесь играет чувство кода. Одни с этим чувством рождаются. Другие работают, чтобы развить его. Это чувство не только позволяет отличить хороший код от плохого, но и демонстрирует стратегию применения наших навыков для преобразования плохого кода в чистый код». По мне — так это золотые слова.
Чувство кода помогает программисту выбрать лучший из имеющихся у него инструментов, использование которого поможет ему в его стремлении создавать чистый и красивый код, приносящий пользу другим людям.
Программист, пишущий чистый код — это художник. Он способен превратить пустой экран в элегантное произведение искусства, которое будут помнить долгие годы.
В завершение нашего разговора о чистом коде вспомним слова Гарольда Абельсона: «Программы должны писаться, в первую очередь, для того, чтобы их читали люди, и лишь во вторую — для выполнения машиной».
Уважаемые читатели! Какие приёмы вы используете для повышения качества собственного кода?
habr.com
Как писать код, который никто не сможет сопровождать / Фонд развития интернет-инициатив corporate blog / Habr
Благодаря советам экспертов в области Java вы научитесь писать код, который будет настолько сложно сопровождать, что любому, кто будет с ним работать после вас, потребуются годы, чтобы внести даже малейшие правки. Более того, если будете неизменно следовать этим правилам, вы сможете гарантировать себе пожизненное рабочее место, так как никто кроме вас не сможет разобраться в вашем коде.
Основные принципы
Чтобы нарушить все планы вашего коллеги по сопровождению кода, вы должны понимать, как он мыслит. У него есть ваша гигантская программа, но нет времени на то, чтобы прочитать весь код и уж тем более разобраться в нем. Он хочет поскорее найти ошибку и исправить ее так, чтобы потом это никак не повлияло на дальнейшую работу системы.
Вот он уже изучает ваш код под лупой. В каждый конкретный промежуток времени он может видеть лишь небольшую часть вашей программы, и вам нужно убедиться в том, что он никогда не сможет увидеть всю картину целиком. Вы должны сделать так, чтобы он ни за что не смог найти то, что ему нужно. И, что еще важнее, вы должны настолько усложнить его работу, чтобы любое его упущение приводило к катастрофе.
Особые методы
1. Лгите в комментариях. Необязательно врать на каждом шагу: достаточно того, что комментарии никак не будут связаны с кодом.
2. Заполняйте код комментариями вроде /* прибавить 1 к i */, но никогда не указывайте в коде такие общие вещи, как назначение модуля или метода.
3. Убедитесь в том, что каждый метод делает чуть больше (или чуть меньше), чем предполагается в его названии. Например, метод isValid(x) может, помимо прочего, переводить x в двоичную систему и сохранять результаты в базе данных.
4. Используйте аббревиатуры, чтобы ваш код был лаконичным. Настоящие мужчины никогда не дают определений своим аббревиатурам: они понимают их на подсознательном уровне.
5. Для создания еще большего эффекта старайтесь не пользоваться инкапсуляцией. Тем, кто вызывает тот или иной метод, необходимы все возможные подсказки, которые напомнят им, как работает этот метод.
6. Если вы, скажем, разрабатываете систему бронирования авиабилетов, сделайте так, чтобы для добавления новой авиалинии код нужно было отредактировать как минимум в 25 разных местах. И никогда не указывайте в комментариях, где именно: те, кто собрался работать с вашим кодом, не имеют права вносить в него коррективы, если до конца в нем не разобрались.
7. В целях повышения эффективности копируйте и вставляйте куски кода по несколько раз. Так выйдет быстрее, чем создавать несколько модулей для их повторного использования.
8. Никогда не пишите комментарии к переменным. Данные об использовании переменной, ее границах, допустимых значениях, скрытом и отображаемом числе знаков после запятой, единицах измерения, форме представления, правилах заполнения переменной (например, максимальное количество знаков или обязательность заполнения), о том, можно ли доверять значениям этой переменной, и т. д. следует выявлять уже в ходе работы программы.Если ваш начальник заставляет вас делать комментарии, делайте их в теле метода, но никогда не пишите комментарии при объявлении переменных, даже временных.
9. Постарайтесь записать как можно больше данных в одну строку. В этом случае отпадает необходимость введения многих временных переменных, а также сокращается объем исходных файлов, так как остается меньше строк и лишнего пустого пространства.Преимуществом написания длинных строк кода является еще и то, что разработчикам, которые не могут прочитать текст с 6 кеглем, приходится увеличивать шрифт, чтобы разглядеть записи в строке.
10. Кд, нпсннй бз глснх, крч [код, написанный без гласных, короче]. Когда сокращаете названия переменных или методов, дайте волю фантазии и используйте несколько вариантов одного и того же слова, иногда записывая его в полном варианте. Так вы сможете бороться с бездельниками, которые пользуются текстовым поиском, чтобы разобраться лишь в одной из функций вашей программы.Подумайте над различными вариантами написания названий, которые могут запутать других. Например, можно одновременно использовать британский colour, американский color и специфичные варианты этого слова вроде kulerz.
В случае, когда вы записываете все имена полностью, у каждой из ваших переменных есть лишь один вариант написания. Специалист по сопровождению без труда сможет их запомнить. А раз одно слово можно сократить несколькими способами, то вы можете использовать несколько разных переменных для одной и той же цели. Более того, специалист по сопровождению ПО может и не заметить, что это несколько отдельных переменных.
11. Никогда не пользуйтесь автоматическим выравниванием кода. Попытайтесь каким-то образом повлиять на начальство, чтобы оно запретило его в вашей компании, аргументируя это тем, что автоматическое выравнивание вызывает непредвиденные изменения в системе управления версиями или потому что у каждого разработчика должен быть свой стиль выравнивания, и он должен оставаться нетронутым в любом из написанных им модулей.Запретить автоматическое выравнивание не так уж сложно, даже несмотря на то, что оно позволяет резко сократить число нажатий по клавишам и дней, потраченных на неправильное понимание плохо выровненного кода. Вы должны настоять на том, чтобы все использовали единый стиль форматирования не только при сохранении данных в общем репозитории, но и в процессе редактирования кода. Это вызовет всеобщий гнев сотрудников, а начальство для поддержания спокойствия будет вынуждено отменить автоматическое форматирование.
После этого вы можете случайно выравнивать код так, чтобы возникала оптическая иллюзия того, что тела циклов и условий выглядят длиннее или короче, чем должны быть, или ключевое слово else соответствуют не тому ключевому слову if.
12. Никогда не вставляйте фигурные скобки { } в своих блоках if-else, если этого не требует синтаксис. Когда в вашем коде несколько выражений и блоков if-else идут подряд, причем еще и с неправильным выравниванием, то вы можете запутать даже опытного коллегу.
13. Строго следуйте указаниям, предусматривающим отсутствие оператора goto, досрочного выхода из цикла и его прерываний, особенно, когда вы можете увеличить глубину цикла if-else как минимум еще на пять уровней.
14. Используйте длинные названия переменных, отличающихся друг от друга всего лишь одним символом или регистром. Идеальная пара переменных – swimmer и swimner.Используйте все возможные недостатки шрифтов, не позволяющих различать ilI1| или oO08, например, в случаях с parselnt и parseInt или D0Calc и DOCalc. В данной ситуации самый подходящий символ в названии переменной – это буква l, так как с первого раза ее не отличишь от константы 1.
Имена переменных также могут отличаться только регистром, например, HashTable и Hashtable.
15. Если временные рамки вас не поджимают, постарайтесь повторно использовать существующие имена несвязанных между собой переменных. Аналогично можете использовать одинаковые временные переменные для различных целей, уменьшая тем самым размер стека.Совсем жестоко будет, если вы немного измените переменную: в начале очень длинного метода вы можете присвоить переменной одно значение, а затем где-то в середине незаметно сменить его на другое – скажем, поменять начало отсчета индексной переменной с 0 на 1. Только убедитесь, что это изменение не фиксируется в документации.
16. Пользуйтесь строчной буквой l при обозначении констант типа long. Например, 10l гораздо легче спутать с 101, чем с 10L.
17. Игнорируйте общепринятые соглашения Java об именовании классов и переменных, согласно которым, например, классы обычно пишутся с заглавной буквы, переменные – со строчной, константы – полностью заглавными, слова внутри названия класса/переменной пишутся с заглавной буквы. Даже компания Sun не следует этим соглашениям (примеры – instanceof/isInstanceOf, Hashtable/HashTable). Не беспокойтесь, компилятор даже не выдаст вам предупреждения.Если все же ваше начальство заставляет вас следовать общепринятым соглашениям, каждый раз, когда у вас появляется выбор – стоит ли начинать с заглавной буквы или нет – пишите все прописными или пишите наугад, например, вы можете одновременно использовать inputFileName и outputfilename.
Более того, вы можете пойти на крайние меры и создать собственные безумно сложные правила именования, а потом упрекать других за то, что они этим правилам не следуют. Идеальный вариант – создать как можно больше имен переменных, слегка отличающихся друг от друга лишь регистром.
18. Никогда не используйте i как внутреннюю переменную в цикле. Можете выбрать любое название, но только не это. Вы можете специально использовать переменную i для других целей. Аналогично можно использовать n в качестве счетчика цикла.
19. Никогда не пользуйтесь локальными переменными. Как только почувствуете, что вам нужно сделать переменную локальной, объявите ее как объект или статическую переменную, чтобы щедро делится ею со всеми остальными методами класса.Вы избавите себя от лишней работы в дальнейшем, когда в других методах нужно будет объявить те же переменные. Разработчики C++ иногда идут еще дальше и объявляют все возможные переменные глобальными.
20. Никогда не документируйте ошибки, не определяемые компилятором. Если вам кажется, что в классе прячется баг, лучше об этом умолчать. Если у вас есть идеи по поводу того, как можно перестроить или переписать код, ради всего святого, нигде о них не пишите.Что если программист, работающий с этим кодом, увидит ваши комментарии? Что, если их увидит глава вашей компании или клиент? Вас же могут уволить.
21. Веселья ради можете подобрать как можно больше слов, обозначающих одно и то же действие, например, display, show, present. Неявно намекните, что между элементами программы якобы имеется небольшое различие, которого на самом деле нет.И наоборот, если видите две похожие функции, имеющие принципиальное отличие, всегда используйте одно и то же слово для описания этих функций. Например, слово print обозначает одновременно и запись в файл, и печать на принтере, и вывод на экран. Не слушайте никого, кто будет требовать вас дать определения всем специфичным терминам. Это было бы непрофессионально с точки зрения принципа сокрытия информации.
22. В названиях функций старайтесь использовать больше абстрактных понятий, таких как it, everything, data, handle, stuff, do, routine, perform, и цифр, например, routineX48, PerformDataFunction, DoIt, HandleStuff и do_args_method.
23. В Java все параметры базового типа фактически доступны только для чтения, потому что они передаются по значению. Вызываемая процедура может изменить эти параметры, но не окажет никакого влияния на значения переменных в вызывающей процедуре. Все объекты, напротив, можно изменять, так как в данном случае по значению передается ссылка на эти объекты, то есть сам объект передается по ссылке. Поэтому вызываемая процедура как угодно может менять поля в вашем объекте.Никогда не говорите о том, может ли метод изменять поля в каждом из передаваемых параметров. Названия ваших методов должны указывать на то, что сами методы могут только считывать значения этих полей, хотя на самом деле эти методы могут их изменять.
24. Никогда не указывайте в комментариях единицы измерения любого типа переменных – входных, выходных или параметров, будь то футы, метры или ящики. Это имеет большое значение не столько для точности расчетов, сколько для процесса разработки в целом.Как следствие, не указывайте в комментариях коэффициенты пересчета каких-либо единиц измерения или методы, с помощью которых были получены итоговые значения. Простой и очень эффективный способ – записывать в комментариях неправильные единицы измерения.
Если у вас совсем нет совести, можете придумать свои единицы измерения, назвав их своим именем или именем никому не известной личности и не дав никаких пояснений. Если к вам придерутся, можете сказать, что таким способом вы отделяете целочисленные расчеты от операций над числами с плавающей точкой.
25. Инженерные расчеты можно запрограммировать двумя способами. Первый способ: перевести все входные значения в систему СИ, выполнить расчет и затем перевести выходные значения в соответствующие единицы измерения. Второй способ: проводить вычисления в различных смешанных системах измерения. Всегда выбирайте второй способ.
26. Еще одна малоизвестная хитрость. Исключения доставляют слишком много проблем. Хорошо написанный код никогда вас не подведет, так что в принципе можно обойтись и без исключений: нечего тратить на них свое время. Выделение подкласса исключений – это занятие для невежд, которые знают, что их программа не будет работать.Вы можете значительно упростить свою программу, если оставите во всем приложении (в методе main) единственный оператор try-catch, который вызывает метод System.exit().
27. Компиляторы языка C преобразуют выражение myArray[i] в выражение *(myArray + i), которое эквивалентно выражению *(i + myArray), которое, в свою очередь, эквивалентно выражению i[myArray]. Настоящие профессионалы знают, как использовать эту особенность в своих целях. Этот способ, к сожалению, применим только в «родных» классах.
28. Если у вас имеется массив из 100 элементов, старайтесь как можно чаще присваивать переменным конкретное значение 100. Не используйте статических ненаследуемых констант вместо этого значения и не ссылайтесь на него через свойство myArray.length. Чтобы это значение было еще сложнее изменить, вы можете использовать другие конкретные числа, к примеру, 50 вместо 100/2 или 99 вместо 100-1. Можно еще больше завуалировать это значение, заменяя выражение a > 100 на a == 101 или выражение a >= 100 на a > 99.Нужно также учитывать такие особенности, как формат страницы, которая состоит из заголовка x, основного текста y и примечаний z. Вы самостоятельно можете создать путаницу одновременно как в каждой из частей кода, так и в их комбинации или общей сумме.
Эти проверенные временем способы эффективнее всего работают, когда в программе есть два несвязанных массива, которые по счастливой случайности содержат по 100 элементов каждый. Для таких случаев есть еще более изощренные методы. Для того чтобы усыпить бдительность специалиста по сопровождению, создайте именованную константу и раз за разом совершенно случайно используйте конкретное значение 100 вместо именованной константы.
Но, помимо всего этого, самым гадким поступком в данной ситуации будет использовать время от времени другие отдельные константы, которые в данный момент времени чисто случайно будут равняться 100. Таким образом, вы фактически должны избегать использования определенной системы имен, которая бы могла связать имя массива с константой, равной его длине.
29. Избегайте любых форм табличной логики. Она только кажется безобидной, однако вскоре приводит к тому, что конечные пользователи начинают в ней разбираться, а затем и подстраивать таблицы под себя.
30. Постарайтесь максимально усложнить структуру кода. Умелые программисты могут вставить до 10 пар круглых скобок ( ) в одной строке и до 20 пар фигурных скобок { } в одном методе. Настоящие мастера умеют располагать начало и конец блока на разных страницах листинга. По возможности в циклах с условием вместо if используйте тернарные операторы [?:].
31. Поищите пособия по программированию, чьи авторы чаще пишут книги, чем программы. Можете зайти в местный книжный магазин и отобрать книги, в которых есть масса сложных диаграмм и ни одного примера написания кода. Бегло просмотрите эти книги и выберите в них чересчур умные слова. Эти слова можно использовать для того, чтобы отпугнуть самонадеянных новичков, претендующих на ваше место.Ваш код должен производить на других впечатление. Если другие не разбираются в терминологии, которую вы используете, то они будут думать, что вы очень умный, а ваши алгоритмы слишком сложные. Не надо использовать примитивную лексику, когда объясняете, как работает ваш алгоритм.
32. Постоянно вносите изменения в свой код и вынуждайте пользователей как можно чаще обновляться: в конце концов, никто не хочет работать с устаревшей версией вашей программы. Несмотря на то, как сильно пользователям нравится работать в вашей программе, только представьте, какое удовольствие они получат после того, как вы ее «улучшили».Никому не говорите, что именно вы изменили в новой версии, если от вас этого не требуются: зачем рассказывать о багах в старой версии, которые никто бы так и не заметил?
33. В разделе «О программе» следует указывать только название программы, имена разработчиков, а также предупреждение о нарушении авторских прав, состоящее из одних юридических терминов. В идеале он должен содержать ссылку на несколько мегабайт кода, которые выдают красивую анимацию. Но ни в коем случае не надо указывать в нем фактическое назначение программы, дополнительный номер версии, дату последнего изменения в программе, сайт, на котором можно получать обновления, или e-mail автора программы. При таком подходе все пользователи вскоре станут работать с разными версиями программы и пытаться установить сразу версию N+2 вместо версии N+1.
34. Чем больше изменений вы можете внести, тем лучше. Вы ведь не хотите, чтобы один и тот же API или пользовательский интерфейс все больше надоедал вашим пользователям. Кроме того, если вы можете внести изменения так, что ваши пользователи этого не заметят, это тоже плюс: так они не будут расслабляться, находясь в постоянном ожидании.
35. Если вам нужно написать классы, которые будет использовать другой разработчик, вставьте код для проверки переменных окружения (getenv() в C++, System.getProperty() в Java) в статические безымянные инициализаторы ваших классов, а затем передайте в таком виде все свои аргументы классам, вместо того чтобы делать то же самое в конструкторе.Преимуществом такого подхода является то, что инициализаторы вызываются во время загрузки модулей программы, до создания экземпляров класса, то есть, как правило, они будут исполняться перед функцией main(). Другими словами, программа не сможет изменить эти параметры до того, как они окажутся в ваших классах: значения переменных окружения у пользователей должны быть такими, какими установили их вы.
36. Выбирайте для переменных названия, не связанные с соответствующими им надписями, которые появляются после запуска программы. Например, если одно из полей на экране подписано как Postal code, то соответствующей переменной вы можете дать название zip.
37. Java позволяет создавать методы, имеющие то же название, что и классы. При этом сами методы могут не являться конструкторами. Используйте эту возможность, для того чтобы всех запутать.
38. Никогда не пользуйтесь менеджерами размещения. Таким образом, когда специалист по сопровождению продукта добавит новое поле, ему придется вручную подбирать абсолютные координаты каждого элемента на экране. Если начальство заставляет вас использовать менеджеры размещения, пользуйтесь одним режимом GridBagLayout, а в качестве координат сетки выбирайте конкретные значения.
39. Забейте на интерфейс Java. Если ваше руководство станет предъявлять к вам претензии, скажите, что интерфейсы Java вынуждают вас копировать код в различные классы, которые одинаково реализуют один и тот же интерфейс, а ваше начальство знает, как тяжело будет сопровождать этот код.Следуйте примеру разработчиков Java AWT – заполняйте свои классы богатым функционалом, который могут использовать только наследуемые классы, и выполняйте частую проверку в своих методах с помощью оператора instanceof. Получается, что любому, кто захочет несколько раз воспользоваться вашим кодом, придется расширять ваши классы. Если кто-то захочет использовать ваш код из двух разных классов, то им не повезло – они не смогут расширить оба класса одновременно.
40. Определите все свои классы, у которых нет наследников, при помощи ключевого слова final. В конце концов, свою работу на проекте вы выполнили, и никто не сможет его улучшить за счет расширения ваших классов. Более того, это может вызвать проблемы в системе безопасности. Именно поэтому класс java.lang.String объявлен как final. Если другие разработчики на вашем проекте начнут возмущаться, скажите им, что работаете над улучшением производительности программы.
41. Объявите как можно больше переменных статическими. Если в этой программе вам достаточно одного экземпляра класса, значит, и всем остальным этого будет достаточно. Если другие разработчики в вашем проекте начинают предъявлять свои претензии, также скажите им, что решаете проблему производительности.
42. Храните все неиспользуемые или устаревшие методы и переменные в коде. Если когда-то в 1976 году в них возникала необходимость, что, если она возникнет и на этот раз? Конечно, с тех пор программа сильно изменилась, но все эти изменения можно легко отменить: вы же не станете «изобретать велосипед» (любимая поговорка менеджеров). Если вы оставите в комментариях все эти методы и переменные нетронутыми и не совсем понятными, то все, кто будут сопровождать ваш код, тоже побоятся что-либо менять.
43. К методу makeSnafucated добавьте один комментарий /* make snafucated */. Нигде не указывайте, что на самом деле обозначает слово snafucated. Всем уже пора знать такие элементарные вещи.
44. Измените порядок следования параметров в методе drawRectangle(height, width) на drawRectangle(width, height), не меняя при этом названия самого метода. Затем после нескольких релизов, измените этот порядок обратно. С первого раза очень сложно догадаться, какой из вариантов используется в программе. Оставим задачу понимания работы метода коллегам.
45. Вместо того чтобы передавать параметры в один метод, создайте как можно больше отдельных методов. Например, в методе setAlignment(int alignment)переменная alignment является константой, определяющей выравнивание по левой и правой стороне и по центру. Вместо одного этого метода вы можете создать три: setLeftAlignment, setRightAlignment, и setCenterAlignment. Для еще большего эффекта можете скопировать общий код в каждый из методов, чтобы их сложнее было согласовывать между собой.
46. У метода Камасутры есть особое преимущество: он позволяет рассеять внимание как пользователей и составителей документации, так и специалистов по сопровождению ПО. Создайте множество перегруженных вариантов одного и того же метода, отличающихся друг от друга в незначительных деталях. По-моему, Оскар Уайльд однажды заметил, что в Камасутре позы 47 и 115 отличались лишь тем, что в позе 115 у женщины были скрещены пальцы. Пользователям же приходится тщательно просматривать длинный список методов, чтобы выбрать наиболее подходящий вариант.Кроме того, благодаря этому методу увеличивается объем документации а, следовательно, и вероятность того, что она окажется устаревшей. Если ваш начальник будет спрашивать, зачем вы так поступаете, поясните, что делаете это исключительно для удобства пользователей. Для еще большего эффекта, как и в других случаях, вы можете скопировать общую часть кода в каждый из методов.
47. Объявите все методы и переменные публичными. Рано или поздно кому-то это понадобится. Если метод является публичным, от него будет тяжело избавиться: так сложнее будет вносить коррективы в работу программы. Помимо этого, такой подход позволяет скрыть реальное назначение класса. Если начальство начнет к вам придираться, скажите, что вы всего лишь следуете традиционным принципам проектирования «прозрачных» интерфейсов.
48. Перегружайте функции из библиотеки C++, используя директиву #define. В этом случае все будет выглядеть так, будто вы используете функцию, хранящуюся в библиотеке, хотя на самом деле она не имеет к ней никакого отношения.
49. В C++ вы также можете перегружать операции «+», «-», «*»», «/», чтобы выполнять действия, совершенно отличные от сложения, вычитания, умножения и деления. Если уж Страуструп догадался использовать оператор сдвига для осуществления ввода/вывода, разве вы не сможете придумать что-то похожее? Когда перегружаете операцию «+», убедитесь, что выражение i = i + 5; никак не связано с выражением i += 5;
50. При составлении документации для файла лучше подобрать случайное название вроде file, а не такие очевидные имена, как Charlie.dat или Frodo.txt. Если говорить в общем, то старайтесь в своих примерах подбирать случайные названия, максимально похожие на зарезервированные ключевые слова.К примеру, для названия параметра или переменной отлично подойдут такие варианты, как bank, blank, class, const, constant, input, key, keyword, kind, output, parameter, parm, system, type, value, var и variable. Если в названиях вы используете зарезервированные слова, которые не принимает командный процессор или компилятор, то это еще лучше. Если у вас все получится, пользователи просто запутаются в ключевых словах и выбранных вами названиях, а вы будете здесь ни при чем, потому что хотели лишь помочь им связать назначение каждой переменной с ее именем.
51. Всегда используйте особый синтаксис команд, определяемый вашей собственной версией БНФ (формы Бэкуса-Наура). Никогда не поясняйте значение своего синтаксиса, представленного в виде набора допустимых и недопустимых команд: это будет говорить о низком уровне вашей компетенции. То же касается и использования синтаксических диаграмм.Проследите за тем, чтобы разницу между конечными символами (теми, что можно ввести) и промежуточными символами (которые представляют собой одну из фраз синтаксиса) увидеть было не так просто. Старайтесь не создавать визуальных подсказок в виде особого шрифта, цвета или заглавных букв, которые могут помочь проверяющему определить эту разницу.
В своей БНФ используйте те же знаки препинания, что и в языке команд: те, кто пытаются разобраться в вашем коде, будут долго думать, составляют ли символы (…), […], {…} и «…» часть вводимой вами команды или же их цель – показать, какие элементы синтаксиса вашей БНФ обязательны к использованию, какие – необязательны, а какие – просто повторяются. В конце концов, если они настолько глупы, что не могут понять суть вашей БНФ, то им просто нет смысла дальше работать с вашей программой.
52. Препроцессор макросов предлагает много возможностей для того, чтобы запутать тех, кто будет читать ваш код. Основным приемом является размещение макроса на несколько уровней вглубь кода, так что остальным приходится искать его различные компоненты в разных файлах формата *.hpp. Если вы вставите исполняемый код в макросы, а затем поместите эти макросы в каждый из файлов формата *.cpp (даже в файлы, не использующие эти макросы), то вы максимизируете число повторных компиляций, в случае если в код будут внесены изменения.
53. Объявление массивов в Java можно осуществлять разными способами. Вы можете объявлять массив по-старому, как в языках C, в виде String x[] (скобки идут после имени переменной) или по-новому в виде String[] x (скобки ставятся после типа данных). Если хотите окончательно запутать других, то можете смешать оба метода.
54. Java дает возможность запутать других во время преобразования типов переменных. Простой пример: вы, конечно, можете конвертировать тип double в String напрямую через Double.toString(d), но лучше сделать это по-другому, записав new Double(d).toString. Если хотите, можете придумать что-то более изощренное.Однако не пользуйтесь методами преобразования, рекомендованными в Conversion Amanuensis. Чем больше временных объектов заполняет динамическую память после преобразования, тем лучше.
55. Как можно чаще пользуйтесь потоками.
P.S. Больше материалов по теме стартапов в наших блогах на Geektimes и Megamozg.
habr.com
Как важно писать хороший код / Habr
Мне приходится очень много читать код. Это и open source, и всяческие фреймворки, и код enterprise приложений. Именно о последних я хотел бы сегодня поговорить.Большая часть кода enterprise приложений — отстой. Приложения глючат и тормозят, их сложно тестировать, постоянно проблемы с развертыванием и обновлением. Это как бы никого не удивляет.
Но удивляют люди, написавшие отстойный код. Эти люди, с немалым опытом, знают несколько языков, прочитали много книг, знают ООП, SOLID, рефакторинг, паттерны и другие малопонятные слова. То есть примерно такие, как многие из вас, читающих этот пост.
Теория разбитых окон
В 1969 году был проведен эксперимент. В ходе эксперимента две одинаковые машины были оставлены в двух местах – в благополучном университетском городке и неблагополучном районе крупного города. Не удивительно что в неблагополучном месте машина простояла всего пару дней и была выпотрошена, а в благополучном машина простояла нетронутой неделю. Но как только в уцелевшей машине разбили стекло, жители этого самого благополучного городка за несколько часов разобрали её на детали и перевернули вверх дном.
В последствии ученые назвали это явление “Теорией разбитых окон”. Согласно теории, любое проявление беспорядка или нарушение норм провоцирует людей также забыть о правилах. Теория получила несколько экспериментальных подтверждений и её можно считать вполне достоверной.
Есть также и обратный эффект. Поддержание порядка приводит к тому, что окружающие также поддерживают порядок.
Как это влияет на код
В enterprise разработке прессинг сроков и неопределенности требований бывает настолько высок, что кажется сделать “быстро и грязно” – гораздо лучший вариант, чем сделать правильно. Моментально подход “быстро и грязно” начинает распространяться по всему приложению, как путем clipboard inheritance (aka copy-paste), так и за счет эффекта разбитых окон.
Еще один фактор влияющий на качество кода – сложность и несовершенство платформ и фреймворков, используемых в разработке. Из-за этого в коде часто появляются хаки и нелепые workaround-ы. Со временем начинает казаться что эти хаки и есть хороший код. Даже когда проблемы фреймворков исправляют, люди продолжают использовать хаки. Кстати эти хаки со временем могут попадать в интернет через форумы, блоги или pastebin и распространяться далеко за пределы одного приложения.
Вы можете сказать, что качество кода не влияет на качество приложения. Увы, еще как влияет. Программисты допускают ошибки. Чем более плохой код, тем сложнее эти ошибки найти и исправить так, чтобы не создать новых. Прессинг сроков и сложности, скорее всего, не даст написать хороший код и появится еще один хак.
В open source и продуктовой разработке такое встречается реже. Там больше следят за качеством и меньше прессинг сроков.
Код пишется для людей
Часто программисты забывают что код программ пишется в первую очередь для людей. Даже если вы пишите программу в одиночку, то посмотрев на нее через месяц, вы не вспомните почему написали тот или иной кусок кода и за что он отвечает.
Хороший код должен, в первую очередь, очень ясно выражать намерения. К сожалению “быстрые и грязные” способы разработки бьют в первую очередь по понимаемости кода. Улучшение кода осознанно откладывается до лучших времен, когда будет пауза чтобы провести рефакторинг. Те самые лучшие времена никогда не наступают, а код начинают читать и дорабатывать сразу же после попадания в source control.
Даже если вы полностью довольны свои кодом (в большинстве случаев программисты свои кодом довольны), то подумайте о том как будет ваш код читать другой человек (в большинстве случаев программисты недовольны чужим кодом).
Приверженность качеству
Единственный способ добиться высокой продуктивности и эффективности – писать хороший код сразу. Единственный инструмент повышения качества кода – вы сами. Если вы не стремитесь всегда делать хороший код, то вам не помогут ни тесты, ни инструменты статического анализа. Даже ревью других программистов не поможет. Код всегда можно сделать настолько запутанным, что в нем невозможно будет найти ошибку при чтении, при этом сделать вид, что код очень важен и никто не возьмется его переписать.
В первую очередь необходимо думать о структуре и именовании. Код с зашифрованными идентификаторами и малопонятным потоком исполнения скорее всего будет содержать ошибки. Не допускайте такого кода, это гораздо дешевле, чем исправлять ошибки.
Ясно выражайте намерения в своем коде, сводите к минимуму неочевидные неявные аспекты. Не надо стремиться сделать код максимально лаконичным, стремитесь сделать его максимально понятным.
Если вам приходится править код, то не создавайте хаков. Потратьте немного времени, напишите нормально. Сэкономите на поддержке. Если же код совсем плохой, был сделан “быстро и грязно” и оброс хаками, то просто выкиньте его и перепишите. Только не надо пытаться переписать все. Учитывайте продуктивность: программист пишет 40-60 отлаженных строк кода в день в нормальном темпе и 120-200 в ускоренном (высокая концентрация, четкая цель, понятно что делать).
Если вы сами пишете “быстро и грязно”, например прототип для уточнения требований, то выкиньте код и перепишите нормально сразу после того, как ваш код сделает свое дело.
Если вы скопировали часть кода из другого места или, не дай бог, из интернета, то разберитесь как он работает, прежде чем заливать изменения в source control. Вообще не используйте непонятные для вас фрагменты кода.
Всегда поддерживайте чистоту и порядок в вашем коде, пользуйтесь инструментами, которые помогают вам это делать. Не будете этого делать – код очень быстро превратится в помойку. Собирайте статистику по плотности проблем в коде, это поможет вам лучше понять, как писать хороший код.
Перечитывайте свой код. Проводите рефакторинг постоянно в процессе написания. Помните, что рефакторинг “потом” никогда не наступает.
Думайте о том, какой код вы хотите написать, до того как начать его писать. Само написание кода – настолько поглощающий процесс, что думать о качестве некогда. Состояние потока – это состояние свободы самовыражения. Необходимо заранее ограничить самовыражение, чтобы код получился хорошим.
Экономика качества кода
Все знакомы с кривой стоимости ошибки:
Ошибка найденная и устраненная на этапе кодирования в 10 раз дешевле, чем ошибка найденная при тестировании и в 100 раз дешевле ошибки, найденной в production. В истории есть реальные примеры ошибок, исправление которых обошлось в десятки тысяч долларов.
Поэтому очень важно устранять ошибки на этапе разработки, причем усилиями самих разработчиков.
Напоследок
Не путайте хороший и идеальный код. Идеального кода не существует, нет смысла заниматься бесконечным улучшением в стремлении к идеалу. Хороший код – это код который читаем, понятен, решает задачу, правильно структурирован и не содержит ошибок. Писать хороший код не просто ваша цель, это ваша обязанность.
habr.com
❶ Как написать код для сайта 🚩 html коды для создания сайта 🚩 Веб-программирование
В наше время существуют конструкторы для создания сайтов, которые позволяют конструировать веб-проект в режиме WYSIWYG (что видишь, то и получаешь).
Действительно, можно в визуальном режиме изменять дизайн сайта, и сразу оценивать результат. Текст добавлять тоже несложно — достаточно его просто напечатать, выбрать необходимый шрифт, размер и прочие атрибуты. Точно так же обстоит дело и со вставкой изображений.
Зачем же тогда учить html? Что это вообще такое?
HTML — это язык гипертекстовой разметки документов. И он вам совершенно необходим по крайней мере в двух случаях:
1. Вы хотите полностью отказаться от использования конструктора сайтов, так как желаете всё делать самостоятельно.
2. Вы решили изучать язык веб-программирования.
Как в первом, так и во втором случае без знания html вам не обойтись. Во втором случае вам нужны эти знания, так как они являются базовыми для изучения языков веб-программирования.
Запаситесь терпением. Это едва ли ни самая главная вещь в обучении. Помните, что поначалу у вас вряд ли будет получаться.
Теорию знать необходимо, так как без четкого понимания, как работает та или иная языковая конструкция, вы вряд ли сможете конструировать полноценные сайты. Но гораздо более важной вещью является практика. Получив любые знания в области html, сразу применяйте их на практике. Не смотрите на дизайн страничек, смотрите на их функциональность, на то, как работает то, что вы применили. Помните, что в разных браузерах написанное вами может слегка отличаться по функциональности. Если что-то не работает так, как ожидалось, попробуйте открыть страничку в другом обозревателе.
Поделите все теги условно на 2 категории: служебные и контентные. В то время, как первые используются исключительно в служебных целях, с помощью тегов второй категории формируется всё содержимое ваших веб-страниц. Такое деление поможет вам лучше понять структуру языка, а также отделить одно от другого.
Ни одного дня не проводите без учебы. Регулярность занятий — залог успеха. Вы можете узнать новую информацию, или применить её на практике. Главное — делать это каждый день.
Обучаясь таким образом, консультируясь в процессе обучения на различных сайтах и форумах, вы обязательно придёте к успеху. Но помните, что изучение html — это только маленькая вершина огромного айсберга. Впереди CSS, Javascript, затем языки веб-программирования. Поэтому прочные знания по html станут залогом дальнейшего успешного обучения искусству web.
www.kakprosto.ru
Как написать чистый код
Сделать код чистым и красивым — прекрасный способ успевать к дедлайну Роберт Мартин попал в точку с одним своим емким высказыванием: «Единственно верным показателем измерения качества кода является единица «Какого чёрта/минуту» (или «What-The-F**ks/Minute» в оригинале).
Позвольте мне пояснить, что это значит. Каждый раз, когда я делаю обзор кода, мой мозг воспроизводит одну из трёх эмоций:- «WTF?! Какого чёрта?!» (с отвращением) — это не то… всё очень плохо….
- «WTF?! Какого чёрта?!» (с восхищением) — хм, это делал смышленый парень!
- «WTF?! Какого чёрта?!» (с раздражением) — какая-то неразбериха, о чём тут вообще речь?!
Что в имени тебе моем
Кендрик Ламар (Kendrick Lamar, американский хип-хоп исполнитель, — прим. ред.) однажды точно подметил: «Если я собираюсь рассказать реальную историю, то должен начать со своего имени». Имена в разработке программного обеспечения повсюду. Мы именуем функции, классы, аргументы, пакеты, программы — всё, что угодно. Мы именуем исходные файлы и справочники и всё с этим связанное. Мы бесконечно что-то именуем, и это становится важнейшей частью работы над созданием чистого кода. Имя, которое вы даёте чему-либо, должно отражать намерение. Найти хорошее имя непросто, это требует времени, но и значительно экономит его, когда приходится разбираться с кодом и ситуация становится сложной. Поэтому отнеситесь к этому процессу внимательно и не бойтесь менять имена позднее, если вам удалось найти более подходящее. Все, кто будет иметь дело с вашим кодом, будут вам очень благодарны.Помните о том, что имя любой переменной, класса, функции должно отвечать на три главных вопроса: почему она (переменная, функция и т.д.) существует, что она делает и для чего используется. Это требует не только хороших описательных навыков, но и общей эрудиции, широкого кругозора. И никто не обучит вас этому лучше, чем вы сами. |
“Одна функция” — одна вещь
Луис Салливан (Louis Henry Sullivan, американский архитектор-рационалист и модернист) однажды прекрасно сказал: “функция определяет форму”. Говорил он это об архитектуре домов, но сути это не меняет. Каждая система строится на неком предметно-ориентированном языке, который создают программисты, чтобы точно её описать. Функции выполняют роль глаголов этого языка, а классы — это существительные. Чаще всего функции являются первостепенными в организации языка программирования, и грамотное их написание является сутью создания хорошего кода. Есть всего два золотых правила качественного написания функций:- Они должны быть небольшими
- Они должны выполнять что-то одно, одну задачу, и делать это хорошо
“Комментарии не компенсируют плохой код”
Винус Уильямс (Venus Williams, американская теннисистка, пятикратная победительница Уимблдонского турнира) попала в точку, сказав: «Все оставляют свои комментарии. Так и появляются слухи». Комментарии — это как обоюдоострый меч.Оставленный к месту комментарий — очень полезная штука. С другой стороны, ничто так не захламляет пространство, как фривольные, бесполезные комментарии. Но самыми пагубными являются комментарии, распространяющие дезинформацию и ложь. Короче говоря, комментарии — это своего рода необходимое зло. Не всегда, но по большей части. Почему? Всё просто, чем старше комментарий, тем сложнее его поддерживать, и большинство программистов, как вы знаете, далеко не всегда меняют комментарии, вместе с изменениями в коде. Код движется и развивается. Части кода перемещаются туда-сюда, а комментарии нет. И это становится проблемой!Помните: чистый и чёткий код с небольшим количеством комментариев гораздо лучше, чем сложный загромождённый код. Не тратьте силы на объяснение того хаоса, который вы создали в комментариях. Лучше потратьте это время на устранение этого беспорядка. |
“Форматирование кода — всегда в приоритете”
Это сказал не кто иной, как Роберт С. Мартин (Robert Cecil Martin), он же — дядя Боб, разработчик, автор множества книг по разработке ПО, консультант, соавтор манифеста Agile и так далее. И добавил: «Форматирование кода — это своего рода коммуникация. А коммуникация — это первоочередная задача для любого профессионального разработчика». Вышеприведённое утверждение нельзя недооценивать, ведь оно говорит об одной из важнейших характеристик отличного разработчика. Отформатированный код позволяет взглянуть вглубь вашего сознания. Мы хотим впечатлить людей своей аккуратностью, вниманием к деталям, умением упорядочить и ясно выражать свои мысли. Но если, глядя на код, люди видят какую-то путаницу, напоминающую винегрет, не имеющего ни начала, ни конца, это сводит на нет ваши старания и понижает репутацию разработчика. Даже не сомневайтесь в этом! Вы очень далеки от истины, если считаете, что главное в этом бизнесе — чтобы “код просто работал”. Функциональность, которую вы сегодня создаёте, с высокой долей вероятности будет изменена в следующем релизе.А вот читаемость кода не изменится. Стиль кода и его хорошая читаемость облегчают поддержку кода на долгое время, даже после того, как оригинальный код был изменён до неузнаваемости.| Никогда не забывайте о том, что в будущем скорее всего будут вспоминать не ваш код сам по себе, а ваш стиль и системность. Поэтому позаботьтесь о том, чтобы код был грамотно отформатирован и подчинялся простым правилам, понятными всем членам команды. |
Сначала создайте блок «try-catch-finally»
Жорж Кангилем (Georges Canguilhem, историк науки, философ) справедливо отметил: “Ошибаться — естественно для человека, но вот настаивать на ошибках — это от дьявола”. Работа над ошибками — это то, что делают все программисты. На вход могут попасть неверные данные и и устройства могут выходить из строя. И, как разработчики, мы должны убедиться, что код делает то, что должен. Вопрос состоит не просто в обработке ошибки, а в её “чистой и легко читаемой” обработке. Многие программы подстраиваются под обработку ошибок. Если так поступать, всё погружается в такой хаос, что уничтожается цель и логика основного кода. Это неправильно, так не должно быть. Код должен быть чистым и надёжным, а обработка ошибок должна спокойно и естественно вплетаться в этот код. Это — показатель высокого класса программиста. И один из способов добиться этого — это правильные вложения и охват всех ошибок в блоках try-catch. Эти блоки определяют рамки применения вашего кода. Когда вы выполняете код в try-части блока try-catch-finally, вы утверждаете, что это выполнение может оборваться в любой момент времени, а затем возобновиться в catch. Поэтому рекомендуем начинать с try-catch-finally, когда вы пишете код. Это поможет определить, что может ожидать от кода пользователь, независимо от того, что с кодом пойдёт не так во время работы try.| Всегда помните, что каждое исключение, которое вы выбрасываете, должно содержать достаточно контекста для определения местоположения и источника ошибки. Созидательные и информативные сообщения об ошибках запоминаются надолго после написания кода, даже когда программист уже занят совершенно другими задачами. |
Подведём итоги
Подытожить всё вышесказанное нам поможет одно непривычное словосочетание. Это code-sense или “чутьё здравого кода”, этакий программистский эквивалент здравого смысла. Со слов Роберта Мартина: «Написание чистого кода требует систематического использования множества маленьких приёмов, применяемых в результате скрупулёзного и несколько болезненного чувства «чистоты». Эти небольшие приёмы в совокупности называются code-sense». У некоторых из нас это “чутьё здравого кода” есть изначально, другим же приходится развивать его проявляя настойчивость в практике. Это чутьё помогает не просто распознать разницу между плохим и хорошим кодом, но и помогает в формировании стратегий, нацеленных на трансформацию плохого кода в хороший. Плохой код портит всё. Если говорить образно, то если самый вкусный торт глазурирвоать собачьим дерьмом, то…эээ… вряд ли он кому-то понравится. Чутьё здравого кода помогает программисту использовать нужные инструменты для достижения своей цели — создание чистого кода. Программист, понимающий что такое code-sense — это художник, способный на пустом экране создать произведение искусства, которое запомнится на долгие годы. Как подытожил Гарольд Абельсон (Harold «Hal» Abelson, профессор компьютерных наук в Mit, директор-основатель Creative Commons и Free Software Foundation): «В первую очередь программы нужно писать так, чтобы их мог прочесть человек, и уж затем — чтобы их выполняла машина». Что можно почитать по теме: “A handbook of Agile Software Craftsmanship” — Robert Martin. “A handbook of Agile estimation” — Mike Cohn Об авторе: Рави Шанкар Раджан (Ravi Shankar Rajan) — Global Manager IT-программ из Мумбаи (Индия). Известный блоггер, поэт хокку, заядлый любитель археологии и истории. Связаться с ним можно в Twitter, Medium , LinkedInjavarush.ru