Обновить
103.07

Качество кода *

Как Макконнелл завещал

Сначала показывать
Порог рейтинга
Уровень сложности

ACL: в поисках идеального решения

Время на прочтение9 мин
Охват и читатели33K
Новый проект. В очередной раз пришлось решать проблему с разграничением прав. В очередной раз пришлось изобретать велосипед. Вот я и подумал, а не проще ли разобраться с этой проблемой раз и навсегда. Хочу решить задачу «на бумаге», чтобы эти принципы можно было использовать независимо от технологии.
Поехали

Source code как способ думать

Время на прочтение7 мин
Охват и читатели16K
Маленькое предварительное замечание: Подробное объяснение потребовало бы объёмов средней книжки. Тут всё дано схематично, кратко и без подробностей. Текст, конечно, хулиганский, но прежде чем наезжать на автора, стоит учесть, что за ним стоит двадцать лет опыта и много-много литературы как классической, так и специалистам ИТ не ведомой.

Есть слово, приносящее индустрии каждый год огромные убытки. И слово это — bug.

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

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

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

Почему так происходит? Потому что в индустрии совершенно превратно понимают, что такое исходный код и для чего он нужен.

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

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

Код именно отражает, а не описывает. Последнее возможно, но требует перестройки всего процесса, от форматов записи до мозгов.

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

Писать и говорить то, что думаешь, — это всегда отсутствие такта, презрение к окружающим и хамство. Если кто-то ставит в своём коде комментарий «Stupid idea. Does not work, if N < 0. Correct ASAP.», он рискует прослыть минимум странным. А вот если это попадёт в участок ответственности гениального программиста, тут уже мелкой истерикой не ограничится. Даже, если «stupid» будет подразумеваться только по контексту. Или напишите в комментарии что-нибудь типа «I do not know why this works, but otherwise the function generates an exception.» Потом покажите это начальнику и попросите повышения.

И, конечно, гораздо выгоднее говорить «Мы исправляем баги в коммуникационном модуле», а не «Читая документацию мы прошляпили несколько критических моментов и неделю будем всё с нуля переделывать.»

Ладно, оставим. Большинство такого не выдерживает. Страшно. И ронять чувство собственного достоинства тоже страшно. И лицо потерять… И начальство тоже… Короче, фиг с ним, перейдём к плюшкам.

Читать дальше →

Остров, о котором забыл Scrum

Время на прочтение7 мин
Охват и читатели30K
На оригинал данной статьи я наткнулся случайно, разгребая почту и наткнувшись на новостную рассылку от ScrumAlliance. Тема метрик Scrum команд и непосредственно кода, меня интересует уже давно. Особенно любопытно, что с этими метриками делать дальше, и первостепенно — зачем они вообще нужны?

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

Чтобы расширить свой кругозор, а также получить ответ на свои внутренние вопросы, добро пожаловать под кат…
Да, я пережил конец света!

Ruby Science: руководство по созданию качественных приложений на Ruby on Rails от thoughtbot

Время на прочтение3 мин
Охват и читатели13K
thoughtbot (с маленькой буквы) — одна из ведущих американских консалтинговых фирм, ориентированных на веб разработку с помощью Ruby on Rails. thoughtbot эксплуатирует распространенную в этой среде бизнес-модель, и зарабатывает не только за счет консалтинга, но и за счет своих больших вкладов в Open Source, активного участия в жизни сообщества (например, подкаст Giant Robots Smashing into Other Giant Robots), образовательной деятельности (воркшопы, менторство), внутренних продуктов и литературы.

На их счету до сегодняшнего дня числилось две полноценных книги: The Playbook — исчерпывающий справочник по внутреннему распорядку и трудовым хитростям thoughtbot (бесплатна для изучения на их сайте), и Backbone.js on Rails — не менее исчерпывающее руководство по использованию JS фреймворка Backbone вместе с Ruby on Rails.

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

Сегодня они объявили о начале работы над новой книгой, под названием «Ruby Science. The reference for writing fantastic Rails applications». Более того, начать чтение книги и принять участие в её развитии можно уже сейчас.

Читать дальше →

Простое написание тестов — это не TDD!

Время на прочтение4 мин
Охват и читатели62K
Эта статья представляет собой хороший теоретический материал о TDD для тех, кто об этом ещё ничего не знает.


Читать дальше →

Чему должны учить в 9-11 классах с углублённым изучением информатики? Какой подход позволит сформировать из старшеклассника-технаря хорошего программиста?

Время на прочтение1 мин
Охват и читатели23K
 

