Рубрика «Проектирование и рефакторинг» - 75

(Перевод)

Последние несколько лет я провел в изучении и экспериментах со многими языками программирования. В частности, я начал использовать Scala как основной язык, стараюсь использовать функциональный стиль везде где это возможно. Меня также весьма заинтересовал Haskell (чистый функциональный язык) и Clojure (современный диалект Лиспа).

Таким образом, я постепенно отказываюсь от объектно-ориентированной парадигмы, несмотря на то, что использовал в основном её последние 17 лет моей профессиональной деятельности. У меня появляется чувство, что объекты это то, что мешает нам писать лапидарный, структурированный и повторно используемый код.
Читать полностью »

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

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

Например на языке Brainfuck Hello world выглядит так:
image
А вот наши критерии удобства:

  • Строгая типизация
  • Документированность
  • Отсутствие “мусора”
  • Однотипность
  • Лаконичность

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

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

Я попробую рассказать обратную историю. Тут около месяца назад я не удачно попытался представить демо версию одной своей разработки (см. Часть №7. RNAInSpace — программное обеспечение для полуавтоматического конструирования РНК в пространстве).

Оказалось, что у скачивающих не работает один модуль, ответственный за показ графики. В двух словах проект RNAInSpace — это программное обеспечение для полуавтоматического конструирования РНК в пространстве. Обеспечивает 3D визуализацию структуры РНК, позволяет её изменять и с помощью связи с модулем RNAWorld позволяет автоматизировать некоторые этапы сворачивания РНК.

Чтобы войти в тему — я тут написал некоторое множество статей:
От белков к РНК, Мат. критерии, Как уменьшить число поворотов цепи?, Как оценить ход сворачивания односпиральной РНК?, Ограничение оптимизирующих методов в играх с противником и без, Одна фундаментальная проблема, Введение в сворачивание многоспиральных РНК

Но эту статью можно обсуждать и не зная предметной области, кстати заодно проверим можно ли судить о качестве ПО не зная семантики предметной области (я утверждаю, что можно).

Так вот эта 3D визуализация (модуль RNAInSpaceDisplay) и не работала на некоторых компьютерах. Для реализации графики я использовал существующий проект VMD 1.8.7.

Ниже история о том как я адаптировал VMD 1.8.7 под свои нужды.

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

Привет. Меня зовут Александр. И я хочу поделится своей историей работы над одним крупным и сложным проектом.

В этой статье не будет кода и схем, в ней будет только история создания «от и до» самого проекта. Думаю, многим будет интересна данная статья. Итак, поехали!

Начало

Все началось летом 2011. На тот момент я был 3 года чистокровным фрилансером. То есть моя работа — это фриланс. Работал и работаю до сих пор только с западными заказчиками. Основная специализация — разработка проектов связанных с распознаванием образов, текста и т.д.

Все началось с того, что я, как всегда, с утра проверял почту, чистил спам, занимался рутинной работой. Обычно я не смотрю, что у меня в спаме, но тут я увидел письмо, с вполне реального адреса. Я открыл письмо, в котором одна компания искала программиста для допиливания крупного западного проекта. Причем эта компания требовала программиста именно из моего города и обязательно с опытом работы в области распознавания. Я ради любопытства ответил на это письмо. Буквально через час мне пришел ответ. А через два мы уже созвонились с менеджером проекта. Поначалу мне показалось, что ничего сложного в доработке нет, обычный набор функционала. После непродолжительного разговора с менеджером я огласил свой прайс, то есть ставку в час. И на этом мы попрощались. На следующий день мне сказали, что согласны на мой ценник и дали тестовое задание. Я его успешно выполнил в течении часа, и мы двинулись дальше. А здесь начинается самое интересное. Во-первых, меня пригласили в офис для того, чтобы подписать договор о неразглашении (Non-Disclosure Agreement). Во-вторых, и это логично, исходники проекта мне обещали отдать только после подписания договора. Если честно, меня это смутило, не знаю даже почему. И интуиция меня не подвела. Я потребовал хотя бы часть исходного кода, чтобы оценить сложность работы и попросил рассказать подробнее о проекте. Как оказалось проект на тот момент велся уже три года и я был 4 (!) исполнителем. До меня работала американская компания, потом индусы, потом компания, которая наняла меня, пыталась реализовать проект силами одной девочки-программиста, а потом это все чудо предложили разгребать мне. Меня это не просто удивило, а очень насторожило. Потом я узнал множество удивительных вещей, например о том, что заказчик 2 года не видел программу, а видел только скриншоты, а индусы кормили обещаниями этого заказчика. У меня не укладывалось в голове, как такое можно реализовать. Менеджеру индусов надо дать медаль «За находчивость».

