Как стать автором
Обновить

Почему читабельность кода имеет значение?

Совершенный код *
Перевод
Понятно, что напрашивающийся (и правильный) ответ — «Потому что код приходится не только писать, а и читать». Едва ли этот ответ стоит целого поста, но автор им не ограничивается.

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

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

Разработчики не только пишут код — большую часть нашего времени мы добавляем, убираем и редактируем небольшие его фрагменты, фактически вносим мелкие изменения в огромный код. Независимые фрагменты кода, написанные с нуля, попадаются редко — если, конечно, мы не начинаем новый проект. Большинство наших проектов — наследие многих поколений разработчиков до нас. Что бы мы ни делали — добавляли новую функциональность или изменяли старую — нам приходится читать код, чтобы выяснить, какая команда что делает и как лучше всего реализовать нашу задумку. Даже при работе над совершенно независимым модулем или классом, как только мы написали первые строки, нам приходится возвращаться к ним снова и снова, чтобы вплетать в них новый код.

Читать дальше →
Всего голосов 80: ↑65 и ↓15 +50
Просмотры 4.8K
Комментарии 28

Маленькие хитрости Java

Java *
Из песочницы
Я уже достаточно много лет занимаюсь разработкой на java и повидал довольно много чужого кода. Как это не странно, но постоянно от одного проекта к другому я вижу одни и те же проблемы. Этот топик — попытка ликбеза в наиболее часто используемых конструкциях языка. Часть описанного — это довольно банальные вещи, тем не менее, как показывает мой опыт, все эти банальности до сих пор актуальны. Надеюсь, статья пригодится многим java программистам. Итак, поехали:

new vs valueOf

//медленно
Integer i = new Integer(100);
Long l = new Long(100);
String s = new String("A");

//быстро
Integer i = Integer.valueOf(100);
Long l = 100L;//это тоже самое что Long.valueOf(100L);
String s = "A";


Старайтесь всегда использовать метод valueOf вместо конструктора в стандартных классах оболочках примитивных типов, кроме случаев, когда вам нужно конкретно выделить память под новое значение. Это связано с тем, что все они, кроме чисел с плавающей точкой, от Byte до Long имеют кеш. По умолчанию этот кеш содержит значения от -128 до 127. Следовательно, если ваше значение попадает в этот диапазон, то значение вернется из кеша. Значение из кеша достается в 3.5 раза быстрее чем при использовании конструктора + экономия памяти. Помимо этого, наиболее часто используемые значения могут также быть закэшированы компилятором и виртуальной машиной. В случае, если ваше приложение очень часто использует целые типы, можно увеличить кеш для Integer через системное свойство «java.lang.Integer.IntegerCache.high», а так же через параметр виртуальной машины -XX:AutoBoxCacheMax=<size>.
Читать дальше →
Всего голосов 141: ↑126 и ↓15 +111
Просмотры 264K
Комментарии 166

Маленькие хитрости Java. Часть 2

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

Buffered Streams

//медленно
InputStream is = new FileInputStream(file);
int val;
while ((val = is.read()) != -1) {
}
//быстро
InputStream is = new BufferedInputStream(new FileInputStream(file));
int val;
while ((val = is.read()) != -1) {
}

Казалось бы — очевидная истина, неправда ли? Но как показал чужой код и опыт собеседования кандидатов, часть разработчиков определенно не понимает в чем преимущество буферизованных стримов. Кто до сих пор не разобрался — метод read() класса FileInputStream:
public native int read() throws IOException;

Согласитесь, каждый раз делать системный вызов, чтобы считать один байт несколько расточительно. Собственно для того, чтобы избежать этой проблемы и были созданы оболочки-буферы. Все что они делают — при первом вызове системного read() считывают несколько больше (в зависимости от указанного размера буфера, котрый по умолчанию равен 8 кб) и при следующем вызове read() считывают данные уже из буфера. Прирост производительности — на порядок. Системные вызовы, на самом деле, это не всегда плохо, например:
System.arraycopy(src, srcPos, dest, destPos, length);

В случае копированния массива — системный метод будет гораздо быстрей реализованного на java. И еще — считывайте данные порциями, а не по байтам, это тоже позволит прилично сэкономить.
Читать дальше →
Всего голосов 93: ↑84 и ↓9 +75
Просмотры 107K
Комментарии 91

Три правила хорошего программирования

