вторник, 2 апреля 2013 г.

Анти-тесты

Ещё более интересная тема, чем просто тесты. Проверка AV, выхода за границ массивов и прочих граничных условий. Да так, чтобы гарантировать ДЕТЕРМИНИРОВАННОСТЬ поведения. ExpectedException - из этой серии.

... to be continued ...

Об атомарных тестах

Тесты вида:

Check(2 * 2 =4);

Или тем более:

Check(2.0 * 2.0 = 4.0);

Или:

Check(X / 2.0 <> X); (Про "эпсилон" - надеюсь все слышали)

Или тем более:

Check(MyStream.ReadLn = 'Эталонная строка'); // - вы конечно - ГЕНИАЛЬНЫЙ программист, но и эта строка может отвалиться, например при переходе на новую версию Delphi

-- тоже весьма полезны.

Чуть позже я постараюсь подробно осветить и эту тему.

Шаблон operation на примесях

Интересно? Писать?
--------------------------------------------------
Вот что нам рассказывает Википедия:
http://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BC%D0%B0%D0%BD%D0%B4%D0%B0_(%D1%88%D0%B0%D0%B1%D0%BB%D0%BE%D0%BD_%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F)

Шаблон publisher/subscriber на примесях

Интересная тема? Писать?

Подведение итогов дня

Вечером я гуляю с собакой.

Хожу и думаю. Подбиваю результаты. Собаке не очень это нравится. Ну а что делать...

Оцениваю - что получилось, а что нет. Ставлю - "галочки" - ЧТО ЖЕ я КОНКРЕТНО сделал. Хвалю себя, если есть за что.

Прикидываю план на следующий день.  Расставляю приоритеты. Заношу заметки в телефон. Ставлю напоминалки - чтобы они на следующий день оповестили меня о том, что надо завести задачу.

Возвращаюсь домой и стараюсь выкинуть работу из головы. Совсем. До следующего утра.

Не всегда правда получается.

Как поддерживать производительность труда и не терять самоуважения

Каждый день с утра, едучи на маршрутке на работу - я ставлю себе ЗАДАЧУ НА ДЕНЬ. Которую я должен сделать.

Это может быть:
1. Написание отлаженного класса.
2. Исправление ошибки.
3. Написание теста.
4. Реализация ТЗ.
5. Рисование UML-диаграммы.
6. Написание документации.
7. Уточнение ТЗ выразившееся в конкретные артефакты.

Хоть что-то из этого списка. А лучше - несколько. Болтовня в CQ и электронной почте в этот список не входит. Равно как и сёрфинг интернета. Равно как и болтовня на совещаниях. Важен РЕЗУЛЬТАТ, а не процесс

Должны быть артефакты, которые положены в CVS или SVN.

Если день прошёл без этого - я считаю день прожитым впустую.

Fire And Motion. Огонь и движение.
http://russian.joelonsoftware.com/Articles/FireAndMotion.html
http://www.joelonsoftware.com/articles/fog0000000056.html

Попробуйте. Может быть и вам понравится.

понедельник, 1 апреля 2013 г.

"Я же вам говорил!"

"Я же вам говорил!"

Это - неправильная фраза при согласовании ТЗ. А особенно для разработчика.

А особенно - когда он таки - оказался прав по результатам разработки.

Всё равно - ничего кроме негатива - она не несёт.

Не надо её использовать. Не надо "дразнить гусей". Это фраза не для разработчиков. Для КОГО УГОДНО, но только НЕ ДЛЯ разработчиков.

Просто - "поставьте себе галочку". Или напишите assert.

Я сам неоднократно пользовался этой фразой. Поверьте мне. И кроме негатива - я так ничего и не заработал.

И если услышите её из моих уст - напомните мне про этот пост.

P.S. эту фразу можете оставить только для САМЫХ БЛИЗКИХ ДРУЗЕЙ. Они вас наверное поймут.

Марко Канту переезжает в Россию?

О ТЗ, цейтноте и "позабывании"

Фрейд З. ЗАБЫВАНИЕ ИНОСТРАННЫХ СЛОВ
Фрейд З. Психопатология обыденной жизни
З. Фрейд. Введение в психоанализ. Лекции >> Забывание имен собственных и иностранных названий, а также иностранных слов тоже можно свести к противоположному намерению, которое прямо или косвен...
Непроизвольная память

Людям свойственно забывать. Всем. Это - аксиома.

