• Уменьшение отступа

    Обратная связь

    (info@ru-sfera.pw)

На заметку Рутина программирования


X-Shar

:)
Администрация
Регистрация
03.06.2012
Сообщения
6 068
Репутация
8 176
krasivye-kartinki-den-programmista-humoraf-ru-31.jpg


Всем привет!

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

Очень часто приходится втыкать в чужой код, искать баги, писать тесты и т.д.

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

В общем сделаю копипаст статьи, в целом 100% согласен что написанно.)

Навеяно мыслями после прочтение замечательной .

Нет романтики​


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

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

И вот наступает тот день, когда мы выходим на работу. У нас появляются обязательства, дедлайны, бесконечные дейлики\митинги и прочие не очень приятные штуки. Приходит понимание, что код нам необходимо писать с 8 до 17, а не когда у нас для этого есть вдохновение. Много рабочего времени придётся тратить не на написание нового функционала, а на правку многочисленных багов, причём в чужом, а не своём коде. Да и работа не сказать, что слишком интересная, т.к. компания разрабатывает очередную CRM, игру, приложение для доставки или интернет магазин, которых в этом мире до нас уже был создан миллион.

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

Низкое качество продукта​

Бизнес достаточно абстрактная штука, но он всегда хочет делать всё быстрее, дешевле и с приемлемым уровнем качества.

Быстрее. Быстрее выпускать новые продукты, быстрее находить новых клиентов, быстрее исправлять свои недостатки, быстрее получать прибыль и т.д.

Дешевле. Дешевле приобретать сырьё и орудия труда, меньше платить за аренду, меньше платить сотрудникам за работу, меньше платить налогов и т.д.

Качество. Если это не выпуск люксовых товаров, то бизнесу не нужно высокое качество, если затраты на него будут достаточно велики. Бизнес вполне устроит средний уровень качества, который позволит продавать товар\услугу большому количеству клиентов. Бизнес не готов инвестировать много денег в качество, потому что часто сами клиенты не всегда готовы за это качество доплачивать. Между VPN сервисами за 8$/месяц и за 10$/месяц клиент чаще всего выберет тот, который дешевле. Между молоком за 85 руб. и 100 руб., покупатель скорее всего купит то, что дешевле.

Как мы пониманием, «Быстро», «Дёшево» и «Качественно» одновременно не бывает, поэтому бизнесу приходится выбирать лишь два из них. Требование «Быстро» остаётся всегда, поэтому под оптимизацию попадают требования «Дёшево» и «Качественно». Уровень качества опускается до минимально приемлемого, чтобы клиенты покупали и не сильно воротили носом от такого качества. Если процент отказов из-за качества будет большим, то тогда уровень качества будут поднимать за счёт увеличения конечной стоимости продукта.

Основной упор делается на «Дёшево». Нужен удобный офис с кабинетной системой, нормальной вентиляцией и мощными компьютерами? Дорого! Посадим всех разработчиков в большой open-space вместе с менеджерами по продажам, пусть они не только создают продукт, но и слушают все пожелания клиентов.

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

Необходимо тщательное тестирование продукта, что потребует найма нескольких тестировщиков? Дорого! Попросим самих разработчиков тестировать свой код, а те ошибки, что будут в продукте, для нас найдут первые его пользователи.

Для создания продукта нужен 1 год времени? Это слишком долго и дорого! У нас есть 6 месяцев, чтобы выпустить минимальный продукт (MVP), с которым начнут работать клиенты. Если продукт выстрелит, то деньги польются рекой, и мы тогда все с нуля перепишем, а пока поставь везде где нужно «костыли и подпорки».

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

Если текущий продукт не «выстрелил», то бизнес его быстро убивает и начинает тратить деньги на создание нового MVP-монстра из глины и палок.

P.S. Если хочется программировать для удовольствия, не беспокоиться о качестве разработки и вечных дедлайнах, то сделайте программирование своим хобби, а не превращайте его в работу.

Оригинал:
 
Верх Низ