​Start with try-catch-finally

Начните с try-catch-finally.
Размещая код в секции try-catch-finally, вы утверждаете, что выполнение программы может прерваться в любой точке, а затем продолжиться в секции catch. Секция catch должна оставить программу в целостном состоянии, что бы ни произошло в секции try. По этой причине написание кода, который может инициировать исключения, рекомендуется начинать с конструкции try-catch-finally. Это поможет вам определить, чего должен ожидать пользователь кода, что бы ни произошло в блоке try.

#exceptions

Command Design Pattern

Command Design Pattern: позволяет инкапсулировать запрос на выполнение определенного действия в виде отдельного объекта. Этот объект запроса на действие и называется командой. При этом объекты, инициирующие запросы на выполнение действия, отделяются от объектов, которые выполняют это действие.

#designpatterns

​Do not pass null

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

#functions #arguments

​Follow Standard Conversions

Соблюдайте стандартные конверции.
Все рабочие группы должны соблюдать единые стандарты кодирования, основанные на отраслевых нормах. Стандарт кодирования определяет, где объявляются переменные экземпляров; как присваиваются имена классов и т.д. Документ с явным описанием этих правил не нужен - сам код служит примером оформления.
Главное - правила должны соблюдаться всеми участниками группы.

#principles

Agile. Кросс-функциональные команды и самоорганизация

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

#architecture #principles

​Avoid negative conditions

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

#conditions

Clean HTML

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

#html #css

​Unambiguous Names

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

#naming #functions

Agile: Кросс-функциональные команды и самоорганизация. Part2

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

#architecture #principles

​Flags in Arguments

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

#functions #arguments

​Lack of Tests

Недостаток тестов. Сколько тестов должен включать тестовый пакет? К сожалению, многие программисты руководствуются принципом "Пожалуй, этого хватит". Тестовый пакет должен тестировать все, что может ломаться. Если в системе остались условия, не проверенные тестами, или вычисления, правильность которых не подтверждена, значит, количество тестов недостаточно.

#tests

YAGNI

YAGNI — процесс и принцип проектирования ПО, при котором в качестве основной цели и/или ценности декларируется отказ от избыточной функциональности, — то есть отказ добавления функциональности, в которой нет непосредственной надобности.

#architecture

Agile: Кросс-функциональные команды и самоорганизация в основе Agile. Part3

В предыдущей статье из цикла мы разобрались с понятием кросс-функциональных команд, "официально" привнесённым в мир Agile фреймворком Scrum, и постарались донести их преимущество относительно традиционного деления по "зонам ответственности". Но теперь перед нами обязательно встает вопрос - как организовать работу всей команды...

#agile #scrum

​Inappropriate static methods

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

#functions

Scrum: Ошибки при работе и как их исправить.

Scrum — одна из разновидностей гибких методологий разработки программного обеспечения agile. Но многие команды, которые заявляют, что работают по скраму, на самом деле не понимают или не придерживаются принципов, которые отличают его от других подходов. Автор блога на Hacker Noon Эрик Вайс описал наиболее частые заблуждения.

#agile #scrum

​Artificial bindings

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

#dependencies

​Avoid Wit

Избегайте остроумия. Если имена ваших методов, переменных или комментариев будут излишни остроумны, то их смысл будет понятен только людям, разделяющим чувство юмора автора - и только, если они помнят шутку.
Остроумие часто воплощается в форме просторечий или сленга. Например, не используйте имя whack() вместо kill(). Не используйте шуточки, привязанные к конкретной культуре, - например, eatMyShorts(), вмесо abort().

#naming

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

Engineers Don’t Want Clean Code

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

#programming #cleancode