Разработка веб-сайтов *
Из песочницы
В последнее время я видел мало действительно хорошего кода, много посредственного и очень много — плохого. (Много того, что я писал раньше — особенно, когда я только начинал — относится к последним, увы.) Читая случайные статьи в интернете и профессиональные книги, я пришел к выводу, что писать хороший код — легко. Невероятно трудно, но в то же время легко. На самом деле, это настолько просто, что сводится к трем правилам.
Читать дальше →
Всего голосов 70: ↑55 и ↓15 +40
Просмотры 59K
Комментарии 20

Do good code: 8 правил хорошего кода

Блог компании GeekBrains Разработка веб-сайтов *Программирование *Совершенный код *
Практически всем, кто обучался программированию, известна книга Стива Макконнелла «Совершенный код». Она всегда производит впечатление, прежде всего, внушительной толщиной (около 900 страниц). К сожалению, реальность такова, что иногда впечатления этим и ограничиваются. А зря. В дальнейшей профессиональной деятельности программисты сталкиваются практически со всеми ситуациями, описанными в книге, и приходят опытным путём к тем же самым выводам. В то время как более тесное знакомство могло бы сэкономить время и силы. Мы в GeekBrains придерживаемся комплексного подхода в обучении, поэтому провели для слушателей вебинар по правилам создания хорошего кода.

В комментариях к нашему первому посту на Хабре пользователи активно обсуждали каналы восприятия информации. Мы подумали и решили, что тему «совершенного кода» стоит развить и изложить ещё и письменно — ведь базовые принципы хорошего кода едины для программистов, пишущих на любом языке.
Читать дальше →
Всего голосов 46: ↑35 и ↓11 +24
Просмотры 112K
Комментарии 111

Главный вопрос программирования, рефакторинга и всего такого

Блог компании PVS-Studio Совершенный код *C++ *C *
Улучшим качество кода!
Я написал маленькую электронную книгу в которой рассматриваю вопросы как сделать код лучше. Книга ориентирована на Си/Си++ программистов, но будет интересна и разработчикам, использующих другие языки. Формат книги не подходит для моего любимого Хабра, но мне интересно получить обратную связь и обсудить мысли, изложенные в статье. Поэтому я решил разместить здесь только анонс, а с самой статьей можно познакомиться здесь. И приглашаю в комментарии для обсуждения.
Читать дальше →
Всего голосов 66: ↑53 и ↓13 +40
Просмотры 47K
Комментарии 98

«Безумное чаепитие» — эксперимент по обучению школьников правилам хорошего кода

Я пиарюсь
Мы — математический лагерь «Слон» — уже давно проводим летние и зимние школы для учеников 8-11 классов. Основной вид деятельности на школе — работа над крупной задачей, проектом. Это может быть что угодно от моделирования сложной физической системы до программы взлома шифров или написания игрушки под Android. Большая часть проектов на школе так или иначе связана с программированием, но редко программирование является самоцелью проекта. Школьники, которые еще не успели стать матерыми программистами, да еще и в условиях вечной нехватки времени пишут код «шоб работало». Так что мы не понаслышке знаем, что такое плохой код и каждый год встречаем всё новые, иногда удивляющие даже нас, способы сделать код нечитаемым — и каждый год решаем, что делать с этой проблемой.

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

Еще одной идеей было использовать git, «чтобы дурь каждого видна была». Тогда ближе к концу проекта можно было бы пересмотреть, с чего все начиналось и куда вывернуло, ужаснуться и делать по-другому. Однако эта идея не прошла проверку временем. По нашему опыту, школьников сложно научить пользоваться системой контроля версий, да еще и регулярно. Им непонятно, для чего СКВ нужны, а потому им скучно. Кроме того, отнимать пару часов только на освоение git — безумное расточительство для проекта длиной в одну неделю. Да и не для того системы контроля версий изначально задумывались.

Решение же, которое мы использовали этой зимой нам самим очень понравилось, поэтому считаем нужным поделиться своим методом. Мы назвали его «Безумное чаепитие».
Итак, задача: научить школьников писать понятный и аккуратный код. При этом надо сделать этот процесс увлекательным…

Чтобы научиться писать хороший код, мы обычно смотрим на примеры хорошего кода и плохого кода. Школьники же обычно смотрят только на свой собственный код. Курс сконструирован так, чтобы поменять эту практику: участники смотрят и на хороший код, и на плохой и пишут код сами. Обычно дети выступают в роли критикуемых, на спецкурсе же у них была возможность посмотреть на чужой код, покритиковать его самим и постараться улучшить. Как?
Читать дальше →
Всего голосов 9: ↑8 и ↓1 +7
Просмотры 4.6K
Комментарии 6

