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

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

А всего лишь разработчиков изолировали от руководства...

@темы: управление проектами

---

softwarepeople.ru/blog/2010/11/02/facebook_big_...

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

@темы: общие вопросы разработки ПО

---

www.globoscope.ru/content/articles/2939/

На первый взгляд эта статья, описывающая влияние психологии человека на его поступки и связанные с этим трудности общепринятых экономических моделей, вовсе не в кассу в блоге, посвящённом разработке ПО. Но, во-первых, мы договорились, что рассматриваем здесь не только технические вопросы. А во-вторых, замените экономическую модель на use-case, и вы поймёте, почему, например, некоторые программные продукты так неудобны в использовании, но при этом бешенно популярны.

@темы: общие вопросы разработки ПО

---

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

www.codenet.ru/progr/other/reengineering.php

Эта статья, надеюсь, заставит вас подумать на несколько важных тем:

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

*****

Всё-таки скажу пару слов от себя.

Реинжениринг, скажем честно, - вещь затратная. И дело не только в том, что программистам приходится разбираться в чужом коде. Хуже то, что далеко не каждый программист способен разобраться в чужих технологиях. Если программа была изначально написана на Java, то при её реинжениринге программисту недостаточно знать только Java. Чаще всего, ему даже недостаточно владеть основными технологиями, используемыми при программировании на Java. В большинстве специализированных пакетов используются специализированные компоненты и пакеты. А при реинжиниринге часто приходится иметь дело с устаревшими пакетами, которым нужно искать замену. И от программиста, проводящего реинжениринг, требуется не только понять структуру и роль каждого компонента, но и правильно подобрать (и, зачастую, заново написать) ему замену.

Добавьте к этому тот факт, что исходная система могла быть написана на устаревшем языке, и программисту придётся при реинжиниринге фактически "перетаскивать" проект на другой язык программирования. А для этого программист должен знать не только оба языка, но и скрытые в них абстракции и "подводные камни" (я об этом уже говорил; кажется, это было где-то здесь: www.diary.ru/~kmi-soft/p119058923.htm).

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

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

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

---

Замечательный анализ, проведённый Еленой Тяпкиной. Сравнительный анализ основных лицензий Open Source: GPL, LGPL, BSD, MIT, Mozilla public license, Apache software license:

www.libertarium.ru/18586

@темы: общие вопросы разработки ПО

---

Сторонники открытого программного обеспечения говорят о том, что open source позволяет избавиться от привязки к вендору, перестать быть заложником технологических решений определенного поставщика. Это преимущество, однако, становится не столь очевидным, когда речь заходит о «программном обеспечении как услуге» (Software as a Service, SaaS) и услугах на базе облачных платформ. Открытые API, а не open source предоставят свободу действий в облаках...

http://cloudzone.ru/articles/analytics/17.html - Почему Open Source не гарантирует свободу выбора поставщика

@темы: общие вопросы разработки ПО

---

Ошибки в ПО приводят, иногда, к очень серьёзным последствиям. История с Therac-25 наводит на определённые размышления. Тут ошибки выбора языка программирования, излишняя дружественность пользовательского интерфейса, ошибки при синхронизации потоков, неправильное понимание реализации типов данных и другие ошибки программного обеспечения привели к смерти нескольких человек. Рекомендую для внимательного анализа:

ru.wikipedia.org/wiki/Therac-25

@темы: программирование, отладка и тестирование, общие вопросы разработки ПО

---

Вот интересную картину наблюдаю. На рынке труда программистов чётко обозначилось два наиболее востребованных направления: Java и C#. При этом C++ традиционнокаменнопостоянен, а Delphi продолжает решительно терять популярность. Ещё вижу PHP, Python и что-то ещё подобное, создающее фон для общей картины.

Интерес, однако, представляет не столько востребованность программистов, сколько чётко обозначившаяся тенденция раскола IT-области на два направления.

C# явно захватывает сегмент приложений для настольных компьютеров, хотя и пропагандируется как основное средство разработки .NET, которая должна была стать некоторым средством организации распределённых информационных систем. Объясняется всё просто: подавляющая часть компьютеров работает под управлением Windows, API которой с некоторого времени успешно было похоронено под завалами абстракций .NET, так что теперь почти никто не может до него добраться, и остаётся лишь использовать абстракции .NET посредством C#.

Java, напротив, ориентирована именно на web-сегмент. Её основное превосходство - кроссплатформенность, до которой .NET-у ещё ползти и ползти. А без поддержки многих платформ реализовывать сетевое приложение нынче как-то не с руки.

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

