Гавно.

1. Логику нужно выносить в модель
2. Магическому числу 257 место на свалке
3. Конвертация дат без учета культуры
4. Convert.ToDateTime("01.12.2012") - зло, ибо: new DateTime(2012, 12, 1)

P.S. Подписываю бегунок, уволен.

sphinx_mvRejected...
Использование модели в элементарных случаях - есть зло и говнокод! Фтопку!
Использование модели для представления в любых случаях - хорошая практика и правильный подход. Неучам и бездарям не понять, что такое лапшекод. Во-вторых, у него код не окончен, следовательно, там можешь быть та еще лапша.
sphinx_mvRejected - Insufficient data to make a decision
Too little experience to date of such statements.

sphinx_mvПофиг!
Если тебе "пофиг" на код, его сопровождение и рефакторинг - я развожу руками. Продолжай писать гавно, я не против.

sphinx_mvЛюбая работающая "лапша с дерьмом" от "чайника" лучше, чем неработающий код от гуру программирования.
Непонятно, к чему этот вброс. С чего это код от гуру программирования неработающий?

sphinx_mvСначала нужно "сделать" ("шоб работало"). Потом "сделать правильно". И только потом "сделать лучше" - если(!) понадобится.
Глупости сивой кобылы - только неопытный гавнокодер среднего пошиба может так говорить. Нужно изначально писать хорошо и правильно, впоследствии такой код проще сопровождать, рефакторить и развивать. Допиливать же опосля гавно напильником, да и еще по нескольку раз - результат плачевный. Хотел бы, чтоб строительные архитекторы и инженеры новостройки для твоей будущей квартиры придерживались такого правила?

sphinx_mvOh, yes! We see your "ultimate experience" when you try to make an important decision without any information at all.
You're a stupid shitmonkey. It's a fact.

vahsphinx_mv
Полностью ВАС поддерживаю!
Гавнокодеры нашли друг дружку

Для таких как вы оба статья: Про абстрагирование, слабосвязную архитектуру и проектирование в целом

vahsphinx_mv
Полностью ВАС поддерживаю!
Кстати, наводящий вопрос - зачем тогда сабж запостил?

vahDenis.Да не, код действительно плохой
если бы я в этом сомневался - сюда б не писал
я знал сколько помоев выльется на мою голову
И, тем не менее, ты написал. Значит, в душе что-то коробило? :)

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

sphinx_mvМнение никаких "говно-орхетекторов" совершенно не интересует заказчиков с их изменяющимиси требованиями со сроками "надо вчера".
Особенно при таком хаосе, как у тебя, невероятно вреден принцип разработки "лишь бы работало". Хаос на хаос даёт в результате армагедон.

sphinx_mvИ очень хочется надеяться (хотя надежда крайне слаба), что Вы вообще имеете представление, что такое рефакторинг и по каким причинам имеет смысл хотя бы просто задумываться, чтобы его делать.
Для начала я хотел бы поинтересоваться, чем невероятен и незыблем этот рефакторинг, чтобы о нем задумываться или не задумываться как о нечто совершенном? В силу своего скромного опыта, ты не осознаешь, что это настолько банальная и стандартная процедура, что о ней не то, что задумываться, а думать вредно.

sphinx_mvВы, естественно, "совершенно не в курсе", почему так бывает? Ну, что ж... И так тоже бывает...
Обычно таких как ты кнопко-кидателей с минимальными знаниями процесса разработки выбрасывают на свалку за ненужностью. И так тоже бывает.

sphinx_mvЛарчик-то просто открывается: элементарно "не успел" из-за соблюдения требований "самых правильных" методик или строго следования "необузданому полету фантазии" слабо вменяемого "орхетектора"
Факапить и топить команду по срокам будет немыслящий подопытный кролик, который не понимает того, что от него хотят. Маломальски соображающая codemonkey сделает всё более или менее красиво - особенно это зачется немного позже. Да и о каких таких задержках по срокам можно говорить - банальный лапшекод в обработчиках нормальные люди раскидывают, хотя бы, в процедурно-ориентированный скоуп, который позже можно легко оторвать из прикладной машанины и распихать по моделям и сервисам. Но ты еще не дорос до того, чтобы это понимать и работать в таких режимах. Пока жуй бананы, о технике потом поговорим.

sphinx_mvУ-у-у-у, как всен запушшено!
Тут Вам самому бы еще опыта поднабираться... Хотя ламерам это не грозит...
Аргументами убил наповал.