Что такое хороший код, или как стать востребованным разработчиком

Блог компании ICL Services Программирование *Совершенный код *C# *
Recovery mode
Tutorial
image

Данный цикл статей предназначен прежде всего для начинающих разработчиков или для тех, кому не понятно, почему они до сих пор «бегают» в джуниорах, а не сеньорах.
Читать дальше →
Всего голосов 36: ↑16 и ↓20 -4
Просмотры 15K
Комментарии 43

Какие привычки делают меня лучше как разработчика ПО?

Программирование *
Из песочницы
Привет, Хабр! Представляю вашему вниманию перевод статьи «What habits made me a better Software Engineer?» от Sonny Recio.

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

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

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

Если вас заинтересовали мои слова, вот некоторые из привычек, которые я сформировал, чтобы стать успешным. Вы их можете также использовать:

Читать дальше →
Всего голосов 18: ↑14 и ↓4 +10
Просмотры 18K
Комментарии 27

Debug Oriented Programming или печаль в глазах Интегратора

PHP *Программирование *Отладка *Разработка под e-commerce *Magento *

Так получилось, что в последние несколько лет я сшиваю Франкенштейнов, а не ваяю милые фарфоровые статуэтки пастушек и трубочистов. Я создаю решения на базе Magento 2. Это значит, что исходный материал у меня — мечта любого археолога. Культурный слой со следами различных "эпох" и "цивилизаций". По нему можно изучать развитие программистской мысли в PHP/JS сообществах в течение последнего десятилетия.


И это только базис, а надстройка — сторонние модули, которые нужно интегрировать вовнутрь. Вот тут уже можно столкнуться с проявлениями внеземного разума. Некоторые модули созданы развитыми существами, очень похожими по мышлению на создателей базиса, но попадаются такие, что хочется приобнять автора за плечо, проникновенно заглянуть ему в глаза и по-дружески так спросить: "Ты с какой планеты, родной?"


image


Сшить Франкенштейна из такого материала помогает отладчик (debugger). Ниже идёт мой персональный топ приёмов кодирования, которые способны усложнить жизнь любому, кто, как и я, ежедневно использует отладчик в своей жизни. Он небольшой, на четыре позиции, но каждый раз, когда я сталкиваюсь с подобным при отладке — я печалюсь. Может быть мой пост уменьшит количество скорбей в мире, а может и нет. Я, по крайней мере, попытаюсь.

Читать дальше →
Всего голосов 31: ↑23 и ↓8 +15
Просмотры 5.3K
Комментарии 43

10 принципов самодокументируемого кода

Совершенный код *Управление разработкой *
Из песочницы
Привет! Сегодня я хочу поделиться советами по написанию совершенного понятного кода, взятые из книги Питера Гудлифа «Ремесло программиста // Практика написания хорошего кода».

Конечно, неплохо было бы прочитать эту занимательную книгу каждому кто пишет код, но для особо ленивых, но желающих перестать меньше мучить и вводить коллег в заблуждение (совесть имейте) представляю под катом 10 принципов самодокументируемого кода:
Читать дальше →
Всего голосов 61: ↑49 и ↓12 +37
Просмотры 38K
Комментарии 134

Чистая архитектура решения, тесты без моков и как я к этому пришел

Совершенный код *.NET *ASP *API *C# *
Из песочницы

Здравствуйте, дорогие читатели! В этой статье я хочу рассказать об архитектуре своего проекта, который я рефакторил 4 раза на его старте, так как не был удовлетворен результатом. Расскажу о минусах популярных подходов и покажу свой.

Читать дальше →
Всего голосов 33: ↑24 и ↓9 +15
Просмотры 15K
Комментарии 65

Почему не надо удалять все элементы массива, переназначая его на [ ]?

Высокая производительность *Разработка веб-сайтов *JavaScript *Программирование *
Перевод
Tutorial

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


Рассмотрим такой список элементов:


let items = ["tea", "coffee", "milk"];

Чтобы удалить все элементы из массива, мы устанавливаем его значение в пустой массив


items = [];

Это работает отлично, и вы обнаружите, что данный пример используют постоянно. Но с этим есть проблема ...


Читать дальше →
Всего голосов 56: ↑6 и ↓50 -44
Просмотры 7.9K
Комментарии 51

Как инженеру вырасти в техлида