Следствием такого раскола стала вторая тенденция. Если раньше было много программистов, успешно совмещавших в себе навыки разработки ПО и для десктопов, и для веба, то теперь программисту приходится выбирать, какими проектами заниматься. Либо, либо. И никакой золотой середины. Windows API теперь недоступно. И недоступным его сделала не столько политика Microsoft, сколько нежелание современного IT-бизнеса вкладывать значительные средства в что-либо более глубокое, чем Java и C#. Только вот к чему это приведёт в конечном итоге?

Посмотрим, как будут развиваться события дальше...

@темы: программирование

---

Меняю работу.

Неделю назад специально засел за комп ночью с воскресения на понедельник и опубликовал своё резюме. Уже в 9:30 утра понедельника получил первое приглашение на собеседование. И всю неделю работодатели обрывали мне почту и телефон.

В это воскресение я решил поспать. Итог - ни одного сообщения, ни одного звонка.

Почему?

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

А выводы простые.

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

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

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

Ну, о пятнице и говорить нечего. Конец недели, сокращённый рабочий день и т.д. и т.п.

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

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

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

Вот и получается, что ночь на понедельник имеет решающее значение.

@темы: персонал

---

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

Начну с формальностей: давайте определим роли программиста и тестера в проекте. Согласно Википедии:

Программист - специалист, занимающийся написанием программ для ЭВМ, то есть программированием.

Тестировщик (тестер) - специалист, занимающийся тестированием программного обеспечения (ПО).

Таким образом, имеем первое формальное различие: программист пишет программы, а тестер их тестирует. В принципе, из определений вытекает, что программист может считаться одновременно тестером собственной программы (ведь, не проверяя её, он не может сказать, что она написана). А вот тестер программистом быть ну никак не может. Он не пишет программы, он их только проверяет.

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

И всё же, разница между этими ролями велика.

Роль программиста заключается в том, чтобы написать программу так, чтобы она РАБОТАЛА. Чем шире программное и аппаратное окружение и чем больше ситуаций, в которых программа сохраняет работоспособность, тем качественнее работа программиста, и тем более он востребован как специалист.

Роль тестера заключается в несколько обратной задаче: ему нужно сделать так, чтобы предложенная ему программа ПЕРЕСТАЛА РАБОТАТЬ. Чем больше количество найденных ситуаций, при которых программа работает неправильно, тем качественнее работа тестера, и тем востребованнее он как специалист.

Разница, как говорится, налицо.

***

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

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

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

@темы: программирование, персонал, отладка и тестирование, общие вопросы разработки ПО

---

http://www.slideshare.net/gaidar/c-pitfalls

В презентации, подготовленной Гейдаром Магдануровым, рассматриваются аспекты поведения C#-программ, приводящие, на первый взгляд, к неожиданным последствиям. Однако стоит лишь копнуть глубже и опуститься ниже уровня абстракций языка, как всё раскладывается по полочкам...

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

@темы: программирование

---

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


Уменьшенная модель устройства - это увеличенная модель его недостатков.

Золотое правило ремонтников: замени неисправную деталь, остальное само заработает.

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

Если можешь не писать, то не пиши...

Чтобы приготовить рагу из кролика, надо сначала поймать кролика. Значит, будем ловить кролика!

...Проблема межзвездных путешествий - проблема побуждений, движущих разумом, а вовсе не физическая проблема; если межзвездные путешествия нужны - разум ее решает. (Василий Головачёв)

@темы: общие вопросы разработки ПО

---

Чему сегодня учат студентов, которые хотят связать свою жизнь с разработкой ПО?

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

На самом деле, чему учат студентов-программистов? Нажимать на кнопки и пункты меню в некоторой среде разработки - не велика наука. Сварганить что-то типа "Хеллоу, уорлд!" - ещё хлеще... Нет! Всё не то!

Чему же их надо учить?

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

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

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

Поэтому большинство нынешних сред разработки скрывают свои механизмы под огромной толщей абстракций. Внутри Java активно используются указатели, но кто из программистов, создающих ПО на Java, знает, как их достать? И разработчики Java говорят, что они скрыли указатели, чтобы, не дай Бог, кто-то не ошибся при работе с ними и не попортил себе программу. Не верьте в этот бред! Указатели скрыты не из-за заботливости создателей Java, а из-за их нежелания делиться своими знаниями. Если вы в своей программе ошибётесь при работе с указателями, то это будут всего лишь ваши личные проблемы. Но скрытые указатели создают проблемы для всех программистов, пишущих на Java, поголовно (ладно, не совсем поголовно - только для тех, кто разрабатывает более-менее серьёзные проекты).

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

