Чистый или нестандартный: какая CMS лучше?

Одна вещь, которую я бы сделал по-другому, — это узнать больше о Drupal заранее. Я использовал его только 3-4 года назад, и только на небольшом проекте. Так что у меня было чему поучиться за день!

Марк Рикерби (CodeBlacks)

SitePoint: Как программист команды, какую подготовку вы делали в преддверии мероприятия?

У меня было несколько недель заблаговременного предупреждения, и, естественно, предполагалось, что я погрузлюсь в практику и подготовку — но я неожиданно понял, что через несколько дней после конкурса я почти ничего не сделал!

Самое важное, что нужно сделать, это поговорить с другими членами команды, понять, как они работают и как мы можем сотрудничать. Моя индивидуальная подготовка состояла из создания фреймворка PHP-кода, который я использовал в предыдущих проектах. Я прошел все классы, добавил модульные тесты, очистил некоторые соглашения об именах и заполнил пробелы. Это было далеко не так полно, как мне бы хотелось, но так как я написал это сам, мне было легче читать и понимать, чем был бы другой случайный открытый исходный код.

SP: Вы, ребята, выбрали систему на заказ, в то время как австралийцы использовали Drupal. Какая польза от вашего решения? Как вы думаете, это ограничивало вас? И в какой момент вы подумали: «О, я откусила больше, чем я могу жевать?»

Я думаю, что было бы справедливо сопоставить преимущества лично для меня с вытекающими из этого преимуществами для команды и клиента. Я думаю, что главное преимущество для всего сайта было в том, что он имел возможность разрабатывать простую и чистую архитектуру — нам никогда не приходилось заново интерпретировать дизайн или модель данных сайта с точки зрения попытки вписать его в неправильную согласованная структура, поэтому у нас была огромная степень свободы. В результате большая часть нашего процесса была сосредоточена на дизайне, что и было нашей первоначальной целью.

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

Я думаю, что сделанная на заказ платформа ограничила нас в том смысле, что она требовала менее гибкого процесса — я потратил много времени, работая над общей архитектурой и серверной частью сайта, а не включая отдельные функции по одной, поэтому мы не стали подготовьте контент к страницам или проверяемым URL-адресам, пока они не появятся слишком поздно. Но отчасти это была моя вина за то, что я допустил несколько глупых ошибок в кодировании, и не обязательно из-за нашего решения использовать пользовательскую CMS (что, на самом деле, заняло у меня меньше часа). В любом случае, нам пришлось бы подождать, пока не будет написан контент и не создан CSS / HTML, прежде чем мы сможем что-либо реализовать, и это был довольно большой отрезок времени, который я мог использовать. (Я просто должен был использовать это с умом — я все еще не уверен, что я сделал!)

Я не думаю, что у меня было чувство откусывать больше, чем я мог жевать до 6 утра, когда я понял, что у меня есть только час, чтобы идти, и было так много вещей, которые все еще не работали. Может быть, я был введен в заблуждение до тех пор? Все эти мелочи обманчиво сложны. Вы знаете, что на кодирование дополнительной функции уйдет всего 10-20 минут, но если учесть разговоры с командой, тестирование, несчастные случаи на пути, может пройти более часа.

Тем не менее, я видел меньше результатов от 80-часовых проектов с гораздо большими бюджетами, поэтому я достаточно доволен конечным продуктом. Я чувствую, что только что поцарапал поверхность того, что возможно за 24 часа.

SP: Где вы вписались в процесс — вы чувствовали себя узким местом вообще? Вы когда-нибудь волновались, что у вас будет всего пара часов на то, чтобы реализовать идеи других?

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

Что касается планирования, я исходил из приблизительного представления о том, где я хочу быть к 11 часам вечера или полуночи, и, к сожалению, не достиг этого, поэтому последние несколько часов превратились в безумную схватку. Я знал, что смогу построить большую часть внешнего интерфейса за 1–3 часа, если до него дойдет, так что это был только вопрос, смогу ли я реализовать более сложные аспекты дизайна (такие как пользовательские подписки и управляемый контент) модель общих тегов). Примерно в 3 часа ночи мне пришлось отказаться от некоторых из этих функций и сосредоточиться на основах.

Было бы хорошо, если бы у меня было двое — один исправлял ошибки и отвечал на отзывы команды, а другой должен был заряжать вперед, внедряя новые вещи. Я тайно завидовал Рексу, Дейву и Джеффу, потому что они, казалось, менялись местами и делили много обязанностей и решали технические проблемы в группе. С нашей командой разделение было намного более определенным. Хотя Томас — хакер из Perl старой школы и разбирается в технологиях, у него все время были заняты руки, и у нас не было общей возможности делегировать технические задачи или исправлять ошибки. Это действительно упало мне на плечи.

