Один из самых простых способов определить качество кода приложения — посмотреть на подсказки IDE (например ZendStudio). На первый взгляд простой приём несет в себе вполне определённый и рациональные моменты.

• «прозрачность» кода
• следование стандартам именования
• правильное использование модификаторов видимости
• использование ООП
• отсутсвие «волшебства» в коде
• документирование методов и функций

Посмотрев на подсказки IDE, можно сделать очень даже обоснованное заключение о качестве кода.

Что думаете?

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

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

Большинство провальных проектов обладают одной закономерностью. Они абсолютно лишены структуры. Я называю архитектуру таких систем «пластилиновой».

В этот раз победу одержало добро. А вернее, исходные коды проекта Chromium. Chromium — один из лучших проектов, который мы проверяли с помощью PVS-Studio.

В 2006 году между Департаментом Национальной безопасности США и частной компанией Coverity, производящей решение для автоматизированного тестирования качества кода, был заключён договор об крупнейшем аудите исходного кода открытого и проприетарного программного обеспечения. Несколько дней назад отчёт компании был опубликован и его выводы кратко приведены ниже:

• Было проверено 37 млн строк программного кода сорока пяти наиболее активных Open Source-проектов, причём средний размер тестируемых проектов составлял 832 000 строк. Был рассчитан показатель "Средняя плотность дефектов" как число ошибок на тысячу строк кода, который составил в среднем 0.45.
• Было проверено 300 миллионов строк проприетарного кода, произведённого сорока одной анонимной компанией. Средний размер проекта — 7.5 млн строк кода, средняя плотность дефектов составила 0.64.
  

Я проработал с Rails уже порядочное количество времени, и за это время я видел много Rails-приложений, а также немало прочитал и написал плохого кода на Ruby. И вот вам 5 самых распространенных ошибок, которые я наблюдал практически в каждом приложении.

Опыт вождения по дорогам Киева натолкнул меня на пару интересных мыслей. Все мы знаем, что на дорогах «куча идиотов». Ровно так же дело обстоит и в разработке – куда ни глянь, страшно на код взглянуть. Почему так происходит?

Изменять код
В процессе разработки программного обеспечения нет такого понятия, как «стагнация». Все, что вы разрабатываете сейчас — просто очередная версия компонента, который вероятно будет меняться в будущем. Изменение является самым распространенным явлением в мире разработки программного обеспечения и вам лучше принять это как факт. Рассчитывайте на возможные изменения всего, что вы разрабатываете и поэтому проектируйте ваш код более модульным. Это упрощает изменения и в тоже время увеличивает качество кода. Старайтесь придерживаться концепций DRY и YAGNI. Вы часто будете в ситуации, когда вы смотрите на ваш код и представляете, что вы могли бы сделать это лучше. Так пусть эта мысль не мешает вам спать. Садитесь сразу за дело и рефакторинг! Если не сделаете это сейчас, вы возможно никогда этого не сделаете. Чем дольше ждете, тем сложнее и дороже это будет. И это может вырасти в лишнюю головную боль, с которой не захочется связываться.
«Хороший код — это код, который легко изменять. Код стремится измениться до момента, когда его уже не легко изменять. Весь код становится плохим кодом». Неизвестный автор.

В этот раз речь пойдет о модульных тестах и инспекциях кода. Когда мы в нашей команде начали использовать две эти практики в своих проектах, драйва и радости от работы прибавилось на порядок. Упомянутым темам посвящено огромное количество теоретических и практических трудов, но сегодня речь пойдет именно о личной выгоде разработчика.

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

За годы присутствия на хабре я прочитал немало статей на тему того, как должен выглядеть идеальный код. И поменьше статьей о том, как конкретно достигать этого идеала. Также стоит отметить, что весьма значительная часть всех этих материалов была переводом западных источников, что, вероятно, является следствием более зрелой отрасли IT «за рубежом», со всеми вытекающими вопросами и проблемами.