Ещё ранее с той же целью использовались различные среды RAD типа Delphi и той же VisualStudio. Только вместо .NET абстрагирование от WinAPI достигалось предоставлением пользователям неких готовых классов. это часто работало! Пока в некоторый момент абстракция не начинала протекать: у программиста появлялись проблемы, суть которых он не мог понять, поскольку для этого требовалось знать не только WinAPI, но и устройство механизмов его среды разработки...

И в итоге мы имеем тысячи программистов-пользователей, которые не могут выйти за пределы одной среды разработки и не могут идти дальше предопределённого набора готовых классов (кроме, разве что, создания их наследников). И создаваемое ими ПО часто имеет сомнительное качество, улучшить которое им не под силу. И всё потому, что в студенческие годы их учили использовать RAD, Java и .NET, но не опускали до уровня битов в регистрах процессора и до уровня вызовов API операционной системы. Они умеют пользоваться чужими идеями и мыслями, но вот вырабатывать свои мысли они не научились...

Не пора ли сказать такому "образованию" СТОП!?

***

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

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

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

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

Во-вторых, каждая нестандартная ситуация на то и нестандартная, что для неё приходится искать свой ключ. Опыт тут может только подсказать направление поиска. А может, наоборот, направить по ложному следу. И тут программист должен, подобно Шерлоку Холмсу, применить все свои способности, чтобы найти причину проблемы и устранить её.

Эти два момента говорят о том, что программистом нужно родиться... Нет, не совсем так! Кроме врождённого таланта, нужно ещё и воспитать свой характер. Но и это не всё. Нужно, всё-таки, получить кое-какие знания.

И вот тут-то мы и подошли к вопросу обучения программистов. Кого учат наши ВУЗы? Правильно, кого только они не учат. Но бесполезно учить того, кто не имеет необходимых способностей или необходимых черт характера. Т.е. ВУЗ он, конечно, окончит, и диплом получит, и даже на работу устроится. Но только инженером-программистом не станет. Я тут не говорю о формальной должности. Я говорю о его способности делать свою работу, не перекладывая её на чужие плечи.

Если б я был студент... При такой постановке вопроса подавляющее большинство нынешних студентов, конечно, в ВУЗ не попало бы. Для них студенчество так и осталось бы мечтой. Но, возможно, освободились бы места для тех, кто действительно талантлив и имеет сильный, воспитанный в детстве характер.

Поэтому первое, что нужно менять в нашей системе образования - требования к абитуриентам. Я не против того, чтобы выпускник школы шёл в ВУЗ. Но я против того, чтобы он занимался не своим делом. От этого никто не выигрывает.

***

Но вот на первый курс поступил молодой человек, явно подающий надежды. Что мы должны вложить в него, чтобы он стал настоящим, надёжным специалистом?

Прежде всего, мы должны опустить его на уровень, на котором НЕТ АБСТРАКЦИЙ. Т.е. на чисто физический уровень. Нужно показать, как команда, отданная программистом, заставит электроны лететь в нужном направлении. Как и почему будут открываться или запираться транзисторы. Как и почему будут заполняться регистры.

Далее можно уже заниматься вводом уровней абстракций, снизу вверх. От битов и байтов до современных библиотек классов. Я могу поспорить, что курсу к четвёртому студент будет в состоянии найти и исправить большинство багов в коде современных сред разработки. А его дипломной работой может стать собственный программный продукт, подобно тому, как им стала когда-то поисковая система Google.

@темы: общие вопросы разработки ПО, персонал, программирование

---

Как часто можно услышать на собеседовании с кандидатом фразу: "Я опытный программист, поэтому я освою этот язык программирования недели за две!". У меня сразу начисто отпадает желание говорить с таким товарищем дальше. И вот почему.

Что значит фраза "я освою язык программирования"? Я уже несколько лет занимаюсь разработками ПО на Java, но, поверите ли, ни разу не пользовался Swing или AWT. Да, за это время я хорошо изучил принципы работы с коллекциями, строками, памятью, влез в технологии управления базами данных, освоил JSP и сервлеты, понял, как надо и как не надо обеспечивать безопасность данных в web-приложении... Но я по прежнему не могу сказать, что я освоил этот язык! Я освоил только мизерную часть того, что называется Java. А тут этот юнец заявляет, что за пару недель освоит то, на что мне не хватило нескольких лет напряжённого труда, причём сделает это без отрыва от производства!

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

