Префиксы-суффиксы. Как лучше? Стоит ли избавляться от них?

[fed]

А вообще - есть такое пародоксальное суждение: Если вы не можете разобраться в коде программы без документации, то вам и документация не поможет
Суждение конечно слишком сильное и провокационное, но я слишком часто при внедрениях Аксапты видел последствия подходов к документированию, позаимствованных на проектах по разработке тиражного софта. То есть - в начале проекта все документируем, префиксы, лейблы,бест-практис и тп. Потом манагер проекта вдруг видит что через 2 месяца запуск а сделано процентов 30 доработок, и начинает стимулировать разработчиков ипатьевским методом. В результате - процентов 30 проекта написано и задокументировано как по книжкам, а оставшиеся 70 процентов - написано как пьяная мартышка левой нижней рукой. Хотя с самого начала можно было не тратить столько времени на все эти методологии разработки "как в книжке", а просто попытаться написать не очень криво, зато почти весь код на одинаковом уровне.

Так что - конечно все рассуждения из серии "Может быть полезным при апгрейде/поддержке и тп" - они в принципе правильные. Действительно может быть полезным. Но гораздо интереснее будет сравнить денежную полезность с денежными затратами на ведение префиксов/суффиксов/лейблов и тп...

[mifi]

Цитата:

Сообщение от fed

А вообще - есть такое пародоксальное суждение: Если вы не можете разобраться в коде программы без документации, то вам и документация не поможет
Суждение конечно слишком сильное и провокационное, но я слишком часто при внедрениях Аксапты видел последствия подходов к документированию, позаимствованных на проектах по разработке тиражного софта. То есть - в начале проекта все документируем, префиксы, лейблы,бест-практис и тп. Потом манагер проекта вдруг видит что через 2 месяца запуск а сделано процентов 30 доработок, и начинает стимулировать разработчиков ипатьевским методом. В результате - процентов 30 проекта написано и задокументировано как по книжкам, а оставшиеся 70 процентов - написано как пьяная мартышка левой нижней рукой. Хотя с самого начала можно было не тратить столько времени на все эти методологии разработки "как в книжке", а просто попытаться написать не очень криво, зато почти весь код на одинаковом уровне.

Так что - конечно все рассуждения из серии "Может быть полезным при апгрейде/поддержке и тп" - они в принципе правильные. Действительно может быть полезным. Но гораздо интереснее будет сравнить денежную полезность с денежными затратами на ведение префиксов/суффиксов/лейблов и тп...

Не надо мешать все в одну кучу - "все документируем" - это одно, а следование стандартам разработки - совсем другое. Никогда не сталкивался с тем, что следование стандартам разработки замедляло проект. Разработчик\ПМ, который этим пытается оправдывать задержки сроков- не профессионал. Либо еще, либо вообще.

[fed]

Цитата:

Сообщение от mifi

Не надо мешать все в одну кучу - "все документируем" - это одно, а следование стандартам разработки - совсем другое. Никогда не сталкивался с тем, что следование стандартам разработки замедляло проект. Разработчик\ПМ, который этим пытается оправдывать задержки сроков- не профессионал. Либо еще, либо вообще.

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

[mifi]

Цитата:

Сообщение от fed

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

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

[kornix]

Цитата:

Сообщение от fed

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

Вот тут полностью соглашусь. Причем как правило приходиться учитывать мнение таких PM И начинается поиск баланса и споры В принципе если осознанно писать код, соблюдая основные правила BP, и строить свои доработки так чтобы самому все было четко и прозрачно (именования и т.п.) - следующие поколения должны тоже разобраться, и без документации к коду

[EVGL]

Цитата:

Сообщение от kornix

Причем как правило приходиться учитывать мнение таких PM

PM не всегда виноват: иногда сам клиент предьявляет абсурдные требования к документации да еще и готов платить за это.

[AlexSD]

Цитата:

Сообщение от EVGL

PM не всегда виноват: иногда сам клиент предьявляет абсурдные требования к документации да еще и готов платить за это.

А разработчику компенсируют "моральные страдания" по выполнению "абсурдных требований" из этих денег?

[kornix]

Цитата:

Сообщение от AlexSD

А разработчику компенсируют "моральные страдания" по выполнению "абсурдных требований" из этих денег?

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