Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 45
«Одним из элементов свободы является отсутствие жестких сроков на выполнение задачи»
Опытный разработчик/проектировщик может определить сроки выполнения задачи и оценить риски.
«В среднем у каждого участника проекта разработки ПО на всякие разговоры уходит 50% рабочего времени.»
Эээ… А кто тогда работает?
«Наличие даже самых звездных актеров не обеспечивает успех фильма. Только талантливый режиссер способен организовать и вдохновить актеров на создание шедевра, открыть новые звезды.»
Так же как и наличие талантливого режиссёра не обеспечит, так как фильм — совместное творение.
Опытный разработчик/проектировщик может определить сроки выполнения задачи и оценить риски.
«В среднем у каждого участника проекта разработки ПО на всякие разговоры уходит 50% рабочего времени.»
Эээ… А кто тогда работает?
«Наличие даже самых звездных актеров не обеспечивает успех фильма. Только талантливый режиссер способен организовать и вдохновить актеров на создание шедевра, открыть новые звезды.»
Так же как и наличие талантливого режиссёра не обеспечит, так как фильм — совместное творение.
Опытный разработчик/проектировщик может определить сроки выполнения задачи и оценить риски.
И внятно объяснить, почему он в них не уложился.
То есть вы заведомо подразумеваете, что ваш разработчик всегда не укладывается в сроки?
Лучше исходить из худшего варианта, так хоть готовым можно быть к возможности не уложиться в сроки.
То есть вы заведомо подразумеваете, что ваш разработчик всегда не укладывается в сроки?
Не совсем. Я подразумеваю, что разработчик не всегда укладывается в сроки и на это есть объективные причины. Как правило, инженер всей информацией не владеет и хрустальный шар у него затуманен. Но, предположим, наш талантливый проектировщик внятно определил сроки окончания и получил, например:
— 20% вероятность, что закончим за 3 недели
— 40%, что за 4 недели
— 70% что за месяц
— 75%, что за пять недель
— 78%, что за шесть
…
— 1%, что закопаемся в проекте, компетенций не хватит и в обозримый срок не закончим
(цифры условные, проект берем более-менее большой, двухчасовые задачки — неинтересно).
Будет ли предствлена менеджеру полная раскладка вероятностей вместе со страшным последним вариантом? Скорее всего нет. Какой срок будет назван? Видимо, в районе месяца, что оставляет аж 30% вероятности не успеть. Либо альтернативный вариант — он перестрахуется и на голубом глазу скажет «4 месяца!», что тоже по понятным причинам нехорошо.
«Будет ли предствлена менеджеру полная раскладка вероятностей вместе со страшным последним вариантом? Скорее всего нет. Какой срок будет назван? Видимо, в районе месяца, что оставляет аж 30% вероятности не успеть. Либо альтернативный вариант — он перестрахуется и на голубом глазу скажет «4 месяца!», что тоже по понятным причинам нехорошо.»
По поводу сроков можно много спорить. Но многие советуют заведомо завышать сроки, чтобы учесть накладки всякие. Брукс в своей книге «Мифический человеко-месяц» вроде как писал, что надо удваивать сроки.
По поводу сроков можно много спорить. Но многие советуют заведомо завышать сроки, чтобы учесть накладки всякие. Брукс в своей книге «Мифический человеко-месяц» вроде как писал, что надо удваивать сроки.
В принципе, понятно, что после того как мы учли все видимые факторы нужно добавить время на то, что мы сейчас не видим. Но на каком этапе это нужно сделать и сколько добавлять?
Если разработчик умножит сроки на пи, потом менеджер умножит сроки на пи, то когда дело дойдет до заказчика/бигбосса, он скажет «Ну, ребята, вы что-то вообще размахнулись» и поделит сроки на девятнадцать.
В результате, это работа менеджера прикинуть на сколько разработчик перезаложился/недозаложился/ошибся, учесть нетехнические риски и, подумав над всем этим, выкатить срок, который был бы достаточен для разработки (скорее всего) и приемлем из бизнес-соображений.
Если разработчик умножит сроки на пи, потом менеджер умножит сроки на пи, то когда дело дойдет до заказчика/бигбосса, он скажет «Ну, ребята, вы что-то вообще размахнулись» и поделит сроки на девятнадцать.
В результате, это работа менеджера прикинуть на сколько разработчик перезаложился/недозаложился/ошибся, учесть нетехнические риски и, подумав над всем этим, выкатить срок, который был бы достаточен для разработки (скорее всего) и приемлем из бизнес-соображений.
Вместо работы болтают 50% времени и минусуют статьи на хабре.
«Опытный разработчик/проектировщик может определить сроки выполнения задачи и оценить риски.»
Любой человек может определить сроки.
Согласитесь, что вопрос и проблема не в этом, а в том, насколько объявленные сроки точны?
Любой человек может определить сроки.
Согласитесь, что вопрос и проблема не в этом, а в том, насколько объявленные сроки точны?
Вопрос в том, на сколько разработчик компетентен. Если всегда реальные сроки слишком разнятся с объявленными, то увольнять такого разработчика.
Меняете тему, но я поддержу.
Увольнять разработчика за то, что он не может здраво оценить срок — не корректно, с моей точки зрения. Причин много, обозначу парочку.
1. Представьте, что вы занимаетесь тем, что прыгаете в длину каждый день. И тут вас попросили оценить, как далеко вы прыгните завтра. Вы называете расстояние, основываясь на ежедневных результатах и своём опыте. Наступает завтра, утром вы случайно съедаете что-либо не первой свежести и вас начинает «полоскать». Приходит «заказчик» и просит вас прыгнуть. Из-за вашего внезапного состояния вы вообще не можете прыгнуть. И если вы постоянно травитесь и не можете прыгнуть на заявленное расстояние, то это не значит, что вы плохо прыгаете или не компетентны в этом вопросе, верно?
2. Представьте, что вы всё ещё прыгун из первого пункта. И вот тренер приходит и говорит: «Извини, но ты откровенно хреново готовил шашлык все эти годы, поэтому я тебя исключаю из своей команды — иди ищи другого тренера».
Подводя итог, умение оценивать сроки и умение реализовывать требуемый функционал — совершенно разные независимые навыки. Глупо увольнять сотрудника от которого вам нужен один навык, если у него не развит другой.
Увольнять разработчика за то, что он не может здраво оценить срок — не корректно, с моей точки зрения. Причин много, обозначу парочку.
1. Представьте, что вы занимаетесь тем, что прыгаете в длину каждый день. И тут вас попросили оценить, как далеко вы прыгните завтра. Вы называете расстояние, основываясь на ежедневных результатах и своём опыте. Наступает завтра, утром вы случайно съедаете что-либо не первой свежести и вас начинает «полоскать». Приходит «заказчик» и просит вас прыгнуть. Из-за вашего внезапного состояния вы вообще не можете прыгнуть. И если вы постоянно травитесь и не можете прыгнуть на заявленное расстояние, то это не значит, что вы плохо прыгаете или не компетентны в этом вопросе, верно?
2. Представьте, что вы всё ещё прыгун из первого пункта. И вот тренер приходит и говорит: «Извини, но ты откровенно хреново готовил шашлык все эти годы, поэтому я тебя исключаю из своей команды — иди ищи другого тренера».
Подводя итог, умение оценивать сроки и умение реализовывать требуемый функционал — совершенно разные независимые навыки. Глупо увольнять сотрудника от которого вам нужен один навык, если у него не развит другой.
Вот то-то и оно, что в разработке ПО законов пока нет. Скорее наблюдения и правила. Голая эмпирика.
Поэтому сравнение с театром и кино мне понравилось.
Несмотря на наличие ВГИК, ГИТИС и различных методик (вспоминаем хотя бы Станиславского)… количество провалов в кино все равно зашкаливает.
Поэтому сравнение с театром и кино мне понравилось.
Несмотря на наличие ВГИК, ГИТИС и различных методик (вспоминаем хотя бы Станиславского)… количество провалов в кино все равно зашкаливает.
Тоже как-то не понял, что не так с инженером. Надо, наверное, сначала определить, что такое инженер, а то слово вроде очевидное, а что на самом деле значит, не совсем ясно.
Инженер — понятие очень широкое, как правило это человек который может выдать решение на основе заданных ограничений и известных закономерностей.
Ремесленник не является инженером — он просто следует инструкциям и воспроизводит некоторый продукт четко по инструкции и ничего более.
Но в нашем мире нет ничего чистого, и инженеры работают за станками и ремесленники изменяют инструкции…
Ремесленник не является инженером — он просто следует инструкциям и воспроизводит некоторый продукт четко по инструкции и ничего более.
Но в нашем мире нет ничего чистого, и инженеры работают за станками и ремесленники изменяют инструкции…
Даже выдающиеся программисты не возьмут на себя смелость утверждать об архитектуре новой программной системы то, что она будет успешной.
Возьмутся, ещё как — это их прямая должностная обязанность — разрабатывать успешные архитектуры.
По поводу отсутствия законов я бы тоже поспорил. Как минимум, некоторые области достаточно хорошо проработаны (например, реляционные БД), существует куча метрик, которые позволяют достаточно объективно оценивать (или сравнивать) качество кода и архитектуры. Если начать копаться, то есть такие области как системотехника, кибернетика и прочие, с которыми любому будет полезно ознакомиться.
Область, конечно, молодая, но не настолько, чтобы не были выработаны базовые принципы и ограничения.
Соответственно, программирование — это никак не ремесло. Программирование — это молодая инженерная дисциплина (с соответствующими «детскими» болячками).
Расскажите, пожалуйста, какие есть объективные метрики качества кода и архитектуры?
Пожалуйста.
Если метриками никто не пользуется, это не значит, что их нет.
Качество кода: цикломатическая сложность, покрытие кода тестами.
Архитектура: степень связанности, её считают по-разному, но как не считай, а это отличная характеристика способности системы расти и изменяться.
Не будем забывать о таких вещах как вычислительная сложность и нормальные формы реляционных баз данных — это уж точно объективные характеристики.
Если немного отойти в сторону от идеальной объективности, то многие утилиты для анализа кода умеют считать кучу метрик вместе с некоторой суммарной характеристикой. Учитывая, что многие из них поддерживаются большими группами профессионалов, их выдачу можно считать объективной.
Хорошим показателем качества кода, например, можно считать компиляцию проекта gcc с флагами -Wall и -Werror.
Если метриками никто не пользуется, это не значит, что их нет.
Качество кода: цикломатическая сложность, покрытие кода тестами.
Архитектура: степень связанности, её считают по-разному, но как не считай, а это отличная характеристика способности системы расти и изменяться.
Не будем забывать о таких вещах как вычислительная сложность и нормальные формы реляционных баз данных — это уж точно объективные характеристики.
Если немного отойти в сторону от идеальной объективности, то многие утилиты для анализа кода умеют считать кучу метрик вместе с некоторой суммарной характеристикой. Учитывая, что многие из них поддерживаются большими группами профессионалов, их выдачу можно считать объективной.
Хорошим показателем качества кода, например, можно считать компиляцию проекта gcc с флагами -Wall и -Werror.
цикломатическая сложность
Говорит только о сложности, но не о качестве. Например, для компилятора она много больше, чем для hello-world. О чём это говорит? О том, что компилятор сложнее.
Она может использоваться, как дифференциальная характеристика: если сложность понизилась при условии неизменности требований и поведения программы, то, вероятно, код стал более качественным.
При изменении требований цикломатическая сложность может измениться и в ту, и в другую сторону.
покрытие кода тестами
Не говорит о качестве кода, кроме как косвено: могут быть написаны тесты и проверено покрытие (согласно некоторой метрике). Т. е. исключает только сильно плохой/связный код при хорошем покрытии. А учитывая, что тесты тоже являются кодом…
Плюс, стоит помнить, что оптимизация по производительности или по памяти может сильно уменьшать тестируемость некоторых кусков кода.
Архитектура: степень связанности, её считают по-разному, но как не считай, а это отличная характеристика способности системы расти и изменяться.
Опять же, применение сильносвязной архитектуры может быть иногда оправдано внешними требованиями по производительности/памяти/нагрузке на GC и т. д. и т. п. Id est такая метрика не является объективным критерием качества архитектуры, которое познается ретроспективно, по сложности внедрения конкретных необходимых изменений. Отсюда всякие методологии типа KISS.
вычислительная сложность
Это вообще не про код и архитектуру, но про алгоритмы. Которые очень сильно зависят от задачи, данных и т. п. Какие объективно лучше для конкретного применения программы могут сказать только прогоны на тестовых данных. Пример — алгоритмы с эвристиками.
нормальные формы реляционных баз данных
Объективные характеристики качества?! В одних задачах нормализация может быть более выгодна, в других наоборот — денормализация. О какой объективности идет речь? Задача, домен и доступные инструменты/технологии определяют наиболее выгодное представление данных.
Если немного отойти в сторону от идеальной объективности, то многие утилиты для анализа кода умеют считать кучу метрик вместе с некоторой суммарной характеристикой. Учитывая, что многие из них поддерживаются большими группами профессионалов, их выдачу можно считать объективной.
Смешиваете понятия. Выдача таких инструментов вполне объективна, они считают ровно те формализованные метрики, которые их просили. SLOC, например. Или SLOC/method. Эти параметры при сильных отклонениях от средних позволяют предположить «code smell». С некоторой долей вероятности.
Не придумали пока серебрянной пули.
Серебряной пули даже в физике нет. Законы Ньютона тоже не всегда работают, но позволяют делать достаточно точные предположения о положении тел в пространстве при определённых допущениях. Так же и приведённые мной метрики позволяют делать предположения (конечно, менее точные чем физические законы) о качестве кода.
Если у нас есть два проекта, выполняющих одну задачу (или один проект в разных версиях), то ориентируясь на изменение этих метрик мы можем объективно сказать, что качество стало лучше или хуже. Более того, на основе этих метрик, мы может строить прогнозы того, как изменится качество кода при исследуемых изменениях.
Раз уж пошло, то это и про то и про другое. Хорошая характеристика и архитектуры и кода, т.к. итоговая вычислительная сложность конкретного куска кода зависит и от первого и от второго. Вполне можно написать пузырьковую сортировку в которой под капотом будет логарифмическая сложность получения элемента из контейнера. О сложностях при взаимодействии между разными компонентами, я надеюсь, говорить не стоит. Поэтому вычислительная сложность (в купе с её аналогом для используемой памяти) — это именно показатель качества.
НФ — объективный показатель качества модели данных.
Давайте не будем забывать, что аспектов у программного проекта множество и они часто имеют взаимоисключающие свойства. Нормальная форма — это (как и большинство других метрик) показатель качества для конкретной части проекта (используемой модели данных), а не его всего.
Если необходим показатель качества проекта целиком, то его нужно считать из соотношения частных показателей с учётом специфики самого проекта.
То есть они позволяют построить некий прогноз, что нам и требуется.
Отсутствие универсальной метрики (или там закона) ни в коем случае не отменяет наличие объектиных частных метрик.
Если у нас есть два проекта, выполняющих одну задачу (или один проект в разных версиях), то ориентируясь на изменение этих метрик мы можем объективно сказать, что качество стало лучше или хуже. Более того, на основе этих метрик, мы может строить прогнозы того, как изменится качество кода при исследуемых изменениях.
Это вообще не про код и архитектуру, но про алгоритмы.
Раз уж пошло, то это и про то и про другое. Хорошая характеристика и архитектуры и кода, т.к. итоговая вычислительная сложность конкретного куска кода зависит и от первого и от второго. Вполне можно написать пузырьковую сортировку в которой под капотом будет логарифмическая сложность получения элемента из контейнера. О сложностях при взаимодействии между разными компонентами, я надеюсь, говорить не стоит. Поэтому вычислительная сложность (в купе с её аналогом для используемой памяти) — это именно показатель качества.
Объективные характеристики качества?!
НФ — объективный показатель качества модели данных.
Давайте не будем забывать, что аспектов у программного проекта множество и они часто имеют взаимоисключающие свойства. Нормальная форма — это (как и большинство других метрик) показатель качества для конкретной части проекта (используемой модели данных), а не его всего.
Если необходим показатель качества проекта целиком, то его нужно считать из соотношения частных показателей с учётом специфики самого проекта.
Смешиваете понятия. Выдача таких инструментов вполне объективна, они считают ровно те формализованные метрики, которые их просили. SLOC, например. Или SLOC/method. Эти параметры при сильных отклонениях от средних позволяют предположить «code smell». С некоторой долей вероятности.
То есть они позволяют построить некий прогноз, что нам и требуется.
Отсутствие универсальной метрики (или там закона) ни в коем случае не отменяет наличие объектиных частных метрик.
Основной тезис, который я хотел донести: мы не можем нормально формализовать понятие качества кода и архитектуры.
Это сродни стандартной проблеме «негативных определений». Мы можем (с некоторыми оговорками) сказать, что объектом не является (качественным кодом/архитектурой, в данном случае). Из этого не вытекает, что мы можем дать позитивное определение объекта.
Два проекта — это почти всегда два разных набора требований. Один проект в разных версиях — тоже. Как максимум, можно ввести критерий-сигнализатор (например, отличие какой-нибудь метрики на порядок/порядки). Как только изменяются требования (вплоть до обнаружения бага), такой прогноз может стать бесполезным.
Какой алгоритм качественнее: со вычислительной сложностью O(N) и памятью O(1) или наоборот?
Необходимые ресурсы (вычисления и память) сильно связаны с моделью данных. И качество кода, архитектуры и модели данных определяется тем, укладывается ли во внешние требования конкретное решение. А это, опять же, негативное определение: не укладывается — плохо, укладывается — неизвестно.
Сказать, какая модель данных, нормализованная или денормализованная, качественнее — невозможно. Можно попытаться проанализировать, какая модель больше подходит для удовлетворения требований в данном конкретном случае.
Только негативный, и то с ограничениями.
Которые показывают погоду на Марсе. То, что эти метрики стабильны не означает, что они объективно характеризуют качество.
Это сродни стандартной проблеме «негативных определений». Мы можем (с некоторыми оговорками) сказать, что объектом не является (качественным кодом/архитектурой, в данном случае). Из этого не вытекает, что мы можем дать позитивное определение объекта.
Если у нас есть два проекта, выполняющих одну задачу (или один проект в разных версиях)… Более того, на основе этих метрик, мы может строить прогнозы того, как изменится качество кода при исследуемых изменениях.
Два проекта — это почти всегда два разных набора требований. Один проект в разных версиях — тоже. Как максимум, можно ввести критерий-сигнализатор (например, отличие какой-нибудь метрики на порядок/порядки). Как только изменяются требования (вплоть до обнаружения бага), такой прогноз может стать бесполезным.
Поэтому вычислительная сложность (в купе с её аналогом для используемой памяти) — это именно показатель качества.
Какой алгоритм качественнее: со вычислительной сложностью O(N) и памятью O(1) или наоборот?
Давайте не будем забывать, что аспектов у программного проекта множество и они часто имеют взаимоисключающие свойства. Нормальная форма — это (как и большинство других метрик) показатель качества для конкретной части проекта (используемой модели данных), а не его всего.
Необходимые ресурсы (вычисления и память) сильно связаны с моделью данных. И качество кода, архитектуры и модели данных определяется тем, укладывается ли во внешние требования конкретное решение. А это, опять же, негативное определение: не укладывается — плохо, укладывается — неизвестно.
Сказать, какая модель данных, нормализованная или денормализованная, качественнее — невозможно. Можно попытаться проанализировать, какая модель больше подходит для удовлетворения требований в данном конкретном случае.
То есть они позволяют построить некий прогноз, что нам и требуется.
Только негативный, и то с ограничениями.
Отсутствие универсальной метрики (или там закона) ни в коем случае не отменяет наличие объективных частных метрик.
Которые показывают погоду на Марсе. То, что эти метрики стабильны не означает, что они объективно характеризуют качество.
Основной тезис, который я хотел донести: мы не можем нормально формализовать понятие качества кода и архитектуры.
Согласен. Также согласен с проблемой «негативных определений». Но отсутствие нормальной формализации не означает её полное отсутствие — другие области знаний тоже не в одним момент формализовали.
Учитывая «негативное определение», можно метрики качества превратить в метрики-антонимы. Пусть они измеряют уровень «брака» — тоже полезный параметр.
Какой алгоритм качественнее: со вычислительной сложностью O(N) и памятью O(1) или наоборот?
В этом случаем мы имеет дело с частично упорядоченных множеством, и данные алгоритмы, соответственно, несравнимы. Но это не отменяет того факта, что другие алгоритмы будут сравнимыми.
Если же вернуться к менее абстрактным вещам, то в рамках конкретного ТЗ вполне можно сравнить даже эти алгоритмы. Достаточно ввести суммарную метрику, основанную на ограничении ресурсов в ТЗ.
Которые показывают погоду на Марсе. То, что эти метрики стабильны не означает, что они объективно характеризуют качество.
Каким свойством должна обладать метрика, чтобы объективно что-то характеризовать?
> То, что производят программисты, нематериально – это brainware, результат коллективного мыслительного процесса проектной команды, материализованный на одном из языков программирования.
Автор много курил и так и не смог понять — материален ли труд программиста или нет?
> Программирование – это проектирование и только проектирование
То есть когда я цикл пишу, то занимаюсь проектированием? Пойду за прибавкой, «мужики-то и не знают».
> Никто не знает, каким местом человек думает и, как он этим местом это делает
Кхм. Обычно — головой. Там, этот — мозг. У автора другое место думает?
> Разработка ПО, ИМХО, по ошибке отнесена к инженерии. Инженерия – это там, где применяются достижения науки, техники, используются законы естественных наук для решения конкретных проблем и достижения поставленных целей. В разработке ПО еще не открыты свои законы Ньютона
Товарищ. Вы с какой луны свалились? В программировании, как минимум, используется математика, но не только она. Алгоритмы рассказать когда были придуманы?
> Даже выдающиеся программисты не возьмут на себя смелость утверждать об архитектуре новой программной системы то, что она будет успешной. Хотя в программировании уже накоплен определенный опыт провалов, который может позволить искушенному программисту увидеть в архитектуре новой системы антипаттерны — источники серьезных будущих проблем. Но не более того
А зачем больше-то??? Исследование чего-либо нового — это всегда крайне затратный труд, успех которого никто не гарантирует. Если я спроектировал архитектуру, в которой я могу опереться на существующие, хорошо зарекомендовавшие себя решения, то она будет мною построена, скорее всего, без серьезных сюрпризов.
В других областях знаний человека, между прочим, все происходит также. Например, строительство.
> Существующее состояние Software Engineering напоминает большую поваренную книгу с многочисленными описаниями рецептов однажды успешно приготовленных блюд из ингредиентов, которых никогда в будущем не будет.
Ну так молодая наука. Вы почитайте историю математики, найдете столько скелетов в шкафу.
> А поскольку это ремесло, то человек, научившийся писать программы на C ++, будет также далек от профессионала, как ученик третьего класса средней школы, научившийся писать по-русски, от А. С. Пушкина или Ф. М. Достоевского.
Автор вообще не понимает о чем пишет, поскольку смешал разные понятия. Попробую растолковать.
Хорошее знание языка не предполагает, что его обладатель станет Пушкиным. Хорошее знание языка = знание грамоты, то есть законов, по котором строятся предложения и вот это все. Более того, есть масса писателей, которые пишут грамматически неверно (авторский язык). Они являются профессиональными писателями. Но могут не сдать ЕГЭ по русскому.
В слове «ремесло» нет ничего плохого, скорее верно обратное. Если что-то стало ремеслом, значит уже накоплен позитивный опыт (на базе тонны негативного) и есть проверенные, работающие решения, которых достаточно, чтобы работать (создавать продукты).
> Свобода – необходимое условие работы программиста.
Автор предлагает их из тюрьмы выпускать на время создания кода?
> В силу отсутствия открытых законов большинство решений программистских задач находится методом проб и ошибок.
Конечно, конечно. Каждая разработка начинается с написания своего компилятора, создания IDE, написание своей базы данных и своих сетевых сокетов.
> У программистов должно быть право на ошибку. Это нормальный атрибут творческого поиска. На ошибках учатся. Умный не тот, кто не делает ошибок, а тот, кто их не повторяет.
Привет, капитан Очевидность! Как жизнь? А можно у людей остальных профессий тоже будет право на ошибку? СПАСИБО, друг! (* плачет от счастья *)
> Для программных продуктов еще не придумали адекватные инструменты визуализации
А как же многостраничные распечатки машинных кодов????? Автор, ну очнись уже. Столько напридумали разных схем и прочего.
> Необходимость постоянных коммуникаций участников разработки. Из опыта. В среднем у каждого участника проекта разработки ПО на всякие разговоры уходит 50% рабочего времени
Кажется, понял автора. Труд программиста — это такой особый труд, где приходится много разговаривать. Возьмем, например экипаж самолета или бригаду хирургов — они-то всю жизнь молчат! Только при выходе на пенсию парой слов обменяются… Или, скажем, работают лифтеры — молчат себе и молчат. Только когда раскаленное олово на голову капнет — тогда разговаривают. А эти программисты — они, блин, болтуны чертовы.
> Для коллективного программистского творчества скорее уместна аналогия с созданием художественного кинофильма или театрального спектакля.
Капустник? Клоунада?
Автор, время идет, жизнь меняется. Когда-то действительно студентам давали на лето задание — написать систему распознавания образов. Но сейчас слегка наработан опыт в самых разных областях программирования и более-менее прояснена сложность тех или иных задач. Также более-менее ясно сколько ресурсов будет уходить на менеджмент, коммуникации и прочее, связанное непосредственно с человеческим ресурсом. С современной точки зрения ваша статья — это несусветная чушь.
Автор много курил и так и не смог понять — материален ли труд программиста или нет?
> Программирование – это проектирование и только проектирование
То есть когда я цикл пишу, то занимаюсь проектированием? Пойду за прибавкой, «мужики-то и не знают».
> Никто не знает, каким местом человек думает и, как он этим местом это делает
Кхм. Обычно — головой. Там, этот — мозг. У автора другое место думает?
> Разработка ПО, ИМХО, по ошибке отнесена к инженерии. Инженерия – это там, где применяются достижения науки, техники, используются законы естественных наук для решения конкретных проблем и достижения поставленных целей. В разработке ПО еще не открыты свои законы Ньютона
Товарищ. Вы с какой луны свалились? В программировании, как минимум, используется математика, но не только она. Алгоритмы рассказать когда были придуманы?
> Даже выдающиеся программисты не возьмут на себя смелость утверждать об архитектуре новой программной системы то, что она будет успешной. Хотя в программировании уже накоплен определенный опыт провалов, который может позволить искушенному программисту увидеть в архитектуре новой системы антипаттерны — источники серьезных будущих проблем. Но не более того
А зачем больше-то??? Исследование чего-либо нового — это всегда крайне затратный труд, успех которого никто не гарантирует. Если я спроектировал архитектуру, в которой я могу опереться на существующие, хорошо зарекомендовавшие себя решения, то она будет мною построена, скорее всего, без серьезных сюрпризов.
В других областях знаний человека, между прочим, все происходит также. Например, строительство.
> Существующее состояние Software Engineering напоминает большую поваренную книгу с многочисленными описаниями рецептов однажды успешно приготовленных блюд из ингредиентов, которых никогда в будущем не будет.
Ну так молодая наука. Вы почитайте историю математики, найдете столько скелетов в шкафу.
> А поскольку это ремесло, то человек, научившийся писать программы на C ++, будет также далек от профессионала, как ученик третьего класса средней школы, научившийся писать по-русски, от А. С. Пушкина или Ф. М. Достоевского.
Автор вообще не понимает о чем пишет, поскольку смешал разные понятия. Попробую растолковать.
Хорошее знание языка не предполагает, что его обладатель станет Пушкиным. Хорошее знание языка = знание грамоты, то есть законов, по котором строятся предложения и вот это все. Более того, есть масса писателей, которые пишут грамматически неверно (авторский язык). Они являются профессиональными писателями. Но могут не сдать ЕГЭ по русскому.
В слове «ремесло» нет ничего плохого, скорее верно обратное. Если что-то стало ремеслом, значит уже накоплен позитивный опыт (на базе тонны негативного) и есть проверенные, работающие решения, которых достаточно, чтобы работать (создавать продукты).
> Свобода – необходимое условие работы программиста.
Автор предлагает их из тюрьмы выпускать на время создания кода?
> В силу отсутствия открытых законов большинство решений программистских задач находится методом проб и ошибок.
Конечно, конечно. Каждая разработка начинается с написания своего компилятора, создания IDE, написание своей базы данных и своих сетевых сокетов.
> У программистов должно быть право на ошибку. Это нормальный атрибут творческого поиска. На ошибках учатся. Умный не тот, кто не делает ошибок, а тот, кто их не повторяет.
Привет, капитан Очевидность! Как жизнь? А можно у людей остальных профессий тоже будет право на ошибку? СПАСИБО, друг! (* плачет от счастья *)
> Для программных продуктов еще не придумали адекватные инструменты визуализации
А как же многостраничные распечатки машинных кодов????? Автор, ну очнись уже. Столько напридумали разных схем и прочего.
> Необходимость постоянных коммуникаций участников разработки. Из опыта. В среднем у каждого участника проекта разработки ПО на всякие разговоры уходит 50% рабочего времени
Кажется, понял автора. Труд программиста — это такой особый труд, где приходится много разговаривать. Возьмем, например экипаж самолета или бригаду хирургов — они-то всю жизнь молчат! Только при выходе на пенсию парой слов обменяются… Или, скажем, работают лифтеры — молчат себе и молчат. Только когда раскаленное олово на голову капнет — тогда разговаривают. А эти программисты — они, блин, болтуны чертовы.
> Для коллективного программистского творчества скорее уместна аналогия с созданием художественного кинофильма или театрального спектакля.
Капустник? Клоунада?
Автор, время идет, жизнь меняется. Когда-то действительно студентам давали на лето задание — написать систему распознавания образов. Но сейчас слегка наработан опыт в самых разных областях программирования и более-менее прояснена сложность тех или иных задач. Также более-менее ясно сколько ресурсов будет уходить на менеджмент, коммуникации и прочее, связанное непосредственно с человеческим ресурсом. С современной точки зрения ваша статья — это несусветная чушь.
Спасибо за внимательное прочтение и ваши развернутые комментарии. Это повод привести дополнительные аргументы к моему посту.
Отвечаю по порядку.
Читаем внимательно. Программисты производят мысли. Они субъективны == идеальны. Но их можно записать на языке программирования. Эта запись будет материальна. Ее можно распечатать, почитать. Но она будет лишь отражением мыслей. Дальше идем в Яндекс
Поверьте, даже когда вы выбираете длину переменной цикла, это будет проектирование.
Тут все не просто. Если бы мы понимали каким местом мы думаем (ведь, есть еще выражение "*опой чувствую") и как мы это делаем, то тридцатикратное повышение производительности программистов было бы воспроизводимо. А там не далеко и до ИИ. Но пока это достаточно мутная область знаний.
Согласен, В слове «ремесло» нет никакого негатива. Это отражение текущего состояния отрасли. В программировании основной метод — «метод проб и ошибок». Просто у ремесленника, достигшего мастерства, пространство перебора сильно меньше.
Так и вижу хирурга или сапера, которые решают свои задачи методом проб и ошибок.
Вы не путаете визуальный образ и текстовое описание? Чертеж самолета и его полное описание в ворде?
А вы объективно с хронометром понаблюдайте на мало-мало серьезном проекте разработки (от 100KSLOC) сколько времени уходит на уточнение задачи, обсуждение подходов к ее решению, дискуссии типа: найден баг или фича, статус митинги и проч.
Еще раз. 50% — это средние затраты по всем участникам проектной команды. РП и аналитики только и делают, что разговаривают. Программисты и тестировщики участвуют в коммуникациях чуть меньше.
В большинстве промышленных разработок имеют вовсе не алгоритмическую сложность, а экспоненциальную сложность масштаба, которую со времен Брукса никто так и не победил. Если вам надо создать ИС, которая содержит тысячи сущностей и десятки тысяч экранных форм то какие достижения CS вам помогут?
Позволю с вами не согласиться ;)
.
Отвечаю по порядку.
Автор много курил и так и не смог понять — материален ли труд программиста или нет?
Читаем внимательно. Программисты производят мысли. Они субъективны == идеальны. Но их можно записать на языке программирования. Эта запись будет материальна. Ее можно распечатать, почитать. Но она будет лишь отражением мыслей. Дальше идем в Яндекс
То есть когда я цикл пишу, то занимаюсь проектированием? Пойду за прибавкой, «мужики-то и не знают».
Поверьте, даже когда вы выбираете длину переменной цикла, это будет проектирование.
Кхм. Обычно — головой. Там, этот — мозг. У автора другое место думает?
Тут все не просто. Если бы мы понимали каким местом мы думаем (ведь, есть еще выражение "*опой чувствую") и как мы это делаем, то тридцатикратное повышение производительности программистов было бы воспроизводимо. А там не далеко и до ИИ. Но пока это достаточно мутная область знаний.
В слове «ремесло» нет ничего плохого, скорее верно обратное. Если что-то стало ремеслом, значит уже накоплен позитивный опыт (на базе тонны негативного) и есть проверенные, работающие решения, которых достаточно, чтобы работать (создавать продукты).
Согласен, В слове «ремесло» нет никакого негатива. Это отражение текущего состояния отрасли. В программировании основной метод — «метод проб и ошибок». Просто у ремесленника, достигшего мастерства, пространство перебора сильно меньше.
Привет, капитан Очевидность! Как жизнь? А можно у людей остальных профессий тоже будет право на ошибку? СПАСИБО, друг! (* плачет от счастья *)
Так и вижу хирурга или сапера, которые решают свои задачи методом проб и ошибок.
А как же многостраничные распечатки машинных кодов????? Автор, ну очнись уже. Столько напридумали разных схем и прочего.
Вы не путаете визуальный образ и текстовое описание? Чертеж самолета и его полное описание в ворде?
А эти программисты — они, блин, болтуны чертовы.
А вы объективно с хронометром понаблюдайте на мало-мало серьезном проекте разработки (от 100KSLOC) сколько времени уходит на уточнение задачи, обсуждение подходов к ее решению, дискуссии типа: найден баг или фича, статус митинги и проч.
Еще раз. 50% — это средние затраты по всем участникам проектной команды. РП и аналитики только и делают, что разговаривают. Программисты и тестировщики участвуют в коммуникациях чуть меньше.
Автор, время идет, жизнь меняется. [...] слегка наработан опыт в самых разных областях программирования и более-менее прояснена сложность тех или иных задач.
В большинстве промышленных разработок имеют вовсе не алгоритмическую сложность, а экспоненциальную сложность масштаба, которую со времен Брукса никто так и не победил. Если вам надо создать ИС, которая содержит тысячи сущностей и десятки тысяч экранных форм то какие достижения CS вам помогут?
С современной точки зрения ваша статья — это несусветная чушь.
Позволю с вами не согласиться ;)
.
> Программисты производят мысли. Они субъективны == идеальны.
Программисты не производят мысли, они думают. Но не только они, все люди (как правило). Меня не интересует объективность мышления, а сам факт, что вы назвали мысли нематериальными (точнее вы сами не знаете так это или нет, поскольку в одном предложении противоречите себе). Мысли являются материальными.
> Поверьте, даже когда вы выбираете длину переменной цикла, это будет проектирование.
Конечно. И когда столяр выбирает какой шуруп ему нужен, он тоже занимается проектированием. И когда водопроводчик подбирает шланг под резьбу. Просто решения на таком уровне не называют проектированием, слишком мелко.
> Если бы мы понимали каким местом мы думаем (ведь, есть еще выражение "*опой чувствую") и как мы это делаем, то тридцатикратное повышение производительности программистов было бы воспроизводимо
Вы смешиваете интуицию и рациональное мышление. Но оба процесса без мозга неосуществимы.
Насчет 30-кратного повышения производительности вспоминается анекдот, что «если бы мне к заднице пилу приделали, то я бы еще и дерево спилил». Но он неприличный для данного ресурса.
> В программировании основной метод — «метод проб и ошибок».
В любой области. В абсолютно любой области этот метод единственно возможный. Поскольку полнотой информации никто не обладает. Просто программирование — молодая наука и мало пути пройдено.
> Так и вижу хирурга или сапера, которые решают свои задачи методом проб и ошибок.
Хм… Автор, вы шутите или серьезно? Вы действительно думаете, что хирурги никогда не ошибаются и все знают наперед? Или саперы? Вы полагаете, что в медицине на любую болезнь есть ясный и понятный способ лечения? Блин, вам надо скорее в доктора, столько народу спасете…
Простите, но у вас в голове какой-то идеализированный мир. И вы преувеличиваете значение ошибки. Ошибки неизбежны в любой области деятельности. Вот недавно самолет упал, пилоты допустили ошибку (возможно). Хотя их учат и тренируют как никого другого. В вашем мире такого бы не случилось, а в реальном — произошло.
> А вы объективно с хронометром понаблюдайте на мало-мало серьезном проекте разработки (от 100KSLOC) сколько времени уходит на уточнение задачи, обсуждение подходов к ее решению, дискуссии типа: найден баг или фича, статус митинги и проч.
Что в этом плохого? Если беспокоит потраченное время — есть способы формализации и передачи знаний, которые позволяют это ускорить.
> В большинстве промышленных разработок имеют вовсе не алгоритмическую сложность, а экспоненциальную сложность масштаба, которую со времен Брукса никто так и не победил.
Автор, вы себе опять противоречите, не замечаете? Вы решите — либо промышленные разработки есть (и значит проблемы решаются как-то), либо их нет (что не так).
> Если вам надо создать ИС, которая содержит тысячи сущностей и десятки тысяч экранных форм то какие достижения CS вам помогут?
Автор, вы не понимаете из чего сложность растет. Кол-во не представляет собой сложность. Сложность — это разнообразие поведения.
А достижения самые обычные: базы данных, XML, языки программирования, тесты и прочее.
Автор, не пишите о том, чего не знаете или не понимаете.
Программисты не производят мысли, они думают. Но не только они, все люди (как правило). Меня не интересует объективность мышления, а сам факт, что вы назвали мысли нематериальными (точнее вы сами не знаете так это или нет, поскольку в одном предложении противоречите себе). Мысли являются материальными.
> Поверьте, даже когда вы выбираете длину переменной цикла, это будет проектирование.
Конечно. И когда столяр выбирает какой шуруп ему нужен, он тоже занимается проектированием. И когда водопроводчик подбирает шланг под резьбу. Просто решения на таком уровне не называют проектированием, слишком мелко.
> Если бы мы понимали каким местом мы думаем (ведь, есть еще выражение "*опой чувствую") и как мы это делаем, то тридцатикратное повышение производительности программистов было бы воспроизводимо
Вы смешиваете интуицию и рациональное мышление. Но оба процесса без мозга неосуществимы.
Насчет 30-кратного повышения производительности вспоминается анекдот, что «если бы мне к заднице пилу приделали, то я бы еще и дерево спилил». Но он неприличный для данного ресурса.
> В программировании основной метод — «метод проб и ошибок».
В любой области. В абсолютно любой области этот метод единственно возможный. Поскольку полнотой информации никто не обладает. Просто программирование — молодая наука и мало пути пройдено.
> Так и вижу хирурга или сапера, которые решают свои задачи методом проб и ошибок.
Хм… Автор, вы шутите или серьезно? Вы действительно думаете, что хирурги никогда не ошибаются и все знают наперед? Или саперы? Вы полагаете, что в медицине на любую болезнь есть ясный и понятный способ лечения? Блин, вам надо скорее в доктора, столько народу спасете…
Простите, но у вас в голове какой-то идеализированный мир. И вы преувеличиваете значение ошибки. Ошибки неизбежны в любой области деятельности. Вот недавно самолет упал, пилоты допустили ошибку (возможно). Хотя их учат и тренируют как никого другого. В вашем мире такого бы не случилось, а в реальном — произошло.
> А вы объективно с хронометром понаблюдайте на мало-мало серьезном проекте разработки (от 100KSLOC) сколько времени уходит на уточнение задачи, обсуждение подходов к ее решению, дискуссии типа: найден баг или фича, статус митинги и проч.
Что в этом плохого? Если беспокоит потраченное время — есть способы формализации и передачи знаний, которые позволяют это ускорить.
> В большинстве промышленных разработок имеют вовсе не алгоритмическую сложность, а экспоненциальную сложность масштаба, которую со времен Брукса никто так и не победил.
Автор, вы себе опять противоречите, не замечаете? Вы решите — либо промышленные разработки есть (и значит проблемы решаются как-то), либо их нет (что не так).
> Если вам надо создать ИС, которая содержит тысячи сущностей и десятки тысяч экранных форм то какие достижения CS вам помогут?
Автор, вы не понимаете из чего сложность растет. Кол-во не представляет собой сложность. Сложность — это разнообразие поведения.
А достижения самые обычные: базы данных, XML, языки программирования, тесты и прочее.
Автор, не пишите о том, чего не знаете или не понимаете.
когда столяр выбирает какой шуруп ему нужен, он тоже занимается проектированием. И когда водопроводчик подбирает шланг под резьбу. Просто решения на таком уровне не называют проектированием
Это самое что ни на есть проектирование. Обычный столяр шурупы не подбирает, они заданы в техзадании и имеют конкретную модель. Шаг в сторону — и это уже проектирование. То же касается и водопроводчика. Если он начнет подбирать шланг под резьбу — жди беды.
Да, реальный мир корректирует наши идеализированные планы и водопроводчики вынуждены подбирать т.к. не существует никаких инструкций на прокладку водопровода в быту. А вот при производстве самолетов — шаг в сторону может обернуться катастрофой. Стяжка топливопровода на пол миллиметра меньше в диаметре — и имеем самолет на пол пути над океаном с опустошенными баками.
Винты лобового стекла на 0.1мм меньше — и имеем вылетевшее лобовое стекло при наборе высоты… и т.д.
Ошибки неизбежны в любой области деятельности. Вот недавно самолет упал, пилоты допустили ошибку (возможно). Хотя их учат и тренируют как никого другого.
Так ведь в чем дело… программирование в такой аналогии будет выглядеть как бесконечные падения по маршруту до тех пор пока очередной самолет таки не долетит до пункта назначения. С другой стороны, пилоты зажаты в своих действиях целым ворохом инструкций! Шаг влево шаг вправо и катастрофа практически обеспечена. И опять же, наш мир и сюда вносит свои коррективы — в нештатных ситуациях, не описанных в инструкциях пилот фактически делает их сам… как это было неоднократно.
Фредерик Брукс очень красиво сказал про пластичность материала.
Материал, в самом деле, очень пластичный, что зачастую и приводит к тому, что:
— «ну пока как нибудь тут по-быстрому напишем, а как нибудь потом, переделаем уже по-хорошему».
А после нескольких десятков тысяч или сотен строк, получается… тихий ужас.
«Программист, подобно поэту, работает почти непосредственно с чистой мыслью. Он строит свои замки в воздухе и из воздуха, творя силой воображения. Трудно найти другой материал, используемый в творчестве, который столь же гибок, прост для шлифовки или переработки и доступен для воплощения грандиозных замыслов».
Материал, в самом деле, очень пластичный, что зачастую и приводит к тому, что:
— «ну пока как нибудь тут по-быстрому напишем, а как нибудь потом, переделаем уже по-хорошему».
А после нескольких десятков тысяч или сотен строк, получается… тихий ужас.
>Есть распространенное мнение: «если бы строители строили дома так же, как программисты пишут программу — первый залетевший дятел разрушил бы цивилизацию»
Если бы требования к строительству домов писали так, как пишут требования к написанию программ, то они бы выглядели так: «хочу дом, ну обычный, как у всех», когда приходило бы время внутренней отделки, говорили бы «а давайте добавим еще один этаж, лифт, и отопление переделаем с центрального на газовое, это же недолго, я бы сам сделал, да времени нет», а за 2 минуты до сдачи говорили «а давайте поиграем с цветом стен и размером окон».
Если бы требования к строительству домов писали так, как пишут требования к написанию программ, то они бы выглядели так: «хочу дом, ну обычный, как у всех», когда приходило бы время внутренней отделки, говорили бы «а давайте добавим еще один этаж, лифт, и отопление переделаем с центрального на газовое, это же недолго, я бы сам сделал, да времени нет», а за 2 минуты до сдачи говорили «а давайте поиграем с цветом стен и размером окон».
Ну и, разумеется, тема была бы раскрыта не полностью без ссылки на этот рассказ: Если бы программисты строили дома :)
Из опыта. В среднем у каждого участника проекта разработки ПО на всякие разговоры уходит 50% рабочего времени. У нас это называется «синхронизация ментальных моделей». Известно, что слова, тембр и интонация передают только чуть меньше половины информации. Поэтому на передачу информации удаленному участнику команды тратиться в два раза больше времени. Отраслевая методика COCOMO II учит, что если проект выполняется распределенной командой, то его трудоемкость надо умножать на 1,5.
Вот это надо золотыми буквами вписать в статьи борцов за удалённую работу.
талантливых режиссеров, как, впрочем, и талантливых менеджеров программных проектов
Я бы не стал сопоставлять режиссеров с менеджерами. Режиссер — это ведущий разработчик команды, архитектор. А менеджер это скорее продюсер фильма, издатель.
Такая тема очень хорошо стимулирует активность эмоционального интеллекта, так что очередного всплеска творческого обсуждения отдельных, вырванных из контекста, цитат не избежать.
Тут еще какой момент — мы обсуждаем индустрию, а говорим от имени своей профессии. И даже профессии наши (роли и компетенции), в силу молодости индустрии, пока еще сравнительно аморфны. Внешний мир только-только начинает, потихоньку, различать «программиста» от «компьютерщика».
На самом деле, как и в любой отрасли, хватит места (приписных свидетельств) и ремесленникам, и инженерам, и творцам и коммерсантам.
В статье остается один вопрос (холиварный) — на что больше похожа наша отрасль — на кинематограф, или строительство?
А раз вопрос риторический, то и ответ очевиден.
Но вот чтобы тему углУбить, мое личное мнение — мы не там делим.
На самом деле — инженерный подход — это методики, работающие там, где нужно стимулировать коллективное творчество.
И достигается это тем, что рутинные операции сворачиваются, границы обозначаются и Инженеру расчищается небольшой такой участок для творческих решений. В идеале — от каждого по способностям, каждому по объемам.
Настоящего «анархического» творчества тоже не бывает, Творцы по полной сворачивают все, что можно, чтобы повысить свою эффективность (посмотрите, как работают Пинк Флойд, Лев Толстой, К.Малевич, Б.Л Пастернак или А.Энштейн, например), но в нашей памяти они просто остаются как очень компетентные и независимые, Творцы.
Направление мне кажется очевидным — двигаться в сторону инженерных дисциплин (со всеми ограничениями, рецептами и справочниками), параллельно строя систему для защиты прав и создания условий тем, кто «вылез» и пытается двигаться быстрее толпы.
А зарабатывать, откровенно по инженерски, помогая всем остальным индустриям, конечно. Мимикрируя, как обычно, и под шоуменов, и под учителей, ну и под суровых производственников с исследователями.
Тут еще какой момент — мы обсуждаем индустрию, а говорим от имени своей профессии. И даже профессии наши (роли и компетенции), в силу молодости индустрии, пока еще сравнительно аморфны. Внешний мир только-только начинает, потихоньку, различать «программиста» от «компьютерщика».
На самом деле, как и в любой отрасли, хватит места (приписных свидетельств) и ремесленникам, и инженерам, и творцам и коммерсантам.
В статье остается один вопрос (холиварный) — на что больше похожа наша отрасль — на кинематограф, или строительство?
А раз вопрос риторический, то и ответ очевиден.
Но вот чтобы тему углУбить, мое личное мнение — мы не там делим.
На самом деле — инженерный подход — это методики, работающие там, где нужно стимулировать коллективное творчество.
И достигается это тем, что рутинные операции сворачиваются, границы обозначаются и Инженеру расчищается небольшой такой участок для творческих решений. В идеале — от каждого по способностям, каждому по объемам.
Настоящего «анархического» творчества тоже не бывает, Творцы по полной сворачивают все, что можно, чтобы повысить свою эффективность (посмотрите, как работают Пинк Флойд, Лев Толстой, К.Малевич, Б.Л Пастернак или А.Энштейн, например), но в нашей памяти они просто остаются как очень компетентные и независимые, Творцы.
Направление мне кажется очевидным — двигаться в сторону инженерных дисциплин (со всеми ограничениями, рецептами и справочниками), параллельно строя систему для защиты прав и создания условий тем, кто «вылез» и пытается двигаться быстрее толпы.
А зарабатывать, откровенно по инженерски, помогая всем остальным индустриям, конечно. Мимикрируя, как обычно, и под шоуменов, и под учителей, ну и под суровых производственников с исследователями.
> Разработка ПО, ИМХО, по ошибке отнесена к инженерии.
Громкие слова, не имеющие никакой базы под собой.
> Инженерия – это там, где применяются достижения науки, техники, используются законы естественных наук для решения конкретных проблем и достижения поставленных целей.
В программировании достижения науки и техники не применяются, законы естественных наук не используются, конкретные проблемы не решаются, а поставленные цели не достигаются?
> В разработке ПО еще не открыты свои законы Ньютона, нет уравнений Лагранжа или хотя бы сопромата
Ой, да ладно. Матлогике тысяча лет в обед. Графы, структуры, алгоритмы, шаблоны — всё это придумано задолго до нас.
То, что большая часть программистов не уверенно этим хозяйством владеет — это объективная реальность, да, что поделать.
С другой стороны, и не каждый слесарь на заводе уверенно три закона Ньютона расскажет. А какой Лагранж — упаси боже!
Громкие слова, не имеющие никакой базы под собой.
> Инженерия – это там, где применяются достижения науки, техники, используются законы естественных наук для решения конкретных проблем и достижения поставленных целей.
В программировании достижения науки и техники не применяются, законы естественных наук не используются, конкретные проблемы не решаются, а поставленные цели не достигаются?
> В разработке ПО еще не открыты свои законы Ньютона, нет уравнений Лагранжа или хотя бы сопромата
Ой, да ладно. Матлогике тысяча лет в обед. Графы, структуры, алгоритмы, шаблоны — всё это придумано задолго до нас.
То, что большая часть программистов не уверенно этим хозяйством владеет — это объективная реальность, да, что поделать.
С другой стороны, и не каждый слесарь на заводе уверенно три закона Ньютона расскажет. А какой Лагранж — упаси боже!
Распечатаю и на стенку!)
Теперь у меня есть грамотный ответ на вопрос «ну и что ты за своим компом делаешь?».
Спасибо!
Теперь у меня есть грамотный ответ на вопрос «ну и что ты за своим компом делаешь?».
Спасибо!
Для программных продуктов еще не придумали адекватные инструменты визуализации. Об этом говорил еще Брукс, почти 40 лет назад.
Не очень удачная конструкция, 40 лет назад очень много чего еще не придумали, из того, что есть сейчас ;) А вообще, вы как-то не очень раскрыли этот момент, так что не очень понятно, что именно вы имели в виду? UML, ERD, блок-схемы? Все же не стоит говорить, что за 40 лет ничего не изменилось, если вы ничего из этого не используете.
Ну, блок-схемы были и 40 лет назад. Но это представление алгоритма, а не продукта. ERD — конечно используем. Но это, опять же, только схема данных. На UML возлагались большие надежды, вплоть до генерации кода. Однако, они, к сожалению, не очень оправдались. Из UML прижились, имхо, только диаграммы Use Cases и сильно реже (в особо сложных случаях) другие диаграммы. Для визуализации архитектуры, по-прежнему, используем доску с квадратиками и стрелочками, подобно рисунку, приведенному в посте.
Программирование как «отрасль» человеческой деятельности лет 30-50 назад содержала один объем информации, а сейчас намного больше. Раньше все программисты одного профессионального уровня по знаниям были похожи друг на друга, а сейчас — нет, у каждого своя специализация. Сейчас уже не скажешь: «Я программист, умею программировать». Правильно говорить: «знаком с С, есть опыт работы на Python».
Вообще надо как-то разделять программирование как технологию, ремесло и теорию программирования. В первом случае изучаются инструменты и их правильное использование, во втором случае — парадигмы (структурное программирование, ооп и др), история, направления. Программирование как искуство — это уже какая-то третья ветвь. Скорее уж не как искусство, а как возможность научного открытия и творческого поиска.
Вообще надо как-то разделять программирование как технологию, ремесло и теорию программирования. В первом случае изучаются инструменты и их правильное использование, во втором случае — парадигмы (структурное программирование, ооп и др), история, направления. Программирование как искуство — это уже какая-то третья ветвь. Скорее уж не как искусство, а как возможность научного открытия и творческого поиска.
Мне вот интересно, а куда отнести в этом случае тестеров продукта? (QA специалистов). Ведь они тоже причастны к програмированию. И что самое интересное, ни в фильмах, ни в строительстве нет людей, которые бы говорили разработчикам (посмотрев отрывок фильма, или живя в ещё не законченном фильме) *Вот тут у вас ляп!* *Здесь жить невозможно, воды нет!* и прочая.
Спасибо! Считаю очень важным, вот таким вот образом (написанием статей (и чтением тоже), отвлекаться от разработки.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Программирование, как новый вид человеческой деятельности