Довольно большое количество литературы посвящено такому вопросу как оценка программного обеспечения (по стоимости и/или времени разработки). Понятно, что дисциплина эта новая (по сравнению, к примеру, с металлургией). И понятно, что ошибки тут бывают довольно часто. В этом посте я приведу несколько историй из жизни, которые невозможно было учесть при составлении оценки и которые повлияли на увеличение сроков разработки.
История об удалении файлов и папок
При разработке приложения по преобразованию файлов была составлена оценка сроков, расписаны задачи, и приложение было сделано примерно по этому плану. Программа даже была протестирована и внедрена (это внутренний инструмент для маленького коллектива, поэтому на самолете к заказчикам никто не летал — просто начали пользоваться). Однако выяснилось, что периодически в программе возникает ошибка вот в каком месте. Программа распаковывает архив во временную папку, работает с файлами оттуда, после чего папку удаляет. Так вот иногда программа «не успевала» закрыть файлы и соответственно при удалении возникала ошибка, связанная с тем, что кто-то «держит» файлы. Программа была написана на .Net, поэтому время запуска сборщика мусора и прочих штук было не совсем очевидным — вероятно проблема была в этом. В результате на эту непредвиденную проблему ушло довольно много времени — сопоставимо с другими задачами этого проекта. Да и до сих пор мы не уверены, что эта проблема решена окончательно.
История о внедрении в процесс и антивирусах
Другой пример, в котором возможно многие узнают свои проблемы. Все знают, что антивирусы не всегда адекватно воспринимают нормальные программы. После небольшого, но важного изменения в одном нашем приложении антивирус стал многократно ругаться на попытку внедрения в процесс и подозрения на вирусы. Хотя ничего криминального в том коде не было, «борьба» с антивирусом потребовала и сил, и ресурсом, которые могли бы быть использованы более адекватно.
История о файловом диалоге
В простеньком приложении (точнее в Control Panel Applet, .cpl) как-то понадобилось показать стандартный диалог открытия файлов. К удивлению, при попытке показать файловый диалог именно из такого типа приложения происходят проблемы, из-за которых диалог не показывается. Сколько на поиск проблемы и решение было потрачено времени — ужас (по сравнению с другими задачами). Решение оказалось еще ужаснее. Пришлось делать отдельное (!) приложение для показа файлового диалога. Только таким страшным способом удалось сделать задачу.
«Ну, так вы просто программировать не умеете!»,
может воскликнуть читатель и будет не прав. Взаимодействия компонентов систем часто бывают настолько сложны, что ошибки и проблемы возникают в самых неожиданных местах. Не верите? Вот вам четвертая история.
История со сломанными OpenGL-приложениями
В команде разработчиков сложного OpenGL-приложения однажды возникла проблема — приложение перестало выдавать радующие глаз картинки. Первым делом были допрошены все программисты на предмет «не сломал ли кто-нибудь что-нибудь». Затем откатились к прошлой версии — это тоже не помогло. Железо (на первый взгляд) на той машине не менялось. Правда, позже вспомнили, что на этом компьютере недавно появился новый ИБП. Но не может же это повлиять на работу OpenGL-приложений? Может. К этому ИБП шел драйвер, который вроде бы работал как надо, но только при нем любые OpenGL-приложения, например игры, не работали. Удаление драйвера решило проблему.
К чему все эти истории?
Уверен, что опытным разработчикам и менеджерам в этих историях не удастся найти чего-то нового. Они-то знают все это на собственном опыте. Эти истории могут быть полезны начинающим программистам, которые может быть даже и читали книги Брукса и Макконнелла, но по молодости думают: «Эти стариканы (авторы книг) программировали в древности, сейчас-то таких проблем не бывает». Увы, бывают. И никаких предпосылок к тому, что их число уменьшится, нет. Никакие библиотеки, инструменты (неужели это я написал?) не защитят вас от того, что вы ошибетесь в оценке проектов. Поэтому когда опытный коллега или начальник увеличит вашу оценку в два-три раза, не думайте, что он недальновидный.
Неужели так будет всегда?
Скорее всего — нет. Просто сейчас разработка программного обеспечения слишком молодая отрасль, в которой нет десятилетиями проверенных стандартов и практик.
В комментариях, пожалуйста, делитесь своими историями, когда что-то неожиданно вылезло при разработке.
