Pull to refresh
43
0

User

Одно из ключевых преимуществ MVC в том, что V и C можно при желании безболезненно отрезать и использовать только M. Или наоборот — подменить одно M на другое без необходимости что-то менять в V и C. Как в вашем «этом, скорее, логическом разделении на три группы. Например, функций-членов.» провернуть вышеописанное?
Тетрадь? Фи, мон ами, в наш просвещённый цифровой век это дурной тон :)
> Мой опыт показал: проще реализовать всю кухню внутри одного класса, чем искусственно делить на некие абстракции, которые к тому же слишком сильно связаны, что грозит адскими интерфейсами

Пример: я хочу использовать вашу систему объектов с её, судя по описаниям, невероятно сложной алгоритмической нагрузкой. Но с небольшим отличием: я хочу разместить ваш код на сервере приложений и дёргать его через веб. Вопрос: зачем мне впились ваши Button и ComboBox в классах бизнес-логики?
О сумме в $3000 вообще трудно говорить как о заработке для компании — даже если стоимость работ по проекту была меньше…
Ну, мне кажется, в данном смысле он тоже может быть применён только к цитате…
> (лицензии компании «КировЧерМет», sic!)

FYI, «sic» означает, что приведённая цитата написана именно так. Например, если в цитате опечатка, то можно добавить sic, указав, что опечатка — не ваша. «sic» не имеет никакой эмоциональной окраски.
> Начиная с Java 5 ключевое слово volatile имеет еще одно очень важное значение.

Я читал, что с введением этого свойства volatile по производительности стали практически как обычные блокировки. Вы не подскажете, так ли это?
> Пароль получается так — base64(md5('фраза')). Фраза берется длинная — цитата какого-нибудь известного мыслителя (Кант, Гегель, Шопенгауэр, Ницше, Маркс, Хайдеггер — да кто угодно), которую вы помните НАИЗУСТЬ (со всеми знаками препинания)

мне непонятно, это такой тонкий троллинг? :-\
Я так понял, Вы субконтрактор. Сколько людей в Вашей организации (не в той, с которой Вы работаете, а именно в Вашей)? Соблюдается ли КЗОТ?
> Если вы не можете прототип использовать в качестве готового кода, значит вы что-то делаете не так.

Неправильно проектируете архитектуру? ;)
Опять какие-то сферические кони в вакууме. Это называется musturbation — говорить о том, какой ситуация должна быть, игнорируя реальность. Кто выгонит человека, если он делает свою работу — пусть и не так хорошо, как мог бы сделать специалист высокого класса? Заметьте, я говорю о больших конторах, а не о мелких, где человека могут запросто пнуть на мороз и всё.
У меня был печальный опыт с прототипированием. Однажды я начал делать внутренний проект с прототипа. Но так получилось, что вместо того, чтобы отложить прототип и начать делать реальную систему, фичи начали накатывать прямо на прототип. Это было неприятно. Впрочем, там во многом я сам был виноват. Вообще в таких случаях нужно чётко оговаривать, что это прототип и что в продакшн будет идти совсем другое и его ещё надо разработать. Ибо начальник может не понять и сказать — хуле, вы ж уже разработали, чо вам ещё надо. И сунет ваш прототип в продакшн.
Вы как-то смешиваете заказчика и документацию по архитектуре. Интересно было бы услышать Ваши аргументы, почему документация по архитектуре не работает?
«Документация не нужна. Ваш код — лучшая документация» — это сверическая ситуация в вакууме. В реальности же есть, во-первых, недобросовестные разработчики, которые считают, что лучше, извините, нах*ячить, чем выискать хорошую, самодокументирующую структуру кода и данных. Во-вторых, в любой системе со временем появляются различные неочевидные вещи, которые просто обязаны быть документированны. Ибо смотришь, например, на некоторый алгоритм расчёта, и думаешь — like, WTF? O_O
> Поощряйте читателей на точку зрения

какой-то рунглиш
Мне кажется, что это могут себе позволить немногие компании: либо небольшие софтверно-ориентированные конторы, либо софтверные конторы, где этот механизм поставлен на поток. В большинстве же компаний IT — непрофильный ресурс, и для бухгалтерии проще повесить их на фиксированную ставку. Может, у вас другие соображения?
Отложив в сторону сарказм, исходя из чего Вы тогда предложите рассчитывать зарплату работника?
Так мне непонятно, Вы предлагает пару недель ковыряний оценить как 2-3 часа рабочего времени, или 2-3 часа рабочего времени оценить как пару недель ковыряний? :)
> Да какая разница когда сотрудники приходят и уходят. Система «отсиживания» должна умереть. Главное о чем должны заботиться руководители — это об эффективности труда, а не о времени, которое сотрудник провел в офисе.

Вы в плане — «мне пофигу когда ты сегодня уйдёшь из офиса, но чтобы завтра всё было готово»?

Information

Rating
Does not participate
Location
Мариуполь, Донецкая обл., Украина
Date of birth
Registered
Activity