sphinx_mvВо-первых, приводить в пример строительство - БРЕД (мягко сказано). В нем, как минимум, совервершенно другие принципы регулирования деятельности! И Вы о них "не в курсе"...
Банальный скромный соскок. Хотя, очень интересно - расскажи про эти принципы регулирования деятельности, набрал попкорна и приготовился.

sphinx_mvВо-вторых (хотя, по-хорошему, должно бы быть "во-первых"), только клинический идиот считает, что для программы представляет какую-то важносто то, КАК она НАПИСАНА, а не то КАК она РАБОТАЕТ!
И то и другое тесно взаимосвязано. Не может некачественно построенный дом на болоте простоять и не свалиться. Хотел бы ты в таких системах хранить свои сбережения на счетах и оперировать переводами? А хотел бы ты летать на самолетах с таким ПО для летчиков?

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

sphinx_mvЕсли затраты на "правильное проектирование" многократно превышают стоимость многократного переписывания (хотя бы из-за изменившихся требований к ПО) - объективно вылетите в трубу раньше, чем Ваша "нетленка" увидит свет... И многократное переписывание "хорошего кода" этому только способствует - можете пытаться опровергать сколько влезет.
А с чего это ты решил, что затраты на "правильное проектирование" многократно что-то должны превышать? Или ты записался в гадалки на кофейной гуще? Правильное проектирование ничего не может привышать, особенно если грамотно закладываться на сроки с рисками. Умный управленец на хороший фундамент затратит дополнительно 10% времени, а в последующем многократно выйграет в разы. Тупой унылый талпайоп, у которого в башке только одна мысль - отжать бабла прямо здесь и сейчас, не думая о партнерских отношениях и долгосрочном сотрудничестве - не будет думать о доп. затратах на старте. Он будет мыслить линейно, в результате сам задохнется в своих зловониях. Ты предлагаешь путь унылого талпайопа, мне жаль тех заказчиков.

sphinx_mvМанифест "правильной" разработки - читать тут ...
Вот-вот, вначале говорится о тезисной выжимке опыта подхода к стартапам. Гавно понаписать и захлебнуться. Автор - идиот, который переврал итерации Agile разработки как написать, переписать, еще раз переписать. Продакт менеджер тебя кастрирует за такие "итерации".

sphinx_mvСамая верная методология разработки программного обеспечения - тут ...
Про критерии "плохого дизайна" - читать здесь ....
Самая верная методология разработки - это Agile подход с техническим соблюдений всех рекомендаций: http://msdn.microsoft.com/en-us/library/ff650706.aspx а не то гавно, которое предлагаешь ты.

sphinx_mvWarning! Bug in your DNA detected! Please contact with developers for get latest updates and necessary maintenance.
Danger! At the time of writing programs, it is discovered that the whole team - chatty codemonkeys.

Где-то в степиНикто не спорит что программист это сплав интеллекта и опыта ( программист - в первую очередь интеллектуал, а уж потом пьяная скотина), и понятие "Прально" это относительность на основе этих двух качеств.
Конечно писать надо изначально правильно, про этапность о которой вы говорите это просто манера письма - у каждого своя.
У русских есть хорошая поговорка:"Делай хорошо, а говно само получится"
Если ее переложить на IT то как бы 'Пиши изначально прально, а что исправлять и улучшить всегда найдем..'
Так что не убедили, давайте ещё..
Программист ничего не решает, решает архитектор и тимлид. Всё остальное - кисло.

Где-то в степибесспорный аргумент, но плох тот п-т, кто не задумывается об архитектуре.
Ну как видишь, sphinx_mv не задумывается об архитектуре и даже более - вредит ей.

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

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

ЕвгенийВВсе это ложиться дополнительными абстрактными слоями, польза от которых мягко говоря спорна. На один слой накладывается второй, на него третий, для обхода возникших трудностей создается четвертый, для возможности использования которого создается новая прогрессивная методология разработки.
См. выше. При хорошей команде (в первую очередь нужен хороший аналитический склад ума, способный покорить предметику) никаких наложений не возникает.

ЕвгенийВА нужно то было всего лишь взять поступившую на вход дату и сравнить ее с неким значением.
Ну ты уж совсем утрируешь, такое ощущение, что на горе-программиста одиночку скинули пласт неподъемных задач, которые нужно поставить в срок - вот он, как уж, начал писать пласт за пластом. Как правило, такие проекты обречены.

