Принципы разработки
Каждый проект, за который я берусь, обречен на успех, благодаря 7 (согласитесь, непростая цифра) проверенным и безупречно результативным принципам:
- Планирование и обратная связь… во имя идеального часа!
- Приоритет важного.
- От исследований причин и закономерностей к требованиям и функциям.
- Простота.
- Сохранение коммуникативной функции программного кода.
- Постепенные изменения.
- Тестирование.
Планирование и обратная связь… во имя идеального часа!
Я уважаю свой труд и уважаю человека, который мне за него платит – Заказчика. Именно поэтому я считаю, что Заказчик должен платить только за то время, которое было реально затрачено на выполнение его задания. Я – профессионал и опускаться до того, чтобы просто тянуть время, вытягивая тем самым деньги, не желаю. В рамках собственного развития предпочитаю, чтобы оценка моего труда в денежном эквиваленте соответствовала оному.
Поэтому я разработал систему идеальных и физических часов. Т.е., принимая какой-либо заказ, я ставлю срок его выполнения, максимально приближенный чистому (идеальному) времени: в расчет я беру только те часы, минуты и секунды, в которые я работал над заказом, не отвлекаясь на что-либо постороннее (есть только я, компьютер и необходимые материалы). По выполнении заказа я сравниваю тот срок, на который рассчитывал изначально, и реальное время выполнения задания. С каждым разом соответствие идеального и физического часов все больше.
Таким образом, выполняется главная формула всех успешных деловых отношений – профессионализм + взаимное уважение.
Да, я – идеалист!
Приоритет важного.
Система априори должна выполнять функции, иначе необходимости в ней бы просто не было. По степени важности эти самые функции различаются.
Одни носят концептуальный характер и жизненно необходимы для полезного функционирования Системы.
Другие функции – вторичны: они сильно упрощают взаимодействие пользователя и Системы и часто применяются.
К третьим же вообще редко обращаются. А некоторые после детального (а порой просто дотошного) рассмотрения, образно говоря, отправляются в Корзину за ненадобностью.
Из всего выше изложенного можно сделать несложный вывод принципа моей работы: самые важные я реализую в первую очередь. Это позволяет Заказчику еще до полного завершения разработки Системы приступить к тестированию критически необходимой функциональности, и… соответственно, понизить риск разработки.
От исследований причин и закономерностей к требованиям и функциям.
Я верю в причинно-следственные связи в этом маленьком мире. Согласно моей вере, любая часть Системы имеет под собой причину, которая определяет назначение каждого элемента и, собственно, функцию. Правильное понимание причин ведет к правильной реализации. Впрочем, как и выявление и учет закономерностей создания эффективной Системы – мелочей в этом вопросе нет.
Я считаю (и со мной многие согласятся), лучше затратить больше времени на осознание задачи, чем потом удивляться, почему же проект, сделанный точно в соответствии с техническим заданием, представляет собой не то, что было нужно Заказчику.
Простота.
Простота – это удобство, а всем приятно работать с тем, что удобно и доступно для понимания и пользования. А для Системы удобство – это одно из «золотых» достоинств.
Простота в интерфейсе позволяет пользователю легко ориентироваться в Системе, а простота в реализации (технических решениях) позволяет программисту затрачивать на Систему разумное время и, как следствие, на ее разработку.
В общем, как ни крути, простота – штука хорошая!
Сохранение коммуникативной функции программного кода.
Да, программный код – это указание машине делать определенные действия. Но! Это же еще и средство общения между разработчиками Системы. И это забывать никак нельзя. Лаконично и понятно сформулированный программный код более надежен, нежели сложный и оттого запутанный. Идеальный код – это не письмена, написанные на мертвых языках, это как раз и есть «живой» язык, на котором говорят программеры и который «понятен» машинам. И никаких комментариев не надо будет!!! В общем, здесь в полной мере важен принцип простоты.
Постепенные изменения.
Эволюция всегда предпочтительней жесткой революции. Во всяком случае, в нашем программерском деле, это непреложная истина. Поэтому-то изменения в Систему должны вноситься небольшими порциями, дозировано. Иначе проект будет неуправляем (как и революция), а Заказчик не сможет отслеживать развитие проекта и влиять на него по своему усмотрению. Я стараюсь получать стабильно работающие версии через настолько короткие временные промежутки, насколько это вообще возможно и представлять эти версии Заказчику.
Тестирование.
Тестирование – это своего рода проверка на прочность. Для Системы проверка на эту самую прочность (и надежность программного обеспечения вообще) – адекватный набор функциональных тестов и автоматических тестов модулей (Unit-тесты). Этот набор должен соответствовать сложности Системы и требованиям к предсказуемости ее поведения.