Отправляет email-рассылки с помощью сервиса Sendsay

Как стать программистом и избежать детских ошибок

Рассылка закрыта

При закрытии подписчики были переданы в рассылку "Работа в сети Интернет" на которую и рекомендуем вам подписаться.

Вы можете найти рассылки сходной тематики в Каталоге рассылок.

←   Август 2010   →
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
Автор
Павел Корягин

Статистика

730 подписчиков
-1 за неделю
←   Все выпуски   →

Как стать программистом и избежать детских ошибок Своё или готовое?


Здравствуйте, дорогой читатель. Один из читателей блога поднял вопрос выбора инструмента: брать готовое или делать своё.

Для себя я нашёл ответ, и сейчас поделюсь им с Вами. Вот моя история, начиная с одного момента. С того, что я стал глядеть на мир не только, как программист, но и как менеджер (тот, который управленец, а не продавец).

Случай первый, довод коммерческий

После открытия Веб-студии у нас встал вопрос выбора CMS. Для нас было очевидно, что лучше взять готовое, поскольку задача сделать сайт казалась нам предельно типовой. Да и не ради процесса, а ради бизнеса мы всё это затевали.

Бесплатное

Выбрали самое популярное на тот момент: Mambo-Joomla. И даже сделали на этом два сайта при помощи фрилансеров, потратив невероятные усилия.

Оказалось, что не все CMS одинаково полезны. Джумла рассчитана на то, что любой пользователь может поставить и настроить себе портал без программирования. Этот плюс и оказался для нас самым ресурсоёмким минусом.

Дело в том, что задача унификации достигается в Джумле довольно сложной комбинацией настроек и жёстких стандартов.

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

Столкнувшись с реальными проблемами (а предвидеть их, согласитесь, было невозможно), мы продолжили свой поиск.

Хорошее

Нашли. UMI-CMS. Идеально вписывалась в тот рабочий процесс, который мы в состоянии были наладить.

Окончательное

Но она платная. Поэтому возник резонный вопрос: а почему бы её собственно не повторить? Прикинули — оказалось жутко выгодно. В дальнейшем жизнь подтвердила наши прикидки: повторить оказалось действительно быстро (заодно улучшили), а копий мы использовали штук 30 и до сих пор мой бывший компаньон продолжает это делать.

В данном случае довод был коммерческий.

Что ещё нужно знать для полноты картины

Тогда в моё поле зрения не попали фреймворки. Да и не нужны они были по названным мной критериям: проект CMS был маленьким и обозримым. К тому же сегодня в подобной ситуации я бы выбрал WordPress или Drupal. Но тогда они тоже прошли мимо.

Как быть с тем, что подходящее решение (Drupal в нашем случае) не попадает в поле зрения, когда оно нужно? Ответ прост: не грузиться.

Да, конечно, потом найдутся «умные» наблюдатели, ворчащие на тему велосипедостроения. Однако надо помнить — люди задним умом крепки. Поиск готового продукта — это тоже само по себе ресурсоёмкая задача, поэтому время на неё также приходится ограничивать. И то обстоятельство, что где-то существует подходящее для Вас решение (а ещё люди, которые бы на Вашем месте его выбрали), решительно ничего не меняет, если Вы этого решения не знаете.

И вариант «опросить всех» здесь не работает. Джумлу-то мы выбрали по рекомендациям!

Вариант «спросить того, чьи советы ранее пригождались» — да, имеет шансы на успех. Либо у Вас образ мысли совпадает и опыт можно перенимать; либо человек уже эксперт и может предсказать Ваше будущее по Вашей задаче.

Случай второй, довод технологический

На Хабре я видел комментарий к очередному фреймворку (цитата не дословная): «Вы его публикуете, потому что уже сделали CMS и её архитектура Вам очень понравилась, или потому что ни один из существующих фреймворков Вас не устраивает?»

На этом можно и закончить, но я всё же проговорю выводы:

  • Если Вам нравится разрабатывать архитектуру — это ещё не достаточный довод для подобной работы. Хотя! Этот опыт может быть бесценным, так что если у Вас вагон времени — вперёд, действуйте по наитию. Потом окупится. Но вот для текущего проекта это опасно: уже при внедрении зароетесь в деталях, о которых пока даже не подозреваете.
  • Если Вам нравится сложившаяся архитектура какой-то из ранее сделанных программ, то стоит крепко подумать в следующих случаях (пока не вложены силы в новую документацию):
    • публикация системы,
    • старт нового проекта с новой (или расширенной) командой.
  • Если никто ещё не пытался реализовать Ваши текущие идеи, то пробуйте. Проведёте фундаментальные исследования. Потом и нам расскажете. Помните о возможной неудаче, но не бойтесь и не избегайте её: исследуйте честно.

Мой опыт: есть свой фреймворк, позволяющий творить кое-что волшебное. Но для проектов, требующих вовлечения нескольких программистов, я склоняюсь к выбору хорошо известных (Zend/Symfony/CakePHP). Однако и небольших проектов за время существования собственного изделия было немало, так что сам он уже обкатан. Теперь маячит на горизонте долгоиграющая задача, где я рискну попробовать и своё изделие.

И если Вам знакомо слово «диалектика», то колебания, описанные в предыдущем абзаце — она самая.

Система развивается, проходя через состояния, выглядящие противоположными друг другу: «Использую А; нет, плохо, теперь только Б; нет, теперь то хорошо, зато другое плохо, беру опять А, но с заимствованием из Б,...». В каждом состоянии накапливается информация, необходимая для следующего шага, но не очевидная ранее.

Мелочи жизни

Зато часто приходится принимать решения, что делать с готовыми компонентами.

  • Если компонент сложный и работает приемлемо, то я его запаковываю в функцию, совместимую с архитектурой фреймворка. Пример: функции определения браузера на стороне PHP — тестировать дорого, ошибки не критичны.
    Кстати, PHP-программисты, знаете функцию get_browser()? А она там как бы есть. Но редко работает. Зато через её документацию можно выйти на очень приятное решение.
  • Если компонент работает с ошибками, то я его либо исправляю, либо беру его код за основу алгоритма и в том же файле переписываю по уму. Пример: отдача файлов с докачкой. Около десяти строк кода, но в Сети куча примеров с ошибками.
  • Если компонент по логике своей тесно интегрируется с фреймворком, то я предпочитаю его переписать. Пример: отправка почты. Она должна брать реквизиты из параметров программы, и поддерживать доступ к шаблонам. Но упаковку вложений и кириллицы в заголовках намного быстрее сдуть, потом сверившись со стандартом, чем наоборот: начинать разбираться с чтения стандартов.

Но самое главное, решая атомарную задачу, нужно во-первых замечать, что она атомарная, а во-вторых иметь проявляющийся в таких случаях зуд: «наверное, её кто-то уже решил, пойти бы мне, поискать».

Success stories для готового

И на сладкое. Я использую:

  • WordPress без доработки, либо с плагинами для блогов,
  • SMF без доработки для форумов (там, кстати, API есть для написания мостов к CMS и куча готовых мостов, чтобы списки пользователей были общими),
  • jQuery с плагинами или ExtJS с компонентами для разработки на JavaScript,

и горя с ними всеми не знаю. И вам желаю найти свой набор для счастья.

Этот выпуск Вы можете прокомментировать в Живом Журнале.

Задать вопрос

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