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

Вашему вниманию предлагается перевод поста о том, как разрабатывался Windows Azure API: о трудностях, удачных и неудачных решениях, сделанных выводах. Далее — текст автора.

После разговора с моим коллегой по работе о REST API мне пришла в голову идея рассказать о своем опыте организации и работы команды, которая создала Windows Azure Service Management API. На написание этого поста меня вдохновили такие великолепные статьи в жанре “чему я научился” как эта за авторством Foursquare и эта от Даниэля Джакобса из Netflix.

Предупреждение: Все рассказанное под катом — мое личное мнение. Я даже не уверен, что остальные участники команды со мной согласны. И я точно знаю, что некоторые из высказанных мыслей довольно противоречивы.

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

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

Мы продолжаем рассказывать интересные зарисовки из жизни колл-центров, телекомов и облачной телефонии. Случалось ли вам отвечать на звонок и слышать “пожалуйста подождите, оператор сейчас свяжется с вами”? Первая мысль, которая приходит в голову обычно нецензурна, вторая — “они что, вконец обнаглели?!?”. Получивший такой звонок пользователь — жертва хитрой технологии “предиктивного обзвона”, которая позволяет колл-центрам экономить сотни часов времени, но иногда приводит к забавным результатам. Под катом я расскажу про эту штуку подробнее и покажу, как она может быть реализована в несколько строк кода на нашей облачной платформе voximplant

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

Итак, первое моё знакомство с языками программирования состоялось в школе, и был это Бэйсик. С тех пор с языками программирования я не пересекался. Прошло больше 20 лет и мне понадобилось изучить один из современных языков программирования. Всем критериям предъявляемым мной языку программирования, которые я смог сформулировать на тот момент, полностью удовлетворял C#. Засучив рукава, я принялся его изучать и у меня появилась возможность оценить насколько изменились языки программирования за это время.

Многое было привычно, если не по внешнему виду, то по концепции: переменные, циклы, операторы ветвления… А что-то было совсем новым: ООП с его классами (полями, методами, свойствами), наследованием и т. д.
Конечно, многое порадовало. Классы теперь позволяют заниматься распределением обязанностей: Так, ты мне принеси «то»; Ты сделай «это»; Ты посчитай мне «это», результат сообщишь. Это очень напоминает наше взаимодействие с окружающей средой. Например, зашли в прачечную, отдали грязное постельное бельё, забрали чистое. Зашли в ателье, отдали ушить брюки, забрали готовый вариант. Зашли в закусочную, сделали заказ, получили завтрак. Очень удобно и наглядно.
Но вернёмся с теме статьи. Я никак не ожидал спустя 20 лет увидеть в языках программирования некоторые вещи:

Представляю вашему вниманию перевод документа "Coding Guidelines for C# 3.0, 4.0 and 5.0".

Целью создания этого списка правил является попытка установить стандарты написания кода на C#, которые были бы удобными и практичными одновременно. Само собой, мы практикуем то, что создали. Эти правила являются одним из тех стандартов, которые лежат в основе нашей ежедневной работы в AvivaSolutions. Не все эти правила имеют четкое обоснование. Некоторые из них просто приняты у нас в качестве стандартов.

Статический анализатор кода VisualStudio (который также известен как FxComp) и StyleCop могут автоматически применять многие из правил кодирования и оформления путем анализа скомпилированных сборок. Вы можете сконфигурировать их таким образом, чтобы анализ производился во время компиляции или был неотъемлемой частью непрерывной или ежедневной сборки. Этот документ просто добавляет дополнительные правила и рекомендации, но его вспомогательный сайт www.csharpcodingguidelines.com предоставляет список правил анализа кода, необходимых в зависимости от того, с какой базой кода вы работаете.

Здравствуйте уважаемые обитатели Хабра. Написать это меня сподвигла статья Программисты не понимают. Это будет крик души одинокого начинающего веб-перфекциониста в уши большинства существующих веб-студий и веб-девелоперов.

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

Владимир Мегре



