Comments 40
Очень похоже на habr.com/company/infopulse/blog/418431
Люди с избытком интеллекта играют в конкурентные игры, придумывают и решают математические задачи и пишут книги, чтобы ответить на абстрактные вопросы о человеческом естестве — и всё это бесплатно, только для удовольствия.Излишне смелое заявление — не все перечисленные проблемы мнимые. Например, вопрос о нашем «я» безумно важен в контексте цифровой версии нашего сознания. Или более приземлённый пример — физик Дэвид Дойч обосновал концепцию квантовых вычислений, решая проблему обоснования многомировой квантовой механики.
У людей, которых выводят, отбирают и поощряют искать сложные решенияХм, так и не понял фразы.
Очень похоже на эпоху застоя.
банковская экосистема действительно достигла совершенства в собственной иерархии присвоения денег. Её лидеры — это коррумпированные пиявки, которые присосались к телу общества
Аплодирую стоя!
Не думаю, что многие разработчики что-то там думают о сохранении чужих рабочих мест. С другой стороны, вряд ли кто вот прямо сознательно решает мнимые проблемы. Скорее реальная проблема в испорченном телефоне и отсутствии ранней обратной связи. Если до разработчика не дошло уточнение заказчика что ему лучше хрупкий костыль за день, чем универсальное гибкое решение, то поставив такое решение разработчик уверен, что решил проблему заказчика, даже если за лишние 6 дней последний обанкротился.
лучше хрупкий костыль за день
Любой заказчик скажет, что ему нужно быстрее и дешевле, а на качество кода ему плевать. Но это не значит, что любому заказчику это РЕАЛЬНО нужно. Часто они мыслят категориями: «деньги и время — это моя проблема и программист хочет заниматься какой-то фигней за мои деньги и время». Но не способны посмотреть даже на шаг вперед и понять, что в среднесрочной перспективе деньги и время они так только потеряют. То есть нужно различать две разные «мне нужно быстро и дешево»:
— Мне нужно быстро, дешево и некачественно, всё-равно я эту штуку через две недели выкину, когда пройдет эвент, под который мы ее делаем
— Мне нужно быстро, дешево, но так, чтобы было и дешево всегда, потому что наша компания собирается ею пользоваться годами
Вот для первых — реально надо делать быстро и дешево, а вторые просто хотят переложить свое нежелание платить полную сумму на ответственность разработчика, когда он через полгода будет овертаймить из-за того, что наделал факапов, которых его просили наделать полгода назад.
Более того, есть ещё такое милое занятие как "аутсорсинг", которое позволяет юристам, программистам, рекламщикам и прочим работникам не делать НИЧЕГО — главное найти, кому слить задачу, оставив себе чуть-чуть (чуть-чуть может легко достигать 70%).
Главное — солидная вывеска! И умение участвовать в тендерах правильно.
Количество воображаемых проблем, которые инженер-программист может для себя создать, зависит от его воображения и сложности реальных проблем, которые нужно решить.
Возможно речь идёт ни столько об усложнении простых и скучных задач, сколько об желании инженера создать свой инструмент для решения текущей задачи, потому что имеющийся не подходит по многим его критериям правильного ПО.
Это ведь элементарно: когда инженеру не нравится архитектура библиотеки для работы с HTTP, он начинает писать библиотеку с хорошей архитектурой, при этом не забыв запихнуть туда всё, что по его мнению должно там быть, не смотря на то, что в текущем проекте это не будет использовано — библиотека ведь должна отвечать критериям правильного ПО...
Хотя да, со стороны это выглядит как усложнение простых и скучных задач...
Это не только выглядит и крякает, как усложнение, но им и является. Потому, что функции данной библиотеки, которые не используются в данном проекте, будут забагованными и крайне неудобными в использовании, так, как тяжело написать что -либо стоящее, не понимая, как это будет использоваться, и тяжело написать что-либо безбажное, не проверив работу в проде.
Мной имелось ввиду (к примеру):
в проде нужен доступ по HTTP, инженер стал пилить свою либу, за одно запилил поддержку SSL/TLS…
в проде нужен доступ по HTTP, инженер стал пилить свою либу, за одно запилил поддержку SSL/TLS…
Отличный пример! Инженеру в рамках задачи надо запилить фичу, для которой выделены ресурсы QA на тестирование работы по http, также early adopters еще раз протестируют работу по http на бете, и после этого еще суровое испытание продом. То есть, вероятность некорректной работы есть, но она незначительна. Но инженер добавляет возможность делать запросы и по https, о чем указываете в комментариях и/или документации.
Тот, кто потом будет работать с этой либой, понимая, что либа проверена временем, и яляется частью успешного проекта, без тени сомнения использует ее для запросов по https, и даже не осознает, что, используя настолько протестированную либу, он является первым человеком, который в принципе запустил эту ветку кода…
Тот, кто потом будет работать с этой либой, понимая, что либа проверена временем, и яляется частью успешного проекта, без тени сомнения использует ее для запросов по https, и даже не осознает, что, используя настолько протестированную либу, он является первым человеком, который в принципе запустил эту ветку кода…
А ещё есть разработчики, которые навыдумывают тысячу ПРОТИВ,
и не сдвинутся с места, не важно: доп.функционал это или нет.
Они видят в каждой строчке кода потенциальную уязвимость,
и у них нет наработанного внутреннего статического анализатора,
который помогает им писать код без багов минуя тесты…
Просто когда у меня возникают предположения вроде: «здесь у нас может случиться бяка»,
я предусматриваю это при кодировании, а не говорю начальству что мне
нужно обкатать это в каком-то там проде, прежде чем позволить себе
закодить это.
Видеть потенциальную уязвимость того или иного решения — ценный дар,
но нужно ещё и уметь правильно пользоваться им: не выбрасывать
в топку идеи, а писать безбажный код!
Я вовсе не склоняю людей к написанию не используемого функционала,
я лишь говорю: можешь — делай, сомневаешься — ты волен забыть это
и никогда не вспоминать ))
и не сдвинутся с места, не важно: доп.функционал это или нет.
Они видят в каждой строчке кода потенциальную уязвимость,
и у них нет наработанного внутреннего статического анализатора,
который помогает им писать код без багов минуя тесты…
Просто когда у меня возникают предположения вроде: «здесь у нас может случиться бяка»,
я предусматриваю это при кодировании, а не говорю начальству что мне
нужно обкатать это в каком-то там проде, прежде чем позволить себе
закодить это.
Видеть потенциальную уязвимость того или иного решения — ценный дар,
но нужно ещё и уметь правильно пользоваться им: не выбрасывать
в топку идеи, а писать безбажный код!
Я вовсе не склоняю людей к написанию не используемого функционала,
я лишь говорю: можешь — делай, сомневаешься — ты волен забыть это
и никогда не вспоминать ))
Ну не факт, что является. Вот делаем библиотеку для http в проекте где только get запросы планируются, но сразу делаем возможность отправлять любые другие. Библиотека усложняется немного, но приложение наше упрощается, потому что в местах вызова http метод указывается явно и программисту, читающему код не нужно исследовать саму библиотеку, чтобы узнать какой метод она использует.
А потом тот, кому надо пост, вдруг обнаруживает, что пост работает не совсем так, как надо (потому, что баги, которые нашлись для гета в процессе тестирования основного проекта, просто не могли быть найдены для поста). И выбирая между «разобраться в недокументированном коде библиотеки» и «забабахать еще одну, в которой уж точно и пост и гет будут работать безупречно», очевидно выбирает вариант 2.
Пример утрированный, но в реальных проектах наблюдал раз 5. Потому, что это для автора библиотека универсальная, расширяемая, и просто достойная восхищения. А для тех, кому потом ею пользоваться — кусок недокументированного хз как работавшегоговна легаси.
Пример утрированный, но в реальных проектах наблюдал раз 5. Потому, что это для автора библиотека универсальная, расширяемая, и просто достойная восхищения. А для тех, кому потом ею пользоваться — кусок недокументированного хз как работавшего
> очевидно выбирает вариант 2.
Нормальный вариант, если реально не разобраться «без поллитры» в предыдущей. Главное, если не выпилить её из проекта полностью, то задеприкейтить, чтобы новый код использовал только её, чтобы ни одна строчка + в диффах следующих коммитов не была со старой (в исключительных случаях можно, типа изменился ендпоинт очень важного внешнего API, который был захардкожен прямо в вызове)
Нормальный вариант, если реально не разобраться «без поллитры» в предыдущей. Главное, если не выпилить её из проекта полностью, то задеприкейтить, чтобы новый код использовал только её, чтобы ни одна строчка + в диффах следующих коммитов не была со старой (в исключительных случаях можно, типа изменился ендпоинт очень важного внешнего API, который был захардкожен прямо в вызове)
Программист становится хорошим, когда он наелся программированием, и оно перестает его интересовать как таковое. В этом случае он начинает искать простейшие и эффективнейшие пути для решения задачи — ему лень писать код, поэтому он пишет по минимуму и максимально оптимизировано и расширяемо, чтобы потом не переделывать.
Видал я таких программистов. Они пишут ужасный, запутанный, плохой код, который невозможно поддерживать. Скорость внедрения новых фич падает, количество багов — растет, а их фиксинг создает еще больше багов.
Потому что человеку не интересно это дело. И вместо того, чтобы подумать и понять корень ошибки — он ленится и выбирает самый быстрый способ. Вместо того, чтобы подумать, как переформатировать код так, чтобы те три почти одинаковых куска слить в один — он просто копипастит его в четвертый раз и бежит пить пивко.
Да, в этот день его менеджер похвалит, но никогда не сможет понять, почему цена поддержи и развития так
Если написанное мной «ему лень писать код, поэтому он пишет по минимуму и максимально оптимизировано и расширяемо, чтобы потом не переделывать.» для вас вытекает в
то ок. Сами за меня придумали, сами свои же фантазии опровергли и мне сминусовали. Полное самообслуживание.
видел я таких… он просто копипастит его в четвертый раз и бежит пить пивко.
то ок. Сами за меня придумали, сами свои же фантазии опровергли и мне сминусовали. Полное самообслуживание.
когда он наелся программированием, и оно перестает его интересовать как таковоеТаких программистов я видал и о таких рассказал.
А вот таких программистов, которые не любят, не горят своей работой, относятся к ней как к должному и при этом стараются писать хороших, оптимизированный, расширяемый и продуманный код — таких не видал. И именно такие мне кажутся фантазией с внутренним противоречием. Взаимоисключающие вещи. Человек или горит и делает работу хорошо или сгорел и делает её на отъ…
Вы никогда не замечали, что программистов, любящих писать код, интересует не результат работы, а процесс, о чем и описано в статье. Человек, который наедается программированием(ну или может более правильное слово «кодированием»), обращает больше внимания на архитектуру и целостность решения. Из лени писать код он делает минимум, или оптимальный минимум. Конечно, для этого интерес к программированию и увлеченность должна была присутствовать хотя бы в прошлом, чтобы не копипастить куски кода. То есть обретение лени пот отношению к кодированию не значит появление безответственности по отношению к результату, возможно иногда наоборот. Мне вспоминается случай одного моего знакомого, который любил писать всякие умопомрачительные вещи, чтобы все восторгались. И он сказал простую фразу: «Если какая-то задача меня по настоящему увлекла, мне пофиг что говорит работодатель», Также вспоминаю еще двух знакомых, программистов топ класса в своей области, которые на форумах демонстрировали просто феноменальный интеллект в подходах к решению задач, но при этом периодически проваливали реальные проекты просто потому, что им было скучно.
Если в вашей жизни вам такие примеры не встречались — видимо у нас разный жизненный опыт и мы говорим о разных людях.
Если в вашей жизни вам такие примеры не встречались — видимо у нас разный жизненный опыт и мы говорим о разных людях.
Мне никогда не встречались программисты, которые устали программировать и которые писали бы при этом хороший код. Видите ли, но для этого нужно думать. А чтобы думать — нужно хотеть думать. А зачем это, если можно не думать? 9 часов в офисе и так и так сидеть — хоть ты самый говнокод пиши
Среди горящих программистов я видел плохих и даже очень плохих. А еще видел хороших и просто звезд, которыми я восхищаюсь.
Среди потухших программистов я видел только плохих и очень плохих. Ну, может, с натяжкой, средних
Среди горящих программистов я видел плохих и даже очень плохих. А еще видел хороших и просто звезд, которыми я восхищаюсь.
Среди потухших программистов я видел только плохих и очень плохих. Ну, может, с натяжкой, средних
Соглашусь с тем, что с опытом программист начинает искать
самые короткие пути достижения поставленных задач.
Больше времени уделяется составлению дорожных карт,
ну или проработке ТЗ если хотите...
Ему лень писать код, поэтому он его копипастит. Видели такое.
По минимуму и максимально расширяемо противоречит друг другу. Мнимальный код, решающий текущую задачу, только случайно может быть более расширяем чем предусмотрено задачей. Ну, например, в объекте для которого пишем новый метод уже инициализирована зависимость нужная для этого метода и тогда мы не пишем код инициализации автоматически получая расширяемость. А не инициализирован — пишем минимальную инициализацию без всяких DI и повторного использования, потому что их поддержка это уже не минимальный код.
Продумать и написать один раз максимально расширяемый код, а не исправлять каждый раз имеющийся после каждого небольшого изменения бизнес-логики и является в моем понимании максимально расширяемым кодом, написанным по минимуму, так как в долгосрочной перспективе хорошо расширяемый код освобождает от необходимости его переписывать.
А что значит тогда максимально расширяемый код, написанный по максимуму?
Например описанное здесь
habr.com/post/422679/#comment_19091403
или написание функционала, который уже есть в существующих библиотеках, а возможно даже в проекте.
habr.com/post/422679/#comment_19091403
или написание функционала, который уже есть в существующих библиотеках, а возможно даже в проекте.
О да, на предыдущем месте работы начальник был именно таким. Добавление дополнительного условия в функцию требовало создания отдельного «сервиса» с функцией с тем же именем, из которой вызывалась бы функция изначального класса, на результат накладывалось бы условие, а в код, откуда вызывается функция, один из этих классов — с условием или без — передавался бы через депенденси инджекшн. Это все безмерно меня удивляло на фоне того, что механизмы, которые реально требовали оптимизации, не оптимизировались под предлогом того, что у нас нет на это времени и ресурсов. Понятно, что после испытательного срока я оттуда ушел, поскольку никакого понимания не было.
Прежде всего тут видна непоследовательность в действиях. Если есть цепочка из пяти шаблонов, а требуется шестое изменение, то нужно или подвинуть один из пяти шаблонов по цепочке, или создать шестой шаблон в ней или другом месте, если к цепочке требуемое изменение никак не относится.
Часто бывает, что применени шаблонов ускоряет разработку, даже если фактического переиспользования кода нет и проект не развивается в том направлении, под которые заточены использованные шаблоны. Просто меньше приходится думать, пускай и больше кода писать.
То есть конкретные шаблоны предназначены для решения каких-то конкретных проблем способом, дающим какие-то «побочные» плюсы не важные здесь и сейчас. Можно решить эти же проблемы кучей других способов, которые могут быть эффективней по размеру кода, потребляемым ресурсам и т. п. в данных случаях, но проще применить шаблон, поскольку его код, как говорится, из под пальцев сам выскакивает, а над специфичным кодом думать надо, пускай и код с шаблонами будет более сложным формально, да и субъективно для человека незнакомого с данным шаблоном.
То есть конкретные шаблоны предназначены для решения каких-то конкретных проблем способом, дающим какие-то «побочные» плюсы не важные здесь и сейчас. Можно решить эти же проблемы кучей других способов, которые могут быть эффективней по размеру кода, потребляемым ресурсам и т. п. в данных случаях, но проще применить шаблон, поскольку его код, как говорится, из под пальцев сам выскакивает, а над специфичным кодом думать надо, пускай и код с шаблонами будет более сложным формально, да и субъективно для человека незнакомого с данным шаблоном.
Первая часть — пересказ картинки программист_и_качели.жпг.
Вторая часть с первой плохо связана. В ней про то, что для зарабатывания денег можно и не упарываться в качество продукта. И это нехорошо, хотя многие так делают.
к нескольким письмам, которые разрушают жизнь бывшего сотрудника и заканчиваются странным самоубийством.
странная отсылка, Алейников жив вроде?
Sign up to leave a comment.
Мнимые проблемы — причина плохого софта