Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 212
Code, Debug, Love the Emperor!
В общей сложности Гильберт был научным руководителем у 69 аспирантов, защитивших докторские диссертации. Интересен его отзыв об одном из аспирантов, бросившем математику и «переквалифицировавшемся» в поэты: «Это хорошо, у него было слишком мало фантазии для математика»
А вообще, после прочтения сложилась полная каша, у вас очень много спорных утверждений и ещё больше — сравнение несравнимого и сопоставлений несопоставимого.
да хотелось как-то так выразить в художественной форме, чтобы не надо было обосновывать. Шкала перевернута — это главное. А остальное Вы в общем-то знаете. Если складывать разные методы оценки кода по шкале — плохо-хуже, больше градаций получается. Психологически. Хорошо-лучше — не работает. Потому что любое хорошо подойдет.
А про математиков — слышал, не согласен. Это не единственное мнение о математике. Фантазия там нужна, как способность понять и удерживать в голове сложные модели, но не фантазирование. Разные вещи.
А про математиков — слышал, не согласен. Это не единственное мнение о математике. Фантазия там нужна, как способность понять и удерживать в голове сложные модели, но не фантазирование. Разные вещи.
Креативить != фантазировать. Вы с методом brainstorming'а знакомы? Это, пожалуй, один из лучших подходов к решению возникающих проблем и разногласий при разработке ПС. Разумеется, за исключением некоторых особых случаев, когда компания работает в режиме IT-конвейера.
Да всё нормально — я не против вообще креатива, потому как его не избежать. Любое решение будет включать в себя долю креатива. Я только за направление стремлений — от креатива подальше. Механические правила рефакторинга, ТДД, выражение мыслей в коде, который пришли от заказчика.
Как можно более прямым способом == как можно меньше от себя креатива.
Как можно более прямым способом == как можно меньше от себя креатива.
Фантазия и фантазирование, несомненно, разные вещи в силу того, что первое (в данном контексте) — атрибут мыслительной деятельности (даже скорее творческой), а второе (судя по морфологии) — некий процесс, который вы отчего-то наделили негативной окраской.
Вы, вроде как, утверждаете, что Катя и Чернова — это разные вещи, но говорите об одной и той же Кате Черновой.
PS: Прошу прощения за изобилие скобок.
Вы, вроде как, утверждаете, что Катя и Чернова — это разные вещи, но говорите об одной и той же Кате Черновой.
PS: Прошу прощения за изобилие скобок.
Вы так быстро меняете значения терминов и перепрыгиваете между уровнями абстракции, еще и комбинируя первое и второе, что вообще ничего не понятно…
Я вообще слабо понимаю, что имел ввиду Гилберт. Слово «фантазия» для меня слабо определено. Попытался свое понимание Гилберта описать с объяснением, что в данном случае есть фантазия.
Математика действительно требует хорошей гибкости ума и внимание, чтобы удержать в уме сложную модель. Но при этом математика — это набор правил, формальных, синтаксических, от которых не отклоняются. Решения задач — это формулы, правила с которыми строго определены. Одна механика.
В посте я больше подразумевал науки, которые изучают природу. Математика в принципе — это аппарат для них.
Математика действительно требует хорошей гибкости ума и внимание, чтобы удержать в уме сложную модель. Но при этом математика — это набор правил, формальных, синтаксических, от которых не отклоняются. Решения задач — это формулы, правила с которыми строго определены. Одна механика.
В посте я больше подразумевал науки, которые изучают природу. Математика в принципе — это аппарат для них.
Математика, в принципе, обладает целым рядом различных ипостасей. Для науки, которая изучает природу математика, действительно, лишь аппарат. Для Анжелы Львовны, поэтессы с богатым внутренним миром и тройкой по математике — это сухой набор формул и вообще для людей без чувства прекрасного.
Но для математиков математика — это чистая фантазия. Коль скоро любая естественная наука обнимает лишь малую часть математики, их взгляд на математику можно считать однобоким, весьма унылым и очень прикладным. Настоящая математика — это не наука в общем смысле: нельзя сформулировать область ее интересов, нельзя адекватно описать математический опыт и так далее.
Фантазия для того, чтобы держать в голове правила и модели, не требуется. Для того чтобы создать их, применять их и открывать их миру — нужна не просто фантазия, а, пардон, ФАНТАЗИЯ.
Возможно, я математический романтик, но мне грустно слышать о том, что математика — это набор правил. Правила в ней — это маленький кусочек проекции математики на околоматематический мир в лучшем случае.
ИМХО.
Но для математиков математика — это чистая фантазия. Коль скоро любая естественная наука обнимает лишь малую часть математики, их взгляд на математику можно считать однобоким, весьма унылым и очень прикладным. Настоящая математика — это не наука в общем смысле: нельзя сформулировать область ее интересов, нельзя адекватно описать математический опыт и так далее.
Фантазия для того, чтобы держать в голове правила и модели, не требуется. Для того чтобы создать их, применять их и открывать их миру — нужна не просто фантазия, а, пардон, ФАНТАЗИЯ.
Возможно, я математический романтик, но мне грустно слышать о том, что математика — это набор правил. Правила в ней — это маленький кусочек проекции математики на околоматематический мир в лучшем случае.
ИМХО.
Математика — это наука о разнообразнейших свойствах количества.
Для применения известных свойств — нужно строго следовать их сути, описанной формулами. Воображение не нужно.
Для поиска новых — нужно иметь очень сильное воображение, чтобы угадать, что какое ещё свойство есть.
Для применения известных свойств — нужно строго следовать их сути, описанной формулами. Воображение не нужно.
Для поиска новых — нужно иметь очень сильное воображение, чтобы угадать, что какое ещё свойство есть.
За что минус? Возразите словами, плиз.
О свойствах количества — это арифметика. 99 с лишним процентов математики же — это наука о свойствах формул, фигур, уравнений, преобразований и алгоритмов ;-)
Но формулы и уравнения — они же тоже все либо про количества непосредственно, либо про свойства формул и уравнений, что, по сути, всё равно свойства количества, только второго и более глубоких порядков. Фигуры в геометрии — тоже, можно сказать, воплощение количества тех или иных характеристик пространства. Алгоритмы в математике — тоже про свойства количества или про свойства его свойств.
Проще сказать, что вся математика — наука о множествах и их свойствах. Иногда множества соответствуют каким-то «количествам», но чаще сами по себе.
Да, я слышал такое определение. Но о каких ещё свойствах множеств, кроме количества, идёт речь?..
С другой стороны, множества элементов — это лишь про целочисленные количества, а вообще количества бывают и не целочисленными, и вообще не в виде числа, а например в виде расстояния вдоль кривой или объёма нескольких сложных фигур. Понятие количества, само по себе, мне видится существенно более фундаментальным.
С другой стороны, множества элементов — это лишь про целочисленные количества, а вообще количества бывают и не целочисленными, и вообще не в виде числа, а например в виде расстояния вдоль кривой или объёма нескольких сложных фигур. Понятие количества, само по себе, мне видится существенно более фундаментальным.
Кривая или сложная фигура — множество бесконечно малых точек, длина или объём — производные характеристики от этого множества.
А точка — это тройка координат, а координата — вещественное число, а вещественное число — множество рациональных чисел, меньших его, а рациональное число — тройка (знак, числитель, знаменатель), а числитель и знаменатель — натуральные числа (или ноль), а натуральное число N — множество (N-1) U {N-1} (а ноль — пустое множество). Так что всё сводится к основам :)
Множество всех бесконечно малых точек в любом объеме — бесконечно.
Ну и что?
Всё равно разные множества дадут разные объёмы фигур. Несмотря на то, что все эти множества бесконечны.
Всё равно разные множества дадут разные объёмы фигур. Несмотря на то, что все эти множества бесконечны.
Бесконечности очень разные бывают, это в математическом анализе тоже проходят…
Бесконечности очень разные бывают, это в математическом анализе тоже проходят
В круге диаметром 10 единиц в точности столько же точек, сколько в круге единичного диаметра (т.к. можно построить биекцию). Метрика мало связана с мощностью бесконечных множеств, это внешняя функция.
Множество точек окружности тоже бесконечно, но тут трюк про биекцию с кругом единичного диаметра не пройдёт;-)
Ну, я прекрасно знаю о классификации бесконечных множеств и континуум-гипотезе. И то, что числа и, соответсвтенно, понятие кол-ва можно сделать производными от множеств. Просто рассуждать о геометрии только в терминах включений множеств врядли выйдет. Это вотчина топологии, где метрика не важна.
В чём проблема? Геометрия, в первую очередь, определяется множеством перемещений плоскости (или пространства), т.е. отображений множества в себя, «сохраняющих расстояние». Отсюда можно ввести и само расстояние между парами точек, как инвариант этих отображений. Плюс у нас есть аксиома о точках на луче, которая сразу даёт биекцию между точками открытого луча и вещественными числами — всё замечательно описывается в терминах множеств. А после того, как мы научимся делить плоскость на квадратики определённого размера, мы и площадь фигуры определим через включение множеств, как это и делается в теории меры.
Это не проблема с точки зрения методологии — вся математика, включая геометрию, зиждется и выводится из набора аксиом, описывающих свойства множеств. Проблема скорее практическая — в жизни в ответ на вопрос «какова площать этой фигуры» мы хотим слышать простой и понятный ответ в виде конкретного числа, а не сложные выкладки с включениями множеств. Да и решать проблемы, используя преобразования и расстояния, гораздо проще и привычней, чем работать с включениями множеств (во всяком случае, мне).
Если эта фигура не относится к некоторым элементарным, то для определения площади тому, у кого вы о ней спросите, всё равно придётся рассматривать её, как множество. И пользоваться свойствами вроде «площадь объединения равна сумме площадей фигур минус площадь пересечения», «если одна фигура лежит внутри другой, то площадь первой не меньше площади второй»… или идти на поклон к матанализу, где интеграл определяется опять же в терминах включения множеств.
Математика зиждется на куче эвристик, а вывод её из того или иного набора аксиом (которые тоже, кстати, эвристики) — лишь один из способов пытаться её формализовать. Неудавшийся и поныне, кстати. (пруф в книжке Мориса Клайна «Математика, утрата определённости»)
Почему же не пройдёт? Если грубо — то берём направление и длину радиус-вектора точки на круге, потом записываем биты их двоичных записей через один, получаем двоичное число — это направление на точку окружности. К сожалению, будут проблемы с центром круга и двойным представлением двоично-рациональных чисел, но и их можно обойти. Так что биекция между кругом и окружностью строится. А площади у них разные :)
Почему же не пройдёт?
Круг изоморфен сфере без точки, которая изоморфна плоскости (преобразование Римана). А мощность плоскости больше мощности одномерного отрезка.
Да и если бы такое преобразование существовало, оно задавало бы линейный порядок на множестве комплексных чисел, а такого порядка не существует.
Линейный порядок на комплексной плоскости задаётся легко: (a1+i*b1<a2+i*b2) == (a1<a2 || (a1==a2 && b1<b2)). Он не инвариантен относительно умножения, но для порядка это не обязательно. А отрезок и плоскость имеют одинаковую мощность — мощность континуума.
наука о множествах и их свойствахКажется, подозрительно близко к ООП;-)
Хорошее замечание. Видимо, и структура математики, и ООП возникли из одного и того же факта — что мы воспринимаем Вселенную как набор объектов.
подозрительно близко к ООП
Нет, не близко. Математические объекты не активны, они не выполняют никаких действий, не имеют состояний, они вечны и неразрушимы в бесконечном мире чистых идей. Человек может выполнять преобразования над объектами, получая новые объекты из этого мира.
Функциональное программирование гораздо более близко математике, чем ООП.
только второго и более глубоких порядков.«Социология — это та же атомная физика, только намного более глубокого порядка. Ведь общество состоит из людей, люди — из клеток, клетки — из молекул, молекулы — из атомов. Так что зная совсем всё об атомах, из этого можно, в принципе, за энное количество итераций, вывести законы социологии.» Только вот в реале даже двухатомную молекулу не научились рассчитывать аналитически (более того, даже задачу трёх тел не научились решать)…
Чистая математика — это такой предмет, где мы не знаем, о чем мы говорим, и не знаем, истинно ли то, о чем мы говорим. (с)Имеет мало общего с программированием. Согласен с автором по поводу креативности.
Ну так философия сидхов, а как вы хотели?
Да, выглядит разумным хотя бы потому, что включает в себя интерпретацию здравых принципов:
— YAGNI
— DRY
— fail fast (let it crash)
— YAGNI
— DRY
— fail fast (let it crash)
Мне кажется, что речь в основном идет про KISS.
Почему люди всегда из одной крайности бросаются другую.
Почему из крайности чрезмерной абстрактности и оптимизации нужно бросаться в жесткий и глючный код без ооп и паттернов, который ни на шаг не отступает от текущего желания заказчика.
Разве единожды написанный код остается неизменным навсегда, разве его не нужно поддерживать?
Разве заказчик всегда абсолютно точно знает чего он хочет?
Главное это баланс, между этими двумя подходами. Хорошая архитектура сорханит огромное количество времени и сил в будущем. Ваш подход не даст затянуть проект на миллионы лет.
Почему из крайности чрезмерной абстрактности и оптимизации нужно бросаться в жесткий и глючный код без ооп и паттернов, который ни на шаг не отступает от текущего желания заказчика.
Разве единожды написанный код остается неизменным навсегда, разве его не нужно поддерживать?
Разве заказчик всегда абсолютно точно знает чего он хочет?
Главное это баланс, между этими двумя подходами. Хорошая архитектура сорханит огромное количество времени и сил в будущем. Ваш подход не даст затянуть проект на миллионы лет.
А разве Вы всегда знаете будущие желания заказчика? Да, писать жесточайший хардкод — не круто и не практично. Но писать универсальное и гибкое решение на все случаи жизни, когда от тебя требуют простое и быстрое это еще менее правильно. Простой пример: у моего знакомого при устройстве на работу попросили написать простой 2D пинбол в качестве тестового задания. Он провозился около 2х недель и не смог его сделать. Когда я узнал причину мне было одновременно и смешно, и грустно: он не смог осилить реальную физику. Он посчитал, что простые правила угол падения равен углу отражения — не покрывают всех возможноей и вдруг от него хотят чего-то больше. Начал реализовывать реальную физику и когда реализовал что-то более менее похожее понял, что все это дело отжирает ресурсов как хорошая трехмерная игра. Вывод только один: не надо угадывать что нужно заказчику. Надо у него это спросить.
Я не призываю делать универсальное во всех планах решение или угадывать что нужно заказчику. Просто проектировать с пониманием того, что некоторые требования заказчика могут измениться.
Например, если заказчик просит написать ему 2 отчета. Мой тезис, что появление третьего отчета лишь вопрос времени. Я не призываю реализовывать все возможные отчеты. Или например заказчику нужны отчеты в определенном формате, стоит понимать, что через некоторое время может появиться новый формат.
В вашем примере я предлагаю не хардкодить физику внутри объектов, а вынести движок в отдельный уровень абстракции и реализовать простую физику. В этом случае объем работ будет почти тот же, зато если понадобится реализовать реальную физику сделать это будет гораздо проще.
Например, если заказчик просит написать ему 2 отчета. Мой тезис, что появление третьего отчета лишь вопрос времени. Я не призываю реализовывать все возможные отчеты. Или например заказчику нужны отчеты в определенном формате, стоит понимать, что через некоторое время может появиться новый формат.
В вашем примере я предлагаю не хардкодить физику внутри объектов, а вынести движок в отдельный уровень абстракции и реализовать простую физику. В этом случае объем работ будет почти тот же, зато если понадобится реализовать реальную физику сделать это будет гораздо проще.
Я с Вами согласен. Если мне ничего не будет стоить по времени сделать немного абстрактней — без проблем. Но обычно это выливается в миллионы CMS, Framework'ов и других «супер крутых велосепедов», когда надо-то было сделать типовой проектик. Большинство программистов, с кем я общался — не чувствуют грани между «я облегчаю себе этим жизнь вбудущем» и «я делаю никому не нужный комбайн, который никогда не будет применен на практике». Я недавно (около года назад) начал писать изометрическую игру в качестве хобби и для того, чтобы освоиться с canvas\HTML5. Сначала я создал себе список задач, который вел к получения универсального супер движка, на котором можно написать супер крутую игру любой сложности ) Продержался около 3 месяцев и понял, что интерес пропадает, так как кроме абстрактного движка у меня ничего нет. И я поменял концепцию: я начал писать только то, что мне нужно для этой игры и в данный момент. В итоге я имею: 5к строк говнокода на сервере + около 12 к строк говнокода на клиенте, который приходится часто пилить под новые задачи. НО! этот говнокод я написал за те же 3 месяца. Потом я еще около месяца потратил на причесывание кода (сказалось отсутствие опыта в JS). В итоге подход «ситха» — 4 месяц и готовый проект, подход «джедая» — 3 месяца и крутой движек, которой написан был на 30% и ни разу не опробованный в действии. Сейчас я уже в свою удовольствие допиливаю проект и добавляю абстракции где это действительно необходимо.
А в мире есть только 2 подхода «ситхов» и «джедаев»? Я призываю вас искать баланс. Если есть какая-то фишка которую долго или сложно реализовывать — реализуйте криво, но предусмотрите возможность безболезненной замены кривой реализации на правильную.
В случае своего проекта не важно как это сделано, ведь он нужен только вам. Но проект заказчика сегодня реализуете вы, а через год может дорабатывать кто-то другой. Да, проблему поддержки кода будет не ваша, но я боюсь представить каково будет поддерживать проект написанный тремя разными командами по пути «ситхов». В результате заказчику вместо доработки проекта придется его целиком переписывать.
В случае своего проекта не важно как это сделано, ведь он нужен только вам. Но проект заказчика сегодня реализуете вы, а через год может дорабатывать кто-то другой. Да, проблему поддержки кода будет не ваша, но я боюсь представить каково будет поддерживать проект написанный тремя разными командами по пути «ситхов». В результате заказчику вместо доработки проекта придется его целиком переписывать.
Пропробуйте у заказчика спросить что для него важнее: сделать быстро и за малые деньги, запуститься и начать получать профит, а только потом думать о развитии или сделать качественно и дорого, но зато всегда можно дешево развивать? Я думаю процентов 90 проголосуют за первый вариант, так как пока Вы делаете качественно я сделаю быстро и займу Вашу нишу. Я не призываю писать говнокод. Я призываю писать за деньги заказчика то, что хочет заказчик, а не то, что Вы считаете, что он хочет. А по поводу баланса: серебрянной пули нет. Зависимость, к сожалению, между качество и скоростью совсем нелинейна. Вы не сможете делать и среднего качества продукт и потратить всего на 50% больше времени. Скорее всего повышение качества на уровень увеличит трудозатраты на порядок. Очень интересная книжка у ДеМарко на эту тему есть. Прочитал на одном дыхании. Называется «Роман об управлении проектами»
сделать быстро и за малые деньги, запуститься и начать получать профит, а только потом думать о развитии или сделать качественно и дорого, но зато всегда можно дешево развивать?
Вы исходите из предположения, что бизнес заказчика какой-то стартап?
Но зачастую бизнес обращается к (новым) разработчикам, потому что текущие решения не успевают или явно вот-вот перестанут успевать за развитием бизнеса из-за первоначальной архитектурной жесткости, нерасширяемости и т. п. Текущие потребности бизнеса худо-бедно обеспечены, но он хочет в будущем быстрой реакции на новые потребности. Вот и «приходится» создавать конструкторы в которых большинство новых требований реализуются (ну или должны реализовываться) декларативным описанием новых сущностей и правил их взаимодействия чуть ли не рядовым менеджером на естественном языке за несколько минут.
Я не имею ничего против. Я уже раз десять повторил, что надо исходить из требований заказчика. Если мне скажут сделать супер гибкую систему и не важно сколько времени\денег — за их деньги любой каприз. Но зачастую получается, что заказчик хочет просто сайт-визитку, а разные студии заставляют его еще платить за супер цмс и миллионны часов разработки, что позволит ему расширить визитку до магазина (сам работал в такой судии. По сути развод клиентов на деньги). И так как заказчик не понимает что это такое, то платит. А на самом деле можно было за 2 часа и 1000 рублей сверстать одну страницу и все.
Развод клиентов на деньги совсем другая ситуация. Я скорее про затягивание сроков (по крайней мере в рабочих часах, а не календарных) из-за желания программистов сделать «красиво» в рамках фиксированного бюджета.
Насчёт ЦМС — на то они и ЦМС, чтоб не писать каждый раз заново под нового заказчика, а копировать типовую. Или вообще держать всех заказчиков на одном сервере и единственном работающем экземпляре этой ЦМС.
Такой подход неплохо работает в схеме, взяли проект, быстро написали, сдали и забыли.
Можно организовать работу по другому: Разбить проект на этапы, сделать минимально необходимый функционал, выделив большие и сложные куски на последующие этапы. Клиент будет видеть как продвигается проект, корректировать направление развития (реализовывать функционал в зависимости от его нужд). Оплату тоже можно делать поэтапно, тогда клиент видит за что он платит. Возможно на каком-то этапе клиент поймет, что ему нужно не то что он просил или ему нужно что-то еще, чего он не просил.
Выбор из этих двух подходов сильно зависит от самого проекта, в частности его размера и сложности.
Но это все не проблемы разработки. Это проблемы управления проектом и взаимодействия с заказчиком.
Можно организовать работу по другому: Разбить проект на этапы, сделать минимально необходимый функционал, выделив большие и сложные куски на последующие этапы. Клиент будет видеть как продвигается проект, корректировать направление развития (реализовывать функционал в зависимости от его нужд). Оплату тоже можно делать поэтапно, тогда клиент видит за что он платит. Возможно на каком-то этапе клиент поймет, что ему нужно не то что он просил или ему нужно что-то еще, чего он не просил.
Выбор из этих двух подходов сильно зависит от самого проекта, в частности его размера и сложности.
Но это все не проблемы разработки. Это проблемы управления проектом и взаимодействия с заказчиком.
Но обычно это выливается в миллионы CMS, Framework'ов и других «супер крутых велосепедов», когда надо-то было сделать типовой проектик.1) Вам предлагают не «миллионы CMS и Framework'ов», а пока только один уровень абстракции. Вполне вероятно, что им дело и ограничится. 2) У начинающего разработчика за спиной обычно ещё нет «типовых» проектов. Есть даже мнение, что наличие таковых является отклонением от нормы, и, когда таковые появляются, надо переходить на более высокий уровень;-)
У вашего знакомого, в общем, просто был недостаток опыта. Причём опыта, скорее, не «исполнительского», а «менеджерского» (точнее «исполнительского» — опыта, а у «менеджера» это скорее будут просто «знания»). Теперь он знает, сколько (хотя бы по порядку) человеко-часов и вычислительных ресурсов требует реальная физика (интересно, а шарик у него был материальной точкой или обладал ещё и моментом инерции?), какие в её использовании риски и почему этот вопрос нужно «не отходя от кассы» прояснять у заказчика.
В его защиту, точнее, в защиту его образа действий, можно сказать то, что иногда бывает так, что переспросить у заказчика невозможно, и вообще «привычка переспрашивать плохо характеризует командира».
Насчёт знания будущих желаний заказчика — умение частично предугадывать будущие желание заказчика — вещь нужная и полезная, но 1) в основном руководителям и 2) приходит обычно с опытом.
В его защиту, точнее, в защиту его образа действий, можно сказать то, что иногда бывает так, что переспросить у заказчика невозможно, и вообще «привычка переспрашивать плохо характеризует командира».
Насчёт знания будущих желаний заказчика — умение частично предугадывать будущие желание заказчика — вещь нужная и полезная, но 1) в основном руководителям и 2) приходит обычно с опытом.
Я бы сказал, что главная проблема в другом — он, видимо, ударился в самую сложную (и, наверное, самую интересную для него) часть, решив реализовать её близко к идеалу, вместо того, чтобы в кратчайший срок выкатить простейший интерфейс с простейшим физ. движком (а-ля «прототип») и спросить развитию чего отдать приоритет. Это было бы уже не переспрашивание на пустом месте, а уточнение по приоритетам при наличии «плана действий». Командиру поставили задачу разгромить противника и занять высоту N, а он, оценив силы свои и противника и набросав общий план, уточняет, что быстрее нужно — разгромить или занять? А то может получиться, что разгромит, а занимать некому будет. Или нечего :) Или займёт, но вынудив противника отойти без боя и, как следствие, без потерь.
Я бы сказал, что главная проблема в другом — он, видимо, ударился в самую сложную (и, наверное, самую интересную для него) часть, решив реализовать её близко к идеалу«Лучше предположить худшее и, может быть, получить приятный сюрприз, чем понадеяться на лучшее и, может быть, получить облом и разочарование». «Хуже — значит сложнее». Есть такие принципы, только не всегда срабатывают, особенно вместе…
Начинать с решения самой сложной из предстоящих задач — особенно, когда её решение критично для проекта в целом — очень здравый поход. Ибо решить всё остальное, а на ней обломаться — хуже, чем обломаться на ней сразу, и не тратить время на уже ненужное остальное.
Решать задачу, не будучи уверенным в том, что решение возможно, — это не «разработка», а «исследования», заниматься ими лучше до работы над проектом, за который заказчик платит деньги, а не во время неё.
Да, но за пределами проекта в ближайшей перспективе эта задача может вообще не иметь ни применения, ни смысла. Разве что придумать интересный хобби-проект специально для неё?
Исследования могут быть частью проекта.
Т.е., мы знаем, что это может быть решено, но пока не знаем как — пока пишутся другие части проекта один из разработчиков занимается исследованием.
Т.е., мы знаем, что это может быть решено, но пока не знаем как — пока пишутся другие части проекта один из разработчиков занимается исследованием.
Исходя из слов «а на ней обломаться» я предположил более худший расклад — что мы не знаем, может ли это быть решено вообще…
«Мы отлично знаем, что она не имеет решения! Мы хотим знать, как её решать!»
знать, как её решать… или обойти…
Верно. В процессе исследования может выяснится, что в текущей постановке задача решения не имеет, но если подумать, то возможно какое-то из списка требований нам на самом деле не столь критично, или скажем того же результата можно достичь иначе… В общем, не обязательно на самом деле начинать со самой сложной задачи.
Не совсем. По мере приближения к сложной части станет более понятно, какие к ней в действительности требования, какие масштабы входных данных, какая степень приближения допустима… Вполне может оказаться, что там совсем не та задача, какой она казалась сначала. Или что её можно заменить на суперэвристику, неотличимую по поведению от истинной задачи.
Если мы ограничены дедлайном, то что лучше: предъявить по наступлению заказчику нечто вообще неработающее в его понимании (физдвижок пинболла, застрявший где-то на уровне оптимизации расчетов релятивистских и квантовых эффектов при трении о поверхность и воздух и взаимодействия с магнитным полем Земли во время пуска шарика, но не дошедший ещё до расчетов столкновений, причем без всякого GUI) или функционально законченное приложение, пускай и не в полную меру реализующее ТЗ (есть юзабельный GUI, есть примитивный движок, причем они разделены каким-то абстрактным интерфейсом и могут доводиться до ума независимо)? Даже не говоря вероятности что это окажется именно тем, что и хотел заказчик, то в каких случаях больше вероятность продолжения проекта (пускай уже и другим разработчиком, но не с нуля)?
Смотря что заказчик считает задачей… В данном случае, реальная физика была, как я понял, очень опциональной фичей, этаким бонусом для вау-эффекта, и на неё время тратить стоило в начале очень ограниченно, не увлекаясь. Лишь оценить потенциальные затраты и требования к внутреннему API, и усилием воли вернуться к вопросу реализации без неё.
Хотя, могу представить себе затею пинбола, опирающуюся именно на физику, то есть изначально оправдываемую лишь тем, что в игре будет физика, и именно этим игра должна будет привлекать покупателей. Тогда заказчика недоделанный движок восхитит сильнее прототипа GUI.
Если на этом не было сделано акцента в ТЗ, то маловероятно. И то, скорее стоило сделать простую реализацию, интерфейс к ней, а потом пилить более точную физику, чтобы в любой момент можно было продемонстрировать/сдать готовое приложение.
Мне кажется, тогда надо тем более сначала делать прототип GUI (вместе с интерфейсом к физике) как намного более лёгкую часть, к тому же облегчающую работу с движком;-)
Это именно та ошибка, от которой спасает приведённое мною соображение. Для отладки физического движка весь GUI пинбола не нужен, нужны частные специализированные тесты, которые даже могут не быть графическими.
Жесткий код — не глючный код без ооп (иногда он даже с паттернами). Это парадокс такой — концентрирование на жесткости и краткости приводит к гибкости, только вынужденной. Жесткий код — совсем не глючный код. Под жесткостью как раз понимается не то, что его нельзя читать или менять, а то, что в нем максимум ограничений для работы программы ровно в заданном русле.
Вам же, когда надо завести переменную int, не приходит в голову сразу, наперед, дать ей тип double? Ведь в последнем случае код будет более гибким. Double может работать и с целыми числами и если вдруг в будущем понадобится, с плавающей точкой.
Вам же, когда надо завести переменную int, не приходит в голову сразу, наперед, дать ей тип double? Ведь в последнем случае код будет более гибким. Double может работать и с целыми числами и если вдруг в будущем понадобится, с плавающей точкой.
Мне приходит в голову использовать динамическую типизацию :)
Переменные — вообще зло, константы намного лучше;-) (оговорюсь сразу, я веду речь о Java). У меня в Eclipse реально стоит опция чтоб «финалить» все переменные (какие можно) при сохранении кода…
Вам же, когда надо завести переменную int, не приходит в голову сразу, наперед, дать ей тип double? Ведь в последнем случае код будет более гибким. Double может работать и с целыми числами и если вдруг в будущем понадобится, с плавающей точкой.
Уже раз 10 спотыкались об этот выбор int вместо double. И будем спотыкаться дальше…
Действительно, int выглядит предпочтительнее, особенно, когда этих объектов приходится много хранить в памяти (экономия 4 байта), или когда они являются частью формата, разрабатываемого «на века» — можно свободно выбирать разрядность и не зависеть от этого странного IEEE 754 — вдруг производителям придёт в голову его поменять? Кроме того, арифметика, вроде бы, быстрее (хотя уже линейную интерполяцию лучше делать на double, по крайней мере, для процессоров Intel). Но каждый раз при использовании целых чисел надо выбирать и точность представления данных, и диапазон, в котором они могут находиться. И тут принцип «640 КБ хватит всем» стреляет изо всех стволов :)
Указывать границы области сканирования с точностью до градуса? Точнее глаз всё равно не оценит! (позже эти области стали браться из других частей программы, и там речь пошла об угловых минутах). Хранить координаты точек в виде 24-битных чисел с шагом 100 микрон (диапазон от -800 до 800 метров)? Точность сканера всё равно 150-200 мкм, а дальность — до 30 м, так что хватит… (позже метрологи стали изучать статистку шума измерений, а геодезисты — смещать начало системы координат на 5 км, и те и другие были недовольны. Да и характеристики сканера улучшились, 100 мкм сейчас — граница между «отличным» и «хорошим», а дальность стала 150-200 м). Работать с углами в диапазоне от 0 до 360 гр, используя переполнение unsigned int для отработки перехода через ноль? Отличное решение! (сейчас некоторым заказчикам зачем-то понадобился диапазон не от от 0 до 720, не то от -360 до 360. Вроде бы код удалось прочистить, но ловить ошибки придётся ещё долго). Длина секции укладывается в 32 бита? (не смешите мои подковы...)
Сейчас в очередном формате собираюсь использовать 48-битные координаты с шагом 1 микрон. Этого хватит, чтобы поместилась вся Земля с началом координат в любой точке внутри или на поверхности. Как вы думаете, этого «хватит всем»?
Поддержу. Давно пришел к выводу, что для каких-то значений в принципе не целых (по большому счету всё кроме нумерации и количества элементов, смещений и т. п. в массиве/списке/множестве/...) нужно использовать float по умолчанию (не забыв про эпсилон при сравнении), а лишь потом оптимизировать через integer, если в том возникнет нужда. А то и вообще спрятаться от конкретной реализации за абстрактным числовым классом. А так выбор integer, да ещё с каким-то множителем/делителем исходя из соображений быстродействия/памяти — типичная преждевременная оптимизация.
Вы смотрите с позиции оптимизации. Если выбор пал на int только потому, что он меньше в памяти занимает и якобы хватает — то это, понятно, не верно.
Я имею ввиду, если переменная должна хранить по смыслу количество или что-то, счетное. Double — тоже может. Но такой выбор — потенциальный баг
Я имею ввиду, если переменная должна хранить по смыслу количество или что-то, счетное. Double — тоже может. Но такой выбор — потенциальный баг
Ситхи любят баги. Их ждут, их уважают. Как только встречается баг, ситх бросает всё и уделяет внимание только ему. У багов такая природа: пока не выяснили причину, не известна важность и урон бага. Если в программе проявился баг – программа теряет доверие. Лучше ей не работать.
Основная причина, по которой обнаружение бага (или любого другого неожиданного поведения) так радует — что после его исправления эффективность программы (и быстродействие, и качество результатов) вполне может перейти на новый уровень. Кроме того, за время охоты можно найти много интересного (но пока не проявившегося) и в других местах программы.
Почти согласен насчёт исключений. Как-то раз довелось поработать с человеком, который панически боялся того, что исключение может каким-то образом прорваться к пользователю, потому что исключение нанесёт пользователю непоправимую психологическую травму. Именно поэтому КАЖДЫЙ метод в его коде был окружен в try...cath, 90% из которых были абсолютно глухими — т.е. просто игнорировали ошибки. Некоторые ошибки он складывал в лог и ни одну не выпускал наружу, даже те ошибки, в которых был явно виноват сам пользователь, например ошибки ввода и др. К счастью наше сотрудничество было не очень долгим, но в итоге моральную травму получил я, потому что пришлось переписывать после него три тонны винегрета.
Падать при любом исключении — явно не комильфо, исключения нужно делить по критичности на разные уровни но в общем идея правильная.
1. Делить исключения по критичности. Некоторые стоит показать пользователю, на некоторых стоит завершить работу программу, а иногда — просто повторно вызвать метод, выдавший исключение.
2. Не пытаться объять необъятное и предусмотреть 100% возможных исключений в 100% кода. Код распухает и становится неоптимальным и нечитабельным.
3. Никогда не надеяться на то, что кто-нибудь когда-нибудь захочет почитать логи. Логи существуют для срочного решения проблем на удалённых площадках, куда нельзя нормально добраться со средствами разработки.
Падать при любом исключении — явно не комильфо, исключения нужно делить по критичности на разные уровни но в общем идея правильная.
1. Делить исключения по критичности. Некоторые стоит показать пользователю, на некоторых стоит завершить работу программу, а иногда — просто повторно вызвать метод, выдавший исключение.
2. Не пытаться объять необъятное и предусмотреть 100% возможных исключений в 100% кода. Код распухает и становится неоптимальным и нечитабельным.
3. Никогда не надеяться на то, что кто-нибудь когда-нибудь захочет почитать логи. Логи существуют для срочного решения проблем на удалённых площадках, куда нельзя нормально добраться со средствами разработки.
У МакКоннелла в «Совершенном коде» обработке ошибок посвящена целая глава — одна из немногих в этой книге, в которых я лично для себя почерпнул что-то существенно новое и полезное. Там ещё зависит от критичности программы: при расчёте дозы облучения при радиотерапии лучше аварийно завершить программу, ошибку отрисовки можно и пропустить…
В смысле, ошибку отрисовки в редакторе электронных таблиц.
ХМ. Забавно. Вообще то концепция ООП подразумевает, что каждый модуль(тобиш класс) — это абсолютно самостоятельная и независимая единица. На практике такого добиться удается редко, но цель — известна.
А если написать хардкор правильно (в лучших традициях жанра ООП) — то он автоматически становиться практически бесконечно расширяемым.
Короче отпадает большинство проблем, если знать теорию и пытаться её придерживаться.
НО! Есть одно маааааленькое НО: для этого нужен моск ;-)
А если написать хардкор правильно (в лучших традициях жанра ООП) — то он автоматически становиться практически бесконечно расширяемым.
Короче отпадает большинство проблем, если знать теорию и пытаться её придерживаться.
НО! Есть одно маааааленькое НО: для этого нужен моск ;-)
Единственное зерно рациональности, с которым могу согласиться: наша задача сделать заказчика HAPPY как можно быстрее. Но это не значит, что нужно реализацию всех методов начинать с вставки туда try...catch, после чего пожно лить туда откровенную халтуру. Надо хотя бы немного задумываться во что выльется плохой код.
Желание делать код гибким — от лени. Разработчик имеет свои собственные идеи, что в дальнейшем может происходить с его продуктом и потому старается минимизировать свою работу в будущем. Если прогноз был верный — он на коне. Если нет — проиграл вдвойне: создавая «лишнее» сейчас да еще и поддерживая это потом.
На стройке двое рабочих носят кирпичи. Один берет по 10 штук, второй носит по одному. Прораб подходит ко второму и говорит
— Ты что же это творишь? Вон человек надрывается, а ты по одному таскаешь?
— Я что виноват в том что он ленивый?
— ???
— Лично мне не лень лишний раз сходить.
Так же и у вас. Желание оптимизировать разработку с прицелом на будущее списываете на лень.
Просто меру нужно знать.
Совсем плохая ситуация, когда версия ПО, в которой доработок максимум на версию на 1.0.1 превращается в 2.0 потому что весь старый код нужно выбросить и переписать с нуля, потому что вариантов его доработок не предусмотрено и внутри всё отлито одним неразделимым куском.
— Ты что же это творишь? Вон человек надрывается, а ты по одному таскаешь?
— Я что виноват в том что он ленивый?
— ???
— Лично мне не лень лишний раз сходить.
Так же и у вас. Желание оптимизировать разработку с прицелом на будущее списываете на лень.
Просто меру нужно знать.
Совсем плохая ситуация, когда версия ПО, в которой доработок максимум на версию на 1.0.1 превращается в 2.0 потому что весь старый код нужно выбросить и переписать с нуля, потому что вариантов его доработок не предусмотрено и внутри всё отлито одним неразделимым куском.
Еще хуже, когда из 12 месяцев разработки нового продукта 6 было отведено на построение гибкой архитектуры, чтобы «расширять потом». А развите продукт не получил. В итоге 6 месяцев работы в пустую. А может если бы выпустили на эти 6 месяцев раньше — продукт бы и взлетел. Как написал cjey нужно искать баланс. Но сделать это практически нереально. В итоге все скатывается либо в говнокод, либо в космолет с сотнями тысяч строк кода. Но все разработчики считают, что это тот самый баланс.
С другой стороны плохо, когда взлетевший проект умирает потому, что заказчик не согласен с ценой развития продукта.
Когда для замены масляного фильтра необходимо полностью разобрать двигатель.
Нужен анализ причин почему не взлетел продукт. Плохо написан? С гибкостью разработки это редко связано. Не соответствует потребностям рынка? Это ошибка бизнес-аналитиков и маркетологов. Что-то было не учтено при составлении проекта. Если есть некое видение развития продукта, то разработчик обязан это видение учитывать и не поддаваться на провокации «давайте сейчас очень по-быстренькому как-нибудь напишем первую версию, а потом будем постепенно дорабатывать». Практика показывает, что при таком подходе во второй версии переписывается 50-60% кода, а процентов 20 монолитного кода, в котором просто не смогли разобраться становится пудовой гирей, которая тянется за проектом в будущем и тормозит его развитие.
Когда для замены масляного фильтра необходимо полностью разобрать двигатель.
Нужен анализ причин почему не взлетел продукт. Плохо написан? С гибкостью разработки это редко связано. Не соответствует потребностям рынка? Это ошибка бизнес-аналитиков и маркетологов. Что-то было не учтено при составлении проекта. Если есть некое видение развития продукта, то разработчик обязан это видение учитывать и не поддаваться на провокации «давайте сейчас очень по-быстренькому как-нибудь напишем первую версию, а потом будем постепенно дорабатывать». Практика показывает, что при таком подходе во второй версии переписывается 50-60% кода, а процентов 20 монолитного кода, в котором просто не смогли разобраться становится пудовой гирей, которая тянется за проектом в будущем и тормозит его развитие.
Нужен анализ причин почему не взлетел продукт.Для этого, в общем, нужно влезть под черепную коробку к каждому потенциальному потребителю;-) Всё остальное — это, по большому счёту, только предположения с разной, и не всегда ясной, степенью приближения к действительности, и такой анализ никогда не будет точным. Надо ставить вопрос — а зачем мы хотим это знать и насколько это нам реально нужно, чтоб вовремя (по затраченному на этот post-mortem анализ бюджету и ресурсам) остановиться.
С другой стороны плохо, когда взлетевший проект умирает потому, что заказчик не согласен с ценой развития продукта.Интересно, много ли реально бывает таких случаев? Мне кажется, если первая по-настоящему взлетевшая версия внезапно оказалась «прототипом на выброс», то всё равно она должна принести достаточно денег, чтоб иметь возможность переписать с нуля… Ила заказчик принимает решение использовать по максимуму то, что есть и не вкладываться в развитие?
А это не проблема архитектуры, а проблема планирования проекта. Что мешает разбить проект на куски, быстро сделать проект с минимальным готовым функционалом, отложив большие и сложные задачи на последующие этапы. Клиент будет видеть развитие проекта, сможет корректировать направление разработки, раньше поймет какого функционала не хватает и в случае задержки будет спокойнее к ней относиться.
Да, Ваш подход идеален в рамках конкурентного рынка. С другой стороны Вы убиваете таким подходом понятие прототипа. Вы не делаете прототип, Вы делаете минимальную рабочую расширяемую версию. Я все таки привык работать с прототипами, которые не превращаются затем в продакшн, а выкидываются и переписываются. Но может я не прав )
Выкидываемые прототипы — спорная концепция (как, в прочем, и противоположный тезис, что их выкидывать нельзя), не думаю, что к ней стоит привыкать;-) Выкидываемый или расширяемый — тут всё зависит от многих факторов. На языке со статической типизацией, мне кажется, в среднем проще сделать расширяемый прототип, чем на языке с динамической типизацией: цена рефакторинга меньше…
Всё зависит от размеров проекта. Если планируется проект на срок разработки 12 месяцев силами 5+ человек, то вряд ли имеет смысл писать прототип — слишком дорогое получится удовольствие. Лучше потратить это время на составление плана разработки, вижена на будущее развитие и глубокую проработку архитектуры.
Отличная статья! Жестко, но справедливо. И в целом, на мой взгляд, все верно
Хотелось бы больше иллюстраций по вселенной SW. Мне как «креативному» программисту нужны образы, чтобы в них видеть больше чем очередной набор «галок» ;)
private void injectMembers(Object t) {
/*
. __---__
. . .-'...:...'-. . .
/ . . : .__ .\
. /........./ \ .\ . . .
/ : : :| () | :\ . .
:...........\__/....: .
. |___________________| . .
|...................| .
. : : : : : : : .
. \................./ . .
\ . . : . . / . .
. . \._........._./ . . .
-..___..- . .
Dark side code
*/
injector.injectMembers(t);
}
Перевернутая шкала ценностей – это оценки в отрицательной части – плохо, хуже, еще хуже. Не бывает хорошо, лучше. Ситхи верят, что джедаи заблуждаются в плане: бывает хороший код, бывает лучше. Не бывает. Отрицательная шкала – это кругом только зло. И ситхи вынуждены выбирать меньшее зло. Джедаи выбирают наибольшее добро. Т.е. если они видят два решения, то они видят позитивные качества и на основании своих предпочтений выбирают то, что лучше.
Только ситхи все возводят в абсолют (с)
Да, жаль, что всему этому только опыт учит. До сих пор время от времени бью себя по рукам, когда хочется реализовать функциональность «на всякий случай». Не настают эти случаи, вместо этого настают другие, которым вся эта теоретическая гибкость только мешает. К тому же заделы на будущее часто содержат вполне настоящие баги.
Вы код пишете так же как статьи? Истинный джедай
Провокация! Автор джедай!
Ситх не мог написать столько воды про котят, про самих ситхов и джедаев ибо надо «Убить в себе гуманитария» и только суть, только хардкор.
Ситх не мог написать столько воды про котят, про самих ситхов и джедаев ибо надо «Убить в себе гуманитария» и только суть, только хардкор.
Согласовано.
Читается интересно, но единственная полезная мысль здесь — не надо заниматься преждевременной оптимизацией. Все остальное — простите, бред, противоречащий здравому смыслу.
И да, статья чисто гуманитарная.
И да, статья чисто гуманитарная.
Говоря проще, лично для меня существует принцип неувеличения энтропии. Это значит, что я продолжаю искать решение, которое мне будет не лень воплощать. А мне всегда лень, поэтому я пишу мало кода. Я вообще не люблю кодить. Именно поэтому, если я увижу красивый фреймворк, который изящно (просто для программиста) решает одну мою проблему и еще 50, решения которых мне не нужны, я буду его использовать, потому что я не люблю кодить. Fuck the fuel economy. Пускай энтропия будет где угодно, только не у меня в уме.
И общий паттерн: вынужденность && конструктивность && достаточность. Чаще всего, вынужденность == бритва Оккама, конструктивность == мне лень писать много кода, достаточность == это решение не подходит, если потенциально потребует переписывания.
Общая логика: мне нужно писать как можно меньше кода:
1. мало кода — мало отладки,
2. мало отладки — больше времени на написание полезного кода,
3. мало кода — мало глюков,
4. мало кода быстрее работает**,
5. мало кода быстрее читается,
6. мало кода проще понимается,
7. мало кода проще поддерживается,
9. мало кода быстрее писать,
8. пускай софт падает тогда когда нет смысла продолжать, это лучше, чем писать много кода.
И еще: креативность нужна ДО того, как началась реализация.
Понравилась первая часть статьи, а дальше, особенно часть с фигурирующим заказчиком — нет. Почти всегда заказчик — это идиот, который вынуждает нас под свою ответственность поднимать уровень энтропии. Чаще всего, он хочет то, что не является вынужденным, даже для него. И многое другое.
И общий паттерн: вынужденность && конструктивность && достаточность. Чаще всего, вынужденность == бритва Оккама, конструктивность == мне лень писать много кода, достаточность == это решение не подходит, если потенциально потребует переписывания.
Общая логика: мне нужно писать как можно меньше кода:
1. мало кода — мало отладки,
2. мало отладки — больше времени на написание полезного кода,
3. мало кода — мало глюков,
4. мало кода быстрее работает**,
5. мало кода быстрее читается,
6. мало кода проще понимается,
7. мало кода проще поддерживается,
9. мало кода быстрее писать,
8. пускай софт падает тогда когда нет смысла продолжать, это лучше, чем писать много кода.
И еще: креативность нужна ДО того, как началась реализация.
Понравилась первая часть статьи, а дальше, особенно часть с фигурирующим заказчиком — нет. Почти всегда заказчик — это идиот, который вынуждает нас под свою ответственность поднимать уровень энтропии. Чаще всего, он хочет то, что не является вынужденным, даже для него. И многое другое.
Всё верно — до начала реализации идет работа с заказчиком. Требования обсуждаются, принимаются. Идиотские отклоняются. Идет плотное и не одностороннее общение. После принятия требований — никакого креатива.
Но считать заказчика идиотом, даже если это так, плохо. Много раз замечал тенденцию, когда программисты думают, что они лучше знают, что надо заказчику, чем он сам.
Но считать заказчика идиотом, даже если это так, плохо. Много раз замечал тенденцию, когда программисты думают, что они лучше знают, что надо заказчику, чем он сам.
Но очень часто программисты оказываются правы, если они в предметной области варятся годами, а заказчик только в неё пришел.
Считать кого-то идиотом, если это невынуждено неправильно. Это также плохо, как и много кода. Вообще, все невынужденное — это плохо.
Программисты знают лучше, что вынудит писать их много кода, а некоторые (о которых речь) делают невынужденный вывод, что в этом виноват заказчик. Это не так.
Есть и другая крайность. Все заказчики, с которыми мне приходилось работать, все до одного, хотели лишнего. Причина? Жадность. БОЛЬШЕ! БОЛЬШЕ! БОЛЬШЕ СВИСТОПЕРДЕЛОК!
Поэтому я чуть-чуть перефразирую фразу: "зачастую, программист лучше знает, что заказчику НЕ надо".
Много раз замечал тенденцию, когда программисты думают, что они лучше знают, что надо заказчику, чем он сам.
Программисты знают лучше, что вынудит писать их много кода, а некоторые (о которых речь) делают невынужденный вывод, что в этом виноват заказчик. Это не так.
Есть и другая крайность. Все заказчики, с которыми мне приходилось работать, все до одного, хотели лишнего. Причина? Жадность. БОЛЬШЕ! БОЛЬШЕ! БОЛЬШЕ СВИСТОПЕРДЕЛОК!
Поэтому я чуть-чуть перефразирую фразу: "зачастую, программист лучше знает, что заказчику НЕ надо".
Много раз замечал тенденцию, когда программисты думают, что они лучше знают, что надо заказчику, чем он сам.Мне кажется, что они лучше знать, что надо заказчику, чем он сам (точнее, лучше уметь сформулировать), — это скорее функция руководителей проекта…
Еще, может не правильно донес идею. Заказчик в посте — это не обязательно внешний заказчик. Это некий символ исходящих требований. Заказчиком может быть и сам программист. Программа обычно служит для какой-то цели, в какой-то предметной области. И код, как описание, должен ее описывать.
Плохой код — это код, в котором не видно такого описания. Конечно, почти нельзя так добиться, чтобы везде в коде было только описание того, что нужно. Но отрицательная шкала оценок кода снимает это противоречие. Код и так плохой. Хуже тот, который не имеет отношения к описанию. Еще более худший код — код, который вообще ничего не описывает. Желательно, чтобы код был читаем локально. Без знаний «архитектуры». Открыв любую страницу кода, хоть там и тысячи страниц, на ней должны читаться намерения.
К сожалению, люди с положительной шкалой скатываются в противоположность. Когда думают, что процент кода небольшой, который прямо решает задачу, а остальное — кирпичики — начинают писать программу ради программы. Это вроде как бы сняли фильм, где во всех подробностях описывается съемка фильма и ничего более. Как фильм, такой может существовать. Процент людей, которым он будет интересен — крайне мал.
А в программировании всё ровно наоборот. Таких бессюжетных фильмов те самые 95 процентов. Программисты увлекаются чем угодно, что касается самого процесса — оптимизациями, многопоточностью, паттернами с гибкостью, распределенной архитектурой. Послушайте о чем они говорят и где лежит сфера их интересов в основном.
Программист, полагая, что без всего этого не обойтись, и имея положительную шкалу оценок — ставит это во главу угла. Получается бессюжетный код.
Плохой код — это код, в котором не видно такого описания. Конечно, почти нельзя так добиться, чтобы везде в коде было только описание того, что нужно. Но отрицательная шкала оценок кода снимает это противоречие. Код и так плохой. Хуже тот, который не имеет отношения к описанию. Еще более худший код — код, который вообще ничего не описывает. Желательно, чтобы код был читаем локально. Без знаний «архитектуры». Открыв любую страницу кода, хоть там и тысячи страниц, на ней должны читаться намерения.
К сожалению, люди с положительной шкалой скатываются в противоположность. Когда думают, что процент кода небольшой, который прямо решает задачу, а остальное — кирпичики — начинают писать программу ради программы. Это вроде как бы сняли фильм, где во всех подробностях описывается съемка фильма и ничего более. Как фильм, такой может существовать. Процент людей, которым он будет интересен — крайне мал.
А в программировании всё ровно наоборот. Таких бессюжетных фильмов те самые 95 процентов. Программисты увлекаются чем угодно, что касается самого процесса — оптимизациями, многопоточностью, паттернами с гибкостью, распределенной архитектурой. Послушайте о чем они говорят и где лежит сфера их интересов в основном.
Программист, полагая, что без всего этого не обойтись, и имея положительную шкалу оценок — ставит это во главу угла. Получается бессюжетный код.
Оказывается, я ситх. И падаванов своих учу темной стороне силы…
Правда во главу я ставлю удовлетворенность заказчика, а не уменьшение кода.
Отсутствующий код не падает — заказчик доволен.
Однако отсутствующая функция расстроит его. И вряд ли заказчика удовлетворит то, что она при этом не падает.
Правда во главу я ставлю удовлетворенность заказчика, а не уменьшение кода.
Отсутствующий код не падает — заказчик доволен.
Однако отсутствующая функция расстроит его. И вряд ли заказчика удовлетворит то, что она при этом не падает.
Всегда считал, что лучший код — этот тот код, который не написан. Он не упадёт, его не нужно покрывать тестами, не нужно рефакторить, и главное — он не потребляет ресурсов!
Я каждый раз как комичу новую функциональность — сравниваю объём старого и нового файлов. Если новый больше — расстраиваюсь, значит, я налажал.
Вы хотите чтобы новая функциональность добавлялась путем удаления кода? :)
int main() {}
Предлагаю добавить функциональность уменьшив объём кода :)
Удалить что-нибудь и появится функциональность «вывод ошибки при компиляции» :)
main() {}
echo 'main() {}' > a.c && gcc a.c -o a && ./a
echo 'main() {}' > a.c && gcc a.c -o a && ./a
Вверху были комментарии о том, что топикстартер из одной крайности впадает в другую. Вы тоже?
Функциональность добавляется так.
На этапе ТЗ разработчик показывает заказчику, что именно этот модуль ему не нужен, а того же результата можно добиться комбинированием уже существующих.
Итог: функции main, как и самого модуля не будет.
На этапе ТЗ разработчик показывает заказчику, что именно этот модуль ему не нужен, а того же результата можно добиться комбинированием уже существующих.
Итог: функции main, как и самого модуля не будет.
Проект Wine был основан в 1993 году. Он представлял собой проект размером 0 байт. И был идеален по архитектуре и составу. Потом в него начали добавлять баги. Проект разрастался, к проекту стали подключаться новые разработчики, которые добавляли ещё больше багов. И поэтому при каждом новом релизе принято спрашивать «Чо опять сломали?!».Lor
Не разделяю полностью путь ситхов, но признаюсь — статья вышла оригинальная.
Подход, описанный в статье обладает сильным рациональным ядром, здоровым прагматизмом. Более того, я во многом ему следую. Но, тем не менее, по описанной шкале, я бы всё равно отнёс себя к джедаям. Я продолжаю экспериментировать с кодом, подходами, языковыми конструкциями, стилями. Почему? Прежде всего, я люблю языки, и выразительность, которую в них можно найти. Несомненно автор прав, что это поэзия. Но я считаю, что эта поэзия просто необходима для развития языков, выплавления новых идей и концепций.
Допустим, сит изучает новый язык программирования. Что он в первую очередь сделает (после изучения основ синтаксиса)? Прежде всего он почитает рекомендации по стандартам стиля написания на данном языке, идиомам данного языка и в своём коде постарается их придерживаться. Тем самым на данном этапе он уже оградил себя от возможности найти что-то новое.
Вероятно, тут нужно соблюдать баланс. В каком-нибудь toy-проджекте или «академической» либе, которую ты мейнтейнишь, можно нести добро, а в суровом продакшене переходить на тёмную сторону.
Всем DRY.
Допустим, сит изучает новый язык программирования. Что он в первую очередь сделает (после изучения основ синтаксиса)? Прежде всего он почитает рекомендации по стандартам стиля написания на данном языке, идиомам данного языка и в своём коде постарается их придерживаться. Тем самым на данном этапе он уже оградил себя от возможности найти что-то новое.
Вероятно, тут нужно соблюдать баланс. В каком-нибудь toy-проджекте или «академической» либе, которую ты мейнтейнишь, можно нести добро, а в суровом продакшене переходить на тёмную сторону.
Всем DRY.
Есть легенда, что каждый раз, когда пишут плохую статью на хабр – Бог убивает котенка. Пора признаться, что все мы – убийцы котят. У некоторых руки по локоть в крови. Первый шаг в сторону силы – признать в себе это. Любая статья – это привнесение во Вселенную хаоса. Любой символ – рост энтропии. Если мы признаем это, то спадет маска умиления и радости от написания статей. Всё, что мы делаем – плохо. И с этим нельзя ничего поделать. Можно только пытаться делать это в меньших количествах.
Автор явно попробовал и повидал многое, но еще далеко не все варианты говнокода ему попадались на тернистом пути. Силу великую я вижу в нем заложенну. Темная сторона Силы молодого джедая влечет… Почувствуй говнокода теченье!
Ну вот, оказывается я Ситх уже давно :(
Блестящая статья. На такой аллегории можно построить отличное выступление по теме «философия программирования».
Разница только в том, откуда идет поток информации при создании артефакта – от себя или от мира. В точных науках занимаются познанием мира и стараются от себя делать поменьше предположений.
Советую к прочтению Беркли.
Советую к прочтению Беркли.
ISBN: 5-8459-0791-8
Темная сторона программирования обладает большой силой, но порабощает душу программиста. Настоящие мастера знают, что этой силой не стоит злоупотреблять.
Лучший код – не написанный код.
*включая паяльную станцию" Да! Мы сделаем это хардверно! Бугагага!
- ResourcesSpentToCode - ResourcesSpentToSupport - ∞ * Heaviside(CurrentSolution - ApplicableSolution) -> maxТакая шкала достаточно отрицательна?
Про соответствующие инструменты тоже не забываем
В точных науках способов решить правильно задачу бывает несколько. Но решить неправильно – бесконечное число способов. Правильные решения обычно основаны на механических правилах.
Мое «не гуманитарное» подсознание подсказывает что правильно бы было — «решить неправильно – бесконечное число способов минус несколько» А то както все совсем грустно и безвыходно…
Боюсь вас совсем разочаровать, но если из бесконечного множества исключить конечное число элементов, оно сохранит свою мощность, т.е. останется таким же бесконечным.
Только при наличии аксиомы выбора. А без неё всё ещё более грустно…
Возможно. В любом случае, для счётных множеств (коим является множество всех программ) это утверждение легко доказуемо.
Для программ — да, они являются подмножеством натурального ряда. А вот какому множеству принадлежат «способы решить задачу» (если говорить не об итоговых решениях, а именно о процессах решения) — вопрос сложный. Не каждое рассуждение, творящееся в голове математика, можно представить в виде текста. Впрочем, к представителям других творческих профессий (включая программистов, архитекторов, кулинаров...) это тоже относится.
Не знаю как насчет сторон силы, но по-моему есть четкое разделение айтишников на админов и программистов.
Все админы жёсткие консерваторы, работает — не трогай, не поставим софт до первого сервиспака, кругом враги и хакеры, пользователи тупые, все программисты говнокодеры, весь софт — глюкавый и т.п. Считают себя круче программистов, хотя, как правило, за всю жизнь не написали ни одного проекта хотя бы на 10-15 тысяч тысяч строк кода.
У програмистов — кругом новые фичи, технологии. Ставим самый последний релиз фреймворков (может даже бету, но можно и альфу). Главное — красота идей и перспективы. Новые фичи важнее всего. Глюки — пофиг, их можно так или иначе пофиксить. Админов не замечают или воспринимают как неизбежное зло.
Эту статью писал админ. По своей сути. Я бы ему вообще не советовал работать программистом.
Все админы жёсткие консерваторы, работает — не трогай, не поставим софт до первого сервиспака, кругом враги и хакеры, пользователи тупые, все программисты говнокодеры, весь софт — глюкавый и т.п. Считают себя круче программистов, хотя, как правило, за всю жизнь не написали ни одного проекта хотя бы на 10-15 тысяч тысяч строк кода.
У програмистов — кругом новые фичи, технологии. Ставим самый последний релиз фреймворков (может даже бету, но можно и альфу). Главное — красота идей и перспективы. Новые фичи важнее всего. Глюки — пофиг, их можно так или иначе пофиксить. Админов не замечают или воспринимают как неизбежное зло.
Эту статью писал админ. По своей сути. Я бы ему вообще не советовал работать программистом.
Странный немного вывод. Я к админству совсем никак не отношусь. Мало того, кодить, на мой взгляд, хорошо получается.
Может быть у вас собрался такой коллектив, где только такие программисты. Конечно, программист не должен жить только на своем коде и писать велосипеды. Всё, что упрощает деятельность — в копилку. И учиться надо новому постоянно. Другое дело, надо не забывать смотреть на цель — зачем этот проект. Не использовать его для фана за деньги заказчика. Молодые не очень опытные программисты часто этим болеют. Пытаются попробовать всё в проекте, а не дома. Нужно это или нет. Причем, по поводу каждой мелочи. Иногда код написать для мелкой задачи — полстраницы, программист будет изучать неделями новые фреймворки, чтобы всунуть чей-то комбайн.
Вообще, в программировании это болезнь. Я бы сказал, что у программистов очень низкий уровень образования (вот так с плеча), сам преподавал им когда-то. Из-за этого, особенно молодые программисты, считают, что крутость заключается в том, сколько мелочей они услышали и запомнили. Какую-то комбинацию кнопок — и считают, что достигли интеллектуальной вершины. Есть такой тип программистов — поверхностно-обзоро-читатели. Каждый день или через день, они ставят новые фишки домой, почти как девочки в социальных сетях статусы меняют.
Не могут ничего или мало, но говорят обо всём.
Может быть у вас собрался такой коллектив, где только такие программисты. Конечно, программист не должен жить только на своем коде и писать велосипеды. Всё, что упрощает деятельность — в копилку. И учиться надо новому постоянно. Другое дело, надо не забывать смотреть на цель — зачем этот проект. Не использовать его для фана за деньги заказчика. Молодые не очень опытные программисты часто этим болеют. Пытаются попробовать всё в проекте, а не дома. Нужно это или нет. Причем, по поводу каждой мелочи. Иногда код написать для мелкой задачи — полстраницы, программист будет изучать неделями новые фреймворки, чтобы всунуть чей-то комбайн.
Вообще, в программировании это болезнь. Я бы сказал, что у программистов очень низкий уровень образования (вот так с плеча), сам преподавал им когда-то. Из-за этого, особенно молодые программисты, считают, что крутость заключается в том, сколько мелочей они услышали и запомнили. Какую-то комбинацию кнопок — и считают, что достигли интеллектуальной вершины. Есть такой тип программистов — поверхностно-обзоро-читатели. Каждый день или через день, они ставят новые фишки домой, почти как девочки в социальных сетях статусы меняют.
Не могут ничего или мало, но говорят обо всём.
Другое дело, надо не забывать смотреть на цель — зачем этот проект. Не использовать его для фана за деньги заказчика.
Я программирую чтобы получать фан и деньги, достаточные для того, чтобы не думать о хлебе насущном (с маслом, а по пятницам с икрой и пивом :) и крышей (отдельной и благоустроенной :) над головой. Крупной суммой отказаться от фана на длительный срок заказчик заставить меня не сможет. Ровно до тех пор забуду про фан, пока не решу вопрос с крышей раз и навсегда, если буду видеть, что он решится в обозримом будущем (год-два-три). Если лет десять не фаниться, чтобы купить квартиру, то просто предпочту меньшие деньги, но за работу, которую можно совмещать с фаном.
Это психология, а не профессия. Я вот тоже админить могу. Даже неплохо получается. Просто не люблю. Мог бы пойти по пути админства, причем, успешно. Но я бы не был этим доволен. А можно из админа программиста сделать. Но тоже ничего хорошего не выйдет. Причем, дело не в качестве его продукта, а в психологическом комфорте человека.
Попробую объяснить идею чётче. У китайцев слово «кризис» из двух частей — опасности и возможности. Любая новая технология — это кризис. Есть люди, которые видят перспективы, а есть люди, которые видят опасности. Они разные. И вместе им быть не дано. Админ хорошо видит опасности, программист — перспективы. Это не значит, что они однобоки и не видят другого, просто у них вектор разный. Разные приоритеты. И не значит, что что-то лучше, а что-то хуже. Это субъективная вещь — для одного важно и интересно одно, для другого — другое.
Попробую объяснить идею чётче. У китайцев слово «кризис» из двух частей — опасности и возможности. Любая новая технология — это кризис. Есть люди, которые видят перспективы, а есть люди, которые видят опасности. Они разные. И вместе им быть не дано. Админ хорошо видит опасности, программист — перспективы. Это не значит, что они однобоки и не видят другого, просто у них вектор разный. Разные приоритеты. И не значит, что что-то лучше, а что-то хуже. Это субъективная вещь — для одного важно и интересно одно, для другого — другое.
Понимаете, я вообще обучался на физ-мате. И есть такое наблюдение. В физике требуется некоторая сила ума. Там не нужно «многознание». Человек может не помнить и десятка формул, но знать всё. Всё вывести.
В программировании я часто встречаю обратное — когда этот интеллект заменяют попугайство-хвастовством. Реально, человек не может код с десяток строк написать, где цвет от строки к строки менялся линейно, но считает дураками всех, кто не знает, что контрл+б в редакторе — что-то делает в обход менюшке. К счастью, таких программистов, которые реально думают, что знать несколько десятков слов и быть в треде — это самое важное — не так много.
С другой стороны, программирование не настолько и простое в сравнении с другими науками. Есть база, computer science — которые не меняются десятилетиями.
Конечно, есть большой пласт программистов, которые целью своей жизни считают прыгание по фреймворкам, мышкой что-то там делание и получение каких-то сайтов или что-то модное даже и не кодить.
Я нигде не утверждаю, что программисту не стоит ничему учиться и держаться за старое. И бояться нового. Но по-моему, и думаю, опытные программисты меня поддержат — новое важно применять, но с оглядкой. Ни в коем случае не согласен, что самое главное — это фичи, даже не смотря на ошибки. Устоявшиеся вещи хоть немного себя зарекомендовавшие надо применять. Риски меньше. Думаете, так только админы думают из страха? Конечно, тормоза придумали трусы.
В программировании я часто встречаю обратное — когда этот интеллект заменяют попугайство-хвастовством. Реально, человек не может код с десяток строк написать, где цвет от строки к строки менялся линейно, но считает дураками всех, кто не знает, что контрл+б в редакторе — что-то делает в обход менюшке. К счастью, таких программистов, которые реально думают, что знать несколько десятков слов и быть в треде — это самое важное — не так много.
С другой стороны, программирование не настолько и простое в сравнении с другими науками. Есть база, computer science — которые не меняются десятилетиями.
Конечно, есть большой пласт программистов, которые целью своей жизни считают прыгание по фреймворкам, мышкой что-то там делание и получение каких-то сайтов или что-то модное даже и не кодить.
Я нигде не утверждаю, что программисту не стоит ничему учиться и держаться за старое. И бояться нового. Но по-моему, и думаю, опытные программисты меня поддержат — новое важно применять, но с оглядкой. Ни в коем случае не согласен, что самое главное — это фичи, даже не смотря на ошибки. Устоявшиеся вещи хоть немного себя зарекомендовавшие надо применять. Риски меньше. Думаете, так только админы думают из страха? Конечно, тормоза придумали трусы.
Настройщиков CMS и адвансед юзеров я даже не рассматриваю. Это как раз скорее даже админский путь. Админ растет вширь, программист вглубь. Админ не изобретает велосипеды, ищет готовое, программист «пишет велосипеды», используя самые новые технологии.
А по-моему плох тот программист, который не мечтает стать творцом чего-то нового. Который не хочет сделать что-то, как говорится, на переднем крае науки или технологии. Глюков бояться — не кодить вообще.
Лично мне программирование нравится только в том случае, если решаемая задача дает какой-то вызов. Если она чем-то важна, трудна, нестандартна. Чтоб был полёт мысли, а не просто следование с трудом выцарапанному из заказчика ТЗ минимальными затратами.
А по-моему плох тот программист, который не мечтает стать творцом чего-то нового. Который не хочет сделать что-то, как говорится, на переднем крае науки или технологии. Глюков бояться — не кодить вообще.
Лично мне программирование нравится только в том случае, если решаемая задача дает какой-то вызов. Если она чем-то важна, трудна, нестандартна. Чтоб был полёт мысли, а не просто следование с трудом выцарапанному из заказчика ТЗ минимальными затратами.
Тут и не поспоришь. Кроме уточнения с велосипедами. С велосипедами нужен баланс. В реальном проекте надо как можно больше использовать готовых решений, чтобы сэкономить себе и заказчику нервы. Но с оглядкой.
1. Затраты на изучение работы с чужим функционалом должны быть меньше, чем создание и поддержка своего. Если нужно всего немного функционала, и пишется он легко, — то возможно не надо чужой код. Часто чужие библиотеки несут большой оверхед, но что обидно, бывает при этом, не дают нужного функционала точно для текущего проекта.
2. Учитывать риски в связи с кодом от третьих лиц. Лучше использовать известное, отработанное решение. Потому как в другом случае и багов может быть в нем много и поддержки никакой.
А велосипеды, да, каждый программист просто обязан пописать, чтобы понять как оно устроено, понять сложности и не писать в реальных проектах, уважать чужой труд.
Фичи и новые фреймворки не являются приоритетом, хотя для себя надо их по мере возможности изучать и понимать, что они могут дать. Не являются приоритетом, потому что заказчика не мотивируешь тем, что в коде используется что-то модное. И как раз по моему, самая главная отличительная черта профессионала в любом деле — в том, что он принимает и решает любую проблему как свою личную. Если он создает проект для заказчика, то он стремится к качеству и уменьшению сроков. Если программист считает, что заказчик должен ему просто так платить и он будет фаном заниматься, потому что других не найдет — это уже как-то не серьезно. Стремиться к качеству и уменьшению сроков — это тоже интересно и приносит удовольствие. Самоорганизовывает, заставляет включать в процесс разработки не только код, но и другие вещи, делает интересной работу, которая могла бы показаться в других случаях неинтересной.
1. Затраты на изучение работы с чужим функционалом должны быть меньше, чем создание и поддержка своего. Если нужно всего немного функционала, и пишется он легко, — то возможно не надо чужой код. Часто чужие библиотеки несут большой оверхед, но что обидно, бывает при этом, не дают нужного функционала точно для текущего проекта.
2. Учитывать риски в связи с кодом от третьих лиц. Лучше использовать известное, отработанное решение. Потому как в другом случае и багов может быть в нем много и поддержки никакой.
А велосипеды, да, каждый программист просто обязан пописать, чтобы понять как оно устроено, понять сложности и не писать в реальных проектах, уважать чужой труд.
Фичи и новые фреймворки не являются приоритетом, хотя для себя надо их по мере возможности изучать и понимать, что они могут дать. Не являются приоритетом, потому что заказчика не мотивируешь тем, что в коде используется что-то модное. И как раз по моему, самая главная отличительная черта профессионала в любом деле — в том, что он принимает и решает любую проблему как свою личную. Если он создает проект для заказчика, то он стремится к качеству и уменьшению сроков. Если программист считает, что заказчик должен ему просто так платить и он будет фаном заниматься, потому что других не найдет — это уже как-то не серьезно. Стремиться к качеству и уменьшению сроков — это тоже интересно и приносит удовольствие. Самоорганизовывает, заставляет включать в процесс разработки не только код, но и другие вещи, делает интересной работу, которая могла бы показаться в других случаях неинтересной.
И как раз по моему, самая главная отличительная черта профессионала в любом деле — в том, что он принимает и решает любую проблему как свою личную.
С уточнением — проблему касающуюся его профессии, его области компетенции. Если я программист, то давать свои рекомендации насчет бизнес-процессов я не имею ни морального, ни юридического права. Единственное, что могу позволить себе — это предложить альтернативы, которые мне будет проще реализовывать с формулировкой типа «а не хотите так сделать? мне так будет проще, а вам дешевле». Либо если вижу в бизнес-процессах дыру, но опять же без рекомендаций как её закрывать — просто констатация факта. Хотя зачастую в ответ спрашивают как лучше закрыть, но тогда я уточняю в ответе, что это мое частное мнение, значащее не больше чем мнение какого-нибудь алкаша из подворотни.
Есть много программистов с частично админским мышлением. Например, я;-) Программист «делает работу», т.е. эффективно тратит человеко-часы, админ «решает проблемы», мне кажется, различие именно в этом.
Вступление чуть затянуто…
А вот тут подвис секунд на 15-20, «где подвох?»…
… и только потом догадался, какое отношение буква «м» имеет к центру Земли…
В качестве развлечения статья неплохая и даже веселая, но практическая польза нулевая :)
P.S. кстати ни у кого нет ссылки на видео, где на одной из конференций кто-то утверждал почему нет
необходимости исправлять ошибки в коде? Там были приведены отличные формулы.
А вот тут подвис секунд на 15-20, «где подвох?»…
Детская загадка:
Что находится посредине Земли?
Ответ: буква «М».
Это пример, когда путают объект с частью языка – словом
… и только потом догадался, какое отношение буква «м» имеет к центру Земли…
В качестве развлечения статья неплохая и даже веселая, но практическая польза нулевая :)
P.S. кстати ни у кого нет ссылки на видео, где на одной из конференций кто-то утверждал почему нет
необходимости исправлять ошибки в коде? Там были приведены отличные формулы.
Полагаю, вы о видео «Как размножаются Боги»: www.youtube.com/watch?v=HRhP9yPO5g8&list=PL5DAFEFCCA04F057A
ДА! О Да!!!
этот доклад должен послушать каждый программист! :)
Спасибо огромное!
этот доклад должен послушать каждый программист! :)
Спасибо огромное!
Ну не знаю, у меня впечатления скорее негативные, хоть я о и не большой фанат фреймворков, а на слово common у меня аллергия. Если вера автора в неограниченный закон Мура умиляет, то призывы писать код без особого осмысления причин, по которым он работает, вызывает недоумение. Возможно, для некоторых ситуаций это работает, но врядли при разработке сервисов 24/7/365,25. Да и идеология Эрланга, мне кажется, немного искажена.
какое-то свободное манипулирование цифрами и законом Мура.
Оттого, что количество багов растет квадратично (это в очень плохом случае, наверное), не следует вывод — что их не надо искать, а писать заплатки. Такие заплатки — сами по себе очень сильно влияют на количество багов. Это не независимые вещи. Скрыли баг, плюс к этому еще скорее увеличили урон. Заплатка — это код, который связан с багом. Таким образом, выпилить баг, если его еще видеть будут — будет значительно сложнее. Количество кода связанного с багами растет.
Поэтому нельзя рассматривать рост количества багов без учета того, что делается, чтобы их не было.
Второе — баги могут быть очень вредны. Т.е. если что-то с производительностью — это куда не шло. А если самолет упадет, сердце станет? Да и просто банковские операции. Клиент не обрадуется, если деньги пропадут.
Третье, наши языки программирования все таки не нейронные сети и не генетические алгоритмы. Они не умеют «самолечиться», выводить закономерности. Так что заплатки резко тянут корабль ко дну.
Оттого, что количество багов растет квадратично (это в очень плохом случае, наверное), не следует вывод — что их не надо искать, а писать заплатки. Такие заплатки — сами по себе очень сильно влияют на количество багов. Это не независимые вещи. Скрыли баг, плюс к этому еще скорее увеличили урон. Заплатка — это код, который связан с багом. Таким образом, выпилить баг, если его еще видеть будут — будет значительно сложнее. Количество кода связанного с багами растет.
Поэтому нельзя рассматривать рост количества багов без учета того, что делается, чтобы их не было.
Второе — баги могут быть очень вредны. Т.е. если что-то с производительностью — это куда не шло. А если самолет упадет, сердце станет? Да и просто банковские операции. Клиент не обрадуется, если деньги пропадут.
Третье, наши языки программирования все таки не нейронные сети и не генетические алгоритмы. Они не умеют «самолечиться», выводить закономерности. Так что заплатки резко тянут корабль ко дну.
Грамотная работа с логом — вообще нетривиальная тема. Писать всё подряд в лог практически бесполезно — в случае отключения какого-нибудь датацентра жаба накидает такую кучу стектрейсов, что в них наврядли кто-то будет разбираться. Коллеги пытались слать серьёзные ошибки на почту, порой до 700.000 писем за ночь могло придти. А служба классификации и фильтрации ошибок сама по себе является весьма нетривиальной в реализации.
Фишка в том, что эволюция примерно так и работает: случайным образом образующиеся удачные заплатки приживаются, и всякая жизнеспособная система действительно состоит сплошь из заплаток. Неудачные — не приживаются, но в софтостроении такие версии тоже в продакшен из разработки не попадают…
Что-то я не помню в своем опыте такого, чтобы заплатки на самом деле делали что-то полезное, а не делали кажущуюся полезность. Бывает, сталкивался с чужим кодом. И не всегда, правда, можно сказать: а была ли заплатка. При детальном рассмотрении оказывается, что баг работает невидимым в продакшене полгода-пара лет. И он не просто там был и ел какие-то ресурсы процессора. Он приносил денежные убытки.
Если же Вы рассматриваете заплатку — как разработка нового функционала в старой системе без детального раздумывания над архитектурой и без рефакторинга, то может быть.
А вообще, я не согласен с роликом, что эволюция работает. В наших языках программирования не работает. Погибает вся популяция ) Она бы работала, если бы языки были подобны генетическим алгоритмам и создавался сразу большой оверхед — на каждое требование рождалось много разных решений и в процессе эволюции плохие погибали, лучшие оставались. Заплатки чтобы временно действовали, я сам движок искал новые правильные решения. Может быть когда-то такие языки будут.
А сейчас мы пишем только одно решение. И оно либо верно, либо нет. Причем, «некритичных» ошибок практически не бывает. Отрисовка в ГУИ некритична, но такие ошибки редкие. Каждая ошибка нарушает процесс работы системы. И урон зависит разве что от того, зачем сделана система.
Вот, один из примеров заплаток. В компании N ищут клиента банка по базе. Если почему-то не находят (а должны), берут первого попавшегося случайного. Какая жесть с ним дальше может произойти, даже рассказывать не буду.
Если же Вы рассматриваете какую-то онлайн-игру, где потеря виртуальных денег или чего-то там, разве что сильно расстроит игрока, но не нанесет ему никакого материального ущерба — то можно при наличии тысяч ошибок лепить заплатки. Но если Вы надеетесь, что они приживутся, то Вы рассматриваете код, как человек, впервые севший за компьютер, обучаться программированию. Когда у него сдают нервы и он начинает менять в программе наугад разные части, чтобы ответ начал сходиться к правильному.
Если же Вы рассматриваете заплатку — как разработка нового функционала в старой системе без детального раздумывания над архитектурой и без рефакторинга, то может быть.
А вообще, я не согласен с роликом, что эволюция работает. В наших языках программирования не работает. Погибает вся популяция ) Она бы работала, если бы языки были подобны генетическим алгоритмам и создавался сразу большой оверхед — на каждое требование рождалось много разных решений и в процессе эволюции плохие погибали, лучшие оставались. Заплатки чтобы временно действовали, я сам движок искал новые правильные решения. Может быть когда-то такие языки будут.
А сейчас мы пишем только одно решение. И оно либо верно, либо нет. Причем, «некритичных» ошибок практически не бывает. Отрисовка в ГУИ некритична, но такие ошибки редкие. Каждая ошибка нарушает процесс работы системы. И урон зависит разве что от того, зачем сделана система.
Вот, один из примеров заплаток. В компании N ищут клиента банка по базе. Если почему-то не находят (а должны), берут первого попавшегося случайного. Какая жесть с ним дальше может произойти, даже рассказывать не буду.
Если же Вы рассматриваете какую-то онлайн-игру, где потеря виртуальных денег или чего-то там, разве что сильно расстроит игрока, но не нанесет ему никакого материального ущерба — то можно при наличии тысяч ошибок лепить заплатки. Но если Вы надеетесь, что они приживутся, то Вы рассматриваете код, как человек, впервые севший за компьютер, обучаться программированию. Когда у него сдают нервы и он начинает менять в программе наугад разные части, чтобы ответ начал сходиться к правильному.
Первый попавшийся случайный клиент банка — это баг. Заплатка могла бы говорить, что его нет — заведите нового. Для приходных операций это бы сошло бы. Потом был бы баг с дублированием учёток — другая заплатка могла б их давать сливать…
Но в целом я не то чтобы с Вами очень спорю. У всех методов есть плюсы и минусы, всегда приходится искать компромисс.
Но в целом я не то чтобы с Вами очень спорю. У всех методов есть плюсы и минусы, всегда приходится искать компромисс.
А естественный отбор вариантов заплаток происходит и в программировании. Делается заплатка, делается тест, прошёл — хорошо, не прошёл — заплатка переделывается, подправляется. Неоднократно, зачастую. Если тесты прошла — выпускается пользователям. Если обнаруживается, что она привела к другим багам — либо лепится новая заплатка поверх, либо, если узнали, что виновата она — откатывается она, и опять переделывается иначе.
И еще, почему я думаю, что надо ошибкам активно себя проявлять вплоть до падения. Проявления ошибок и количество ошибок — разные вещи. Ошибок на самом деле не много. Я думаю, можно писать без ошибок. Мнение, что ошибки есть всегда, стало настолько популярным, что почти приравнивается к «давайте не искать». Даже в больших системах, если не рассматривать потенциальные баги, неверную архитектуру, то ошибок в районе — 10-20. А проявляться они могут сколько угодно раз в день.
Чем активнее применяются методы для их отлова, тем быстрее код станет чистым. И один из самых эффективных способов — это написание кода так, чтобы в нем не было компромиссов. Каждый метод делает что-то одно, представляет, что ему дают параметры такие как надо, если нет — падает, а также, если он не смог выполнить то, что от него требуется — падает.
Чем активнее применяются методы для их отлова, тем быстрее код станет чистым. И один из самых эффективных способов — это написание кода так, чтобы в нем не было компромиссов. Каждый метод делает что-то одно, представляет, что ему дают параметры такие как надо, если нет — падает, а также, если он не смог выполнить то, что от него требуется — падает.
Спасибо, порадовали
Почти «подписываюсь под каждым словом»…
Гибкость нужна. В меру. В первую очередь для того, чтоб не делать лишнюю работу…
Гибкость нужна. В меру. В первую очередь для того, чтоб не делать лишнюю работу…
Я уже как то высказывался на хабре на счет быдлокода.
Я сейчас работаю в фирме, где 7 лет быдлкодили. Сайт очень известный, 1 000 000 хитов в день, люди ходят и пользуются им, но я был шокирован когда увидел начинку, и ведь работает до сих пор. Обычный пользователь и заказчик не замечают, что их сайт написан на коленке с использованием микса технологий perl, cgi, php3, cron, mysql_query, parser (Лебедева) и куча папок, каждая папка мини движок в которой скопипастен конфиг, шаблон, кстати шаблоны внутри скриптов прям.
Так вот вся пробема кроется во времени, когда ты быдлокодишь ты выигрываешь сейчас, но проигрываешь в будущем. Былокодить имеет смысл одноразовые сайты, промо сайты или любые другие которые поддерживать не придется, но нужно сделать очень быстро.
Расскажу одну проблему, чтобы изменить или дбавить новую функциональность приходится тратить день, а то и 3-4 дня бывает зависнешь в поисках решения. А бывает так что решение от тебя не зависит, а зависит от третьих факторов к которым привязан код. Поэтому меня и наняли решить вопрос так, чтобы выполнять однотипные задачи за 5 минут через нормальную админку, а не по 3-4 дня хрен пойми как без админок.
И получается круговая порука, тебе шлют задачи которые тебе надо сделать быстро, а быстро их сделать ты не можешь, но в тоже время тебе нужно писать новый движок и старый функционал переносить на него.
«Спасибо» быдлокоду, я каждый день шлю лучи ненависти тем кто быдлокодил такой большой проект, это наплевательское отношение не только к тебе но и к твоим последователям, собратьям программистам, потому что приходится иногда делать работу секретарши вместо того чтобы программировать…
Я сейчас работаю в фирме, где 7 лет быдлкодили. Сайт очень известный, 1 000 000 хитов в день, люди ходят и пользуются им, но я был шокирован когда увидел начинку, и ведь работает до сих пор. Обычный пользователь и заказчик не замечают, что их сайт написан на коленке с использованием микса технологий perl, cgi, php3, cron, mysql_query, parser (Лебедева) и куча папок, каждая папка мини движок в которой скопипастен конфиг, шаблон, кстати шаблоны внутри скриптов прям.
Так вот вся пробема кроется во времени, когда ты быдлокодишь ты выигрываешь сейчас, но проигрываешь в будущем. Былокодить имеет смысл одноразовые сайты, промо сайты или любые другие которые поддерживать не придется, но нужно сделать очень быстро.
Расскажу одну проблему, чтобы изменить или дбавить новую функциональность приходится тратить день, а то и 3-4 дня бывает зависнешь в поисках решения. А бывает так что решение от тебя не зависит, а зависит от третьих факторов к которым привязан код. Поэтому меня и наняли решить вопрос так, чтобы выполнять однотипные задачи за 5 минут через нормальную админку, а не по 3-4 дня хрен пойми как без админок.
И получается круговая порука, тебе шлют задачи которые тебе надо сделать быстро, а быстро их сделать ты не можешь, но в тоже время тебе нужно писать новый движок и старый функционал переносить на него.
«Спасибо» быдлокоду, я каждый день шлю лучи ненависти тем кто быдлокодил такой большой проект, это наплевательское отношение не только к тебе но и к твоим последователям, собратьям программистам, потому что приходится иногда делать работу секретарши вместо того чтобы программировать…
Собственно, разбираюсь с последствиями такого подхода.
3 года назад написан бьіл веб-проект, где одной из фич являлось хранение загруженньіх файлов на сервере. Генерация пути для сохранения, чтения, удаления файлов и групп файлов делалась в каждом методе, и гвоздями бьіла прибита к тому, что все хранится на конкретном сервере в некоторьіх папках.
Не прощло и 3 лет, и вот нужно уже хранение в облаке (причем, разньіх). Приходится все шерстить и править.
3 года назад написан бьіл веб-проект, где одной из фич являлось хранение загруженньіх файлов на сервере. Генерация пути для сохранения, чтения, удаления файлов и групп файлов делалась в каждом методе, и гвоздями бьіла прибита к тому, что все хранится на конкретном сервере в некоторьіх папках.
Не прощло и 3 лет, и вот нужно уже хранение в облаке (причем, разньіх). Приходится все шерстить и править.
А таким воркэраундом, как виртуальные диски и папки, эта проблема не лечится?
Пост ровно о том, как не писать говнокод. Если думаете, что возможно либо писать продуманную архитектуру, либо говнокод, то вот:
Смешная вымышленная история, как архитектор вообще не смог завершить проект:
Как два программиста хлеб пекли
И моя попытка показать, что второй программист не обязан быть говнокодером:
Хлеб Маркуса и YAGNI
Краткость — не только сестра таланта, но и сестра абстрагирования. Абстрагирование в программировании — это по сути — избавление от рутины, т.е. повторяющейся деятельности. Т.е. повторяющегося кода. Плюс такого подхода, что абстракции если и возникают, то возникают совершенно обоснованно, а не как карта легла у креативного программиста в голове.
По сути, такой подход к разработке отличается от предварительного планирования только тем, что программист «планирует в действии». Есть люди, которые любят играть в шахматы в уме. Но проще на доске. И от мазохизма избавляемся. Язык программирования — отличная вещь для представления абстракций. И программист, следуя прямому выражению мысли, меняющимся требованиям не брезгует прикасаться к клавиатуре, когда планирует. Он как бы еще при этом пользуется настоящим языком программирования, как своим родным языком — показывая, что он никакой не сантехник, не бухгалтер и не электрик — ему роднее язык программирования.
А так, в принципе, то же самое планирование, только на языке программирования и в действии. Человек в голове тоже обычно задачи на куски разбивает, не может всё одновременно продумывать. Так почему бы не записывать.
Смешная вымышленная история, как архитектор вообще не смог завершить проект:
Как два программиста хлеб пекли
И моя попытка показать, что второй программист не обязан быть говнокодером:
Хлеб Маркуса и YAGNI
Краткость — не только сестра таланта, но и сестра абстрагирования. Абстрагирование в программировании — это по сути — избавление от рутины, т.е. повторяющейся деятельности. Т.е. повторяющегося кода. Плюс такого подхода, что абстракции если и возникают, то возникают совершенно обоснованно, а не как карта легла у креативного программиста в голове.
По сути, такой подход к разработке отличается от предварительного планирования только тем, что программист «планирует в действии». Есть люди, которые любят играть в шахматы в уме. Но проще на доске. И от мазохизма избавляемся. Язык программирования — отличная вещь для представления абстракций. И программист, следуя прямому выражению мысли, меняющимся требованиям не брезгует прикасаться к клавиатуре, когда планирует. Он как бы еще при этом пользуется настоящим языком программирования, как своим родным языком — показывая, что он никакой не сантехник, не бухгалтер и не электрик — ему роднее язык программирования.
А так, в принципе, то же самое планирование, только на языке программирования и в действии. Человек в голове тоже обычно задачи на куски разбивает, не может всё одновременно продумывать. Так почему бы не записывать.
Феерично, спасибо. Поймал себя на мысли, что иногда скатываюсь на «светлую» сторону. Буду стараться давить и давить в себе джедая…
Но джедаи тоже нужны. Иначе кто же будет делать фреймворки и CMS?
Ситхи и там будут не хуже джедаев )
Язык программирования — язык выражения мыслей. Как инглишь. Можно знать грамматику, но это не делает лингвистом и переводчиком. На языке можно говорить о космосе, о погоде, о музыке, о чем угодно, а не о презент континиус и наречиях. Но тем не менее, можно и о наречиях тоже.
Беда в том, что в основном программисты только о грамматике и пишут в коде.
Тем не менее, те, кто могут писать не о грамматике, точно так же могут писать о грамматике. Они в этом не ущербнее. Правильнее сказать: возможно, джедаи хоть в созданиях фреймворков пригодятся. Но я бы не надеялся )
Язык программирования — язык выражения мыслей. Как инглишь. Можно знать грамматику, но это не делает лингвистом и переводчиком. На языке можно говорить о космосе, о погоде, о музыке, о чем угодно, а не о презент континиус и наречиях. Но тем не менее, можно и о наречиях тоже.
Беда в том, что в основном программисты только о грамматике и пишут в коде.
Тем не менее, те, кто могут писать не о грамматике, точно так же могут писать о грамматике. Они в этом не ущербнее. Правильнее сказать: возможно, джедаи хоть в созданиях фреймворков пригодятся. Но я бы не надеялся )
Эта статья как раз про меня. Она на 100% отражает мои сомнения и метания. Годами пытаюсь убить в себе перфекциониста (джедая), но то ли натура творческая, то ли плохо пытаюсь, частенько ухожу в сторону от основной задачи. Заведу себе хобби — буду канзаши (кандзаси) клеить — удовлетворяя тем самым потребность в творческом самовыражении :)
Написание излишних абстракций и обработок «на все случаи жизни» вместо решения поставленной задачи - это один из вариантов прокрастинации
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Темное программирование