Совместимо ли программирование и быстрое создание продуктов?

[Духовность™]

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

lurkmore

Давайте поговорим об отрасли.

Сейчас я работаю в компании (не It), где есть два проекта.

Один проект писал довольно опытный программер. ООП, MVC, Doctrine, единый стандарт кодирования и до блеска отшлифованный код. Я стараюсь писать так же. Мы делаем продукт, который вполне возможно будет реально поддерживать после нас. Делаем долго и вдумчиво.

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

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

Я конечно все понимаю, но есть все же вопрос морали - а как программисту ужиться в такой среде, когда 90% предложений на рынке - это должность "школоты", которая должна работать быстро, что безусловно сказывается на коде. Т.е. условия работы вынуждают тебя создавать некачественные продукты, фактически - заниматься делом, которое любой нормальный программист должен на генном уровне отторгать и презирать. Ведь это безумно скучные, серые рабские работы, сопоставимые разве что с должностью торговца китайским ширпотребом на "Черкизоне". Вам так не кажется?

 

[флоппик]

Либо ты создаешь качественный код, нацеленный на будущее, либо ты создаешь говно.

Что проецируется на самом деле в «мне потом с этим работать / с этим - работать уже не мне».
Понимаешь, кроме все тут гораздо сложнее и взаимосвязанней: Заказчик во-первых, не очень хорошо представляет реалии ИТ-рынка, да и сам ИТ-рынок(впрочем, опять таки, не только ИТ-рынок) на 70% состоит из «временных» людей, пришедших снять легких денег, во-вторых, поэтому Заказчик боится плохих партнеров (часто - не зря), которые могут внезапно исчезнуть, и по этому не хочет покупать продукт с его поддержкой (логично, что его пишут сравнительно качественно, потому что, см. выше, «мне потом с этим работать»), рыночный опыт в реальных отношениях ему подсказывает приобрести продукт, которым он сможет «обладать», «поставить на полку», «положить в сейф» считая, что может его продать за пол-цены как б/у, и все в таком духе, или закупает «студента» на должность исполнителя, пытаясь убить двух зайцев сразу — получить регулярную поддержку сайта, сэкономить на цене, и даже мечтает о третьем зайце (ну мы с этим продуктом можем даже сами на рынок выйти!)

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

 

[fixxxer]

Для каждого конкретного случая min(стоимость разработки + стоимость поддержки).

Все остальное программерская демагогия и ЧСВ

 

[zerkms]

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

Ты закрываешь глаза на то, что собственно твой выбор насчёт дистрибутива линукса - такое же точно решение: "Я выберу что попроще, потому что у меня времени нет". Как результат - все твои действия и решения в этом вопросе всегда будут такими же дилетантскими, как и у той конторы, попросту потому, что:
а) некогда изучать
б) некогда делать хорошо - ибо и так сойдёт



btw, начали напрягать постоянные отсылки местных постоянных посетителей на лурк. Неужели свои слова закончились?

ещё один непонятный мне тренд - использование термина ЧСВ к месту и не очень (http://phpclub.ru/talk/threads/С-какой-операционки-начать-изучение-nix-подобных-систем.66643/page-3#post-593978, http://phpclub.ru/talk/threads/Совместимо-ли-программирование-и-быстрое-создание-продуктов.66690/#post-593975). Люди, что с вами случилось? %)

 

[fixxxer]

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

 

[zerkms]

то, что вообще вряд ли потребует дальнейшей поддержки.

все всегда так говорят )))

 

[fixxxer]

Не, ну понятное дело, что нужен баланс.

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

 

[Духовность™]

твой выбор насчёт дистрибутива линукса - такое же точно решение: "Я выберу что попроще, потому что у меня времени нет"

zerkms вообще ни к месту сравнение.

btw, начали напрягать постоянные отсылки местных постоянных посетителей на лурк. Неужели свои слова закончились?

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

 

[Adelf]

это наше достояние и то, что сплачивает нацию.

))

Насчет вопроса - совместимо. Нужно в тот или иной момент всегда реализовывать лишь необходимый функционал, оставляя лазейки для рефакторинга(!). Не надо заглядывать на годы вперед. Это почти также вредно(в основном для кошелька владельца проекта) как и преждевременная оптимизация.

 

[craz]

IT России - это такое нечто...

Пока заказчик не поймет, что поддержка стоит дешевле, чем создание нового... так и будут клепать за место одного говна другое.

И если "в среднем по больнице температура" "3 000 за сайт + оптимизация в поисковиках + мы вам оближем ж", то о каком качестве кода говорить?

 

[whirlwind]

Быстро надо работать всегда. Разница в том, что проекты с небольшим количеством кода можно удержать в голове, а для большого количества кода нужно применять специальные подходы, что бы в последствии скорость разработки в среднем не сократилась. Отсюда простой вывод: все зависит от проекта.

 

[MildMildMint]

Не согласен. Говнокод писать не быстрее. Разница будет небольшая.

 

[Krishna]

Не согласен. Говнокод писать не быстрее. Разница будет небольшая.

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

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

 

[Raziel[SD]]

когда экономят на рефакторинге, вставляют костыли.

В одном проекте видел забавную картину: костыль исправляющий баг, порожденный костылем, который исправляет баг еще одного костыля