Цитата: графит от 27.09.2018 15:56:26Вы можете доказать это ваше утверждение? Или все хайли лайкли / весь мир это знает?
Пока что никто из моих оппонентов не привел хоть один убедительный пример того, что аджайл, тдд, непрерывная интеграция, солид, кисс и прочее мешают процессу разработки или являются источником говнокода.
Ну что ж, давайте попробуем доказать.
1)
имеем тонны говнокода практически в каждой используемой программе и потрясающе низкую эффективность по использованию ресурсов Если нужно это доказать, укажите отдельно. Игры, банальный MS Word, если Вы просто приведёте примеры повседневных(возможно и профессиональных?) программ, которые стали есть меньше ресурсов и работать быстрее со временем - я с удовольствием с Вами разберу этот вопрос подробно.
Общая тенденция развития программ сейчас такова, что они от версии к версии софт обрастает тонной "фич", при этом абсолютно насрав на оптимизацию работы уже существующего функционала. Заметней всего эта тенденция в операционных системах... Такое чувство, что уже, просто, забыли, что такое операционная система и, что входит в её задачи. Сейчас это компот из маркетологического, шпионского и мультимедийного блока и где то там на задворках, как рудимент, ещё остались намёки на управление доступом, ресурсами и процессами... да и то для совместимости с "касперским 2022"...
Пока оставим в категории "весь мир знает".
2)
Пока что никто из моих оппонентов не привел хоть один убедительный пример того, что аджайл, тдд, непрерывная интеграция, солид, кисс и прочее мешают процессу разработки или являются источником говнокода.Для этого заглянем в вики и разберём общие принципы:
Agile — семейство процессов разработки, а не единственный подход в разработке программного обеспечения, и определяется Agile Manifesto[2]. Agile не включает практик, а определяет ценности и принципы, которыми руководствуются команды. Основные идеи: - люди и взаимодействие важнее процессов и инструментов;
В общем то полезный общечеловеколюбивый лозунг. На заводе будет смотреться особенно уместно!
- работающий продукт важнее исчерпывающей документации;
- сотрудничество с заказчиком важнее согласования условий контракта;
- готовность к изменениям важнее следования первоначальному плануОчень полезные идеи при написании операционки... впрочем что это я... компилятора! Нет, всё равно меня зарубает... ну ладно, интерпретатора...
Ладно, как то с примерами и правда туго, надо бы перевести принципы на понятный язык...
Принципы, которые разъясняет Agile Manifesto[3]: - удовлетворение клиента за счёт ранней и бесперебойной поставки ценного программного обеспечения; Уже через 2 недели в клиента полетит первое гавно с первым десятком кнопок, оно ещё ничего не умеет, даже дырки до СУБД ещё не проковыряли, но главное поставка!
- приветствие изменений требований даже в конце разработки (это может повысить конкурентоспособность полученного продукта); Любой каприз за Ваши деньги!
Ну например, в тридевятом царстве, в тридевятом государстве, написали как то электронный дневник для школьников провели тестирование на 5 школах райцентра кукуево, всё красиво, всё работает, заказчик счастлив... Мэра, кстати, позвали, показали... Мэр кукуева тоже был счастлив... и решили на всё кукукёво поставить... сказано - сделано! Первое сентября, торжественное дёрганье рубильника... 2 сентября... новейший электронный дневник упал и больше не поднялся... никак... Все забегали, засуетились... как же мол так? ведь всё ж работало... Работало... на 5 школах... а когда их стало 1174, вдруг перестало... и сделать ничего нельзя, так как архитектура не позволяет даже если на 2 ЦОДА эту хрень посадить... Худо-бедно... выясняют через 3 месяца секса, что оказывается, существующую платформу, нельзя переписать под новые требования по производительности, ну потому что её писало 2 студента и педагог-фанатик, в меру сил так сказать и знаний... Что поделать, надо с нуля заного писать... больше 4х лет в нашей сказочке такая эпопея могла бы длится... зато конкурентоспособность команд программеров резко упала... за десяток команд, в нашей сказочке, счёт перевалил... по мере написания и обсирания...
- частая поставка рабочего программного обеспечения (каждый месяц или неделю или ещё чаще); Самое главное почаще, чтобы заказчик понимал, что работа идёт передовыми темпами!
Цитата... вот это наша новая секретарша Екатерина, печатает 600 знаков в минуту...
а вот это наша старая секретарша Антонина, печатает 1000 знаков в минуту... такая херня получается!
- тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта;- проектом занимаются мотивированные личности, которые обеспечены нужными условиями работы, поддержкой и доверием; Аминь!
- рекомендуемый метод передачи информации — личный разговор (лицом к лицу); Главное при этом нанять хорошую службу охраны. Бывали случаи порчи мордоимущества реализатора заказчиком.
- работающее программное обеспечение — лучший измеритель прогресса; Главное не уточнять КАК оно должно работать!
- спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределённый срок; Натюрморт - "резиновый кошелёк рядом с белкой в колесе".
- постоянное внимание улучшению технического мастерства и удобному дизайну;
Благо безумство руководства заказчика каждые 2 недели подкидывает хотелки на любой вкус.
- простота — искусство не делать лишней работы;- лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды; Бесспорно, 4 волосатика, при тренере, бухгалетере и директоре всегда лучше знают, как правильно написать программу синхронизации тяговых установок атомохода. Самое главное эти установки от интернета не отключать, иначе патчи вовремя прилетать не будут.
- постоянная адаптация к изменяющимся обстоятельствам. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.Ну, а теперь попробуем ответить на вопрос:
Почему же? как результат многолетней работы agile принципов мы сейчас имеем тонны говнокода, низкую эффективность, штат полудурков? 1) Вся инфраструктура разработки, обслуживает толстосумов в режиме "сделай то, не знаю что", без каких либо точных требований к заказанному.
2) К сожалению, следуя тренду, этот процесс(1) начинается с самого начала, что обычно не позволяет сделать нормально спроектированную базу проекта, которая впоследствии позволила бы обеспечивать требуемую производительность/надёжность, даже при кардинальных изменениях проекта.
3) Отсутствие нормального проектирования, управления требованиями по надёжности и эффективности приводит к тому, что на надёжность и эффективность насрать абсолютно всем "участникам похода". Заказчик - докупит лишнее железо, прогаммеры со временем исправят баги, манагеры придумают новые фичи... всем выгодно!
4) Горизонт планирования всех "участников похода", на любом этапе равен нулю, ибо вся жизнь такого программного продукта и людей его окружающих - это реакция на изменение окружающей ситуации. Ни заказчики, ни девелоперы не просчитывают никаких шагов вперёд, кроме бизнес плана по получению денег, для всех сторон. Отсюда рождается непредсказуемость поведения программного продукта при изменении условий эксплуатации (например масштабировании нагрузки, или увеличении объёма входных данных).
5) Программист при работе в такой системе, не должен хорошо понимать основы работы вычислительной техники или коммуникаций, не должен понимать как работает операционная система, и какое место его программа занимает в окружении. Программист должен хорошо знать на какой фреймворк он переключится завтра, когда манагер укажет ему следующую "идею", которую он должен реализовать.
(6) Пункт (5) обязывает сохранять стадность коллектива, так как директор вспомнил, что программист-сосед по стойлу использовал "вон ту херню, вон на той хреноте" - опять же есть у кого спросить! А вот на прошлой неделе, к нам привели новенького.... он супер новомодный __уэтон знает! А значит завтра, наш манагер, придумает какую нибудь фичу под _уэтон и протолкнёт её в личном общении с заказчиком. О чём нам послезавтра расскажут, на утреннем тренинге!
(7) Опять таки
стадный командный дух, подкреплённый гуглом и тренингом, уже не допускает мысли о том, что при возникновении какого то сложного вопроса, можно что-то изучить, почитать и подумать. Зачем? Всегда можно легко и просто вынести этот вопрос на обсуждение и вероятно кто то из твоих соседей уже наступал на эти грабли и разбирался, но тебе уже этого не надо делать, тебе надо его послушать, взять готовый код и понестись на крыльях ночи в новый день! Учится? зачем? завтра всё равно будем делать что то новое! Неизвестное!
Впрочем, я увлёкся. Уважаемый,
Графит, безусловно, доказать я Вам, ничего не смогу, так как форумы не то место, где нельзя придумать подходящий контраргумент. Но я питаю надежду на то, что, Вы, как человек (судя по Вашим предыдущим постам) здравомыслящий, сами легко поймёте разницу. Те принципы разработки и сопровождения, которые хорошо работают на 1С Торговле и прочем коммерческом прикладном ПО, могут вообще не работать в ПО боевой корабельной/авиационной системы, Мат-КАДе или в открытом проекте по управлению беспилотными летательными аппаратами. Возможно, так же, Вы, сможете представить, что ни один девелопер, даже составом всей команды включая тренера и уборщицу, не в состоянии знать тонкости процесса химической возгонки диметилацетатбромата и без предельно точного ТЗ с жёсткими требованиями по надёжности есть все шансы получить тысяч 10-15 трупов из жителей городка окружающего завод, да, кстати, не уверен, что будет шанс поставить обновление исправляющее ошибку.
Отредактировано: DarkRaider - 27 сен 2018 22:27:12