Для большинства людей, за исключением ремесленников, создающих кино, поход в кино - это побег. Акт сидения в огромном кинотеатре, прослушивание точно настроенного звука, погружение в огромный экран, приостановка недоверия - все это предназначено для того, чтобы погрузить нас в опыт, который не является нашим собственным, чтобы мы могли сидеть назад и просто наслаждайтесь.
Будь то комедия или драма, боевик или мелодрама, мультфильм или биографический фильм, фильмы предлагают нам столько или меньше развлечений и удовлетворения, сколько мы выберем. Возможно, достаточно света, цветов и звуков. Невероятные спектакли, которые заставят вас забыть имя вашего любимого актера, поскольку они олицетворяют другого. А может, это несколько взрывов. Какой-то чудесный CGI, практически неотличимый от реальной жизни. Может быть, это тонко сплетенная история или прекрасный кинематограф, который перенесет нас на другой конец света.
Однако для творческих людей каждый кадр - это возможность поразмышлять не только о рассказываемой истории, но и о ее рассказе. «Как они сделали этот снимок?» «Как они пришли к такому сюжету?» «Какая тонкая работа».
Программное обеспечение не слишком отличается. После того, как чудо и путаница кривой обучения утихают (и кажется, что каждый последующий урожай цифровых аборигенов преодолевает кривую быстрее, чем предыдущий), многие из нас сразу переходят к автопилоту. Пользователи ожидают, что приложение будет «просто работать», практически не задумываясь о том, что происходит, чтобы заставить его работать. Это почти как инстинктивная приостановка недоверия к тому, что лежит в основе программного обеспечения, эвристика, которая помогает нам справиться с огромным всплеском стимулов, которыми люди нагружают себя в этом веке.
Однако мастера программного обеспечения, такие как инженеры, руководители продуктов и дизайнеры Giant Machines, посвящают большую часть своей жизни удалению слоев, чтобы понять и помочь определить, что именно делает программное обеспечение «великим».
«Хорошее программное обеспечение - это не только выполнение его предполагаемой функциональности», - отмечает Эмре Кумали, старший инженер-программист в Giant Machines. «Это всего лишь ставки стола. Что происходит, когда программное обеспечение должно развиваться с учетом отзывов пользователей и изменений бизнес-требований? Сможет ли приложение справиться с резкими скачками трафика? Разработан ли код с учетом гибкости и масштабируемости? »
Эмре использует здесь определение величия. Речь идет не только о том, чтобы сегодня сделать что-то отличное. Речь идет о создании чего-то отличного с учетом устойчивости. Одного феноменального сезона для профессионального спортсмена обычно недостаточно, чтобы попасть в Зал славы своего вида спорта. Требуется преодолеть планку величия и подтянуть ее вместе с собой.
Когда дело доходит до программного обеспечения, это означает создание версии 1 с учетом будущих версий. Придерживаясь аналогии со спортсменом, это не означает, что нужно прятаться в спортзале, пока вы не станете в совершенстве. Это означает выходить на улицу и оттачивать свое мастерство изо дня в день.
«Хорошее программное обеспечение начинается с понимания болевых точек или вариантов использования, которые вы пытаетесь решить, - продолжает Эмре. Создавайте минимально жизнеспособный продукт, развертывайте, получайте отзывы, учитесь, повторяйте. «Путь к этому не заключается в разработке, разработке, разработке и выпуске того, что вы считаете идеальным. Но вы, конечно же, не добьетесь этого, торопясь с процессом разработки и выпуская продукт, который вам нужно перестроить и рефакторировать только для того, чтобы выпустить одну новую функцию ».
Эмре продолжает: «За годы разработки программного обеспечения и общения с признанными экспертами в этой области я пришел к тому, чтобы определять качество программного обеспечения по трем характеристикам, которые оно включает, сформулированным в трех простых вопросах. Первый уровень - самый простой - это «Работает ли он и ведет себя так, как задумано?» На этот вопрос может ответить любой пользователь программного обеспечения ».
Следующие две характеристики - остальная часть метафорического айсберга, основная масса под поверхностью - определяют код качества с инженерной точки зрения. Могут ли разработчики легко сотрудничать сегодня? Можем ли мы провести рефакторинг, чтобы учесть изменения в функциональности завтра?
«Второй вопрос, который нужно задать, - делится Эмре, - это:« Насколько легко понять код? »Сообщается ли он другим инженерам, не прибегая к комментариям к коду или документации?
«Этого можно достичь, написав чистый, понятный, самодокументирующийся код. Ясно и последовательно названы пакеты, классы, функции и переменные? Может ли соавтор разобраться в вашем коде и быстро внести свой вклад? »
// Returns the area of a rectangle with integer sides i1 and i2 passed to this method
public String myFunction (int i1, int i2){
return i1*i2;
}
vs
public String calculateRectangeArea (int side1, int side2){
int rectangleArea = side1 * side2;
return rectangleArea;
}
Вот простой пример, иллюстрирующий нашу точку зрения. Если инженер обновит входные параметры int i1 и int i2 до плавающих типов, он может пропустить обновление комментариев над методом. Используя явные имена пакетов, классов, методов и переменных, они написали более прозрачный, самодокументируемый код, что избавляет от необходимости использовать комментарии для объяснения намерений и делает код более понятным для потенциального соавтора.
«Наконец, спросите:« Насколько открыто это для изменения? »Если бы я должен был расширить функциональность, скажем, добавив или удалив функцию, нужно ли мне изменять несколько несвязанных частей кодовой базы и рисковать? нарушение приложения? »
Код, обеспечивающий ожидаемую функциональность, просто не подлежит обсуждению, но что происходит, когда ожидания меняются? Пользователи могут быть непостоянными. И даже вне этой непостоянства требования и привычки могут измениться. Благодаря гибкой разработке ваше приложение естественным образом развивается благодаря обратной связи, полученной от последующих выпусков.
Возможно, здесь кино и софт непримиримо расходятся. Там, где программа - это живая, развивающаяся вещь, фильм - статичный артефакт. Мы можем улучшить наше понимание контекста, а рассматриваемый фильм может или не может устареть. Но он не предназначен для постепенного изменения с течением времени - возможно, переделки, но работа остается указателем на определенный момент времени. С другой стороны, мастера, которые создают отличный код и запоминающийся пользовательский опыт, обладают как способностью, так и неявным разрешением улучшать свою работу с течением времени, отвечая, а иногда и помогая переосмыслить ожидания пользователя.
Для нас это звучит неплохо.