Руководству, дизайнерам, аналитикам, заказчикам (stakeholder'ам короче) - иногда свойственно не отвечать на ВСЕ заданные вопросы. Это - допущение. Если у вас не так - вам повезло. Тогда это пост не для вас. Не читайте. Спите спокойно.

Но! Часто бывает ситуация, когда ТЗ передано в разработку, но оно вызывает вопросы.

Делайте свою работу честно.

Нет ничего более ужасного, чем недовыясненные вопросы спрятанные в глубины вашего гениального кода. Его всё равно никто не оценит.

Уважайте своих коллег, которые придут "лет через десять после вас".

ЗАДАВАЙТЕ ВОПРОСЫ!

И ДОБИВАЙТЕСЬ ответов на них.

Если в процессе реализации ТЗ у вас возник вопрос требующий ответов stakeholder'ов, то для того, чтобы сохранять состояние "потока" и при этом НЕ СНИЖАТЬ темп разработки - я советую вам следующее:

1. Задайте вопрос.
2. УБЕДИТЕСЬ, что он дошел до адресата.
3. Напишите ASSERT. Да, да! Банальный assert с условием, которое вам непонятно.
4. Сформулируйте в комментариях к коду СУТЬ вопроса.
5. Укажите ДАТУ и время задания вопроса. По CVS это будет сделать муторно, да и лень.
6. Укажите номер "тикета" в базе данных или дайте ссылку на обсуждение, если оно проходит в электронном виде.
7. Предусмотрите более-менее вразумительное сообщение в лог для пользовательского варианта системы. ОТКЛЮЧАЙТЕ ASSERT'ы в пользовательском варианте системы.
8. Напишите - EXIT. Вдруг там дальше вы написали ёщё какой-то свой гениальный код.
9. Ждите ответа на вопрос и продолжайте реализацию ТЗ.
10. Если в течении "разумного" времени вы не получили ответа - дополните комментарий к коду подробностями - "когда, кто и где".
11. Если вы не получили ответов - закрывайте задачу и передавайте её в Группу Качества. Желательно при закрытии задачи указать список недовыясненных подробностей. Может быть группа качества поможет вам. И сразу откатит задачу с указанием подробностей.
12. Если вы получили ответ на вопрос - скажите "спасибо" тому, кто его дал. Ведь он - "сделал часть вашей работы".
13. Удалите ASSERT.
14. Напишите вменяемый код, учитывающий данный вам ответ.
15. Напишите тест - этот аспект системы занял не только ваше время и нервы, но и чужие. Он УЖЕ СТОИТ того, чтобы быть покрытым тестом.
16. Спите спокойно, пока какой-нибудь ASSERT не разбудит вас.

Попробуйте. Может вам понравится.

Сразу предупреждаю - может не понравиться stakeholder'ам. Но я бы - всё равно попробовал.

В конце концов - они честно делают свою работу , делайте и вы. Честно. И ДУМАЙТЕ о тех, кто придёт вам на смену. Они могут оказаться не такими гениальными как вы.

И если вы думаете - "ах у меня 800-т незаконченных задач. Ах как мне трудно.." Посмотрите сюда:

это - самоирония... если что...

P.S. Есть и альтернативные сценарии. Но все они по-моему - менее выигрышные.

Вот как я их вижу:
1. Не задавать вопросы и полагаться на свои силы. Не считайте себя черезчур гениальным.
2. Не задавать вопросы и оставить всё как есть. По-моему - в не думаете о будущем.
3. Задать вопросы и переключится на другую задачу. Тут тратим силы и время на переключение контекстов и выход из одного "потока" и вход в другой. Это - затратно.
4. Задать вопросы и ждать все ответы на них. И ничего не делать. Я - так не умею. Я сразу начинаю мучатся безделием и терять уважение к самому себе.
5. Вернуть ТЗ на доработку и забыть о нём. "Пока эта вся бюрократия раскачается". Это - самый неконструктивный путь. Если вы выбираете его - подумайте - стоит ли вам работать программистом. "Просто получать деньги" - можно и в другом месте. Например на Forex. Или в других "мыльных пузырях".

А вы знаете про проблемы с WM_SIZE в Win64?

Проблемы таки - есть в Win64 вообще и в VCL - в частности. WM_Size - не всегда доходит. Потому что увеличился размер указателя и при большой вложенности контролов у MS где-то банально кончается стек. И в итоге сообщение до контролов банально не доходит. В результате получаем эффект того, что размеры формы (или другого контейнера) - изменились, а вот вложенные контролы - не пересчитали свои размеры. И дизайн формы - "поплыл". Скроллеры в воздухе повисли, ну и т.п. Причём проблема касается как Win32, так и Win64 приложений. Т.е. проблема зависит не от типа приложения, а именно от типа ОПЕРАЦИОННОЙ СИСТЕМЫ. Под которой приложение запускается.

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

А также постараюсь описать свой путь лечения VCL "на коленке".