Михаил Смирнов

Партионный учет в интернет-магазине

2011-10-30T22:11:00.000+04:00

Пару лет назад передо мной стояла задача организации партионного учета в интернет-магазине.

Здесь я расскажу о том, как это было сделано.

Для начала коротко о том, что такое партионный учет и зачем он нужен в интернет-магазине.
Представьте, что ваш магазин продает, скажем, кроссовки. При этом он периодически делает закупки у поставщиков и производит отгрузку покупателям.

Перед вами стоит задача определения размера прибыли, приносимой магазином.

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

Продемонстрирую это на примере.
Предположим, вы закупили 10 пар кроссовок по 100 рублей и через месяц еще 10 пар 200 рублей. Затем у вас возник заказ на 12 пар кроссовок, которые вы продали по 300 рублей (общая сумма заказа 12 x 300 = 3600 р.).

Теперь определим маржу. Она составляет (300 – 100) х 10 + (300 - 200) х 2 = 2200 р.

Т.е. мы видим, что в данном заказе присутствовало 10 пар кроссовок из первой партии, которая была закуплена по 100 рублей и 2 пары из второй партии, которая была закуплена по 200 рублей.

Для правильного подсчета маржи нам и необходим партионный учет.

Теперь о том, как это было реализовано на практике.

Прежде всего приведу схему базы данных.

Рассмотрим таблицы этой схемы.

Products – справочник продуктов.
ProductModifications – таблица, содержащая разновидности, модификации или варианты продукта. Например, вышеупомянутые кроссовки могут быть разного размера или цвета и для каждого из них нужен свой учет.
Orders – таблица заказов
OrderItems – табличная часть заказов
ProductIncomes – таблица поступлений товаров на склад
ProductOutcomes – таблица списаний товаров со склада
ProductOutcomesToParties – вспомогательная таблица, определяющая закупочные цены.

Теперь более подробно об этих таблицах.

Таблица ProductModifications содержит закупочную цену последней партии (поле OriginalPrice) и текущую продажную цену (поле Price). Закупочная цена последней партии не участвует непосредственно в партионном учете. Она имеет чисто информационный характер.

Цена продажи (Price) определяет по какой цене в настоящий момент происходит продажа товара.

Таблица OrderItems содержит ссылку на модификацию товара, количество (Count) и цену продажи (Price).

Таблица ProductIncomes позволяет содержит историю поступления товаров на склад. Для каждого поступления содержится дата (IncomeDate), закупочная цена (OriginalPrice) и количество поступившего товара (Count).

Таблица ProductOutcomes содержит историю списаний товаров со склада. Она также содержит дату списания (OutcomeDate), количество товара (Count) и отпускную цену (Price). Кроме продаж, могут существовать и другие причины списания товаров со склада – например, возврат некондиционного товара или временное резервирование. Для отметки таких списаний применяются поля ReturnToAuthour и IsReserved.

Все вышеперечисленные таблицы заполняются в процессе работы интернет-магазина. Справочники товаров и поступлений заполняются администраторами, заказов – покупателями и администраторами, списания заполняются автоматически при создании заказов, либо администраторами для случая списаний без заказов.

Для того, чтобы подсчитать маржу каждого конкретного проданного товара, нам надо заполнять таблицу ProductOutcomesToParties. Для каждого списания со склада эта таблица содержит несколько записей, которые содержат закупочную цену товара и количество закупленного по данной цене товара. Если рассматривать приведенный выше пример с кроссовками, то эта таблица должна содержать две записи – для каждой из закупленных партий.

Итак, наша задача состоит в том, что правильно рассчитать закупочные цены и заполнить таблицу ProductOutcomesToParties.

Для этого мы должны полностью отследить историю движения по складу каждой модификации товара.

Для начала создадим представление ProductMoves, которое будет содержать всю историю движения товара – т.е. объединение историй поступлений и списаний.

CREATE VIEW [dbo].[ProductMoves]
AS
SELECT MovType, ID, ProductModificationID, Date, Price, Count, OrderID, 
       CONVERT(bit, ReturnToAuthor) AS ReturnToAuthor, CONVERT(bit, IsReserved) AS IsReserved
FROM
    (SELECT 1 AS MovType, ID, ProductModificationID, IncomeDate AS Date, OriginalPrice AS Price, 
            Count, 0 AS OrderID, 0 AS ReturnToAuthor, 0 as IsReserved
     FROM ProductIncomes
     UNION ALL
     SELECT 2 AS MovType, ID, ProductModificationID, OutcomeDate AS Date, Price, 
            Count, OrderID, ReturnToAuthor, IsReserved
     FROM ProductOutcomes) AS a

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

В данной таблице у нас хранится ссылка на партию (PartyID) – т.е. на запись в таблице ProductIncomes, текущее количество товара данной партии на складе (CurrentCount), закупочная цена (Price), дата партии (PartyDate) и ссылка на модификацию продукта.

Для расчета закупочных цен создадим хранимую процедуру RecalculateWarehouse, которая решает эту задачу цен для заданной модификации товара.

Рассмотрим код процедуры. В коде процедуры приведены комментарии, объясняющие ее работу.

CREATEPROCEDURE [dbo].[RecalculateWarehouse]

@PMID int, -- ID модификациитовара

@Result nvarchar (max) output -- Результат работы процедуры

set @Result = ''

-- Сохраняем историю движения товара вовременную таблицу.

-- Делаем это для того, чтобы расчетомне мешать работе магазина.

select* into #ProductMoves

fromProductMoves (nolock)

whereProductModificationID =@PMID

declare@MoveID int, @MoveType int, @Price money, @Count int, @MoveDate datetime, @MovOrderID int

-- Определяем курсор по историидвижения товара.

-- Данный курсор будет пробегаться повсем фактам поступлений и списаний по мере их
-- наступления

-- Для этого в курсоре примененасортировка по дате и типу движения
-- (чтобы в случае одинаковых дат поступления всегда шли перед списаниями).

declarecur cursor local for

selectMovType, ID, Price, [Count], date, OrderID

from#ProductMoves

orderby date, MovType

--Открываемкурсор

opencur

fetchnext from cur into @MoveType, @MoveID, @Price, @Count, @MoveDate, @MovOrderID

-- И бежим по всей истории движенийтовара по складу

while @@fetch_status = 0

begin

-- Обрабатываем поступления на склад

if @MoveType = 1

begin

-- Если данная партия товара еще не зарегистрирована наскладе

if (selectcount (*)
from ProductWarehouse wherePartyID = @MoveID) = 0

-- Регистрируем даннуюпартию товара на складе

                                  insert into ProductWarehouse
                                   (PartyID, CurrentCount, Price,
                                   PartyDate, ProductModificationID)

select @MoveID, @Count, @Price, @MoveDate, @PMID

else -- Еслиданная партия уже была зарегистрирована на складе

-- Обновляем информацию о ней

update ProductWarehouse

set CurrentCount = @Count, Price = @Price

where PartyID = @MoveID

end

-- Обрабатываем списания со склада

if @MoveType = 2

begin

-- Определяем временную таблицу, в которую будут помещены
-- результаты определения закупочных цен

declare @parties table (ID int, Date datetime, Price money)

declare @PresentedCountint

-- Определяем количество товара на складе на моментсписания

                           select @PresentedCount = isnull (sum ([CurrentCount]), 0)
                           from ProductWarehouse (nolock)
                           where ProductModificationID= @PMID and PartyDate < @MoveDate

-- Если количествотовара на складе достаточно для списания

if @PresentedCount >= @Count

begin

-- Заполняем таблицу закупочных цен теми партиями,
-- текущихколичеств на складе которых

-- достаточнодлясписания

insert into @parties (ID, Date, Price)

select ID, PartyDate, Price

from ProductWarehouse (nolock)

where ProductModificationID= @PMID and
CurrentCount > 0 and PartyDate < @MoveDate

order by PartyDate

declare @pid int, @PPrice money, @PDate datetime