sphinx_mvА вот Вы просто попытайтесь рассмотреть ситуацию, когда на крупном предприятии есть собственный отдел программных разработок... И в качестве "заказчика" выступает не какой-то посторонний "Вася Пупкин" из фирмы "Рога и Копыта", а непосредственно один из отделов предприятия, в котором для обеспечения очень конкретных производственных процессов крайне необходим определенный функционал.
Уж тем более для своей компании писать "чтоб работало" не резонно. Как правило в таких компаниях более вменяемые сроки и лояльное руководство. Есть воля где можно архитектурно разгуляться.

sphinx_mvНекоторое время в таких условиях, конечно, можно помурыжить "вот ту мы техзадание готовим", а "вот тут мы архитектуру модуля продумываем", "а сейчас мы пишем идеальный код" и все такое прочее...
А никто и не говорит, что нужно тянуть кота за яйца и что-то там мурыжить. Даже получив задачу с пинка можно её грамотно разложить по полочкам на колене без технических заданий и функциональных спецификаций. Главное, понимать предметную область и разбираться в производственных процессах.

sphinx_mvПисать "правильно" - это, конечно, круто... Осталось только определить КАК это делать
Начнем с того, чтобы хотя бы не писать унылый лапшекод в обработчиках с логикой.

sphinx_mv1) Для своей компании нужно писать так, чтобы она в трубу не вылетела. Есть понимание, что делает и как работает конкретный участок кода? Если да - "ну, и фиг с ним" (с).
2) Лояльность руководства имеет границы.
3) Архитектурно разгуливаться можно только если нет других задач... И только когда есть четкое представление о том, что нужно изменить, на что это повлияет и как это вообще можно сделать при имеющихся ресурсах...
1) Я боюсь, что при всех отрицательных раскладах, не компания в трубу вылетит, а кучка гавнокодеров-идиотов.
2) Всё в мире гранично, речь не об этом. Я говорю о лояльности по сравнению с интеграторами и консалтинговыми конторами.
3) Заложив нормальный архитектурный фундамент и потратив на него минимум времени всегда можно к нему вернуться и по-человечески продолжить работу, вместо того, чтобы наваять какашку и ходить пускать слюну о том, что мы весть крутые и справляемся в сроки.

sphinx_mvЭто все замечательные соображения. Только не имеющие никакого отношения к тому, получился в итоге лашекод или нет... Особенно - с учетом отсутствия "стандарного" представление о лапшекоде. Кому-то нравится, кто-то плюется...
Единственный объективный критерий - выполнение (или нет) некоторым кодом некоторой функции. Все остальное - лирика.
А итога тут еще не усматривается, лапшекод в твоем случае пишется изначально. Как правило, в окончательном выхлопе качества так и не будет - всё это фантастические сказки деда Римуса про терновый куст. В который уже лишний раз не полезешь, проще вкорячить подпорку и жить дальше.

sphinx_mvЕсли "лапшекод в обработчиках с логикой" - достаточно эффективное решение, чтобы выполнить поставленную задачу, то имеено его и следует применить. Потом - если будет наобходимость, желание и ресурсы - код можно улучшить. Но можно и не улучшать.
"Кристальный код" не панацея. А рефакторинг - не самоцель.
"Лапшекод в обработчиках с логикой" априори не может быьт достаточно эффективным решением, без вариантов. Особо много времени не потратишь, если хоты бы в процедурно ориентированном стиле решить эту же задачу. Зато потом отвязать этот шматок уныния будет на порядки проще и быстрее, чем заново всё переписывать. Приходилось работать с такими программами из нескольких тысяч строк в обработчиках, это полный пецдец - это результат твоего направления.

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

ЕвгенийВНапример многие системы автоматизации предприятий пляшут от организационной структуры, но я ни разу не видел таковую, которая была бы реализована как надо. Обычно тупое дерево и все у них хорошо.
"Как надо" - весьма сомнительный критерий. Я говорю о том, что писать изначально нужно хорошо. Я не требую от тебя невероятного.

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

ЕвгенийВВ большинстве случаев ему дается указание архитектором(тим лидом) нагромоздить таких то классов, применить такие то паттерны и сделать за такое то время. В результате получается нечто, работающее не совсем так как надо и не так быстро, как хотелось бы.
Не вижу прямой зависимости, почему это получается нечто неправильно работающее?

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