Оver-engineering - "зачем так сложно?"

[ax_mct]

Dech, мне тяжело написать 2000 строк даже если я очень захочу.
Речь о существующем коде.
И об отношении к коду.
Для меня 2000 строк это не говнокод, а просто код.
Не хуже и не лучше чем если бы был разбит на части.

Да, тот же settleNow() примерно такой длины, но я не уверен что от деления этой логики на множество методов, или не дай бой иерархии классов, станет легче. Скорее всего будет шило на мыло.

Проблема то именно в фанатичном использовании ООП вообще и не свойственного для Аксапты ООП в частности.
Вот это нетерпимость к "неправильному" коду и есть одна из причин over-engineering.
Если код делает то что от него требуется, включая возможность его поддержки и расширения, то он не может быть неправильным. При условии конечно соблюдения Best Practices для АХ, но никак не "общепринятого программирования".

Уважай культуру места где находишься вот и все. Если 2000 строк в данной культуре - ОК, и более того работает и работает, то не трогай. Не считай себя более одаренным чем те программисты которые подняли этот продукт.
Уважай то что работает какое бы грязное оно не было. Рабочее оно как раз всегда грязное.

[macklakov]

Цитата:

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

тот же settleNow() примерно такой длины

settleNow() сам по себе результат "программизма". Объединить accounts receivable и account payable в одну и иерархию, мог только человек который ни дня не провел в этих отделах, зато много в коде ковырялся и увидел в этих процессах некоторую корреляцию. Но это реально 2 совершенно разных отдела! И работают они по совершенно разным бизнесс-процессам. Поэтому вся эта CustVend иерархия создает больше проблем, чем пользы.
Т.е. "программизма" хватает и в "старой доброй" axapta. И от него надо было избавляться. Это учетная система, она должна отражать реальность, а не продвигать идеализм в массы.

[Ace of Database]

Цитата:

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

settleNow() сам по себе результат "программизма". Объединить accounts receivable и account payable в одну и иерархию, мог только человек который ни дня не провел в этих отделах, зато много в коде ковырялся и увидел в этих процессах некоторую корреляцию. Но это реально 2 совершенно разных отдела! И работают они по совершенно разным бизнесс-процессам. Поэтому вся эта CustVend иерархия создает больше проблем, чем пользы.
Т.е. "программизма" хватает и в "старой доброй" axapta. И от него надо было избавляться. Это учетная система, она должна отражать реальность, а не продвигать идеализм в массы.

А я часто копи-пастю джобы, меняю в них Cust на Vend, Sales на Purch - и работает! Это как раз хороший, добрый программизм.

[macklakov]

Цитата:

Сообщение от Ace of Database

А я часто копи-пастю джобы, меняю в них Cust на Vend, Sales на Purch - и работает! Это как раз хороший, добрый программизм.

Самому не стыдно? Твой код приходится менять. Почему сразу не продумал все варианты? Ведь у тебя же есть иерархия. Мог бы объявить объект класса-родителя, инициировать конкретного наследника через factory, исходя из параметров. Ну и потом почему поленился, нормально, через SysOperation, делать? Ведь это гораздо более универсальный механизм чем jobs.

Цитата:

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

Я не против дублирования в принципе, просто оно должно быть обосновано.

А я не против "серьезных" программстских подходов. Паттерны, абстракции, обощения и т.д. Просто оно должно быть обосновано

[belugin]

Цитата:

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

Почему сразу не продумал все варианты?

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

[macklakov]

Цитата:

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

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

Это в жизни у них общего мало. А в системе очень даже много. Ведь с точки зрения системы это лишь отражения счетов в ГК. А у всех счетов ГК много общего друг с другом. У них есть дебет, кредит и балланс.
Девочки операционистки зачастую слишком необразованны чтобы оценить величие и изящество замысла. Когда им звонит клиент, он ожидают видеть баланс клиента, а не баланс на счету AR. И поэтому им каждый раз приходится долго втолковывать что инвойс делает счет клиента положительным, а платеж делает этот счет отрицательным. И все равно путаются какое-то время.
Да что говорить. Процесс закупки настолько отличается от клиентского возврата, что целый модуль procurement and sourcing наваяли. И одобрения платежей. На закупках часто бывает 3-х уровневое одобрение, а возврат клиенту делается на месте. Но при возврате важен исходный платеж. А в оплате покупки такого платежа не было вовсе.
Зато мы не какие-то там быдлокодеры, которые под клиента подстраиваются. У нас наследование и фреймворки. Все как у взрослых

[belugin]

Цитата:

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

Ведь с точки зрения системы это лишь отражения счетов в ГК. А у всех счетов ГК много общего друг с другом.

То есть есть что-то общее и есть кокретное подразделение, которому нужно это общее, правильно?

Цитата:

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

То что есть различия, тоже понятно

Так вы на вопрос не ответили, как возникла вообще потребность сделать одно и то же для двух вещей, между которыми НИЧЕГО общего.

[ax_mct]

Цитата:

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

settleNow() сам по себе результат "программизма". Объединить accounts receivable и account payable в одну и иерархию, мог только человек который ни дня не провел в этих отделах, зато много в коде ковырялся и увидел в этих процессах некоторую корреляцию. Но это реально 2 совершенно разных отдела! И работают они по совершенно разным бизнесс-процессам. Поэтому вся эта CustVend иерархия создает больше проблем, чем пользы.
Т.е. "программизма" хватает и в "старой доброй" axapta. И от него надо было избавляться. Это учетная система, она должна отражать реальность, а не продвигать идеализм в массы.

CustVend иерархия это хороший пример теория vs практика.
Обоюдоострый топор - прекрасная идея, но нам им лес валить.

Действительно если бы вместо settleNow() было два метода было бы легче.
И то что было бы повторение кода в этих двух методах - и слава яйцам в разных корзинах.

А главное мое "салон vs двигатель" слишком лиричное, а твое Это учетная система, она должна отражать реальность - понятнее.

P.S. Отражать реальность без искажений и членовредительства. Если в реальной жизни это два отдела то не нужно отражать то чего нет. Код учетной системы не должен жить своей внутренней жизнью и оптимизироваться сам по себе. Код - должен только отражать реальность. Когда программист меняет код по сути для своего удобства и ради своих принципов - он тот самый крот.

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