Статья посвящается Зацепину П.М., выдающемуся инженеру Алтайского государственного университета, под чьим чутким руководством многие студенты, включая автора статьи, постигали магию инженерного творчества.

Введение

Спор о возможности использования в программах оператора GOTO ведётся уже очень давно (официальным его началом признана статья Дейкстры «О вреде оператора GOTO», опубликованная в 1968 году [2]). Через три года мы будем праздновать 50-летний юбилей этого спора. Это хороший повод, чтобы наконец-то «расставить все точки над i» и прекратить спор.

Цитата в эпиграфе выбрана неслучайно. Она в точности отражает текущую ситуацию в споре про GOTO. В нашем случае «комната за закрытой дверью» – это понятная всем постановка задачи. Пока, к сожалению, такой постановки задачи озвучено не было, поэтому споры и не угасают. Противоборствующие стороны спорят хоть и о схожих, но всё-таки о разных вещах, поэтому и не могут найти компромисса.

Давайте займём в этом споре нейтральную сторону, и беспристрастно во всём разберёмся. Рассмотрим доводы «противников» и «защитников» оператора GOTO и решим, «кто из них прав, а кто виноват».

Привет хабр! Основная речь пойдет про разработку на .Net, то есть с использованием Microsoft Visual Studio, ReSharper, Nuget и пр.
Я думаю, многие из вас разрабатывали большие решения (в msdn — solution), со множеством подпроектов. И в этом случае нередко становилась проблема синхронизации Nuget пакетов, настроек сборки и т.д. Причем, ReSharper здесь поможет слабо, разве что он тоже начнет путаться во множестве используемых библиотек.
Чтобы проверять исходный код, было сделано Open Source решение — SolutionCop, которое бесплатно для использования.
Для начала приведу парочку примеров, когда не помешали бы проверки наших решений.

Пример 1: разные версии Nuget библиотек.

Например, есть три проекта: exe, dll1 и dll2. exe ссылается на обе библиотеки, каждая из них ссылается, например, на RX. Но dll1 использует RX 2.2.0, а dll2 — RX 2.2.5. На деле, далеко не сразу можно получить ошибку, так как сигнатуры функций более-менее совпадают, более того, MsBuild чаще всего собирает проекты в одном и то же порядке. Однако подобная конфигурация может привести к проблемам, которые появятся после deployment'а, когда все модульные тесты пройдут (т.к. они ссылаются только на свою библиотеку), и когда будет готовиться результирующий набор файлов.

Пример 2: проект ссылается на библиотеку напрямую, а не через Nuget.

Опять возьмем три наших проекта: exe, dll1 и dll2. Допустим, мы также используем еще Jetbrains.Annotations, чтобы размечать код NotNull/CanBeNull аттрибутами и получать симпатичный статический анализ. Но вот незадача: для dll1 мы честно скачали пакет версии 9.2.0, а в dll2 мы просто попросили ReSharper добавить ссылку, что он и сделал. В итоге, в packages.config файле dll2 нет пакета с аттрибутами, а значит, если проект будет собираться в порядке dll2 --> dll1 --> exe, то мы получим ошибку, ведь Nuget пакет скачается только при сборе dll1!

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

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

Разработка Parallels Access потребовала создания геораспределенного сервиса, позволяющего безопасно устанавливать связь между компьютерами и мобильными клиентами пользователей в различных точках земного шара. Команда, которая над ним трудится, хочет поделиться полученным опытом в форме цитат, чтобы облегчить участь тем, кто только планирует создание своего клиент/серверного продукта, и погрузить в ностальгию профессионалов, имеющих за спиной дюжину успешных проектов:

Эпичный эпиграф:
«Паттернов можешь ты не знать,
но управленье знать обязан!»

«Большое видится на расстояньи»

