Comments 55
Эти парни любят абстракции даже больше, чем сами программисты.
Ещё они любят картинки и рисовать процессы в них. :)
Рамки задает задает фреймворк.
Алгоритмы типовые в основном.
Сидишь и из кубиков складываешь как нужно в текущей задаче.
У меня не было за всю жизнь «уникального кода» кроме костылей придуманных мною.
Даже работа с апи руцента по их протоколу это не уникальный код (а просто очень редкий случай, человек 100 подобное я думаю уже писали) им просто не делятся.
хотя пару раз в год «палка стреляет» и я пишу на проде достаточно уникальный код.
Думаю посмотреть в сторону кодовой базы опенсорса — может у них есть места для этого?
Андроид-приложение. Экран «Делать Х» (Х можно делать разными способами, в разные места, с разными ограничениями). Реализован список все полей (с нужной вспомогательной обвязкой вроде) который в принципе могут потребоваться, какие именно поля — решает сервер. Сервер трогать нельзя, совсем нельзя (потому что на нем за список полей и обработку данных с этого экрана отвечает по сути отдельный закрытый компонент). Порядок полей должен быть красивым. Сделано жестким заданием порядка в layout. Да, можно полностью руками конструировать GUI либо попробовать Jetpack Compose (а с порядком по другому решить как то). Но это переписывать достаточно много.
Для одного набора подзадач вида «делать X способом Y1..Y3» существующий порядок полей настолько сильно мешал что пришлось часть полей (вместе с логикой поддержки) задублировать (и показывать их).
Это уже не уникальный код?
А переписка всей архитектуры данного модуля на Jetpack Compose была бы написанием уникального кода? (при том что текущий вариант работает вполне хорошо а беклог и так огромный)
ты занят полезным делом, если пишешь уникальный код.
если вы пишете код, который кто-то уже написал, и есть возможность этот код использовать, то вы теряете время
Осталось научиться делать оптимальный в каждом случае выбор — "писать код, б..." или "копипастить со stackoverflow"
Мне показалось, или программистов к кодерам прировняли?
Ну, и вообще, если не подумать над архитектурой вначале, то можно сколько угодно долго писать уникальный код, который не приближает к решению задачи, а даже отдаляет от нее. Поэтому, мне лично такое определение полезной деятельности не нравится.
100 %
И в определении нужности вдруг начинают помогать всякие скрамы со стэндапами, которые многие программисты видят лишь как карго культ, типа заставляющий их работать. Скрамы — они не про программистов, а про процесс разработки продукта.
Скрамы — они не про программистов, а про процесс разработки продукта.Именно, они про то что зачастую выглядит так — давайте бросим всех программистов в одну кострюлю, сделаем суп, вдруг что-то получится.
Зачем продукт-менеджеру менеджить, лиду лидить, мастеру мастерить, аналитику аналитить. Лучше на синергию надеяться, чтобы как-нибудь само.
Да на психологию, если программист сам оценил задачу (а в большинстве случаев оценки излишне оптимистичные), то он будет пыхтеть но свою оценку выдерживать — а если что, то ему ещё и попенять за это. Всем явная выгода.
Если вы пишете уникальный код – вы заняты делом. Прям пишете, сидя за компьютером, и стуча пальцами по клавиатуре.
Если вы кодер, то да. Хотя и в этом случае мыслительные процессы в перерывах между стуком пальцами никто не отменял.
Что такое уникальный код? Уникальный в мире? Уникальный в проекте? Уникальный сегодня?
Эффективная работа — это быстрое решение задач. Быстро решать можно копи пастом из ранее выполненных задач. У типового программиста уникального кода не бывает.
В статье вы подменили то, что важно бизнесу (быстро поставлять фичи), на то, что важно вам (писать уникальный код)
«Или вообще лёг спать на работе», без этого не могу во второй половине дня продуктивно работать. На предприятии это считалось лютым косяком, даже если и в обеденный перерыв. Часто видел, народ прикрывшись монитором, спит. Из-за этого отчасти и уволился ((
Вот я неделю читал код драйвера, добавлял отладку, тестировал. В итоге решил проблему двумя строчками. Две строчки за неделю = нулевая производительность/польза. Работающее устройство = довольный клиент, новые заказы, развитие компании.
Уникальный код? 80% задач повторяются с определенной периодичностью, не нужно каждый раз форыч изобретать, чтобы выполнить задачу. Я так понимаю, что когда автору нужен новый компьютер, то он идет в магазин радиодеталей, покупает транзисторы, делает самодельную плату, распаивает всё это добро на плате, тратит огромное количество времени и в итоге получает непонятное нечто. А мог бы просто воспользоваться проверенными, оттестированными практиками — не изобретать велосипед. Моё мнение, что автор всё же любит тешить самолюбие, мол смотрите, я потратил время и написал УНИКАЛЬНЫЙ код, такого больше нет нигде, я сделяль. И вы так же делайте. Только бизнесу плевать на эту уникальность, решай больше задач за меньшие сроки (95%)
Если бы Вы работали на проекте, где количество строк измеряется сотнями тысяч и Вам нужно было бы разработать какой-то функционал, то вы бы с ходу взялись за написание кода? Хорошо, если там всё покрыто тестами и они сразу все упали, а если бы проблемы вскрылись на регрессе или, о боже, в продакшене? Насколько эффективной Вы сможете считать свою работу после такого?
Я понимаю, что можно много рассуждать о полезности той или иной методологии разработки, но подвергать сомнению необходимость стандартных процессов вроде отладки, проектирования архитектуры и анализа существующего кода по меньшей мере странно.
Я надеюсь, что Вы не станете в ближайшее время менеджером, иначе с таким подходом это приведёт к тому, что производительность на вашем проекте будет измеряться количеством написанных строк.
Уникальный код, говорите?
На клавиатуре? Какой-то упрощенный подход, кмк.
То есть, если программер калякает на листочках математические формулы, пытаясь свести вашу задачу к обычному линейному дифференциальному уравнению, он уже бездельничает? (Про других не скажу, но почему-то мне проще такие вещи делать на бумаге. Карандашом.)
Если он обсуждает с разработчиком электроники вопрос, в каком виде данные с ацп лучше передавать, он уже балду пинает?
Если он объясняет своему коллеге, как в данной ситуации будет лучше организовать структуру базы данных, (для окружающих — сидят два мужика и полтора часа квадратики на листе бумаге рисуют) он уже фигней страдает?
Если он изучает логи системы, пытаясь понять причины подвисаний...
Если он стоит в цеху у рядом с наладчиком, и пытается понять, чем неудобна текущая версия софтины, которой этот наладчик пользуется...
По моему опыту, современный инженер — разработчик софта тратит непосредственно на написание кода не так уж много времени.
Более того, если программер сидит на работе за монитором, вперившись в отладчик или колотит по клавиатуре — это еще не значит, что он действительно работает.
Верно и обратное- если он на работе отсутствует — это совсем не значит, что он бездельничает...
Даже строительный, или машиностроительный, или электронщик — основное время занимают переписка, совещания, просмотр каталогов и серфинг интернета, подбор и анализ решений, запросы цен и сроков, доказательство своих решений другим лицам, проверка соответствия госнормам, и так далее.
Если он изучает логи системы, пытаясь понять причины подвисаний...Значит он или тот кто писал систему плохо молился.
Если он стоит в цеху у рядом с наладчиком, и пытается понять, чем неудобна текущая версия софтины, которой этот наладчик пользуется...Значит он или тот кто писал софтину плохо молился.
По моему опыту, современный инженер — разработчик софта тратит непосредственно на написание кода не так уж много времени.Ну во все времена программист тратит на создание ошибок не более 10% времени. Все остальное время он эти ошибки устраняет. Причем оставшееся время рекурсивно делится в той же пропорции.
Если он объясняет своему коллеге, как в данной ситуации будет лучше организовать структуру базы данных, (для окружающих — сидят два мужика и полтора часа квадратики на листе бумаге рисуют) он уже фигней страдает?Ну с учетом того что уже овер 25 лет существуют тулзы, которые позволяют рисуя оные квадратики на мониторе параллельно и реализацию оной структуры БД получать, то делают абсолютно необходимую работу абсолютно неэффективным способом. А если эффективным — ну в общем то это и есть написание оного уникального кода.
То есть, если программер калякает на листочках математические формулы, пытаясь свести вашу задачу к обычному линейному дифференциальному уравнению, он уже бездельничает? (Про других не скажу, но почему-то мне проще такие вещи делать на бумаге. Карандашом.)Ну то что не в IDE это делать — это точно. Ну в общем то можно не на бамашке карандашиком, а на планшете распознающем рукописный ввод стилусом. Или во всяких маткадах по старинке. Оно как бы позволяет часть преобразований на комп переложить, хотя бы элементарных. Да в общем то и кота какого-никакого сгенерить они вроде как умеют, который в общем то может за основу для причесывания пойтить. Со временем это станет гораздо более совершенным. Т.е. как бы опять же процесс то ли обеспечения уникальности то ли само написание оного уникального кода.
Т.е. все о чем вы говорите — абсолютно справедливо, в случае если рассматривать это через призму существующих технологий хотя бы частичной автоматизации этих процессов, и именно как средство добиться того, чтобы код писать и отлаживать можно было только уникальный.
Верная оценка потерь в работе — ключ к продуктивности. Так все системы ровно об этом. Другое дело, что верная оценка потерь программиста — это та еще тема. На кандидатскую, а то и на нобелевку по экономике потянет. И пока нобелевского лауреата с такой темой нет каждый вынужден для себя ответы искать. А тут есть темы для рассуждения.
Думаю, что для начала надо аксиоматически принять простую истинну — потери неизбежны. Просто неизбежны. Токарь тоже теряет время на заточку инструмента. У нас мысль, прежде чем начать реализовываться, должна сформироваться. Желательно целиком и полностью. У нас есть свои методы, позволяющие сократить эти потери. То же программирование сверху вниз, то же ООП — это про это. Не надо сразу понимать весь проект — реализуй его послойно. Другое дело, что цена ошибки в каждом из слоев становится очень существенной. Потому безоговорочно доверять им тоже нельзя.
Ну и «непроизводственные потери». Нельзя знать все. Токарь тоже будет тратить некоторое время на изучение чертежа новой детали прежде чем начнет ее делать. И не сразу у него будет максимальная производительность. Так и программисту — просто жизненно необходимо время разгона. Не бывает в реальном мире бесконечного ускорения.
И это только взгляд сверху. А сколько еще слоев скрыто? Но основная идея статьи абсолютно правильна. Именно соотношение потерь к производительному времени — ключ к продуктивности. Больше того, мне кажется, что максимум продуктивности в разных сферах прораммирования будет разным. И это тоже данность, спорить с которой довольно глупо и бесполезно.
Другое дело, что цена ошибки в каждом из слоев становится очень существенной. Потому безоговорочно доверять им тоже нельзя.Вот именно поэтому важно соблюдать требование к полному и универсальному покрытию каждым классом своей зоны ответственности. Именно недостаточность в этом плане ведет к трудоемкому рефакторингу.
А вот касательно багов — чем больше компонентов более верхнего слоя используют компонент более нижнего, тем труднее в нем спрятаться багу.
macode.ru
Я не согласна, с тем что полезное — это только писать уникальный код.
Ну то есть если вы — программист-кодер и работаете по чётко поставленному ТЗ, то да, это так.
Но если вы программист-инженер, то ваша основная задача — решить проблему. А для этого уже нужно понять бизнес-процессы, обсудить с командой, порисовать у доски, взвесить за и против, написать ТЗ, написать абстракции, а само написание кода вообще можно отдать джунам.
Ну то есть если вы — программист-кодер и работаете по чётко поставленному ТЗ, то да, это так.
Что то в списках как квалификаций так и должностей таковые не наблюдаются. При этом четкое ТЗ — т.е. список требований к системе — это только отправная точка для создания постановки задачи (т.е. способа ее решения), а не как не основа для написания кода.
Но если вы программист-инженер, то ваша основная задача — решить проблему. А для этого уже нужно понять бизнес-процессы, обсудить с командой, порисовать у доски, взвесить за и против, написать ТЗ, написать абстракции,
И проделывать еще кучу всяких «глюпостей» (с точки зрения менеджера), нужных только с одной целью — экспоненциально снизить объем кода, за счет избегания его дублирования. Причем не только кода одного и того же 2+2, но и дублирования частных случаев одной и той же абстракции — т.е. описания вычисления 2+2, 2+5, 7+10 и т.д. вместо написания один раз вычисления a+b.
а само написание кода вообще можно отдать джунам.Это заблуждение сгубило уже очень много душ и хороших начинаний. Для отладки кода нужно понимать предметную область не хуже, чем тот кто осуществляет постановку задачи. При этом зачастую постановку необходимо корректировать на лету. Нельзя спроектировать все сразу до мельчайшего винтика без коррекций в процессе реализации — именно в этот момент вылазят нестыковки. А соответственно наиболее скоростной и качественный подход — разделение зон ответственности между компонентами при проектировании архитектуры, а детальную постановку на каждый отдельно взятый компонент делать непосредственно перед его реализацией.
При этом стоит помнить тот факт, что джун таки моложе, а значит заканчивал ликбез позже. А соответственно владеет более свежими и совершенными методиками анализа, и при этом они для него нативны, в отличии от сеньора, которому эти методики пришлось наращивать поверх старых, даже если он их и изобрел. Если джуну чего то и не хватает для успешного проделывания всех этих «глюпостей» — то только опыта и глубины понимания того, чему его учили в ликбезе (оно приходит годам к 40-ка). А соответственно объединяя более свежие знания толкового «желторотика» с опытом «стариков» на всех этапах, получим гораздо более эффективный как анализ так и реализацию.
Я не согласна, с тем что полезное — это только писать уникальный код.А суть всех остальных занятий именно в том чтобы обеспечить именно это — писать и самое главное отлаживать только уникальный код.
Программист должен решать задачи бизнеса, разбираться в проблеме и находить правильное решение, лучше из готового кода, который протестирован и проверен в реальных условиях большой группой людей.
То, что описано в статье — это максимум средненький мидл, точно не больше! При чем, любитель велосипедов.
P.S. Не понимая, почему лайков больше, чем дизлайков?
Что за чушь я сейчас прочитал? Вы головой ударились или что?
Если же задача требует понимания — скопировав код с гитхаба вы с большой вероятностью просто перенесёте утечку времени из одного места в другое(скорее всего вам придётся залезть внутрь и переписать всё чуть ли не с нуля, только с грудой костылей).
Но не воспринимайте это как призыв заново переписывать функции взятия БПФ.
Главная утечка времени — в плохом ТЗ.
Можно сколько угодно писать уникальный код который будет отправляться на помойку, ибо кто-то не может определиться в какую сторону мы сейчас воюем.
У меня один вопрос: вы для кого код пишете? Для компьютера или для коллег?
А дизайнеры это враги стандартизации. Желают выделеться за счёт чего-нибудь с подвывертом, а не понимают что умом надо выделяться, а не зелёными, мигающими кнопочками.
Пишите еще. У вас талант!
И статья, и комменты порадовали.
Поржал от души ;)
тайный поклонник
и аналогично — что тогда неуникальный код?
При таком подходе если условные Вася и Петя получают одинаково, то более успешным окажется тот, кто меньше работает.
Возможны и иные варианты.
Обычно один из них трудолюбив много-много работает, то бишь копипастит а потом пытается это как то заставить работать. В результате получает копейки на доширак. Ну каков результат.
А второй ужасно ленив и почти ничерта не делает, только во всю находит способы как переложить 99% своей работы на комп за счет остального 1% который он делает сам — а именно пишет уникальный универсальный код. И получает куда поболе. Ну тоже каков результат.
Написание кода — это процесс создания полезности, и его уменьшать не стоит. А вот обдумывание важно, но его уменьшать (не во вред коду) надо.
Уникальность кода — означает, что его автор потрудился, чтобы он возник. То есть автор доказал свою полезность в написании полезного кода.
Проблема, в том, что сейчас приходит время «больших батальонов».
Искусство одного программиста становиться все менее и менее значимым.
Из-за этого нужно организовывать команды и программисты становятся все более и более специализированными.
Я предлагаю такую формулировку, для программиста: ты занят полезным делом, если пишешь уникальный код
Вот уж где точно скрываются 97% от обозначенных 97% потерь
Эти парни любят абстракции даже больше, чем сами программисты.
Зачем тогда вы абстрагируетесь от самоорганизации процесса написания кода? В вашем мире существует некий сферический кодер в вакууме, который пишет уникальный код и не хочет организовывать свой процесс: оценивать свой тайминг, свою эффективность. Во времена расцвета студии Лебедева этого вполне хватало: заказчика не интересовали детали. Ему был важен результат. Сидишь, пишешь код, получаешь зарплату. Увы, сегодня такие орлы нам нафиг не нужны. Потому что результат стал измеряться не в проданных вагонах майонеза, а в полученных электронных транзакциях, в объёмах электронных покупок, в точности датчиков, отправляющих метрики через REST API и в скорости коммитов этих метрик в базу. Бизнес становится технологичным, и специально обученные писать уникальный код люди стали не нужны. Нужны программисты, способные построить свой рабочий процесс, дать оценку задаче и сопроводить её прогресс. Поэтому, после высера про то, что скрам и канбан — придумка менеджеров — статью можно не читать. Скрам и канбан — это инструменты разработчиков, и переворачиватели пингвинов, как и бухгалтеры, при виде нормального аджайл-процесса, начинают сходить с ума и орать, что они привыкли к своему грёбаному корпоративному порталу с задачами, висящими месяцами с одним и тем же статусом. А если ты будешь пытаться выжать из менеджерского звена максимум результата применением доски задач, они уже через пару часов побегут к руководству с жалобами на то, что им не нравится настоящее лицо матушки Эффективности. И во всей этой иерархии ваш сферический кодер находится ниже переворачивателя пингвинов. Со своим мнением об инструментах самоорганизации он находится где-то между пьяным сантехником и корпоративным говном, которое тот вычищает из корпоративного унитаза. Такой же бестолковый, и такой же не понимающий методов оценки производительности и сроков реального завершения процесса. Главное — писать код. Или месить говно в туалете. Суть одинаковая.
Или вот, например, 15 лет назад я мог написать за неделю 10000 строк уникального кода, и решить некоторую сложную задачу. По вашей логике, я целую неделю занимался, относительно, полезной работой. Так вот, теперь я могу эту же задачу решить за пол дня, а то и меньше, написав на порядок меньше строк скомпонованного из не уникальных частей кода. Получается, что я пол дня занимался бесполезной работой? Что вообще такое по вашему работа?
По моему, если менеджер не может определить чем занят в текущий момент программист, полезным или бесполезным занятием, то срочно нужно менять менеджера, либо нанимать того, кто непосредственно уже будет руководить программистами. Такому руководителю важно уметь без двусмысленностей поставить задачу и самому уметь её решить, либо уметь помочь более компетентному в этом вопросе программисту её решить, если у того возникнут какие-либо затруднения.
После прочтения этой статьи у меня в голове возникла картинка, ассоциирующаяся с авторами этой и той статьи, которую я указал в этом комментарии выше, которая в гугл картинках гуглится по запросу «это босс это лидер», где автора той статьи я вижу в роли лидера, а этой в роли босса.
или намертво зажат в массажном кресле
Сама возможность в кресле полежать может быть доводом для программиста работать именно в этой компании, при прочих равных.
Сама возможность в кресле полежать может быть доводом для программиста работать именно в этой компании, при прочих равных.Цена массажного кресла в пределах 5 килобаксов, при это от начинается с 600-800. Так что таки з/п которая позволяет его прикупить и лежать в нем когда угодно, будет более важным фактором чем возможность в нем полежать в офисе после работы, привязывающая его к конкретной конторе аки крепостного.
И вот теперь есть код который как-то можно запустить и он что-то делает, но что и как — не знает никто.
Зато тот парень молодец — у него потерь по времени было мало, а уникального кода — хоть отбавляй.
Людей, разбирающихся в работе программиста, можно встретить где угодно