Немного о web-разработке

В сфере разработки я начинал как контент-менеджер. В стародавние времена разработка админки была дорогим удовольствием и я просто вставлял и форматировал голый html в dreamweaver-е. За год 10000 страниц. Мне платили 5000р. в месяц. Картинки на иконки я тоже резал вручную.
Как-то раз мне нужно было выложить Библию, но с нашим дизайном. У меня была кипа файлов - около 1000. Довольно средний php-программист сделал это за полчаса.

Автоматизация делает использование ресурсов эффективнее. Но чаще сделать что-то руками гораздо быстрее, чем автоматизировать.

Потом я пять лет занимался эникейством. В простонародии - компьютерщик, сисадмин. Параллельно от нечего делать изучил freebsd, linux и немного seo-продвижение. Максимум, что я мог в то время в веб-разработке, это сделать редизайн сайта и реализовать трехуровневое меню на css. Но уже этого было достаточно, чтобы начать клепать сайты на Wordpress и Joomla. Drupal я не осилил. И все это параллельно системному администрированию, которое было основной моей деятельностью. В обед, по вечерам, в выходные, я занимался вебом. Мне просто было интересно. Верхом достижения на этом этапе был плагин платежного шлюза для оплаты картой в Magento.

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

Одной из идей была школа веб-разработки. Я готовил отдельные занятия и параллельно систематизировал свои знания и заполнял terra incognita новой информацией. Гугл стал в этом незаменимым помощником, а повсеместное развитие мобильного интернета привело меня в адаптивную верстку и SPA, а через это - к Javascript-разработке.

Следите за трендами, но не увлекайтесь ими. Умение извлекать из модных и красивых технологий действительно стоящие и надежные - очень важный навык.

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

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

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

Любой владелец бизнеса старается снизить затраты на разработку, поскольку это очень ценный и дефицитный ресурс. А снизить затраты можно только как следует проработав требования и огранизовав процессы.

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

Стив Макконнелл: "Управления сложностью должно стать основным постулатом профессиональной разработки ПО".

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

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

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

Нет ничего постоянней временного решения.

Яндекс.Метрика