Проблема, которую вы решаете, важнее, чем код, который вы пишете

Автор оригинала: Fagner Brack
  • Перевод


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

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

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

Вот пример.

Был стартап, который создавал устройство позволяющее человеку открывать дверь своего дома по Bluetooth. В качестве визуального интерфейса использовался виджет, который был виден даже когда телефон был заблокирован. У него была единственная кнопка под названием «Открыть дверь».

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

Кто-то посмотрел на это и спросил:
Если мы используем Bluetooth и наша бизнес-модель пускает в дом любого, кто имеет телефон, почему мы должны заставлять кого-то брать телефон и нажимать на кнопку? Пусть дверь будет открываться при приближении устройства на 1 метр. Таким образом, нам не нужно платить за разработку и программирование визуального интерфейса!
Эта история с Bluetooth — отличный пример узкой направленности: цель состояла в том, чтобы открыть дверь с минимальными усилиями. Нет смысла разрабатывать визуальный интерфейс, если датчики беспроводные.

Если вы знаете, каких целей хочет достичь бизнес и что имеет ценность для пользователя, то вы можете объединить эти знания с вашими знаниями о технологиях. Только тогда вы будете располагать достаточной информации, чтобы придумать лучшие ответы, и сделать вывод, что для продукта интерфейс не нужен.

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

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

image

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

Существует разница между инкапсуляцией сложной логики и абстракцией полезных знаний. Иногда информация должна быть сделана понятной. Если вы абстрагируете их, они могут иметь противоположный эффект и их будет труднее понять.

Более полезно использовать некоторые типы команд низкого уровня в CLI, чем команду высокого уровня, которая абстрагирует знания, такие как Git.

Несколько лет назад я работал над проектом с использованием пошаговой доставки. Это была система проверки личности, которая требовала от пользователя предоставить некоторые личные данные для проверки сторонним поставщиком.

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

И вот почему: проверка была обязательной!

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

В худшем случае пользователи, которые не смогли проверить себя, могли позвонить в службу поддержки, чтобы проверить все вручную.
Не каждую функцию стоит программировать
Если вы разработчик и вы понимаете проблему, которую вы пытаетесь решить, вы сможете придумать более качественный код, а иногда и сможете справиться вовсе без кода. Вы не "Code Monkey", которому платят за написание символов на экране. Вы профессионал, которому платят за решение проблем.

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

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

Есть такая поговорка: «Если у вас есть только молоток, все выглядит как гвоздь».

Лучше сначала иметь гвоздь, чтобы вы смогли рассмотреть необходимость молотка.

То есть если вам нужен гвоздь в первую очередь.

Спасибо за прочитанную статью!

Если у меня есть ошибки в переводе, пожулуйста напишите об этом в комментариях!
А также зайдите на мой сайт, где появился быстрый доступ к вопросом и ответам по javascript — Вопросы и ответы по JavaScript

Буду очень вам благодарен и признателен)

Я в твиттере и вк

