Как улучшить свой стиль программирования?

Исповедь 1


Я — разработчик. От своих работодателей я постоянно слышу, что работаю медленно и часто всё усложняю без веской причины. И что мне пора бы что-то с этим сделать. Во избежание.

Весь мой опыт программирования складывается из университетских работ и пары лет пребывания в различных компаниях. Критикующие меня люди неоднократно говорили мне, что в целом я разбираюсь в теме, так что я далеко не клинический случай, как можно было подумать. Однако, очевидно, я выработал совсем не те программистские привычки (как минимум, на взгляд работодателя) и мне нужно срочно изменить их. Везде, где бы я ни работал, мои решения, использующие иерархии мелких классов с делегированием поведения, признавались плохими. Говорят, будто так и надо писать, но это не так. Потому что всё это «как надо» может стоить мне работы.

Я начал читать книги. В них я видел все то же самое, от чего пытался убежать. Например: для одной разовой работы я воспользовался похожим кодом из другого проекта, для чего привел его к общему интерфейсу. Мой коллега, разбирая ошибку, наткнулся на этот код и спросил меня зачем я сделал всё так сложно для одноразовой-то работы. Но для меня это не одноразовая работа! Оба проекта очень похожи и тот же самый абстрактный код можно было бы использовать еще в нескольких.

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

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

Решения мирового сообщества разделились на четыре группы:
1.«Забить», т.к. опытные программисты — просто дураки. И если они долго проработали, это еще не значит, что они опытны (много голосов).
2. Спросить у критиков, как бы они структурировали код (столько же голосов).
3. Напроситься программировать в пару / сходить на курсы (немного голосов).
4. «Ну так пиши проще!» — нет никакой гарантии, что требования к новым проектам хорошо лягут на заботливо разработанный интерфейс (1 голос).

Все эти советы не выходят из области, в которой сформулирован вопрос, и потому не могут решить главную проблему — «Так что мне сделать, чтобы улучшить свой стиль программирования?» Пункт 4 подбирается ближе всех, но всё же далек. Проблема глубже.

Что делать?


Ролевые игры. Часть 1

Вы и ваш двойник открыли бизнес по автоматизации чего-нибудь. Конкретно вы из вас двоих — директор.

Какая у вашего двойника часовая ставка? Возьмите калькулятор и поделите число, указанное в трудовом договоре на 160. Если вы совершаете эти действия в рабочее время, то поделите результат еще на 60. Вот на столько (+20% льготной ставки в ПФР + 0.2% за травматизм + 6% УСН (половину можно зачесть из налогов ПФР) = +23.2% минимум) вы нагрели своего работодателя, развлекаясь здесь со мной. Знаете, как выглядит миллион рублей? Вспомните объем (и, особенно, качество) написанного вами за последний год — вот это и есть миллион. Стоит покупать ваш труд? Вы, уже как директор, купили бы?

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

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

А теперь, внимание, большой секрет. Для, вас, как директора, он уже никакой не секрет, а очевидная мысль — вам не нужны программисты. Вам надо решить проблему. Может, стоило заказать программу в другом месте или купить готовый модуль или вообще ничего не автоматизировать, а нанять людей на низкую зарплату. На текущий момент вы уже потратили 600 тыс. и не получили никакого пригодного результата.

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

Если из всей статьи вы готовы запомнить лишь одну мысль, то запомните эту: Программирование не самоценно, а программисты — обслуживающий персонал.

Эта мысль может вас задеть — всё нормально. Чем раньше вы примете её, тем более ценным специалистом вы сможете стать. В нашей культуре считается, что лучше быть господином, нежели слугой. Но если подумать, то общество и вы находитесь в некоторых отношениях. В этих отношениях вы можете занять роль «добровольного слуги» и общество (в лице работодателя и довольных клиентов) щедро вознаградит вас за вашу заботу.

Ролевые игры. Часть 2

Зайдем с другой стороны: ваш двойник — директор, а вы — разработчик.

К вам вот-вот заглянет директор, а фабрика абстрактных автоматизаторов еще не дописана, SQL-запросы не отлажены да и вообще за полгода пришло понимание, что всё должно быть не так.

Дилемма: никто не хочет работать тяп-ляп. Все хотят гордиться своей работой. Следовательно: (логическая ловушка) Да, я делаю медленно, зато правильно.
Если с «медленно» всё ясно, то что такое «правильно» — совсем не очевидно. На самом деле всё просто. «Правильно» — это когда за отведенный срок (±) появляется пригодная к использованию программа или сервис. Если ваше другое понятие «правильно» не приводит к появлению пригодного к использованию продукта за разумный срок, то ваше «правильно» никуда не годится. Тут нет простора для маневра. Вспомните, что программирование не самоценно.

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

Второй Большой Секрет: код — это всегда плохо. «Красивого» кода не бывает. Чем меньше кода, тем лучше. Любой код содержит ошибки, компромиссы и проблемы производительности.

  • Меньше классов, меньше функций, меньше кнопок, меньше связей и вообще — меньше.
  • Не пишите обобщенную функцию, если её функционал не встретился минимум три раза в разных местах.
  • Не пишите функции и методы класса до того, как у них появится пользователь. Т.е. сперва где-то появился вызов метода и только потом появился сам метод.
  • Вам не нужно три уровня наследования с шаблонным классом посередине.
  • Стандартный модуль вполне способен решить вашу задачу — почитайте еще раз документацию.
  • SQL — не единственное в мире хранилище. Очень много всего можно запросто хранить прямо в файлах в JSON.
  • Не думайте о системе «на вырост». Другие требования — другая система. Не пытаться строить в деревне небоскреб — это и есть архитектура
  • Этот алгоритм O(n^2) можно не оптимизировать до O(n logn), потому что в данном месте n никогда не больше 5, поскольку означает число задействованных пальцев на руке.
  • Вместо написания генератора таблицы её можно один раз сверстать в HTML — она незначительно меняется раз в полгода.
  • SVN — отличная система контроля версий. Особенно, когда вместе с вами её используют непрограммисты, работающие с вами над одним проектом.
  • Вам действительно нужно попиксельное освещение для визуализации мат.модели или стандартного GL_SMOOTH хватит? И, кстати, мы будем показывать её на выставке на 7-летнем ноутбуке со встроенной графикой.
  • Правда думаете, что цикл на итераторах работает быстрее, чем на индексах, особенно если сравнить первый и второй со временем доступа к диску?
  • Похожие классы в двух проектах — не повод связать один с другим. Считайте это случайным совпадением. Если вы сделаете общий класс, то отныне, при любом изменении, вам придется думать о двух проектах одновременно. Стоит ли это того? Вряд ли.
  • Доска с маркером + телефон с камерой отлично заменяют UML-диаграммы и большую часть программ прототипирования интерфейсов


Программист, принимающий во внимание коммерческие следствия своих решений, ценится на вес золота. Стив Макконел.

Исповедь 2


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

Весь мой опыт программирования складывается из школьных «проб пера», олимпиад, университетских работ, дополнительного образования, преподавательской деятельности, домашних проектов и 8 лет успешной работы в мелких, средних и крупных компаниях. В целом, я разбираюсь в теме. Очевидно, я выработал «те» программистcкие привычки (как минимум, на взгляд работодателя) и считаю нужным поделиться ими. Везде, где бы я ни работал, мои решения никогда не страдали манией «переиспользования». Говорят, будто так писать не хорошо, но это не так. Потому что всё это «как надо» может стоить работы не только мне.

Я читал книги и продолжаю читать. В книгах есть всё. Я пишу код почти каждый день (включая выходные: мне нравится писать код) и почти каждый день читаю документацию. У меня всё получилось далеко не сразу. Но я точно знаю, что терпение — самый короткий путь. Я никуда не спешу, потому что быстро — это медленно, но каждый день. Я отвязан от языка, парадигм, технологий и всего остального технофетиша. Мне просто нравится делать полезные программы для людей. Решать проблемы.