После того как я выслушал удивительную историю, мы договорились с менеджером о том, что он мне отдаст исходный код и я оценю масштаб трагедии. Чтобы было более понятно, я расскажу более подробно о проекте. Этот проект — это инструмент для инженеров, архитекторов, электриков и других людей, которые занимаются строительством домов, небоскребов, одним словом зданий. Он служит для подсчета различных элементов на строительных планах, расчета площадей, измерения длин и составления смет. Грубо говоря есть строительный план и на нем есть розетки. Нам надо распознать и посчитать сколько этих розеток. Для распознавания использовалась библиотека написанная другим программистом. Сам проект написан на C#. Моя задача была собрать все воедино и доработать дополнительный функционал, а также привести программу к более менее стабильному состоянию. Кажется все просто и элементарно. Я тоже так подумал. Но не тут-то было.

После того как я получил исходники, я попытался скомпилировать проект. Это мне не удалось. После краткого анализа, я исправил ошибки и все же запустил проект. Но, к сожалению, он не заработал так как нужно. После нескольких часов анализа кода я пришел к выводу, что вся проблема в библиотеке распознавания. На тот момент у меня стояла 64-битная «семерка», а у менеджера 32-битная. У него все работало, у меня нет. Я попросил, что бы мне скомпилировали библиотеку под 64-битную платформу. Но разработчик библиотеки с пеной у рта доказывал, что не в разрядности дело. Я не мог ему ничего доказать, так как он дал очень немного информации о своей библиотеке и вообще берег ее как зеницу ока. Время шло и мне надо было хотя бы полностью провести процесс поиска. Я плюнул на все и поставил себе 32-х битную версию ОС. И о чудо! Все заработало. Отвлекаясь, хочу сказать о библиотеке, в будущем дело все же оказалось в ее разрядности.

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

1. Компоненты и контролы.

Проект очень сильно связан с графикой, но для ее вывода и обработки использовался обычный PictureBox. Самый маленький размер плана — 5400x3600 пикселей. Знающие люди поймут, что для PictureBox -это достаточно проблематичная тема с выводом больших картинок и их обработкой. Не стоит забывать, что помимо самих планов выводится еще много информации (площади, текст, найденные символы и т.д.). При запуске проекта с 5 маленькими планами, программа непременно падала с ошибкой «Out of memory». Что было очень большой проблемой, так как основной задумкой было то, что инструмент должен был работать по принципу «запустил и забыл».

2. Логика архитектуры исходного кода программы.

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

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

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

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

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

image
Доброго времени суток всем.

«Как лодку назовешь, так она и поплывет» — довольная известная фраза, которая вполне подходит к функциям, переменным, классам.

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

Например

enum Dates{
  GET_FIRST,
  GET_SECOND,
  GET_BOTH,
  None
}

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

Работаю в проекте, реализованном на C#. Предлагаю решение задачи, с которой столкнулся в проекте.
Условия. Есть классы-сущности, описывающие данные предметной области. При этом бывает и наследование — естественным образом организованное отношение «является». Эти классы описывают данные. Они лежат в отдельной сборке. Есть уровень клиента и уровень сервера. И ими используется эта сборка.
Возникновение задачи. Сборка, описывающая сущности, может описывать поведение только предметной области. Но, возникла задача, когда в слое сервера нужно работать с объектами, описанными в сборке сущностей, у которых уже есть иерархия наследования, полиморфно. При этом нужно сохранять ту же иерархию наследования. Требуемая работа с объектами на сервере не относится к предметной области.
Читать полностью »

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

Это очень простая штуковина, которая может кардинальным образом повлиять на процесс разработки в целом. С одной стороны существует TDD (“test-first approach), при котором тесты «драйвят» не только процессом кодирования, но и процессом проектирования (т.е. дизайном системы). С другой стороны существуют разработчики с противоположной точкой зрения, которые считают юнит-тесты пустой тратой времени, потому что они не приносят никакой ценности пользователю.

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

Представте себе типичное приложение:

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

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

Казалось бы, как можно допустить ошибку в такой типичной ситуации?
Читать полностью »

Представте себе типичное приложение:

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

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

Казалось бы, как можно допустить ошибку в такой типичной ситуации?
Читать полностью »


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