@темы: персонал

---

Исключительные ситуации в коде - вещь противная. Практически нет сегодня ни одного более-менее популярного языка, в котором не было бы возможности перехватить и обработать исключение. Но это помогает в том случае, если разработчик знает, что перехватывать. А если он этого не знает? Что делать, если возникнет исключение там, где его не ждали?

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

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

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

Но это не всё. Я защищаю ключевые функции в коде. При этом вводятся две константы. Первая указывает на файл исходного кода, в котором реализована функция. Вторая содержит имя функции (для метода некоторого объекта указывается имя объекта и имя метода через точку). Затем весь код функции заключается в блок try, а в блоке обработки исключения результату функции присваивается некоторое значение по умолчанию и вызывается запись параметров исключения в log-файл. В файл записывается не только время и параметры исключения, но и имя файла и функции, а в некоторых случаях и параметры, переданные функции при её вызове. Таким образом, удаётся, во-первых, избежать последствий возникшего исключения (за счёт возврата корректного результата) и, во-вторых, записывается важная информация о самой ситуации. Используя записанную информацию, можно исправить значительное количество ошибок, даже если они не воспроизводятся на испытательном стенде.

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

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

@темы: программирование, отладка и тестирование

---

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

Почему первое решение неправильное? Прежде всего потому, что разработчик через пару дней сам забудет, что созданный внутри метода объект нужно после использования освободить. Он вызовет метод, получит объект, поработает с ним - и забудет. Если для освобождения объекта достаточно автоматической сборки мусора, то ничего особо страшного не произойдёт. Но если перед уничтожением объекта нужно провести некоторые манипуляции, то произойдёт "утечка памяти" - ресурсы не будут освобождены и будут висеть в памяти до завершения работы приложения.

Второе решение значительно нагляднее и безопаснее. Вы создаёте и уничтожаете объект в одном и том же месте. Конечно, забыть об освобождении ресурсов и тут можно. Но опытный программист пишет код освобождения объекта сразу, как только был написан код его создания, да ещё и позаботится о том, чтобы освобождение произошло даже при возникновении исключения в коде (например, заключит весь код работы с объектом после его создания в блок try, а код освобождения ресурсов - в блок finally).

@темы: программирование

---

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

Начинаю разбираться. После некоторых поисков локализую ресурсоёмкий код. Это, естественно, цикл. В цикле вызывается стандартная процедура вывода данных, которая никогда и ни у кого не вызывала проблем. И тут, вроде бы не должна. Но грешить больше не на что. Сама процедура отрабатывает при каждой итерации без особых задержек, но итераций больше 5000. Очевидно, что задержка в теле процедуры хотя бы на одну миллисекунду вызывает общую задержку в 5 секунд!

Лезу в текст процедуры. Внутри вызываются несколько методов. Просматриваю каждый. И внутри одного из методов вижу ещё один цикл, внутри которого выполняется поиск нужного объекта и проверка его свойств. Ещё 10000 итераций. Получается, что я 5000 раз запускаю один и тот же цикл, но ищу в нём разные объекты. А оно мне надо?

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

Вроде бы вложенные циклы остались. Но раньше мне приходилось делать 5000 х 10000 = 50000000 итераций поиска и отбора. А теперь я выполняю сначала 10000 итераций поиска и отбора, а затем 5000 х 100 = 500000 итераций вывода данных. Итого 510000 итераций. Таким образом, у пользователя его функция стала работать почти в 100 раз быстрее!

Конечно, это грубая оценка. Итерация итерации рознь. Но факт состоит в том, что я убрал лишние проверки. Фильтрация списка объектов идёт только один раз, а не 10000, как раньше.

*****

Ладно, пользователь доволен. Однако я - нет. Как случилось, что в продукт вообще влезла такая гадость? И как избежать повторения ошибки?

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

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

Очевидно, нужно предпринять несколько мер.

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

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

@темы: программирование

---

Помнится, была у Джоэля Сполски такая статья. "Огонь и движение" (russian.joelonsoftware.com/Articles/FireAndMoti...). Бывает, я точно также "не могу ничего делать". Я не в потоке. Мысли рассыпаются мелкими осколками...

