Test Your Soft - QA сервис. Тестирование ПО и web приложений.

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

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

Из всего многообразия методик стоит обратиться к следующим направлениям:
  * документирование требований 
  * сценарии использования 
  * написание спецификации 
Первые 2 пункта позволят вам понять, что должна делать система, а спецификация должна описать как она это будет делать. Казалось бы - все предельно просто, но... Но это требует времени, а руки-то уже чешутся писать код... Ну что же. Если так, то можно создать прототип системы. Но ни в коем случае не превращайте его потом в заготовку, из которой будете делать ваше приложение!

Итак, перед началом написания кода у вас должны быть определены требования и описана спецификация. Если работаете на заказчика, то из спецификации достаточно легко получить техническое задание. Приступайте к работе только если вы подписали и согласовали ТЗ с заказчиком! Это избавит вас от заявлений заказчика "А я думал, что вот тут.. " или "А мне бы доделать здесь такую штуку, я про нее сразу забыл..". Истина прописная, но тем не менее, мало кто ей следует, за что потом и расплачиваются. В случае наличия ТЗ за свои прихоти будет платить уже заказчик.

Начали писать код - документируйте его. Установите единый стиль форматирования (благо есть уже инструменты, которые делают это автоматически) кода и именования объектов. Используйте систему контроля версий - на рынке их хватает. Можно использовать системы автоматической сборки проектов, чтобы каждый день получать билд и прогонять на нем Unit-тетсты. Юнит-тесты тоже очень желательно писать.

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

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

Минимизируйте ввод данных от пользователя. Не позволяйте вводить данные вручную, где только это возможно. Используйте календари, выпадающие списки, диалоги, визарды. Пользователь должен выбирать данные, а не вводить их. Постарайтесь ограничить выбор 7-8 пунктами. Если же это невозможно сделать - группируйте и упорядочивайте элементы. Хотя, как показывает практика, люди вполне успешно способны работать и с большими списками, особенно если за это им платят деньги.

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

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

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

Кроме этого не давайте утомляться глазам, хорошо кушайте, спите 8 часов в сутки и не унывайте. И все у вас получится! Удачи!