30 May, 2009

Использование модификатора protected на полях в базовом классе

Недавно задали мне вопрос - что я думаю об использовании модификатора protected для членов базового класса? Под этим вопросом кроются более серьёзные вещи. Например, любой член класса, имеющий модификатор protected, расширяет интерфейс базового класса для подклассов - подклассы имеют доступ ко всем protected и public методам этого поля. Иногда это сделано специально, например, для того, чтобы подклассы могли иметь доступ к какой-либо функциональности. Однако, если подкласс будет использовать protected поля неправильно (например, он может установить его в null, нарушив, таким образом, поведение базового класса), то это не принесёт пользы. Поразмыслив над вопросом я пришел к следующему, достаточно логичному и широкоизвестному выводу - необходимо давать наиболее закрытый доступ, какой можно. То есть, если можно объявить член класса как private, то необходимо сделать его private. Если в подклассах необходим доступ к члену класса, то необходимо проанализировать, какие методы нужны в подклассах и открыть только их через делегирование. Если набор методов заранее неизвестен, то можно сделать protected getter для поля.

26 May, 2009

Сферический программист в вакууме и абстрактное понятие качества кода в условиях Fixed-Price проектов (часть 2)

Причин для написания плохого кода может быть несколько. Некоторые из них лежат на поверхности:
  1. Отсутствие опыта
  2. Невнимательность
  3. Некомпетентность
  4. Немотивированность
Отсутствие опыта - казалось бы, самая простая причина проблемы; решение проблемы выглядит очевидным - со временем, разработчик будет писать код лучше. Но это ошибочное мнение. Бывает, люди с опытом более 5-10 лет разработки коммерческих приложений пишут настолько плохой код, что иногда кажется, что они это нарочно. Решать эту проблему необходимо постоянным указанием на ошибки. Но это решит только часть проблемы - человек узнает, как писать код в конкретных ситуациях. Но не всякий разработчик (к сожалению, по опыту знаю) сможет экстраполировать знание на все подобные проблемы способ решения. Невнимательность - через это проходят почти все. Почти каждый сможет вспомнить случай, когда не был сделан svn add перед коммитом. Эта проблема решается обычно самомотивацией человека на хороший код. Впрочем, команда и сервер непрерывной интеграции тоже прилагают усилия для того, чтобы человек проверил ещё раз то, что он хочет выложить в репозиторий. Некомпетентность - эта причина пересекается с недостатком опыта, но, при этом отлична от неё. Адекватный разработчик, на мой взгляд, должен стремиться к компетентности в той области, в которой он работает. Но этого, к сожалению часто не происходит. На мой взгляд это из-за следующей причины. Немотивированность. Самое большое зло, которое может быть. Причины недостаточной мотивации разработчика могут быть весьма разнообразными - не выспался, дома проблемы, зарплата низкая, задача скучная и неинтересная. Список можно продолжать до бесконечности. Решение этой проблемы кроется, в первую очередь, в качественном управлении. Менеджер должен быть тонким и хорошим психологом, чтобы видеть или чувствовать все эти проблемы и предотвращать их.

Сферический программист в вакууме и абстрактное понятие качества кода в условиях Fixed-Price проектов (часть 1)

В последнее время всё чаще задумываюсь о том, почему разработчики пишут плохой и некачественный код. Под кодом я подразумеваю не только сам код, но и, в том числе, архитектуру и дизайн. Плохим кодом я считаю следущий:
  1. Невыполняющий функциональные требования
  2. Невыполняющий нефункциональные требования
  3. Непокрытый тестами
  4. Плохо тестируемый
  5. Плохо поддерживаемый
  6. С багами
  7. Неоптимальный