Замечу, что люди на похожих позициях (и самые продуктивные разработчики), придерживаются схожих мыслей. Поэтому здесь два варианта: либо что-то не так со всеми опытными разработчиками, либо что-то не так с…

P.S.
Третий секрет. Начните писать в commit'ах пользовательскую ценность добавленного кода. Не «добавил два метода», а «Теперь пользователю быстрее/легче/меньше...» или «появилась функция / изменилась реакция». Вам нечего написать? Вы ничего не сделали за день.
Метки:
Поделиться публикацией
Похожие публикации
Комментарии 248
  • +39
    годы должны пройти для понимания этого.
  • +6
    Вдохновляет.
    • +5
      Недавно пришёл к мысли: многие начинающие программисты воспринимают программирование как творчество. А нужо воспринимать как инструмент. Вырезать с корнем свой перфекционизм и просто решать поставленную задачу.
      • +21
        Вы правы, но абсолютно везде нужно чувство меры.
        • +1
          Конечно. Добиваться цели, но без фанатизма. Не нужно бросаться в крайности и писать работающий абы-какой код, нужно и думать о подержке с масштабированием, но и что-то очень универсальное долго и упорно городить тоже не стоит. Просто я столкнулся уже с парой проектов, где в погоне за улучшением сроки превысили выносливость разработчиков и релиз так и не наступил.
          • +4
            Считаю что «опытность» разработчика заключается в умении чувствовать и соблюдать баланс между «работает» и масштабированием. Нормальный IT менеджер должен ещё уметь дать зелёнкам его(баланс) почувствовать. Собственно отсюда и проблема человека из первой исповеди — все ему толкуют «делай проще», а «что такое полюс и с чем его едят» (с) А. Милн. никто сказать не может.
            • 0
              Согласен, опытный программист тем и отличается, что сможет изящно написать короткую программу, которая делает то, что надо здесь и сейчас, так что при необходимости её можно будет и легко расширить.
        • +13
          А останется ли радость от работы после такого изменения?
          • +1
            А почему нет?
            «Я решил задачу — я молодец» все равно будет работать. Удовлетворение от решения проблемы то остается.
            • +8
              Вы любите свою работу только за то, что способны ее выполнить?
              • 0
                Я люблю свою работу за то что могу сделать, что создаю и да, то что могу решить вопрос. )
                Я не говорила будто считаю программирование лишенным творческого подхода, просто у меня для самовыражение есть хобби. )
                • +12
                  Искренне рад за Вас, а у меня сон нарушен, если в проекте, даже задеплоенном, имеются недостатки, которые я в состоянии исправить, опять же руководствуясь чувством меры.
                  • 0
                    Ооо, а ещё зудит во всем теле, когда пришлось идти на компромисс ради скорости.
                    А ещё вызывает нервный тик старый неотрефакторенный код, до которого не доходят руки.
                    А ещё…

                    Прекрасно вас понимаю.
                • +1
                  Дык комментарий выше имхо не об этом говорит. Человек любит эффективно решать поставленные задачи, а не процесс их решения ради самого процесса. И статья именно об этом!
                • +6
                  Лично я воспринимаю разработку в первую очередь — как творческую область. Решить проблему можно уймой способов, в том числе скучных и быстрых. Но от такого решения и радости меньше. А вот решить красиво, это уже надо уметь.
                  • +3
                    Понимаете «красиво» для всех по разному. Каждый вкладывает свой смысл, но значение по сути не меняется. Я тоже люблю красиво решать вопрос.
                    Мне нравится делать что-то хорошо сразу, но всегда в будущем (или даже сейчас) найдется другое решение лучшее и красивее. И если находится этот способ я перепишу код и буду довольна, но выше уже было сказано о чувстве меры. Ибо код можно править бесконечно. У меня нет той степени перфекционизма о которой говорят сейчас в комментариях) Но я понимаю о чем речь и чувства. Перфекицонизм во мне просыпается в хобби, где никогда и ничто не будет достаточно хорошо, красиво или идеально.
                    Здесь вообще нельзя спорить, вмешиваются разные взгляды, вкусы, предпочтения, условия.

                    • +5
                      Мне вот непонятно, почему во всей статье и многих комментариях перфекционизм воспринимается как что-то непригодное для коммерческой разработки… До определённого уровня он не только пригоден, но ещё и полезен!
                      Ну вот простой пример:
                      — пришёл заказчик и говорит хотим такую-то фичу (сохранять некоторые параметры в куки и встраивать эти параметры в ифрейм) — ок, пользуемся уже существующим инструментарием + досыпаем чуть-чуть программной логики — первый вариант перфекционизма (не добавлять лишней сущности).
                      — приходит заказчик снова, говорит, нужна определённая бизнес-логика и вообще есть несколько разных списков параметров, за раз должен применяться один. Ок, оцениваем — дополнять старый функционал будет костылищем, вырезаем старый код, делаем аккуратный отдельный модуль-фильтр, прописываем обратную совместимость (чтобы после релиза ничего не сломать). Опять перфекционизм — поддерживаемость + наглядность + изоляция отдельного кода.

                      PS да — заказчик уже несколько раз приходил с изменениями в реализуемой бизнес-логике и вовремя выполненный рефакторинг на втором раунде серьёзно сэкономил сил, нервов и времени.
                      • 0
                        Наверное потому что все представляют себе более запущенный вариант, чем в вашем примере. ))

                        • +1
                          Ну… в работе я ещё не встречал запущенных случаев перфекционизма (не университет всё же таки).
                        • +1
                          Это не перфекционизм, а опыт :))
                  • +5
                    Спорный вопрос, потому что каждому — своё.

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

                    А вот сам код — он инструмент. Инструмент упрощения, улучшения жизни. Мне доставляет удовольствие сам процесс написания кода (иначе бы процесс программирования был бы пыткой), но он, блин, не самоцель. По этой же причине я люблю рефакторинг, который уменьшит количества кода или упростит его поддержку, но люто не люблю рефакторинг с предпосылками «это некрасиво», «это не по фэншую/не по канонам» и.т.п.
                    • +3
                      я люблю рефакторинг, который уменьшит количества кода или упростит его поддержку, но люто не люблю рефакторинг с предпосылками «это некрасиво»

                      Красивый код — это и есть простой код, в котором нет ничего лишнего.
                      • 0
                        Встаёт вопрос — считать ли «лишним» «задел на будущее»?
                        • +1
                          Я для себя выработал какую-то такую стратегию: если я точно знаю, что это в будущем понадобится, то оставляю определенный запас. Если же: «ну, может быть, по идее пригодится», то делать максимально адаптированно под текущую ситуацию. Бизнес-требования меняются очень быстро и с большим разбросом, поэтому тратить лишнее время сейчас смысла нет.

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

                          Так что, красота кода в отрыве от контекста не значит, на мой взгляд, ничего. А даже в контексте, если убрать случаи явного говнокода, всё это очень субъективно.
                          • 0
                            нет, пока он не содержит кода.
                    • +25
                      А зачем только программированием ограничиваться? Давайте считать, что вообще ни в какой профессии нет места творчеству. Вам хочется писать офигенную музыку? А ну быстро вырезайте с корнем свой перфекционизм! Народу нужна качественная и понятная попсятина, а не ваши потуги на самовыражение!
                      • +35
                        Если у вас контракт на такую музыка, садитесь и пишите. Если это творчество для себя, то можете самовыражаться с перфекционизмом.
                      • +2
                        Ну зачем же перегибать палку. Если музыка нужна для зароботка — пишите попсу. Если для души и узкого круга ллюбителей — пишите своё. В кино сейчас всё точно так и обстоит. Вон, Zach Braff снимает художественные произведения, а кто-то клепает тех же трансформеров зарабатывает неплохие деньги. Всё зависит от цели.
                        • +7
                          Я считаю, что призыв выкорчевать с корнем свой перфекционизм — это и есть «перегибать палку». В процессе эволюции у человека не просто так появилось чувство прекрасного. Красота и эффективность всегда связаны друг с другом. В комментариях ниже уже рассказывают о проблемах, возникающих, когда всё делают по принципу «лишь бы как-то работало».
                          • 0
                            В процессе эволюции у человека не просто так появилось чувство прекрасного.
                            Красивая теория, а мне кажется, что эволюция выработала чувство неудовлетворенности текущим положением. И потому если не унять своего перфекциониста — никогда не сможешь чувствовать себя хорошо здесь и сейчас, т.к. все время придется бежать к лучшему.

                            Лучшее — враг хорошего (с) М. Джиованни
                          • +2
                            А почему нельзя для зароботка писать хорошую музыку? Тот же вопрос и про кино.
                            • 0
                              Почему же нельзя, можно. Но зачастую не получается.
                              • +1
                                Я бы сказал что дело не в «не получается», а в «нет желания».
                                • 0
                                  Я бы сформулировал как «недостаток упорства», а не желания… Для видео — есть Youtube, и там некоторые реально зарабатывают. С музыкой — тоже наверняка тоже есть. Даже просто играя в компьютерные игры можно заработать — тот же Youtube, или же Twitch…
                                  • +2
                                    Дело не в «нет желания», а в «нет спроса». Нет спроса — нет денег (заработка). Не верите? Посмотрите, где в чартах хорошие инструментальные группы, и где «тынца-шмынца-муси-пуси».
                                    • 0
                                      Вершина чартов — однодневки, которых раздули талантливые продюсеры и (если речь идет о музыке) отличные звукорежиссеры.

                                      В творчестве «хороших» (читай — истинно талантливых) исполнителей главная ценность — преданность аудитории. Если какая-нибудь «Птичка-Певичка» завтра пропадет и перестанет петь, то о ней через неделю никто даже не вспомнит. И то, что вчера ее крутили по всем радиостанциям (кроме «Серебряного Дождя»), ей никак не поможет. А вот предствьте себе, сколько должно пройти лет, чтобы забыли Кортнева, Макаревича, Шевчука.

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

                                  Это напрямую следует как из того уровня формализации (как процесса, так и целей), который на данный момент принят в этой области. Так и из того уровня решений, которые вынуждены самостоятельно принимать даже «начинающие программисты».
                                • +31
                                  С другой стороны, программист А написал код, оформив его в виде библиотеки. Программист А из другой альтернативной реальности (назовем его условно программистом В) такого делать не стал — тиснул всю бороду в контроллер, абы быстрее сдать. Со временем команда расширилась, и схожий функционал потребовался в другом месте. Программист С взял библиотеку, быстро прочитал комментарии к функциям и реализовал то, что ему требовалось, особенно не вникая в тонкости реализации библиотеки. В альтернативной реальности программист С тупо скопировал код, где-то подправил и закоммитил так.

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

                                  Я пишу очевидные вещи, которые есть в большинстве книг. Но вот буквально в данный момент я сижу и смотрю в дубликаты кода. Вынужден шарахаться по проекту, который писали люди, привыкшие «экономить на карандашах и скрепках» в поисках мест, где же еще может встретиться данный баг… Разве это не отнимает время? Лично я бы лучше потратил это время на то, чтобы «навести красоту», чем на чтение и разбор говнокода.

                                  Почему, собственно, возраст и номинальный опыт воспринимаются нами как признак авторитетности мнения? Не бывает, разве, такого, что с возрастом и ростом авторитета человек начинает относиться менее критично к своему мнению? Разве эти опытные советчики не могли отстать от тенденций?
                                  • +25
                                    Угу, а потом начинается, проект А использующий либу хочет доп функционал, она появился в новой версии апи стороннего сервера, надо обновить апи, следовательно при обновлении либы провести регресс тесты всех работающих проектов. А потом выяснится что в старом апи был депрекейтед метод который как раз юзается в проекте В. Много раз такое видел. И по хорошему получается что либа уже поддерживает разные версии апи, настраивается снаружи и превратилась в маленького монстрика. Так что не везде в данный момент совпадающий код является общим.
                                    • +1
                                      Все имеет свои плюсы и свои минусы. Большая часть проблем, которые вы перечислили, либо полностью либо частично нивелируются соответствующими шаблонами проектирования ООП (ну… если его юзают). Нельзя полностью избавиться от проблем, но можно быть готовым к некоторым из них, если потратить чуточку времени и подумать.

                                      Простой пример — авторизация с помощью OAuth. Более-менее разумные решения прекрасно преодолевают перечисленные вами проблемы — разные версии протоколов плюс «собственный взгляд» некоторых сервисов.

                                      Хотя иногда… в очень редких случаях… почти никогда, но все же можно не париться и заговнокодить быстро. Но тут надо быть полностью уверенным: что оно не будет раздуваться и оно маленькое. Как только оно начало расти, его надо на корню переписывать и сразу делать правильно. Часы, сэкономленные в этот момент, могут обернуться неделями впоследствии.
                                      • +2
                                        Я из своей практики вижу, что почти никогда нет возможности сказать заранее: оно маленькое или оно будет расти.

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

                                        И вот тут — как раз важен опыт: нужно осознать что да, «пора уже это выкинуть и переписать» до того, как этот компонент разрастётся настолько, что переписывание станет невозможным.
                                        • +1
                                          Если приложение кому-то нужно, то оно развивается =)
                                          • +1
                                            Я разделяю говнокод… один раз видел такое место в коде от 2001 года, где чтобы посчитать количество комментариев, делалась выборка в массив, а потом считался sizeof от него… вместо того, чтобы сделать COUNT(*) по целевой выборке. Это — говнокод. Грубое нарушение индентации и стандартов кодирования — тоже говнокод. Если человек мыслит стройно, то у него и код должно быть удобно читать. А есть еще плохо организованный код: дублированный или написанный без возможности использовать его повторно — это тоже говнокод. И если в первых двух случаях все решается довольно легко и нетрудозатратно (относительно), если код организован правильно, то в последнем случае, чтобы исправить ситуацию, придется сильно попотеть. Здесь я согласен — самый страшный говнокод — это плохо организованный код.

                                            По поводу размеров приложения. Положим, какому-то отделу потребовалось «забирать» что-то по апи. Вы договорились… ну что там — пара методов всего, запилили по-быстренькому, без фреймворков и прочего. И оно живет. Но когда этому отделу идея понравилась и приходит требование сильно расширить возможности этого приложеньица — в этот момент нужно сразу брать тайм-аут на приведение приложения к нормальному виду (фреймворк, тесты, непрерывная интеграция и т.д.)… вот, о чем я. То есть, если вокруг приложения возникла активность — в этот момент нужно принимать волевое решение и закладывать нормальный ресурс на разработку. Вот, о чем я.
                                            • 0
                                              Интересный посыл про удобство. Мне удобно писать и читать длинные строки, а кто-то каждый поганый SQL запрос SELECT-FROM-WHERE на три строки разбивает потому что у него парсер слабый. А мне наоборот неудобно в голове строки собирать — мне нравится на весь поток смотреть, а не на его куски.

                                              Но это всё вопросы стиля кодирования, конечно, а не качества собственно кода.
                                            • +1
                                              Чтобы его выкинуть, надо сначала понять как он работает, чтобы не задеть поведение использующих его частей, в которых уже возможно тоже заковнокожены костыли, ожидающие костыльного поведения. Понять говнокод — половина беда. Понять его правильно со всеми нюансами костылей, когда git log выглядит как череда из коммитов с локоничным сообщением «fix» или «fix of a last fix» — вообще невозможно. А если при этом «опытные разработчики» еще и на тесты забили, потому что «нет времени, надо пилить фичи», то даже пытаться практически бесполезно.
                                        • +23
                                          Соль в том, что обычно разбор говнокода предстоит не тому, кто поленился навести красоту.
                                          • +4
                                            Тут скорее просто стремление к техническому совершенству должно быть коммерчески обосновано. Если у участников есть понимание, что совершенство кода позволит в будущем заработать больше денег (создать более сложный проект и т.п.) — то конечно можно совершенствовать код до бесконечности. Но иногда дешевле просто выкинуть полностью код 8-ли летней давности и написать новый (возможно даже на какой-то новой платформе).
                                            • 0
                                              Пример из реальной жизни — когда я пришел в одну компанию, у них были реализованы порядка 20 совместно работающих сайтов на общих библиотеках и темплейтах (classic asp еще). Казалось бы — все это хорошо и здорово! А потом оказалось, что чуть ли не в каждом из этих сайтов версии этих библиотек разные. И простое обновление до последней — запросто роняло сайт. И это был мини-филиал ада — пытаться что-то править там — так как правка одной из библиотек тянула за собой необходимость проверять, не ломают ли эти правки что-то еще во всех остальных сайтах, где она используется. Так что выносить в библиотеки код, хоть и обычно правильно, но надо делать это надо осмотрительно.
                                              • 0
                                                Так все надо делать осмотрительно. Не зря ж придумали Semantic Versioning.
                                              • +1
                                                Этот подход обычно не работает, потому что когда программист С берет библиотеку, он обнаруживает, что она делает примерно то, что надо, но не совсем. Вопрос, как расширить функционал? Есть известные принципы для расширения функционала, но их можно применить только тогда, когда исходная библиотека предполагает именно такое расширение. Т.е. программист А должен был заранее предусмотреть не только требования к своему проекту, но и требования, которые в будущем возникнут у программиста С. А также у всех остальных программистов D, E, F, для которых и пишется эта библиотека. На практике это хорошо работает только для малого числа функций, которые очень далеки от прикладных задач.

                                                Что за «прикладные задачи»? Это я вспомнил книгу «Мифический человеко-месяц». Там упоминалось, что задачи можно разделить на «прикладные» и «системные». Если с «системными» все более-менее хорошо и однозначно, то в «прикладных» все очень зыбко и подвержено изменениям, в результате стоимость работ по «прикладным» задачам оказывается в разы выше.
                                              • +4
                                                Может быть совершенный код и получается тогда, когда идет постоянное противоборство программиста перфекциониста, который все хочет сделать хорошо, а значит долго, и менеджера, которому главное решить быстро задачу и получить профит. В споре рождается истина.
                                                • +15
                                                  Не является ли такой подход тормозом в профессиональном развитии? Если я, условно говоря, умею клепать сайты по шаблонам, 100% времени занят этим, плюс подгоняю все задачи под моё эффективое умение клепать. Велика вероятность, что я так и останусь на этом уровне, и через пару лет мои навыки и понимание коммерческих следствий своих решений будут стоить дешевле чем грязь.
                                                  • –2
                                                    Имхо, перфекционизм и тяга к прекрасному строго обязательны в школьные и университетские годы, когда человек программирует для себя.

                                                    Более того, они обязательны в начале карьеры, если приходится работать в левой непрофильной конторе с маленькой зарплатой. Многих такие условия демотивируют, однако это отличный шанс как следует освоить новые направления и выработать стиль без особой ответственности за сорванные сроки.
                                                  • +12
                                                    Еще в школе на факультете по программированию до нас, детей, пытались донести мысль: «Профессиональное программирование не является искусством, оно — ремесло. Профессиональные программисты создают продукты на продажу. Только программирование как хобби может быть искусством.»

                                                    Понимание этого пришло только с годами. Да и то не полностью еще.
                                                    • +4
                                                      Поэтому программирование как хобби необходимо для того, чтоб писать хорошие программы не продажу.
                                                      • +2
                                                        Именно поэтому существует opensource
                                                      • +3
                                                        И тем не менее программирование является исскуством. Многие из картин висящих сейчас в музеях тоже писались по заказу и на продажу. И почему хобби не может совпадать с работой?
                                                        А вообще, программирование как ремесло — это давняя мечта всех менеджеров, подразумевается что средний человек после стандартного курса обучения должен быть способен выпускать с заданной скоростью стандартные модули, из которых можно комбинировать различные стандартные программы. Так ведь не получается же! Компании которые наиболее последовательно шли по этому пути сейчас тратят до 60% ресурсов на исправление первичных и вторичных багов.
                                                        Статья-то абсолютно правильная, только написана она умеренным перфекционистом для вразумления крайних перфекционистов и перфекционистами же в основном обсуждается. Неужели никто никогда не сталкивался с кодом, написанным изначально ремеслинниками и ими же поддерживаемыми?
                                                        В обшем, основная мысль — должен быть баланс, крайности ведут в адь.
                                                        • –1
                                                          Ваше сравнение с картинами — это, к сожалению, признак вашего невежества и непонимания, что такое искусство, и чем оно отличается от ремесла.

                                                          Дело в том, что картины на заказ писались не по техническим заданиям. Они полностью строились по желанию автора. Заказчик не мог сказать «вот тут мне не нравится перо на шляпе, переделайте» и уж тем более «поиграйтесь с цветом».

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

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

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

                                                            Не думайте о системе «на вырост». Другие требования — другая система. Не пытаться строить в деревне небоскреб — это и есть архитектура

                                                            Серьёзно? А где вы берёте время на переписывание продукта с нуля? Особенно, если требования к нему растут взрывообразно?
                                                            • 0
                                                              Никогда не угадаешь, какие появятся требования и какой проект неожиданно загнётся.
                                                              Стоит выбирать, жить в сегодняшнем дне или в гипотетическом завтрашнем.
                                                              • +5
                                                                Вполне себе угадаешь и требования и сколько жить будет.
                                                                Не все тут сайтики пишут после школы. Есть и длительные проекты, которые не умрут ни при каких обстоятельствах. И планы на них есть, и опыт который подсказывает что и как может поменяться и где соломку подстелить.
                                                              • +5
                                                                Чтобы понадобилась поддержка нужно, для начала, чтобы продукт вообще появился и «взлетел».
                                                                Вспоминается «пример про Петю и Васю»
                                                                Вася и Петя одновременно начали писать один и тот же продукт.
                                                                Вася был «ориентирован на результат» и начал сразу писать говнокод не продумав толком архитектуру.
                                                                А Петя месяц разрабатывал архитектуру, месяц делал удобный интуитивный интерфейс, которому позавидывал бы Джони Айв, потом месяц писал тесты, потом два месяца писал сам код и получил идеальное стабильное приложение.
                                                                Но Вася выпустил уже через месяц первую версию программы, пусть и не идеальную, пусть с багами, но рабочую, и начал её продавать. Ещё через месяц выпустил вторую версию исправляющие баги первой и добавляющие новые баги. Ещё через месяц на доходы от продаж нанял двух толковых программеров, которые за два месяца перелопатили весь код, согласно пожеланиям пользователей допилили интерфейс и выпустили третью версию программы.
                                                                Итого, через пять месяцев у Васи было два работника, куча клиентов и сносно работающее приложение отвечающее желаниям клиентов.
                                                                У Пети было вылизанное никому не известное приложение, минус на банковском счёте и ни одного клиента.
                                                                В завершение этого выдуманного примера можно сказать, что через полгода Вася купил все наработки Пети, Петю взял в штат тестировщиком, а сам по пьяни разбился на своём новеньком Туареге.
                                                                © Goodkat
                                                                Если же будущее продукта гарантировано, то да, стоит думать и о нём.
                                                                • +1
                                                                  «Появился и взлетел» — это про стартапы. У меня, например, всегда есть конкретный заказчик с конкретными потребностями. Всегда проводится анализ требований и составляется ТЗ, по которому сразу понятно на чём ваять, за сколько денег и в какие сроки. Всё это фиксируется в договоре\приказе и начинается работа до дедлайна. С систематически не укладывающимся в дедлайн программистом я просто прощаюсь. Программист, работающий быстрее и качественнее других, наоборот поощряется. Всё просто.
                                                                • +2
                                                                  Как всегда, вопрос баланса. Иногда, если не сделать проще и быстрее, то вопрос поддержки уже не встает, встает вопрос поиска работы. Так что зависит от ситуации, как бы КО это не звучало.
                                                                • +7
                                                                  1. Чувство меры обычно приходит с опытом.

                                                                  2. Опыт появляется гораздо быстрее, если код регулярно подвергается code review и конструктивной критике со стороны более опытных программистов.
                                                                  Я лично много для себя понял и многому научился в процессе код ревью. Причем слышал и приведенные в статье замечания.

                                                                  3. Вместе с тем, у меня лично при программировании временами есть чувство творчества и красоты созданного кода. И такие моменты лично для меня очень ценны в моей работе и жизни.
                                                                  • +1
                                                                    я лично использую закон Парето для разумной борьбы с перфекционизмом.
                                                                    • +5
                                                                      >Не думайте о системе «на вырост». Другие требования — другая система. Не пытаться строить в деревне небоскреб — это и есть архитектура

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

                                                                      Довольно сложно объяснить Заказчику, что для того, чтобы добавить в систему «Вот эту маленькую хреновину», Вам нужно писать Систему с нуля, потому что с изначально неверной архитектурой Системы, весь запас костылей уже был исчерпан ранее…
                                                                    • +17
                                                                      С башорга:
                                                                      С Хабра:
                                                                      Senecarus: Я раньше тоже был перфекционистом, когда программировал. Став руководителем, ответственным за успех, а следовательно за деньги, я стал молиться на говнокодеров.
                                                                      • +33
                                                                        С Хабра:
                                                                        С башорга:
                                                                        С Хабра:
                                                                        Senecarus: Я раньше тоже был перфекционистом, когда программировал. Став руководителем, ответственным за успех, а следовательно за деньги, я стал молиться на говнокодеров.
                                                                        • +8
                                                                          Ждём на баше.
                                                                        • 0
                                                                          Ну так да: теперь в распоряжении есть живые «поставщики кода», то функцию «делания кода» можно оставить им, а самому состедоточиться на «делании качества», рефакторя и вылизывая их говнокод.

                                                                          P.S. Пруф цитаты.
                                                                        • +5
                                                                          Чего-то все цепляются к фразе «Не думайте о системе «на вырост». Другие требования — другая система. Не пытаться строить в деревне небоскреб — это и есть архитектура».
                                                                          В каждом конкретном случае предполагается, что есть кто-то главный с мозгами, который в общем понимает, что можно быстро заговнокодить, а что сразу надо написать нормально. Речь в статье не о методологии разработки программного обеспечения.

                                                                          Статья-то про другое.
                                                                          Статью рекомендуется дать к прочтению программистам, которые считатают «не технарей» быдлом и говном. Менеджеры нихрена не делают же. А когда просишь программиста лично пообщаться с заказчиком и объяснить, почему из-за распиздяйства этого программиста проект лежал 6 часов, то тут как тут нужен менеджер. Еще можно статью дать почитать восторженным молодым специалистам, которые хотят нахуячить 18 рядов абстрактных классов и интерфейсов, потому что «в будущем может понадобиться».

                                                                          В целом, статья о том, что программист сам по себе без менеджеров, бухгалтеров, продажников и прочих членов большой команды нахрен никому не нужен. Статья именно про работников контор, а не про фрилансеров и прочих, способных данные проблемы решать самостоятельно.
                                                                          • +3
                                                                            Еще можно статью дать почитать восторженным молодым специалистам, которые хотят нахуячить 18 рядов абстрактных классов и интерфейсов, потому что «в будущем может понадобиться».


                                                                            У нас таких называют архитектурными астрономами.
                                                                            • +6
                                                                              Это искаженное «Архитектурные астронавты» Джоэла Спольски?
                                                                              • 0
                                                                                Слишком много времени прошло, чтобы точно вспомнить, но, вероятно, это вот из этого комментария

                                                                                Для меня «дзен» ООП — это умение написать с его помощью такую архитектуру классов, которую не придется рефакторить до основания после очередной смены требований. И тут пригодится не сколько умелое применение паттернов, сколько интуиция по поводу того, что реально в будущем может потребовать изменений. И не впасть при этом в over-engineering и не стать архитектурным астрономом.
                                                                                • 0
                                                                                  Хороший абзац. Утащил к себе в копилку, спасибо =)
                                                                            • –1
                                                                              Менеджеры нихрена не делают же.

                                                                              Если программисту хоть раз пришлось самому общаться с заказчиком — так и есть, менеджер нихрена не делает и он — быдло и говно. А если он при этом смеет как-то ещё вякать на программиста по поводу сроков и стоимости, то его не просто уволить нужно, а набить ещё при этом лицо.
                                                                              • 0
                                                                                Не-не-не. Имеется в виду менеджер, который уже затрахался разгребать за программистом, огребать от заказчика и программист, который багует, считая что «ошибки — обязательный элемент творения». При этом реакция на уже громкое негодование менеджера (не в первый раз негодует) идет не в стиле «О, черт, мой косяк, простите, максимально быстро исправлю», а с позиции «Не рассказывай мне про мои ошибки, ничтожество, ибо аз есмь творец, а ты быдло в белом воротнике».

                                                                                Ну и попытки рассказать не технарям, что вообще-то это сложно написать такой функционал без ошибок, бла-бла. За это просто убивать хочется. Человек искренне уверен в крайней сложности своей работы, и никчемности чужой работы, забывая, что всякая работа по-своему сложна.

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

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

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

                                                                                  А админы жалуются и на тех, и на других. И вообще они нытики :)
                                                                                  • +2
                                                                                    Вот из вашей истории я вижу такой сценарий:
                                                                                    М(Менеджер): Нам нужно реализовать фичу1, фичу2, фичу3 и фичу4
                                                                                    П(Программист): Хм… ну тут только месяц реализовывать. Потом еще месяца 2 тестировать, отлаживать.
                                                                                    М: Мы бы хотели в конце месяца релиз.
                                                                                    П: Но до конца месяца же 3 недели всего.
                                                                                    М: Ну фичу4 впринципе можно не делать

                                                                                    Через месяц:
                                                                                    М: У тебя опять баги во всех фичах
                                                                                    П: Ну нельзя столько функционала написать за 3 недели и без ошибок.
                                                                                    М: Так ты же итак не делал фичу4. Можно было исправить ошибки за это время. Нам в новом релизе надо запилить фичу5, фичу6, фичу7, а мы не можем это делать, потому что у нас нет фичи1, фичи2, фичи3, они все с багами и нам надо править баги.

                                                                                    А еще бывает такое, что менеджер приходит, и говорит, надо реализовать такую и такую фичу. Ты смотришь на эту фичу, и понимаешь, что она дико не логична, пользоваться ей — это все равно что есть кактус. А чтобы реализовать эту фичу — нужно впихнуть букет костылей. Ты пытаешься объяснить, чем фича плоха, и что это вообще бред сивой кобылы, а не фича. Но менеджер вынашивал эту фичу 3 недели, и он думает примерно так:
                                                                                    Этот аз есмь программист вообще оборзел. Никакого уважения к человеческому труду, одно завышенное самомнение.
                                                                                    • 0
                                                                                      А бывает когда-нибудь (хотя бы раз в два года), что виноват программист?
                                                                                    • +1
                                                                                      В примере с программистом и менеджером опять скатываемся к плохо организованному процессу разработки, когда программист остается за все крайним, а менеджер-самодур может менять условия задачи, сроки и состав задач в зависимости от расположения Марса по отношению к Юпитеру. Это отвратный сценарий, хоть и частый. Я все-таки рассматриваю условно нормальных людей в условно нормальной рабочей обстановке.
                                                                                      Я вообще привык к хорошему и все рассуждения веду с такой точки зрения: менеджер не может просто так взять и что-то сказать, для этого есть продукт-овнер, а если они оба (менеджер и ПО) городят херню, то можно пойти к непосредственному начальству и челом бить. И тогда тебе объяснят, что вообще-то «херня» имеет далеко идущие планы и все грабли, о которых ты говоришь, учтены. А может и нет, может ты расскажешь про грабли, о которых никто не подумал и «херню» отменят или перепланируют с учетом твоих корректив. Я привык к адекватной обстановке в конторе, когда учитывается только голос разума, а не позиция говорящего в иерархической структуре компании.

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

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

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

                                                                                      Короче. Надо быть человеком и думать головой. Даже на работе =)
                                                                                      • 0
                                                                                        И вот на ниве повышенного IQ и осознания, что можешь что-то, чего другие не могут, махать своим ЧСВ — вот это фу. А этим ну вот прям многие грешат.

                                                                                        Повышенный IQ помимо способности что-то сделать должен ещё по идее дать способность понять, что махать ЧСВ плохо. Другими словами, если кто-то машет ЧСВ, вполне вероятно, что IQ на самом деле у него никакой не повышенный. Умный человек — умный, а не умеющий решать задачки.

                                                                                        А вот к маханию ЧСВ часто приводит именно начальственное положение на фоне отсутствия нормального IQ. Как этот сопляк посмел спорить! Он что, думает, что умней меня? Я его урою! И это как раз и приводит к историям про мудаков-менеджеров и программистов-страдальцев. Здесь уходит умный (сам). В обратной ситуации (дурак-подчинённый, умный начальник) дурака обычно увольняют.
                                                                              • +2
                                                                                Доска с маркером + телефон с камерой отлично заменяют UML-диаграммы и большую программ прототипирования интерфейсов


                                                                                Oh yeah, baby…
                                                                                • +1
                                                                                  А как потом вывести фотографию обратно на доску для доработки? Есть какие-нибудь графопостроители для этого, или только вручную?
                                                                                  Доску-то к проекту не приложишь, а в файле маркером не порисуешь. (Двухметровые сенсорные экраны в расчёт не беру)
                                                                                  • +1
                                                                                    Наверное, имеется в виду, что исправления нарисованной схемы навряд ли потребуются, а если и потребуются, то не так долго перерисовать.
                                                                                    • +2
                                                                                      Тереь я понял, статья про разработку приложения Yo! Все встало на свои места! =)
                                                                                • +6
                                                                                  Баланс важен везде. Суть, пожалуй, именно в балансе. Перегибы в любую сторону, в любом вопросе — зло. Как архитектура ради архитектуры, так и говнокод ради зашибания бабла здесь и сейчас. Грабли с обеих сторон узкой дорожки.
                                                                                  • +2
                                                                                    Вообще, по поводу фразы о «системе на вырост». Мне кажется, тут нужно разделить два случая:
                                                                                    1) В задаче ясно говорится (или умалчивается), что для данного продукта будет определённое максимальное количество пользователей, и возможное превышение его в ближайшее время очень маловероятно;
                                                                                    2) В требованиях указано, что система должна быть сделана горизонтально расширяемой с возможностью, например, добавить в случае чего новый сервер.

                                                                                    В первом случае «система на вырост» не нужна, во втором же — строго обязательна.

                                                                                    P.S. Я вполне не против «строить в деревне небоскрёб», если это будет соответственно профинансировано Заказчиком (и очень желательно — иметь в себе некоторые сложности, для саморазвития).
                                                                                    • +9
                                                                                      Третий секрет. Начните писать к commit'ах пользовательскую ценность добавленного кода. Не «добавил два метода», а «Теперь пользователю быстрее/легче/меньше...» или «появилась функция / изменилась реакция». Вам нечего написать? Вы ничего не сделали за день.

                                                                                      Вот именно такая логика часто и приводит к тому, что наступает ситуация, при которой переписать дешевле и проще, чем развивать.

                                                                                      Все перечисленные в статье аргументы абсолютно справедливы… но только для краткосрочных проектов. А в долгоиграющих есть такое понятие, как рефакторинг. И как показывает мой скромный опыт, если в проекте руководитель пренебрегает необходимостью этой «гигиенической» процедуры, то сепсис и гангрена всего проекта неизбежны.

                                                                                      Насколько мне известно, примерно 30% действий, совершаемых разработчиками над кодом, не имеют ни малейшего отношения к пользовательской функциональности. Причем если на фазе «зализывания багов» эта цифра может опуститься до 5-10% (и модель, описываемая в статье почти работает), то на фазе начала нового проекта, когда большая часть работы связана даже не столько с архитектурным проектированием, сколько с изучением инструментария и предметной области, написать, какой профит тут получил пользователь нельзя.
                                                                                      • +2
                                                                                        Погодите, статья как раз и предлагает писать упрощенный код. Если не угадали с упрощением — всегда можно сделать рефакторинг. Скажем, после нескольких месяцев разработки выяснилось, что часть функций действительно дублируются в 2 местах. Вот тогда и стоит делать рефакторинг для выделения общей части. А если изначально писать обобщенную библиотеку, то велик шанс не угадать, как она будет использоваться в дальнейшем, и усилия пропадут даром.
                                                                                        • 0
                                                                                          Правильнее всего сделать так: когда потребуется написать второй дубль кода, выделить его в отдельную функцию для переиспользования. Для этого, правда, надо быть в курсе, что такой код уже есть, а для этого — знать, какой код уже есть. А новый разработчик может просто не знать, какой код уже есть, и напишет «велосипед», не подозревая о том.
                                                                                          • +1
                                                                                            … а вот для этого нужно строгое разделение функционала между модулями и сжатая, но информативная проектная документация, которую новый разработчик должен прочитать внимательно и получить представление о том, что код проекта уже умеет делать
                                                                                      • +2
                                                                                        всегда был против использования излишнего кода…
                                                                                        правильно подмечено: больше кода — больше ошибок.
                                                                                        • 0
                                                                                          Точно! Никогда не ошибается тот, кто ничего не делает.

                                                                                          Лозунг у них был такой: «Познание бесконечности требует бесконечного времени». С этим я не спорил, но они делали из этого неожиданный вывод: «А потому работай не работай — все едино».
                                                                                          А. и Б. Стругацкие. «Понедельник начинается в субботу»
                                                                                        • +14
                                                                                          Почему-то к каждой такой статье вижу здоровенные треды «куча абстракций» VS «весь код в контроллере». Статья-то не о том, что надо «фигак-фигак и в продакшен подешевле да побыстрее, а там разберемся, на крайняк перепишем с нуля». Статья о том, что абсолютно любая работа программиста должна быть экономически оправдана. Если ту же задачу можно решить дешевле, то ее надо решить дешевле, а не разводить сопли про всякие там высшие материи. Другой вопрос если программист реально видит риск дешевого решения и принимает _осознанное_ и _аргументированное_ решение усложнить вот этот вот кусочек архитектуры, потому что ожидаются такие-то требования — это ок, по-моему.
                                                                                          • 0
                                                                                            Задели прям за живое =) Сам недавно очень много размышлял на эту тему и пришел к абсолютно идентичными выводам и аргументации как в статье.
                                                                                            • +3
                                                                                              Вы и ваш двойник открыли бизнес по автоматизации чего-нибудь. Конкретно вы из вас двоих — директор.

                                                                                              Какая у вашего двойника часовая ставка? Возьмите калькулятор и поделите цифру, указанную в трудовом договоре на 160. Если вы совершаете эти действия в рабочее время, то поделите результат еще на 60. Вот на столько (+20% льготной ставки в ПФР + 0.2% за травматизм + 6% УСН (половину можно зачесть из налогов ПФР) = +23.2% минимум) вы нагрели своего работодателя, развлекаясь здесь со мной.
                                                                                              Я ничего не понял. :( Какого работодателя я нагрел, если вы сами назвали меня директором? И каким образом я кого-то нагрел на несколько копеек (часовая ставка / 9600)?
                                                                                              • +2
                                                                                                Тоже перечитал этот абзац три раза, но таки понял.
                                                                                                160 — количество рабочих часов в месяц. Чтобы узнать часовую ставку делим «цифру» (ну число же, блин!) из трудового договора на количество часов.

                                                                                                А следующее предложение уже о том, что если вы это считаете в рабочее время (следовательно, не работаете), то работодатель теряет на этом деньги. Полагается, что на расчёты ушла 1 минута, по-этому делим часовую ставку на 60.

                                                                                                А автора я бы всё таки попросил переписать этот абзац ;)
                                                                                              • +1
                                                                                                Было бы здорого если бы раз в две недели кто нибудь зачитывал этот отрезвляющий пост! Спасибо!!!
                                                                                                • +5
                                                                                                  программисты никому не нужны. И программы тоже. То есть совсем. Людям интересны они сами, их проблемы...
                                                                                                  Программы нужны программистам. Программисты тоже люди.
                                                                                                  • 0
                                                                                                    Я думаю, весьма редкое событие в жизни, когда один программист платит другому программисту деньги просто за «красивый код».
                                                                                                    Это обычно называется donate, и чаще всего мотивация немного другая.
                                                                                                    • +1
                                                                                                      > Я думаю, весьма редкое событие в жизни, когда один программист платит другому программисту деньги просто за «красивый код».

                                                                                                      Я же просто уверен, что имея более удобный интерфейс библиотеки (пусть это свойство будет частью собирательного «красивый код»)
                                                                                                      реализующий необходимый программисту функционал выбор будет очевидно в сторону…

                                                                                                      «Красота кода» это и есть внутренняя характеристика от программиста к программисту, так как красоту кода не видит пользователь.
                                                                                                      • 0
                                                                                                        А часто художники платят художникам «просто за красивую картину»?
                                                                                                        • 0
                                                                                                          «Почти художники» (визуальные дизайнеры) очень часто платят себе подобным за клипарты
                                                                                                        • 0
                                                                                                          Хочу заметить, что общая стоимость использованных в проекте библиотек часто значительно превышает стоимость экземпляра готового продукта для юзера. И, кстати, donate я бы тоже не исключал из экономики ибо он, слава богу, становится все популярнее.

                                                                                                          Поясню свою позицию. Я считаю, что именно open-source создает будущее индустрии не потому, что «проприетарщики» зажали свой код и требуют деньги, а потому, что код их ужасен (ибо написан согласно принципу «прибыль в первую очередь»)

                                                                                                          Зачастую код коммерческого решения настолько негибок и глючен, что поддерживающий его огромный штат программистов с трудом выдерживает конкуренцию с новым open-source-проектом, который делают на порядок меньше людей. Так, к примеру, на глазах у древних как мамонты 3DMax и Maya «вырос» Blender.
                                                                                                          • 0
                                                                                                            Я начинаю понимать, что смысл моего комментария немного был не понят. Я к тому, что не встречал еще людей, которые бы заплатили за «красоту» кода и не более. Как за красивое полотно. Не потому что код чистый, понятный, удобный и его легко интегрировать. А вот просто потому что мне понравилась программа. Красивая она. Т.е. это был ответ на то что «программисту нужна программа». Программисту не нужна программа как просто красивый набор букв и символов. Ему нужно удобное и легкое решение. Я вот вообще о чем!
                                                                                                            • 0
                                                                                                              Хорошо, а как вам пример соревнований «самый запутанный код на C»? Там даже операционные системы участвуют! :)
                                                                                                              • 0
                                                                                                                Хорошо, если и олимпиады припомнить с наградами, то Вы правы. Не хочу развивать длинную ветку из-за сгоряча написанного комментария :)
                                                                                                            • –1
                                                                                                              Я мечтаю, чтобы у каждого opensource была параллельная коммерческая лицензия. Платная лицензия позволяет предъявлять претензии.

                                                                                                              Сейчас же ситуация выглядит так:
                                                                                                              opensource: «Если что-то будет работать плохо или не будет работать совсем, я верну вам деньги.»
                                                                                                              я: «Но я же ничего не платил.»
                                                                                                              opensource: «Вот именно.»

                                                                                                              Немного спасают maintainer'ы, которые всего за 50$ (OpenSceneGraph) — 125$ (x264) в час согласны доработать свой код. К чести maintainer'ов, работа всегда выполнялась четко, в срок и полностью соответствовала ожиданиям.
                                                                                                              • +1
                                                                                                                У вас смешались в кучу кони люди: платный/бесплатный софт, опенсорс и возможность предъявить претензии.
                                                                                                                Опенсорс — это всего лишь открытый исходный код. Есть еще проприетарный софт. Но это не значит что опенсорс бесплатный, а проприетарный — платный. Полно бесплатного проприетарного софта.
                                                                                                                И если вы что-то заплатили за софт — это еще не значит что можно качать права. Ваши права определяются пользовательским соглашением, с которым вы согласились при установке софта.
                                                                                                          • +5
                                                                                                            > программисты никому не нужны. И программы тоже. То есть совсем.

                                                                                                            Разрешите процитировать мораль басни Крылова — «Свинья под дубом»:

                                                                                                            Невежда также в ослепленье
                                                                                                            Бранит науки и ученье,
                                                                                                            И все ученые труды,
                                                                                                            Не чувствуя, что он вкушает их плоды.


                                                                                                            Мне кажется это будет тут уместно.
                                                                                                            • 0
                                                                                                              Да это надо в эпиграф статьи!
                                                                                                          • 0
                                                                                                            > Правда думаете, что цикл на итераторах работает быстрее, чем на индексах

                                                                                                            А если стурктура данных — linked list? ;)
                                                                                                            • 0
                                                                                                              а если цикл по linked list то итератор однозначно быстрее ;)
                                                                                                              • 0
                                                                                                                >> Правда думаете, что цикл на итераторах работает быстрее, чем на индексах
                                                                                                                > А если стурктура данных — linked list? ;)

                                                                                                                Когда появляется неопределенность ее надо проверять.
                                                                                                                Создайте синтетический пример и убедитесь самостоятельно…
                                                                                                              • +2
                                                                                                                Для красоты и правильности есть свои проекты и опенсурс.
                                                                                                                • +1
                                                                                                                  Мне кажется что налицо старый, как мир, конфликт:
                                                                                                                  -желание делать любимое дело, со своими критериями красоты (творчество)
                                                                                                                  -выполнение работы по найму
                                                                                                                  Мне понравилась аналогия с музыкой, приведенная выше. Подобное разделение, в общем, есть в любом искусстве. Грубо — попса, созданная с целью делать деньги, и авангард (андеграунд, народные напевы и.т.д.) созданные ради себя самих.
                                                                                                                  Проблема в том, что программисты (в широком смысле слова — сотрудники, занятые в разработке ПО), в большинстве своем, очень любят свое дело. Поэтому стараются делать его наилучшим (с их точки зрения) образом. А с точки зрения руководителя/заказчика нужно чтоб работало ТОТЧАС. Стройные иерархии классов конечному пользователю не видны, и польза от проработки архитектуры «на будущее» — не очевидна.
                                                                                                                  Тем не менее, программисты вряд ли захотят делать «ширпотреб». Для себя я нашел любопытное решение — я занимаюсь разработкой дома для души. А на работе перешел из разработки в тестирование :)
                                                                                                                  • +7
                                                                                                                    К счастью реалии рынка не соответствуют этому (вне всякого сомнения разумному) мнению :)

                                                                                                                    А реальность такова, что мне мало интересны проблемы моего работодателя, точно как и ему мало интересны мои эстетические предпочтения в программировании. Просто так сложилось, что я люблю есть, а работодателю могут быть полезны мои навыки. Трудовой контракт это честная сделка только в том случае, если обе стороны признают, что их цели и интересы различны и готовы идти на компромиссы. Обе стороны.

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

                                                                                                                    Давайте же уважать друг друга и стремиться к разумным компромиссам ;)
                                                                                                                    • 0
                                                                                                                      Да, ситуация к нам благосклонна :) Однако подобный подход может «аукнуться» в периоды кризиса, или стать препятствием на пути к карьерному росту (хотя не всем оно и надо)
                                                                                                                      • 0
                                                                                                                        Всё так. Это прекрасно, что есть люди, которым нравится программировать. До тех пор, пока работа выполняется, вам никто не начнет рассказывать про «правильное отношение». Мало того, работодатель будет только рад найти программиста на 60 тыс., который всю жизнь будет прикрывать задачи на 60 тыс. Работодатель не планирует рост заплаты, развитие, продвижение по карьерной лестнице и т.д., и с удовольствием (и легким сожалением) с этих же 60 тыс. проводит программиста на пенсию. Дворник с 20-летним стажем всё равно будет получать зарплату дворника, как бы ловко он не управлялся с метлой.

                                                                                                                        Эта статья не для вашего начальника, а для вас. Потому что в один прекрасный момент понадобится человек, готовый взять на себя ответственность в весомом денежном эквиваленте, в условиях ограниченных ресурсов. И было бы очень здорово, если таким человеком оказались бы вы.
                                                                                                                        • 0
                                                                                                                          > И было бы очень здорово, если таким человеком оказались бы вы

                                                                                                                          За долю в компании такой вариант можно ещё рассмотреть. Всё, что меньше — банально не стоит новой головной боли. Так что уж лучше довольным дворником ;) Тем более, что за хороших дворников сейчас готовы платить намного больше 60 тысяч.
                                                                                                                      • +1
                                                                                                                        Жаль, что в статье не упомянут такой способ улучшения дизайна существующего кода, как рефакторинг. Заодно помогает относительно быстро научиться писать хорошо.
                                                                                                                        • +1
                                                                                                                          В статье описана не конкретная методология разработки, а один из руководящих принципов, основанных на ценности создаваемого, который, если его принять, может помочь воспитать в себе более хороший стиль программирования. Этот же принцип пригоден для любого производства. Качество проработки мелких деталей зависит от того, за сколько вы собираетесь продавать готовый продукт. Сравните резные деревянные детали на мебели разной ценовой категории.

                                                                                                                          Я не агитирую за т.н. «говнокод» и не говорю, что перфекционизм — это плохо. Я лишь говорю о том, что код должен соответствовать своей бизнес-ценности. У нас есть части, которые отполированы до блеска — это разные транспортные уровни. Потому что, если не будет работать передача данных, то ничего работать не будет. А есть части, которые намерено сделаны дешево. Скажем pdf-просмотрщик на pdf.js — тормозит, ест много памяти, но свою цель выполняет и написан за один вечер (левой ногой).
                                                                                                                          • +1
                                                                                                                            Я не агитирую за т.н. «говнокод» и не говорю, что перфекционизм — это плохо

                                                                                                                            Значит в статье вы сильно переусердствовали. Однозначно создаётся впечатления, что надо «фигак-фигак и в продакшен» и никакой перфекционизм не допустим.
                                                                                                                            • 0
                                                                                                                              Было бы замечательно, если бы это мнение Вы отразили в статье. А-то реально создается впечатление, что Вы весь код предлагаете писать быстро и некачественно.
                                                                                                                          • +1
                                                                                                                            Кину свои 0,5 копеек.
                                                                                                                            Приоритеты при разработке:
                                                                                                                            1. Должен быть результат, т.е. програма должна работать и выполнять свою работу — это главное. Всё остальное — лирика.
                                                                                                                            2. Результат должен быть эффективным, т.е. всё должно выполняться за приемлимое время и кушать приемлимое количество ресурсов, и т.д.
                                                                                                                            3. Результат должен быть стабилен, без косяков. Если результат нестабилен, но эффективно выполняет свою работу с некоторыми косяками, то это лучше, чем стабильный код съедающий все ресурсы либо выполняющийся год. Не относится к случаю из пункта 1.
                                                                                                                            4. Код результата должен быть оформлен по правилам KISS, YAGNI и DRY + правила вашей среды разработки.
                                                                                                                            5. Все остальные требования.
                                                                                                                            6. Profit.
                                                                                                                            • +9
                                                                                                                              Давайте будем честными. У директора и у программиста разные цели и мотивация. Программисту интересно «программировать», именно поэтому он этим занимается. А директору деньги зарабатывать, поэтому он директор. Конечно, хороший результат заключается в компромиссе, но пока программист занимается программированием, не пытайтесь свалить на него ответственность директора и поставить одного на место другого, пусть директор сам по этому поводу париться, ему за это платят, причем сильно больше, чем программисту. Как только программист будет получать деньги за то, что компания больше заработала, как это бывает, когда программист делает свой проект какой-то, так сразу появляется и мотивация на «сделать быстрее». А если не нравится, то конъюнктура рынка такова, что разработчика возьмет другой директор, более лояльный к личностным нюансам.
                                                                                                                              • 0
                                                                                                                                Тронуло черт возьми… На самом деле как будто в душу себе заглянул. Сам руковожу компанией разработчиков и за плечами приличный опыт работы рядовым программистом в разных компаниях (ну как я считаю по крайней мере). Поэтому проникся всеми ньюансами с обоих сторон. Спасибо огромное за статью!
                                                                                                                                • +13
                                                                                                                                  Одни компании выпускают по 50 продуктов в месяц, другие по пять, третьи по одному, а четвертые один продукт в 5 лет. А некоторые и один в 30 лет.
                                                                                                                                  Скажите, Вы хотите автопилоты в машины, которые писали бы говнокодеры с мыслью о том, как бы их менеджер быстрее заработал на этом денег? А беспилотное метро? А может школьники пусть софт на космические аппараты пишут? Как насчет телекомов с их инфраструктурой? А может разработку Half Life 3 каким пацанам с улицы отдадим?

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

                                                                                                                                  И пример этот реален. Откройте код движка id Tech и какой-нибудь «бизнес системы». Земля и небо.

                                                                                                                                  Тому парню из цитаты топика я бы посоветовал просто искать работу R&D, где нужны рассудительность, мозг, умение красиво и правильно решать проблемы, где результат твоего труда нужен не вчера, а понадобится послезавтра.

                                                                                                                                  • +6
                                                                                                                                    Исключения лишь подтверждают правила. Проблема в том, что 90% программистов любой говносайт воспринимают как программу для Боинга. И когда директор их пинает — они смотрят с высока и говорят — отстань — я тут творчеством занимаюсь.
                                                                                                                                    • +2
                                                                                                                                      Ну это косяк менеджера, а не программиста. Значит, ему нужны люди, которые будут на шаблоне быстро «фигак-фигак и в продакшн». Не надо тогда писать в резюме, что фирма ищет офигенного программиста с божественными знаниями языка (а то и нескольких), по совместительству хорошего архитектора, вот это все. Так и надо писать, что нужен кодер, который быстро и эффективно будет строчить то, что скажет менеджер/тимлид.