Исследование отношения популярных языков программирования к случайным ошибкам

Время на прочтение2 мин
Охват и читатели27K
Группа греческих учёных под руководством Диомидиса Спинеллиса провела интересное исследование чувствительности десяти популярных языков программирования к ошибкам и опечаткам при наборе текста программы. Ущерб от таких ошибок иногда может составлять многие миллионы, и способность языка обнаруживать их как можно раньше очень важна для разработки надёжных программ. Для тестирования использовались несколько примеров из проекта Rosetta Code — вики, на которой собраны реализации множества задач и алгоритмов на разных языках. На основании статистических данных о популярности языков, а так же некоторых практических соображений (наличие свободного компилятора и примеров на Rosetta Code) были выбраны следующие языки и компиляторы:
Язык компилятор/среда
C gcc 4.4.5
C++ g++ 4.4.5
C# mono 2.6.7, CLI v2.0
Haskell ghc 6.12.1
Java OpenJDK 1.6.0_18
JavaScript spidermonkey 1.8.0
PHP PHP 5.3.3-7
Perl perl 5.10.1
Python python 2.6.6
Ruby ruby 1.8.7
Читать дальше →

Количественная оценка понятности кода

Время на прочтение3 мин
Охват и читатели18K
image

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

Но давайте посмотрим на проблему с другой стороны. Что мы делаем, когда разбираемся с чьим-то кодом? Как происходит сам процесс изучения кода? Мы листаем функции, ищем определения переменных, классов, переходим от функции к функции, от файла к файлу.

Читать дальше →

Марсианский код: лекция о том, как программировали Curiosity

Время на прочтение1 мин
Охват и читатели33K
На конференции HotDep 2012 Джерард Хольцман из Лаборатории реактивного движения НАСА прочёл лекцию о том, как обеспечивалась надёжность и корректность кода для марсохода Curiosity. Часовая лекция рассказывает, какие методики, стандарты кодирования и инструменты разработки применялись программистами НАСА, чтобы написать три с половиной миллиона строк сверхнадёжного кода, который в автономном режиме посадил Curiosity на поверхность Марса и обеспечивает работу всех его систем и приборов.

Лекцию можно посмотреть онлайн на сайте usenix.org, или скачать в формате .mp4 (228 Мб).

Грязный, чистый, устремлённый

Время на прочтение8 мин
Охват и читатели47K

Грязный


Давайте вместе поразмыслим — что же такое чистый код, и что такое код грязный? Или, как говорят американцы – «hairy code», т.е. волосатый?

Чем чистый код отличается от грязного – или, как говорят в этих наших интернетах, от «говнокода»? Да и нужен ли он вообще, этот чистый код?


Давайте сначала разберёмся с определениями.

Мне кажется, что дать чёткого определения «чистому» коду просто невозможно. Отчасти это – как с красотой: смотришь на картину, или там скульптуру – и видишь: да, красива. Или, наоборот, уродлива.
А что же с чистым и устремлённым?

Работая в интересах Будущих Разработчиков

Время на прочтение11 мин
Охват и читатели16K
Успешный программный продукт обычно проходит за свою жизнь через руки множества разработчиков. Вы — лишь одно из звеньев в цепочке опекунов вашего проекта, и каждая строчка кода, которую Вы написали — это оставленный Вами артефакт, который когда-нибудь будет изучаться Будущим Разработчиком. Также, как Вы унаследовали решения разработчиков, которые были до Вас, другие разработчики унаследуют решения, которые Вы приняли сегодня. Они получают от нас в наследство все наши недоразумения, срезанные нами углы, примененные нами недопонятые паттерны и техники, наше невнимание к деталям, нашу лень, наши изменения, сделанные на скорую руку, наших скелетов в шкафах, наше грязное белье. И гораздо реже — выгоду от нашей дисциплинированности, наших обсуждений и подготовок.


Хочу очистить свою совесть!

Ближайшие события

Затерянный остров хорошего кода

Время на прочтение2 мин
Охват и читатели18K
Очередной спор о стиле, красоте и компактности кода занял слишком много времени, в связи с чем и был отправлен на разрешение широкой аудитории StackOverflow. Это помогло, и спор решился, но в комментариях мне намекнули, что я пришел не по адресу:
Stack Exchange's "codereview" site is the new hotness for this sort of question.


Оказывается, больше года назад в застенках Area 51 был рожден вопросник Code Review, призванный делать код лучше.

Да, я хочу сделать свой код лучше!

Встречайте Critic: система инспектирования кода в Opera Software