Если код не выполняет функциональные требования, то этот код вообще ничего не стоит. Заказчику такой код не нужен, именно поэтому этот код плохой. На него были потрачены ресурсы, но при этом сам код не имеет никакой ценности. Если код не выполняет нефункциональные требования, то это говорит о том, что либо дизайн, либо реализация, не учли требования и это тоже не добавляет удовлетворённости конечному пользователю. Часто здесь можно провести рефакторинг, но бывает и так, что архитектурные ошибки не дают в принципе выполнить нефункциональные требования, либо их реализация требует очень больших временных затрат. Если код не покрыт тестами, то этот код не работает. Эта аксиома должна всегда быть перед глазами разработчика. Как говорится, самая большая проблема с компьютерами это то, что они делают не то, что разработчик подразумевал, а то, что он написал. Именно поэтому тесты - гарантия того, что код выполняет то, что подразумевает разработчик. Хотя здесь тоже есть проблема, что разработчик не понимает, что именно ему нужно от кода, либо не знает, как протестировать нужную ему функциональность. Плохо тестируемый код. Такой код часто встречается, когда не используется TDD, в связи с этим разработчик не понимает или не знает, что именно он хочет от кода. Также, плохо тестируемый код это признак того, что код имеет не самую лучшую архитектуру (например, высокий coupling) Плохо поддерживаемый код это любой код, который сложно поддерживать. Сюда относятся любые ошибки в коде, которые осложняют поддержку - нет единого стиля форматирования, неясные имена переменных, методов, классов, плохая декомпозиция, отсутствие или наличие устаревших тестов, комментариев, документации, или, что ещё хуже ошибки в комментариях, документации, плохая архитектура (как её отсутствие, так и overdesigned). Все эти проблемы в конечном итоге влияют на качество проекта и на удовлетворённость заказчика. Код с багами. Логично, что это плохой код, и это, к сожалению, часто встречающийся код. По статистике, на 1000 строк кода приходится 10-12 багов. К сожалению, этот показатель меняется в зависимости от различных факторов (компетентность разработчика, сроки, сложность архитектуры, используемый язык и технологии и т.д.) и часто в сторону ухудшения. Неоптимальный код не всегда плохой, при условии, что он выполняет функциональные и нефункциональные требования, а также лёгок в поддерживании. Продолжение следует...

23 May, 2009

Google Application Engine

Посмотрел на Google App Engine (GAE). При своей цене (= бесплатно) это очень хороший сервис. GAE - это инфраструктура для запуска веб-приложений на серверах Google. То, что сейчас модно называть cloud computing. На презентации платформы в 2008 году Google объявил только о поддержке Python. Год спустя, в апреле 2009 года Google заявил о поддержке Java, правда с ограничениями. Собственно, поддержка Java и была тем самым толчком, что я решил поближе посмотреть на платформу.

Возможности

Google App Engine предоставляет следующие возможности как платформа:
  • масштабируемость
  • кластеризация
  • он-лайн мониторинг
  • балансировку нагрузки
  • безопасность
  • горизонтальное масштабирование базы данных
  • отказоустойчивость

Ограничения

Как и любое бесплатное решение у платформы есть ограничения. На данный момент эти ограничения следующие:
  • Ограниченный набор Java API
  • Нереляционное хранилище данных
  • Ограничение доступа к другим компьютерам
  • Из доступных языков: Python, Java и JVM-based
  • Ограничения на используемые ресурсы

Технологии

App Engine Services

База данных

Это небезызвестный BigTable. Для работы с ним используется GQL. Для Java-реализации используется JDO с ограниченной поддержкой JPA.

Применение

Уже сейчас существует много приложений, которые размещены на серверах Google. Многие из них доступны в галерее приложений App Engine На мой взгляд, использование нереляционной модели данных накладывает свои ограничения на тип проектируемых приложений, так как не всегда возможна полная денормализация данных.

Впечатления от использования SDK

