Pull to refresh

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

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

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

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

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

Читать дальше →
Total votes 80: ↑65 and ↓15 +50
Views 4.8K
Comments 28

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

Java *
Sandbox
Я уже достаточно много лет занимаюсь разработкой на 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>.
Читать дальше →
Total votes 141: ↑126 and ↓15 +111
Views 265K
Comments 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. И еще — считывайте данные порциями, а не по байтам, это тоже позволит прилично сэкономить.
Читать дальше →
Total votes 93: ↑84 and ↓9 +75
Views 107K
Comments 91

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

Website development *
Sandbox
В последнее время я видел мало действительно хорошего кода, много посредственного и очень много — плохого. (Много того, что я писал раньше — особенно, когда я только начинал — относится к последним, увы.) Читая случайные статьи в интернете и профессиональные книги, я пришел к выводу, что писать хороший код — легко. Невероятно трудно, но в то же время легко. На самом деле, это настолько просто, что сводится к трем правилам.
Читать дальше →
Total votes 70: ↑55 and ↓15 +40
Views 59K
Comments 20

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

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

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

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

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

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

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

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

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

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

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

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

ICL Services corporate blog Programming *Perfect code *C# *
Recovery mode
Tutorial
image

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

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

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

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

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

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

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

Читать дальше →
Total votes 18: ↑14 and ↓4 +10
Views 18K
Comments 27

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

PHP *Programming *Debugging *Development for e-commerce *Magento *

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


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


image


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

Читать дальше →
Total votes 31: ↑23 and ↓8 +15
Views 5.3K
Comments 43

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

Perfect code *Development Management *
Sandbox
Привет! Сегодня я хочу поделиться советами по написанию совершенного понятного кода, взятые из книги Питера Гудлифа «Ремесло программиста // Практика написания хорошего кода».

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

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

Perfect code *.NET *ASP *API *C# *
Sandbox

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

Читать дальше →
Total votes 33: ↑24 and ↓9 +15
Views 15K
Comments 65

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

High performance *Website development *JavaScript *Programming *
Translation
Tutorial

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


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


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

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


items = [];

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


Читать дальше →
Total votes 56: ↑6 and ↓50 -44
Views 8K
Comments 51

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

Конференции Олега Бунина (Онтико) corporate blog System Analysis and Design *Designing and refactoring *Project management *Conferences
Кто такие тимлид, архитектор или QA и чем они занимаются, в IT представляют себе примерно все. Но с пониманием, кто такой техлид, за что отвечает и как им стать, возникают трудности. Мы провели десятки интервью со специалистами крупных компаний и узнали, что это инженер, который инициирует процессы: связывает людей и инструменты с целями организации. Он берёт инициативу и ответственность за технологическое развитие продукта и радеет за качество технических решений. При этом качество это не только тестирование, а архитектура, дизайн, инженерные практики и эксперименты, работа с техдолгом и техническое совершенствование компании в целом.



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

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

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

Programming *Perfect code *
Recovery mode

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

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

Так как же оценить хороший код?
Total votes 23: ↑7 and ↓16 -9
Views 3.4K
Comments 13

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

OTUS corporate blog Programming *Java *
Translation

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

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

Читать далее
Total votes 4: ↑3 and ↓1 +2
Views 6.3K
Comments 0

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

Perfect code *
Recovery mode

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

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

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

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

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

Читать далее
Total votes 19: ↑7 and ↓12 -5
Views 5.3K
Comments 30

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

Haulmont corporate blog Programming *Product Management *
Translation


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


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


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

Читать дальше →
Total votes 22: ↑18 and ↓4 +14
Views 8.3K
Comments 16

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

Programming *Development Management *Personnel Management *

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

Читать далее
Total votes 29: ↑23 and ↓6 +17
Views 12K
Comments 36