То, что их интересно решать, не означает, что они кому-то нужны
«Группа людей проводит мозговой штурм над ноутбуком и листом бумаги», фото Стефана Стефанчика с Unspalsh
Есть много факторов, которые приводят к созданию плохого ПО: выбор инструментов, общение в команде, личная незаинтересованность разработчиков в успехе, методология тестирования. Мне кажется, у всего этого есть главная первопричина: это воображаемые проблемы.
Чрезмерно сложное или не функционирующее ПО не было задумано таким. Оно просто спроектировано для чего-то иного, а не для реальной задачи.
Предположим, вы публикуете подкасты, и вам нужен сайт, где можно продавать сопутствующие товары, зарабатывать на рекламе и, самое главное, публиковать подкасты, видео и блоги.
Требования к этому маленькому веб-приложению могут выглядеть примерно так:
- Быстрая загрузка для Северной Америки с трансляцией подкастов в реальном времени
- Отсутствие сбоев в первые 15 минут для 99,99% пользователей, желательно полное отсутствие сбоев
- Хорошая интеграция с Google Adwords и, возможно, другими сторонними рекламными системами, если есть время
- Динамические ссылки на последние товары в магазинчике и, если возможно, рекомендации пользователям на основе просмотренных страниц
- Интеграция с плеером Facebook Live. Если можно легко сделать альтернативное решение для потоковой передачи без Facebook, то ещё лучше
Вы даете эти спецификации команде подрядчика и немного с ними беседуете. Кажется, все на одной волне. Но когда они через два месяца показывают прототип, ваше лицо наливается кровью. Вы потратили $15 тыс. на кусок мусора — и хотите вернуть свои деньги.
При первом открытии приложение зависает. Вы спрашиваете, как выбрать тип баннеров — и вам показывают уродливый, непонятный UI. Половина ссылок на товары в магазинчике побиты или там отсутствуют изображения, а прямая трансляция через Facebook лагает!
Но команда разработчиков не понимает вашего гнева. В самом деле, с их точки зрения, они сумели выполнить адски сложную работу.
Они вложили душу в создание приложения, у него же удивительные возможности:
- Самая современная система рекомендаций
- Алгоритм текстовой расшифровки всех аудиопотоков в режиме реального времени
- Главная страница загружается быстрее 200 мс по всему миру
- Протокол потокового вещания и клиент сделаны почти с нуля, если вы не хотите полагаться на Facebook Live
- Разработан сервис, позволяющий легко интегрировать более 20 рекламных бирж
Проблема в том, что вы просили базовый продукт с несколькими дополнительными функциями при условии, что они достаточно просты в реализации. А команда разработчиков поняла иначе. Они услышали несколько захватывающих задач, которыми можно заняться… и множество скучных, базовых функций, которые не стоят особого внимания и тщательного тестирования.
Хуже того, вы с разработчиками не общались напрямую — вы общались через испорченный телефон. Вы говорили с продажником, который проводил совещания с участием некоторых менеджеров среднего звена. Они писали какие-то бизнес-спецификации для менеджера проекта, который писал технические спецификации — и отдавал их тимлиду или архитектору, а уже он со своей командой начинал разработку продукта. Каждое звено вносило искажения по пути.
Мнимые проблемы часто интереснее решать, чем реальные. Люди с избытком интеллекта играют в конкурентные игры, придумывают и решают математические задачи и пишут книги, чтобы ответить на абстрактные вопросы о человеческом естестве — и всё это бесплатно, только для удовольствия. Но посредственный программист, вероятно, возьмёт с вас изрядную сумму за создание простого приложения для Android. Это не потому, что посредственных программистов труднее найти, чем гениев, а потому, что первые виды деятельности интересны, а последние — довольно скучны.
Большинство программистов хотят получать деньги и получать удовольствие одновременно. Конечно, определение «интересного» у всех разное, но для многих инженеров оно сводится к решению интересных и сложных задач, которые находятся в области разрешимости.
Дайте умному человеку слишком много скучных задач, которые невозможно автоматизировать, и вы в конечном итоге сведёте его с ума. Однако человеческий мозг после миллиардов лет эволюции стал очень изобретательным в сохранении рассудка. Подобно тому, как жертвы детских лишений или жестокого обращения находят спасение в фантастических книжках, жертвы корпоративного программирования и фрилансеры ищут спасение в решении воображаемых проблем.
Количество воображаемых проблем, которые инженер-программист может для себя создать, зависит от его воображения и сложности реальных проблем, которые нужно решить.
Следует отметить, что эта проблема не уникальна для разработчиков. Менеджмент, продажи, HR, поддержка, юридические и даже бухгалтерские отделы — у всех есть собственные уникальные способы создания мнимых проблем. Одни стараются влезть в процесс принятия решения, когда их присутствие на собрании является просто формальностью или вообще не требовалось. Другие переоценивают мелкую проблему, связанную с их ролью, или нанимают намного больше сотрудников, чем необходимо, чтобы продемонстрировать свою важность.
Когда проблемы слишком глупы, умные люди найдут способ исправить ситуацию.
Но воображаемые проблемы идут не только от скучающих разработчиков. Они также порождаются в результате длинных цепочек коммуникаций.
Когда я только начал искать клиентов как фрилансер, то не мог позволить себе выстраивать коммуникацию на своё усмотрение. Так что приходилось иметь дело с длинными почтовыми тредами с сотнями писем, где обсуждались незначительные детали внутренних MVP. Люди в течение недели меняли каждое требование в проекте. У меня были клиенты, которые задавали такие вопросы: «Это будет совместимо с проведением ICO?» или «Можно здесь добавить немного ИИ?»
Конечно, у большинства клиентов достаточно опыта, но даже им часто не хватает знаний для формулирования или построения некоторых требований. Это нормально, поскольку часть моей работы в качестве «компьютерщика» — помочь людям понять, что они делают, а что им не нужно, исходя из их конкретной ситуации. Но это гораздо труднее определить, когда между вами и клиентом несколько прокладок.
Требования меняются, потому что кто-то или неправильно понял намерение, или попытался справиться с вышеупомянутой скукой
Большинство компаний любят заводить в штате продажника, который пристаёт к потенциальным клиентам, торгуется и в общем описывает продукт. Также есть специалисты с продвинутыми навыками общения с людьми, чтобы обсудить с клиентом более детальные спецификации и требования: это обычно такой же продажник, только немного с другим названием должности. И есть внутренняя корпоративная система, различные уровни менеджмента и, возможно, некоторая иерархия в технической команде.
Когда список требований клиента проходит через такое количество людей, даже если у этих людей лучшие намерения, в процессе неизбежно что-то теряется. Иногда это происходит потому, что исходное требование не имело смысла или его нужно изменить. Возможно, продажник заявил клиенту: «Всего за 39 999 сверху мы сделаем это на блокчейне». Тот согласился, а всем остальным остаётся гадать, что именно означает «сделать на блокчейне».
Чаще всего требования меняются или потому что кто-то или неправильно понял намерение, или попытался справиться с вышеупомянутой скукой, пытаясь сделать свою работу или работу своей команды более интересной и впечатляющей.
За всем этим теряются первоначальные требования — те реальные проблемы, которые необходимо решить. Они заменяются воображаемыми проблемами и пустотами, а у вас много людей, готовых и желающих заполнить эти пустоты своими воображаемыми проблемами, потому что реальные проблемы, которые они должны решить, скучны, а заполнение пустот даёт им удовлетворение.
Чрезмерная сложность и естественный отбор
Часто есть и более мрачная причина появления мнимых проблем: такие проблемы помогают команде или компании расти, они даже могут стать неотъемлемой частью её работы.
«У людей, которых выводят, отбирают и поощряют искать сложные решения, нет стимула внедрять упрощённые»
— Нассим Николас Талеб
Вы слышали о тех трёх программистах, которые нашли по-настоящему простое решение для безопасного веб-банкинга? Они разработали с нуля безупречный банковский софт, используя методологию функционального дизайна и безопасные языки, а затем начали переводить крупные банки на свою удивительную инфраструктуру.
Возможно, вы о них не слышали, потому что их не существует. Но есть много команд из тысяч разработчиков, которые не в состоянии усвоить простые понятия, такие как «откат на старую версию», и они постоянно заняты созданием банковского софта.
Хранение и передача цифр — не особо сложная проблема. Вот проиндексировать всё содержимое интернета и выдать соответствующий результат для запроса на естественном языке за доли секунды — другое дело. Но лишь нескольким умным парням удалось решить эту проблему.
Хронической проблемой онлайн-банкинга является то, что банковская экосистема действительно достигла совершенства в собственной иерархии присвоения денег. Её лидеры — это коррумпированные пиявки, которые присосались к телу общества, но лидеры организации лишь отражают состояние всей системы.
Я не говорю, что большинство обычных банковских сотрудников — злобные и вредные личности. Отнюдь нет. Как правило, это дружелюбные ребята, которые зарабатывают на еду, жильё и образование для своих семей. Но их главный стимул — не исправлять банковское программное обеспечение, а сохранить работу. Потеря работы в современной экономике — серьёзная проблема для некоторых людей, а в банковской отрасли неосторожное слово или излишняя инициатива — это простой способ предстать перед дисциплинарным комитетом.
Таким образом, банковские системы остаются прежними — не потому, что они эффективны, а из-за инерции. Эта инерция проявляется в виде решения мнимых проблем, чтобы избежать решения реальных проблем — решение которых, как уже отмечалось, угрожает работе других людей. Решение этих реальных проблем может привести к увольнению или, в случае некоторых особенно неприятных «учреждений» вроде Goldman Sachs, к нескольким письмам, которые разрушают жизнь бывшего сотрудника и заканчиваются странным самоубийством.
«Трудно заставить человека что-то понять, если его зарплата зависит от того, что он не понимает!»
— Аптон Синклер
Рядовые корпи игнорируют тот факт, что высший менеджмент тратит 90% времени на «встречи с клиентами», включая путешествия на тропические острова и миллионные бюджеты для «накладных расходов». В свою очередь, высший менеджмент закрывает глаза на коррупцию в рядовом составе.
Поскольку менеджеры среднего звена поощряет их фантазии в стиле «Волка с Уолл-Стрит», высшее руководство закрывает глаза на поведение этих менеджеров, которые покупают эксцентричные офисы, нанимают трёх секретарш и десяток стажёрок.
Поскольку рядовые менеджеры не жалуются о своих диктаторских фантазиях и жажде власти, менеджеры среднего звена закрывают глаза на тот факт, что они вместо сокращения расходов тратят время на презентации PowerPoint об «Улучшении нашей гибкой методологии Agile».
Поскольку тимлиды не обращают внимания, что их начальство даже не умеет правильно использовать Excel и заходит в офис пару раз в неделю, рядовые менеджеры закрывают глаза, когда тимлиды и архитекторы говорят о «следующем поколении взаимодействия между нашими системами через JRPC и микросервизацию с помощью Hibernate и Spring», когда эти чёртовы MySQL-запросы выполняются больше суток.
Поскольку разработчики как будто не замечают, что их тимлиды не пишут никакого кода, кроме диаграмм, тимлиды не жалуются на своих разработчиков, которые вместо того, чтобы ОБЪЯСНИТЬ тормоза вышеупомянутого запроса, в десятый раз за год переделывают UI на новом фреймворке JavaScript.
Это порочный круг решения воображаемых проблем: от генерального директора, который не понимает, что кража ещё 30 миллионов не даст ему родительской любви, до стажёра, который не понимает, что новая кнопка «Отправить» на Angular-Material-Bootstrap 19.13.5 не изменит того, что пароли хранятся обычным текстом (и используются для проверки куков).
Но всем приходится и дальше решать воображаемые проблемы, потому что если они перестанут это делать, то начнут фокусироваться на реальных проблемах — и поймут, что вся система сломана. Они могут понять, что в углу офиса Дебра уже десять лет смотрит на графики безотказной работы кластера серверов, хотя пять лет назад компания переехала на AWS. Они могут понять, что 99% их задач нужно только для сохранения чьей-то чужой работы. И это осознание трудно принять, осмелюсь сказать, даже невозможно для большинства. Поэтому большинство находит способ адаптироваться.
Комментарии (40)
arielf
08.09.2018 20:51+1Люди с избытком интеллекта играют в конкурентные игры, придумывают и решают математические задачи и пишут книги, чтобы ответить на абстрактные вопросы о человеческом естестве — и всё это бесплатно, только для удовольствия.
Излишне смелое заявление — не все перечисленные проблемы мнимые. Например, вопрос о нашем «я» безумно важен в контексте цифровой версии нашего сознания. Или более приземлённый пример — физик Дэвид Дойч обосновал концепцию квантовых вычислений, решая проблему обоснования многомировой квантовой механики.Hardcoin
09.09.2018 12:31+2Этот пассаж не про мнимость, а про интерес. Интересные вещи люди могут делать и бесплатно. А скучные — только за деньги. Но делать скучные вещи — скучно. Потому придумывают себе интерес в виде мнимых проблем.
arielf
08.09.2018 21:08У людей, которых выводят, отбирают и поощряют искать сложные решения
Хм, так и не понял фразы.
maisvendoo
08.09.2018 22:10банковская экосистема действительно достигла совершенства в собственной иерархии присвоения денег. Её лидеры — это коррумпированные пиявки, которые присосались к телу общества
Аплодирую стоя!
VolCh
08.09.2018 23:22+1Не думаю, что многие разработчики что-то там думают о сохранении чужих рабочих мест. С другой стороны, вряд ли кто вот прямо сознательно решает мнимые проблемы. Скорее реальная проблема в испорченном телефоне и отсутствии ранней обратной связи. Если до разработчика не дошло уточнение заказчика что ему лучше хрупкий костыль за день, чем универсальное гибкое решение, то поставив такое решение разработчик уверен, что решил проблему заказчика, даже если за лишние 6 дней последний обанкротился.
TheShock
09.09.2018 08:18лучше хрупкий костыль за день
Любой заказчик скажет, что ему нужно быстрее и дешевле, а на качество кода ему плевать. Но это не значит, что любому заказчику это РЕАЛЬНО нужно. Часто они мыслят категориями: «деньги и время — это моя проблема и программист хочет заниматься какой-то фигней за мои деньги и время». Но не способны посмотреть даже на шаг вперед и понять, что в среднесрочной перспективе деньги и время они так только потеряют. То есть нужно различать две разные «мне нужно быстро и дешево»:
— Мне нужно быстро, дешево и некачественно, всё-равно я эту штуку через две недели выкину, когда пройдет эвент, под который мы ее делаем
— Мне нужно быстро, дешево, но так, чтобы было и дешево всегда, потому что наша компания собирается ею пользоваться годами
Вот для первых — реально надо делать быстро и дешево, а вторые просто хотят переложить свое нежелание платить полную сумму на ответственность разработчика, когда он через полгода будет овертаймить из-за того, что наделал факапов, которых его просили наделать полгода назад.
mSnus
09.09.2018 00:47Более того, есть ещё такое милое занятие как "аутсорсинг", которое позволяет юристам, программистам, рекламщикам и прочим работникам не делать НИЧЕГО — главное найти, кому слить задачу, оставив себе чуть-чуть (чуть-чуть может легко достигать 70%).
Главное — солидная вывеска! И умение участвовать в тендерах правильно.
dmxvlx
09.09.2018 01:16Количество воображаемых проблем, которые инженер-программист может для себя создать, зависит от его воображения и сложности реальных проблем, которые нужно решить.
Возможно речь идёт ни столько об усложнении простых и скучных задач, сколько об желании инженера создать свой инструмент для решения текущей задачи, потому что имеющийся не подходит по многим его критериям правильного ПО.
Это ведь элементарно: когда инженеру не нравится архитектура библиотеки для работы с HTTP, он начинает писать библиотеку с хорошей архитектурой, при этом не забыв запихнуть туда всё, что по его мнению должно там быть, не смотря на то, что в текущем проекте это не будет использовано — библиотека ведь должна отвечать критериям правильного ПО...
Хотя да, со стороны это выглядит как усложнение простых и скучных задач...
algotrader2013
09.09.2018 11:36Это не только выглядит и крякает, как усложнение, но им и является. Потому, что функции данной библиотеки, которые не используются в данном проекте, будут забагованными и крайне неудобными в использовании, так, как тяжело написать что -либо стоящее, не понимая, как это будет использоваться, и тяжело написать что-либо безбажное, не проверив работу в проде.
dmxvlx
09.09.2018 11:46Мной имелось ввиду (к примеру):
в проде нужен доступ по HTTP, инженер стал пилить свою либу, за одно запилил поддержку SSL/TLS…algotrader2013
10.09.2018 23:07Отличный пример! Инженеру в рамках задачи надо запилить фичу, для которой выделены ресурсы QA на тестирование работы по http, также early adopters еще раз протестируют работу по http на бете, и после этого еще суровое испытание продом. То есть, вероятность некорректной работы есть, но она незначительна. Но инженер добавляет возможность делать запросы и по https, о чем указываете в комментариях и/или документации.
Тот, кто потом будет работать с этой либой, понимая, что либа проверена временем, и яляется частью успешного проекта, без тени сомнения использует ее для запросов по https, и даже не осознает, что, используя настолько протестированную либу, он является первым человеком, который в принципе запустил эту ветку кода…dmxvlx
11.09.2018 03:49А ещё есть разработчики, которые навыдумывают тысячу ПРОТИВ,
и не сдвинутся с места, не важно: доп.функционал это или нет.
Они видят в каждой строчке кода потенциальную уязвимость,
и у них нет наработанного внутреннего статического анализатора,
который помогает им писать код без багов минуя тесты…
Просто когда у меня возникают предположения вроде: «здесь у нас может случиться бяка»,
я предусматриваю это при кодировании, а не говорю начальству что мне
нужно обкатать это в каком-то там проде, прежде чем позволить себе
закодить это.
Видеть потенциальную уязвимость того или иного решения — ценный дар,
но нужно ещё и уметь правильно пользоваться им: не выбрасывать
в топку идеи, а писать безбажный код!
Я вовсе не склоняю людей к написанию не используемого функционала,
я лишь говорю: можешь — делай, сомневаешься — ты волен забыть это
и никогда не вспоминать ))sumanai
11.09.2018 19:52Есть три стадии принятия уязвимостей в написанном собою коде:
- Пишешь говнокод, не задумываясь об уязвимостях
- Пишешь код, продумывая с учётом потенциальных уязвимостей
- Пишешь код, продумываешь, но всё равно понимаешь, что в нём есть дыры
Судя по «писать безбажный код» вы на второй стадии.dmxvlx
11.09.2018 20:10Всё относительно… Это лишь вами очерченные границы, за которыми вы ещё возможно и не бывали…
Мир — большой, и полон удивительных вещей! И он не ограничивается тремя берёзками в густом смешанном лесу…
Я — есть я, не потому что я на какой-то там стадии, всё проистекает из личности…
VolCh
09.09.2018 15:14+1Ну не факт, что является. Вот делаем библиотеку для http в проекте где только get запросы планируются, но сразу делаем возможность отправлять любые другие. Библиотека усложняется немного, но приложение наше упрощается, потому что в местах вызова http метод указывается явно и программисту, читающему код не нужно исследовать саму библиотеку, чтобы узнать какой метод она использует.
algotrader2013
09.09.2018 20:12А потом тот, кому надо пост, вдруг обнаруживает, что пост работает не совсем так, как надо (потому, что баги, которые нашлись для гета в процессе тестирования основного проекта, просто не могли быть найдены для поста). И выбирая между «разобраться в недокументированном коде библиотеки» и «забабахать еще одну, в которой уж точно и пост и гет будут работать безупречно», очевидно выбирает вариант 2.
Пример утрированный, но в реальных проектах наблюдал раз 5. Потому, что это для автора библиотека универсальная, расширяемая, и просто достойная восхищения. А для тех, кому потом ею пользоваться — кусок недокументированного хз как работавшегоговналегаси.VolCh
10.09.2018 07:29> очевидно выбирает вариант 2.
Нормальный вариант, если реально не разобраться «без поллитры» в предыдущей. Главное, если не выпилить её из проекта полностью, то задеприкейтить, чтобы новый код использовал только её, чтобы ни одна строчка + в диффах следующих коммитов не была со старой (в исключительных случаях можно, типа изменился ендпоинт очень важного внешнего API, который был захардкожен прямо в вызове)
dimoff66
09.09.2018 07:48Программист становится хорошим, когда он наелся программированием, и оно перестает его интересовать как таковое. В этом случае он начинает искать простейшие и эффективнейшие пути для решения задачи — ему лень писать код, поэтому он пишет по минимуму и максимально оптимизировано и расширяемо, чтобы потом не переделывать.
TheShock
09.09.2018 08:00+1Видал я таких программистов. Они пишут ужасный, запутанный, плохой код, который невозможно поддерживать. Скорость внедрения новых фич падает, количество багов — растет, а их фиксинг создает еще больше багов.
Потому что человеку не интересно это дело. И вместо того, чтобы подумать и понять корень ошибки — он ленится и выбирает самый быстрый способ. Вместо того, чтобы подумать, как переформатировать код так, чтобы те три почти одинаковых куска слить в один — он просто копипастит его в четвертый раз и бежит пить пивко.
Да, в этот день его менеджер похвалит, но никогда не сможет понять, почему цена поддержи и развития так
dimoff66
09.09.2018 08:06-1Если написанное мной «ему лень писать код, поэтому он пишет по минимуму и максимально оптимизировано и расширяемо, чтобы потом не переделывать.» для вас вытекает в
видел я таких… он просто копипастит его в четвертый раз и бежит пить пивко.
то ок. Сами за меня придумали, сами свои же фантазии опровергли и мне сминусовали. Полное самообслуживание.TheShock
09.09.2018 08:12+1когда он наелся программированием, и оно перестает его интересовать как таковое
Таких программистов я видал и о таких рассказал.
А вот таких программистов, которые не любят, не горят своей работой, относятся к ней как к должному и при этом стараются писать хороших, оптимизированный, расширяемый и продуманный код — таких не видал. И именно такие мне кажутся фантазией с внутренним противоречием. Взаимоисключающие вещи. Человек или горит и делает работу хорошо или сгорел и делает её на отъ…dimoff66
09.09.2018 08:24Вы никогда не замечали, что программистов, любящих писать код, интересует не результат работы, а процесс, о чем и описано в статье. Человек, который наедается программированием(ну или может более правильное слово «кодированием»), обращает больше внимания на архитектуру и целостность решения. Из лени писать код он делает минимум, или оптимальный минимум. Конечно, для этого интерес к программированию и увлеченность должна была присутствовать хотя бы в прошлом, чтобы не копипастить куски кода. То есть обретение лени пот отношению к кодированию не значит появление безответственности по отношению к результату, возможно иногда наоборот. Мне вспоминается случай одного моего знакомого, который любил писать всякие умопомрачительные вещи, чтобы все восторгались. И он сказал простую фразу: «Если какая-то задача меня по настоящему увлекла, мне пофиг что говорит работодатель», Также вспоминаю еще двух знакомых, программистов топ класса в своей области, которые на форумах демонстрировали просто феноменальный интеллект в подходах к решению задач, но при этом периодически проваливали реальные проекты просто потому, что им было скучно.
Если в вашей жизни вам такие примеры не встречались — видимо у нас разный жизненный опыт и мы говорим о разных людях.TheShock
09.09.2018 08:30Мне никогда не встречались программисты, которые устали программировать и которые писали бы при этом хороший код. Видите ли, но для этого нужно думать. А чтобы думать — нужно хотеть думать. А зачем это, если можно не думать? 9 часов в офисе и так и так сидеть — хоть ты самый говнокод пиши
Среди горящих программистов я видел плохих и даже очень плохих. А еще видел хороших и просто звезд, которыми я восхищаюсь.
Среди потухших программистов я видел только плохих и очень плохих. Ну, может, с натяжкой, средних
dmxvlx
09.09.2018 10:34Соглашусь с тем, что с опытом программист начинает искать
самые короткие пути достижения поставленных задач.
Больше времени уделяется составлению
дорожных карт,
ну или проработке ТЗ если хотите...
VolCh
09.09.2018 15:34По минимуму и максимально расширяемо противоречит друг другу. Мнимальный код, решающий текущую задачу, только случайно может быть более расширяем чем предусмотрено задачей. Ну, например, в объекте для которого пишем новый метод уже инициализирована зависимость нужная для этого метода и тогда мы не пишем код инициализации автоматически получая расширяемость. А не инициализирован — пишем минимальную инициализацию без всяких DI и повторного использования, потому что их поддержка это уже не минимальный код.
dimoff66
09.09.2018 15:40Продумать и написать один раз максимально расширяемый код, а не исправлять каждый раз имеющийся после каждого небольшого изменения бизнес-логики и является в моем понимании максимально расширяемым кодом, написанным по минимуму, так как в долгосрочной перспективе хорошо расширяемый код освобождает от необходимости его переписывать.
VolCh
10.09.2018 07:18А что значит тогда максимально расширяемый код, написанный по максимуму?
dimoff66
10.09.2018 12:22Например описанное здесь
habr.com/post/422679/#comment_19091403
или написание функционала, который уже есть в существующих библиотеках, а возможно даже в проекте.
scg
10.09.2018 11:34Зато я видал обратное: человек начитается книжек по всяким продвинутым технологиям и начинает пихать их в проект к месту и не к месту. То, что множно написать 10-ю строчками превращвется в 10 файлов. Обязательно нужно засунуть пару фабрик и 10 синглтонов. А объект нужно создавать так, чтобы было непонятно, откуда он вообще взялся, так как это круто и так было в книге. Еще, такие программисты очень любят заморачиваться с будущей расширяемостью, превращая простой класс в цепочку из пяти шаблонов: чтобы можно было на любом уровне расширить функциональность. Правда, за всю историю проекта этот класс не модифицируется ни разу, зато новые фичи требуются в других местах, о которых он не думал и проект все-равно превращается в кучу костылей, но уже с шаблонами.
Да что тут говорить, даже я недавно дорабатывая программу, добавил одну очень нужную фичу от себя, думая, что она очень полезная и понадобиться заказчику. Потратил на это лишний месяц, а потом пришлось ее вырезать.dimoff66
10.09.2018 12:16О да, на предыдущем месте работы начальник был именно таким. Добавление дополнительного условия в функцию требовало создания отдельного «сервиса» с функцией с тем же именем, из которой вызывалась бы функция изначального класса, на результат накладывалось бы условие, а в код, откуда вызывается функция, один из этих классов — с условием или без — передавался бы через депенденси инджекшн. Это все безмерно меня удивляло на фоне того, что механизмы, которые реально требовали оптимизации, не оптимизировались под предлогом того, что у нас нет на это времени и ресурсов. Понятно, что после испытательного срока я оттуда ушел, поскольку никакого понимания не было.
VolCh
10.09.2018 18:12Прежде всего тут видна непоследовательность в действиях. Если есть цепочка из пяти шаблонов, а требуется шестое изменение, то нужно или подвинуть один из пяти шаблонов по цепочке, или создать шестой шаблон в ней или другом месте, если к цепочке требуемое изменение никак не относится.
scg
10.09.2018 20:37Нет, все еще печальнее: изменение требовались вообще в другом месте. В процессе разработки программист видел один путь развития проекта, а жизнь продиктовала совсем другой. В результате человек потратил некоторые усилия, но результат оказался не просто бесполезным а еще и немного вредным. Получилось как в статье: решались проблемы существующие лишь в голове разработчика. Поэтому я и согласен с автором комментария, что более опытный программист не будет решать несуществующие проблемы в том числе и из-за лени.
VolCh
11.09.2018 10:37+1Часто бывает, что применени шаблонов ускоряет разработку, даже если фактического переиспользования кода нет и проект не развивается в том направлении, под которые заточены использованные шаблоны. Просто меньше приходится думать, пускай и больше кода писать.
То есть конкретные шаблоны предназначены для решения каких-то конкретных проблем способом, дающим какие-то «побочные» плюсы не важные здесь и сейчас. Можно решить эти же проблемы кучей других способов, которые могут быть эффективней по размеру кода, потребляемым ресурсам и т. п. в данных случаях, но проще применить шаблон, поскольку его код, как говорится, из под пальцев сам выскакивает, а над специфичным кодом думать надо, пускай и код с шаблонами будет более сложным формально, да и субъективно для человека незнакомого с данным шаблоном.
iig
09.09.2018 09:50Первая часть — пересказ картинки программист_и_качели.жпг.
Вторая часть с первой плохо связана. В ней про то, что для зарабатывания денег можно и не упарываться в качество продукта. И это нехорошо, хотя многие так делают.
zxweed
09.09.2018 14:45к нескольким письмам, которые разрушают жизнь бывшего сотрудника и заканчиваются странным самоубийством.
странная отсылка, Алейников жив вроде?
TiesP
Уже было, только статья называлась Воображаемые проблемы — корень плохого ПО