Блог компании Конференции Олега Бунина (Онтико) Анализ и проектирование систем *Проектирование и рефакторинг *Управление проектами *Конференции
Кто такие тимлид, архитектор или QA и чем они занимаются, в IT представляют себе примерно все. Но с пониманием, кто такой техлид, за что отвечает и как им стать, возникают трудности. Мы провели десятки интервью со специалистами крупных компаний и узнали, что это инженер, который инициирует процессы: связывает людей и инструменты с целями организации. Он берёт инициативу и ответственность за технологическое развитие продукта и радеет за качество технических решений. При этом качество это не только тестирование, а архитектура, дизайн, инженерные практики и эксперименты, работа с техдолгом и техническое совершенствование компании в целом.



Также мы выяснили, что для техлидов есть много конференций. Но почти все они концентрируются на  инструментах, а не на инженерных практиках и процессах. Именно поэтому мы запустили новую конференцию TechLead Conf 2020 Online — для тех, кто хотел бы стать техлидом и разобраться с тем, что такое качество. 

На TechLead Conf 2020 Online вторичен вопрос «С помощью какого технического инструмента решалась проблема?». Эта конференция для тех, кто борется за качество технических решений и берёт на себя ответственность за технологическое развитие продукта. С 8 по 10 июня мы изучим опыт внедрения и использования практик, управления технологиями и процессами в компании. Подробнее о программе и о чём будем говорить на мероприятии, расскажем дальше.
Читать дальше →
Всего голосов 27: ↑24 и ↓3 +21
Просмотры 7.6K
Комментарии 0

Что такое хороший код? Считаем звёзды

Программирование *Совершенный код *
Recovery mode

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

Моё мнение - нет никакого "хорошего кода", потому что само понятие "хороший" крайне субъективно и неизмеримо. Так, может, нужна линейка для измерения хорошести качества кода? В общем, предлагаю вашему вниманию шкалу, которая самонадеянно претендует на исчерпывающий ответ. В шкале ровно 5 значений (ну или 6, начиная с нулевого - мыжпрограммисты), а для наглядности они обозначены звёздами. Впрочем, вы можете заменить звёзды на даны, школьные баллы, попугаи или любые другие единицы измерения - суть не изменится. Погнали!

Так как же оценить хороший код?
Всего голосов 23: ↑7 и ↓16 -9
Просмотры 3.4K
Комментарии 13

Создание самодостаточных исполняемых JAR

Блог компании OTUS Программирование *Java *
Перевод

Когда программное приложение выходит за пределы десятка строк кода, вам, вероятно, следует разделить код на несколько классов. На этом этапе встает вопрос о том, как их распределить. В Java классическим форматом является Java-архив, более известный как JAR. Но реальные программы, вероятно, зависят от других JAR.

Цель этой статьи — описать способы создания самодостаточных исполняемых (self-contained executable) JAR, также известных как uber-JAR или fat JAR.

Читать далее
Всего голосов 4: ↑3 и ↓1 +2
Просмотры 6.2K
Комментарии 0

Почему сложно понять, что код не должно быть сложно понять?

Совершенный код *
Recovery mode

Знакомая ситуация?

Авторы очередного убийцы redux\jira\microsoft обычно обижаются в ответ на разумные замечания по качеству кода и пишут что то вроде ‘При чём тут качество кода? Посмотрите какую штуку я запилил’. Что, блин? Неужели сложно понять, что код сложно понять?

Написание такого кода говорит о том, что код либо не планируется поддерживать, либо у автора недостаточно опыта, чтобы понимать, почему это важно. В любом случае, в успехе такого продукта есть определённые сомнения.

Но вообще, в чём проблема читабельности? По моему мнению, это как элементарная гигиена: пришёл с улицы - помыл руки, написал код - привёл его в порядок. Почему же читабельность часто становится неким камнем преткновения?

Давайте обсудим.

Читать далее
Всего голосов 19: ↑7 и ↓12 -5
Просмотры 5.3K
Комментарии 30

Энтерпрайзные проекты убили профессию разработчика

Блог компании Haulmont Программирование *Управление продуктом *
Перевод


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


На эту статью меня вдохновил комментарий на HackerNews, который я больше не могу найти. Суть его была такая: “В то время, как архитектура слишком проработана, код недоработан”. Если кто-то опознает автора, я с радостью проставлю его авторство.


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

Читать дальше →
Всего голосов 22: ↑18 и ↓4 +14
Просмотры 8.3K
Комментарии 16

Как я решил проблему плохого кода с помощью architecture guide

Программирование *Управление разработкой *Управление персоналом *

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

Читать далее
Всего голосов 29: ↑23 и ↓6 +17
Просмотры 12K
Комментарии 36