-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Где грань между гибкостью кода и скоростью разработки?
- Автор темы varan
- Дата начала
triumvirat
не правда. самый говнокодистый говнокод, пишется более-менее продвинутыми разработчиками, когда они ошибаются с архитектурой и делают код заумным и загибким.
во время быстрой разработки можно жертвовать функционалом, а качеством не получится, потому что код обязан быть рабочим.
не правда. самый говнокодистый говнокод, пишется более-менее продвинутыми разработчиками, когда они ошибаются с архитектурой и делают код заумным и загибким.
во время быстрой разработки можно жертвовать функционалом, а качеством не получится, потому что код обязан быть рабочим.
Alexandre
PHPПенсионер
а почему не попробовать сразу писать не говнокод?
хотели как лучше - а получилось как всегда...
кодирование - это как подчерк второклассника.
кто-то пишет красиво, кто-то коряво, хотя написаны одни и теже слова . Если ты начинаешь писать быстрее - это еще не значить, что коряво... и если ты писал всегда коряво, и если станешь писать медленне -не значить будет красиво...
делайте вывод, Юноша.
PS я не могу похвастаться чистотой кодирования... но я стараюсь разглядеть свои ошибки и их не повторять.
"потом" наступает всегда... я не говорю про поддержку...просто когда проект уже завершен и забыт, со временем должно стать стыдно, если другой программист будет исполнять роль ассенизатора и занть автора этого хозяйства... (ах как мы иногда с гордостью любим ставить авторство в комментах...)
atv
Новичок
По мере проведения рефакторинга, рука, что называется, набивается, и при дальнейшем программировании код сразу получается более качественным.
Не стоит забывать, что затраты на освоение технологий программирования, это единоразовые затраты. Сначала, естественно, будет медленнее чем у других, работающих "по старинке". Но потом, постепенно скорость будет увеличиваться, причём не в ущерб качеству.
Так получилось, что в разных проектах, в которых я участвовал, использовались разные фрэймворки. Некоторые члены команды не стремились глубже разобраться с ними, и лепили код как попало. Я же не жалел времени, чтобы разобраться с фичами, и потом значительно ускорял время своей работы. В коде использовались стандартные решения фрэймворка и код был легко читаем и понимаем. Точно также и с технологиями программирования. Только единоразовые затраты времени больше.
Естественно, что не все технологии дают экономический эффект на проектах любого уровня. И в каждом конкретном проекте нужно оценивать экономический эффект от внедрения той или иной технологии.
Не стоит забывать, что затраты на освоение технологий программирования, это единоразовые затраты. Сначала, естественно, будет медленнее чем у других, работающих "по старинке". Но потом, постепенно скорость будет увеличиваться, причём не в ущерб качеству.
Так получилось, что в разных проектах, в которых я участвовал, использовались разные фрэймворки. Некоторые члены команды не стремились глубже разобраться с ними, и лепили код как попало. Я же не жалел времени, чтобы разобраться с фичами, и потом значительно ускорял время своей работы. В коде использовались стандартные решения фрэймворка и код был легко читаем и понимаем. Точно также и с технологиями программирования. Только единоразовые затраты времени больше.
Естественно, что не все технологии дают экономический эффект на проектах любого уровня. И в каждом конкретном проекте нужно оценивать экономический эффект от внедрения той или иной технологии.
Lightning
Трудоголик
ТС смешивает понятия гибкости и качества? Лишняя гибкость в коде действительно не нужна. А вот на качестве сэкономить практически нельзя. Говнокод может быть эффективным только в краткосрочных проектах. В остальных случаях действует "закон контроля качества ПО". Собственно, это все уже обсуждалось и много книг по этому поводу написано.
Если все врачи будут эдакими докторхаусами, лечащими по одному пациенту в неделю, то да - все эти мысли правильные. Но нет такого. Они там за день ставят стока диагнозов, что по барабану каким почерком они будут написаны. Аналогия с программистами кстати вполне явная.
varan
Б̈́̈̽ͮͣ̈Л̩̲̮̻̤̹͓ДͦЖ̯̙̭̥̑͆А͇̠̱͓͇̾ͨД͙͈̰̳͈͛ͅ
Не знаю... Имхо гибкость - одна из двух составляющих качества. (Вторая составляющая - понятность). Могу ошибаться...
Согласен. Но надо учитывать, что таких проектов - тьма тьмущая.
1) Множество проектов на начальном этапе рассматриваются, как проекты с коротким сроком, потому что надо быстро начать зарабатывать бабло, чтобы тупо не прогореть.
2) Как говорили выше, сайты на заказ - та же фигня. За качество кода денег не дают, увы.
В остатке остаются только крупные проекты, которые уже перешли некий период первоначального хаоса. Вот там качество на первом плане.
В общем, я всё это к тому, что чтобы быть действительно эффективным, всегда надо решать главную проблему бизнеса, и сверхкачественный код, бывает, противоречит ей. Утрированно говоря, если вам нужно сделать небольшой интернет-магазинчик для ИП "Пупкин", и вы его пишете через TDD, постоянно рефакторя, с шаблонизатором, с подробными комментариями и красивой документацией к коду, то вы будете удовлетворены как программист, но наносите финансовый удар по фирме, потому что за это время дешевый говнокодер сделал бы 1,5 - 2 таких магазина, намешав php с хэтээмэлем и эскуэлем.
У любой теории есть граничные условия ее применения.
-~{}~ 10.09.09 12:48:
Частично соглашусь. Если делать работу без "дзена", то мотивация снижается, что может опять-таки сказаться на производительности труда
Alexandre
PHPПенсионер
опять приведу цитату (вольное трактование) из "Факты и заблуждения..."
это первый факт : "первоночально на освоение ногвой технологии необходимо время, которое окупится в дальнейшем. Не надо ждать серебрянной пули от применения инноваций в первом проекте"...
хорошее замечание есть у Фаулера "где нужен и где не нужен Рефакторинг"...
все уже высказано до нас, люди на этом собаку съели еще пять-десять лет назад. А мы - все наступаем на новые грабли.
Lightning
Трудоголик
varan
Если говорить об эффективной разработке, то эффективен итерационный подход. Т.е., как уже писали выше и как писал ты сам, быстро разрабатывается работающее приложение с минимальным функционалом, а потом расширяется, дописывается, модифицируется. А расширять и модифицировать качественный код ДЕШЕВЛЕ чем знаменитый говнокод. Вот и получаем выгоду, как для бизнесмена так и для программиста. Потому что выгоднее нанять 3-х хороших программистов, чем 10 говнокодеров, даже если платить программистам в 3 раза больше чем говнокодерам.
![Raziel[SD]](https://secure.gravatar.com/avatar/5bcf62e34d3825c80884f57d341fad2a?s=96){kind=avatar}
Raziel[SD]
untitled00
На тему говнокода: поставил задачу пофиксить нотайс ... казалось бы что может быть проще, но после исправления нотайса появилось 3 новых 
задачу выполняли почти год и закончилось это практически полным переписыванием того функционала. Вот так бывает "дешевле" сделать потом нормально
задачу выполняли почти год и закончилось это практически полным переписыванием того функционала. Вот так бывает "дешевле" сделать потом нормально