Время на прочтение5 мин
Охват и читатели9.3K
Внутренняя система инспектирования исходного кода Critic, применяемая в Opera Software, вчера вечером была выложена на Github под лицензией Apache License 2.0.

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

Скачать исходные коды Critic можно здесь: github.com/jensl/critic.
Читать дальше →

Почему нельзя превращать прототип в итоговую программу

Время на прочтение2 мин
Охват и читатели43K
Всем привет! Сколько уже статей было про говнокод, но я считаю, их поток нельзя сокращать, потому как поток говнокода только увеличивается.
Внимание: статья полна субъективизма и сюрреализма. Автор не претендует на истину в последней инстанции
Очень часто, создавая новое приложение, программу, веб-сайт, мы сначала экспериментируем, а затем создаем из наших экспериментов конечный продукт.
Но дайте ответ на следующие вопросы не задумываясь:
  1. сколько раз, получая исходники от других разработчиков, вы находили их крайне непривлекательными?
  2. сколько раз, передавая исходники другим разработчикам вам было стыдно за свой код?

Мои ответы: постоянно, довольно часто.
Почему так происходит?


Давайте попробуем разобраться

Функциональное программирование в ООП

Время на прочтение5 мин
Охват и читатели15K
Думаю, никто не станет спорить, что хороший код — код, который не только исполняет, но и максимально описывает свою задачу (это, конечно, относится в первую очередь к бизнес-логике). Причем описывает ее не деталями алгоритма, а своей сигнатурой (названием, параметрами и возвращаемым типом), сигнатурой вызываемых методов, переменными, которые он использует. В таком случае тело метода можно прочитать сверху вниз, не удерживая в памяти какой-то дополнительный контекст.
Читать дальше →

Программирование в стиле русских романов

Время на прочтение1 мин
Охват и читатели27K


Одна из вещей, которая делает классические русские романы столь тяжелыми для чтения (для иностранцев) это то, что главные герои имеют кучу имён. К примеру, в романе "Братья Карамазовы" один из персонажей — Алексей Фёдорович Карамазов (Alexei Fyodorovich Karamazov), которого по ходу текста называют также Алёша, Алёшка, Алёшенька, Алёшечка, Алексейчик, Лёша и Лёшенька (Alyosha, Alyoshka, Alyoshenka, Alyoshechka, Alexeichik, Lyosha и Lyoshenka)

«Программирование в стиле русских романов» — это антипаттерн, возникающий в ситуации, когда одна вещь имеет много имён. Для какой-нибудь программы у вас может быть путь в системе контроля версий, путь на диске, имя проекта, имя исполняемого файла и т.д. Все они могут иметь одинаковые (однокоренные) имена или наоборот — называться каждая по-своему. Например, синонимами. Или вообще разными словами. Так уж вышло по историческим причинам, что бинарник foo.exe получается при компиляции проекта bar, лежащего в папке baz и т.д.
Читать дальше →

Практические советы для эффективного инспектирования кода

Время на прочтение3 мин
Охват и читатели15K
Инспектирование кода — это очень сложная и ответственная задача, которая может отнимать много ресурсов. Важно ответственно подходить к инспектированию и проводить его эффективно. Эффективно — это значит тратить мало времени и находить много дефектов. Но как повысить эффективность? Ниже представлены несколько советов, которые помогут в этом.
Читать дальше →

Сравнение методик обзора кода

Время на прочтение7 мин
Охват и читатели26K
Думаю, многие разработки знакомы с понятием code review или обзор кода по-русски (также данный термин переводят как просмотр кода, инспектирование кода или рецензирование кода – далее, для единообразия, будет использоваться вариант «обзор кода»). Недавно я столкнулся с необходимостью «разложить по полочкам» и классифицировать знания по этой теме. Результат – данная статья. Надеюсь, она окажется полезной, а также поможет внедрить обзоры кода в свой производственный процесс тем, кто только об этом задумывается.
wtf per minute
Обзор кода является одним из наиболее эффективных методов поиска и устранения дефектов программы. Обзоры проводятся человеком, что позволяет находить широкий класс ошибок, в том числе с трудом детектируемых или вообще не детектируемых автоматическими средствами. Безусловно, обзор кода, не отменяет использование анализаторов кода или других методик обнаружения ошибок, например, unit-тестирования. К сожалению, не существует метода, который один обеспечил бы обнаружение всех дефектов программы (в исследованиях эффективность обзора кода обычно оценивается как 30-50% обнаруженных ошибок в приложении).
Читать дальше →