Вместо заключения
Задумываться о борьбе с ошибками переполнения следует до начала разработки программы, а не лихорадочно вспоминать о них на последней стадии завершения проекта. Если это не поможет гарантированно их предотвратить, то, по крайней мере, уменьшит вероятность возникновения до минимума. Напротив, возлагать решение всех проблем на beta-тестеров и надеяться, что надежно работающий продукт удастся создать с одной лишь их помощью –слишком наивно.
Тем не менее именно такую тактику выбрали ведущие фирмы, – стремясь захватить рынок, они готовы распространять сырой, кишащий ошибками программный продукт, "доводимый до ума" его пользователями, сообщающими производителю об обнаруженных ими ошибках, а взамен получающих либо "заплатку", либо обещание устранить ошибку в последующих версиях.
Как показывает практика, данная стратегия работает безупречно и даже обращает ошибку в пользу, а не в убыток – достаточно веской мотивацией пользователя к приобретению новой версии зачастую становятся отнюдь не его новые функциональные возможности, а… заверения, что все (или, на худой конец, большинство) присущих ему ошибок теперь исправлено. На самом деле исправляется лишь незначительная часть от всех ошибок, и добавляется множество новых, поэтому, такую волынку можно тянуть до бесконечности, и потребитель (куда ж ему деться) будет без конца приобретать все новые и новые версии, обеспечивая компании стабильный доход и процветание.
Вы все еще хотите исправлять ошибки в своей программе? (Шутка, конечно, а то вдруг кто поймет неправильно)
