Обновить
128K+

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

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

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

Десятикратная разборчивость

Время на прочтение8 мин
Охват и читатели41K
Каждый знает, что бывают «десятикратные» программисты, которые в 10 раз более производительны, чем программист обыкновенный. Мы не можем измерить производительность, поэтому и не знаем, правда ли это. Но на самом деле людей необыкновенно производительных существует немало, достаточно, чтобы доказать существование «десятикратного программиста».

Как же они этого добиваются?

Часто считают, что десятикратная производительность вытекает из десятикратных способностей или десятикратных знаний. Я так не думаю. Не хочу сказать, что способности или знания бесполезны. Но за много лет я заметил, что самое главное тут — десятикратная разборчивость. Фокус в том, чтобы постоянно уклоняться от паршивой работенки.

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

Техника: Перемещение функций между объектами (рефакторинг М. Фаулера)

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

Пять правил успешного кросс-платформенного проекта

Время на прочтение3 мин
Охват и читатели3.3K
От переводчика: я сейчас по крупицам собираю литературу по проектированию кросс-платформенного ПО. Этот небольшой текст — самое интересное, что я пока нашёл.

Кодеру для реализации конкретной фичи достаточно гугла, но ведь есть особые требования к проектированию? Скажем, ветвление
#ifdef в методах — единственное средство выделения platform-specific частей проекта? (Не много ли макарон?) Есть ли более высокоуровневые подходы, шаблоны, «надстройки» над #ifdef? Надеюсь, этот пост послужит пищей для дальнейшего обсуждения.
Итак, 5 правил

Использование паттернов проектирования в javaScript: Порождающие паттерны

Время на прочтение5 мин
Охват и читатели77K
Привет, хабр!
С удивлением обнаружил отсутствие на хабре развернутой статьи о сабже, что немедленно сподвигло меня исправить эту вопиющую несправедливость.

В условиях когда клиентская часть веб-приложений становится все более толстой, бизнес-логика неумолимо переползает на клиент, а на суверенитет серверных технологий все более смело посягает node.js нельзя не задуматься о приемах проектирования архитектуры на javaScript. И в этом деле нам несомненно должны помочь паттерны проектирования — шаблонные приемы решения часто встречающихся задач. Паттерны помогают построить архитектуру, которая потребует от вас наименьших усилий при необходимости внести изменения. Но не стоит воспринимать их как панацею, т.е., грубо говоря, если качество кода «не фонтан», он кишит хардкодом и жесткой связью между логически независимыми модулями, то никакие паттерны его не спасут. Но если стоит задача спроектировать масштабируемую архитектуру, то паттерны могут стать хорошим подспорьем.
Но впрочем эта статья не о паттернах проектирования как таковых, а о их применении в javaScript. В первой части этой статьи я напишу о применении порождающих паттернах.
Читать дальше →

Что делать с плохим кодом

Время на прочтение3 мин
Охват и читатели36K
Вот мой скромный совет о том, как, по моему мнению, людям следует поступать с плохим кодом. Этот совет не имеет ничего общего с техникой; строго говоря, это даже и не совет, а просто мои недавние размышления.

Обычно, первое, что человек делает, встретив плохой код — ищет виноватого. Это сразу становится личной или племенной вендеттой:
«Как можно быть таким идиотом?»
«Кто виноват в том, что мой мозг взорвался от всей этой бессвязности и богохульства?»
«Кто оскорбляет <Название Компании>!?»

Это неправильно. Не надо начинать с этого. Прежде, чем найти беднягу-автора кода и обрушить на него свой гнев, лучше поймите сам код.
Подробности

Техника: Составление методов (рефакторинг М. Фаулера)

Время на прочтение5 мин
Охват и читатели34K
Начало Код с душком (рефакторинг М. Фаулера) .
В продолжении, техника рефакторинга по книге Рефакторинг. Улучшение существующего кода Мартин Фаулер.

Синтаксис будет на C#, но главное понимать идею, а её можно использовать в любом другом языке программирования.
Читать дальше →

90 рекомендаций по стилю написания программ на C++

Время на прочтение20 мин
Охват и читатели431K
От переводчика. Искал в интернете простой и легко применимый гайдлайн по написанию программ на C++. Мне понравился один из вариантов, и я решил его перевести и опубликовать. Если хабрапользователи хорошо встретят этот топик, могу перевести и другие связанные документы, а также гайдлайны по написанию кода от других компаний.

1 Введение


Настоящий документ содержит рекомендации по написанию программ на языке C++.

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

Но для появления ещё одного списка рекомендаций, помимо указанных источников, есть несколько причин. Основная причина — их излишняя обобщённость, поскольку зачастую требуется задать частные правила (в особенности правила именования). Данный документ содержит комментарии, что делает его более удобным в использовании при проведении ревизий кода, чем другие уже существующие документы. К тому же, рекомендации по программированию обычно вперемешку содержат описания проблем стиля и технических проблем, что не совсем удобно. Этот документ не содержит каких-либо технических рекомендаций по C++, делая упор на вопросах стиля.
Читать дальше →

Код с душком (рефакторинг М. Фаулера)

