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

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

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

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



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

Как должно быть очевидно, одна из целей этого сайта — убедить принимать 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 семестровых курсов, потом долго топчешься по различным граблям, перенимаешь опыт старших товарищей, изучаешь хорошие и плохие примеры (плохие почему-то чаще).

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

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

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

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

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

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

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

Приветствую, коллеги. За последние несколько лет Stack Overflow стал полезнейшим инструментом для разработчиков. Множество вопросов, заданных Гуглу и Яндексу, в первых же ссылках ведут на понятные и исчерпывающие ответы на этом ресурсе. Большинство разработчиков используют сайт Stack Overflow именно как базу знаний программистов, возможность быстро получить нужный ответ. Под катом я расскажу про несколько интересных кейсов подводной части айсберга: спрятанные ответы, награды, прокачивание кармы и многое другое, скрытое от поверхностного взгляда.

Хотелось бы в очередной раз поднять эту довольно спорную тему.

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

В статье я постараюсь исправить это упущение и расставить ещё немного точек над «ё».

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

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

StyleCop

Задача: реализовать тотальную принудительную проверку кода (C#) на соответствие правилам оформления.

Условие: тотально, принудительно. Т.е. весь код, попадающий на сборку, должен быть проверен в обязательном порядке. В случае обнаружения нарушений — build error и вперёд, рефакторить.

Инструменты: StyleCop, MSBuild (TFS или TeamCity — неважно).

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

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

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

Я по жизни самоучка: если не считать FORTRAN и PL/1, которым меня «учили» в ВУЗе (надеюсь, понятно, как давно это было?), основную часть своих знаний по программированию я получил исключительно методом самообразования. Начинал, как водится, с Pascal и логичным его продолжением Delphi. По мере изменения приоритетов осваивал ассемблер 86-го семейства (MS DOS), а затем, по мере увлечения микроконтроллерами освоил ASM51 и AVR Assembler. Все это давалось мне достаточно просто, т.к. все перечисленное поддается весьма простому и, главное, четко структурированному логичному описанию — я имею ввиду синтаксис и принципы языка.

Закономерно неизбежным был и следующий шаг — переход на Си (подчеркну — в моем случае речь именно о программировании микроконтроллеров), и тут, как говорится, процесс застопорился. Синтаксис Си — та еще штучка, книги по этому языку — отдельная песня. Даже у классиков K&R с первой же главы на неокрепший мозг начинающего обрушивается «работающий helloword», при том что ни единого слова о синтаксисе, об операторах и т.п. сказано не было! Когда я начал изучать стандарт языка Си, у меня возникали суицидально-депрессивные состояния, ибо ранее устаканившееся в мозгу понятие стандарта, как четкого регламента, было разрушено почти полностью!

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

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

Это история о значительной оптимизации интерпретатора Perl, о борьбе со сложностями кода, и о том, как мы хотели «съесть торт так, чтобы он у нас остался» [английская поговорка «You can't have your cake and eat it», означающая невозможность достижения двух противоположных целей].

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

Предыстория

В perlguts и PerlGuts Illustrated написано, что представление переменных в Perl обычно состоит из двух частей – заголовка и тела (представляемых как struct). Заголовок содержит необходимые для обработки переменных данные, которые не зависят от её типа, включая указатель на возможное тело.



Структура тела может сильно отличаться, в зависимости от типа переменной. Простейшая переменная — SvNULL, которая представляет undef и которой не требуется тело.

У строки (PV — “pointer value”) тело имеет тип XPV:



Структура тела PV отличается от тела PVNV. PVNV может содержать число с плавающей точкой и строковое представление того же значения.



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

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

Использование исключений для контроля хода выполнения программы (flow control) — давняя тема. Я хотел бы суммировать этот топик и привести примеры правильного и неправильного использования исключений.

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

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

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

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

Реальность такова, что под «старшим разработчиком» понимается человек, который ваяет код более 3 лет. Его ставят на руководящую позицию, и обычно все заканчивается ожидаемо плачевно.

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


Постер из сериалa «Компьютерщики»