-- Определяем курсорпо всем партиям, которые на
-- данный момент есть на нашем складе

declare pcur cursor local for

select id, Price, Date from @parties order by Date

open pcur

declare @SaleCount int

set @SaleCount = @Count

-- Удаляем результатыпредыдущих расчетов

delete from ProductOutcomesToParties
whereProductOutcomeID =@MoveID

fetch next from pcur into @pid, @PPrice, @PDate

-- Пробегаем по всемпартиям товара до тех пор,
-- пока не наберем достаточное

-- количество товара, для заполнения всего списания

while @@fetch_status = 0 and @SaleCount > 0

begin

declare @CurrentCountint, @DecCount int

-- Определяем текущееколичество товара на складе
-- для данной партии

select @CurrentCount = CurrentCount
from ProductWarehousewhere ID = @pid

-- Если текущегоколичества товара достаточно

if (@CurrentCount >= @SaleCount)

begin

-- Уменьшаем текущее количество товара на
-- количествотребуемого товара

set @DecCount = @SaleCount

set @CurrentCount=@CurrentCount- @SaleCount

set @SaleCount= 0

-- Обновляем количество товара на складе

update ProductWarehouse

set CurrentCount = @CurrentCount

where ID = @pid

-- Сохраняем закупочныецены

                                                   insert into ProductOutcomesToParties
                                                               (ProductOutcomeID, [Count],
                                                                IncomePrice, IncomeDate)

select @MoveID, @DecCount, @PPrice, @PDate

end

else

-- Если текущего количества товара НЕ достаточно

begin

-- Полностью забираем товар из данной партии

-- Затем уменьшаем кол-во требуемого товара

set @DecCount = @CurrentCount

set @SaleCount=SaleCount - @CurrentCount

set @CurrentCount = 0

-- Обновляем количество товара на складе

update ProductWarehouse

set CurrentCount = @CurrentCount

where ID = @pid

-- Сохраняем закупочные цены

select @MoveID, @DecCount, @PPrice, @PDate

end

fetch next from pcur into @pid, @PPrice, @PDate

end

close pcur

deallocate pcur

end

else

-- Если количество товара на складе НЕ достаточно длясписания

-- Вообще говоря, такая ситуация является ошибочной

-- Но все же мы ее обрабатываем на тот случай,
-- еслиинформация о поступлениях товара

-- еще не была занесена в базу данных

begin

declare @PsevdoPrice money, @PsevdoDate datetime

-- В качестве закупочной цены берем последнюю закупочнуюцену

set @PsevdoPrice = isnull (

(select top 1 Price from ProductWarehouse (nolock)

where ProductModificationID= @PMID and
PartyDate < @MoveDate

order by PartyDate desc), 0)

-- Тоже самое делаем и с датой

set @PsevdoDate = isnull (

(select top 1 PartyDate from ProductWarehouse (nolock)

where ProductModificationID= @PMID and

PartyDate < @MoveDate

order by PartyDate desc), @MoveDate)

-- Удаляем результаты предыдущих рассчетов

delete from ProductOutcomesToParties
whereProductOutcomeID =@MoveID

-- Сохраняем закупочные цены

insert into ProductOutcomesToParties
(ProductOutcomeID, [Count], IncomePrice, IncomeDate)

select @MoveID, @Count, @PsevdoPrice, @PsevdoDate

-- Обновляем количество товара на складе

update ProductWarehouse

set CurrentCount = 0

where ProductModificationID= @PMID and PartyDate < @MoveDate

                             set @Result = @Result + N'Ошибка рассчета. В заказе'
                                           + convert (nvarchar (16), @MovOrderID) +
                                 N' на дату ' + convert (nvarchar (16), @MoveDate, 104)
                               + N' ' + convert (nvarchar (16), @MoveDate, 108) +
                                 N' требуется списать ' +convert (nvarchar (50), @Count)
                               + N' шт. товара, на складе -' +
                               convert (nvarchar (50), @PresentedCount) +
                               N'</b> шт. Товар был продан по цене <b>' +
                               convert (nvarchar (50), @Price) +
                               N', закупочная цена определена как ' +
                               convert (nvarchar (50), @PsevdoPrice) + N''

end

fetch next from cur
into @MoveType, @MoveID, @Price, @Count, @MoveDate, @MovOrderID

end

close cur

deallocate cur

drop table #ProductMoves

if @Result = ''

set @Result = 'OK'

Теперь создадим процедуру, которая выполняет рассчет закупочных цен для всех товаров.

CREATE PROCEDURE [dbo].[RecalculateAllWarehouse]
AS
create table #res (ProductID int, Result nvarchar (max))

declare @PMID int, @ProductID int

declare cur cursor local for 
select ID, ProductID from ProductModifications (nolock) order by ID

open cur

fetch next from cur into @PMID, @ProductID

while @@fetch_status = 0
    begin
        declare @res nvarchar (max)        

        exec RecalculateWarehouse @PMID, @res output

        insert into #res (ProductID, Result)
        select @ProductID, @res

        fetch next from cur into @PMID, @ProductID
    end

close cur
deallocate cur

select *
from #res
order by ProductID

drop table #res

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

70-433

2011-10-20T15:28:00.001+04:00

Эх, давненько я не брал в руки шашек!

Позавчера сдал экзамен 70-433 “Microsoft SQL Server 2008, Database Development”.

При этом набрал максимальный балл – 1000 из 1000 возможных.

Экзамен, в общем-то, не сложный, но все равно приятно

Как заставить работать filtered indexes в MS SQL Server 2008.

2011-08-18T15:12:00.003+04:00

Недавно мы столкнулись со следующей проблемой – создали несколько filtered indexes, которые не хотели работать – оптимизатор не хотел их использовать, даже если условия запроса удовлетворяли условиям индекса.