Время на прочтение2 мин
Охват и читатели82K
Всем привет.

Небольшая шпаргалка для новичков, и всех остальных кто забыл, по книге Рефакторинг. Улучшение существующего кода Мартин Фаулер.
Читать дальше →

Опрос. Выравниваете ли код по столбцам?

Время на прочтение1 мин
Охват и читатели23K
После очередного спора внутри нашей компании решили вынести холивар на хабр.

Собственно, какой из вариантов форматирования кода предпочитаете использовать?

Выравниваю код
foo       = 'bar'
habrahabr = 'Hello, world!'


Не выравниваю код
foo = 'bar'
habrahabr = 'Hello, world!'


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

О стартапе-ловушке, или Роберт Мартин хочет нам навредить

Время на прочтение3 мин
Охват и читатели33K
Я почувствовал, что устои мироздания потрясены, когда сотни хабраюзеров начали яростно спорить по поводу заметки Роберта Мартина о стартапе-ловушке.

Хотите знать, как я обычно участвую в таких спорах?

— Так какие же тесты пишешь ты сам?
— Мнэ-э…

— Когда же ты пишешь тесты?
— Мнэ-э…

— Ты вообще тесты пишешь?
— Мнэ-э…

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

Но как раз сейчас у меня, кажется, есть эта парочка часов.
Читать дальше →

Стартап-ловушка

Время на прочтение4 мин
Охват и читатели78K
  • Вы присоединились к новому стартапу.
  • Вы мегаталантливое создание.
  • Вы можете работать 60, 70, 80 часов в неделю для достижения результата.
  • Вы офигенный разработчик и дизайнер.
  • Вы не попадетесь в ловушки, в которые попадались другие.
  • Вы убедитесь, что в этот раз все будет по-другому.
  • Вы настолько хороши, что правила вам ни к чему.
  • Вы в жопе.

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

В чём разница между использованием MVC и MVP

Время на прочтение2 мин
Охват и читатели74K
Привлекая внимание на проблемы, описанные в статье — «Шаблон MVC — это тупик для разработки приложений?», я считаю, что недостаточно подробно объяснил сам механизм MVC. И для колоритности в этой статье хотел бы осветить и MVP. Думаю, что важно понимать различия между MVC и MVP и общие моменты этих двух парадигм.

Чтобы понять разницу, давайте сначала посмотрим, в каких условиях прижился MVC и какие преимущества он давал приложениям.


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

Про абстрагирование, слабосвязную архитектуру и проектирование в целом

Время на прочтение4 мин
Охват и читатели36K
К хорошим постам «Код в стиле «дамп потока сознания»» и «Микро-рефакторинг, о котором мы так часто забываем».

  • Почему большинство программистов не любят «читать чужой код»?
  • Почему рефакторинг и внесение изменений становятся серьезной проблемой?
  • Почему так часто случается, что легче переписать с нуля?
  • Почему одни программисты называют других хорошими или плохими словами?


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

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

Микро-рефакторинг, о котором мы так часто забываем

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

Введение


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

CoffeeScript 1.5.0 позволяет писать комментарии в формате Markdown

Время на прочтение2 мин
Охват и читатели11K
Сегодня, 25 февраля, вышла версия 1.5.0 языка CoffeeScript. В ней впервые появилась базовая поддержка так называемого «грамотного» или «литературного» программирования (literate programming). Концепцию грамотного программирования придумал Дональд Кнут в 1981 году при разработке системы TeX. В отличие от исходного кода на обычном языке программирования, который включает в себя небольшие вкрапления комментариев, грамотное программирование подразумевает написание текстового документа на естественном языке с вкраплениями кода. Многие существующие системы грамотного программирования вообще не зависят от конкретного машинного языка.
Читать дальше →

Об идеальном коде и суровой реальности

Время на прочтение3 мин
Охват и читатели68K
Думаю, никто не будет спорить, что программный код должен быть чистым и «не пахнуть» (code smell), а паттерны проектирования и TDD должны стать верными спутниками любого мало-мальски грамотного разработчика на протяжении его нелегкой, но продуктивной карьеры. Все также знают, что цена ошибки в продакшине возрастает в десятки раз, а также то, что хорошие программисты оптимизируют код, а плохие — покупают новые сервера, а еще то, что 9 женщин не родят одного ребенка за месяц.



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

Напиши алгоритм для МКС и выиграй 10 тыс. долларов

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

Международная космическая станция

НАСА объявило конкурс на оптимизацию алгоритмов движения солнечных панелей для Международной космической станции. Конкурс ISS Longeron Challenge проводится совместно с порталом TopCoder.
Читать дальше →

ООП-билдер «массивных» параметров

Время на прочтение3 мин
Охват и читатели9K
Многие фреймворки любят магию и сложные многоуровневые массивы для передачи параметров. Что первое, что второе — зло с точки зрения истинно-ленивого программера, который любит IDE и доки всегда под рукой, а не тыкать в интернет/тело вызываемого метода. Мы можем победить это, как образец взяв параметры метода из одного фреймворка и создав ООП-билдер.
Как же он выглядит?

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.» Потом покажите это начальнику и попросите повышения.

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

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

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