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

Хай, Хабр!
Сегодня я хочу представить, дорогому хабрасообществу свой первый хабраперевод. Программировать на языке Python — подобно песне. Но еще лучше, когда Ваш код читаем и понятен, а значит чуть более поэтичен, чем обычно бывает производстве. У каждого свои правила и свои стереотипы относительно написания и оформления исходного кода, на каком бы языке он ни был написан. Множество копий сломано о щиты на форумах, но, как ни крути, нельзя не считаться с мнением авторитетных товарищей. Так что сейчас будет представлен перевод первой части стайл-гайда для языка Python от Google. Коснется он именно постулатов написания кода (вторая часть тоже скоро появится, а посвящена она будет форматированию исходного кода). Сразу предупреждаю: тут много (если не большая часть) прописных истин, которые все знают уже давно. Но я искренне надеюсь, что Вы сможете найти тут что-то новое или хотя бы вспомнить старое. Приступим под катом. И pdf тут как тут.

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

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

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

Начало Код с душком
Техника: Составление методов

В продолжении, техника рефакторинга по книге Рефакторинг. Улучшение существующего кода Мартин Фаулер.

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

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

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

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

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

Обычно, первое, что человек делает, встретив плохой код — ищет виноватого. Это сразу становится личной или племенной вендеттой:

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

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

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

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

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

1 Введение

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

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

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

Всем привет.

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

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

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

Выравниваю код

foo       = 'bar'
habrahabr = 'Hello, world!'

Не выравниваю код

foo = 'bar'
habrahabr = 'Hello, world!'

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

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

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

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

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

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

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

Но как раз сейчас у меня, кажется, есть эта парочка часов.

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

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

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

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

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

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

Введение

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

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

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



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

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

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

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

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