Кто знаком с теорией Геделя о неопределенности (которая получила не совсем точное название «о неполноте»), тот понимает: все (достаточно) сложные системы испытывают принципиальные трудности в самопознании и самоописании на определенном уровне глубины и детальности. Сразу уточню: я НЕ утверждаю, что между теорией вышеупомянутого Г. и “вечными” (именно в кавычках!) проблемами ООП имеется прямая связь, нет. Но я, тем не менее, утверждаю, что проблемы «совершенного кода» – объективно не разрешимы. Не вообще никогда, а ровно до того момента, пока мы наконец-то не выйдем за пределы самого ООП – и не посмотрим на него с высоты еще более сложной системы. «Большое ведь видится на расстояньи»!

Наверняка вы уже знаете об операторе безопасной навигации ("?." операторе) в C# 6. В то время как это довольно хороший синтаксический сахар, я хотел бы отметить варианты злоупотребления этим оператором.

— Мы забрели в зону с сильным магическим индексом-объяснил он, — Когда-то давно здесь образовалось мощное магическое поле.
– Вот именно, — ответил проходящий мимо куст.
Терри Пратчетт, Цвет волшебства

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

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



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

Как должно быть очевидно, одна из целей этого сайта — убедить принимать F# всерьёз в роли универсального языка разработки.

Но в то время как функциональный стиль всё больше проникает в массы, и C# уже получил такие функциональные средства как лямбды и LINQ, кажется, что C# всё больше и больше наступает на пятки F#. Так что, как это ни странно, но я стал всё чаще слышать как высказывают такие мысли:

• «C# уже обладает большей частью инструментария F#, и зачем мне напрягаться с переходом?»
• «Нет никакой необходимости что-то менять. Всё, что нам нужно сделать, так это пару лет подождать, и C# получит достаточно от F#, что обеспечит практически все плюшки.»
• «F# только чуть лучше, чем C#, но не настолько, чтобы в самом деле тратить время с переходом на него.»
• «F# кажется действительно неплох, хоть и пугает местами. Но я не могу найти ему практического применения, чтобы использовать вместо C#.»

Не сомневаюсь, что теперь, когда и в Java тоже добавлены лямбды, подобные комментарии зазвучали в экосистеме JVM при обсуждении «Scala и Closure против Java».

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

Если вы программист (или чего хуже архитектор), то можете ли вы ответить на такой простой вопрос: как писать НЕ тестируемый код? Призадумались? Если с трудом можете назвать хотя бы 3 способа добиться не тестируемого кода, то статья для вас.

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

Языки программирования и среды разработки развиваются непрерывно, предлагая современному разработчику всё больше и больше вкусностей. Я уверен, что не за горами тот день, и наступит время, когда компьютеры научатся понимать живую речь и преобразовывать её в машинный код. Я решил представить, как это может выглядеть в реальности, быть может даже этому немного поспособствовать. Кстати, название данной статьи написано на ICQuery в том виде, как я его себе представляю, и является исходным кодом аналога её функции main.

Когда её нет

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

Во многом такое негативное отношение объясняется отсутствием культуры программирования у большого количества PHP-разработчиков. Почему так происходит? Да, у этого языка действительно низкий порог вхождения и легко освоить его может человек без специального технического образования. Изучив основы, можно сразу делать небольшие проектики и даже продавать свои услуги на биржах фрилансеров. А раз на такое есть спрос, зачем тратить время на углубление своих знаний, когда деньги можно зарабатывать уже сейчас?

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

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

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

Всем привет.

При конструировании приложений хорошим тоном является использование Dependency Injection(внедрение зависимостей). Данный подход позволяет делать код слабо связанным, а это в свою очередь обеспечивает легкость сопровождения. Также облегчается тестирование и код становится красивым, универсальным и заменяемым. При разработке наших продуктов с самого начала использовался этот принцип: и в высоконагруженной DSP и в корпоративном Hybrid. Мы писали модули, подключали интеграцию с различными системами, количество зависимостей росло и в какой-то момент стало сложно поддерживать само конфигурирование приложения. Плюс к этому добавлялись неявные регистрации(например, кастомный DependencyResolver для Web Api задавался в настройках Web Api) и начали возникать сложности с порядком вызова модулей конфигурации. В конце концов мы выработали подход для регистрации, конфигурации и инициализации модулей в сложном приложении. О нём и расскажу.

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

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

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

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

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

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

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

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

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