К сожалению, во многих случаях авторы либо забираются в недосягаемые выси многослойных архитектур, что требуется в лучшем случае для 1% проектов, либо ограничиваются общими фразами вроде «код должен быть понятен» или «используйте ООП и паттерны», не опускаясь до подробных объяснений, в чем например измеряется «понятность» кода.

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

Знаете ли вы, что за все годы существования индустрии разработки ПО не было выявлено сильной связи межу опытом работы и качеством кода и продуктивностью сотрудника?

В 1968 году было проведено исследование продуктивности работы программистов (источник), которое показало что соотношение лучших и худших программистов составило:

• 20:1 по времени написания кода
• 25:1 по времени отладки кода
• 10:1 по скорости работы программы
• 5:1 по объему кода

Эти цифры в разных вариациях уже все видели. А вот тот факт, что исследование проводилось на программистах, имевших в среднем 7 лет опыта разработки с небольшими отклонениями, не знает никто.

Наверное каждый из вас сталкивался с такими решениями для SharePoint: решение вроде работает, но постоянно возникают какие-то проблемы, данные не сохраняются, странные падения при, казалось бы, безобидных операциях. Тестеры тратят много времени на такое решение, но исправление одних багов порождает другие. Развернуть такое решение на production ферме оказывается очень сложно, поддержка превращается в ад. Знакомо, да?

