По пункту 1. Утверждение не верное и не неверное. Всё зависит от того, как Вы это воспринимаете. Если в Вашей семье было принято всегда извиняться, родителей на вы называть и т.д., то Вы никак не воспринимаете прямоту.
По пункту 2. То же самое. Культурные отличия — это не более, чем автоматические действия. Конечно, если в Японии принято, то это просто принято.
Такие семьи, имхо, ужасны. В моей семье принято просить прощения, говорить спасибо, соблюдать этикет, быть вежливым друг с другом, и вообще делать очень много вещей, которые Фромм, кажется, называл взаимными поглаживаниями.
Не ужасны. Такие же самые. Искренность отношений говорит о взаимопонимании и взаимоуважении по умолчанию. И эти качества не требуют постоянных подтверждений словами.
Мне кажется, Вы в одну кучу сливаете прямое общение, критику без перехода на личности (т.е. «Вася, код твой ужасен, поправь» vs «Вася, ты дебил, поэтому код говно»), и хамство (это когда человек переходит границы личного и на личности: «у твоей жены маловат размер груди»). Это всё разные вещи. Критика полезна. И полезно ее учиться воспринимать спокойно, не оскорбляясь. Также полезно уметь критиковать, пусть и матом даже, но не переходя на личности, отделяя человека от его работы или каких-то мелких недостатков. У всех недостатки. Но критиковать надо недостатки (не человека), потому что это полезно для развития. Для быстрой реакции на проблему, улучшения качества работы.
Какая больше способствует производительности — «Вася, посмотри пожалуйста, у тебя в этой функции что-то странное происходит» и «Эй, Вася, слышь, ты чо за говно тут понаписал»?
Смотря какие отношения между Васей и Петей. Если они друзья, то еще не то могут друг другу сказать и никто не обидится. Бывает и «Глянь, Вася, какое я говно написал ))».
Нет, гопники, кажется, это другое. Но в общем, говорить можно и не словами «говно» а как угодно. Но если Вы знаете о проблеме и еще знаете где, то можно и пальцем тыкнуть, а не заувалированно боясь оскорбить говорить «Вася, у тебя (предположительно, извини, извини), в классе где-то есть ошибка».
2. Странное раздражение. Это же просто стиль общения — главное, как относятся. Где-то было (в даосизме?), что вежливость и этикет возникают там, где есть лицемерие. В семье не просят извинений, потому что отношения искренние и понятно, что специально на ногу никто не наступал.
Специальная наглость и хамство — тоже неприятно. Но прямота, по моему, способствует лучшей производительности. Вот, в нашей культуре, видишь, что код «говно», то как это сказать? Завуалированно? Так и 10 лет пройдет, а человек будет думать, что его код пахнет. Критика и самокритика — вещи хорошие. Главное, не переходить на личности и не воспринимать за оскорбления.
Как культурное отличие Европы, Японии или американцев — это я могу понять. Не могу понять, как может так раздражать наша, вроде неплохая вещь. Ну да, есть хамы, которые просто так хамы, которые всегда пересекают границу личного пространства.
Это опасное заблуждение, что автомобиль едет. В большинстве случаев. Лучше перебдеть. По умолчанию желательно считать, что если происходит что-либо неожиданное — контроль над программой утерян и она находится в несогласованном состоянии. Поэтому ее работа должна приравниваться к неработе. Причем, дальнейшая ее работа опаснее неработы, т.к. способствует «скрыванию» проблемы и увеличению убытков.
Природа бага такова, что вы, пока не создав тесты, стабильно его повторяющие, не нашли код и не исправили — причину бага не знаете. Не зная причины, вы никак не можете оценить важность бага и его урон.
Еще, в поддержку того, что лучше упасть — хотя гарантии отсутствия багов не будет никогда, если нормально написан код, покрыт тестами, багов на самом деле не очень много. Поэтому чем жестче программа реагирует на «неожиданное поведение», тем быстрее эти баги отловятся. Возможно даже до продакта.
Только в крайне редких случаях можно так делать — ехать дальше. Не хочется о них и напоминать. Бывает, что у вас приложение для какой-то сферы деятельности, а на ГУИ появляются непонятные артефакты или что-то несущественное не прорисовывается. Или действительно обрабатываете данные с мусором и это ожидаемое поведение, и вы логируете предупреждения. Т.е. очень иногда так можно поступать. К сожалению, многие это «иногда» возводят в абсолют.
Я работал в компании, которая писала ПО для работы с людьми и их деньгами.
Увидел один раз код, который копипастом распространился везде: если по какой-то «счастливой» случайности не нашли клиента по айди — брался первый попавшийся. Снимались деньги или начислялся долг. Вот как надо начальства бояться )))
Возможно такого никогда не произошло. Но заботливый программист это заложил. И коду не один год…
Выживаемость программы — прямо противоположная вещь надежности в большинстве случаев.
Еще нравится, как люди пишут кругом, не задумываясь:
if (a != null)
{
a.DoSomething();
}
И даже средства улучшения кода в полуавтоматическом режиме такие вещи делают. Ну, вы поняли…
Что-то не понимаю, почему силверлайт так все хоронят? Хорошая штука для программирования? Хорошая. Позволяет быстро создавать приложения, качественные и надежные? Да. Не хтмл и не джаваскрипт все же.
Если побеждает по каким-то причинам html5 и он умеет всё, что умеет силверлайт, но он лучше в плане «не нужно плагина» или «не нужно грузить долго» — то это все равно не причина переходить на эти вещи. Главное то в нашей профессии — скорость кодирования и надежность, а не всякие непрограммерские аргументы. Поэтому, если html5 лучше по каким-то космическим причинам, не программерским, то легко напишут транслятор в html5.
Ассемблер может тоже круче. Но главное — удобство кодирования. Потому что вот написали — то что на силвере делается за день, на html5 делается за неделю. Хотите в 5-7 раз меньше зарплату?
Вы неверно поняли мою фразу. Это при прочих равных условиях. Если взять двух человек и оба не имели опыта работы, но один показывает что-то сделанное, а второй уверенные знания — то второй лучше.
Всё верно — книги без практики — пустая трата времени. Но и не надо из этого делать противоположности — либо практика, либо книги. Книга, а за ней практика наиболее быстрый способ получить глубокие знания. Просто потому, что любую книгу прочитаете за неделю/две. А практика нарабатывается дольше. Так удлинять себе путь и учиться на своих ошибках? В конце концов, если захотите стать профи в теме, то Вам рано или поздно придется прочитать книги, чтобы не было упущенных знаний. Так что оптимально начать с книги.
Повторю — это мнение основано на ЧСВ. Нет разделения на теорию и практику. Но много людей, не имеющих мозгов, пытаются себя причислить к практикам. Это такой общественный стереотип — если человек знает хорошо науки, математику и т.п., то он в жизни глупее, забывает зонтик, теряет очки и т.д. Причем много людей как раз не осваивают никаких теорий, просто потому, что либо ленивы, либо не дано — но зато себя потом причисляют к умельцам не все руки — противоположность тем, кто все таки что-то изучил. И таких людей больше. Особенно много в бизнесе. Естественно, они поддерживают такой миф. Один раз я удивился, когда вроде опытный программист, на математическом проекте, смеялся с тех, кто знает как взять интеграл. Т.е. считал, что те, кто берут интеграл — немного недоумки. Смешно, правда?
Книги без практики — пустая трата времени. И если программист читает книги по темам, которые не применяет в повседневной работе, но еще и не закрепляет практикой материал — то это выглядит странно — тема ему не интересна. Как можно изучать новую технологию или язык, но при этом не захотеть попробовать это в деле?
Лучше брать человека, который только книгу прочитал, и всё?
При всех равных — да. Если это уже «состоявшийся» инженер, как написано в посте, и просто изучил новую технологию или язык по книге — то очевидно, он будет состоявшегося инженера, прочитавшего статью какую-то или пошаговое руководство и попробовавшего сделать какой-нибудь примитив.
Если сравнивать двух человек без опыта, то тоже, видимо, хорошо знающий книги по предмету вызывает больше уважения, чем тот, кто поверхностно только что-то видел и попробовал.
Книги не достаточны. Нужно иметь опыт. Это значит — и попробовать самому и еще лучше — поработать в коллективе, кто в этих вещах опытный.
Но книги — самый надежный вариант быстро войти в тему. Хорошая книга дает всю базу, все необходимые знания, кроме нюансов, кроме практики. И если кто-нибудь хочет с чем-то работать, то лучше сразу изучить книгу, потом уже пробовать. Второй шаг тоже обязательный. Без начального изучения материала, человек пробуя, строит нечто несуразное, создает велосипеды, не знает даже, в каком направлении двигаться. Допускает много ошибок и даже не знает, что их можно не допускать. Поэтому — сначала база, потом практика — наиболее быстрый метод.
И еще, чтение любой книги гораздо меньше времени займет, чем обретение практики. Только лень и высокое ЧСВ заставляют людей думать, что они и без книг умные. А по времени на самом деле выгоднее прочитать книгу.
Я встречал «программистов», которые утверждают, что книги им не нужны и они никогда не читают. Не все такие и программистами становятся, только любят в околопрограммисткой тусовке находиться. Те, которые программисты, если можно так назвать, имеют крайне поверхностные знания, пишут код плохо, любят больше говорить. Это тип такой людей, которые путают ум и запоминанием набора услышанных фактов.
Не увидел в посте описания опасностей от чтения книг. Книга — практически единственный способ получить сразу и в полном объеме знания. Понятно, что этого не достаточно. Далее надо «руку набить».
А вот без книг получается результат гораздо плачевнее. По статьям на хабре предмет не изучишь. Лучше брать на работу человека, не имеющего опыта, хорошо знающего книгу, чем выскочку, что-то сделавшего по пошаговому руководству. Первый хоть будет встречать в проекте знакомые вещи и быстро научится.
Говнокодинг — это уже целая культура. Списать просто на глупость людей, судя по их количеству — нельзя. И как-то заметил, что у большинства из них есть общая черта. Они не стремятся писать чистый код. Они стремятся оптимизировать, причем заранее. Причем всегда. Мозги у людей так повернуты, что они бесконечно думают только о том, чтобы код «летал». Т.е. смещена картина мира — они говнокодом называют то, что не быстро работает. Даже если не требуется. А то, что их код — говно, они не замечают совершенно.
В итоге, их код не читается, нельзя менять. И еще в добавок и не летает, а ползает, как недобитое животное. Предварительная оптимизация — такая предварительная.
У Вас вроде всё верно — написали на реляционной базе — работает, деньги приносит. А потом, уже когда код работал, дали оптимизировать.
Так получился у меня код, потому что я следую определенной стратегии. Представляю, что требования имеют смысл. И я этот смысл перевожу на язык программирования. Как можно точнее и как можно с меньшими своими домыслами. Я и не думал особо.
Посмотрев на
1 X X X X — 100 очков
5 X X X X — 50 очков
1 1 1 X X — 1000 очков
2 2 2 X X — 200 очков
3 3 3 X X — 300 очков
4 4 4 X X — 400 очков
5 5 5 X X — 500 очков
6 6 6 X X — 600 очков
я нигде не видел прямых указаний, что в правиле могут быть только по одной или только по три цифры. Что в правиле только одинаковые цифры. Я просто вижу набор цифр и соответствующее число очков. Глаза, конечно, замечают неявные закономерности, но смысл надо переводить как можно более прямо. А Вы, видимо, прочитали правила иначе. Вы сразу по умолчанию выписали неявные закономерности, как исходные требования. И у Вас возникло на ровном месте многообразие способов задания правил. И поэтому паттерн.
Поэтому пример для паттерна неудачный. Он лишний.
Замечу, что если бы требования были заданы в словесной форме, так:
«Правилом считаем выпадение некоторого числа одинаковых значений 1..6. За каждое правило начисляем очки.
Правила бывают с одним значением и с тремя.
Правила:
если выпадает 1-ца один раз, то начисляем 100;
…
если выпадает 4-ка три раза, то начисляем 400;
… „
То в таком виде стратегия перевода требования заставила бы создавать правила именно так. Но далее, в процессе рефакторинга, не применяя никаких паттернов, скорее всего алгоритм подсчета был бы вынес в один метод, данные, которые ему передаются, тоже сведены в список. Далее, по сути, создание правил — это всего лишь конструктор для этих списков. В конце концов, из-за рефакторинга снова пришли бы где-то к такому же коду.
И наоборот. Если я написал код вот так, как сейчас, при нынешних требованиях, но вдруг начали приходить “неудобные» требования. Например: «За 500 выпадений 6-рок, начисляем миллион». То теперь, становится ясно, что писать 500 раз 6 как минимум неудобно. Тогда добавляется конструктор. А именно: в коде анонимный тип заменяется на класс, в нем эти же два свойства, и добавляем конструктор, которому передаем (int diceRollNumber, int count). А сам алгоритм не меняется.
Не совсем понял. В моем коде в шаблоне набираете цифры в любом порядке, любые цифры, даже не одинаковые.
Т.е. правило:
1, 1, 2, 2, 3 — xxx очков? (350 очков)
Просто добавляете строку:
new { Template = new List<int> {1, 1, 2, 2, 3 }, Score = 350 }
Спорить не зачем и не о чем. Просто пример для этого паттерна неудачный.
Паттерны сами по себе в отрыве от задачи — зло. Я не знаю полезных паттернов. Каждый из них что-то плохое, да и делает.
Вы во вступлении написали, что бывает надо писать много ветвлений, а этот паттерн позволяет избавиться. Если в отрыве от задач, то стремиться избавиться от ифов — это просто объявить войну компилятору и языку программирования. Это добавление нового измерения, выворачивание условий наизнанку и создание своего «настраиваемого» языка. Т.е. есть в C# конструкция if, но кому-то не нравится этот язык и он решает создать свой. Более гибкое и настраиваемое решение — это всегда более ущербное и ненадежное.
Но все что мы пишем, с паттернами или без — зло. Любая новая строчка кода — увеличение энтропии. Поэтому этот паттерн может быть полезен, как меньшее зло. Можно представить, например, что будет стоять задача — пользователь в графическом интерфейсе задает правила поведения системы. Вот, скорее всего, такой паттерн будет хорошо оправдан.
Вот так я отношусь к паттернам. И еще, они и сами появляются, если заниматься постоянным рефакторингом.
Зря вы не любите linq. Сильно упрощает жизнь. Читается легко, если привыкнуть.
Этот код я написал для примера и на Func. Если не нравится такой подход, код можно без проблем разбросать на несколько методов в классе, вместо анонимного типа написать небольшой класс с двумя свойствами. Код останется практически таким же.
select я бы не выбрасывал. Но он также преобразовывается в foreach. И будет обычный ООП код.
Простота этого кода и прямое решение задачи, без паттернов, имеет еще один плюс: если присмотреться, то этот подход даже гибче, чем с паттерном. Тут нет никаких дополнительных предположений, кроме того, что я понял из требований. Тут нет отдельного класса для правила из одного элемента. Тут не зашито утверждение, что в правиле должны быть только одинаковые цифры. Поэтому теперь добавлять новые правила вообще без проблем, даже если они изменятся и это будет проще, чем с паттерном. Т.е. это решение гибче. Хотя я к ней никогда обычно не стремлюсь.
А гибким оно получилось потому, что как раз я посмотрел на требования и не додумывал ничего от себя. Я не искал в правилах игры неявные закономерности и не вшивал их в код.
Извините, но это ужасно. Визуально, тот код, который назывался плохим для игры в кости, выглядит лучше. Он меньше.
Да, он непонятный, но только потому, что совершенно безобразно написаны имена, тройка прыгает по коду.
Если его причесать и если класс действительно должен считать кубики и там написан минимум на данный момент (YAGNI), то он будет лучше. Но он правда и ягни не отвечает. Просто странно ни в какие ворота написан.
Паттерн здесь выглядит еще хуже.
Сразу оговорюсь, я не критикую автора вообще за паттерн, возможно он хотел показать его использование, а пример выбрал неудачный.
Но я лично, паттерны и не люблю. Паттерны появляться должны самостоятельно, если надо. Обычно, они нужны для гибкости. Но программы не должны быть гибкими. Программы должны быть точными. А это буквально наоборот, чем то, что здесь написано. Т.е. вы с чего-то думаете о каком-то вымышленном завтра, когда вдруг внезапно появятся новые правила. И наворотили бог весть что. Вывернули логику, заставили страдать компилятор.
Не воспринимайте как оскорбление, просто давайте по другому взглянем на задачу. Я всегда говорил, что язык программирования — это язык, а программирование — это перевод требований. Как есть. Без никаких домыслов о завтра. Завтра будет завтра. Если записано как есть, то и менять не очень много надо будет. Также, в коде должно быть максимальное соотношение кода, которое прямо относится к задаче и к требованиям. Их должно быть видно.
Давайте и посмотрим:
1 X X X X — 100 очков
5 X X X X — 50 очков
1 1 1 X X — 1000 очков
2 2 2 X X — 200 очков
3 3 3 X X — 300 очков
4 4 4 X X — 400 очков
5 5 5 X X — 500 очков
6 6 6 X X — 600 очков
Это буквально юз-кейсы. Какие требования?
1. Порядок не важен.
2. Из всех комбинаций ищем наборы комбинаций (назову шаблонов), которые дают максимальное количество очков.
И вот код:
int GetScore(int[] roles)
{
List<int> rolesList = roles.ToList();
Func<int> getScoreFromBestTemplate = () =>
{
var templatesWithScores = new []
{
new { Template = new List<int> {1}, Score = 100 },
new { Template = new List<int> {5}, Score = 50 },
new { Template = new List<int> {1, 1, 1}, Score = 1000 },
new { Template = new List<int> {2, 2, 2}, Score = 200 },
new { Template = new List<int> {3, 3, 3}, Score = 300 },
new { Template = new List<int> {4, 4, 4}, Score = 400 },
new { Template = new List<int> {5, 5, 5}, Score = 500 },
new { Template = new List<int> {6, 6, 6}, Score = 500 },
};
Func<List<int>, List<int>, List<int>> deleteMatchElements = (source, template) =>
{
var sourceCopy = source.ToList();
template.ForEach(item => sourceCopy.Remove(item));
return sourceCopy;
};
Func<List<int>, List<int>, bool> isMatch =
(source, template) => deleteMatchElements(source, template).Count == source.Count - template.Count;
var templateWithMaxScore =
(from tws in templatesWithScores
where isMatch(rolesList, tws.Template)
orderby tws.Score descending
select tws
).FirstOrDefault() ?? new { Template = new List<int> {}, Score = 0 };
rolesList = deleteMatchElements(rolesList, templateWithMaxScore.Template);
return templateWithMaxScore.Score;
};
int sumScore = 0;
int score = 0;
do
{
score = getScoreFromBestTemplate();
sumScore += score;
}
while (score != 0);
return sumScore;
}
Согласитесь, так читаемость намного лучше. Требования видны невооруженным глазом. Не надо разбираться с конструкторами классов. Да и классы писать не надо. Буквально видно по шагам, как откуда всё получается. Не должно быть у простых задач много кода!
В нем да, жестко зашиты требования, как поняты мною на данный момент. Да, в этом коде заложено, что я выбираю всегда самый «дорогой» шаблон. Но ведь так и надо на данный момент. Именно это и требуется из задачи. Нет никакого будущего. Если меня попросили перевести на английский «собачка перебежала дорогу», то именно так и надо поступать, а не писать «ххх перебежало дорогу». Чтобы когда-то послезавтра кошку туда подставить. Когда требования выражены четко, когда кода минимум, тогда и переписать будет не проблема, если изменятся требования.
Код возможно не идеально простой. Может, заставит задуматься о замыканиях и сайд-эффекте.
Но, в общем, не в паттернах счастье.
Для таких вещей вот как раз и есть документация. Это не документация по коду. А какая-то вводная, курс молодого бойца по предметной области для программистов.
Программисты — это такие люди, которые как бы обязаны знать предметную область. Только таких программистов почти нет. Не учат программированию со смежными специальностями. Я закончил физ-мат, физик, поэтому может удивительно, что люди закон всемирного тяготения не знают, хоть он и из школьного курса.
Т.е. как переводчик, он должен знать язык, с которого переводит. Знание программирования недостаточно. Иначе такой программист может писать программы только для программистов.
Как выход из ситуации — программист должен иметь хорошую математическую и другие базы, чтобы уметь быстро вникнуть в предметную область.
Это в идеале и может быть мои знания в этом устарели. Может быть уже ничего и знать не должен, а уметь на стартаптусовках пиариться ))
По пункту 2. То же самое. Культурные отличия — это не более, чем автоматические действия. Конечно, если в Японии принято, то это просто принято.
Не ужасны. Такие же самые. Искренность отношений говорит о взаимопонимании и взаимоуважении по умолчанию. И эти качества не требуют постоянных подтверждений словами.
Мне кажется, Вы в одну кучу сливаете прямое общение, критику без перехода на личности (т.е. «Вася, код твой ужасен, поправь» vs «Вася, ты дебил, поэтому код говно»), и хамство (это когда человек переходит границы личного и на личности: «у твоей жены маловат размер груди»). Это всё разные вещи. Критика полезна. И полезно ее учиться воспринимать спокойно, не оскорбляясь. Также полезно уметь критиковать, пусть и матом даже, но не переходя на личности, отделяя человека от его работы или каких-то мелких недостатков. У всех недостатки. Но критиковать надо недостатки (не человека), потому что это полезно для развития. Для быстрой реакции на проблему, улучшения качества работы.
Смотря какие отношения между Васей и Петей. Если они друзья, то еще не то могут друг другу сказать и никто не обидится. Бывает и «Глянь, Вася, какое я говно написал ))».
Нет, гопники, кажется, это другое. Но в общем, говорить можно и не словами «говно» а как угодно. Но если Вы знаете о проблеме и еще знаете где, то можно и пальцем тыкнуть, а не заувалированно боясь оскорбить говорить «Вася, у тебя (предположительно, извини, извини), в классе где-то есть ошибка».
Специальная наглость и хамство — тоже неприятно. Но прямота, по моему, способствует лучшей производительности. Вот, в нашей культуре, видишь, что код «говно», то как это сказать? Завуалированно? Так и 10 лет пройдет, а человек будет думать, что его код пахнет. Критика и самокритика — вещи хорошие. Главное, не переходить на личности и не воспринимать за оскорбления.
Как культурное отличие Европы, Японии или американцев — это я могу понять. Не могу понять, как может так раздражать наша, вроде неплохая вещь. Ну да, есть хамы, которые просто так хамы, которые всегда пересекают границу личного пространства.
Природа бага такова, что вы, пока не создав тесты, стабильно его повторяющие, не нашли код и не исправили — причину бага не знаете. Не зная причины, вы никак не можете оценить важность бага и его урон.
Еще, в поддержку того, что лучше упасть — хотя гарантии отсутствия багов не будет никогда, если нормально написан код, покрыт тестами, багов на самом деле не очень много. Поэтому чем жестче программа реагирует на «неожиданное поведение», тем быстрее эти баги отловятся. Возможно даже до продакта.
Только в крайне редких случаях можно так делать — ехать дальше. Не хочется о них и напоминать. Бывает, что у вас приложение для какой-то сферы деятельности, а на ГУИ появляются непонятные артефакты или что-то несущественное не прорисовывается. Или действительно обрабатываете данные с мусором и это ожидаемое поведение, и вы логируете предупреждения. Т.е. очень иногда так можно поступать. К сожалению, многие это «иногда» возводят в абсолют.
Увидел один раз код, который копипастом распространился везде: если по какой-то «счастливой» случайности не нашли клиента по айди — брался первый попавшийся. Снимались деньги или начислялся долг. Вот как надо начальства бояться )))
Возможно такого никогда не произошло. Но заботливый программист это заложил. И коду не один год…
Выживаемость программы — прямо противоположная вещь надежности в большинстве случаев.
Еще нравится, как люди пишут кругом, не задумываясь:
И даже средства улучшения кода в полуавтоматическом режиме такие вещи делают. Ну, вы поняли…
Если побеждает по каким-то причинам html5 и он умеет всё, что умеет силверлайт, но он лучше в плане «не нужно плагина» или «не нужно грузить долго» — то это все равно не причина переходить на эти вещи. Главное то в нашей профессии — скорость кодирования и надежность, а не всякие непрограммерские аргументы. Поэтому, если html5 лучше по каким-то космическим причинам, не программерским, то легко напишут транслятор в html5.
Ассемблер может тоже круче. Но главное — удобство кодирования. Потому что вот написали — то что на силвере делается за день, на html5 делается за неделю. Хотите в 5-7 раз меньше зарплату?
Перчатки усложнителя
Всё верно — книги без практики — пустая трата времени. Но и не надо из этого делать противоположности — либо практика, либо книги. Книга, а за ней практика наиболее быстрый способ получить глубокие знания. Просто потому, что любую книгу прочитаете за неделю/две. А практика нарабатывается дольше. Так удлинять себе путь и учиться на своих ошибках? В конце концов, если захотите стать профи в теме, то Вам рано или поздно придется прочитать книги, чтобы не было упущенных знаний. Так что оптимально начать с книги.
Книги без практики — пустая трата времени. И если программист читает книги по темам, которые не применяет в повседневной работе, но еще и не закрепляет практикой материал — то это выглядит странно — тема ему не интересна. Как можно изучать новую технологию или язык, но при этом не захотеть попробовать это в деле?
При всех равных — да. Если это уже «состоявшийся» инженер, как написано в посте, и просто изучил новую технологию или язык по книге — то очевидно, он будет состоявшегося инженера, прочитавшего статью какую-то или пошаговое руководство и попробовавшего сделать какой-нибудь примитив.
Если сравнивать двух человек без опыта, то тоже, видимо, хорошо знающий книги по предмету вызывает больше уважения, чем тот, кто поверхностно только что-то видел и попробовал.
Книги не достаточны. Нужно иметь опыт. Это значит — и попробовать самому и еще лучше — поработать в коллективе, кто в этих вещах опытный.
Но книги — самый надежный вариант быстро войти в тему. Хорошая книга дает всю базу, все необходимые знания, кроме нюансов, кроме практики. И если кто-нибудь хочет с чем-то работать, то лучше сразу изучить книгу, потом уже пробовать. Второй шаг тоже обязательный. Без начального изучения материала, человек пробуя, строит нечто несуразное, создает велосипеды, не знает даже, в каком направлении двигаться. Допускает много ошибок и даже не знает, что их можно не допускать. Поэтому — сначала база, потом практика — наиболее быстрый метод.
И еще, чтение любой книги гораздо меньше времени займет, чем обретение практики. Только лень и высокое ЧСВ заставляют людей думать, что они и без книг умные. А по времени на самом деле выгоднее прочитать книгу.
Я встречал «программистов», которые утверждают, что книги им не нужны и они никогда не читают. Не все такие и программистами становятся, только любят в околопрограммисткой тусовке находиться. Те, которые программисты, если можно так назвать, имеют крайне поверхностные знания, пишут код плохо, любят больше говорить. Это тип такой людей, которые путают ум и запоминанием набора услышанных фактов.
А вот без книг получается результат гораздо плачевнее. По статьям на хабре предмет не изучишь. Лучше брать на работу человека, не имеющего опыта, хорошо знающего книгу, чем выскочку, что-то сделавшего по пошаговому руководству. Первый хоть будет встречать в проекте знакомые вещи и быстро научится.
Мой комментарий был направлен на название статьи.
Говнокодинг — это уже целая культура. Списать просто на глупость людей, судя по их количеству — нельзя. И как-то заметил, что у большинства из них есть общая черта. Они не стремятся писать чистый код. Они стремятся оптимизировать, причем заранее. Причем всегда. Мозги у людей так повернуты, что они бесконечно думают только о том, чтобы код «летал». Т.е. смещена картина мира — они говнокодом называют то, что не быстро работает. Даже если не требуется. А то, что их код — говно, они не замечают совершенно.
В итоге, их код не читается, нельзя менять. И еще в добавок и не летает, а ползает, как недобитое животное. Предварительная оптимизация — такая предварительная.
У Вас вроде всё верно — написали на реляционной базе — работает, деньги приносит. А потом, уже когда код работал, дали оптимизировать.
Посмотрев на
я нигде не видел прямых указаний, что в правиле могут быть только по одной или только по три цифры. Что в правиле только одинаковые цифры. Я просто вижу набор цифр и соответствующее число очков. Глаза, конечно, замечают неявные закономерности, но смысл надо переводить как можно более прямо. А Вы, видимо, прочитали правила иначе. Вы сразу по умолчанию выписали неявные закономерности, как исходные требования. И у Вас возникло на ровном месте многообразие способов задания правил. И поэтому паттерн.
Поэтому пример для паттерна неудачный. Он лишний.
Замечу, что если бы требования были заданы в словесной форме, так:
«Правилом считаем выпадение некоторого числа одинаковых значений 1..6. За каждое правило начисляем очки.
Правила бывают с одним значением и с тремя.
Правила:
если выпадает 1-ца один раз, то начисляем 100;
…
если выпадает 4-ка три раза, то начисляем 400;
… „
То в таком виде стратегия перевода требования заставила бы создавать правила именно так. Но далее, в процессе рефакторинга, не применяя никаких паттернов, скорее всего алгоритм подсчета был бы вынес в один метод, данные, которые ему передаются, тоже сведены в список. Далее, по сути, создание правил — это всего лишь конструктор для этих списков. В конце концов, из-за рефакторинга снова пришли бы где-то к такому же коду.
И наоборот. Если я написал код вот так, как сейчас, при нынешних требованиях, но вдруг начали приходить “неудобные» требования. Например: «За 500 выпадений 6-рок, начисляем миллион». То теперь, становится ясно, что писать 500 раз 6 как минимум неудобно. Тогда добавляется конструктор. А именно: в коде анонимный тип заменяется на класс, в нем эти же два свойства, и добавляем конструктор, которому передаем (int diceRollNumber, int count). А сам алгоритм не меняется.
Как видим, снова пришли к тому же коду.
Т.е. правило:
1, 1, 2, 2, 3 — xxx очков? (350 очков)
Просто добавляете строку:
Можете поменять порядок цифр, смысл не меняется.
Паттерны сами по себе в отрыве от задачи — зло. Я не знаю полезных паттернов. Каждый из них что-то плохое, да и делает.
Вы во вступлении написали, что бывает надо писать много ветвлений, а этот паттерн позволяет избавиться. Если в отрыве от задач, то стремиться избавиться от ифов — это просто объявить войну компилятору и языку программирования. Это добавление нового измерения, выворачивание условий наизнанку и создание своего «настраиваемого» языка. Т.е. есть в C# конструкция if, но кому-то не нравится этот язык и он решает создать свой. Более гибкое и настраиваемое решение — это всегда более ущербное и ненадежное.
Но все что мы пишем, с паттернами или без — зло. Любая новая строчка кода — увеличение энтропии. Поэтому этот паттерн может быть полезен, как меньшее зло. Можно представить, например, что будет стоять задача — пользователь в графическом интерфейсе задает правила поведения системы. Вот, скорее всего, такой паттерн будет хорошо оправдан.
Вот так я отношусь к паттернам. И еще, они и сами появляются, если заниматься постоянным рефакторингом.
Этот код я написал для примера и на Func. Если не нравится такой подход, код можно без проблем разбросать на несколько методов в классе, вместо анонимного типа написать небольшой класс с двумя свойствами. Код останется практически таким же.
select я бы не выбрасывал. Но он также преобразовывается в foreach. И будет обычный ООП код.
Простота этого кода и прямое решение задачи, без паттернов, имеет еще один плюс: если присмотреться, то этот подход даже гибче, чем с паттерном. Тут нет никаких дополнительных предположений, кроме того, что я понял из требований. Тут нет отдельного класса для правила из одного элемента. Тут не зашито утверждение, что в правиле должны быть только одинаковые цифры. Поэтому теперь добавлять новые правила вообще без проблем, даже если они изменятся и это будет проще, чем с паттерном. Т.е. это решение гибче. Хотя я к ней никогда обычно не стремлюсь.
А гибким оно получилось потому, что как раз я посмотрел на требования и не додумывал ничего от себя. Я не искал в правилах игры неявные закономерности и не вшивал их в код.
Да, он непонятный, но только потому, что совершенно безобразно написаны имена, тройка прыгает по коду.
Если его причесать и если класс действительно должен считать кубики и там написан минимум на данный момент (YAGNI), то он будет лучше. Но он правда и ягни не отвечает. Просто странно ни в какие ворота написан.
Паттерн здесь выглядит еще хуже.
Сразу оговорюсь, я не критикую автора вообще за паттерн, возможно он хотел показать его использование, а пример выбрал неудачный.
Но я лично, паттерны и не люблю. Паттерны появляться должны самостоятельно, если надо. Обычно, они нужны для гибкости. Но программы не должны быть гибкими. Программы должны быть точными. А это буквально наоборот, чем то, что здесь написано. Т.е. вы с чего-то думаете о каком-то вымышленном завтра, когда вдруг внезапно появятся новые правила. И наворотили бог весть что. Вывернули логику, заставили страдать компилятор.
Не воспринимайте как оскорбление, просто давайте по другому взглянем на задачу. Я всегда говорил, что язык программирования — это язык, а программирование — это перевод требований. Как есть. Без никаких домыслов о завтра. Завтра будет завтра. Если записано как есть, то и менять не очень много надо будет. Также, в коде должно быть максимальное соотношение кода, которое прямо относится к задаче и к требованиям. Их должно быть видно.
Давайте и посмотрим:
Это буквально юз-кейсы. Какие требования?
1. Порядок не важен.
2. Из всех комбинаций ищем наборы комбинаций (назову шаблонов), которые дают максимальное количество очков.
И вот код:
Согласитесь, так читаемость намного лучше. Требования видны невооруженным глазом. Не надо разбираться с конструкторами классов. Да и классы писать не надо. Буквально видно по шагам, как откуда всё получается. Не должно быть у простых задач много кода!
В нем да, жестко зашиты требования, как поняты мною на данный момент. Да, в этом коде заложено, что я выбираю всегда самый «дорогой» шаблон. Но ведь так и надо на данный момент. Именно это и требуется из задачи. Нет никакого будущего. Если меня попросили перевести на английский «собачка перебежала дорогу», то именно так и надо поступать, а не писать «ххх перебежало дорогу». Чтобы когда-то послезавтра кошку туда подставить. Когда требования выражены четко, когда кода минимум, тогда и переписать будет не проблема, если изменятся требования.
Код возможно не идеально простой. Может, заставит задуматься о замыканиях и сайд-эффекте.
Но, в общем, не в паттернах счастье.
Программисты — это такие люди, которые как бы обязаны знать предметную область. Только таких программистов почти нет. Не учат программированию со смежными специальностями. Я закончил физ-мат, физик, поэтому может удивительно, что люди закон всемирного тяготения не знают, хоть он и из школьного курса.
Т.е. как переводчик, он должен знать язык, с которого переводит. Знание программирования недостаточно. Иначе такой программист может писать программы только для программистов.
Как выход из ситуации — программист должен иметь хорошую математическую и другие базы, чтобы уметь быстро вникнуть в предметную область.
Это в идеале и может быть мои знания в этом устарели. Может быть уже ничего и знать не должен, а уметь на стартаптусовках пиариться ))