Есть много «похожего» кода, но в каждом свои детали. Код простой и линейный. Можно дублирование устранить, сделав функцию\объект с кучей параметров, которые покрывают все случаи. Это убирает повторения, но делает код сложнее. Какой вариант лучше?
Код не становится заметно сложнее при правильном подходе. Например, если у нас после попытки убрать дублирование появляется длинная функция со switch внутри, который содержит в своих ветках практически исходные куски кода — это неправильный подход. Функция должна по возможности оперировать параметрами напрямую, а не на уровне условного goto. Т.е. cube(n) делает внутри себя return n * n * n, грубо говоря, а не if(n == 2) return 8, if(n==3) return 27
Если же не получается так, значит фрагменты кода слишком сложны для унификации, и убирать дублирование надо на уровне их отдельных частей. Либо посмотреть на архитектуру в целом — почему получается такая ситуация.
Есть список «общепринятых» концепций?
Есть — на уровне ЯП, отрасли, команды в которой работаешь и мира IT в целом — в качестве примеров я уже приводил автолоад классов и UNIX-конвейеры.
Если же сам алгоритм сложен, то лучше всего правильно назвать метод и в remarks вставить ссылку на описание алгоритма.
Понятия «хорошего» и «плохого» кода субъективны. Рассуждать о них — это пустая трата времени.
Понятия «простоты кода» и «DRY» — полностью объективны. Простота/сложность — это количество языковых и смысловых конструкций, а также сущностей, которыми оперирует программа. Оно может быть избыточным (что плохо), или достаточным (что хорошо). С DRY все еще проще — если код дублируется (причем я не говорю только про посимвольное совпадение, естественно, речь про совпадение функциональности) — это всегда плохо. Потому что увеличивается количество сущностей, нужно вносить правки в нескольких местах, резко повышается вероятность ошибки (в одном месте поправили, в другом — нет).
Насчет «удобочитаемости» — это некоторое общественное соглашение. Как правила литературного русского языка например, или этикета. Математически они не объясняются, просто вот так люди договорились.
Так я рассказываю — упрощайте код и избавляйтесь от дубликатов каждый раз когда появляется хоть малейшая возможность, любым способом, даже если он вам кажется «кривоватым» или «примитивным». Вода камень точит. Иначе и правда надо все сносить и с нуля, что во многих случаях малореально.
Простота и DRY противоречат друг другу иногда. Что делать в этом случае?
Я про это писал в статье — достижение DRY простыми и очевидными методами помогает в большинстве случаев. Если же выходит так, что без объектов, динамически генерируемых через цепочку фабрик согласно XML-конфигурации, дублирования не избежать, надо задуматься — а все ли вообще хорошо с архитектурой? Т.е. на каком-то этапе этот процесс перестает быть линейным и требует подняться на уровень выше.
«Концептуальность» вообще слабо формализуемое понятие, глядя на код как понять насколько он «концептуален»?
Если концепция общепринятая, она понятна и так. А если их (концепций) в коде нет вообще, то это определяется по другому — смотрим на код, понимаем, что в нем есть лишние сущности. Т.е. какие-то вещи можно переделать на более общем уровне. Утрированный пример — автолоад классов вместо include в каждом месте, где они нужны. Вот это и есть — применить концепцию.
«Удобочитаемость» это не то же самое, что «удобопонимаемость».
Особенно доставил последний пункт. Если есть неочевидный код, то почему бы его не написать чтобы он стал очевидным, вместо написания комментариев?
Не любой фрагмент кода можно сделать очевидным для каждого, кто его будет смотреть. Бывает объективная сложность описываемого алгоритма или бизнес-процесса, которую не снизить за счет правильного подбора языковых конструкций. Вот повысить можно запросто :)
Я думал об этом, но кроме раздела «Удобочитаемость» не нашел куда их воткнуть, а там и так одни прописные истины перечислены, на каждую по паре десятков статьей написано уже, если не больше.
В остальных случаях — в отрыве от контекста примеры больше споров вызовут, чем пользы. Скажем, в разделе про «простоту» кода даже и нельзя написать, что это «хорошо», а вот это «плохо», например про класс из двух слабосвязанных методов по сравнению с просто двумя функциями. Вроде и так и так можно сделать, а с классом даже «правильнее», если рассматривать сферический код в вакууме, как по учебникам.
На деле же, суммарную сложность проекта такие «правильные» конструкции могут повысить в несколько раз, ну и как следствие — сложность поддержки, рост числа ошибок и т.д.
Что такое 10 килобаксов? Смешные деньги, на самом деле. В Москве/Питере во столько средней фирме обходится один месяц одного среднего программера (считая з/п, налоги, аренду и пр), а то и больше. А сколько в америках/европах обходится, я молчу.
Я не поделитесь, откуда такие сведения? Я не знаю как в Москве, но в Питере вполне приличного программиста (даже чуть повыше среднего), хотя конечно и не «звезду», можно найти тысяч на 80-90 в месяц чистыми, и он даже не будет потом думать, что ему недоплачивают.
Если это даже полностью белая з/п, что бывает не всегда, то это +40 тысяч примерно налогов и взносов, и еще порядка 5-10 на аренду площади его рабочего места, интернет, «печеньки» и прочее.
Что в сумме составит самое большее 5 килобаксов, но никак не 10.
Все по существу, и без лишней воды.
Как предприниматель в сфере IT с 5-летним стажем готов подписаться под каждым словом.
Спасибо автору за то, что поделился полезным опытом, и удачи в новых начинаниях.
В коммерческой разработке — рынок решает. Масса факторов, связанных с бюджетом проекта, сроками, стоимостью поддержки, стоимостью специалистов, их доступностью и т.д.
Переписать все на Haskell — оправдано только тогда, когда это экономически целесообразно с учетом всего выше перечисленного хотя бы в среднесрочном периоде. А не тогда, когда это «правильно».
Про «Adsense/Yandex.Direct, 700 000 в сутки» — число с потолка, т.к. это очень сильно зависит от тематики сайта, его структуры, размещения блоков и т.д.
Например, указанную вами выше сумму в $10000 реально получать и при в 10 раз меньшем количестве суточных просмотров. Согласитесь, что ошибка в оценках на порядок (в буквальном смысле, а не в переносном, как многие любят употреблять) — может полностью поменять выводы из этих оценок.
А если тематика что-нибудь типа банковских кредитов или фармацевтики, то конвертация может быть еще на порядок выше (но скорее всего при меньших объемах, т.к. рынок более специализирован и трафик меньше).
Начало статьи (где говорится про универсальную механическую методику для программистов любой квалификации) противоречит ее же финалу (где уже начинает требоваться мудрость).
В этом и проблема — если сильно перегибать с вынесением каждого логического куска кода в отдельный метод, велик риск получить огромное количество классов с сотнями методов в каждом.
Я такой код видел пару раз. Заходишь в метод — там if-else ветки и вызов других методов, и больше практически никакого кода нет. Заходишь в эти методы — там то же самое. И так рекурсивно на 5-6 (иногда и 10) уровней вниз. Где-то там после 6 уровня вложенности метод делает что-то типа вашего: return ($this->token != "");
К этому моменту мы уже имеем дерево из 15-20 методов, которые нам надо держать в голове, чтобы понять что реально происходит в исходном методе, который нам требовалось понять (или поменять).
В общем, не зная меры, такой методикой можно сделать код только хуже.
Все в общем то правильно, но ту работу, которая никому не нравится тоже должен кто-то делать. Если каждый будет опираться на прокрастинацию, то кто будет делать рутину? Вероятность того, что на каждую работу найдется тот, кому она нравится мне кажется не слишком высокой.
Это довольно распространенное заблуждение, основанное на принципе «сужу по себе».
Многим кажется что если им что-то нравится/не нравится, то такое же отношение к этому и у остальных «нормальных» людей, к которым большинство себя подсознательно причисляет.
Это не так.
В частности, работа, которая вам не нравится, кажется скучной и неинтересной, может полностью устраивать кого-нибудь другого, и даже приносить ему удовольствие в той или иной степени.
Хотя на интуитивном уровне вам это может показаться невозможным.
P.S. Обратная сторона этой медали — полный провал многих проектов, которые своим создателям кажутся удобными/полезными, но не учитывают мнения своей конечной аудитории.
Все игроки, в основном, оказались из России, здесь сюрпризов не было. А вот то, что каждый второй из Санкт-Петербурга, меня сильно удивляет.
От разных людей неоднократно слышал, что Вконтакте пользуется наибольшей популярностью именно в Питере (хотя честно говоря документального подтверждения этому не смог найти).
Ну вы тоже не загибайте, у посредственного web программиста зп от 50k разве что в ДефолтСити, так там и у школьных учителей 30-35к вполне бывает.
В целом по стране от 50к получает хотя бы программист-хорошист, уровня «выше среднего», не меньше. Бывают конечно исключения, но обычно это означает что сотрудник переоценен и долго ситуация не продлится.
Получается, что «ширина» башни говорит об «открытости» позиции, т.е. о множестве открытых (или потенциально открытых) «посадочных» блоков. Это дает кучу вариантов, но это же в перспективе приводит к более короткому решению.
Возможно что ширина на старте действительно обратно пропорциональна глубине оптимума.
А куча вариантов на старте сама по себе не является помехой для бота. Большая их часть может быть зарезана при проверке вариантов-дублей, либо отброшена по длине/стоимости.
Могу предположить что проблемой для робота станут лишь башни с очень большой глубиной оптимального решения, т.е. для русских башен это 110-120 ходов или больше. Не знаю, существуют ли такие, хотелось бы на них взглянуть.
У роботов то тоже потенциалы ускорения неплохие, хотя бы на компилируемом языке переписать, и то дело.
Ну и комп у меня далеко не топовый даже по меркам 2-3х летней давности.
Если же не получается так, значит фрагменты кода слишком сложны для унификации, и убирать дублирование надо на уровне их отдельных частей. Либо посмотреть на архитектуру в целом — почему получается такая ситуация.
Есть — на уровне ЯП, отрасли, команды в которой работаешь и мира IT в целом — в качестве примеров я уже приводил автолоад классов и UNIX-конвейеры.
Ну так ссылка это и есть комментарий.
Насчет «удобочитаемости» — это некоторое общественное соглашение. Как правила литературного русского языка например, или этикета. Математически они не объясняются, просто вот так люди договорились.
Если концепция общепринятая, она понятна и так. А если их (концепций) в коде нет вообще, то это определяется по другому — смотрим на код, понимаем, что в нем есть лишние сущности. Т.е. какие-то вещи можно переделать на более общем уровне. Утрированный пример — автолоад классов вместо include в каждом месте, где они нужны. Вот это и есть — применить концепцию.
Не любой фрагмент кода можно сделать очевидным для каждого, кто его будет смотреть. Бывает объективная сложность описываемого алгоритма или бизнес-процесса, которую не снизить за счет правильного подбора языковых конструкций. Вот повысить можно запросто :)
В остальных случаях — в отрыве от контекста примеры больше споров вызовут, чем пользы. Скажем, в разделе про «простоту» кода даже и нельзя написать, что это «хорошо», а вот это «плохо», например про класс из двух слабосвязанных методов по сравнению с просто двумя функциями. Вроде и так и так можно сделать, а с классом даже «правильнее», если рассматривать сферический код в вакууме, как по учебникам.
На деле же, суммарную сложность проекта такие «правильные» конструкции могут повысить в несколько раз, ну и как следствие — сложность поддержки, рост числа ошибок и т.д.
Я не поделитесь, откуда такие сведения? Я не знаю как в Москве, но в Питере вполне приличного программиста (даже чуть повыше среднего), хотя конечно и не «звезду», можно найти тысяч на 80-90 в месяц чистыми, и он даже не будет потом думать, что ему недоплачивают.
Если это даже полностью белая з/п, что бывает не всегда, то это +40 тысяч примерно налогов и взносов, и еще порядка 5-10 на аренду площади его рабочего места, интернет, «печеньки» и прочее.
Что в сумме составит самое большее 5 килобаксов, но никак не 10.
Как предприниматель в сфере IT с 5-летним стажем готов подписаться под каждым словом.
Спасибо автору за то, что поделился полезным опытом, и удачи в новых начинаниях.
Переписать все на Haskell — оправдано только тогда, когда это экономически целесообразно с учетом всего выше перечисленного хотя бы в среднесрочном периоде. А не тогда, когда это «правильно».
Например, указанную вами выше сумму в $10000 реально получать и при в 10 раз меньшем количестве суточных просмотров. Согласитесь, что ошибка в оценках на порядок (в буквальном смысле, а не в переносном, как многие любят употреблять) — может полностью поменять выводы из этих оценок.
А если тематика что-нибудь типа банковских кредитов или фармацевтики, то конвертация может быть еще на порядок выше (но скорее всего при меньших объемах, т.к. рынок более специализирован и трафик меньше).
Похоже что заброшен.
В этом и проблема — если сильно перегибать с вынесением каждого логического куска кода в отдельный метод, велик риск получить огромное количество классов с сотнями методов в каждом.
Я такой код видел пару раз. Заходишь в метод — там if-else ветки и вызов других методов, и больше практически никакого кода нет. Заходишь в эти методы — там то же самое. И так рекурсивно на 5-6 (иногда и 10) уровней вниз. Где-то там после 6 уровня вложенности метод делает что-то типа вашего:
return ($this->token != "");К этому моменту мы уже имеем дерево из 15-20 методов, которые нам надо держать в голове, чтобы понять что реально происходит в исходном методе, который нам требовалось понять (или поменять).
В общем, не зная меры, такой методикой можно сделать код только хуже.
Это довольно распространенное заблуждение, основанное на принципе «сужу по себе».
Многим кажется что если им что-то нравится/не нравится, то такое же отношение к этому и у остальных «нормальных» людей, к которым большинство себя подсознательно причисляет.
Это не так.
В частности, работа, которая вам не нравится, кажется скучной и неинтересной, может полностью устраивать кого-нибудь другого, и даже приносить ему удовольствие в той или иной степени.
Хотя на интуитивном уровне вам это может показаться невозможным.
P.S. Обратная сторона этой медали — полный провал многих проектов, которые своим создателям кажутся удобными/полезными, но не учитывают мнения своей конечной аудитории.
От разных людей неоднократно слышал, что Вконтакте пользуется наибольшей популярностью именно в Питере (хотя честно говоря документального подтверждения этому не смог найти).
P.S. Это к тому что для каждой задачи все-таки свой инструмент нужен
В целом по стране от 50к получает хотя бы программист-хорошист, уровня «выше среднего», не меньше. Бывают конечно исключения, но обычно это означает что сотрудник переоценен и долго ситуация не продлится.
Возможно что ширина на старте действительно обратно пропорциональна глубине оптимума.
А куча вариантов на старте сама по себе не является помехой для бота. Большая их часть может быть зарезана при проверке вариантов-дублей, либо отброшена по длине/стоимости.
Могу предположить что проблемой для робота станут лишь башни с очень большой глубиной оптимального решения, т.е. для русских башен это 110-120 ходов или больше. Не знаю, существуют ли такие, хотелось бы на них взглянуть.
У роботов то тоже потенциалы ускорения неплохие, хотя бы на компилируемом языке переписать, и то дело.
Ну и комп у меня далеко не топовый даже по меркам 2-3х летней давности.
Да, вот именно про это я и писал. Тем более что область применения этой функции из трех строк шире, чем просто создание синглтонов-наследников.