Я заметил, что мне сложно приняться за какую-либо работу, если я в деталях не представляю, как её выполнить. Мне нужен план. Детальный план, учитывающий каждый аспект ТЗ. План, в котором нет подзадачи продолжительнее 4-х часов. План, в котором собрана вся информация о явных и скрытых требованиях к разрабатываемой программе.

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

"...В запросе поиска анкеты можно ввести данные об анкете:
- тип анкеты (..., калибровочная);
- требует ли анкета калибровки;
- была ли проведена калибровка..."

И всё. Само собой разумеется, что калибровка уже реализована (хотя об этом раньше никто и не думал). В ТЗ даже нет расшифровки понятия "калибровка"... Брррр! Мороз по коже.

Начинаю исправлять ошибки менеджеров (а ведь считается, что составление и рецензирование ТЗ - вообще не моя работа!). На это надо себя ещё как следует "пнуть".

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

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

Задача разрастается на глазах. А ведь всё началось так просто: нужно найти анкету...

Беглый взгляд на структуру продукта даёт ещё набор требований. В списке анкет нужно выделять пиктограммами анкеты, требующие калибровки, прошедшие калибровку или (и?) являющиеся калибровочными. Список нужно фильтровать и сортировать по этим признакам. Для завершённой анкеты теперь нужно выводить два результата: её собственный и с учётом калибровки (в последнем нужно учесть калибровку калибровки и калибровку калибровки калибровки...). При выводе отчётов нужно учитывать либо собственные результаты анкет, либо результаты, учитывающие калибровку. И т.д. и т.п.

Вот вам и ТЗ! Добавим сюда изменение структуры базы данных, реализацию функций по внедрению этих изменений на уже развёрнутых системах и прочую мелочёвку. И всё настроение работать отрезает напрочь. И почему нельзя было просто забанить ошибочную анкету и заставить неряху заполнить всё заново? Чем попытки попасть пальцем в небо лучше?.. Вопросы без ответов уводят меня, и без того злого на наших менеджеров, далеко в сторону от рабочего процесса.

***

Менеджеры имеют нехорошую привычку заключать договор с заказчиком на основе такого непродуманного ТЗ, не согласовывая его с разработчиками. Получается так, что и менеджеры и заказчики считают, что функция проста в реализации, и закладывают на её реализацию короткий срок и небольшую сумму денег. Но при этом они забывают, что видят только вершину айсберга, ведь только разработчик может сказать, сколько труда нужно, чтобы реализовать эту "простую" функцию. И неожиданно для себя, разработчик становится заложником сложившейся ситуации, когда ему нужно создать работающую функцию за очень короткий срок и при этом не вылезти из бюджета. Что, как известно, неразрешимо: страдает либо качество, либо сроки, либо бюджет, либо, чаще всего, всё вместе.

Что же делать разработчику? Сначала он идёт к начальству и жалуется на менеджеров, подкинувших ему свинью. Хорошо, если начальство сможет решить проблему и договорится с заказчиком на новых условиях. Но чаще пересмотреть договор не получается. И тогда разработчик остаётся один на один с проблемой. И решить её он в рабочее время не может, не превысив сроки или бюджет. И он остаётся работать после окончания рабочего дня, или работает дома. Причём работает бесплатно... Как Вы думаете, сколько таких подвохов он выдержит, прежде чем пошлёт всё лесом?

Безответственное отношение к созданию ТЗ сродни диверсии на производстве. Оно может надолго выбить программистов из колеи и поставить весь проект под удар.

Чтобы избежать подобных ситуаций, руководство должно принять соответствующие организационные меры. Например, предупредить менеджеров, что договора с заказчиками не будут подписываться, если ТЗ не согласовано с разработчиками. А уж если договорённость с заказчиком всё-таки была достигнута, и разработчику пришлось эту кашу расхлёбывать, то он должен получить не только положенные сверхурочные, но и дополнительную премию за подставу с извинениями от руководства за допущенный промах. Ведь хороший разработчик ПО всегда найдёт работу, а вот Вы хорошего разработчика искать будете долго, учитывая подмоченную репутацию.

@темы: программирование, персонал, внедрение

---

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

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

Иногда эта основа трещит по всем швам. И тогда она выворачивает руки всем, кто за неё держится. Т.е. всем, кто задействован в проекте.

И если Вы не были готовы к такому развитию ситуации, Вы потеряете контроль, проект резко развернёт - и пиши пропало...

@темы: управление проектами

---

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

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

Вот на эту тему и нужно поговорить.

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

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

