Совет по дизайну. Две модели для данных

[m_ax]

Давайте реализуйте мне за день программу сложности "я нихрена в этом не разбираюсь в первый раз вижу но делать надо". Я посмотрю на вашу архитектуру

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

[vbv]

1. Реализовать в модели слоты.
2. сделать центральное событие.
3. зацепить его на слоты моделей.
4. Вызывать центральное событие для обновления данных.

И не надо лохматить бабушку.

Вопрос был "как обновить" а не как построить архитектуру.

[Bepec]

Вот vbv и поставил жирную точку

Однако лохматить бабушку можно и продолжить, если у моделей имеется пункт "удалить запись", который должен быть своим у каждой модели

[vizir.vs]

1. Реализовать в модели слоты.
2. сделать центральное событие.
3. зацепить его на слоты моделей.
4. Вызывать центральное событие для обновления данных.

И не надо лохматить бабушку.

Вопрос был "как обновить" а не как построить архитектуру.

В модели уже есть слот. Называется refresh. Да и сигнал об изменении данных тоже модель имеет.

[Igors]

Если архитектура, как заметили выше, не совсем правильная, то как объединить эти две модели в одну, учитывая, что количество строк/столбцов разное?

Никак, да и не нужно их объединять, главное чтобы данные были одни и менялись синхронно.

В модели уже есть слот. Называется refresh. Да и сигнал об изменении данных тоже модель имеет.

Ну и нормально, тогда что Вас тревожит?

Давайте реализуйте мне за день программу сложности "я нихрена в этом не разбираюсь в первый раз вижу но делать надо". Я посмотрю на вашу архитектуру

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

Ну и чего Вы взъелись на совершенно безобидное высказывание? Один день или сколько - сроки всегда есть. Также правильно что какое-то более или менее глубокое понимание приходит где-то с версии 1.0, а до этого "ну вроде так правильно, а там посмотрим" - это нормально.

[Bepec]

to Max: такие "шарашки" называются форс мажор и работа в команде. Без них никуда. Особенно когда у человека случается что-то и он выпадает к чертям. А второго специалиста нет.

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

Время разработки = время изучения предмета + время написания альфы + поиск и изучение библиотек + переработка архитектуры + написание релиза.

В случае срочности формула будет выглядеть так
Время разработки = поиск и изучение библиотек + написание релиза(оно же альфы). И никуда вы от этого не уйдёте. Только в идеальных условиях есть время на изучение, пробы, тесты, написание альфы, бета версий программы.

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

PPS можете не верить, но такой "срочный" подход плодит больше шедевров, чем размеренная деятельность.

[vulko]

У нас повсюду такие шедевры, начиная от дорог и автомобилей...

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

Когда только начинал карьеру младшим sw developer'ом, был у меня в команде парень с небольшим опытом работы, что-то около двух лет, который отлично умел писать много много говно кода в день. А вся команда за ним фиксила это кривой код. Но он считал себя супер профи, бегал в комнату к архитекторам каждый день, но продолжал делать говно код.
Производительность по количеству строк кода у него была раза в 2-3 выше чем у других в команде, а вот качество его кода было как минимум в те же 2-3 раза ниже.

[Bepec]

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

А у специалистов высокого уровня на это просто не было времени. Вот просто у него неделя на разработку архитектуры, неделя на альфу+тестирование, неделя на бету + тестирование. При это остальные его проекты стоят.
А у новичка 2 дня на один проект. Это так называемое затыкание дыр.

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

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

[Old]

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

Да ладно. 

[Bepec]

Ага. Гораздо проще.
Но в противовес -  добавлять новый функционал сложнее.

[Old]

Ага. Гораздо проще.
Но в противовес -  добавлять новый функционал сложнее.

Так одноразовые проекты (сделал, отдал и забыл) никому не нужны. Нормальные проекты можно развивать... в отличие от...

[Bepec]

Представьте себе, сотни работников НИИ с вами не согласятся

Не знаю, мб в других областях программирования "одноразовые" и не нужны, но вот провести НИР без одноразовых не получится
И таки да - иногда на один НИР приходится по 2-4 "одноразовых проекта".

PS Научно-Исследовательская Работа.

[_OLEGator_]

Есть хорошая книга по этой теме.

Эдвард Йордон.
Путь камикадзе. Как разработчику программного обеспечения выжить в безнадежном проекте.

И да Верес, видимо, ярый представитель быдлокодеров, уж извините) иначе бы не оправдывался.

[Bepec]

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

PS не извиняю. Хамло вы редкостное. Ну оскорбляя других, вы выставляете себя хамом, так что увы.

PPS надо понимать точку зрения себя и собеседника. Вы же меня не понимаете. Вы отрицаете необходимость срочного написания программ, но куда вы от неё денетесь?

[vulko]

И самое главное достоинство того парня (говно кодера, по вашим словам) - что его проекты работали так как надо и за короткое время.

Как раз таки работали они не как надо, но в короткое время да.
Это очень кажущееся впечатление того что работает как надо. До первых тестов наговнокоженного.

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

Еще пример из личного опыта:
Может вам знакома такая библиотека как WebRTC. Это открытый говнокод от гугла. Жутко кривое. 2 года фиксили эту библиотеку для продукта, чтобы оно хоть как-то работало. Там весь набор, начиная от дедлоков, рейс кондишенов, огромного количества крешей и заканчивая ликами убивающими айфоны и айпады до состояния когда спасает только хард ресет.

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


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

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