Большую часть времени я не мог позволить себе беспокоиться ни о чем, кроме конкретных вещей, связанных с дизайном. Это действительно было похоже на спортивное соревнование с точки зрения этого отношения — мы все работали так усердно, как могли. Хорошая вещь о нашей команде состояла в том, что, несмотря на относительно строгое разделение ролей, у всех нас был действительно сильный дизайн и удобство использования, поэтому мы все могли внести конструктивный вклад в концептуальную сторону вещей. Иногда, чтобы отдохнуть от своего кодирования, я ходил по комнате и рассказывал дизайнерам о том, что они делали, задавал вопросы и продолжал разговор. Мне повезло, что у меня была возможность работать с такими талантливыми и веселыми людьми, и я рада, что они полностью доверяют моему техническому решению. К сожалению, из-за необходимости заставить все это работать в коде, у меня было больше власти над общим результатом, чем мне бы хотелось. Я не хотел бы думать, что я являюсь узким местом — я бы скорее подумал, что у других были идеи, которые были слишком амбициозными, чтобы работать в течение 24 часов!

SP: Какие инструменты вы использовали в своей среде разработки, учитывая, что у вас было всего 24 часа? Управления источником? IDE? Удалось ли вам использовать какой-либо набор тестов? Миграция базы данных? Использовали ли вы какие-либо другие инструменты для обнаружения ошибок, которые могут появиться, когда вы лишены сна и строки кода начинают слиться в одну?

Я хотел использовать SVN, но было неясно, как управлять этим с остальной частью команды, которая использовала множество различных операционных систем и IDE. Ближе к концу у нас было несколько волнующих моментов, когда временные метки файлов начали плавать у меня на глазах и, казалось, двигались в направлении, противоположном обычному течению прошлого и будущего! А пара случайных файловых перезаписей шаблонов HTML означала исправление одних и тех же ошибок дважды. Это было страшно.

Изначально у меня был коварный план использовать ActiveRecord вне Rails и использовать возможности миграции Ruby, но в итоге все это делалось на PHP — фактически это была та же функциональность, но без явного управления версиями «вверх / вниз». Это было чрезвычайно продуктивно и означало
что я мог вносить различные эволюционные изменения в схему базы данных в течение дня, когда Зеф усовершенствовал информационную модель. Срыв идей Дамиана Конвея и Дэвида Хайнемайера Ханссона о плюрализации строк в моем фреймворковом коде также принес большую пользу.

Я настроил структуру модульного тестирования в начале дня, но в итоге написал всего несколько утверждений для тестирования среды Apache / PHP. К сожалению, некоторые из проблем, с которыми я столкнулся, вероятно, не помогут при модульном тестировании: такие как опечатки, которые не анализируют ошибки, случайный вызов неправильного метода — программирование 101, идиотские вещи. Трудные вещи, чтобы выследить, все же. Вы думаете, что если вы сделали что-то всего за две или три строки кода, ничто не могло пойти не так, но в действительности ничто не может быть дальше от истины. Я потратил гораздо больше времени на эти вопросы, чем на технические и дизайнерские проблемы, которые действительно разочаровали меня. Я исправил часть этого кода в течение нескольких недель после соревнования, и был поражен тем, насколько банальными были эти ошибки — и как быстро их исправить — но как невозможно было их увидеть в то время!

Хотелось бы, чтобы были инструменты, которые могли бы защитить нас от грубых ошибок сна. Модульное тестирование включает когнитивную нагрузку, которая может быть слишком высокой для подобных ситуаций. Я не могу придумать ничего, что могло бы помочь больше, кроме того, чтобы вообще не писать код (единственный надежный способ избежать ошибок).

SP: Что бы вы сделали по-другому, если бы вы снова участвовали в конкурсе?

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

Вероятно, главное — попытаться написать код в более медленном и более спокойном состоянии, надеясь избежать случайных опечаток. И обязательно используйте контроль версий. Я также попытался бы получить работающий прототип и запустить его в течение 6 часов или меньше, вместо того, чтобы ждать до середины ночи, чтобы отбросить всю инфраструктуру сайта. Кроме того, самое главное, я бы постарался больше сфокусироваться на камерах и аудитории и устроить для них гораздо лучшее шоу! К сожалению, я был в подавленном состоянии большую часть времени и не мог вникать в выходки столько, сколько хотел.

Если вам интересно узнать мнение других участников конкурса FullCodePress, прочитайте мое интервью с дизайнерами FullCodePress и менеджерами проектов .