Среднестатистический программист гордится своей работой, любит её и старается делать её не просто качественно, но... как бы это сказать... творчески. Он создаёт продукт из самого загадочного и неуловимого материала на свете - из МЫСЛИ.

Безусловно, первым приоритетом для любого человека при поиске рабочего места является удовлетворение его нужд (включая нужды, связанные с семьёй и близкими). Если работа не удовлетворяет эти нужды полностью, то человек будет работать и одновременно искать другое место - и он уйдёт при первом же попутном ветре!

А вот на втором месте у программиста стоит сама ВОЗМОЖНОСТЬ работы. Ему нужен достаточно производительный компьютер, Ему нужна тихая и спокойная обстановка. Ему нужно тёплое помещение зимой и прохладное - летом. Помните, он работает с мыслью. Одно отвлечение - и мысль исчезла, растворилась. Шум, дискомфорт, другие раздражители делают программиста непродуктивным. А он, как профессионал, не любит быть непродуктивным. Заметьте, глючное ПО, которое некоторые работодатели навязывают программисту в качестве среды разработки, тоже может стать источником его непродуктивности, а иногда и прямой причиной увольнения.

Третий момент: насколько задачи, выполняемые программистом, позволяют ему сохранять актуальными свои навыки? Среды и языки программирования изменяются очень быстро. Программист должен постоянно следить за развитием отрасли и быть "на высоте", чтобы в случае чего не остаться на улице ни с чем. Заметим, что ещё три года назад была большая потребность в программистах, знающих Delphi. Но сегодня этой потребности нет. Точнее, она значительно скромнее. Сегодня требуются знатоки C#. И те, кто не успел перескочить с одного поезда на другой, может оказаться в весьма затруднительном положении. Но знать язык в теории мало, нужна практика. И если текущая работа не даёт такой практики, то это может стать поводом для поиска другого места работы.

Не следует также забывать о личных целях и амбициях разработчика. У него могут быть развиты не только навыки программирования. Он может быть талантливым организатором и руководителем. И если таланту не дают развиваться, рано или поздно произойдёт конфликт. Далее, у программиста могут быть долгосрочные цели, для достижения которых ему нужно принимать определённые шаги. Например, его семья нуждается в улучшении жилищных условий, поскольку дети растут, и скоро его квартирка станет маловата. На новую нужны деньги. Их нужно зарабатывать. Чтобы их заработать, нужно занять определённую позицию (например, из программиста дорасти до ведущего специалиста). Чтобы занять эту позицию, нужно пройти обучения на спецкурсах, получить пару сертификатов, выучить десяток технологий и всё такое... Целая стратегия. И на любом шаге этой стратегии нынешнее рабочее место может оказаться серьёзной помехой, подлежащей устранению.

Ещё важный момент - УВАЖЕНИЕ. Если Вы наймёте молодого зелёного программиста на оклад, который получает давно работающий у Вас опытный разработчик, и тот узнает об этом - пиши пропало. Это самое серьёзное оскорбление, которое Вы можете нанести своему сотруднику. Искать ему замену Вы будете долго.

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

Задача менеджера-кадровика является выявление и распутывание всего этого клубка на возможно более ранних стадиях. Тогда уход разработчика не станет неожиданностью. Но уж если о том пошёл разговор, то нужно сразу расставить всё по полочкам. А дальше вырабатывать стратегию удержания.

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

Итак, узнаём о нуждах сотрудника и определяем, можем ли мы их удовлетворить (способы могут быть разные: повышение зарплаты, ссуды, даже найм рабочих для проведения ремонта в доме сотрудника за счёт фирмы). Если нет - дальше удерживать бесполезно и даже опасно. Две недели на передачу дел - и не дай Бог вам затягивать время! Помните, что от Вас уходит профессионал, имеющий, как правило, широкие связи в своей среде. Негативный отзыв от него отпугнёт от Вас многих хороших разработчиков.

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

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

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

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

Согласовываем. Фиксируем. Дальше.

Смотрим на цели и амбиции сотрудника. Тут, как правило, сиюминутных решений быть не может. Но вот выстроить совместную стратегию развития Вашего сотрудника Вы можете. Вы можете даже ЗАПЛАНИРОВАТЬ, на каком этапе он действительно покинет Вашу компанию. Но это лучше, чем потерять ключевого разработчика посреди проекта.

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

Возможно, я что-то тут не рассмотрел. Но, думаю, общий принцип понятен.

@темы: управление проектами, персонал