В Books online проблема описана довольно скупо, но вот что удалось выяснить – для нормальной работы filtered indexes необходимо произвести те же настройки, которые нужны для indexed views или indexed computed columns, а именно (http://msdn.microsoft.com/en-us/library/ms175088.aspx):

ANSI_NULLS ON
ANSI_PADDING ON
ANSI_WARNINGS ON
ARITHABORT ON
CONCAT_NULL_YIELDS_NULL ON
NUMERIC_ROUNDABORT OFF
QUOTED_IDENTIFIER ON

После включения этих опций filtered indexes начинают работать как надо.

Первая встреча Костромского клуба тестировщиков

2011-08-15T21:08:00.003+04:00

Сегодня состоялось первое собрание Костромского клуба тестировщиков (http://www.clubqa.ru).

Честно говоря, я не ожидал такого количества народу на данном мероприятии. По моим оценкам там присутствовало порядка 40-50 человек.

Собрание было достаточно коротким – было прочитано всего два доклада.

Первый доклад читала Виктория Птицына. Ее доклад назывался “Азы тест-анализа и тест-дизайна”. Доклад был посвящен основным понятиям и подходам процесса тестирования.

Второй доклад назывался “Что должен знать тестировщик”. Читал доклад Иосиф Иткин. Его доклад освящал основные компетенции тестировщика и направления его развития.

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

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

И напоследок несколько фотографий с собрания.

Шаблон договора на разработку сайта - в помощь фрилансеру

2011-08-11T17:46:00.001+04:00

В помощь фрилансерам выкладываю шаблон договора для заключение контрактов на разработку сайтов.
Скачать шаблон договора можно по следующей ссылке: http://www.msmirnov.ru/public/ContractForSite.doc

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

Текст шаблона привожу ниже.

Договор № _______
на проведение работ по разработке интернет-сайта «___________».

г. ______________________ «__» __________ 20__ г.

___________________________________________________________,зарегистрирован(а) по адресу _________________________________________________________________,с одной стороны, и

_______________________________________________________________________________________________________________________________________________________,с другой стороны,

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

1. ПРЕДМЕТ ДОГОВОРА

1.1. Исполнитель по поручению Заказчика выполняет работы поразработке и внедрению интернет-сайта «______________» в объеме, определяемом Приложением №1 к настоящему Договору «Техническое задание»,в сроки, предусмотренные Приложением №2 к настоящему Соглашению,«Календарный план».

2. ОБЯЗАННОСТИИСПОЛНИТЕЛЯ

Исполнитель обязуется:

2.1. оказать услуги в соответствии с разделом 1настоящего Договора;

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

3. ОБЯЗАННОСТИЗАКАЗЧИКА

Заказчик обязуется:

3.1. оплатить оказанные услуги в размерах и в сроки,установленные настоящим Договором;

3.2. выпустить приказ о формировании группы сопровожденияпроекта, ответственной за своевременное и правильное выполнение обязательств понастоящему Договору со стороны Заказчика. В данной группе определяетсяответственный исполнитель. Список членов группы, копии приказа о назначенииответственного исполнителя передать Заказчику в течение 5 дней с датыподписания настоящего Договора.

3.3. обеспечить согласование документов в сроки,определенные Календарным планом (Приложение №2 к настоящему Соглашению).

3.4. при наличии согласованной Сторонами необходимости, обеспечитьсотрудникам Исполнителя возможность оказания услуг в помещениях Заказчика неменее 10 (десяти) рабочих часов в сутки по рабочим дням и в выходные дни;

3.5. обеспечить сотрудникам Исполнителя, прибывшим наобъекты Заказчика для оказания услуг по Договору, безопасные условия труда ипроведения инструктажей в соответствии с правилами техники безопасности.

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

4. СТОИМОСТЬРАБОТ И ПОРЯДОК РАСЧЕТОВ

4.1. Общаястоимость работ Исполнителя по настоящему Договору составляет ____________________рублей.

4.2. Заказчик выплачивает аванс в размере ________________рублей в сроки определенные в Приложении № 2 к настоящему Договору, «Графикработ».

4.3. Сумму, эквивалентную __________________ рублей,Заказчик оплачивает в сроки определенные в Приложении № 2 к настоящему Договору,«График работ».

4.4. Дополнительные работы по проекту осуществляются израсчета ________ руб / чел.час. При этом исполнитель предоставляет переченьдополнительно выполненных работ с указанием даты их проведения и стоимости.Оплата дополнительных работ производится в течении _____ рабочих дней со дняпредоставления перечня.

5. СРОКИ ОКАЗАНИЯУСЛУГ

5.1. Сроки работ определяются Приложением № 1 к настоящему Договору,«Календарный план».

5.2. В случае задержки предоставления Заказчиком исходныхданных (п. 3.6)срок действия Договора и сроки выполнения обязательств Исполнителем переноситсяна время задержки.

5.3. Сроки оказания услуг могут быть изменены в процессе ихоказания только по соглашению Сторон.

5.4. При появлении новых деталей и обстоятельств, неуказанных в Техническом задании, стоимость и время разработки проекта будетувеличено в соответствии с пунктом 4.4 настоящего Договора.

6. ПОРЯДОКСДАЧИ-ПРИЕМКИ

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

6.2. Оказанныепо настоящему Договору услуги Заказчик принимает путем подписания Актасдачи-приемки услуг, оформляемого в 2 (двух) экземплярах.

7. ОТВЕТСТВЕННОСТЬСТОРОН

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

8. Гарантийныеобязательства

8.1. Исполнитель предоставляет услуги гарантийной поддержкипрограммного обеспечения разработанного по настоящему Договору. Гарантийнаяподдержка включает исправление обнаруженных ошибок в работе разработанных илидоработанных Исполнителем частей программного обеспечения без изменениясогласованного перечня требований к соответствующему программному обеспечению,зафиксированных Сторонами при выполнении работ по настоящему Договору к нему,при условии соблюдения Заказчиком порядка эксплуатации программногообеспечения, описанного в эксплуатационной документации к нему.

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

8.3. Под ошибкой понимается несоответствие документациифункционалу программного обеспечения (ошибка в документации) либосистематическое невыполнение или некорректное выполнение функций программы(ошибка в коде), которое отвечает одному из критериев:

8.3.1. несоответствует документации на программное обеспечение;

8.3.2. явноприсутствует (проявляется) в обслуживаемом программном обеспечении;

8.3.3. неявляется явным следствием одного или нескольких обстоятельств:

8.3.3.1. ошибочногопользования программное обеспечение;

8.3.3.2. несанкционированногоизменения или дополнения ПО;

8.3.3.3. сбоясмежного программного либо аппаратного обеспечения;

8.3.3.4. недостаточностиаппаратных или телекоммуникационных ресурсов;

8.3.3.5. неисправностиили изменения оборудования, на котором ПО установлено;

8.3.4. неявляется следствием изменения регламентов деловых процессов Заказчика.

8.4. Гарантийный срок составляет ________ месяцев с датыподписания Сторонами Акта сдачи-приемки выполненных работ.

9. ИМУЩЕСТВЕННЫЕПРАВА

9.1. Заказчику принадлежат исключительные имущественныеправа на разработанное по настоящему Договору программное обеспечение интернет-сайта«_______________________».

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

10. ПРОЧИЕУСЛОВИЯ

10.1. Настоящий Договор вступает в силу с момента егоподписания Сторонами и действует до выполнения ими принятых на себяобязательств.

10.2. Договор в письменной форме. Письменная форма считаетсявыполненной при наличии подписей уполномоченных лиц и оттисков печатей Сторон.

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

10.4. Настоящий Договор может быть изменен либо дополнен наосновании письменного соглашения Сторон.

10.5. Все Приложения, Дополнения и Соглашения к настоящему Договоруявляются неотъемлемой его частью и действительны при условии соблюденияписьменной формы и подписей сторон.

11. ПРИЛОЖЕНИЯ

11.1. Всеперечисленные ниже Приложения к настоящему Договору являются его неотъемлемойчастью и действительны при наличии подписей должностных лиц, наделенных правомподписи данных документов и оттисков печатей Сторон.

11.1.1. Приложение № 1- «Техническое задание»

11.1.2. Приложение № 2 - «Календарныйплан»

12. ЮРИДИЧЕСКИЕАДРЕСА И БАНКОВСКИЕ РЕКВИЗИТЫ СТОРОН

Заказчик:		Исполнитель:
«____» ___________ 20___ г.		«____»____________ 20___ г.

Приложение № 1

«ТЕХНИЧЕСКОЕ ЗАДАНИЕ»

Техническое заданиевключает в себя следующие пункты:

Приложение № 2

«КАЛЕНДАРНЫЙ ПЛАН »

№ этапа	Наименование этапа	Сроки выполнения работ	Стоимость Работ, руб.




Итого за работы:

* Примечание:Формы представления результатов работ, требования к их составу, содержанию иоформлению устанавливаются Руководителями проекта (п. 4.1 Договора) в рабочемпорядке.


ОТ ЗАКАЗЧИКА «____» ___________ 2011 г.		ОТ ИСПОЛНИТЕЛЯ «____»____________ 2011 г.

Работа со старыми DTS-пакетами MS SQL Server 2000 в MS SQL Server 2008

2011-07-26T00:15:00.008+04:00

Недавно мне пришлось столкнуться с необходимостью работы с набором DTS-пакетов, созданных много лет назад в MS SQL Server 2000 и импортированных в SQL Server 2008.

Отказаться от их использования было нельзя - приложение было написано очень давно и задачи перехода на SSIS не стояло.

SQL Server 2008 обеспечивает корректную работу старых DTS-пакетов, но вот Management Studio 2008 не открывает DTS-пакеты для просмотра и редактирования, выдавая следуюшую ошибку:

"SQL Server 2000 DTS Designer components are required to edit DTS packages. Install the special Web download, “SQL Server 2000 DTS Designer Components” to use this feature. "

Microsoft предлагает скачать и установить SQL Server 2000 DTS Designer Components - см. здесь - (для этого надо будет скопировать 6 файлов (SEMSFC.DLL, SQLGUI.DLL, SQLSVC.DLL, SEMSFC.RLL, SQLGUI.RLL, и SQLSVC.RLL) из установки SQL Server 2000 в каталог с SQL Server 2008).

Однако, это не решит проблему для случая SQL Server 2008 - после копирования файлов Server 2000 DTS Designer будет запускаться из Management Studio 2008, но корректно работать все равно не будет. Этот способ работает только для случая SQL Server 2005.

В SQL Server 2008 будет выдаваться следующая ошибка:

"Error Source : Microsoft Data Transformation Services (DTS) Package
Error Description : The DTS host failed to load or save the package properly."

В Microsoft пока не создали решения этой проблемы для SQL Server 2008, но есть один обходной вариант - пусть не очень удобный, но в случае необходимости он работает.

Следует поставить старый добрый SQL Server 2000 - причем не только сам Enterprise manager, а и ядро сервера - без инстанса работать с DTS-пакетами не получиться.
Причем, ставить нужно SQL Server 2000 SP3 или SP4. С SP2 работать не будет.

После этого необходимо сохранить DTS-пакеты из Management Studio 2008 на диск и открыть файлы на редактирование в Enterprise manager. Сам инстанс SQL 2000 при этом не понадобиться - Enterprise manager будет просто работать с файлами. Затем файлы необходимо опять импортировать в SQL Server 2008.

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

Хорошей новостью является то, что DTS-пакетами можно при этом управлять без каких-либо ограничений, так параметры подключений, которые в них указаны, в этом случае подключаются, как правило не к текущему серверу, а к SQL Server 2008, что облегчает работу с ними.

Какие вопросы задавать заказчику на первой встрече?

2011-07-20T17:06:00.000+04:00

Я руковожу в основном продуктовой разработкой.

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

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

Привожу этот список здесь - как заметку для себя на будущее, как способ поделиться опытом, а также с целью послушать критику и внести возможные изменения.

Итак, вопросы.

Общие вопросы.

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

Команда проекта.

Кто будет осуществлять руководство проектом со стороны заказчика?
Обладает ли он достаточными полномочиями для этого?
Кто ответственен за принятие ключевых решений со стороны заказчика?
Кто обладает достаточными знаниями для формирования требований к проекту?
Кто еще будет входить в состав проектной группы со стороны заказчика?

Влияние проекта.

Кто будет затронут результатами внедрения проекта?
Какие могут быть сложности или особые условия в процессе внедрения?
Предполагается ли какая-либо миграция или одновременная работы с некими старыми системами?
Предполагается ли обучение персонала как часть проекта?
Кто будет пользователями проекта?
При работе над проектом, либо при его внедрении - будут ли задействованы какие-либо сторонние организации либо ваши подразделения, не являющиеся непосредственными пользователями (например, поставщики либо получатели каких-либо данных)?

Риски

Какова квалификация пользователей проекта?
Будет ли обеспечен доступ в рабочую среду для проведения тестирования и раннего внедрения результатов проекта?
Существуют ли сотрудники, на стороне заказчика, не заинтересованные в реализации проекта?

Visual Paradigm for UML

2011-07-19T17:10:00.001+04:00

На днях мне довелось поработать с Visual Paradigm for UML 8.0.

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

Но, как мне показалось, что инструмент слегка перегружен. Тот же Enterprise Architect от Sparx мне показался более стройным и логичным что-ли.

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

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

Для меня эталоном удобства по работе с UML остается Rational XDE - очень удобный продукт времен Visual Studio 2003, который, к сожалению, не выпускается уже наверное лет 8. Очень жаль что IBM прекратила его поддержку - очень мощный и удобный был инструмент.

Небольшой образчик китайского кода

2011-07-15T15:47:00.001+04:00

Не смог удержаться, чтобы не запостить небольшой образчик китайского кода, который попался на глаза мне на днях.
Это не прикол – это реальный кусочек кода приложения.

            string s = Request.QueryString["action"];
            // s may have "restore" or "remove" values

            switch (s[2])
            {
                case 's':
                case 'S':
                    ..............
                    break;

                case 'm':
                case 'M':
                    ..............
                    break;

            }

Как говорится, это было бы смешно, если бы не было так грустно……

Летний Аналитический Фестиваль-2011 (ЛАФ-2011)

2011-06-26T16:04:00.001+04:00

Вчера я посетил наверное уже ставший традиционным Летний Аналитический Фестиваль-2011 (ЛАФ-2011), который как и в прошлом году проходил в Иваново и был посвящен системному анализу.

О ЛАФ-2010 я писал здесь и здесь.

Было приятно увидеть множество знакомых лиц с прошлого фестиваля.

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

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

Лично для себя я отметил следующие доклады:

1. Ирина Левенец "Управление ожиданиями в продуктовой разработке". На мой взгляд интереснейший доклад.

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

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

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

Соответственно, ценность сервиса для заказчика снижается.

Какие пути решения проблемы предлагает Ирина:
- Доносить ценность новых возможностей систем до заказчиков. Т.е. при обновлении систем им необходимо сообщать не о новых возможностях, которыми теперь обладает система, а о новых проблемах и задачах, которые она умеет решать. И расписывать в красках, как здорово она умеет это делать.

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

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

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

- Меньше обещать, больше делать. Т.е. если мы пообещаем заказчику сделать что-то например за неделю, и сделаем за неделю - это хорошо. А вот если мы пообещаем сделать за две недели, а сделаем за неделю - это будет просто отлично, заказчик будет счастлив.

- Если что-то не может быть сделано - так и сообщать заказчику. Не говорить, что может быть мы когда-то потом это сделаем.

- Вовлекать заказчиков в процесс сортировки требований. Это способствует повышению адекватности заказчиков.

2. Сергей Мартыненко "Варианты управления требованиями". Как и в прошлом году, у Сергей был очень интересный доклад.

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

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

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

- Хороший способ распределения требований по релизам:

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

3. Денис Казика. "Внедрение ITIL/ITSM" Тоже довольно интересный доклад.

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

Для решения проблем были предприняты следующие шаги:

- Была внедрена система управления инцидентами (нечто типа внутренней системы баг-трекинга.) Все запросы в IT-подразделение могли теперь поступать только через нее (до внедрения этой системы ситуация была примерно такая, как говорил Сергей Мартыненко - кто громче кричит или у кого больше зарплата, того требования и реализуются быстрее). Для того, чтобы отучить сотрудников от старых привычек работы с IT-отделом, двери отдела даже пришлось запирать на две недели, чтобы никто из других отделов не мог попасть внутрь не соблюдая регламент.

- Были внедрены внутренние регламенты работы IT-подразделения.

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

- Была введена должность бизнес-аналитика.

Весь процесс занял примерно 2.5 года.

После всех преобразований:
- IT-подразделение стало бизнес-образующим.

- Исчезли конфликты между IT-подразделением и другими подразделенями.

- Бизнес компании стал более эффективным.

4. Алексей Киселев "Могут ли быть выгодны ошибки аналитика или история одного тендера".

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

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

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

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

- Гос.заказчики не признают итеративную разработку. Только водопад.

Пожалуй, это были самые интересные для меня доклады.

К сожалению мне не удалось попасть на мастер класс Дмитрия Безуглова, но я надеюсь увидеть его как-нибудь позже.

Кроме того, не удалось побывать на интересном мастер-классе Ирины Векленко "Анализируй это: Жизнь как Проект", но я также надеюсь пообщаться с ней позже.

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

Я надеюсь, что в следующем году состоится ЛАФ-2012 и буду очень рад присутствовать на нем.

Хотелось бы поблагодарить всех организаторов и участников фестиваля за то, что они делают!

All you need is... ЛАФ!

Сложности распределенных команд и проектов

2011-06-22T16:38:00.000+04:00

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

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

Еще хочу обратить внимание, что данные проблемы не являются не решаемыми.

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

1. Часовые пояса.
Большая разница во времени (например, 12 часов) существенно замедляет процесс разработки.

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

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

Если же окажется так, что вопрос решен не целиком (а это выяснится только на следующий день, когда вы начнете работу), то вам опять придется ждать до вечера.

Можно, конечно, не задерживаться, а просто написать письмо, но это еще хуже.

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

2. Языковой барьер.
Де-факто инструментом общения сейчас является английский язык.

Писать и читать на нем все более или менее уже научились.

Намного сложнее слушать и быстро отвечать.

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

Еще хуже когда таких собеседников несколько одновременно и нужно успевать понимать, что все они говорят.

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

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

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

5. Демотивация.
Предыдущий пункт приводит к демотивации членов команд, так как они не чувствуют глубокой причастности к работе над проектом. Проект на становиться для них, что называется “своим”.

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

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

6. Сложности в соблюдении единого стиля разработки.
Это касается как стандартов кодирования, так и технических и архитектурных решений.

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

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

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

Поздравляю Андрея Маркеева!

2011-06-20T22:20:00.000+04:00

Хочу поздравить Андрея Маркеева с отличным выступлением на Sharepoint User Group!

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

Создание тестов для Selenium на C# для web-приложений на ASP.NET

2011-05-30T14:37:00.004+04:00

Как я и обещал ранее здесь, привожу пример разработки тестовых сценариев для автоматизированного тестирования web-приложений на C# с использованием библиотеки Selenium 2.0b3.

Для первой версии Selenium разработка скриптов на C# также возможна, но она довольно сильно отличается и обладает гораздо меньшими возможностями, так что я бы не рекомендовал ее использовать. При этом, такой продукт, как Selenium IDE, позволяет осуществлять генерацию C# кода только для первой версии Selenium, поэтому для нас он также получается не актуален.

Далее по шагам рассмотрим пример создания тестового сценария проверки логина на тестируемый сайт.

В Visual Studio.NET cоздаем новый проект – библиотеку классов на C#.
В данную библиотеку помещаем ссылки на библиотеки Selenium:
- Selenium.WebDriverBackedSelenium
- WebDriver.Common
- WebDriver.Remote
- WebDriver.Remote.Common
- WebDriver.Firefox
- WebDriver.IE
Все эти библиотеки доступны для загрузки с сайта http://seleniumhq.org/download – Скачать необходимо Selenium WebDriver версии 2.0b3 – речь в статье пойдет о ней.
Создаем класс TestFramework который будет предоставлять нам основные функции по выполнению скриптов.
```
   1:  public class TestFramework
```
```
   2:      {
```
```
   3:          static RemoteWebDriver _WebDriver;
```
```
   4:   
```
```
   5:          public static RemoteWebDriver WebDriver
```
```
   6:          {
```
```
   7:              get
```
```
   8:              {
```
```
   9:                  if (_WebDriver == null)
```
```
  10:                      _WebDriver = new FirefoxDriver();
```
```
  11:   
```
```
  12:                  return _WebDriver;
```
```
  13:              }
```
```
  14:          }
```
```
  15:   
```
```
  16:          public static void OpenURL (string URL)
```
```
  17:          {
```
```
  18:              WebDriver.Navigate().GoToUrl(URL);
```
```
  19:          }
```
```
  20:   
```
```
  21:          public static IWebElement FindWebElement(WebItem webItem)
```
```
  22:          {
```
```
  23:              if (webItem.ID != "")
```
```
  24:                  return WebDriver.FindElementById(webItem.ID);
```
```
  25:   
```
```
  26:              if (webItem.ClassName != "")
```
```
  27:                  return WebDriver.FindElementByClassName(webItem.ID);
```
```
  28:   
```
```
  29:              if (webItem.XPathQuery != "")
```
```
  30:                  return WebDriver.FindElementByXPath(webItem.ID);
```
```
  31:   
```
```
  32:              return null;
```
```
  33:          }
```
```
  34:   
```
```
  35:          public static void Delay(int Seconds = 10)
```
```
  36:          {
```
```
  37:              System.Threading.Thread.Sleep(Seconds * 1000);
```
```
  38:          }
```
```
  39:      }
```
Основу для выполнения тестов представляет собой экземпляр класса RemoteWebDriver, который предоставляет доступ ко все основным функциям Selenium.

При этом, экземпляр класса RemoteWebDriver содержит ссылку на объект драйвера, реализующего работу с конкретным браузером – IE, FireFox, Chrome.

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

Метод OpenURL,как видно из названия предназначен для открытия различного рода ссылок.

Метод FindWebElement реализует поиск элементов на текущей странице браузера. При этом на вход ему подается экземпляр класса WebItem, который будет описан позднее. Пока лишь отмечу, что этот класс предоставляет возможность работы с элементами на странице.

Данный метод возвращает экземпляр интерфейса IWebElement, который реализуется всеми страничными элементами Selenium.

Метод использует возможности поиска объектов на странице по их ID, имени css-класса или запросу XPath. Вообще говоря, Selenium предоставляет больше возможностей поиска, но в данном примере я оставил только эти три, как наиболее часто применяемые.

Последний метод Delay предназначен для приостановки тестов до момент окончания загрузки страниц.

Создаем класс WebItem, который я упоминал выше.

   1:  public class WebItem

   2:      {

   3:          public string ID;

   4:          public string ClassName;

   5:          public string XPathQuery;

6:

   7:          public WebItem(string ID, string ClassName, string XPathQuery)

   8:          {

   9:              this.ID = ID;

  10:              this.ClassName = ClassName;

  11:              this.XPathQuery = XPathQuery;

  12:          }

13:

  14:          public void Click()

  15:          {

  16:              TestFramework.FindWebElement(this).Click();

  17:          }

18:

  19:          public void SetValue(string Value)

  20:          {

  21:              TestFramework.FindWebElement(this).SendKeys(Value);

  22:          }

  23:      }

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

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

Создаем класс LoginWebItems, который будет содержать набор элементов для работы с формой логина.

   1:  public static class LoginWebItems

   2:      {

   3:          public static WebItem LoginLink

   4:          {

   5:              get

   6:              {

   7:                  return new WebItem("ctl00_Header1_TopHeader1_ExitLinkButton", "", "");

   8:              }

   9:          }

10:

  11:          public static WebItem UserNameTextBox

  12:          {

  13:              get

  14:              {

  15:                  return new WebItem("ctl00_ContentPlaceHolder1_EMailTextBox", "", "");

  16:              }

  17:          }

18:

  19:          public static WebItem PasswordTextBox

  20:          {

  21:              get

  22:              {

  23:                  return new WebItem("ctl00_ContentPlaceHolder1_PasswordTextBox", "", "");

  24:              }

  25:          }

26:

  27:          public static WebItem LoginButton

  28:          {

  29:              get

  30:              {

  31:                  return new WebItem("ctl00_ContentPlaceHolder1_LoginButton", "", "");

  32:              }

  33:          }

  34:      }

Как видим, класс содержит ссылки на следующие элементы – ссылку на страницу логина, текстовые поля для имени пользователя и пароля, а также непосредственно кнопку логина.

Создадим класс PagesActions, который будет выполнять действия по открытию различных страниц нашего сайта. Он нужен нам для того, чтобы исключить жесткое упоминание ссылок в коде тестовых сценариев.
```
   1:  public class PagesActions
```
```
   2:      {
```
```
   3:          public static void OpenHomePage()
```
```
   4:          {
```
```
   5:              TestFramework.OpenURL("http://www.test.com/");
```
```
   6:          }
```
```
   7:      }
```
Теперь создадим класс LoginAction, который будет нам реализовывать действия входа на сайт.

Впоследствии это действие может быть использовано во многих тест-кейсах.
```
   1:  public class LoginAction
```
```
   2:      {
```
```
   3:          public static void DoLogin()
```
```
   4:          {
```
```
   5:              LoginWebItems.LoginLink.Click();
```
```
   6:   
```
```
   7:              LoginWebItems.UserNameTextBox.SetValue("test login");
```
```
   8:              LoginWebItems.PasswordTextBox.SetValue("test password");
```
```
   9:   
```
```
  10:              LoginWebItems.LoginButton.Click();
```
```
  11:   
```
```
  12:              TestFramework.Delay();
```
```
  13:          }
```
```
  14:      }
```
Как видим, наше действие описано простым языком, в понятных терминах и не содержит кода, зависимого от библиотеки, реализующей выполнение скриптов, т.е. от Selenium.

Ну и наконец мы создаем класс тест-кейса LoginTestCase, который реализует непосредственно тестирование входа на сайт

   1:  public class LoginTestCase

   2:      {

   3:          public static void DoTestCase()

   4:          {

   5:              PagesActions.OpenHomePage();

6:

   7:              LoginAction.DoLogin();

   8:          }

   9:      }

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

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

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

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

Мы можем также организовать автоматическое создание багов в TFS – о том, как это сделать я писал в посте “Как создать work item в TFS (Team Foundation Server) из письма в Outlook”

P.S.
Другие мои посты на тему Selenium:
1. От QTP к Selenium
2. Создание тестов для Selenium на C# для web-приложений на ASP.NET

От QTP к Selenium

2011-05-23T10:57:00.001+04:00

Последние несколько лет мы использовали Mercury Quick Test Pro (QTP) для выполнения скриптов автоматизированного тестирования наших web-приложений.

В настоящий момент мы осуществляем переход к Selenium. Именно Selenium будет использоваться для выполнения скриптов регрессионного контроля.

Для нас Selenium имеет целый ряд преимуществ по сравнению с QTP:

1. Selenium бесплатный. QTP стоит очень дорого.

2. Selenium позволяет разрабатывать скрипты на том же языке программирования, на котором ведется основная разработка – C#, Java и пр. Это избавляет от необходимости изучать еще один язык программирования для разработки тестовых сценариев. Благодаря этому, разработчики могут при случае легко вносить изменения в тестовые сценарии, а тестировщики избавлены от необходимости переучиваться, при переходе в разработчики.

3. Так как разработка тестовых скриптов ведется в той же среде, что и основная разработка, скрипты Selenium могут использовать библиотеки тестируемого приложения в своих тестах – например, библиотеки бизнес-логики и пр.

4. Тестовые скрипты Selenium можно включать в наборы unit-тестов тестируемого приложения.

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

Есть, конечно, и некоторые сложности во внедрении Selenium (куда же без них?):

1. Очень бедная документация.

2. Более высокие требования к опыту тестировщиков в плане умений программировать.

3. Полное отсутствие инструментария разработки.

4. Отсутствие возможности тестировать Windows-приложения.

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

P.S.
Другие мои посты на тему Selenium:
1. От QTP к Selenium
2. Создание тестов для Selenium на C# для web-приложений на ASP.NET

Заметка о мотивации

2011-05-10T17:10:00.001+04:00

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

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

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

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

И сегодня один мой коллега, имени которого я не называю, рассказал мне о той системе мотивации, которая принята в их ИТ-подразделении.

Суть системы такова: зарплата программистов складывается из двух часть: оклад + премия (50% от оклада).

Для каждой задачи ставится срок ее сдачи. Если программист не сдает задачу во время, то от премии всего ИТ-отдела, во главе с начальником, вычитается 1% за каждый день просрочки.

Если после сдачи задачи в ней будут найдены баги, то аналогично: минус 1% за каждый баг со всего ИТ-отдела.

Как говорит коллега, такого, чтобы отдел получил 100% премии, не было еще ни разу.

Интересная система мотивации, не находите?

Водопад жив…

2011-04-18T10:40:00.001+04:00

Недавно я с удивлением узнал, что не смотря на накопленный за последние десятилетия опыт в разработки программного обеспечения и большое количество написанной литературы, водопад (Waterfall) по-прежнему применяется, и причем даже в интернет-проектах.

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

Где разместить тестовое окружение?

2011-04-11T12:46:00.000+04:00

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

Изначально, тестовое окружение у нас располагалось рядом с рабочим – т.е. удаленно у нашего ISP.

Схематично это выглядело так:

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

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

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

Происходило это по нескольким причинам:
1. Тратилось очень длительное на время на сравнение схем всех баз данных – около двух часов.
Происходило это потому, что схемы были довольно большие и баз было несколько. Поэтому, приходилось скачивать локально большое количество DDL-скриптов.
2. Очень медленно работало регрессионное тестирование веб-интерфейса. Из-за низкой скорости доступа через интернет на выполнение всех автоматизированных скриптов, которые выполнят все варианты тестирования требовалось около 2-х суток. Конечно, варианты тестирования можно запускать параллельно, но это не решает проблему кардинально.

Было решено перенести тестовое окружение локально, т.е. получить в итоге следующую схему работы:

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

При таком подходе, правда, тоже есть подводные камни: в частности не так явно видны проблемы передачи больших объемов данных через интернет – “тяжелый” HTML или большие данные веб-форм и т.п.

Индийский код

2011-03-11T17:13:00.000+03:00

Некоторое время назад мне пришлось столкнуться с достаточно большим объемом кода, написанного индийскими товарищами.

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

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

А теперь конкретные замечания по коду:
1. Очень большой объем дублирования кода. Видно, что Copy-Paste используется очень активно.
Идентичные куски кода повторяются и не выделяются в отдельные функции.

2. Очень длинные многостраничные методы. Отсутствует разбиение на мелкие методы.

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

4. Размытие слоев приложения – например, SQL-код генерируется во всех слоях приложения, вплоть до JavaScript’а, исполняемого в браузере.

5. Активное использование именований переменных, при котором первым символом обозначается тип переменной. Например, int iID или string sName. На мой взгляд очень неудобно.

6. Слабое понятие о нормализации баз данных. Большое количество дублирования данных в БД.

7. Именование всех полей в базах данных в верхнем регистре. Например, AUTHOR_NAME.

Изменение количества строк кода с течением времени

2011-02-24T14:17:00.001+03:00

Некоторое время назад решено было посмотреть график изменения общего количества строк кода в проекте с течением времени.

При этом был получен следующий график:

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

Шаблоны некоторых документов для разработки проектов

2011-02-02T17:32:00.001+03:00

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

Все эти шаблоны я либо использовал раньше в своей работе, либо использую сейчас.
Эти шаблоны документов были сформированы с использованием шаблонов RUP (Rational Unified Process), а также при анализе различного рода интернет-источников и литературы.

Наиболее интересные из этих шаблонов я решил поместить в открытый доступ.

Шаблоны доступны по следующей ссылке http://www.msmirnov.ru/public/pm_doc_templates.zip:

Данный набор содержит следующие шаблоны документов:

Документ проекта
План осуществимости
Концепция
Общее описание архитектуры
Общий план тестирования
Список основных рисков
План проекта
Документ описания архитектуры
План итерации

P.S. Описание структуры самого производственного процесса (это тоже своего рода шаблон производственного процесса) приведен в посте "Схема и шаблон производственного процесса"

Стандарты и правила оформления кода C# и T-SQL

2011-01-13T10:17:00.001+03:00

Последнее время меня несколько раз спрашивали относительно стандартов и правил оформления кода на C# и T-SQL , поэтому я решил выложить их в открытый доступ.

Стандарты и правила доступны по следующим ссылкам на моем сайте:

Стандарт оформления кода C#: http://www.msmirnov.ru/public/CSharp_Coding_Standards.doc
Стандарт оформления кода T-SQL: http://www.msmirnov.ru/public/TSQL_Coding_Standards.doc

Стандарты и правила оформления кода C#

2011-01-12T15:51:00.005+03:00

Последнее время меня несколько раз спрашивали относительно стандартов и правил оформления кода C#, поэтому я решил выложить их в открытый доступ.

Для загрузки Стандарты и правила доступны по следующей ссылке на моем сайте: http://www.msmirnov.ru/public/TSQL_Coding_Standards.doc

Либо с ними можно ознакомиться прямо здесь.

Стандарт оформления кода C#

Цель документа

Документ является соглашением по оформлению и написанию кода на языке C#. В документе приведены основные правила оформления кода и приемы, используемые при написании программ.

Цели документа:

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

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

Стили именования

Pascal case – первая буква каждого слова в имени идентификатора начинается с верхнего регистра.

Пример: TheCategory;

Camel case – первая буква первого слова в идентификаторе в нижнем регистре, все первые буквы последующих слов – в верхнем.

Пример: theCategory;

UpperCase – стиль используется только для сокращений, все буквы в имени идентификатора в верхнем регистре.

Пример: ID;

Hungarian notation – перед именем идентификатора пишется его тип в сокращенной форме.

Пример: strFirstName, iCurrentYear.

Правила именования идентификаторов

Общие правила именования идентификаторов

При именовании идентификаторов не используются аббревиатуры или сокращения, если только они не являются общепринятыми.

Пример: GetWindow(), а не GetWin();

Если имя идентификатора включает в себя сокращение – сокращение пишется в upper case. Исключение - когда имя идентификатора должно быть указано в camel case и сокращение стоит в начале имени идентификатора. В этом случае сокращение пишется в нижнем регистре.

Пример:
PPCAccount (PPC – сокращение от pay per click) для pascal case,
ppcAccount для camel case.

Использование верхнего и нижнего регистра в именах

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

Пример:
               KeywordManager и Keywordmanager;
               KeywordManager.Keyword и KeywordManager.KEYWORD;
               int id {get, set} и int ID {get, set};

findByID(int id) и FindByID(int id);
void MyFunction(string s, string S).

Правила именования классов

Следует избегать имен классов, совпадающих с именами классов .NET Framework;

Для классов используется стиль именования pascal case;

Для классов, унаследованных от CollectionBase используется суффикс Collection, перед которым указывается тип объектов, для которых используется коллекция.

Пример: UserCollection, CompanyCollection;

В качестве имен классов используются имена существительные;

Имя класса не должно совпадать с именем namespace’а.

Пример: namespace Debugging, класс Debug;

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

Пример: таблица Users, класс User;

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

Пример:
базовый класс Figure,
потомок FigureCircle;

Имена файлов, в которых находятся классы, совпадают с именами классов. Для именования файлов используется стиль pascal case.

Правила именования интерфейсов

Имена интерфейсов начинаются с буквы I, после которой следует название интерфейса в pascal case.

Пример: IDisposable.

Правила именования generic’ов

Generic’и обозначаются буквой T, если generic’ов несколько их имена начинаются с буквы T.

Пример: GetItems<T>(int parentID)

Правила именования функций

Для именования функций используется стиль pascal case;

Функции объявляются согласно следующему шаблону:

<Модификатор доступа> [Другие модификаторы] <Тип> <Название функции>();

Пример: protected abstract void HelloWorld();

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

Большие функции, не умещающиеся на одном экране, делятся на несколько private функций меньшего размера, имена таких вспомогательных функций состоят из имени основной (большой) функции и существительного, глагола или фразы, которые уточняют действие вспомогательной функций, разделенные подчеркиванием. Основная и вспомогательная функции объединяются в регионы. Вспомогательные функции вызываются только из основной функции.

Пример:
основная функция – CheckProduct,
вспомогательные функции – CheckProduct_Price,
CheckProduct_Url,
CheckProduct_SearchTerm.

Правила именования параметров функций

Для именования параметров используется стиль camel case;

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

Пример:
public void EncodeString(string sourceString, ref string encodedString),
а не public void EncodeString(string string1, ref string string2).

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

Пример:
UserFactory.Create(Company company);
CheckUsers(UserCollection users);

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

Пример:

public void CreateUser(string firstName, string lastName)
{
this.firstName = firstName;
this.lastName = lastName;
}

В именах параметров не используется венгерская нотация.

Правила именования свойств

Для именования свойств используется стиль pascal case;

Свойства объявляются согласно следующему шаблону:

<Модификатор доступа> [Другие модификаторы] <Тип> <Название свойства>;

Пример: public static User CurrentUser { get; }

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

Пример:
public User User { get; set; }
public UserCollection Users { get; set; }

Название свойства типа bool должно представлять из себя вопрос, требующий ответа да или нет.

Примеры названий: “CanDownload”, “HasKeywords”, “IsChecked”, “NeedsUpdate”.

Правила именования полей

Для именования полей, доступных вне класса, используется стиль pascal case, для private полей - camel case;

Поля объявляются согласно следующему шаблону:

<Модификатор доступа> [Другие модификаторы] <Тип> <Название поля>;

Пример: private static User currentUser = null;

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

Пример:
public User User = new User();
public UserCollection Users = new UserCollection();

Название поля типа bool должно представлять из себя вопрос, требующий ответа да или нет.

Примеры названий: “CanDownload”, “HasKeywords”, “IsChecked”, “NeedsUpdate”.

Правила именования переменных

Для именования переменных используется стиль camel case;

Переменные объявляются согласно следующему шаблону:

<Тип> <Название поля>;

Пример: int userID = null;

В циклах foreach имя переменной назначается как имя массива в единственном числе.

Пример: foreach(Campaign newCampaign in NewCampaigns).

Правила именования констант

Для именования констант используется стиль pascal case.

Правила именования enum’ов

Для именования enum’ов и их значений используется стиль pascal case;
Имена enum’ов указываются в единственном числе
Имена, как правило, состоят из имени сущности, к которой относится enum и названия содержимого enum’а (status, type, state).

Пример: KeywordStatus, ConnectionState, TaskType.

Правила именования exception’ов

Для exception’ов используется стиль pascal case;
Имена классов для создаваемых custom exception’ов заканчиваются суффиком Exception;
В качестве имени объекта исключения внтури catch, для исключений типа Exception, используется имя “ex”.

Пример: catch(Exception ex).

Правила именования control’ов в asp.net

Для именования control’ов используется венгерская нотация (стиль Hungarian notation). См. Приложение 1: Префиксы, используемые для именования контролов в asp.net.

Форматирование кода

Используются стандартные настройки форматирования Visual Studio;
В одном файле не объявляется больше одного namespace’а и одного класса (исключение – небольшие вспомогательные private классы);
Фигурные скобки размещаются всегда на отдельной строке;
В условии if-else всегда используются фигурные скобки;
Размер tab’а – 4;
Использование строк длиннее 100 символов не желательно. При необходимости инструкция переносится на другую строку. При переносе части кода на другую строку вторая и последующая строки сдвигаются вправо на один символ табуляции;
Каждая переменная объявляется на отдельной строке;
Все подключения namespace’ов (using) размещаются в начале файла, системные namespace’ы объявляются над custom namespace’ами;
Если для свойства существует соответствующее поле (например, при загрузке по требованию), то поле объявляется над свойством.

Пример:
private User user;
public User User { get; set; }

Если set или get свойства состоит из одной операции – весь set или get размещается на одной строке.

Пример:
   Public User
   {
                     get { return user; }
       }

Функции, поля и свойства группируются внутри класса по своему назначению. Такие группы объединяются в регионы;

Комментирование кода

Все комментарии должны быть на русском языке;
Для функций, классов, enum’ов, свойств и полей комментарии необходимо указывать в таком виде, чтобы по ним можно было автоматически сгенерировать документацию. Для этого используются стандартные tag’и такие как <summary>, <param> и <return>.
Для функций создающих exception’ы – возможные исключения необходимо указывать в tag’ах <exception>;
Для включения в документацию примеров использования необходимо применять tag’и <example>, <remarks> и <code>
Для ссылок в документации необходимо использовать tag’и <see cref=””/> и <seeAlso cref=””/>.
При использовании в тексте комментариев символов, использующихся в xml как спецсимволы, необходимо использовать tag CDATA.
Комментарии к заголовкам функций, свойств, полей, интерфейсов и прочего необходимо указывать всегда;

Для функций, выполняющих сложные алгоритмы, не очевидные для восприятия, необходимо указывать подробные комментарии не только к заголовку функции, но и самому алгоритму с пояснением каждого шага выполнения алгоритма;
В случае внесения изменений в критические участки кода, ядро системы, либо когда сложно проследить последствия, которые может повлечь такое изменение, необходимо указывать подробный комментарий о том кто внес изменение, когда и по какой причине;
В том случае если необходимо временно добавить заплатку, без которой система не может работать, но заплатку в дальнейшем планируется убрать – необходимо добавлять ключевое слово “//TODO: ”, после которого указывается когда и что должно быть исправлено. Кроме этого необходимо указывать подробный комментарий о том, для чего предназначено временное исправление, кто его внес и когда;
При разработке кода, изменения которого могут повлечь за собой сбой в других частях системы, при этом связь между этими двумя частями программы неочевидна и ошибка не будет показана на этапе компиляции, либо если сам код неочевидным образом зависит от других частей системы – необходимо указывать подробное описания взаимосвязей.

Конфигурация

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

Пример:

<add key="MainDatabaseConnectionString" value="server=...;Integrated Security=SSPI;"/>
<add key=" SupportDatabaseConnectionString" value="server=...;Integrated Security=SSPI;"/>

Для ключей, хранящих boolean значения, value может быть равно только true или false, а не 0/1 или yes/no.

Переменные и типы

Свойства необходимо использовать только тогда, когда это имеет смысл. Если при получении и сохранении значений никакая дополнительная логика не участвует – вместо свойства необходимо использовать поле (исключение – когда класс bind’ится на asp.net страницах, т.к. стандартный механизм bind’а имеет доступ только к public свойствам);
Необходимо использовать максимально простые типы данных. Так, например, необходимо использовать int, а не long, если известно, что для хранимых значений будет достаточно типа int;
Константы необходимо использовать только для простых типов данных;
Для сложных типов вместо констант необходимо использовать readonly поля;
Boxing и unboxing value типов необходимо использовать только когда это действительно необходимо;
При задании значений нецелых типов, значения должны содержать как минимум одну цифру до точки и одну после;
Необходимо использовать именования типов C#, а не .NET common type system (CTS).

Пример: int userID = -1; , а не Int32 userID=-1;

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

Пример: private User CreateUser(string firstName, string lastName);

Модификаторы доступа (private, protected, internal и public) необходимо указывать в зависимости от того, где требуется доступность соответствующего поля, свойства, функции, класса или конструктора. Модификатор public необходимо указывать только тогда, когда необходим доступ к полю из других проектов, internal – когда необходим доступ из других классов внутри одного проекта, protected – для предоставления доступа классам – потомкам, во всех остальных случаях используется private, т.е. доступ ограничивается самим классом;

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

Пример: private int userID = -1;
private string firstName = “”;
private string lastName = “”;

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

Пример:
   private User()
   { }
   public User(int userID)
   { }

Вместо использования “magic numbers” для идентификаторов статусов, состояний и т.п. необходимо указывать константы или enum’ы. Идентификаторы состояний в виде чисел использовать нельзя.

Пример не правильного использования: public GetUserByStatus(int statusID);
Пример правильного использования: public GetUserByStatus(UserStatus userStatus);

Тип object необходимо использовать только когда это действительно необходимо, в большинстве случаев вместо него используются generic’и. Вместо Hashtable необходимо использовать Dictionary<>, вместо ArrayList используется List<>;
В том случае если в get’е или set’е какого-либо свойства выполняются сложные вычисления, если операция, выполняемая в get или set является преобразованием, имеет побочный эффект или долго выполняется – свойство должно быть заменено функциями;
Свойство не должно менять своего значения от вызова к вызову, если состояние объекта не изменяется. Если результат при новом вызове может быть другим при том же состоянии объекта, вместо свойства необходимо использовать функции;
Внутри get’а и set’а не должно быть обращений к коду, не связанному напрямую с получением или сохранением значения свойства, т.к. такие действия могут быть не очевидны для клиентов, использующих свойство;
Все настройки, влияющие на работу приложения, нельзя указывать жестко в коде, а необходимо выносить в config. Если есть возможность прописать значение по умолчанию – они должны быть прописаны, если значение по умолчанию не может быть задано и соответствующий ключ не прописан в конфиге – необходимо создавать исключение.

Функции

Функции, возвращающие массив, всегда должны возвращать массив. Если нет данных – функции возвращают пустой массив, но не null. Это же касается коллекций;

В функциях никогда нельзя использовать больше 7-ми параметров. Если параметров больше – они объединяются в класс.

Управление выполнением программы

При использовании foreach по коллекции объектов – сама коллекция никогда нельзя модифицировать (новые элементы не добавляются, существующие не удаляются);
Если задачу можно решить, используя рекурсию и используя циклы, предпочтение необходимо отдавать использованию циклов. Рекурсия необходимо применять только тогда, когда решение с использованием циклов сложнее, чем при использовании рекурсии;
Тернарные операции необходимо использовать только для простых проверок. В тех случаях, когда проверка сложная и включает в себя несколько условий – используются if/else;
В aspx файлах нельзя использовать код. Т.е. tag’и <%= “C# code” %> использовать нельзя. Это связано с тем, что при компиляции такой код не проверяется;
Сложные проверки, состоящие из множества условий, необходимо разбивать на несколько простых. Для сохранения промежуточных результатов необходимо использовать boolean переменные;
Классы, реализующие интерфейс IDisposable, создаются в директиве using.

Пример: using(SqlConnection sqlConnection = new SqlConnection) { }.

События, делегаты, потоки

Перед вызовом делегатов и событий всегда необходимо выполнять проверку на null;
При создании простых event’ов необходимо использовать стандартные классы EventHandler и EventArgs;
При создании сложных event’ов для передачи аргументов необходимо использовать классы потомки EventArgs;
Для блокировок при написании многопоточных приложений необходимо использовать оператор lock, а не класс Monitor.

Exception’ы и их обработка

Блоки try-catch нельзя использовать для управления ходом работы программы, а только для обработки непредвиденных ошибок;
При прокидывании исключений выше по StackTrace’у, необходимо использовать оператор “throw;”, а НЕ “throw ex;”;
Custom exception’ы необходимо наследовать от класса Exception (а не ApplicationException или какого-то другого);
Исключения необходимо создавать всякий раз, когда функция не может быть выполнена – переданы неверные параметры при вызове функции, нет доступа к базе данных, не известные идентификаторы и т.п.;
Все исключения должны быть записаны в log или показаны пользователю системы. Пустые секции catch использовать нельзя;
При записи информации об ошибке, как правило, пишется StackTrace.

Приложение 1: Префиксы, используемые для именования контролов в asp.net.

Button – btn,
CheckBox – cb,
DropDownList – ddl,
HiddenField – hf,
HyperLink – hl,
Image – img,
ImageButton – ibtn
Label – l,
LinkButton – lbtn
ListBox – lb,
Literal – lt,
Panel – pnl
PlaceHolder – ph,
RadioButton – rb,
TextBox – tb,
Table – tbl,
Validator – val,
ValidationSummary – vals,

AdRotator – ar,
BulletList – bl,
Calendar – cld,
CheckBoxList – cbl,
FileUpload – fup,
ImageMap – im,
Localize – loc,
MultiView – mv,
RadioButtonList – rbl,
Substitution – sbs
View – v,
Wizard – wiz,
Xml – xml.

Приложение 2: Сводная таблица правил именования

Идентификатор	Регистр	Пример
Класс	Pascal	User
Локальная переменная	Camel	user
Интерфейс	Pascal	IDisposable
Generic	Pascal	T, TKey, TValue
Public функция	Pascal	Authenticate
Private функция	Pascal	Authenticate
Параметр функции	Camel	userID
Public свойство	Pascal	FirstName
Private свойство	Pascal	FirstName
Public поле	Pascal	FirstName
Private поле	Camel	firstName
Enum	Pascal	UserStatus
Значение enum’а	Pascal	Active
Exception	Pascal	UserAuthenticationException
Event	Pascal	StatusChanged
Namespace	Pascal	UserManager