Как стать автором
Обновить
68
0
Сергей Архипенков @craft_brother

Эксперт в управлении разработкой ПО

Отправить сообщение
«Миф #1. Разработку ПО можно ускорить» — это не миф, это факт, ее можно ускорить, миф лишь то, что увеличение числа программистов всегда положительно и линейно сказывается на скорости и т.п.


Пожалуйста, примеры в студию.

«Большинство выдающихся программных продуктов создано студентами «в гараже».» — а вот это миф.


Вот факты.

25 августа 1991 г. финский студент Линус Торвальдс разместил в Internet скромное сообщение о том, что он разработал собственную ОС.

Поисковик Google был основан двумя аспирантами Стэндфордского университета Лари Пейджем (Larry Page) и Сергеем Брином (Sergey Brin),

Facebook была основана Марком Цукербергом в феврале 2004 года, сначала в качестве эксклюзивной сети для студентов Гарварда.

Не убедительно?
Алексей, привет!
Думаю, что когда-нибудь напишу для Хабра пост об адаптивном управлении, туда и добавим это видео.
Ну, это оценивается экспертно. Новая экранная форма — крупная доработка. Добавить поле в существующую форму — мелкая. Как-то, так.
Публикую ответ на вопрос: как количественно померить качество архитектуры.
ИМХО, о качестве архитектуры свидетельствует время, затрачиваемое программистами на мелкие доработки и исправление багов. Мои ожидания: время, которое на это тратят программисты, в среднем не должно превышать 4 часа. Если больше, то либо сильная связанность, либо размазанность прикладной логики. Как-то, так.
К сожалению ничего не прояснили. Должен быть социальный заказ. Нужны специалисты с определенным уровнем знаний. И этот уровень вуз должен оценить, как неудовлетворительный или, как отличный. И мне, как потребителю, безразлично, интересно или не интересно, вашим студентам то, что вы преподаете. Мне важно то, что они знают и умеют. Где-то так…
Вам повезло. Забираю свой квантор общности. Заменяю на «многие».
Ну, да. Бывают и преподаватели с отличным практическим опытом, знаю таких, например, в ВШЭ. Но они, не профессора, а так, как правило, старшие преподаватели. И тем боле не аспиранты. Ну, если, пришлете линк на профессора, у которого 10 лет опыта промышленного программирования, буду признателен.
Чтобы стать мастером в программировании и учить других, надо минимум 5 лет серьезного опыта, а лучше 10. Если такой опыт у аспиранта есть, тогда может и учить.
А я думал, вузы для того, чтобы учить. А оказывается для того, чтобы финансироваться. Как-то не весело это.
ИМХО, проблема не преподавателях и не в студентах. Проблема в том, что программирование — это не наука, и даже не инженерия, а ремесло, которое по лекциям и книжкам не освоишь. Ремеслу учатся у матерого мастера своего дела. И, как правило, обучение идет «при помощи подзатыльников», а не теории. А все аспиранты и профессора, к сожалению, теоретики.

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

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

ЗЫ. Ничего личного. Просто, мое видение истоков проблем, о которых вы написали.
А вообще мне подсказали гениальную мысль: результаты обучения студентов должны подчиняться нормальному распределению.

Может от таких гениальных мыслей и загибается наше высшая школа. Эта мысль == главное не засветиться, чтобы тебя не трогали.

В СССР оценивались знания. И видел учебные группы, в которых половина выпускников получала красные дипломы. А были и такие, в которых до дипломов дотягивали единицы. «От каждого по способностям — каждому по труду» — и никакого нормального закона.
Сугубо, ИМХО. Отладка = модульное тестирование. Для этого нужна продуманная система тестов. Если каждую свою программу отлаживать в дебагере, производительность упадет в разы. За 25 лет активного программирования использовал дебагер в единицах случаев. Как правило, тогда, когда была ошибка в чужом коде — надо было придумать как ее обойти.
Вообще-то, я писал про измерения в проектах разработки новой функциональности. Вы пишите о проекте поддержки. Там количество SLOC считается по другому. N = Nadded + Nupdated + Ndeleted
Кстати, насчет «сект» и их эффективности. Только мне этот миф никогда не был удивителен? Как-то всегда ощущалось, что лучшая система разработки — это «мужики договорились, как делать — мужики сделали как договорились»?


Ставлю плюс. Жизнь привела к такому же выводу. Главное, чтобы «мужики» были правильные!
Конкурентоспособность продукта и команды это две разные вещи. Как показывает жизнь, они очень слабо между собой коррелируют.
Улыбнуло. ИМХО, возможно. Осталось только определить понятие «костыль».

Однако, я измеряю по другому. Как? Отпишусь позже.
Коллега, уточняю. Я никогда не оцениваю отдельного программиста по количеству написанного им кода. Убежден, что любые индивидуальные KPI в разработке ПО не применимы. В моем посте речь идет о необходимости сбора статистики по командам. И она очень полезна.
Давай посчитаем. Предположим, что хороший программист пишет в среднем 200 SLOC. Средняя длина строки — 40 знаков. Итого, 8000 знаков. Скорость набора у хорошего программиста 100 знаков/мин. Делим одно на другое — получаем 80 мин. = 1,33 часа. Остальные 6,67 часов работает головой, даже если сидит за клавиатурой.

Отсюда и получается 80%.
Да. Могу. Выглядит это примерно так. Все фичи делятся на три класса: простые, средние и сложные.

  • Простая: один или несколько методов — от 40 до 200 SLOC.
  • Средняя: один или несколько классов — от 200 до 1000 SLOC.
  • Сложная: пакет — от 1000 до 2000 SLOC.

А далее оцениваем суммарное количество строк в проекте по методу PERT.

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

Просто оставлю это здесь.

Производительность (минимум-максимум (среднее)) в SLOC/мес.на проекте в 100 KSLOC:
  1. 300-7000 (800) интранет.
  2. 200-7000 (600) бизнес.
  3. 100-2000 (300) Интернет.
  4. 50-600 (100) системное ПО, телеком.
  5. 20-300 (50) системы реального времени

(с) С.Макконнелл, «Сколько стоит программный проект»

И еще.


Ну, а у вас с производительностью и качеством?

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Зарегистрирован
Активность