Comments 124
Я бы к мифам еще отнес меру производительности в SLOC.
Если речь о заурядных корпоративных приложениях, то SLOC является не таким уж плохим показателем. Его можно использовать для грубой оценки (велась ли работа), однако нельзя говорить об этом программистам. Кроме того, прежде чем применять SLOG, нужно смотреть на качество архитектуры, качество кода (применение copy/paste, без труда, может увеличить SLOC на порядок).
Если же речь о научно-сложных приложениях, где результат долгих исследований выливается в код, то SLOG не применим. Там и одна строчка кода может миллионы стоить.
Для небольших проектов SLOC около 80-100 в день. Для более крупных (более 10 тыс. строк) — около 50 в день.
Если же речь о научно-сложных приложениях, где результат долгих исследований выливается в код, то SLOG не применим. Там и одна строчка кода может миллионы стоить.
Для небольших проектов SLOC около 80-100 в день. Для более крупных (более 10 тыс. строк) — около 50 в день.
UFO just landed and posted this here
Над одной строкой может быть проведена исследовательская работа на многие часы, в ходе которой писалось множество тестов.
UFO just landed and posted this here
Ничего существенного строка может не представлять постфактум. Скажем, приведение к целому или булеву объекта некоего класса. Но вот выяснение нюансов этого приведения в зависимости от различных его состояний и проверки что это таки именно то, что нужно может занять не один час.
UFO just landed and posted this here
То есть провести это исследование сам?
UFO just landed and posted this here
Что значит «не знает что делали»? Была поставлена задача и она была решена одной строчкой. Максимум, на что компания имеет право, так решить соответствует ли потраченное на строчку время занимаемой сотрудникам должности.
UFO just landed and posted this here
В достаточно наукоёмкой задаче у него может не хватить знаний, чтобы оценить каждое конкретное решение. Ему остаётся только доверять подчинённому — но тогда и никакие SLOC не нужны.
UFO just landed and posted this here
Пример (первый, пришедший в голову). Проект с элементами компьютерного зрения. Стояла задача уменьшить число ложных срабатываний некоторого алгоритма распознавания. Разработчик провёл исследование: собрал статистику разных случаев, проанализировал промежуточные результаты алгоритма, нашел несколько факторов, определённое соотношение которых уменьшает вероятность ложного срабатывания в 5 раз, а вероятность ложного отрицательного результата — на 1%. Реализация критерия заняла одну строчку, время работы над задачей — 2 недели. О чём может говорить «факт такой задачи»? Она была, о ней знали, вот решение.
Вопрос, который меня в этой ситуации интересует гораздо больше — какой комментарий писать к этой строчке???
Вопрос, который меня в этой ситуации интересует гораздо больше — какой комментарий писать к этой строчке???
UFO just landed and posted this here
К этой строчке надо написать комментарий:
Для получения данного критерия было проведено статистическое исследование, суть и результаты которого описаны в файле stat_analysis.txt
Для получения данного критерия было проведено статистическое исследование, суть и результаты которого описаны в файле stat_analysis.txt
Закоммитить свои тесты и результаты в отдельную веточку, не относящуюся к собственно сборке. И повесить на это ссылку. Потом, когда в веточке наберется достаточно материала, сделать из этого статью, издать, получить репутационный профит для себя и для организации.
«потраченное на строчку» или «потраченное на задачу»?
Эм, есть такая басня, не басня, притча, не притча про «знать, где ударить». Гуглится. Рекомендую.
SLOC — не показатель, особенно если дело касается интеграции со сторонними библиотеками/протоколами, работы с большим спектром устройств, отладки в поисках трудновоспроизводимых багов, мультипоточности, борьбы с утечками памяти, рефакторинга ключевых функций/классов,…
Ничего серьезного, правда? Это если не говорить про архитектуру и процессы, там все очень спорно.
Я обычно на подобные заявления предлагаю попробовать попереводить и почитать переводные стихи, и сравнить количество затраченных усилий и, собственно, объем результата. Просто из любопытства.
SLOC — не показатель, особенно если дело касается интеграции со сторонними библиотеками/протоколами, работы с большим спектром устройств, отладки в поисках трудновоспроизводимых багов, мультипоточности, борьбы с утечками памяти, рефакторинга ключевых функций/классов,…
Ничего серьезного, правда? Это если не говорить про архитектуру и процессы, там все очень спорно.
Я обычно на подобные заявления предлагаю попробовать попереводить и почитать переводные стихи, и сравнить количество затраченных усилий и, собственно, объем результата. Просто из любопытства.
Тесты должны остаться в репозиториях. А их результаты — в лабораторных журналах.
Ну, невозможно совсем отказаться от идеи ее измерять. Со всякими поправочными коэффициентами, учетом размера проекта, области изменений и архивных данных компании LOC более или менее работают.
Локально при стабильных условиях — тоже. Например, для себя на типовом проекте я достаточно хорошо могу определять с помощью них общую картину и делать какие-то прогнозы.
Локально при стабильных условиях — тоже. Например, для себя на типовом проекте я достаточно хорошо могу определять с помощью них общую картину и делать какие-то прогнозы.
Дефектность продукта в bugs/KSLOC туда же, кстати говоря.
Проблема в том, что оценивать можно только ремесленнический труд. Скажем, один горшечник в день делает один кувшин, другой — два. Второй должен зарабатывать вдвое больше — это очевидно всем.
А какой художник лучше? Тот, что пишет две картины в неделю? Или тот, у которого на каждую уходит по нескольку лет?
Проблема в том, что в работе каждого программиста есть как ремесленничество, так и творчество. В крупных проектах, как правило, творческую часть отдают старшим разработчикам, а ремесло — новичкам. Поэтому оценить работу новичка опытный работник может просто глянув, что тот написал и сколько он этого написал.
Но в инновационных проектах порой пять-десять строк кода могут реализовывать алгоритм, над которым автор думал месяц. Цена этих строчек — половина цены всего проекта. Как улыбка Джоконды — половина популярности картины. И тут — не оценишь. За примерами далеко ходить не надо. По рассказам разработчиков движок Starcraft (первой, разумеется) был почти целиком написан, кажется, за месяц одним человеком. Потом его доводили, допиливали и рисовали картинки еще несколько месяцев. У них там был аврал жуткий. Так вот — этот человек произвёл на свет шедевр, без преувеличения. Кто не согласен пусть бросит в меня камень. Его труд вряд ли можно оценить через SLOC.
Поэтому SLOC годится, но только в больших проектах и при условии, что вы хотите получить «среднюю температуру по больнице».
А какой художник лучше? Тот, что пишет две картины в неделю? Или тот, у которого на каждую уходит по нескольку лет?
Проблема в том, что в работе каждого программиста есть как ремесленничество, так и творчество. В крупных проектах, как правило, творческую часть отдают старшим разработчикам, а ремесло — новичкам. Поэтому оценить работу новичка опытный работник может просто глянув, что тот написал и сколько он этого написал.
Но в инновационных проектах порой пять-десять строк кода могут реализовывать алгоритм, над которым автор думал месяц. Цена этих строчек — половина цены всего проекта. Как улыбка Джоконды — половина популярности картины. И тут — не оценишь. За примерами далеко ходить не надо. По рассказам разработчиков движок Starcraft (первой, разумеется) был почти целиком написан, кажется, за месяц одним человеком. Потом его доводили, допиливали и рисовали картинки еще несколько месяцев. У них там был аврал жуткий. Так вот — этот человек произвёл на свет шедевр, без преувеличения. Кто не согласен пусть бросит в меня камень. Его труд вряд ли можно оценить через SLOC.
Поэтому SLOC годится, но только в больших проектах и при условии, что вы хотите получить «среднюю температуру по больнице».
Коллега, уточняю. Я никогда не оцениваю отдельного программиста по количеству написанного им кода. Убежден, что любые индивидуальные KPI в разработке ПО не применимы. В моем посте речь идет о необходимости сбора статистики по командам. И она очень полезна.
Так я же и сказал — если вас устраивает «средняя температура по больнице». Проблема в том, что при оценке проекта согласно подобным статистическим подходам мы легко (и часто, по моему опыту) получаем кучу людей, которые почти ничего не делают но усердно едят за счет проекта, а проект к светлому будущему тянут 5 крутых трудоголиков, которые бы справились и без остальных. Они и делают статистику, затрачивая титанические усилия, масштаб которых они сами не осознают, ибо трудоголики.
И кстати, у некоторых разработчиков, активно (и очень успешно) занимающихся рефакторингом кода, показатель SLOC может быть меньше нуля. Это так, для смеха.
Лучше бы кто-нибудь придумал критерий оценки интеллектуальных усилий в проект… но это, видимо, увы, закон природы. Творчество нельзя оценить объективно.
И кстати, у некоторых разработчиков, активно (и очень успешно) занимающихся рефакторингом кода, показатель SLOC может быть меньше нуля. Это так, для смеха.
Лучше бы кто-нибудь придумал критерий оценки интеллектуальных усилий в проект… но это, видимо, увы, закон природы. Творчество нельзя оценить объективно.
И кстати, у некоторых разработчиков, активно (и очень успешно) занимающихся рефакторингом кода, показатель SLOC может быть меньше нуля. Это так, для смеха.
Действительно. У меня план на ближайшую неделю — примерно -4000 SLOC (реализовать остатки старой реализации модуля в новой, а старую выкинуть). Хорошо, что у нас строки не считают :)
Эх, у вас старый модуль, а у меня целая старая Система. В большинстве случаев, куда ни копни, почти любая доработка тянет за собой рефакторинг, ибо нет сил оставлять это ТАК. Вот с начала этой недели искоренил пару тысяч строк копипаста в рамках очередной доработки. На выходе — в 4-6 раз меньшее количество кода стало выполнять чуть большее количество задач…
Ну, метрики это отдельная большая тема. Если коротко, то мало SLOC и много SLOC — одинаково плохо. У моих команд производительность на каждого участника, включая РП, от 40 до 60 SLOC/день. Измерения, которые не попадают в данный диапазон, — повод для анализа причин.
Не знаю, может конечно у вас это каким-то образом и работает, но у меня бывает и несколько тысяч строк кода в день и 5-10 строк кода в день и это будут одинаково продуктивные дни.
Коллеги, измерять необходимо. Хотя бы для того, чтобы понимать конкурентоспособность своей команд на рынке разработки ПО.
Просто оставлю это здесь.
Производительность (минимум-максимум (среднее)) в SLOC/мес.на проекте в 100 KSLOC:
(с) С.Макконнелл, «Сколько стоит программный проект»
И еще.
Ну, а у вас с производительностью и качеством?
Просто оставлю это здесь.
Производительность (минимум-максимум (среднее)) в SLOC/мес.на проекте в 100 KSLOC:
- 300-7000 (800) интранет.
- 200-7000 (600) бизнес.
- 100-2000 (300) Интернет.
- 50-600 (100) системное ПО, телеком.
- 20-300 (50) системы реального времени
(с) С.Макконнелл, «Сколько стоит программный проект»
И еще.
Ну, а у вас с производительностью и качеством?
Ну вот конкурентоспособность-то оценить, думаю, не очень сложно. Надо просто выпустить продукт и поглядеть, окупился ли он. Если окупился, значит мы конкурентоспособны. Я не прав?
А если надо срочно оценить конкурентоспособность в процессе разработки продукта, значит мы взялись делать слишком крупный продукт.
А если надо срочно оценить конкурентоспособность в процессе разработки продукта, значит мы взялись делать слишком крупный продукт.
SLOC имеет хоть какой-то смысл если известно сколько строк необходимо для реализации проекта на выбранном языке в данном окружении.
Вы можете оценить по спецификации сколько строк будет в проекте? Если да, то с какой точностью?
Вы можете оценить по спецификации сколько строк будет в проекте? Если да, то с какой точностью?
Да. Могу. Выглядит это примерно так. Все фичи делятся на три класса: простые, средние и сложные.
А далее оцениваем суммарное количество строк в проекте по методу PERT.
Относительная погрешность оценки суммарного количества получается, как правило, приемлемой.
- Простая: один или несколько методов — от 40 до 200 SLOC.
- Средняя: один или несколько классов — от 200 до 1000 SLOC.
- Сложная: пакет — от 1000 до 2000 SLOC.
А далее оцениваем суммарное количество строк в проекте по методу PERT.
Относительная погрешность оценки суммарного количества получается, как правило, приемлемой.
Разработка «сложной» фичи на 2000 строк может занять один день т.к. я найду эту фичу готовую на другом языке и просто втупую перепишу её на нужный.
А фикс бага в простой фиче, занимающий 1 строку кода, может занять дня три, потому что баг оказывается был вовсе не в этой фиче, а в другой, и не в фиче, и не баг и вообще проблема была в фреймворке.
В среднем это может быть и работает, но это как средняя температура по больнице. Как считать например поиск готовых решений? Я потратил на это пол дня, написал 2 строки кода, но в результате все работает, потому что я нашел и адаптировал готовое решение которое полностью удовлетворяет требованиям.
Можно десятки, как минимум, примеров найти, где SLOC считать совершенно бесполезно на мой взгляд.
А фикс бага в простой фиче, занимающий 1 строку кода, может занять дня три, потому что баг оказывается был вовсе не в этой фиче, а в другой, и не в фиче, и не баг и вообще проблема была в фреймворке.
В среднем это может быть и работает, но это как средняя температура по больнице. Как считать например поиск готовых решений? Я потратил на это пол дня, написал 2 строки кода, но в результате все работает, потому что я нашел и адаптировал готовое решение которое полностью удовлетворяет требованиям.
Можно десятки, как минимум, примеров найти, где SLOC считать совершенно бесполезно на мой взгляд.
Их не просто бесполезно считать, их как мне кажется, вредно считать, индусы, которые похоже по этой системе работают, по пять раз копипастят один и тот же код, отличающийся одной константой, которую можно передать как параметр, сколько раз уже на такой код натыкался. И тут даже не скажешь, что они тупые, они просто обманывают нелепую систему оценок.
Вы этой статьей сводите в нуль усилия евангелистов всяких tdd, scrum, ооп, строгой типизации, и прочих сект.
Кстати, эти евангелисты очень любят постить различную инфографику, где показывается процент успешно завершенных проектов при использовании определенной методологии.
А причем тут строгая типизация и ООП? Это все равно что спорить об том какой гаечный ключ лучше — трещетка, вороток, разводной или классический. Сила не в инструментах и методологии, а в том как их правильно выбрать и уметь ими пользоватся.
Я не знал «сильных» людей которые бы поддерживали waterfall. Все люди, о которых я был высокого мнения в технологическом и «будет сделано» вопросе, были за agile так или иначе.
Это статья вместе с Коуберном и моим опытом говорит не об ненужности методологий — а о том, что здравый смысл должен превалировать над инструментом.методологией. Если, конечно, вы хотите сделать успешный проект.
а мой опыт вместе с тем же Коуберном говорит, что, когда говорят «что здравый смысл должен превалировать над инструментом.методологией», то на практике часто просто забивают болт на методологии в принципе и всё скатывается к «мы что-то делаем, если надо, то останемся до ночи и в субботу». А Коуберн хочет сказать лишь о том, что их использоваться ОБЯЗАТЕЛЬНО НУЖНО, просто следует правильно выбрать waterfall или scrum. И не играть в скрам-покер, например, где это не нужно (двоем) или не делать стендап митинги раз в день, если это не удобно, но сделать их раз в 2 дня, например.
Но почему-то всех, кто в реальности мне заявляет что «нужно думать своей головой» нефига не овладели нормально ни одной методологией, для начала, чтобы потом их оптимизировать. Максимум сходили на тренинг, а то и просто на хабре в комментах прочли
Но почему-то всех, кто в реальности мне заявляет что «нужно думать своей головой» нефига не овладели нормально ни одной методологией, для начала, чтобы потом их оптимизировать. Максимум сходили на тренинг, а то и просто на хабре в комментах прочли
Кстати, насчет «сект» и их эффективности. Только мне этот миф никогда не был удивителен? Как-то всегда ощущалось, что лучшая система разработки — это «мужики договорились, как делать — мужики сделали как договорились»?
А вводить любую систему «по книжке» — в лучшем случае нервировать людей, в худшем — вредить их эффективности.
Но, кстати, думаю надо особо заметить, что этот «миф» имеет пределы применимости. Скажем, никто не сомневается, что такой инструмент, как система контроля версий повышает эффективность разработки?
Таким образом вместо
Можно написать:
Проблемы разработки ПО можно решить использованием полезных инструментов и стремления отдельных работников к всеобщему консенсусу. И это уже не будет такой уж миф.
А вводить любую систему «по книжке» — в лучшем случае нервировать людей, в худшем — вредить их эффективности.
Но, кстати, думаю надо особо заметить, что этот «миф» имеет пределы применимости. Скажем, никто не сомневается, что такой инструмент, как система контроля версий повышает эффективность разработки?
Таким образом вместо
Миф #2. Проблемы разработки ПО можно решить при помощи инструментов и процессов
Применение новых инструментов снижают производительность, но если повезет, может ее повысить на 2-20%
Можно написать:
Проблемы разработки ПО можно решить использованием полезных инструментов и стремления отдельных работников к всеобщему консенсусу. И это уже не будет такой уж миф.
Кстати, насчет «сект» и их эффективности. Только мне этот миф никогда не был удивителен? Как-то всегда ощущалось, что лучшая система разработки — это «мужики договорились, как делать — мужики сделали как договорились»?
Ставлю плюс. Жизнь привела к такому же выводу. Главное, чтобы «мужики» были правильные!
Вы следуете точно по пути первобытных культур: разрушая старые мифы и выстраивая из их кусков новые.
Почему первобытных? Это путь любых культур. Мифы постоянно разрушаются и создаются новые.
Социологи, например, часто используют понятие «социальный миф». Возьмём например «средний класс». Это социальный миф нового времени.
Надо понимать, что миф — это не заведомая ложь, и даже не сказка. Он просто представляет собой схему, которая объясняет нам какую-то часть жизни.
Социологи, например, часто используют понятие «социальный миф». Возьмём например «средний класс». Это социальный миф нового времени.
Надо понимать, что миф — это не заведомая ложь, и даже не сказка. Он просто представляет собой схему, которая объясняет нам какую-то часть жизни.
Мифы – это попытки осмысления картины окружающего мира, присущие первобытной культуре.
Ага, что не реклама то миф. Или покрась волосы — оплодотворит красавец, или побрызгайся этим — бабы дают безотказно. Это нам присуще, средние века называть средними. Мы то не знаем где сами.
Вы серьезно измеряете SLOC? Я-то думал, это осталось только в анегдотах про програмистов из Индии.
Как вообще сложность функциональности относится к количествам строчек кода? Может я разбалован всяким там аджайлом, но мне кажется что задачи измеряются временем решения, а не строчками кода. Если только у вас не контора по говносайтам, то программисты в основном обдумывают решение проблемы, а не набивают код.
Если коротко, то мало SLOC и много SLOC — одинаково плохо. У моих команд производительность на каждого участника, включая РП, от 40 до 60 SLOC/день. Измерения, которые не попадают в данный диапазон, — повод для анализа причин.
Как вообще сложность функциональности относится к количествам строчек кода? Может я разбалован всяким там аджайлом, но мне кажется что задачи измеряются временем решения, а не строчками кода. Если только у вас не контора по говносайтам, то программисты в основном обдумывают решение проблемы, а не набивают код.
Ну, с мифами понятно. А факты где? В статье видны только тезисы и антитезисы.
Не то, что я согласен с одними или другими, но покоробило странное использование слова «факт».
Не то, что я согласен с одними или другими, но покоробило странное использование слова «факт».
Наиболее эффективно программисты работают без жестких сроков. Сверхурочные и авралы снижают общую производительность.
Если мне не говорят КОГДА от меня ожидают результат, или хотябы отчет о проделанной работе — мне кажется что заказчику/начальнику пофиг на результат. Мне нравится чувствовать определенное давление.
в моём случае так — меня спрашивают «чо когда?» я говорю — вот мне надо неделю, потому пишу две, шеф говорит на это — «ок, я записал месяц»
Ага, но еще есть и избитый закон Паркинсона. Когда знаешь что ты делаешь «не фигню» и надо результат пораньше — работаешь лучше.
Девять беременных женщин не родят ребенка за месяц. Добавление людей в отстающий проект только увеличит отставание
Это выражение мне кажется спорным, ведь девять женщин могут родить меньше чем за год девять детей, в то время как одной на это понадобится около девяти лет. Есть минимальный срок, да, но зависимость прямая в этом случае.
Помню спорили мы с архитектором, столько стоит изменить 5 байт.
Задача конвертации между двумя враждующими PDL на лету — по архитектуре все идеально, тесты выполняются, код причесан и опрятен, а на выходе трэш — неделю программист искал баг, исправление заняло 5 байт. Заплатили ему по 4 000 рублей за байт. Оно того стоило.
И как тут говорить о SLOC?
Задача конвертации между двумя враждующими PDL на лету — по архитектуре все идеально, тесты выполняются, код причесан и опрятен, а на выходе трэш — неделю программист искал баг, исправление заняло 5 байт. Заплатили ему по 4 000 рублей за байт. Оно того стоило.
И как тут говорить о SLOC?
И Брукс, и Боэм — седовласые 80-летние деды. Конечно, учитывая их возраст, опыт в IT у них огромный. Но есть мнение, что их знания и исследования несколько устарели и не вполне соответствуют современным реалиям.
Хотелось бы более современных исследований и фактов.
Хотелось бы более современных исследований и фактов.
«Дедов» от программирования есть сотни тысяч. А Брукса и Боэма стоит помнить потому, что они писали о той специфике нашей отрасли, которая не подвластна времени.
Сколько книг написано и будет написано… основной сутью всё-равно остаётся, что во главе угла стоит человеческий фактор (peopleware), а инструменты/методологии вторичны.
Я, вот, пытаюсь представить, насколько бы медленее выполнял свою задачу, если бы писал все в блокноте, а не в IDE. Насколько сложнее было бы рефакторить, если бы язык был не строго типизированный… Я уже не говорю о таких технологиях как современные СУБД.
Неужели это дает лишь 20% прирост в скорости?
Неужели это дает лишь 20% прирост в скорости?
По моим оценкам хороший программист 80% рабочего времен работает головой. И только 20% руками. Поэтому IDE или Notepad — это вопрос 20% не более. Видел программистов, которые думают руками при помощи IDE. Это были вчерашние студенты. Но это тупик.
По моим оценкам хороший программист 80% рабочего времен работает головой. И только 20% руками.
Если программа наукоемкая или алгоритмически сложная — то и 99% может думать головой, лишь 1 % руками. Не спорю. Может вам повезло работать в такой области.
Но для корпоративных приложений 20% руками сомнительно. Это как, из 8-ми часового рабочего дня лишь 1,6 часов за компьютером сидеть? Или из 16 часов (кроме сна) все время думать над программой, и лишь 3,2 часа кодить? Или и сон включаем во время обдумывания?
Все таки написание кода, зачастую, отнимает 50% времени и более. А если не будет современных инструментов — то кодирование будет занимать 99% времени. Далеко ходить не нужно — достаточно забрать у программиста СУБД. Свою простую СУБД он будет воять очень долго, потом очень долго отлаживать и ловить баги.
Давай посчитаем. Предположим, что хороший программист пишет в среднем 200 SLOC. Средняя длина строки — 40 знаков. Итого, 8000 знаков. Скорость набора у хорошего программиста 100 знаков/мин. Делим одно на другое — получаем 80 мин. = 1,33 часа. Остальные 6,67 часов работает головой, даже если сидит за клавиатурой.
Отсюда и получается 80%.
Отсюда и получается 80%.
Делим одно на другое — получаем 80 мин. = 1,33 часа.
Вы забыли про отладку программы, которая целиком и полностью завязана на инструмент (дебагер).
Сугубо, ИМХО. Отладка = модульное тестирование. Для этого нужна продуманная система тестов. Если каждую свою программу отлаживать в дебагере, производительность упадет в разы. За 25 лет активного программирования использовал дебагер в единицах случаев. Как правило, тогда, когда была ошибка в чужом коде — надо было придумать как ее обойти.
Отладка = модульное тестирование.
Подобное приравнивание некорреткно. Это совершенно ортогональные вещи.
Никто не требует заниматься отладкой при каждом дуновении ветра.
Но существуют баги, которые возможно отловить только при исполнении приложения под отладчиком, и тут несовершенство отладчика может замедлить ход отладки в разы.
Не все пользуются дебаггерами. Тесты, логирование и т. п.
для корпоративных приложений 20% руками сомнительно
Все таки написание кода, зачастую, отнимает 50% времени и более
Более 10 лет занимаюсь корпоративными приложениями (Java Enterprise), боюсь даже представить себе 4 часа в день чистого кодинга. Первые годы, пожалуй, соотношение работы головой/руками стремилось к такому показателю, но чем ближе оно к нему было, тем больше к такому кодингу просился префикс «г»…
программист 80% рабочего времен работает головой. И только 20% руками. Поэтому IDE или Notepad — это вопрос 20% не более.
Если IDE даёт выигрыш по сравнению с Notepad хотя бы в 6 раз, то соотношение 80/20 (с IDE) превращается в 40/60 (с Notepad), а время работы увеличивается вдвое… Каким бы коротким ни был участок, на котором мы можем проиграть, итоговый проигрыш может оказаться сколь угодно большим. А кроме того, Notepad требует больше ресурсов мозга, чем IDE, так что на «работу головой» остаётся меньше не только времени, но и места для хранения контекста задачи.
И каким образом делалась оценка, интересно?
По факту, существует и другая оценка: программист чаще читает код, нежели его пишет. И процесс придумывания нового кода зачастую связан с чтением кода прочих компонент, с изучением возможных способов интеграции своего кода со старым.
И в этом смысле, если вы используете IDE, то вы затрачиваете минимум усилий для поиска, навигации по коду.
Кроме того, при использовании IDE вам реже требуется перепроверять сигнатуры и имена используемых сущностей, в то время, как в каком-нибудь блокноте вам приходится отрываться от процесса, чтобы перепроверить правильность имен, порядка аргументов и прочего.
Является ли это 20%? Сильно сомневаюсь.
Ну а если вас не устраивает пример с IDE, то другой пример: попробуйте поотлаживать приложения с помощью отладочного вывода и карандаша, а потом то же самое провести, используя специализированные отладочные программы или встроенные средства в IDE.
Кстати, совершенно субъективное высказывание. Также могу привести примеры таких программистов. Сказать, что они в тупике, язык не повернется.
По факту, существует и другая оценка: программист чаще читает код, нежели его пишет. И процесс придумывания нового кода зачастую связан с чтением кода прочих компонент, с изучением возможных способов интеграции своего кода со старым.
И в этом смысле, если вы используете IDE, то вы затрачиваете минимум усилий для поиска, навигации по коду.
Кроме того, при использовании IDE вам реже требуется перепроверять сигнатуры и имена используемых сущностей, в то время, как в каком-нибудь блокноте вам приходится отрываться от процесса, чтобы перепроверить правильность имен, порядка аргументов и прочего.
Является ли это 20%? Сильно сомневаюсь.
Ну а если вас не устраивает пример с IDE, то другой пример: попробуйте поотлаживать приложения с помощью отладочного вывода и карандаша, а потом то же самое провести, используя специализированные отладочные программы или встроенные средства в IDE.
Это были вчерашние студенты. Но это тупик.
Кстати, совершенно субъективное высказывание. Также могу привести примеры таких программистов. Сказать, что они в тупике, язык не повернется.
Насколько сложнее было бы рефакторить, если бы язык был не строго типизированный…
Насколько? Чем строгая типизация помогает рефакторингу?
Насколько? Чем строгая типизация помогает рефакторингу?
В классе было одно поле, позже понадобилось разбить его на 2. Со строгой типизацией проблема решается просто: запустил компилятор и увидел все места, где используется это поле. А без типизации вам нужно по каждому такому случаю писать тесты.
Запустил IDE и нажал Find usage..., если просто поиск типа grep не устраивает и нужен статический анализ. И совсем непонятно причем тут компилятор. Python например язык со строгой (вернее сильной, как и многие мэйнстримовые языки, со строгой вроде нет в мэйнстриме) типизацией, но «референсный» транслятор — интерпретатор.
если просто поиск типа grep не устраивает и нужен статический анализ
Поиск не поможет. Полей с таким же названием в других классах может быть много.
Запустил IDE и нажал Find usage...
Не подскажите IDE для JavaScript, в которой есть «Find usage»?
Не подскажите IDE для JavaScript, в которой есть «Find usage»?
PhpStorm/WebStorm справляется с этой задачей очень даже неплохо.
PhpStorm/WebStorm справляется с этой задачей очень даже неплохо.
Вообще динамические языки не подразумевают возможность поиска несуществующих полей в классе, т.к. само поле может быть добавлено в процессе исполнения программы.
Но JB, по всей видимости, опять сделали интеллектуальную систему, которая пытается это делать. Однако это не классика.
Может быть добавлено в рантайме, но часто описывается «статически». Плюс у JB хорошая поддержка различных *doc аннотаций — даже если метод вызывается «магически», я могу его описать в комментариях и IDE не будет ругаться на обращение к несуществующему методу.
Есть, конечно, ситуации, когда статический анлиз не справляется с динамическими языками — когда, например, имя метода собирается посимвольно — но в целом, если пишешь не write only код, то такими возможностями почти не пользуешься.
Есть, конечно, ситуации, когда статический анлиз не справляется с динамическими языками — когда, например, имя метода собирается посимвольно — но в целом, если пишешь не write only код, то такими возможностями почти не пользуешься.
Нравится мне как относятся к программистам современные управленцы. Соревнуются между собой кто лучше их понимает. Поди скоро книги начнут выходить: «Как ухаживать за программистом», «Что делать если ваш программист несчастен», «Программист: руководство для чайников»…
Да, уже лет тридцать пишут такие книги. Одна из первых Шнейдерман, «Психология программирования». Самая известная Демарко и Листер «Peopleware» где-то середина 90-х.
«Как пасти котов»
Ага, а dev офисы IT-компаний превращают в детские садики для взрослых, смотреть тошно.
Известно, что программисты, как дети: любят сиськи и сладкое.
Если программист не женского полу
и пиво. такой распространенный миф, что все программисты любят пиво.
и еще одна девочка мне доказывала, что все программисты должны любить аниме. аргументы не привела.
и еще одна девочка мне доказывала, что все программисты должны любить аниме. аргументы не привела.
Ну, возможно она не так далека от истины. Среди моих друзей-программистов, как минимум противников аниме точно нет: аниме им либо нравится, либо они его просто не смотрели толком.
А у аниме бывают противники (за исключением борцов за нравственность)?
Бывают. Но эти люди, в основном, понятия не имеют об аниме, кроме фразы «аниме говно».
Ну, помимо радикальных противников, описанных AraneusAdoro, есть просто люди, которым аниме не нравится из-за личного вкуса или предубеждений.
Ну, мне не нравится, но я не противник, пока оно меня не касается. Бороться с аниме я буду только в виде «ты эту свою фигню уже два часа смотришь, дай я нормальное кино посмотрю» — ровно так же как с, например, бразильскими или аргентинскими мыльными операми. Или с фильмами ужасов (без значащей фантастической составляющей).
Да тут разброс предпочтений очень широкий в разных сферах.
Я вот, например, ни аниме не люблю, ни пиво не употребляю.
Я вот, например, ни аниме не люблю, ни пиво не употребляю.
Качество архитектуры. Предлагаю читателям самим указать единицу измерения, в качестве упражнения.
1 Костыль.
Улыбнуло. ИМХО, возможно. Осталось только определить понятие «костыль».
Однако, я измеряю по другому. Как? Отпишусь позже.
Однако, я измеряю по другому. Как? Отпишусь позже.
Одни из критериев — грепнуть по проекту //(TODO|FIXME) а также любое нарушение принципов архитектуры(которые должны оговариваться отдельно от исходного кода)
Количество if операций в проекте.
Тернарный или подобный условный оператор считается за if ?
А вообще, не очень критерий, условие условию рознь.
Мне кажется это можно пообсуждать и добавить туда и некоторые switch/case. Я, по сути, придумал это после прочтения вопроса и как мне кажется это может даже работать :). Если задуматься, то когда ты начинаешь писать много костылей для той или иной ситуации — это все условия.Или просто начинаешь писать разделение функций на основе условий — это все признаки неудобной архитектуры. В удобной архитектуре тебе обычно нужно ~1 условие то бы выбрать нужный класс реализации / подставить новую стратегию. Можно ради интереса попробовать посчитать как нибудь количество (if / switch-case) / (LOC).
38 попугаев.
Сергей, приветствую!
Раз вы не вставили в пост видео с Вашего доклада на CodeFreeze по изложенной теме, то пожалуй, как один из организаторов, это сделаю я в этом комментарии :)
P.S.: может, вставите видео в пост?
Раз вы не вставили в пост видео с Вашего доклада на CodeFreeze по изложенной теме, то пожалуй, как один из организаторов, это сделаю я в этом комментарии :)
P.S.: может, вставите видео в пост?
Публикую ответ на вопрос: как количественно померить качество архитектуры.
ИМХО, о качестве архитектуры свидетельствует время, затрачиваемое программистами на мелкие доработки и исправление багов. Мои ожидания: время, которое на это тратят программисты, в среднем не должно превышать 4 часа. Если больше, то либо сильная связанность, либо размазанность прикладной логики. Как-то, так.
ИМХО, о качестве архитектуры свидетельствует время, затрачиваемое программистами на мелкие доработки и исправление багов. Мои ожидания: время, которое на это тратят программисты, в среднем не должно превышать 4 часа. Если больше, то либо сильная связанность, либо размазанность прикладной логики. Как-то, так.
«Миф #1. Разработку ПО можно ускорить» — это не миф, это факт, ее можно ускорить, миф лишь то, что увеличение числа программистов всегда положительно и линейно сказывается на скорости и т.п.
"«Большинство выдающихся программных продуктов создано студентами «в гараже».» — а вот это миф.
Про неточности и обобшения о SLOC и т.п. я вообще молчу, как-то неаккуратненько для развенчания мифов и срыва покровов.
"«Большинство выдающихся программных продуктов создано студентами «в гараже».» — а вот это миф.
Про неточности и обобшения о SLOC и т.п. я вообще молчу, как-то неаккуратненько для развенчания мифов и срыва покровов.
«Миф #1. Разработку ПО можно ускорить» — это не миф, это факт, ее можно ускорить, миф лишь то, что увеличение числа программистов всегда положительно и линейно сказывается на скорости и т.п.
Пожалуйста, примеры в студию.
«Большинство выдающихся программных продуктов создано студентами «в гараже».» — а вот это миф.
Вот факты.
25 августа 1991 г. финский студент Линус Торвальдс разместил в Internet скромное сообщение о том, что он разработал собственную ОС.
Поисковик Google был основан двумя аспирантами Стэндфордского университета Лари Пейджем (Larry Page) и Сергеем Брином (Sergey Brin),
Facebook была основана Марком Цукербергом в феврале 2004 года, сначала в качестве эксклюзивной сети для студентов Гарварда.
Не убедительно?
Например разобрали задачи и средненькому разработчику досталась сложная часть, а той самой звезде, что в 28 раз быстрее может фигачить досталась рутина, в подобной ситуации просто поменяв их местами можно ускорить разработку проекта в целом в 10+ раз. Подобных примеров может быть миллион, всегда найдется способ ускорить разработку при внимательном рассмотрении того или иного проекта.
Пара исключений не значит, что из них можно выводить правило, говоря о большинстве ПО. Да и никакие это не исключения по большому счету, Google такой каким его знаем не благодаря тому, что Пейдж с Брином начинали на пару, а вопреки этому, если бы они не смогли вывести одиночную работу на командный уровень.
Особенно опасны такие мифы, когда они написанны на русском языке. В России полно головастых одиночек, однако не особо видно выдаюшихся программных продуктов, именно потому что гаража маловато, без инженерного, системного подхода и т.п.
Пара исключений не значит, что из них можно выводить правило, говоря о большинстве ПО. Да и никакие это не исключения по большому счету, Google такой каким его знаем не благодаря тому, что Пейдж с Брином начинали на пару, а вопреки этому, если бы они не смогли вывести одиночную работу на командный уровень.
Особенно опасны такие мифы, когда они написанны на русском языке. В России полно головастых одиночек, однако не особо видно выдаюшихся программных продуктов, именно потому что гаража маловато, без инженерного, системного подхода и т.п.
Ну, вот еще пара фактов.
Опять не убедил? :)
В 1977 году молодой программист Ларри Эллисон бросил учебу в Йельском университете, чтобы начать собственный бизнес. Ларри Эллисон, в распоряжении которого тогда было всего 1200 долларов, уговорил Боба Майнера и Эда Оутса, своих бывших коллег, создать собственную компанию. [...] Так в 1977 году появилась Software Development Lab., вскоре
переименованная сначала с Relational Software Inc., а затем — в Oracle. Молодые программисты, чьи общие вложения в бизнес составили $2 тыс., начали разработку системы управления базами данных (СУБД), построенной на принципах реляционной алгебры.
Microsoft. Компания начинает свою историю с 1975 года, когда друзья-студенты Гарварда Билл Гейтс и Пол Аллен, прочитав опубликованную 1 января 1975 года в журнале «Popular Electronics (англ.)» статью о новом персональном компьютере Altair 8800, разработали для него интерпретатор языка Basic. Через месяц, 1 февраля, было подписано лицензионное соглашение с компанией Micro Instrumentation and Telemetry Systems (англ.) (MITS), производителем этого ПК, об использовании Basic в составе ПО для Altair. Свой первый год новая компания, в которой работало три человека, закончила с оборотом $16,005 тыс.
Опять не убедил? :)
Один из первых шагов Гейтса была покупка системы QDOS за $50.000 (у того парня, что сидел в гараже) и продажа ее IBM под именем MS-DOS. Опять же — умник одиночка с его поделкой не нашел применения, не увидел пути развития, а решили бизнес навыки и умение организовать впоследствии разработчиков для полноценной работы над развитием продукта.
Sign up to leave a comment.
Разработка ПО: факты против мифов