Рубрика «Совершенный код» - 39

50 оттенков Go: ловушки, подводные камни и распространённые ошибки новичков - 1

Go — простой и забавный язык. Но в нём, как и в любых других языках, есть свои подводные камни. И во многих из них сам Go не виноват. Одни — это естественное следствие прихода программистов из других языков, другие возникают из-за ложных представлений и нехватки подробностей. Если вы найдёте время и почитаете официальные спецификации, вики, почтовые рассылки, публикации в блогах и исходный код, то многие из подводных камней станут для вас очевидны. Но далеко не каждый так начинает, и это нормально. Если вы новичок в Go, статья поможет сэкономить немало часов, которые вы бы потратили на отладку кода. Мы будем рассматривать версии Go 1.5 и ниже.
Читать полностью »

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

Эти доработки включают перекрытие методов Object.Equals(Object) и Object.GetHashCode().

Остановимся подробнее на особенностях реализации метода Object.Equals(Object) для соответствия следующему требованию в документации:

x.Equals(y) returns the same value as y.Equals(x).

// и, как следствие, следующему:

If (x.Equals(y) && y.Equals(z)) returns true, then x.Equals(z) returns true.

Класс Person, созданный в предыдущей публикации, содержит следующую реализацию метода Equals(Object):

Person.Equals(Object)

public override bool Equals(object obj)
{
    if ((object)this == obj)
        return true;

    var other = obj as Person;

    if ((object)other == null)
        return false;

    return EqualsHelper(this, other);
}

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

В соответствии с примером, приведенным в документации, приведение производится с помощью оператора as. Проверим, дает ли это корректный результат.
Читать полностью »

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

Невзламываемый код существует - 1

Весною 2015 года команда хакеров пыталась взломать беспилотный военный вертолёт под названием Little Bird («Птичка»). Вертолёт, схожий с пилотируемой версией любимого спецназом США летательного аппарата, находился на территории компании Boeing в Аризоне. У хакеров была фора: в начале их работы они обладали доступом к одной из подсистем управляющего компьютера. Им оставалось лишь взломать основной бортовой полётный компьютер и получить контроль над БПЛА.
Читать полностью »

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

По умолчанию два объекта считаются равными, если соответствующие переменные содержат одну и ту же ссылку.
В противном случае объекты считаются неравными.

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

Пусть есть класс Person, содержащий персональные данные — имя, фамилию, и дату рождения персоны.

На примере этого класса рассмотрим:

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

Для каждого случая рассмотрим, каким именно образом лучше реализовать сравнение объектов по значению, чтобы получился согласованный и, насколько это возможно, компактный, copy-paste free, производительный код.

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

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

Извилистый путь разработчика - 1

Учиться программированию — пожизненная затея. Почти всегда будет попадаться что-то новое, о существовании чего вы ещё не знали.

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

После разговора с @PrototypeAlex, где мы обсуждали множество этапов, которые проходят разработчики, у меня появилось вдохновение написать об этом. За 30 лет, которые я пишу код, я прошёл почти через каждый описанный в статье этап, и некоторые были особенно болезненными.

Узнаёте себя на каком-нибудь из этих этапов? И что я пропустил? Многие этапы ускользают из моего поля зрения; мы никогда не перестаём учиться и делать открытия.

Великий Копипастер

Писать код трудно, но люди решили проблему за вас! Ваш браузер переходит к Stack Overflow при вводе "s" в адресной строке, и вы часами вставляете различные фрагменты кода, чтобы увидеть, какой из них выполняет то, что вам требуется. Иногда это высасывает моральные силы, но в итоге у вас появляется хоть какой-то рабочий код.Читать полностью »

Правила плохого и хорошего тона в программировании — мнения экспертов - 1

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

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

Для слабых разработчиков работа в изоляции может стать непреодолимым препятствиемЧитать полностью »

The Pros & Cons of Test-Driven Development - 1

Test-driven development (TDD) — практика, известная уже довольно давно. Разработка через короткие циклы «прежде всего пишем юнит-тест, затем код, потом проводим рефакторинг, повторяем» в ряде компаний принята в качестве стандарта. Но обязательно ли команда, достигшая хорошей степени зрелости процесса разработки, должна принимать TDD? Как и для большинства других практик Extreme Programming, споры по поводу TDD до сих пор не стихают. Оправдываются ли первоначальные затраты на обучение и внедрение TDD? Даёт ли TDD ощутимый выигрыш? Можно ли этот выигрыш измерить? Нет ли случаев, когда TDD проекту вредит? А есть ли ситуации, когда без TDD решить задачу просто невозможно?

Об этом мы поговорили с разработчиками-экспертами Андреем Солнцевым asolntsev (разработчик из таллинской компании Codeborne, который практикует Extreme Programming и придерживается TDD) и Тагиром Валеевым lany (разработчик в JetBrains, также разрабатывает опенсорсную библиотеку StreamEx и анализатор байткода Java HuntBugs; убежден, что TDD — бесполезная практика). Интересно? Добро пожаловать под кат!
Читать полностью »

25 октября 2016 года Майкл Фезерс, Director of R7K Research & Conveyance и автор книги «Working Effectively with Legacy Code», выступит на uDev Tech Events с лекцией на тему «Micro Refactoring and Macro Refactoring: Strategies and Techniques».

Читать полностью »

Работать в проекте без ошибок — мечта любого ИТ-шника. Достижимо ли это в реальности? Этот вопрос является одновременно и простым и сложным, потому что, чтобы избежать ошибок, надо с одной стороны иметь строго выверенную цепочку начиная от формирования общих требований до детальной реализации. С другой стороны, в сферу ИТ вливается поток специалистов, которые слабо представляют, как можно доказать отсутствие ошибок в программе или выстроить структуру, которая сокращает возможности ошибок, прежде всего логических, которые носят принципиальный характер.
Читать полностью »

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

Здесь и далее я буду рассматривать общекнижный пример с сотрудниками предприятия, писать будем на чем-то СИ-подобном. Наследовать класс Сотрудник (Employee) от класса Человек (Person) – прекрасная идея, особенно если хранить данные исключительно в памяти: SQL имеет некоторые проблемы с наследованием таблиц, но речь не об этом — ООП со своим иерархизмом, агрегациями, композициями и наследованиями предлагает идеальный способ организации данных. Проблемы с методами.

За каждым методом бизнес-логики стоит факт мира, который этот метод (чаще не в одиночку) моделирует. Факты программирования – это операции: дальше будем называть их так. Делая метод членом класса, ООП требует от нас привязать операцию к объекту, что невозможно, потому что операция – это взаимодействие объектов (двух и более), кроме случая унарной операции, чистой рефлексии. Метод ВыдатьЗарплату (PaySalary) может быть отнесен к классам Сотрудник (Employee), Касса (Cash), БанковскийСчет (Account) – все они равнозначны в праве владения им. Дилемма о расположении методов сопутствует всему процессу разработки: неловкое ее разрешение может оказаться критичным и даже фатальным.

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


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js