Спасибо большое за ваше внимание!
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 53

    +7

    … не каждый продукт следует разрабатывать. /закопали.

      –1
      извините, не понял
        +12

        Если не каждую функцию стоит программировать и не каждый баг фиксить, то и не каждый продукт стоит разрабатывать.


        Вот придумали PM'ы новый суперметод на аукционе продавать рекламу по приватным данным фейсбука.


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

      +4
      Так и рождаются странные вещи, которыми нельзя удалённо открыть дверь, а необходимо именно самому подойти. т.е. открыть кому то дверь не вскакивая каждый раз — будет тем ещё приключением )
        +2
        Да, решение очень странное. За дверью нужен чёткий контроль в плане открытия.
          +1
          плюс постоянные открывания двери когда просто проходишь мимо неё… решение не то что странное, а идиотское и вредное
            +1
            А если она не только отпирается, но и автоматически открывается…
              +1
              Всё становится веселее, если оставить телефон у входной двери ))
                0
                Ахах, а если телефон дома забыл?)))
                  0

                  А кто вас выпустит без телефона или если телефон сядет? ))

                    +1
                    Значит надо сделать станцию с зарядкой возле двери)))
              0

              Странные вещи рождаются от непроработки всех вариантов использования и "бездумной" реализации всех фич, которые где-то видел менеджер или разработчик. А если в процессе разработки есть фильтр на "странные/ненужные фичи" и отдел тестирования, странных вещей на выходе уже должно получаться меньше.
              Те же постоянные автоматические открывания/закрывания двери возможны, скорее всего, тогда, когда кому-то автоматическое открывание показалось отличной идеей, но он не подумал, что можно ходить не только сквозь дверь, но и рядом с дверью. Но этот вариант может быть лучше, чем постоянный виджет на экране блокировки смартфона (зачем он, когда пользователь далеко от двери?). Тут надо много думать, прежде чем делать (собственно, вся статья про это).

                +1
                Виджет нужен если вы хотите кого то впустить-выпустить.

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

                Насчёт думать и делать… это всё прекрасно, конечно, но, чаще всего просто фантазии.

                Для этого должны быть специальные люди (аналитики?) которые должны понимать пользователя, собирать данные и формулировать задания программистам и инженерам в таком виде, в котором они должны быть сделаны. Потому что требовать от программиста ещё и изучать предметную область, определять пользовательские пути и специфику их работы и мировоззрений — это требовать его выполнять не его обязанности, очевидно.

                Более того, когда «видиние» программиста входит в конфликт с тем, как это видит начальство или его же аналитик… не избежать беды. =)
                  0
                  Для этого должны быть специальные люди (аналитики?) которые должны понимать пользователя, собирать данные и формулировать задания программистам и инженерам в таком виде, в котором они должны быть сделаны.

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

                    0
                    ну так о том и речь.
                    Это функции разных ролей в команде.
                    И если они совмещаются в одном человеке, то это или очень маленькая команда, или что то пошло не так (руководство решило поэкономить).
                    0
                    Для этого должны быть специальные люди (аналитики?)

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

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

                    Frank Cottrell Boyce «Chitty Chitty Bang Bang Flies Again»
                    But that afternoon, as Mum trudged up the garden path after a hard day’s work at Unbeatable Motoring Bargains, a very refreshing thing happened. The front door opened all by itself, and a bright little voice said, “Do come in. The kettle is on.”

                    “What a lovely homecoming,” said Mum, strolling into the kitchen just as the kettle came to the boil.

                    “I installed an automatic self-opening on the front door,” explained Dad, “and hooked it up to the kettle.”

                    “My genius.” Mum smiled.
                    “The word today,” said Dad, “is welcome home.”

                    Там это было образцом идиотского изобретения. Дверь отрывалась, ставила чайник на плиту и приглашала заходить на чай. Закончилось тем, что кухня была забита десятками пробегающих мимо физкультурников, которые съели всё печенье и выпили весь чай.
                    +9
                    Это менеджерское мнение и оно в стратегическом смысле справедливое. То есть в перспективе, если программисты постоянно занимаются тем, что никому не нужно, то это повредит всем, в том числе, опосредованно и самим программистам.
                    А есть другое мнение. Есть программист, ему платят зп за 8 часов работы, он наемный работник и его судьба проекта (особенно большого) интересует не слишком сильно. Ему же интересно попробовать новые технологии, порешать сложные задачи (даже если не просят), прокачать скиллы для резюме. А дальше, если с проектом все пойдет плохо, он плюнет, уволится и будет технически готов к новой работе. Это выглядит цинично, менеджерам это не нравится и они пишут подобные статьи.
                      +1
                      А что мешает совмещать одно с другим? Ну вот скажем вы программист и отработав свои 8 часов вы уходите домой. Пока вы на фирме вы пробуете новые технологии и решаете сложные задачи. Но если к вам приходят с юзер стори/техзаданием, то вы можете попытаться прокачать скилл «определение адекватности техзадания и нахождения более оптимальных вариантов решений». Ну или что-то в этом роде ;)

                      П.С. И на мой взгляд такой скилл очень даже полезен на рынке труда и вполне себе пригодится в профессиональной карьере. И мне кажется вся статья как раз об этом.
                      П.П.С. И я бы даже сказал что в как минимум в некоторых областях ИТ именно этот скил необходим чтобы стать сениором или техлидом.
                        0
                        А что мешает совмещать одно с другим?

                        Видимо, склад мышления. Не даром есть разделение на программистов, аналитиков и менеджеров. Хотя, иногда, программист может решать и аналитические и менеджерские задачи, но это скорее исключение.
                          0
                          Ну я бы не сказал что такое как-то обязательно противоречит складу мышления программиста.
                          Но да, в чём-то вы правы и тогда я бы сказал что «сениор/техлид» из моего поста выше это комбинация «программист-аналитик». А «программист-менеджер» это уже какой-нибудь тимлид :)

                          P.S.Но останусь при своём: если вы можете такие навыки прокачать, то оно пожалуй того стоит и в жизни/профессии пригодится.
                            0
                            Но останусь при своём: если вы можете такие навыки прокачать, то оно пожалуй того стоит и в жизни/профессии пригодится.

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

                              И ты не перестаёшь быть хорошим айтишником если ты этого всего не делаешь. Просто вопрос ещё одного дополнительного «техно-софт-скилла» :)
                          0
                          Но если к вам приходят с юзер стори/техзаданием, то вы можете попытаться прокачать скилл «определение адекватности техзадания и нахождения более оптимальных вариантов решений»

                          Просто это неинтересный мне скилл. Я лучше попрокачиваю навыки в темплейтах или в хаскеле.

                          +1
                          Есть программист, ему платят зп за 8 часов работы, он наемный работник и его судьба проекта (особенно большого) интересует не слишком сильно.

                          Иногда людей, пишущих код, презрительно разделяют на кодеров и программистов. В этой "классификации", ваш программист — это кодер.


                          А есть и другой путь — заниматься не написанием фич, а созданием программного продукта. Не просто множества разных функций, а упорядоченной, гибкой и логичной системы, позволяющей пользователям решать даже такие задачи, о которых создатели системы не подозревали. Узкие примеры таких систем — word, excel (по принципу "чего в них только не пишут"). Ещё примеры — СУБД, файловые системы, различные редакторы и т.д.

                            +1
                            В этой «классификации», ваш программист — это кодер.

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

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

                              0
                              при чем тут это деление

                              Мне показалось, вы описали позицию "делаю строго то, что скажут", и у меня возникли ассоциации с таким делением. Имхо, эта позиция — совсем не самое интересное, что может быть в профессии программиста.

                          +5
                          — Что за ревью?! Какие тесты?! Тут работы на два дня на всю систему! Просто сделайте!
                          ...(некоторое время)…
                          — Ты же сам это написал! Всё работало! Неделю простейший баг исправить не можешь! Я тебе за что деньги плачу?! Что значит ты уходишь?!!!
                          ...(некоторое время)…
                          — Вот тут у нас уже всё написано… Немного доработать… Как переписать?! Я столько денег ввалил!

                          А вообще всё правильно. Но очень часто принцип, вынесенный в заголовок, «используется» «менеджерами» из монолога выше.
                            0
                            Жиза.
                            +7
                            Очень часто, а в мире OpenSource так в большинстве случаев, код пишется не потому, что хотят решить какую-то проблему, а потому, что нравится писать код. Т.е. людей интересует не цель, которой часто может и не быть, а сам процесс.
                            Вот возьмём в качестве примера такой крупный OpenSource проект, как radare2. Это кроссплатформенный фреймворк для анализа и реверсинжениринга кода, который иногда даже осмеливаются назвать свободным аналогом IDA. Но вся его крутость разбивается о тот маленький фактик, что r2 не позволяет загружать ранее созданные проекты. Ну то есть вы можете загрузить бинарник, провести анализ, расставить комментарии, обозвать переменные и структуры, даже провести частичную декомпиляцию в псевдокод. Вот только при повторной загрузке всё это потеряется, потому что загружать проекты r2 пока не умеет.
                            В итоге софт, над которыми работали многие сотни людей, пригоден разве только для примитивных крекмисов. И знаете что? Никого из разработчиков это не волнует, потому что у них нет цели создать рабочий продукт. Они занимаются ровно теми вещами, над которыми им интересно работать, пишут новые фичи, добавляют поддержку новых архитектур. В общем, получают кайф от процесса кодирования. А результат? Да кому он вообще нужен.
                            К счастью, когда подобные проекты в достаточной мере обрастают более-менее рабочими фичами, на них могут обратить внимание крупные корпорации. Вот например достал всех Autodesk совершенно неадекватной работой с крупными клиентами, и корпорации подбросили бабла в Blender. После чего вместо насквозь глючного кошмара, в котором даже union двух кубов булился с дырами, образовался вполне себе пригодный к использованию продукт.
                            Именно для того в разработке и нужны менеджеры — чтобы ставить чёткие цели и контролировать их достижение вне зависимости от того, нравится это кодерам или нет.
                              0

                              Проекты radare вроде умеет с 2017 http://radare.today/posts/project-files/. Или вы имели в виду что-то другое?

                                0
                                Это только заявлено, что умеет. А вы попробуйте:

                                r2 some_binary_file
                                aaa
                                Ps proj_name
                                q

                                и потом загрузить этот проект через Po или командную строку. Сохранение проектов реализовано, загрузка — нет.
                                0

                                Нужны менеджеры, которым нравится Open Source :)


                                Гитхаб в последнее время активно внедряет поддержку спонсорства. Уже можно спонсорить как проекты, так и самих пользователей. Может это больше их больше стимулирует пилить нужные фичи.

                                +1
                                Одним словом — изучите предметную область, прежде чем писать код.
                                  +3
                                  Рекомендую почитать «Психбольница в руках пациентов».
                                  Если кратко, то все программисты, согласно автору (вроде тоже бывшему программисту), являются особым подклассом людей, которые не умеют проектировать, но умеют писать код. И их и близко нельзя подпускать к проектированию, иначе все равно получится дурно пахнущая субстанция. Для проектирования нужны специально обученные люди.

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

                                  P.S. А дверной замок, открывающийся при приближении телефона не купил бы никогда. Слишком непредсказуемая система.
                                    +1
                                    А дверной замок, открывающийся при приближении телефона не купил бы никогда. Слишком непредсказуемая система.

                                    +1, особенно весело будет подойти к двери с телефоном спросить «кто там» когда за дверью алкаш неадекватный или грабитель какой.
                                  +1
                                  Есть довольно интересный взгляд немного с другой стороны: программисты и менеджеры, которые непосредственно руководят разработкой, обычно не очень тупые. И они понимают, что им платят за процесс разработки, а завершение разработки приведёт к массовым сокращениям, когда на поддержке останется пара человек. Поэтому надо сесть и продолжать кодить, выдавая тысячи обновлений и новые проекты, получая при этом зарплату. Так появляются безумные приложения для замков (!), почта, которая тормозит на современном ноутбуке, приложение мобильного оператора, которое требует максимальную версию IOS и посылает остальных, и пиццерия, которая нанимает десятки разработчиков и аналитиков, чтобы стабильно возить невкусную пиццу.

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

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

                                    Ну и напоследок лично я вообще ничего не имею против если продукт доходит до какого-то уровня развития, когда лично мне в нём больше нет места. Значит уволюсь(а ещё лучше пусть меня уволят) и найду новую работу по нраву. Причём скорее всего ещё и с большей зарплатой.
                                      +1
                                      бизнес и окружающий мир «придумывают» что ещё можно добавить в продукт или как его изменить

                                      Бизнес и окружающий мир — это часто и есть те люди, которые не заинтересованы в том, чтобы проект закончился. И они не хотят, в отличие от вас, увольняться и искать новую работу по нраву.
                                        0
                                        Я скорее имел ввиду «хозяев фирмы» и «мир за пределами фирмы». И если не хотят чтобы проект заканчивался и платят за это, то тут у меня вообще никаких проблем нет.
                                          +1
                                          На стороне заказчика тоже есть люди, которые вели проект, довели до рабочего состояния, но как и с ремонтом — невозможно завершить, всегда можно придумать что-то еще.
                                            0
                                            С этим я не спорю. И я ничего не имею против того чтобы проекты развивались и продолжались. Я против того чтобы разработчики сами «создавали» себе ненужную работу просто из боязни быть уволенными,

                                            П.С. И ненужная работа это именно ненужная, а не какой-нибудь действительно полезный рефакторинг или технологичеслий апгрэйд.
                                    +1
                                    The first prerequisite you need to fulfill before beginning construction is a clear statement of the problem that the system is supposed to solve.

                                    © Code complete, Steve McConnell

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

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

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

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

                                        +1

                                        Проблема, которую вы решаете, важнее, чем код, который вы пишете


                                        Программисты не решают проблемы. Программисты пишут код. А те, кто решают проблемы, сами код не пишут. Если для решения проблемы им нужен код, они зовут программистов для написания кода. И почему-то думают, что программисты решают их проблему. Господи, да мы в большинстве случаев только от вас и узнаём, что проблема существует! Хотите открывать дверь по кнопке — нате вам кнопку, хотите по GPS — нате вам GPS. Вы сами не знаете, чего хотите, и вам просто нужно с кем-то об этом поговорить? ОК, давайте устроим совещание.

                                          +1
                                          А те, кто решают проблемы, сами код не пишут.

                                          Очень глобальное заявление и на мой взгляд даже если это и правило, то у него есть огромное количество исключений :)
                                            +2

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

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

                                            КМК, тот же Spring Framework код ради кода, но при этом упрощает решение бизнесовых задач.
                                            Про виджет вам выше вполне обоснованно написали когда он удобен, возможно из-за его отсутствия стартап и накрылся?
                                            Однако, как и в случае с «Техническим долгом», ничто не должно служить оправданием для написания дерьмового кода.
                                            Не каждый код стоит писать

                                            На сколько правильно я понял посыл, зачем писать ___, которое займет 3 часа если в нужном месте можно добавить костыль за 5 минут. Так и рождается тех долг.

                                            Если у вас криптобиржа и в системе один и тот же платеж провелся дважды
                                            Не каждый баг стоит исправлять

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

                                              "Пожулуйста" это конечно не ошибка перевода...)

                                              • НЛО прилетело и опубликовало эту надпись здесь

                                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                Самое читаемое