Обзор не был бы полным, если бы я не попробовал написать простенькое приложение для платформы. Для этого необходимо зарегистрироваться на App Engine и запросить поддержку Java. Google объявил, что попробовать платформу можно только первым 10000 разработчикам. Судя по всему, ещё можно успеть, так как я получил доступ в течении 15 минут (приходит ключ по SMS). Подтверждение на поддержку Java пришло в течении суток. Google предоставляе SDK для работы с платформой. В SDK входят скрипты для создания приложения, загрузки их на сервера Google и API для доступа к вышеперечисленным сервисам платформы. Кроме того, при разработке используются заглушки для сервисов (например, для User Service API), которые позволяют локально писать и отлаживать приложение. Компания SpringSource объявила о поддержке Grails на платформе Google App Engine. Это не может не радовать, но первые впечатления были смазаны, так как плагин appengine для Grails ещё нужно дорабатывать. Например, кодогенератор заточен для gorm, который сделан поверх hibernate, но так как appengine не поддерживает hibernate, для генерации CRUD приходится делать следующие пассы: включать hibernate плагин, генерировать CRUD, отключать hibernate плагин. Надеюсь, в следующей версии appengine плагина эта проблема будет решена. Остальные проблемы можно почитать как в комментариях к анонсу, так и в джире проекта.

Альтернативные платформы

Самым известным, наверно, является Amazon EC2, а замыкает тройку Microsoft с их Windows Azure. Amazon не предоставляет бесплатной дозы, в отличии от Microsoft и Google. При этом Amazon предоставляет shell-доступ к серверам. Сравнивать в целом платформы не имеет смысла, поэтому не буду.

02 May, 2009

Eclipse и его расширения

Многие ругают Eclipse за то, что там нет многого из того, что есть в коробке у Jetbrains Intellij IDEA. Мне всегда казалось это не очень корректным, так как Eclipse в первую очередь платформа, а уже потом - среда для Java разработки.
Решил собрать воедино весь список используемых мною расширений для Eclipse.
  1. Subclipse - без этого никуда. Это расширение позволяет работать с системой контроля версий Subversion не выходя из Eclipse.
  2. m2eclipse - Расширение для работы с maven. Графический редактор pom.xml позволяет избавиться от редактирования pom.xml вручную. В качестве приятного дополнения - возможность посмотреть графически список зависимостей проекта (вместе с транзитивными), а так же увидеть ситуации, когда 2 разные библиотеки зависят от разных версий одной и той же библиотеки.
  3. Google Plugin for Eclipse - официальное расширение от Google для работы с Google Web Toolkit и Google Application Engine.
  4. Eclipse-CS - Нет, это не запускалка Counter Strike, а всего лишь расширение, интегрирующее статический анализатор исходного кода Checkstyle в Eclipse. Проверяет правильность форматирования кода согласно заданным правилам. Обязательное расширение при работе в команде.
  5. Spring IDE - расширение от команды SpringSource для работы с проектами, использующими Spring, в том числе Spring AOP и Spring Webflow.
  6. XMind - отличное расширение, предоставляющее mind-mapping возможности в Eclipse.
  7. JBoss Tools - наборо расширений для работы с продуктами JBoss - Hibernate, JBoss AS, Drools, jBPM, JSF, (X)HTML, Seam, Smooks, JBoss ESB, JBoss Portal...
  8. EclEmma - интеграция отличной библиотеки EMMA в Eclipse. EMMA - приложение для подсчёта покрытия кода тестами. Must-have расширение.
  9. TPTP - Под этой странной аббревиатурой скрывается Test & Performance Tools Platform. Набор расширений для тестирования и профилирования приложений.
  10. PMD - Интеграция библиотеки PMD, которая выполняет статический анализ кода на предмет возможных ошибок в коде.
  11. WTP - Web Tools Platform - официальный набор расширений для разработки Web и Java EE приложений.
  12. Groovy & Grails - расширение для работы с языком Groovy и фреймворком Grails.
  13. eGit - расширение предоставляет возможность работы с распределенной системой контроля версий git.
  14. Eclipse SQL Explorer - тонкий SQL-клиент, который позволяет просматривать различные JDBC-совместимые базы данных.
Очень много расширений есть на Eclipse Plugin Central

Также, все плагины, на которые я обращаю внимание можно найти на del.icio.us