Занимаясь разработкой правил анализа кода для SPCAF (http://spcaf.com), я нашел способ как быстро исправить такую ситуацию.

Вчера организация The Linux Foundation объявила о запуске проекта Core Infrastructure Initiative (CII) для финансовой поддержки бедствующих Open Source проектов вроде OpenSSL, который в последние годы жил на пожертвования $2000 в год.

В официальном пресс-релизе The Linux Foundation подчёркивает, что необходимость финансовой поддержке совершенно не связана с низким качеством кода OSS, совсем наоборот. Свободное ПО превосходит проприетарный софт по качеству кода и по безопасности. В подтверждение этого The Linux Foundation сослалась на последнее исследование Coverity Open Scan, результаты которого опубликованы 15 апреля, через неделю после публикации информации о баге Heartbleed.

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

В этой ситуации важно понимать, что качество кода СПО действительно объективно превосходит качество кода проприетарного софта. Условно говоря, если бы код OpenSSL не был открыт, мы могли вообще никогда не узнать об этой уязвимости.

Сейчас любое крупное приложение состоит из множества сторонних библиотек. Хочется поднять такую тему, как доверие к этим библиотекам. В книгах и статьях можно встретить очень много рассуждений о качестве кода, методах тестирования, методологиях разработки и так далее. Но я не помню, чтобы кто-то рассуждал о качестве кирпичей, из которых строятся приложения. Давайте немного поговорим об этом. Например, есть Medicine Insight Segmentation and Registration Toolkit (ITK). Мне кажется, он написан весьма качественно. По крайней мере, я заметил в коде весьма мало ошибок. Но я не могу сказать, что код используемых библиотек столь же качественен. Тогда вопрос. Насколько мы можем доверять таким системам? Есть повод для размышлений.

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

PHP — скриптовый язык, сервер отвечает на запрос и объекты умирают. Да, это не desktop-приложение.
Но это не значит, что объекты предметной области, с которыми мы должны работать, не нужны вовсе.
Наоборот! Они нужны, они должны помогать нам сохранять и восстанавливать их состояние, после их удаления из памяти.

На PHP можно и нужно писать качественный код, в прочем это вообще не зависит от языка!
В первую очередь статья будет полезна для новичков, но думаю не помешает и бывалым разработчикам. Возможно, и в вашем проекте всё не так, как хотелось бы?

Здравствуйте, меня зовут Александр Акбашев, я Lead QA Engineer в проекте Skyforge. А также по совместительству ассистент tully в Технопарке на курсе «Углубленное программирование на Java». Наш курс идет во втором семестре Технопарка, и мы получаем студентов, прошедших курсы по C++ и Python. Поэтому я давно хотел подготовить материал, посвященный самым распространенным ошибкам новичков в Java. К сожалению, написать такую статью я так и не собрался. К счастью, такую статью написал наш соотечественник — Михаил Селиванов, правда, на английском. Ниже представлен перевод данной статьи с небольшими комментариями. По всем замечаниям, связанным с переводом, прошу писать в личные сообщения.



Изначально язык Java создавался для интерактивного телевидения, однако со временем стал использоваться везде, где только можно. Его разработчики руководствовались принципами объектно-ориентированного программирования, отказавшись от излишней сложности, свойственной тем же С и С++. Платформонезависимость виртуальной машины Java сформировала в своё время новый подход к программированию. Добавьте к этому плавную кривую обучения и лозунг «Напиши однажды, запускай везде», что почти всегда соответствует истине. Но всё-таки ошибки до сих пор встречаются, и здесь я хотел бы разобрать наиболее распространённые из них.

Когда осенью 2012 года я пришёл в Airbnb, то здесь мягко выражаясь, был некоторый разброд и шатание. Некоторое время назад компания начала расти и развиваться огромными темпами. В первую очередь это выражалось в объёмах трафика и транзакций. Чтобы справляться со всем этим, очень быстро увеличили и штат разработчиков. За год до моего прихода в группе было 16 человек, со мной было около 40, а сейчас уже свыше 130. И одной из главных проблем, вызванной всеми этими процессами, стало сохранение качества кода в стремительно увеличивающемся и усложняющемся проекте.

Примечание от переводчика. Изначально эта статья была опубликована на сайте AltDevBlogADay. Но сайт, к сожалению, прекратил своё существование. Более года эта статья оставалась недоступна читателям. Мы обратились к Джону Кармаку, и он сказал, что не против, чтобы мы разместили эту статью на нашем сайте. Что мы с удовольствием и сделали. С оригиналом статьи можно познакомится, воспользовавшись Wayback Machine — Internet Archive: Static Code Analysis.

Поскольку все статьи на нашем сайте представлены на русском и английском языке, то мы выполнили перевод статьи Static Code Analysis на русский язык. А заодно решили опубликовать её на Хабре. Здесь уже публиковался пересказ этой статьи. Но уверен, многим будет интересно прочитать именно перевод.

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

1. Вступление

Сталкиваясь с необходимостью контролировать работу других программистов, начинаешь понимать, что, помимо вещей, которым люди учатся достаточно легко и быстро, находятся проблемы, для устранения которых требуется существенное время.

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

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

Профессии программиста, как и большинству других профессий, приходится учиться каждый день в течение нескольких лет, а, по большому счету, и всю жизнь. Вначале ты осваиваешь набор базовых знаний в объеме N семестровых курсов, потом долго топчешься по различным граблям, перенимаешь опыт старших товарищей, изучаешь хорошие и плохие примеры (плохие почему-то чаще).

Говоря о базовых знаниях, надо отметить, что умение писать красивый профессиональный код — это то, что по тем или иным причинам, в эти базовые знания категорически не входит. Вместо этого, в соответствующих заведениях, а также в книжках, нам рассказывают про алгоритмы, языки, принципы ООП, паттерны дизайна…

Да, все это необходимо знать. Но при этом, понимание того, как должен выглядеть достойный код, обычно появляется уже при наличии практического (чаще в той или иной степени негативного) опыта за плечами. И при условии, что жизнь “потыкала” тебя не только в сочные образцы плохого кода, но и в примеры всерьез достойные подражания.

В этом-то и заключается вся сложность: твое представление о “достойном” и “красивом” коде полностью основано на личном многолетнем опыте. Попробуй теперь передать это представление в сжатые сроки человеку с совсем другим опытом или даже вовсе без него.

Но если для нас действительно важно качество кода, который пишут люди, работающие вместе с нами, то попробовать все же стоит!