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

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

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

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

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

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


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

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

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

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

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

Водопад жив…

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

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

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

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

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

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


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

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

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

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


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


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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Документ проекта
2. План осуществимости
3. Концепция
4. Общее описание архитектуры
5. Общий план тестирования
6. Список основных рисков
7. План проекта
8. Документ описания архитектуры
9. План итерации

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

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

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

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

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