пятница, августа 31, 2007

Архивы в сети

В Сети помимо порнографии есть и ещё кое-что :-) В частности, выложены в сеть архивы многих выдающихся учёных.

Программистское


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

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

А во-вторых о том, не случится ли что-то с этими сайтами в будущем, не исчезнут ли они? Каждый раз хочется все к себе скачать :-)

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

воскресенье, августа 19, 2007

Про типы

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

Все описанное в статьях (как тех на которые я ссылался, так и первоисточниках имени Chris Smith и Luca Cardelli), написано на довольно высоком уровне. Мне же кажется, что очень важным моментом здесь является "качественное" понимание, объяснение, так сказать "на пальцах". Потому что без подобного понимания знание фактов и определений скорее является следованием "культу карго", чем настоящим знанием.

Итак, что же такое типы и зачем они нужны?

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

Как известно математики часто проводят в своих рассуждениях чёткое различие между элементами, множествами элементов, функциями и так далее. Для новой переменной, используемой в первый раз, математик определяет "тип", например: "Пусть f - это функция действительного переменного". Часто в книгах (обычно во введении и предисловии) также даются подобные определения: "В дальнейшем для множеств будут использоваться прописные буквы". Эти определения являются не более чем "помощниками" для читателя, позволяют ему быстрее ориентироваться в дальнейшем тексте.

Представители логики и теории множеств предпочитали не иметь дело с переменными различных "типов". Однако, такая необходимость появилась весной 1901 года, когда, во время работы над фундаментальным трудом "Principia Mathematica" известный английский математик и философ Бертран Рассел сформулировал так называемый парадокс Рассела:

"Пусть S - это множество всех множеств, которые не содержат себя в качестве элемента. Содержит ли S само себя?"

Любой ответ, данный на этот вопрос практически мгновенно приводит к противоречию. Данный парадокс можно также переформулировать несколькими более "жизненными" способами:

  • Деревенскому брадобрею приказали «брить всякого, кто сам не бреется, и не брить того, кто сам бреется», как он должен поступить с собой?

  • В одной стране вышел указ: «Мэры всех городов должны жить не в своем городе, а в специальном Городе мэров», где должен жить мэр Города мэров?

  • Некая библиотека решила составить библиографический каталог, в который входили бы все те и только те библиографические каталоги, которые не содержат ссылок на самих себя. Должен ли такой каталог включать ссылку на себя?
Решение этого парадокса, предложенное Расселом носит название "теории типов" и заключается в том, что каждой логической или алгебраической переменной приписывается "тип", который определяет, обозначает ли она [переменная] элемент, множество, множество множеств и так далее. Далее, Рассел постулировал, что любое утверждение вида" x является элементом из y" грамматически осмысленно лишьтогда, когда x - переменная типа элемент, а y - переменная типа множество или x - переменная типа множество, а y - переменная типа множество множеств и так далее. Любое утверждение, не удовлетворяющее этому правилу считается бессмысленным - вопрос о его истинности или ложности просто не существует, оно представляет собой просто набор букв.

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

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

Особенностями понятия типа являются:
  1. Тип определяет класс значений, которые могут принимать переменная или выражение
  2. Каждое значение принадлежит одному и только одному типу
  3. Тип значения константы, переменной или выражения можно вывести либо из контекста, либо из вида самого операнда, не обращаясь к значениям, вычисляемым во время работы программы
  4. Какой операции соответствует некоторый фиксированный тип операндов и некоторый фиксированный (обычно тот же самый) тип результата. (операции, обозначаемые одним и тем же символом, но производимые над различными типами операндом считаем разными)
  5. Для каждого типа свойства значений и элементарных операций над значениями задаются при помощи аксиом.
Таким образом знание типа, позволяет обнаруживать в программе бессмысленные конструкции и предотвращает множество ошибок.

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

Использованные материалы:
  1. Russel's Paradox
  2. Парадокс Рассела - Википедия
  3. Luca Cardelli. Type systems.
  4. К. Хоор "О структурной организации данных" из книги У. Дал, Э. Дейкстра, К. Хоор "Структурное программирование", Москва, Мир, 1975

суббота, августа 04, 2007

Реальное рабочее время

Меня продолжает сильно интересовать проблема оценки сроков проекта. В этой связи я наконец добрался до книги Steve McConnel Software Estimation: Demystifying the Black Art, которая в русском переводе имеет совершенно удивительное название "Сколько стоит программный проект". (на самом деле объяснить название конечно можно, поскольку в содержании книги сроки, затраты или рабочее время считаются более или менее взаимозаменяемыми понятиями).

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

В книге описаны различные способы оценки сроков (или затрат) на выполнение проектов, но меня заинтересовало вот что.

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

Насколько это число соответствует действительности - неважно, лучшего у нас все равно нет. Однако важным является то, учитывает ли это число время, проведённое на работе, но при этом потраченное на "нерабочие дела" - интернет, кофе, перекуры и так далее.

В связи с этим какое-то время назад я организовал на RSDN голосование поэтому поводу. Вот вопрос, который я задавал и результаты голосования:

Вот такие результаты. Думаю, что при планировании очень стоит помнить про то, что не все время, проведённое на работе, действительно уделяется работе.

