MVC и разногласия на работе
afaik на такие случаи один из коллег назначается главным
Тимлида нету?
Действительно, весь код по факту можно запихать в один класс.но есть еще два ориентира - кол-во строк на метод, и кол-во методов на класс.
сколько здесь получается?
Это небольшой и интересный стартап, главных тут нет, кроме генерального директора. Его позицию см. выше. 
>но есть еще два ориентира - кол-во строк на метод, и кол-во методов на класс.
На что второй скажет что метрики для неудачников. =)
На что второй скажет что метрики для неудачников. =)
Пусть назначает главного, иначе имхо вы никуда не уедите.
но есть еще два ориентира - кол-во строк на метод, и кол-во методов на класс.Здесь получается, что услышав наши пререкания по поводу класса размером в 6000 строк, человек "разделил" его в один .h и несколько .cpp
сколько здесь получается?
Короче, программировать он не умеет и попал в команду только потому, что его не собеседовали программисты. Генеральный директор взял его самостоятельно. Теперь он сидит на довольно высокой для своего уровня зарплате и, вероятно, очень сильно этим гордится.В общем я думал, не существует ли каких-нибудь более убедительных аргументов в пользу использования ООП против allinone, потому что все аргументы в этих вопросах обычно достаточно прозрачны и абстрактны.
На что второй скажет что метрики для неудачников. =)но это единственный способ - перевести спор из теоретической плоскости: что лучше "пиво" или "водка"? в более практическую, что лучше: ящик водки или баттл пива?
Это небольшой и интересный стартап, главных тут нет, кроме генерального директора. Его позицию см. выше.поддерживаю ранее сказанное:
обязательно должен быть главный за техническую сторону, с которого можно спросить за результат в целом.
если гендир техническую сторону не тянет, значит надо выбрать кого-то из оставшихся, иначе будет лебедь, щука и рак в классическом варианте.
В общем я думал, не существует ли каких-нибудь более убедительных аргументов в пользу использования ООП против allinone, потому что все аргументы в этих вопросах обычно достаточно прозрачны и абстрактны.человек вменяемый или нет? т.е. он готов слушать аргументы или нет? готов быть лучше, или нет?
если вменяемый: то можно устроить что-то типа соревнования:
1. в каком коде быстрее добавляется функционал
2. в каком коде быстрее локализуется ошибка
3. в каком коде проще добавить поддержку несколько вариантов разного поведения(вывода, данных и т.д.)
если невменяемый, то надо капать на мозги гендира, что чел подлежить увольнению.
Понтяно. В общем, все варианты сводятся к тому, чтобы выбрать третье лицо. Я согласен, что это решение вполне подходящее.
Второй вопрос, нет ли каких-либо практических аргументов, которые могут выглядеть очень убедительными? Я понимаю, что вряд ли такие найдутся, учитывая профподготовку нашего мегакодера. И всё-таки?
Второй вопрос, нет ли каких-либо практических аргументов, которые могут выглядеть очень убедительными? Я понимаю, что вряд ли такие найдутся, учитывая профподготовку нашего мегакодера. И всё-таки?
я думаю, единственный, кто решит все ваши проблемы — это пианист. =)
1. в каком коде быстрее добавляется функционалК сожалению, всё это мы уже проходили. Не хочет он развиваться, то ли в силу своей упёртости, то ли просто потому, что не понимает, зачем и почему это нужно.
2. в каком коде быстрее локализуется ошибка
3. в каком коде проще добавить поддержку несколько вариантов разного поведения(вывода, данных и т.д.)
1. "Функционал быстрее добавляется в мой код, потому что я не могу разобраться, когда много классов, да и код становится непонятный".
2. См.1. А если речь заходит об интеграции, то "её нужно как можно меньше, чтобы можно было найти ответственного за ошибку".
3. "Когда нам это понадобится, тогда и будем что-то придумывать", а сейчас он уже накодил "то, что работает" и хоть трава не расти.
При чем тут тогда MVC, не понятно.
А ты сам-то уверен, что в вашем случае есть вообще смысл использовать шаблоны проектирования?
А то частенько бывает, что то, что можно сделать легко, делают "как положено" в ущерб простоте и функциональности. Шаблоны созданы для решения стандартных проблем. Есть ли у вас проблема, которую призван решить шаблон "Модель - представление - контроллер"?
А то частенько бывает, что то, что можно сделать легко, делают "как положено" в ущерб простоте и функциональности. Шаблоны созданы для решения стандартных проблем. Есть ли у вас проблема, которую призван решить шаблон "Модель - представление - контроллер"?
Есть ли у вас проблема, которую призван решить шаблон "Модель - представление - контроллер"?имхо, 6000 строчек в классе - это уже проблема.
Нет, это не та проблема, которую должен решать шаблон.
допустим, ты прав.
тогда какой ты ответ может предложить на вопрос: что делать с вьюхой на 6000 строк?
кроме ответа: ну, не знаю, надо в код смотреть.
тогда какой ты ответ может предложить на вопрос: что делать с вьюхой на 6000 строк?
кроме ответа: ну, не знаю, надо в код смотреть.
Погоди, давай по порядку
Если вьюха компилится и работает, то не надо ничего с ней делать.
А делать надо, когда возникнет проблема:
- новый работник не может среди этих 6000 строк найти то, что ему надо, и путается в коде
- в процессе интеграции требуется все эти 6000 строк перелопатить
- при небольшом изменении какого-то протокола из-за дублирования одного и того же кода изменения надо внести в десяток разных мест
Ну или какая-то другая похожая проблема возникнет. Вот тогда будет повод ткнуть носом незадачливого проектировщика в эту проблему и сказать "Ага, а вот если бы был MVC - то этой проблемы бы можно было избежать!" А ссылаться на длину кода - это ещё не аргумент.
Если вьюха компилится и работает, то не надо ничего с ней делать.
А делать надо, когда возникнет проблема:
- новый работник не может среди этих 6000 строк найти то, что ему надо, и путается в коде
- в процессе интеграции требуется все эти 6000 строк перелопатить
- при небольшом изменении какого-то протокола из-за дублирования одного и того же кода изменения надо внести в десяток разных мест
Ну или какая-то другая похожая проблема возникнет. Вот тогда будет повод ткнуть носом незадачливого проектировщика в эту проблему и сказать "Ага, а вот если бы был MVC - то этой проблемы бы можно было избежать!" А ссылаться на длину кода - это ещё не аргумент.
И вообще, я предлагал задуматься в первую очередь, для чего существует такой шаблон, как MVC?
Он существует для того, чтобы отделить бизнес-логику модели от представления и поведения. Если есть потребность для одной модели иметь несколько представлений (грубо говоря, интерфейсов или есть потребность через один интерфейс управлять несколькими разными моделями, подставляя соответствующие контроллеры, или если в будущем предполагается, что такая потребность может появиться - то тогда использование этого шаблона оправдано. Так что предлагаю топикстартеру задуматься прежде всего самому над тем, как объяснить необходимость использования этого шаблона, а то создаётся впечатление, что он знает, что MVC - это модно, но не представляет, где и зачем его использовать.
Он существует для того, чтобы отделить бизнес-логику модели от представления и поведения. Если есть потребность для одной модели иметь несколько представлений (грубо говоря, интерфейсов или есть потребность через один интерфейс управлять несколькими разными моделями, подставляя соответствующие контроллеры, или если в будущем предполагается, что такая потребность может появиться - то тогда использование этого шаблона оправдано. Так что предлагаю топикстартеру задуматься прежде всего самому над тем, как объяснить необходимость использования этого шаблона, а то создаётся впечатление, что он знает, что MVC - это модно, но не представляет, где и зачем его использовать.
>А ссылаться на длину кода - это ещё не аргумент.
Предлагаешь все проекты начинать писать в одном файле, и только в случае последующих проблем их переписывать?
Предлагаешь все проекты начинать писать в одном файле, и только в случае последующих проблем их переписывать?
Это чисто организационный вопрос. И решать его какими-либо техническими методами (подсчет количества строчек, классов или чего еще либо) это не вариант.
Как уже сказали, надо назначить одного человека главным, сказать, что он отвечает за успех мероприятия, а дальше как он скажет, так и будет.
Как уже сказали, надо назначить одного человека главным, сказать, что он отвечает за успех мероприятия, а дальше как он скажет, так и будет.
А делать надо, когда возникнет проблема:Практика и опыт моей работы показывает, что в классе M+V+C размером 6000 строк всегда возникает проблема. Особенно, если этот класс появился в проекте, которому 2 месяца.
Делать правильно надо не тогда, когда у тебя возникли очень серьёзные проблемы из-за ошибок проектирования, а сразу. Тогда этих проблем точно не возникнет.
>то тогда использование этого шаблона оправдано
А SRP значит для трусов?
А SRP значит для трусов?
А ссылаться на длину кода - это ещё не аргумент.+1
Всегда есть стандартные проблемы и стандартные решения для них и есть нестандартные проблемы (для стартапов более актуальны).
2 автор:
посмотри со стороны - ты тоже упертый и закованный в рамки шаблонов прогер, неспособный мыслить нестандартно. Твой подход хорошо использовать там, где нужно сделать "миллион" однотипных классов, прог, операций, etc. А подход человека, который смог в один клас запихнуть 6000 строк кода и оно работает - тоже достоин уважения.
ИМХО - если ты не можеш доступно аргументировать, почему твой метод лучше для конкретно этой задачи, а начинаешь приводить общие доводы (из рекламных текстов
) - то твой метод не нужен для этой задачи.Ну и разводить холивар ООП vs ПП из-за этого нестоит.
При чем тут тогда MVC, не понятно.Это одно из общепринятых ООП решений, конкретный случай, для которого можно было бы привести очень убедительные примеры. Дело в том, что я создал тему, когда возникли разногласия именно по поводу наличия или отсутствия контроллера.
Нет, я не предлагаю этого делать, не надо искажать мою мысль. Просто речь идёт о конкретном случае, в котором возникло непонимание между двумя программистами. И если один из программистов не может грамотно отстоять свою позицию, то возможная проблема заключается в недостатке аргументации вследствие недостаточно глубокого понимания собственной позиции. И своими "не надо ссылаться на длину кода" я лишь призываю упрочнить позицию, приведя более очевидные аргументы, чем "в файле на 6000 строк всегда возникнут проблемы", так как это ссылка на свой опыт, а для другого программиста твой опыт может не иметь какого-то значения, так как у него есть свой. противоположный, опыт.
Если вьюха компилится и работает, то не надо ничего с ней делать.очень спорное мнение, и я с ним категорически несогласен, т.к. такой подход провоцирует создание тысячи граблей, который бьют по самым неожиданным местам в самое неподходящее время.
телефон разрывает сотня пользователей, у которых легла система, а ты говоришь "Вася, ты не можешь найти ошибку? а я ж тебе говорил, что надо было делать MVC".
ты призываешь до такого доводить?
А ссылаться на длину кода - это ещё не аргумент.длинный код - это один из "ароматов" плохого кода.
и к таким ароматам надо принюхиваться и безжалостно искоренять, если нужен код, который легко поддерживать, а не код вида - "что-то написали, как-то работает, и может быть когда-нибудь найдется самоубийца, который попробует это поправить".
ИМХО - если ты не можеш доступно аргументировать, почему твой метод лучше для конкретно этой задачи, а начинаешь приводить общие доводы (из рекламных текстов ) - то твой метод не нужен для этой задачи.Я могу аргументировать, только у меня получаются достаточно абстрактные рассуждения, которые отметаются фразой "мне не понятно, зачем делать много классов, когда в одном всё работает". Один класс по возможности должен решать одну задачу, а ты в своём посте это опровергаешь. Код размером в 6000 строк работает непонятно. Сейчас нельзя сказать правильно или нет. И даже если через месяцы отладки этот код будет приведён в рабочее состояние, нельзя будет петь осанну тому, кто осилил такую работу. Это всё равно что слепить Венеру из засохшего гавна - вроде бы можно, только пахнет плохо. Все эти разговоры про ООП берутся не из воздуха.
А SRP значит для трусов?SRP - это ещё один аргумент, который стоит привести упёртому программисту. Но поможет это только в случае, если он признаёт авторитеты
2 автор:согласен
посмотри со стороны - ты тоже упертый и закованный в рамки шаблонов прогер, неспособный мыслить нестандартно. Твой подход хорошо использовать там, где нужно сделать "миллион" однотипных классов, прог, операций, etc. А подход человека, который смог в один клас запихнуть 6000 строк кода и оно работает - тоже достоин уважения.
ИМХО - если ты не можеш доступно аргументировать, почему твой метод лучше для конкретно этой задачи, а начинаешь приводить общие доводы (из рекламных текстов
Ну и разводить холивар ООП vs ПП из-за этого нестоит.
у меня были случаи когда я порил а потом понимал что подход противника не лишен смысла
а бы ли и такие случаи: когда назначали главным идиота, потом всем приходилось этот идиотизм писать
в результате проект загибался
некторые люди (я например) когда их заставляешь любимое дело делать неправильно либо отказываются это дело делать (мне вот рабочий в ванной отказался класть потолок как я захотел, пришлось другого искать) либо будут это делать через силу и как попало (назло)
Ещё раз: я не призываю оставить всё как есть, и в данном вопросе на стороне топкстартера, хотя бы потому, что я сам работаю системным архитектором и грамотное потроение систем - одна из моих задач. Я только хочу обратить внимание на то, как неубедительна аргументация сторонников MVC.
Частенько мне приходится выдерживать долгие споры с начальством по вопросу, стоит ли тратить дорогие человекочасы на рефакторинг некоторого плохо спроектированного legacy-кода, если всё и так работает, и обычно привожу аргументы, которые понятны второй стороне, так что они в итоге соглашаются. Поэтому я предлагаю топикстартеру найти такие аргументы, котоорые его убедят. Пусть это будет абстрактная оценка трудозатрат на какое-нибудь прогнозируемое изменение в коде, например, или что-то ещё, но не ссылка на неочевидное "так делать правильно".
Частенько мне приходится выдерживать долгие споры с начальством по вопросу, стоит ли тратить дорогие человекочасы на рефакторинг некоторого плохо спроектированного legacy-кода, если всё и так работает, и обычно привожу аргументы, которые понятны второй стороне, так что они в итоге соглашаются. Поэтому я предлагаю топикстартеру найти такие аргументы, котоорые его убедят. Пусть это будет абстрактная оценка трудозатрат на какое-нибудь прогнозируемое изменение в коде, например, или что-то ещё, но не ссылка на неочевидное "так делать правильно".
>6000 строк кода и оно работает - тоже достоин уважения.
И в чем именно состоит его достижение? Для написать 600 страниц бессвязного текста, не удосужившись разделить его на абзацы, главы и т.п. большого ума не надо, садись и пиши. Вот только что потом с этим текстом делать?
И в чем именно состоит его достижение? Для написать 600 страниц бессвязного текста, не удосужившись разделить его на абзацы, главы и т.п. большого ума не надо, садись и пиши. Вот только что потом с этим текстом делать?
некторые люди (я например) когда их заставляешь любимое дело делать неправильно либо отказываются это дело делать (мне вот рабочий в ванной отказался класть потолок как я хотел, пришлось другого искать) либо буду это делать через силу и как попало (назло)Этот момент так же является чуть ли не основным.
И в конечном счете именно он может привести к разорению стартапа.
Но в данной ситуации, я так понял, есть блат.
Поэтому имеет смысл все же либо переписать 6000 строк кода в понятный вид (хотя бы согласно общим стандартам) не доходя до крайностей вида "пара сотен пустых методов - пох, что ща пусто, потом допишем" и "несколько десяткой наследований, которые нах и не нужны".
Но в общем я бы посоветовал найти чела, который уже занимался разработкой архитектуры похожей системы и разбирается в возможных подводных камнях и делать так, как скаже он.
Т.е. третью сторону, как говорит автор.
Для написать 600 страниц бессвязного текстанекорректное сравнение. Ибо текст бессвязный, а код - рабочий.
И человек, который его пише является ченным кадром, особенно, если им правильно управлять. Например я думаю его бы без проблем взяли в какой-нить vkontakte.ru, где нужно что бы все работало просто и быстро, а не куча всякого хлама, который можно будет доработать и который работает по стандартам, но при этом уступает в 10 раз по производительности решению без ООП.
- новый работник не может среди этих 6000 строк найти то, что ему надо, и путается в кодеТогда будет уже поздно.
- в процессе интеграции требуется все эти 6000 строк перелопатить
- при небольшом изменении какого-то протокола из-за дублирования одного и того же кода изменения надо внести в десяток разных мест
Ещё забыл то, что вполне может понадобиться, чтобы в этом всём смогли разобраться другие люди. Тот который это написал и понимает что там к чему - не вечен.
но при этом уступает в 10 раз по производительности решению без ООП
Предвещается холивор
Так вот пока не поздно, нужно смоделировать ситуацию, что произойдёт, когда будет уже поздно Например, моделируем ситуацию "Интерфейс C++-программы надо сменить на веб-интерфейс" (ну или любую более подходящую под вашу специфику ситуацию оцениваем трудозатраты в человекочасах для внесения изменений третьим (не тобой и не вторым программером) человеком в код MVC и в код одним куском, переводим в рубли, идём к гендиру. Гендир видит, что на кону стоит реальное бабло, и принимает твою сторону И тут уже пусть второй программер оправдывается "Такого нам никогда не потребуется"
Например, моделируем ситуацию "Интерфейс C++-программы надо сменить на веб-интерфейс" (ну или любую более подходящую под вашу специфику ситуацию оцениваем трудозатраты в человекочасах для внесения изменений третьим (не тобой и не вторым программером) человеком в код MVC и в код одним куском, переводим в рубли, идём к гендиру. Гендир видит, что на кону стоит реальное бабло, и принимает твою сторону И тут уже пусть второй программер оправдывается "Такого нам никогда не потребуется" Тогда будет уже поздно.ну блин
идеального статического кода не существует
а уж о динамическом и речи не идет
под статическим подразумевается код под задачу которая в будущем не изменится
>Ибо текст бессвязный, а код - рабочий.
Ну допустим у текста тоже есть заголовок и аннотация, тоесть по сути то он тоже рабочий, вот только пользоваться (читай поддерживать) им невозможно.
Ну допустим у текста тоже есть заголовок и аннотация, тоесть по сути то он тоже рабочий, вот только пользоваться (читай поддерживать) им невозможно.
очень спорное мнение, и я с ним категорически несогласен, т.к. такой подход провоцирует создание тысячи граблей, который бьют по самым неожиданным местам в самое неподходящее времяимхо, ты выдрал фразу из контекста
я вот полностью согласен с йожиком
если перед тобой вьюха на 6000 строк и она тебе не приносит проблем (окромя экстетических) - не надо ее трогать
как только появятся проблемы, а лучше незадолго до появления проблем их предугадать - тогда и трогать ее
если ты с нуля вьюху пишешь, конечно лучше не писать ее на 6000 строк
но если она уже перед тобой и объективно не напрягает - не нада трогать
Это небольшой и интересный стартап, главных тут нет, кроме генерального директора. Его позицию см. выше.Ну решить как-то между собой, кто главный. Монетку бросить, на кулаках сразиться, члены измерить. И ещё, подозреваю, развиваться стартапу будет трудно, если директор не решает вопросы в своей компетенции.
Пусть это будет абстрактная оценка трудозатрат на какое-нибудь прогнозируемое изменение в коде, например, или что-то ещё, но не ссылка на неочевидное "так делать правильно".В этом топике я и прошу поделиться мыслями и аргументами. MVC подходит всегда, потому что практически любое ООП решение можно поворачивать и рефакторить как угодно. Приведу часть из разногласий, в которых мне не удалось найти взаимопонимания:
1. Создавать класс в одной функции, а затем "наполнять его содержимым" в другой. Класс - это view, который переключает табы. Причём функция наполнения реализована в вызывающем классе, и она виртуальная, чтобы наполнять класс разным содержимым в зависимости от типа вызывающего класса. Мне кажется, что со времён отмирания COM классы "наполняются" в конструкторах. Поэтому мой аргумент был в том, что для инициализации классов используются конструкторы (как по книжке а Си-стиль инициализации вносит непонимание в процесс создания объекта. Кроме того, очень тяжело понять, каким образом добавить ещё один таб в наше view. Человек отказался, сказав "я не понимаю, зачем городить столько классов".
2. Много view отображают некоторые данные определённой модели. Сейчас эти view связаны между собой через "главный" view, который переключает странички. Кроме того, эти же view содержат куски данных из модели, и эти же view обновляют одну модель. Таким образом, каждый view решает сразу три задачи. Главный view постоянно находится в памяти, независимо от того, отображается он или нет. Я пытался аргументировать тем, что при изменении view мы будем очень сильно завязаны на логику представления. Получил ответ "а я не вижу никаких проблем, а когда они будут, тогда и почешемся". Ещё разные view дублируют логику обновления модели. "Ну и что, там же всего 3-5 строчек кода". Человек просто не понимает, зачем это всё надо, он лучше будет сидеть и часами копаться в гавне и багах, которые в нормальном случае просто не появляются.
Гендир видит, что на кону стоит реальное бабло, и принимает твою сторонуПонимаешь, на стартапе гендиру бывает похрен на всё, если ему показывают гуйню, более-менее рабочий прототип. Беда в том, что не все программисты рефакторят прототип в нормальный код. Многие продолжают развивать прототип до продакшена. Это приводит к большим проблемам уже через год разработки. Конечно, в итоге прототип появляется на 1-2 месяца раньше, но конечный продукт - на 1.5-2 года позже. Увы, среди руководителей только единицы понимают, что на долгом проекте нужна выгода не здесь и сейчас.
А ты уже нарисовал диаграмму классов, чтобы было понятно, какие классы что делают и зачем они вообще нужны? А то я сталкивался уже с подобой проблемой, когда в погоне за идеалами ООП плодят десятки классов там, где они не нужны вообще. Какие-то ненужные классы-фабрики, классы-транзации, классы-контроллеры...
MVC - это общая концепция построения системы, а не концепция разбиения сущности на классы. И попытка оформить каждую сущность в виде трёх классов M-V-С приведёт к полной путанице, да.
MVC - это общая концепция построения системы, а не концепция разбиения сущности на классы. И попытка оформить каждую сущность в виде трёх классов M-V-С приведёт к полной путанице, да.
А ты уже нарисовал диаграмму классов, чтобы было понятно, какие классы что делают и зачем они вообще нужны? А то я сталкивался уже с подобой проблемой, когда в погоне за идеалами ООП плодят десятки классов там, где они не нужны вообще. Какие-то ненужные классы-фабрики, классы-транзации, классы-контроллеры...Это всё уже было сделано. Естественно, MVC - это не просто три класса. Выше я уже написал, что наш программист накодил, почему я с этим не согласен, и как я пытался аргументировать.
MVC - это общая концепция построения системы, а не концепция разбиения сущности на классы. И попытка оформить каждую сущность в виде трёх классов M-V-С приведёт к полной путанице, да.
MVC подходит всегда, потому что практически любое ООП решение можно поворачивать и рефакторить как угодно.Ну ну...
Вы хотите поговорить про это?
А по поводу аргументов - если чел не хочет менять свою точку зрения, то он ее не поменяет - парится бессмысленно. Пока работает то решение, которое он накодил, все паттерны будут ему до одного места.
MVC - это общая концепция построения системы, а не концепция разбиения сущности на классы. И попытка оформить каждую сущность в виде трёх классов M-V-С приведёт к полной путанице, да.Ну, вообще MVC можно применять на разных уровнях абстакции - от всей системы до отдельных виджетов, как, например, в Java Swing. Мое мнение - нужно останавливаться на уровне контейнеров - панелей, диалогов, меню. Иметь M-V-С для каждой кнопки и чек-бокса можно только в приложениях типа Калькулятор - иначе, да, будет полная путаница.
Понимаешь, на стартапе гендиру бывает похрен на всё, если ему показывают гуйню, более-менее рабочий прототип.Итак, твоя ситуация - ты делаешь красивый правильный код, но дольше; твой напарник генерит код по-быстрому, и код пока работает. В итоге напарник в шоколаде, так как он выполняет план быстрее, гендиру это нравится.
Тогда тебе стоит решить, ради чего ты работаешь. Если ради бабла - то тогда тоже генери код по-быстрому. Если тебе надо опираться на какую-то концепцию - возьми за основу Agile Software Development.
Если работаешь ради идеи, ради того, чтобы проект развивался успешно - то продавливай свою точку зрения, строй понятные диаграммы, описывай преимущества, делай это наглядно. Раз твой напарник не силён в ООП - помоги ему понять твою идеологию, но не словами "так будет правильно и быстро", а "так понятнее".
В крайнем случае наймите себе проектировщика, который будет делать это вместо тебя.
Ну а если ничего не поможет - разделите зоны ответственности, чётко оговорив интерфейсы взаимодействия ваших частей кода, и тогда для тебя его код будет "чёрным ящиком", что позволит тебе не париться по поводу того, как он написан.
Ну, вообще MVC можно применять на разных уровнях абстакции - от всей системы до отдельных виджетов, как, например, в Java Swing. Мое мнение - нужно останавливаться на уровне контейнеров - панелей, диалогов, меню. Иметь M-V-С для каждой кнопки и чек-бокса можно только в приложениях типа Калькулятор - иначе, да, будет полная путаница.Ну я GUI-приложения не разрабатываю, мне трудно судить, нужен ли MVC для чекбоксов
Итак, твоя ситуация - ты делаешь красивый правильный код, но дольше; твой напарник генерит код по-быстрому, и код пока работает. В итоге напарник в шоколаде, так как он выполняет план быстрее, гендиру это нравится.Если бы так. Кода я написал в три раза больше по кб, по задачам 2-1 в мою пользу. Проект сложный, поэтому хорошие ООП решения приводят к тому, что задачи решаются быстрее даже в рамках 2-3 месяцев работы.
Гендиру просто хочется побыстрее увидеть прототип. Этот чел давит на то, что в случае с большим количеством классов ему писать больше и дольше. Другие два разработчика почти полностью согласны с вещами, которые я предлагаю.
Что касается чёрных ящиков. Мне кажется, что отсутствие более глубокой интеграции в таких проектах, особенно на этапе старта, тоже приводят к проблемам.
Что касается чёрных ящиков. Мне кажется, что отсутствие более глубокой интеграции в таких проектах, особенно на этапе старта, тоже приводят к проблемам.Конечно приведёт
Но если зоны ответственности разделены, то проблемы прежде всего возникнут у автора "чёрного ящика". И это станет аргументом против его точки зрения, либо вообще аргументом за его увольнение.Кстати, если есть ещё два программера, которые с тобой согласны - то зачем вы вообще убеждаете этого чудика? Собрали совещание, большинством голосов выработали точку зрения, кто не согласен - тот будет уволен за саботаж
Конечно приведёт Но если зоны ответственности разделены, то проблемы прежде всего возникнут у автора "чёрного ящика". И это станет аргументом против его точки зрения, либо вообще аргументом за его увольнение.Было бы всё так просто. Многие люди, несмотря на свою грамотность, довольно похуистичны. Они видят, что переубедить нельзя и что гендиру похер. Поэтому не парясь предлагают написать два view, которые переключают табы.
Кстати, если есть ещё два программера, которые с тобой согласны - то зачем вы вообще убеждаете этого чудика? Собрали совещание, большинством голосов выработали точку зрения, кто не согласен - тот будет уволен за саботаж
Просто чтобы не париться.Тогда предлагаю поступить мудрее - сделать эти два "view", хрен бы с ним, раз уж это быстрее, но при первом удобном случае провести рефакторинг. Это будет как раз в стиле Agile Software Development.
Беда в том, что опять же из опыта своей работы я знаю, что подобные вещи не рефакторятся годами. До тех пор, пока всех окончательно не заебут. У нас на прошлом проекте был вроде бы грамотный мужик, но он не умел программировать. В итоге класс на 10к строк, который два программиста переделали перед релизом просто потому, что уже не могли пофиксить все баги. В буквальном смысле исправление одного бага приводило к появлению 1-2 других.
Ладно, я пошёл поговорить с гендиром. Чувствую, что всё закончится двумя одинаковыми (внешне) классами.
У нас на прошлом проекте был вроде бы грамотный мужик, но он не умел программировать. В итоге класс на 10к строк, который два программиста переделали перед релизом просто потому, что уже не могли пофиксить все баги. В буквальном смысле исправление одного бага приводило к появлению 1-2 других.Ладно, я пошёл поговорить с гендиром. Чувствую, что всё закончится двумя одинаковыми (внешне) классами.
MVC - это общая концепция построения системы, а не концепция разбиения сущности на классы. И попытка оформить каждую сущность в виде трёх классов M-V-С приведёт к полной путанице, да.это только фанатики каждую логическую херотень оформляют в виде отдельного класса.
имхо, не из таких.
соответственно это подразумевает, что в ряде случае - использование шаблона mvc - может выглядить как user control с длинным конструктором - но в котором:
первый абзац - это model,
второй - view,
третий - контроллер.
обычно это уже достаточно, чтобы код был читабелен, и легко поддавался дальнейшим изменениям
Оставить комментарий
kokoc88
Что бы вы сделали, если бы все аргументы в пользу MVC ваш коллега парировал размазыванием контроллера и модели по view и утверждением "меня не прёт, когда много классов"; а начальство при этом занимало бы пассивную позицию "свои проблемы решайте сами"?Ведь если подумать, то переубедить человека практически невозможно ("не учи меня программировать"). Действительно, весь код по факту можно запихать в один класс. С некоторой точки зрения это просто железная аргументация.