Темное программирование

    imageПредлагаю перейти на сторону зла, на темную сторону программирования. Ситхи сильнее джедаев. И печенек хватит на всех. Предупреждаю, прежде чем начнете читать далее. Характер при переходе на темную сторону портится.
    Прошу под кат

    Перевернутая шкала ценностей


    Есть легенда, что каждый раз, когда программист пишет плохой код – Бог убивает котенка. Пора признаться, что все мы – убийцы котят. У некоторых руки по локоть в крови. Первый шаг в сторону силы – признать в себе это. Любой код – это привнесение во Вселенную хаоса. Любой символ – рост энтропии. Если мы признаем это, то спадет маска умиления и радости от кодирования. Всё, что мы делаем – плохо. И с этим нельзя ничего поделать. Можно только пытаться делать это в меньших количествах.

    Мы как самураи. Мы обучены убивать. Но смысл – не убивать. Или убивать как можно меньше. Лучший бой – не начавшийся бой. Лучший код – не написанный код. Любой код – зло.

    Перевернутая шкала ценностей – это оценки в отрицательной части – плохо, хуже, еще хуже. Не бывает хорошо, лучше. Ситхи верят, что джедаи заблуждаются в плане: бывает хороший код, бывает лучше. Не бывает. Отрицательная шкала – это кругом только зло. И ситхи вынуждены выбирать меньшее зло. Джедаи выбирают наибольшее добро. Т.е. если они видят два решения, то они видят позитивные качества и на основании своих предпочтений выбирают то, что лучше.

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

    Ситх не страдает проблемой выбора. Он не медлит в выборе. Для него очевидно, что всё плохо, поэтому менее плохо то, что позволяет сократить деятельность.

    Есть побочный эффект от такого подхода – окончательно портится характер. Ситх любой код называет говнокодом. Что может разрушить отношения в коллективе джедаев. Джедай думает примерно так: «Каждый подход и инструмент имеет свои плюсы и минусы и ситх почему-то категоричен, называя их применения говнокодом». Про минусы джедай лукавит, т.к. никогда на них не концентрируется, видя во всем только плюсы. Ситх же всё называет говнокодом, шкала такая. В зависимости от задачи, он пытается его уменьшить, а не любоваться еще одним способом решить задачу. Для ситха любое решение плохое. Но некоторые еще хуже.

    Выражать мысль заказчика


    Вершиной сокращения деятельности является прямое выражение мысли. Причем, мысли из предметной области. В связи с этим, язык программирования рассматривают как язык общения. Это язык, на котором выражают мысли. Популярность ООП связана как раз с этим: наши естественные языки требуют подлежащего и сказуемого. Подлежащие – это объекты, сказуемые – методы. Это не мир состоит из объектов, это восприятие и естественный язык такой. Иногда получаются казусы, вроде «ветер дует», «свет светит». Бред. Здесь нет объекта и его действия. Такой же бред иногда встречается в энтерпрайзе. Но так уже повелось, поэтому ООП часто является естественной формой выражения мыслей, перевода с языка заказчика.

    Это не реклама ООП. Более жесткие способы описаний (см. Жесткость) приветствуются.

    Язык программирования – это не конструктор для программ. Так же как в естественном языке есть грамматика – знание грамматики не говорит о том, что вы можете выражать мысли, ясно, точно, лаконично. Если вы до сих пор увлекаетесь паттернами, оптимизациями, разными возможностями – вы еще новичок. Умение выразить мысль – вот что главное. А не сколько раз в предложении встретилась буква «М».

    Не стоит восторгаться возможностями, которые предоставляются с языком, вроде работы с многопоточностью и тому подобное. Всё это относится не к задачам, не к мыслям заказчика. Нас интересует только то, насколько он позволяет лаконично и ясно выразить мысль заказчика.

    Если заказчик просит нас перевести на язык программирования «собачка перешла дорогу», то точно так и надо поступить. Не коровка, не кошечка. Многие программисты настолько увлечены процессом, что пишут: «Белая болонка в позолоченном ошейнике пересекла дорогу на углу возле дерева, под которым только что справила нужду». Создают не только породу и ошейник. А строят еще и миску для нее и хозяйку. Всю инфраструктуру города. Потому что воспринимают язык, как конструктор. Зачем? Да чтобы вдруг заказчик захочет собачку покормить потом, выразит такое требование – миска уже была, город был.

    Надо признать, что иногда языки программирования требуют создать некоторую инфраструктуру. Но тогда надо минимизировать эту деятельность, потому что кпд программиста будет вычисляться формулой:

    (Полезная работа) / (Затраченная работа)

    И не надо себя обманывать, что какой-то WCF канал входит в полезную работу, а заказчик о нем мечтает, просто не знает о нем.

    Убить в себе гуманитария


    Как-то в частной беседе, знакомая, психолог, нарисовала большую галку:
    И спрашивает:
    — Что ты видишь на листке?
    — Галку – ответил я, не понимая, к чему этот вопрос.
    — Ничего из тебя не выйдет. Ты не креативная личность, не способен на творчество. Это простой тест на креативность. И чем более творческая личность, тем причудливее видит формы. Некоторые сердечка, облака, некоторые даже лошадей.
    Потом со вздохом добавляет:
    — Но математики почему-то видят почти всегда галку… Редко – знак бесконечности.
    Я:
    — Они видят галку, потому что это похоже на галку.

    Тогда у меня и сложилось мнение, чем отличается аналитический ум, точные науки, от гуманитарных наук и искусства. Человек взаимодействует с внешним миром и создает артефакты. Разница только в том, откуда идет поток информации при создании артефакта – от себя или от мира. В точных науках занимаются познанием мира и стараются от себя делать поменьше предположений. Смешно было бы услышать при решении задачи по физике несуразицу со словами «Я так вижу».

    Креативные же личности запросто так говорят. И креативят в коде. Каждый раз, когда я слышу от программистов «у нас творческая профессия», «могут быть все правы, у каждого свое мнение», «существует масса способов решить» — то вспоминаю лошадей вместо галки. Каждый раз, обычно, при тех словах, программисты уже что-то задумали – какую-то гибкость (про которую позже).

    В точных науках способов решить правильно задачу бывает несколько. Но решить неправильно – бесконечное число способов. Правильные решения обычно основаны на механических правилах.

    У нас, у программистов, источник внешней информации – заказчик. Существует не такое большое число способов как можно точнее перевести его требования. При этом каждый язык программирования предлагает свой естественный способ.

    Что еще отличает людей с точным складом ума – это то, что язык используется для выражения каких-то внешних по отношению к языку мыслей.

    Детская загадка:
    Что находится посредине Земли?
    Ответ: буква «М».
    Это пример, когда путают объект с частью языка – словом.

    Люди с точным складом ума оперируют объектами, а не словами или конструкциями языка. И наоборот, люди с ГСМ бывает находят красоту в звуках, в комбинациях слов, скрытый смысл в корнях слов и тому подобное.

    Ситхам надо убить в себе гуманитария. Мы не творческие люди, мы инженеры. Да, сейчас это не модно.
    Оперировать смыслом в коде – это выражать мысли заказчика. Но джедаи настолько увлекаются языком, его свойствами и конструкциями, что переходят все грани в своем творчестве. Это нелепо выглядит со стороны, так же как кони в галке.

    Жесткость


    Программы должны быть жесткими, а не гибкими. Узнали в себе джедая? У ситхов перевернутая шкала.
    В университетах и в книгах учат, что плохой код — это негибкий код, хардкод. Это всемирный заговор и обман. Всё ровно наоборот. Программа должна удовлетворять требования заказчика. Причем на данный момент. И точка. Причем удовлетворять самым жестким способом, самым ограниченным. Ограничения для программы – это как рельсы для поезда. Программа должна выполнять свое предназначение и не отклоняться ни на сантиметр. В связи с этим верный союзник – статическая типизация. Программист специально создает типы, которые не могут программе позволить вообще оказаться в запрещенных местах и это проверяет компилятор до запуска.

    Гибкость программы вообще не является приоритетом. Как можно, чтобы программа была и гибкой и одновременно жесткой? Фокус в том, что не учат, забывают, что единственно важная вещь для программы – быть правильной. То, что из-за хардкода будут проблемы в будущем у программиста, если требования поменяются – это ли должно волновать заказчика? Это индейская проблема. Но настолько все сконцентрировались на гибкости и паттернах, что жесткость начала порицаться. Когда как только она и обеспечивает правильность работы программы. Конечно, плохой хардкод будет приносить проблемы, что идет в разрез с ситховской минимизацией деятельности. Но в вершине нашего мировоззрения стоит краткость и ясность изложения мыслей в программе. А значит, программу легко переписывать, менять код. Гибкость если и есть, то она «вынужденная». В оценку эффективности разработки надо включать не только сам язык, но и IDE. Можно не закладывать гибкость из страха изменений. Не в блокноте работаем.

    Умерщвление программы и баги


    Ситхи любят баги. Их ждут, их уважают. Как только встречается баг, ситх бросает всё и уделяет внимание только ему. У багов такая природа: пока не выяснили причину, не известна важность и урон бага. Если в программе проявился баг – программа теряет доверие. Лучше ей не работать. Не работающая программа в общем случае приоритетнее, чем работающая кое как. Продолжающая работать программа просто ест ресурсы, а не производит полезного действия. По крайней мере, не доказано, что она делает что-то полезное. Мало того, работающая программа часто скрывает баг. Которого так ждут ситхи.

    Так как ситхи ждут баг, то приоритет в том, чтобы баг был очень заметен. Чем настойчивее он себя проявляет, тем лучше. А чем не лучший способ захватить внимание, как упасть программе? Я видел пару раз приложения, где ошибки складываются в лог. И как можно догадаться, лог этот не читают длительные сроки.

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

    Я (как ситх) не призываю писать ПО, которое падает при каждом вздохе полностью. Тут, надо выбирать меньшее зло и брать на себя ответственность, что опаснее простой, когда упало всё и ошибка исправляется, или продолжение работы, когда падает только какая-то одна операция. Часто приемлемее второе решение.

    Самый худший вариант, это когда программист считает, что программа должна выживать, включая каждый локальный кусок. Каждый метод пишется так, как будто бы он находится на поле боя в окружении одних врагов, не имея союзников. И он пытается решить возложенную на него задачу, если не может, то найти обходной путь, если не может, то выжить просто так. Это ацкий говнокод. Даже поиск обходного пути. Если нечто случилось такое, что методу приходится обходить, то значит либо баг во внешнем коде, а метод покрывает его деятельность, либо программист что-то не знает о внешнем по отношению к методу коде. Что чревато. Писать методом «наугад», признак не то, что новичка, а нулевичка.

    Заключение


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

    Подробнее
    Реклама
    Комментарии 211
    • +23
      Code, Debug, Love the Emperor!
    • +31
      В общей сложности Гильберт был научным руководителем у 69 аспирантов, защитивших докторские диссертации. Интересен его отзыв об одном из аспирантов, бросившем математику и «переквалифицировавшемся» в поэты: «Это хорошо, у него было слишком мало фантазии для математика»

      А вообще, после прочтения сложилась полная каша, у вас очень много спорных утверждений и ещё больше — сравнение несравнимого и сопоставлений несопоставимого.
      • +7
        да хотелось как-то так выразить в художественной форме, чтобы не надо было обосновывать. Шкала перевернута — это главное. А остальное Вы в общем-то знаете. Если складывать разные методы оценки кода по шкале — плохо-хуже, больше градаций получается. Психологически. Хорошо-лучше — не работает. Потому что любое хорошо подойдет.

        А про математиков — слышал, не согласен. Это не единственное мнение о математике. Фантазия там нужна, как способность понять и удерживать в голове сложные модели, но не фантазирование. Разные вещи.
        • +1
          Креативить != фантазировать. Вы с методом brainstorming'а знакомы? Это, пожалуй, один из лучших подходов к решению возникающих проблем и разногласий при разработке ПС. Разумеется, за исключением некоторых особых случаев, когда компания работает в режиме IT-конвейера.
          • +4
            Да всё нормально — я не против вообще креатива, потому как его не избежать. Любое решение будет включать в себя долю креатива. Я только за направление стремлений — от креатива подальше. Механические правила рефакторинга, ТДД, выражение мыслей в коде, который пришли от заказчика.
            Как можно более прямым способом == как можно меньше от себя креатива.
            • +6
              Извините, но почему-то сразу вспомнилось вот это…

              image
          • +1
            Фантазия и фантазирование, несомненно, разные вещи в силу того, что первое (в данном контексте) — атрибут мыслительной деятельности (даже скорее творческой), а второе (судя по морфологии) — некий процесс, который вы отчего-то наделили негативной окраской.
            Вы, вроде как, утверждаете, что Катя и Чернова — это разные вещи, но говорите об одной и той же Кате Черновой.

            PS: Прошу прощения за изобилие скобок.
            • +1
              Вы так быстро меняете значения терминов и перепрыгиваете между уровнями абстракции, еще и комбинируя первое и второе, что вообще ничего не понятно…
              • +1
                Я вообще слабо понимаю, что имел ввиду Гилберт. Слово «фантазия» для меня слабо определено. Попытался свое понимание Гилберта описать с объяснением, что в данном случае есть фантазия.

                Математика действительно требует хорошей гибкости ума и внимание, чтобы удержать в уме сложную модель. Но при этом математика — это набор правил, формальных, синтаксических, от которых не отклоняются. Решения задач — это формулы, правила с которыми строго определены. Одна механика.

                В посте я больше подразумевал науки, которые изучают природу. Математика в принципе — это аппарат для них.
                • +8
                  Математика, в принципе, обладает целым рядом различных ипостасей. Для науки, которая изучает природу математика, действительно, лишь аппарат. Для Анжелы Львовны, поэтессы с богатым внутренним миром и тройкой по математике — это сухой набор формул и вообще для людей без чувства прекрасного.
                  Но для математиков математика — это чистая фантазия. Коль скоро любая естественная наука обнимает лишь малую часть математики, их взгляд на математику можно считать однобоким, весьма унылым и очень прикладным. Настоящая математика — это не наука в общем смысле: нельзя сформулировать область ее интересов, нельзя адекватно описать математический опыт и так далее.
                  Фантазия для того, чтобы держать в голове правила и модели, не требуется. Для того чтобы создать их, применять их и открывать их миру — нужна не просто фантазия, а, пардон, ФАНТАЗИЯ.

                  Возможно, я математический романтик, но мне грустно слышать о том, что математика — это набор правил. Правила в ней — это маленький кусочек проекции математики на околоматематический мир в лучшем случае.

                  ИМХО.
                  • +2
                    Подозреваю, что тут проблема формулировки, возможно, перевода. Я бы сказал, что математику нужно хорошее воображение. Именно оно нужно для создания и обдумывания сложных объектов в уме. Правда, оно нужно для всех профессий, не являющимся тупым исполнением последовательности действий (которые в свою очередь можно заменить роботами).
                    • –1
                      Математика — это наука о разнообразнейших свойствах количества.

                      Для применения известных свойств — нужно строго следовать их сути, описанной формулами. Воображение не нужно.
                      Для поиска новых — нужно иметь очень сильное воображение, чтобы угадать, что какое ещё свойство есть.
                      • 0
                        За что минус? Возразите словами, плиз.
                        • +1
                          О свойствах количества — это арифметика. 99 с лишним процентов математики же — это наука о свойствах формул, фигур, уравнений, преобразований и алгоритмов ;-)
                          • 0
                            Но формулы и уравнения — они же тоже все либо про количества непосредственно, либо про свойства формул и уравнений, что, по сути, всё равно свойства количества, только второго и более глубоких порядков. Фигуры в геометрии — тоже, можно сказать, воплощение количества тех или иных характеристик пространства. Алгоритмы в математике — тоже про свойства количества или про свойства его свойств.
                            • +1
                              Проще сказать, что вся математика — наука о множествах и их свойствах. Иногда множества соответствуют каким-то «количествам», но чаще сами по себе.
                              • 0
                                Да, я слышал такое определение. Но о каких ещё свойствах множеств, кроме количества, идёт речь?..

                                С другой стороны, множества элементов — это лишь про целочисленные количества, а вообще количества бывают и не целочисленными, и вообще не в виде числа, а например в виде расстояния вдоль кривой или объёма нескольких сложных фигур. Понятие количества, само по себе, мне видится существенно более фундаментальным.
                                • 0
                                  Кривая или сложная фигура — множество бесконечно малых точек, длина или объём — производные характеристики от этого множества.
                                  • 0
                                    А точка — это тройка координат, а координата — вещественное число, а вещественное число — множество рациональных чисел, меньших его, а рациональное число — тройка (знак, числитель, знаменатель), а числитель и знаменатель — натуральные числа (или ноль), а натуральное число N — множество (N-1) U {N-1} (а ноль — пустое множество). Так что всё сводится к основам :)
                                    • 0
                                      Множество всех бесконечно малых точек в любом объеме — бесконечно.
                                      • 0
                                        Ну и что?
                                        Всё равно разные множества дадут разные объёмы фигур. Несмотря на то, что все эти множества бесконечны.
                                        • 0
                                          Бесконечности очень разные бывают, это в математическом анализе тоже проходят…
                                          • 0
                                            Бесконечности очень разные бывают, это в математическом анализе тоже проходят

                                            В круге диаметром 10 единиц в точности столько же точек, сколько в круге единичного диаметра (т.к. можно построить биекцию). Метрика мало связана с мощностью бесконечных множеств, это внешняя функция.
                                            • 0
                                              Множество точек окружности тоже бесконечно, но тут трюк про биекцию с кругом единичного диаметра не пройдёт;-)
                                              • 0
                                                Ну, я прекрасно знаю о классификации бесконечных множеств и континуум-гипотезе. И то, что числа и, соответсвтенно, понятие кол-ва можно сделать производными от множеств. Просто рассуждать о геометрии только в терминах включений множеств врядли выйдет. Это вотчина топологии, где метрика не важна.
                                                • 0
                                                  В чём проблема? Геометрия, в первую очередь, определяется множеством перемещений плоскости (или пространства), т.е. отображений множества в себя, «сохраняющих расстояние». Отсюда можно ввести и само расстояние между парами точек, как инвариант этих отображений. Плюс у нас есть аксиома о точках на луче, которая сразу даёт биекцию между точками открытого луча и вещественными числами — всё замечательно описывается в терминах множеств. А после того, как мы научимся делить плоскость на квадратики определённого размера, мы и площадь фигуры определим через включение множеств, как это и делается в теории меры.
                                                  • 0
                                                    Это не проблема с точки зрения методологии — вся математика, включая геометрию, зиждется и выводится из набора аксиом, описывающих свойства множеств. Проблема скорее практическая — в жизни в ответ на вопрос «какова площать этой фигуры» мы хотим слышать простой и понятный ответ в виде конкретного числа, а не сложные выкладки с включениями множеств. Да и решать проблемы, используя преобразования и расстояния, гораздо проще и привычней, чем работать с включениями множеств (во всяком случае, мне).
                                                    • 0
                                                      Если эта фигура не относится к некоторым элементарным, то для определения площади тому, у кого вы о ней спросите, всё равно придётся рассматривать её, как множество. И пользоваться свойствами вроде «площадь объединения равна сумме площадей фигур минус площадь пересечения», «если одна фигура лежит внутри другой, то площадь первой не меньше площади второй»… или идти на поклон к матанализу, где интеграл определяется опять же в терминах включения множеств.
                                                      • 0
                                                        Математика зиждется на куче эвристик, а вывод её из того или иного набора аксиом (которые тоже, кстати, эвристики) — лишь один из способов пытаться её формализовать. Неудавшийся и поныне, кстати. (пруф в книжке Мориса Клайна «Математика, утрата определённости»)
                                                        • –2
                                                          На эвристиках зиждутся физика и прочие естественные науки, а математика основана на аксиомах и только.
                                                          • +1
                                                            Аксиомы — это эвристики, которые решили не доказывать. Учите матчасть.
                                                            • 0
                                                              Гм. Поправьте меня, если вру, но эвристика — это же умозаключение, полученное в результате наблюдений, тогда как аксиома — «истина, очевидная сама по себе».
                                                              • +2
                                                                «очевидная» — значит наблюдаемая :)
                                                • 0
                                                  Почему же не пройдёт? Если грубо — то берём направление и длину радиус-вектора точки на круге, потом записываем биты их двоичных записей через один, получаем двоичное число — это направление на точку окружности. К сожалению, будут проблемы с центром круга и двойным представлением двоично-рациональных чисел, но и их можно обойти. Так что биекция между кругом и окружностью строится. А площади у них разные :)
                                                  • 0
                                                    Почему же не пройдёт?

                                                    Круг изоморфен сфере без точки, которая изоморфна плоскости (преобразование Римана). А мощность плоскости больше мощности одномерного отрезка.
                                                    Да и если бы такое преобразование существовало, оно задавало бы линейный порядок на множестве комплексных чисел, а такого порядка не существует.
                                                    • 0
                                                      Линейный порядок на комплексной плоскости задаётся легко: (a1+i*b1<a2+i*b2) == (a1<a2 || (a1==a2 && b1<b2)). Он не инвариантен относительно умножения, но для порядка это не обязательно. А отрезок и плоскость имеют одинаковую мощность — мощность континуума.
                                                      • 0
                                                        Да, вы правы, мощности площади и отрезка совпадают, и биекция существует. По поводу порядка я тоже погорячился. Лексикографический порядок удовлетворяет аксиоматике.
                                                        • 0
                                                          Наверное, вы подразумевали «множество точек прямой и множество всех подмножеств множества точек прямой». Вот у них разная мощность.
                                      • 0
                                        наука о множествах и их свойствах
                                        Кажется, подозрительно близко к ООП;-)
                                        • +1
                                          Хорошее замечание. Видимо, и структура математики, и ООП возникли из одного и того же факта — что мы воспринимаем Вселенную как набор объектов.
                                          • +1
                                            подозрительно близко к ООП

                                            Нет, не близко. Математические объекты не активны, они не выполняют никаких действий, не имеют состояний, они вечны и неразрушимы в бесконечном мире чистых идей. Человек может выполнять преобразования над объектами, получая новые объекты из этого мира.
                                            Функциональное программирование гораздо более близко математике, чем ООП.
                                        • +1
                                          только второго и более глубоких порядков.
                                          «Социология — это та же атомная физика, только намного более глубокого порядка. Ведь общество состоит из людей, люди — из клеток, клетки — из молекул, молекулы — из атомов. Так что зная совсем всё об атомах, из этого можно, в принципе, за энное количество итераций, вывести законы социологии.» Только вот в реале даже двухатомную молекулу не научились рассчитывать аналитически (более того, даже задачу трёх тел не научились решать)…
                                          • 0
                                            Да, социология — один из системных эффектов квантовой физики. Только вот математики пока не обнаружили способов почитать имеющие место свойства количества типа этих трёх тел, да и Гейзенберг мешает…
                              • –1
                                Чистая математика — это такой предмет, где мы не знаем, о чем мы говорим, и не знаем, истинно ли то, о чем мы говорим. (с)
                                Имеет мало общего с программированием. Согласен с автором по поводу креативности.
                                • 0
                                  Ну так философия сидхов, а как вы хотели?
                                • +15
                                  Да, выглядит разумным хотя бы потому, что включает в себя интерпретацию здравых принципов:
                                  — YAGNI
                                  — DRY
                                  — fail fast (let it crash)
                                  • +4
                                    Мне кажется, что речь в основном идет про KISS.
                                  • +8
                                    Почему люди всегда из одной крайности бросаются другую.
                                    Почему из крайности чрезмерной абстрактности и оптимизации нужно бросаться в жесткий и глючный код без ооп и паттернов, который ни на шаг не отступает от текущего желания заказчика.

                                    Разве единожды написанный код остается неизменным навсегда, разве его не нужно поддерживать?
                                    Разве заказчик всегда абсолютно точно знает чего он хочет?

                                    Главное это баланс, между этими двумя подходами. Хорошая архитектура сорханит огромное количество времени и сил в будущем. Ваш подход не даст затянуть проект на миллионы лет.
                                    • +22
                                      А разве Вы всегда знаете будущие желания заказчика? Да, писать жесточайший хардкод — не круто и не практично. Но писать универсальное и гибкое решение на все случаи жизни, когда от тебя требуют простое и быстрое это еще менее правильно. Простой пример: у моего знакомого при устройстве на работу попросили написать простой 2D пинбол в качестве тестового задания. Он провозился около 2х недель и не смог его сделать. Когда я узнал причину мне было одновременно и смешно, и грустно: он не смог осилить реальную физику. Он посчитал, что простые правила угол падения равен углу отражения — не покрывают всех возможноей и вдруг от него хотят чего-то больше. Начал реализовывать реальную физику и когда реализовал что-то более менее похожее понял, что все это дело отжирает ресурсов как хорошая трехмерная игра. Вывод только один: не надо угадывать что нужно заказчику. Надо у него это спросить.
                                      • +4
                                        Я не призываю делать универсальное во всех планах решение или угадывать что нужно заказчику. Просто проектировать с пониманием того, что некоторые требования заказчика могут измениться.

                                        Например, если заказчик просит написать ему 2 отчета. Мой тезис, что появление третьего отчета лишь вопрос времени. Я не призываю реализовывать все возможные отчеты. Или например заказчику нужны отчеты в определенном формате, стоит понимать, что через некоторое время может появиться новый формат.

                                        В вашем примере я предлагаю не хардкодить физику внутри объектов, а вынести движок в отдельный уровень абстракции и реализовать простую физику. В этом случае объем работ будет почти тот же, зато если понадобится реализовать реальную физику сделать это будет гораздо проще.
                                        • +7
                                          Я с Вами согласен. Если мне ничего не будет стоить по времени сделать немного абстрактней — без проблем. Но обычно это выливается в миллионы CMS, Framework'ов и других «супер крутых велосепедов», когда надо-то было сделать типовой проектик. Большинство программистов, с кем я общался — не чувствуют грани между «я облегчаю себе этим жизнь вбудущем» и «я делаю никому не нужный комбайн, который никогда не будет применен на практике». Я недавно (около года назад) начал писать изометрическую игру в качестве хобби и для того, чтобы освоиться с canvas\HTML5. Сначала я создал себе список задач, который вел к получения универсального супер движка, на котором можно написать супер крутую игру любой сложности ) Продержался около 3 месяцев и понял, что интерес пропадает, так как кроме абстрактного движка у меня ничего нет. И я поменял концепцию: я начал писать только то, что мне нужно для этой игры и в данный момент. В итоге я имею: 5к строк говнокода на сервере + около 12 к строк говнокода на клиенте, который приходится часто пилить под новые задачи. НО! этот говнокод я написал за те же 3 месяца. Потом я еще около месяца потратил на причесывание кода (сказалось отсутствие опыта в JS). В итоге подход «ситха» — 4 месяц и готовый проект, подход «джедая» — 3 месяца и крутой движек, которой написан был на 30% и ни разу не опробованный в действии. Сейчас я уже в свою удовольствие допиливаю проект и добавляю абстракции где это действительно необходимо.
                                          • +2
                                            А в мире есть только 2 подхода «ситхов» и «джедаев»? Я призываю вас искать баланс. Если есть какая-то фишка которую долго или сложно реализовывать — реализуйте криво, но предусмотрите возможность безболезненной замены кривой реализации на правильную.

                                            В случае своего проекта не важно как это сделано, ведь он нужен только вам. Но проект заказчика сегодня реализуете вы, а через год может дорабатывать кто-то другой. Да, проблему поддержки кода будет не ваша, но я боюсь представить каково будет поддерживать проект написанный тремя разными командами по пути «ситхов». В результате заказчику вместо доработки проекта придется его целиком переписывать.
                                            • +1
                                              Пропробуйте у заказчика спросить что для него важнее: сделать быстро и за малые деньги, запуститься и начать получать профит, а только потом думать о развитии или сделать качественно и дорого, но зато всегда можно дешево развивать? Я думаю процентов 90 проголосуют за первый вариант, так как пока Вы делаете качественно я сделаю быстро и займу Вашу нишу. Я не призываю писать говнокод. Я призываю писать за деньги заказчика то, что хочет заказчик, а не то, что Вы считаете, что он хочет. А по поводу баланса: серебрянной пули нет. Зависимость, к сожалению, между качество и скоростью совсем нелинейна. Вы не сможете делать и среднего качества продукт и потратить всего на 50% больше времени. Скорее всего повышение качества на уровень увеличит трудозатраты на порядок. Очень интересная книжка у ДеМарко на эту тему есть. Прочитал на одном дыхании. Называется «Роман об управлении проектами»
                                              • +2
                                                сделать быстро и за малые деньги, запуститься и начать получать профит, а только потом думать о развитии или сделать качественно и дорого, но зато всегда можно дешево развивать?

                                                Вы исходите из предположения, что бизнес заказчика какой-то стартап?

                                                Но зачастую бизнес обращается к (новым) разработчикам, потому что текущие решения не успевают или явно вот-вот перестанут успевать за развитием бизнеса из-за первоначальной архитектурной жесткости, нерасширяемости и т. п. Текущие потребности бизнеса худо-бедно обеспечены, но он хочет в будущем быстрой реакции на новые потребности. Вот и «приходится» создавать конструкторы в которых большинство новых требований реализуются (ну или должны реализовываться) декларативным описанием новых сущностей и правил их взаимодействия чуть ли не рядовым менеджером на естественном языке за несколько минут.
                                                • +1
                                                  Я не имею ничего против. Я уже раз десять повторил, что надо исходить из требований заказчика. Если мне скажут сделать супер гибкую систему и не важно сколько времени\денег — за их деньги любой каприз. Но зачастую получается, что заказчик хочет просто сайт-визитку, а разные студии заставляют его еще платить за супер цмс и миллионны часов разработки, что позволит ему расширить визитку до магазина (сам работал в такой судии. По сути развод клиентов на деньги). И так как заказчик не понимает что это такое, то платит. А на самом деле можно было за 2 часа и 1000 рублей сверстать одну страницу и все.
                                                  • 0
                                                    Развод клиентов на деньги совсем другая ситуация. Я скорее про затягивание сроков (по крайней мере в рабочих часах, а не календарных) из-за желания программистов сделать «красиво» в рамках фиксированного бюджета.
                                                    • 0
                                                      Я считаю, надо дать программисту что-то сделать красиво. Пусть не в этом проекте, а в каком-нибудь другом. Опыт «делания красиво» быть таки должен.
                                                    • 0
                                                      Насчёт ЦМС — на то они и ЦМС, чтоб не писать каждый раз заново под нового заказчика, а копировать типовую. Или вообще держать всех заказчиков на одном сервере и единственном работающем экземпляре этой ЦМС.
                                                  • +2
                                                    Такой подход неплохо работает в схеме, взяли проект, быстро написали, сдали и забыли.
                                                    Можно организовать работу по другому: Разбить проект на этапы, сделать минимально необходимый функционал, выделив большие и сложные куски на последующие этапы. Клиент будет видеть как продвигается проект, корректировать направление развития (реализовывать функционал в зависимости от его нужд). Оплату тоже можно делать поэтапно, тогда клиент видит за что он платит. Возможно на каком-то этапе клиент поймет, что ему нужно не то что он просил или ему нужно что-то еще, чего он не просил.

                                                    Выбор из этих двух подходов сильно зависит от самого проекта, в частности его размера и сложности.

                                                    Но это все не проблемы разработки. Это проблемы управления проектом и взаимодействия с заказчиком.
                                                • 0
                                                  Но обычно это выливается в миллионы CMS, Framework'ов и других «супер крутых велосепедов», когда надо-то было сделать типовой проектик.
                                                  1) Вам предлагают не «миллионы CMS и Framework'ов», а пока только один уровень абстракции. Вполне вероятно, что им дело и ограничится. 2) У начинающего разработчика за спиной обычно ещё нет «типовых» проектов. Есть даже мнение, что наличие таковых является отклонением от нормы, и, когда таковые появляются, надо переходить на более высокий уровень;-)
                                              • 0
                                                У вашего знакомого, в общем, просто был недостаток опыта. Причём опыта, скорее, не «исполнительского», а «менеджерского» (точнее «исполнительского» — опыта, а у «менеджера» это скорее будут просто «знания»). Теперь он знает, сколько (хотя бы по порядку) человеко-часов и вычислительных ресурсов требует реальная физика (интересно, а шарик у него был материальной точкой или обладал ещё и моментом инерции?), какие в её использовании риски и почему этот вопрос нужно «не отходя от кассы» прояснять у заказчика.

                                                В его защиту, точнее, в защиту его образа действий, можно сказать то, что иногда бывает так, что переспросить у заказчика невозможно, и вообще «привычка переспрашивать плохо характеризует командира».

                                                Насчёт знания будущих желаний заказчика — умение частично предугадывать будущие желание заказчика — вещь нужная и полезная, но 1) в основном руководителям и 2) приходит обычно с опытом.
                                                • 0
                                                  Я бы сказал, что главная проблема в другом — он, видимо, ударился в самую сложную (и, наверное, самую интересную для него) часть, решив реализовать её близко к идеалу, вместо того, чтобы в кратчайший срок выкатить простейший интерфейс с простейшим физ. движком (а-ля «прототип») и спросить развитию чего отдать приоритет. Это было бы уже не переспрашивание на пустом месте, а уточнение по приоритетам при наличии «плана действий». Командиру поставили задачу разгромить противника и занять высоту N, а он, оценив силы свои и противника и набросав общий план, уточняет, что быстрее нужно — разгромить или занять? А то может получиться, что разгромит, а занимать некому будет. Или нечего :) Или займёт, но вынудив противника отойти без боя и, как следствие, без потерь.
                                                  • 0
                                                    Я бы сказал, что главная проблема в другом — он, видимо, ударился в самую сложную (и, наверное, самую интересную для него) часть, решив реализовать её близко к идеалу
                                                    «Лучше предположить худшее и, может быть, получить приятный сюрприз, чем понадеяться на лучшее и, может быть, получить облом и разочарование». «Хуже — значит сложнее». Есть такие принципы, только не всегда срабатывают, особенно вместе…
                                                    • 0
                                                      Начинать с решения самой сложной из предстоящих задач — особенно, когда её решение критично для проекта в целом — очень здравый поход. Ибо решить всё остальное, а на ней обломаться — хуже, чем обломаться на ней сразу, и не тратить время на уже ненужное остальное.
                                                      • –1
                                                        Решать задачу, не будучи уверенным в том, что решение возможно, — это не «разработка», а «исследования», заниматься ими лучше до работы над проектом, за который заказчик платит деньги, а не во время неё.
                                                        • 0
                                                          Да, но за пределами проекта в ближайшей перспективе эта задача может вообще не иметь ни применения, ни смысла. Разве что придумать интересный хобби-проект специально для неё?
                                                          • 0
                                                            Такая часть выделяется в отдельный таск и заказчику предоставляются на выбор различные альтернативы, как минимум: пилим этот таск прежде всего или пока делаем для него фэйковую реализацию за абстрактным интерфейсом и пилим остальные таски.
                                                          • +3
                                                            Исследования могут быть частью проекта.
                                                            Т.е., мы знаем, что это может быть решено, но пока не знаем как — пока пишутся другие части проекта один из разработчиков занимается исследованием.
                                                            • +1
                                                              Исходя из слов «а на ней обломаться» я предположил более худший расклад — что мы не знаем, может ли это быть решено вообще…
                                                              • 0
                                                                «Мы отлично знаем, что она не имеет решения! Мы хотим знать, как её решать!»
                                                                • +1
                                                                  знать, как её решать
                                                                  … или обойти…
                                                                  • +1
                                                                    Верно. В процессе исследования может выяснится, что в текущей постановке задача решения не имеет, но если подумать, то возможно какое-то из списка требований нам на самом деле не столь критично, или скажем того же результата можно достичь иначе… В общем, не обязательно на самом деле начинать со самой сложной задачи.
                                                          • +3
                                                            Не совсем. По мере приближения к сложной части станет более понятно, какие к ней в действительности требования, какие масштабы входных данных, какая степень приближения допустима… Вполне может оказаться, что там совсем не та задача, какой она казалась сначала. Или что её можно заменить на суперэвристику, неотличимую по поведению от истинной задачи.
                                                          • +1
                                                            Если мы ограничены дедлайном, то что лучше: предъявить по наступлению заказчику нечто вообще неработающее в его понимании (физдвижок пинболла, застрявший где-то на уровне оптимизации расчетов релятивистских и квантовых эффектов при трении о поверхность и воздух и взаимодействия с магнитным полем Земли во время пуска шарика, но не дошедший ещё до расчетов столкновений, причем без всякого GUI) или функционально законченное приложение, пускай и не в полную меру реализующее ТЗ (есть юзабельный GUI, есть примитивный движок, причем они разделены каким-то абстрактным интерфейсом и могут доводиться до ума независимо)? Даже не говоря вероятности что это окажется именно тем, что и хотел заказчик, то в каких случаях больше вероятность продолжения проекта (пускай уже и другим разработчиком, но не с нуля)?
                                                            • 0
                                                              Смотря что заказчик считает задачей… В данном случае, реальная физика была, как я понял, очень опциональной фичей, этаким бонусом для вау-эффекта, и на неё время тратить стоило в начале очень ограниченно, не увлекаясь. Лишь оценить потенциальные затраты и требования к внутреннему API, и усилием воли вернуться к вопросу реализации без неё.
                                                              • 0
                                                                Хотя, могу представить себе затею пинбола, опирающуюся именно на физику, то есть изначально оправдываемую лишь тем, что в игре будет физика, и именно этим игра должна будет привлекать покупателей. Тогда заказчика недоделанный движок восхитит сильнее прототипа GUI.
                                                                • 0
                                                                  Если на этом не было сделано акцента в ТЗ, то маловероятно. И то, скорее стоило сделать простую реализацию, интерфейс к ней, а потом пилить более точную физику, чтобы в любой момент можно было продемонстрировать/сдать готовое приложение.
                                                                  • 0
                                                                    Мне кажется, тогда надо тем более сначала делать прототип GUI (вместе с интерфейсом к физике) как намного более лёгкую часть, к тому же облегчающую работу с движком;-)
                                                                    • 0
                                                                      Это именно та ошибка, от которой спасает приведённое мною соображение. Для отладки физического движка весь GUI пинбола не нужен, нужны частные специализированные тесты, которые даже могут не быть графическими.
                                                        • +2
                                                          Жесткий код — не глючный код без ооп (иногда он даже с паттернами). Это парадокс такой — концентрирование на жесткости и краткости приводит к гибкости, только вынужденной. Жесткий код — совсем не глючный код. Под жесткостью как раз понимается не то, что его нельзя читать или менять, а то, что в нем максимум ограничений для работы программы ровно в заданном русле.

                                                          Вам же, когда надо завести переменную int, не приходит в голову сразу, наперед, дать ей тип double? Ведь в последнем случае код будет более гибким. Double может работать и с целыми числами и если вдруг в будущем понадобится, с плавающей точкой.
                                                          • –2
                                                            Мне приходит в голову использовать динамическую типизацию :)
                                                            • 0
                                                              Переменные — вообще зло, константы намного лучше;-) (оговорюсь сразу, я веду речь о Java). У меня в Eclipse реально стоит опция чтоб «финалить» все переменные (какие можно) при сохранении кода…
                                                              • +2
                                                                Вам же, когда надо завести переменную 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 микрон. Этого хватит, чтобы поместилась вся Земля с началом координат в любой точке внутри или на поверхности. Как вы думаете, этого «хватит всем»?
                                                                • 0
                                                                  Поддержу. Давно пришел к выводу, что для каких-то значений в принципе не целых (по большому счету всё кроме нумерации и количества элементов, смещений и т. п. в массиве/списке/множестве/...) нужно использовать float по умолчанию (не забыв про эпсилон при сравнении), а лишь потом оптимизировать через integer, если в том возникнет нужда. А то и вообще спрятаться от конкретной реализации за абстрактным числовым классом. А так выбор integer, да ещё с каким-то множителем/делителем исходя из соображений быстродействия/памяти — типичная преждевременная оптимизация.
                                                                  • 0
                                                                    Прежде, чем использовать float, всё равно придётся откуда-то догадаться, хватит ли нам в этом месте 23 бит точности (если речь про C-шный float, конечно).
                                                                  • +1
                                                                    Вы смотрите с позиции оптимизации. Если выбор пал на int только потому, что он меньше в памяти занимает и якобы хватает — то это, понятно, не верно.
                                                                    Я имею ввиду, если переменная должна хранить по смыслу количество или что-то, счетное. Double — тоже может. Но такой выбор — потенциальный баг
                                                              • +4
                                                                Ситхи любят баги. Их ждут, их уважают. Как только встречается баг, ситх бросает всё и уделяет внимание только ему. У багов такая природа: пока не выяснили причину, не известна важность и урон бага. Если в программе проявился баг – программа теряет доверие. Лучше ей не работать.

                                                                Основная причина, по которой обнаружение бага (или любого другого неожиданного поведения) так радует — что после его исправления эффективность программы (и быстродействие, и качество результатов) вполне может перейти на новый уровень. Кроме того, за время охоты можно найти много интересного (но пока не проявившегося) и в других местах программы.
                                                                • +5
                                                                  Почти согласен насчёт исключений. Как-то раз довелось поработать с человеком, который панически боялся того, что исключение может каким-то образом прорваться к пользователю, потому что исключение нанесёт пользователю непоправимую психологическую травму. Именно поэтому КАЖДЫЙ метод в его коде был окружен в try...cath, 90% из которых были абсолютно глухими — т.е. просто игнорировали ошибки. Некоторые ошибки он складывал в лог и ни одну не выпускал наружу, даже те ошибки, в которых был явно виноват сам пользователь, например ошибки ввода и др. К счастью наше сотрудничество было не очень долгим, но в итоге моральную травму получил я, потому что пришлось переписывать после него три тонны винегрета.
                                                                  Падать при любом исключении — явно не комильфо, исключения нужно делить по критичности на разные уровни но в общем идея правильная.
                                                                  1. Делить исключения по критичности. Некоторые стоит показать пользователю, на некоторых стоит завершить работу программу, а иногда — просто повторно вызвать метод, выдавший исключение.
                                                                  2. Не пытаться объять необъятное и предусмотреть 100% возможных исключений в 100% кода. Код распухает и становится неоптимальным и нечитабельным.
                                                                  3. Никогда не надеяться на то, что кто-нибудь когда-нибудь захочет почитать логи. Логи существуют для срочного решения проблем на удалённых площадках, куда нельзя нормально добраться со средствами разработки.
                                                                  • +1
                                                                    У МакКоннелла в «Совершенном коде» обработке ошибок посвящена целая глава — одна из немногих в этой книге, в которых я лично для себя почерпнул что-то существенно новое и полезное. Там ещё зависит от критичности программы: при расчёте дозы облучения при радиотерапии лучше аварийно завершить программу, ошибку отрисовки можно и пропустить…
                                                                    • 0
                                                                      В смысле, ошибку отрисовки в редакторе электронных таблиц.
                                                                      • 0
                                                                        Компоненты DevExpress при любом неперехваченном исключении в методе отрисовки рисуют вместо компонента красный конверт (Белый прямоугольник, перечеркнутый и обведённый красными линиями). Мол, пишите письма. Компонент прекращает отрисовку до перезагрузки формы.
                                                                        • 0
                                                                          Я пару дней назад видел неотрисовку части рабочего стола в Vista после свёртывания всех окон;-) Даже перезапустил — думал, серёзное что-то… Оказалось, зря беспокоился.
                                                                  • –7
                                                                    ХМ. Забавно. Вообще то концепция ООП подразумевает, что каждый модуль(тобиш класс) — это абсолютно самостоятельная и независимая единица. На практике такого добиться удается редко, но цель — известна.
                                                                    А если написать хардкор правильно (в лучших традициях жанра ООП) — то он автоматически становиться практически бесконечно расширяемым.

                                                                    Короче отпадает большинство проблем, если знать теорию и пытаться её придерживаться.
                                                                    НО! Есть одно маааааленькое НО: для этого нужен моск ;-)
                                                                    • –3
                                                                      Единственное зерно рациональности, с которым могу согласиться: наша задача сделать заказчика HAPPY как можно быстрее. Но это не значит, что нужно реализацию всех методов начинать с вставки туда try...catch, после чего пожно лить туда откровенную халтуру. Надо хотя бы немного задумываться во что выльется плохой код.
                                                                      • 0
                                                                        Желание делать код гибким — от лени. Разработчик имеет свои собственные идеи, что в дальнейшем может происходить с его продуктом и потому старается минимизировать свою работу в будущем. Если прогноз был верный — он на коне. Если нет — проиграл вдвойне: создавая «лишнее» сейчас да еще и поддерживая это потом.
                                                                        • +5
                                                                          На стройке двое рабочих носят кирпичи. Один берет по 10 штук, второй носит по одному. Прораб подходит ко второму и говорит
                                                                          — Ты что же это творишь? Вон человек надрывается, а ты по одному таскаешь?
                                                                          — Я что виноват в том что он ленивый?
                                                                          — ???
                                                                          — Лично мне не лень лишний раз сходить.
                                                                          Так же и у вас. Желание оптимизировать разработку с прицелом на будущее списываете на лень.
                                                                          Просто меру нужно знать.
                                                                          Совсем плохая ситуация, когда версия ПО, в которой доработок максимум на версию на 1.0.1 превращается в 2.0 потому что весь старый код нужно выбросить и переписать с нуля, потому что вариантов его доработок не предусмотрено и внутри всё отлито одним неразделимым куском.
                                                                          • +2
                                                                            Еще хуже, когда из 12 месяцев разработки нового продукта 6 было отведено на построение гибкой архитектуры, чтобы «расширять потом». А развите продукт не получил. В итоге 6 месяцев работы в пустую. А может если бы выпустили на эти 6 месяцев раньше — продукт бы и взлетел. Как написал cjey нужно искать баланс. Но сделать это практически нереально. В итоге все скатывается либо в говнокод, либо в космолет с сотнями тысяч строк кода. Но все разработчики считают, что это тот самый баланс.
                                                                            • +2
                                                                              С другой стороны плохо, когда взлетевший проект умирает потому, что заказчик не согласен с ценой развития продукта.
                                                                              Когда для замены масляного фильтра необходимо полностью разобрать двигатель.
                                                                              Нужен анализ причин почему не взлетел продукт. Плохо написан? С гибкостью разработки это редко связано. Не соответствует потребностям рынка? Это ошибка бизнес-аналитиков и маркетологов. Что-то было не учтено при составлении проекта. Если есть некое видение развития продукта, то разработчик обязан это видение учитывать и не поддаваться на провокации «давайте сейчас очень по-быстренькому как-нибудь напишем первую версию, а потом будем постепенно дорабатывать». Практика показывает, что при таком подходе во второй версии переписывается 50-60% кода, а процентов 20 монолитного кода, в котором просто не смогли разобраться становится пудовой гирей, которая тянется за проектом в будущем и тормозит его развитие.
                                                                              • +1
                                                                                Нужен анализ причин почему не взлетел продукт.
                                                                                Для этого, в общем, нужно влезть под черепную коробку к каждому потенциальному потребителю;-) Всё остальное — это, по большому счёту, только предположения с разной, и не всегда ясной, степенью приближения к действительности, и такой анализ никогда не будет точным. Надо ставить вопрос — а зачем мы хотим это знать и насколько это нам реально нужно, чтоб вовремя (по затраченному на этот post-mortem анализ бюджету и ресурсам) остановиться.
                                                                                • 0
                                                                                  Я просто хотел сказать, что этот вопрос выходит за рамки разработки и находится в области менеджмента. От сабжа (гибкости архитектуры) напрямую не зависит.
                                                                                • 0
                                                                                  С другой стороны плохо, когда взлетевший проект умирает потому, что заказчик не согласен с ценой развития продукта.
                                                                                  Интересно, много ли реально бывает таких случаев? Мне кажется, если первая по-настоящему взлетевшая версия внезапно оказалась «прототипом на выброс», то всё равно она должна принести достаточно денег, чтоб иметь возможность переписать с нуля… Ила заказчик принимает решение использовать по максимуму то, что есть и не вкладываться в развитие?
                                                                                  • 0
                                                                                    Здесь главный вопрос в размерах прототипа.
                                                                                    Я говорю о достаточно больших продуктах на сотни тысяч (полгода-год разработки) человеко-часов. Обидно такие продукты переписывать с нуля.
                                                                                • +1
                                                                                  А это не проблема архитектуры, а проблема планирования проекта. Что мешает разбить проект на куски, быстро сделать проект с минимальным готовым функционалом, отложив большие и сложные задачи на последующие этапы. Клиент будет видеть развитие проекта, сможет корректировать направление разработки, раньше поймет какого функционала не хватает и в случае задержки будет спокойнее к ней относиться.
                                                                                  • +1
                                                                                    Да, Ваш подход идеален в рамках конкурентного рынка. С другой стороны Вы убиваете таким подходом понятие прототипа. Вы не делаете прототип, Вы делаете минимальную рабочую расширяемую версию. Я все таки привык работать с прототипами, которые не превращаются затем в продакшн, а выкидываются и переписываются. Но может я не прав )
                                                                                    • +2
                                                                                      Выкидываемые прототипы — спорная концепция (как, в прочем, и противоположный тезис, что их выкидывать нельзя), не думаю, что к ней стоит привыкать;-) Выкидываемый или расширяемый — тут всё зависит от многих факторов. На языке со статической типизацией, мне кажется, в среднем проще сделать расширяемый прототип, чем на языке с динамической типизацией: цена рефакторинга меньше…
                                                                                      • 0
                                                                                        Всё зависит от размеров проекта. Если планируется проект на срок разработки 12 месяцев силами 5+ человек, то вряд ли имеет смысл писать прототип — слишком дорогое получится удовольствие. Лучше потратить это время на составление плана разработки, вижена на будущее развитие и глубокую проработку архитектуры.
                                                                              • +4
                                                                                Отличная статья! Жестко, но справедливо. И в целом, на мой взгляд, все верно
                                                                                • +5
                                                                                  Хотелось бы больше иллюстраций по вселенной SW. Мне как «креативному» программисту нужны образы, чтобы в них видеть больше чем очередной набор «галок» ;)
                                                                                  • +9
                                                                                    private void injectMembers(Object t) {
                                                                                    /*
                                                                                              .          __---__
                                                                                            .     .   .-'...:...'-.               .          .
                                                                                                     / .  . : .__ .\
                                                                                              .     /........./  \ .\  .   .                            .
                                                                                                   / :  :   :| () | :\                  .        .
                                                                                                  :...........\__/....:         .
                                                                                           .      |___________________|              .                     .
                                                                                                  |...................|               .
                                                                                            .     :  :  :   :   :   : :                          .
                                                                                                .  \................./      .            .
                                                                                                    \  .  . : .  .  /   .                                .
                                                                                          .      .   \._........._./  .        .                   .
                                                                                                        -..___..-                .         .
                                                                                    
                                                                                        Dark side code
                                                                                    */
                                                                                        injector.injectMembers(t);
                                                                                    }
                                                                                    
                                                                                  • +11
                                                                                    Перевернутая шкала ценностей – это оценки в отрицательной части – плохо, хуже, еще хуже. Не бывает хорошо, лучше. Ситхи верят, что джедаи заблуждаются в плане: бывает хороший код, бывает лучше. Не бывает. Отрицательная шкала – это кругом только зло. И ситхи вынуждены выбирать меньшее зло. Джедаи выбирают наибольшее добро. Т.е. если они видят два решения, то они видят позитивные качества и на основании своих предпочтений выбирают то, что лучше.


                                                                                    Только ситхи все возводят в абсолют (с)
                                                                                  • 0
                                                                                    Да, жаль, что всему этому только опыт учит. До сих пор время от времени бью себя по рукам, когда хочется реализовать функциональность «на всякий случай». Не настают эти случаи, вместо этого настают другие, которым вся эта теоретическая гибкость только мешает. К тому же заделы на будущее часто содержат вполне настоящие баги.
                                                                                    • 0
                                                                                      Вы код пишете так же как статьи? Истинный джедай
                                                                                      • +10
                                                                                        Провокация! Автор джедай!
                                                                                        Ситх не мог написать столько воды про котят, про самих ситхов и джедаев ибо надо «Убить в себе гуманитария» и только суть, только хардкор.
                                                                                        • +2
                                                                                          А это текст для падаванов и троллинг джедаев )
                                                                                          • 0
                                                                                            Откуда информация?
                                                                                        • +3
                                                                                          Согласовано.
                                                                                        • –1
                                                                                          Читается интересно, но единственная полезная мысль здесь — не надо заниматься преждевременной оптимизацией. Все остальное — простите, бред, противоречащий здравому смыслу.

                                                                                          И да, статья чисто гуманитарная.
                                                                                          • +2
                                                                                            «Уровень воды достиг максимума за последние годы»
                                                                                          • +12
                                                                                            Говоря проще, лично для меня существует принцип неувеличения энтропии. Это значит, что я продолжаю искать решение, которое мне будет не лень воплощать. А мне всегда лень, поэтому я пишу мало кода. Я вообще не люблю кодить. Именно поэтому, если я увижу красивый фреймворк, который изящно (просто для программиста) решает одну мою проблему и еще 50, решения которых мне не нужны, я буду его использовать, потому что я не люблю кодить. Fuck the fuel economy. Пускай энтропия будет где угодно, только не у меня в уме.

                                                                                            И общий паттерн: вынужденность && конструктивность && достаточность. Чаще всего, вынужденность == бритва Оккама, конструктивность == мне лень писать много кода, достаточность == это решение не подходит, если потенциально потребует переписывания.

                                                                                            Общая логика: мне нужно писать как можно меньше кода:
                                                                                            1. мало кода — мало отладки,
                                                                                            2. мало отладки — больше времени на написание полезного кода,
                                                                                            3. мало кода — мало глюков,
                                                                                            4. мало кода быстрее работает**,
                                                                                            5. мало кода быстрее читается,
                                                                                            6. мало кода проще понимается,
                                                                                            7. мало кода проще поддерживается,
                                                                                            9. мало кода быстрее писать,
                                                                                            8. пускай софт падает тогда когда нет смысла продолжать, это лучше, чем писать много кода.

                                                                                            И еще: креативность нужна ДО того, как началась реализация.

                                                                                            Понравилась первая часть статьи, а дальше, особенно часть с фигурирующим заказчиком — нет. Почти всегда заказчик — это идиот, который вынуждает нас под свою ответственность поднимать уровень энтропии. Чаще всего, он хочет то, что не является вынужденным, даже для него. И многое другое.
                                                                                            • +1
                                                                                              Всё верно — до начала реализации идет работа с заказчиком. Требования обсуждаются, принимаются. Идиотские отклоняются. Идет плотное и не одностороннее общение. После принятия требований — никакого креатива.

                                                                                              Но считать заказчика идиотом, даже если это так, плохо. Много раз замечал тенденцию, когда программисты думают, что они лучше знают, что надо заказчику, чем он сам.
                                                                                              • +1
                                                                                                Но очень часто программисты оказываются правы, если они в предметной области варятся годами, а заказчик только в неё пришел.
                                                                                                • +1
                                                                                                  Считать кого-то идиотом, если это невынуждено неправильно. Это также плохо, как и много кода. Вообще, все невынужденное — это плохо.

                                                                                                  Много раз замечал тенденцию, когда программисты думают, что они лучше знают, что надо заказчику, чем он сам.

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

                                                                                                  Есть и другая крайность. Все заказчики, с которыми мне приходилось работать, все до одного, хотели лишнего. Причина? Жадность. БОЛЬШЕ! БОЛЬШЕ! БОЛЬШЕ СВИСТОПЕРДЕЛОК!

                                                                                                  Поэтому я чуть-чуть перефразирую фразу: "зачастую, программист лучше знает, что заказчику НЕ надо".
                                                                                                  • 0
                                                                                                    Огромное спасибо за изменённый вариант фразы. Вот уж истина — так истина. Не поспоришь! Возьму на вооружение.
                                                                                                • 0
                                                                                                  Много раз замечал тенденцию, когда программисты думают, что они лучше знают, что надо заказчику, чем он сам.
                                                                                                  Мне кажется, что они лучше знать, что надо заказчику, чем он сам (точнее, лучше уметь сформулировать), — это скорее функция руководителей проекта…
                                                                                                  • +1
                                                                                                    Нередко он программист или бывший программист (а бывших программистов не бывает :)
                                                                                                    • +1
                                                                                                      Могу усилить тезис: на этом пути программисты и становятся руководителями проектов;-) Только надо уметь реально формулировать, что лучше заказчику, лучше, чем он сам.
                                                                                                • 0
                                                                                                  Еще, может не правильно донес идею. Заказчик в посте — это не обязательно внешний заказчик. Это некий символ исходящих требований. Заказчиком может быть и сам программист. Программа обычно служит для какой-то цели, в какой-то предметной области. И код, как описание, должен ее описывать.
                                                                                                  Плохой код — это код, в котором не видно такого описания. Конечно, почти нельзя так добиться, чтобы везде в коде было только описание того, что нужно. Но отрицательная шкала оценок кода снимает это противоречие. Код и так плохой. Хуже тот, который не имеет отношения к описанию. Еще более худший код — код, который вообще ничего не описывает. Желательно, чтобы код был читаем локально. Без знаний «архитектуры». Открыв любую страницу кода, хоть там и тысячи страниц, на ней должны читаться намерения.

                                                                                                  К сожалению, люди с положительной шкалой скатываются в противоположность. Когда думают, что процент кода небольшой, который прямо решает задачу, а остальное — кирпичики — начинают писать программу ради программы. Это вроде как бы сняли фильм, где во всех подробностях описывается съемка фильма и ничего более. Как фильм, такой может существовать. Процент людей, которым он будет интересен — крайне мал.

                                                                                                  А в программировании всё ровно наоборот. Таких бессюжетных фильмов те самые 95 процентов. Программисты увлекаются чем угодно, что касается самого процесса — оптимизациями, многопоточностью, паттернами с гибкостью, распределенной архитектурой. Послушайте о чем они говорят и где лежит сфера их интересов в основном.
                                                                                                  Программист, полагая, что без всего этого не обойтись, и имея положительную шкалу оценок — ставит это во главу угла. Получается бессюжетный код.
                                                                                                • +1
                                                                                                  Оказывается, я ситх. И падаванов своих учу темной стороне силы…

                                                                                                  Правда во главу я ставлю удовлетворенность заказчика, а не уменьшение кода.
                                                                                                  Отсутствующий код не падает — заказчик доволен.
                                                                                                  Однако отсутствующая функция расстроит его. И вряд ли заказчика удовлетворит то, что она при этом не падает.
                                                                                                  • +3
                                                                                                    Всегда считал, что лучший код — этот тот код, который не написан. Он не упадёт, его не нужно покрывать тестами, не нужно рефакторить, и главное — он не потребляет ресурсов!
                                                                                                    • 0
                                                                                                      Я каждый раз как комичу новую функциональность — сравниваю объём старого и нового файлов. Если новый больше — расстраиваюсь, значит, я налажал.
                                                                                                      • +2
                                                                                                        Вы хотите чтобы новая функциональность добавлялась путем удаления кода? :)
                                                                                                        • 0
                                                                                                          Удаляется то, что мешает и оставшееся делает, что нужно. Знаете, как статуя, которая уже есть в куске мрамора, от которого нужно только убрать лишнее :)
                                                                                                          • 0
                                                                                                            В идеале — да :).
                                                                                                            • 0
                                                                                                              На этом основан ТРИЗ: механизма нет, а функции его выполняются :)
                                                                                                            • +2
                                                                                                              int main() {}

                                                                                                              Предлагаю добавить функциональность уменьшив объём кода :)
                                                                                                              • +1
                                                                                                                Удалить что-нибудь и появится функциональность «вывод ошибки при компиляции» :)
                                                                                                                • 0
                                                                                                                  main() {}

                                                                                                                  echo 'main() {}' > a.c && gcc a.c -o a && ./a
                                                                                                                  • 0
                                                                                                                    Можно и main(); оставить, но функциональность-то добавленная где?
                                                                                                                    • 0
                                                                                                                      пожалуй мне надо научиться читать)
                                                                                                                      ну по-читерски:

                                                                                                                      echo 'main(a){X;}' > a.c && gcc -DX='return a-1' a.c -o a && ./a
                                                                                                                  • 0
                                                                                                                    Вверху были комментарии о том, что топикстартер из одной крайности впадает в другую. Вы тоже?
                                                                                                                    • +1
                                                                                                                      Функциональность добавляется так.
                                                                                                                      На этапе ТЗ разработчик показывает заказчику, что именно этот модуль ему не нужен, а того же результата можно добиться комбинированием уже существующих.
                                                                                                                      Итог: функции main, как и самого модуля не будет.
                                                                                                                  • +7
                                                                                                                    Проект Wine был основан в 1993 году. Он представлял собой проект размером 0 байт. И был идеален по архитектуре и составу. Потом в него начали добавлять баги. Проект разрастался, к проекту стали подключаться новые разработчики, которые добавляли ещё больше багов. И поэтому при каждом новом релизе принято спрашивать «Чо опять сломали?!».
                                                                                                                    Lor
                                                                                                                  • +3
                                                                                                                    Не разделяю полностью путь ситхов, но признаюсь — статья вышла оригинальная.
                                                                                                                    • +3
                                                                                                                      Подход, описанный в статье обладает сильным рациональным ядром, здоровым прагматизмом. Более того, я во многом ему следую. Но, тем не менее, по описанной шкале, я бы всё равно отнёс себя к джедаям. Я продолжаю экспериментировать с кодом, подходами, языковыми конструкциями, стилями. Почему? Прежде всего, я люблю языки, и выразительность, которую в них можно найти. Несомненно автор прав, что это поэзия. Но я считаю, что эта поэзия просто необходима для развития языков, выплавления новых идей и концепций.
                                                                                                                      Допустим, сит изучает новый язык программирования. Что он в первую очередь сделает (после изучения основ синтаксиса)? Прежде всего он почитает рекомендации по стандартам стиля написания на данном языке, идиомам данного языка и в своём коде постарается их придерживаться. Тем самым на данном этапе он уже оградил себя от возможности найти что-то новое.
                                                                                                                      Вероятно, тут нужно соблюдать баланс. В каком-нибудь toy-проджекте или «академической» либе, которую ты мейнтейнишь, можно нести добро, а в суровом продакшене переходить на тёмную сторону.
                                                                                                                      Всем DRY.
                                                                                                                      • +3
                                                                                                                        Есть легенда, что каждый раз, когда пишут плохую статью на хабр – Бог убивает котенка. Пора признаться, что все мы – убийцы котят. У некоторых руки по локоть в крови. Первый шаг в сторону силы – признать в себе это. Любая статья – это привнесение во Вселенную хаоса. Любой символ – рост энтропии. Если мы признаем это, то спадет маска умиления и радости от написания статей. Всё, что мы делаем – плохо. И с этим нельзя ничего поделать. Можно только пытаться делать это в меньших количествах.