Замечания

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

  1. "Подобные подсчеты бессмысленны". Бизнес сторона программирования требует выдачи сроков. Более того, часто невозможно даже давать сроки по Steve McConnel - при помощи диапазонов. И человеку, который должен составить оценку волей или неволей приходится выдавать прогноз. И лучше если у него есть понимание того, что выданная оценка скажем в 5 часов рабочего времени - это в реальности два рабочих дня.
  2. "Настоящий программист может думать о работе и дома и во время отдыха, поэтому непонятно что считаем". Действительно, это так. И действительно это не особенно то и подсчитаешь. Программа подсчёта рабочего времени может подсчитать сколько времени у меня на экране была открыта Visual Studio, но вряд ли догадается, что я в это время думал про то, как здорово понырял в красном море. Тут мой ответ таков - лучше хоть какие-то, пусть даже заниженные оценки, чем никаких.
На самом деле, мне кажется вышеуказанные замечания вызваны некоторой боязнью, что данные о том сколько человек "реально" работает могут быть использованы для оценки работы человека и последующих выводов с точки зрения зарплат, премий, повышений и тому подобного. Ничего такого я не имел ввиду и считаю, что подобное использование таких данных только повредит проекту. Эти данные нужны управленцу исключительно для того, чтобы точнее планировать работу и выдавать более точные сроки, но ни в коем случае для того, чтобы выделять "лучших" и "худших".

17458907.195e50a0db7e7428ccd693c67f635406.1186223110.9626a2d31cf793845f340f27c23ea8b8

пятница, августа 03, 2007

К вопросу о "стандартах кодирования"

На форуме Artima Developer Spotlight появилась тема: "What's the Most Effective Code Style Policy?", посвящённая обсуждения "стандартов кодирования".

Немного о терминологии

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

Рассмотрим возможные смыслы термина:

  1. Стиль и синтаксис форматирования исходного кода программы
    • Расстановка скобок
    • Использование пробелов и пустых строк
    • Правила написания выражений (for, if, while и так далее)
    • Правила именования переменных
    • Правила объявления переменных
    • Правила написания комментариев
    • Правила использование отступов
  2. Иногда к содержанию первого пункта могут быть добавлены элементы "управления конфигурацией"
    • правила именования файлов
    • структура файлов проекта
    • правила использования системы контроля версий
    • стандартизация используемых средств разработки
  3. Иногда к стандартам кодирования могут также быть добавлены "best practices" того, как надо писать программы, в зависимости от определённого языка программирования, среды разработки, компании или специфики разрабатываемого продукта (типичным примером может служить требование "всегда создавать в классе виртуальный деструктор", для C++)
Конечно же, "стандарты кодирования" могут включать в себя содержимое и всех пунктов сразу, и какую-то их смесь, а также что-то что здесь не упомянуто.

Мой взгляд

Здесь я хочу ответить на вопрос, заданный в теме на форму Artima - "What's the Most Effective Code Style Policy?".

Обращаю внимание, что все дальнейшие рассуждения касаются "стандартов кодирования" в смысле (1) и оставляют аспекты (2) и (3) без внимания.

Основной необходимостью существования "стандартов кодирования" обычно называют (некоторые части процитированы по Code Conventions for Java Programming Language, они отмечены '*'):
  1. Необходимость работ над одним и тем же исходным файлом нескольким программистам
  2. Улучшение "понятности" исходного кода, что позволяет программистам более полно и быстро понять новый для них код (*)
  3. Необходимость сопровождения (исправления ошибок, внесения небольших исправлений) кода и тот факт что в большинстве случаев споровождение осуществляется не тем же человеком, который является исходным автором кода. (*)
  4. Программист, работающий над исходным кодом, который написан не в "любимом" или "привычном" стиле будет тратить на его исправление больше времени (аргумент Bill Venners из исходного сообщения в форуме).
Моё мнение состоит в том, что усилия на создание и поддержание "стандартов кодирования" в большинстве случаев существенно выше чем затраты на "понимание" или поддержку кода, написанного "в другом стиле". Я конечно не имею ввиду примеры из "Obfuscated C Code Contest" :-) В большинстве случаев, код написанный вменяемым программистом понятен другому вменяемому программисту, вне зависимости от того, как именно расставлены в нем фигурные скобки или именованы переменные. Единственной неприятностью могут быть различия в настройках отступов и табуляций/пробелов, при просмотре кода различными текстовыми редакторами, просмотрщиками и программами сравнения.

Поэтому в моей голове всегда существовал такой "стандарт кодирования":
  1. Единообразная настройка длины табуляции (tab length)
  2. Использование пробелов вместо табуляций
  3. При правке кода пользоваться тем стилем, который используется в этом коде
Вот собственно и все. А если Вы или Ваш коллега пишете код в стиле "Obfuscated C Code Contest", то подумайте может проблема должна быть решена не при помощи "стандартов кодирования", а как-нибудь по-другому?

17458907.195e50a0db7e7428ccd693c67f635406.1186161181.ba176d26a55281a16d8fd8b02a541ce8
17458907.48319b4763d4aa2700c0fda3363b9fab.1186391267.b8da257c7d1fa1c830df3b9f73d6fb72