Последние новости

https://gaperton.livejournal.com/66825.html
2016-06-09 09:26 gaperton
К сожалению, сегодня совсем не веселая картинка. Я бы предпочёл про пм-ов рисовать.

Почему злится ПМ?
2016-06-08 08:30 gaperton

Software: Managing the Complexity
2016-06-05 10:02 gaperton
Эта заметка про понятие "сложности" в ПО, и его связь с управлением проектами.

С веселыми картинками и забавными примерами.

https://medium.com/@gaperton/software-managing-the-complexity-caff5c4964cf#.crsq3slua

Руководство по two-way data binding в React.
2016-06-05 09:58 gaperton
Во-первых, он таки в React есть. Называется value link. Это такой дизайн паттерн. И не смотря на то, что Фейсбук убирает свою кривую реализацию оного из React, он не может вам запретить его использовать.

Понимаем, что это такое, и учимся делать формы на React просто и приятно.

https://medium.com/@gaperton/managing-state-and-forms-with-react-part-1-12eacb647112#.m4awqrpf2

Во-вторых, этот паттерн способен на куда большее, чем примитивная его реализация в React. Например, он помогает весьма изящно делать валидацию ввода в реальном времени.

Учимся делать валидацию форм красиво, без традиционной для таких случаев боли:

https://medium.com/@gaperton/react-forms-with-value-links-part-2-validation-9d1ba78f8e49#.nbf6s3zee

Ну и в третьих. Самое интересное в этом паттерне вовсе не тот очевидный факт, что он устраняет ненужные коллбэки. А то, что он позволяет полностью отделить (и инкапсулировать) способ, которым выполняется data binding, как от слоя view, так и от слоя данных. Чего вообще ни один из популярных фреймворков не может.

Что, например, позволяет нам легко и непринужденно работать со сложным состоянием в React State, без какой-либо черной магии и кучи сторонних библиотек.

Учимся работать со сложным состоянием:

https://medium.com/@gaperton/state-and-forms-in-react-part-3-handling-the-complex-state-acf369244d37#.9f9rp5mwi

Помимо того, что это просто красиво - эта техника сокращает объем кода в JSX примерно вдвое.

https://medium.com/@gaperton/software-managing-the-complexity-caff5c4964cf#.3zdeyc03t

Такие дела.

5. Backbone Sucks
2015-07-14 01:37 gaperton
Кому-то могло показаться после прочтении предыдущей статьи, что мне "просто нравится бэкбон", или что я считаю его лучшей в мире технологией. Это не так. Мы начали с backbone по двум причинам: (1) многие с него начинают, и (2) это, пожалуй, минимально возможный фреймворк для браузерных приложений.

Так как мы приверженцы "бритвы Оккама" - сравниваться мы будем именно с ним, это как точка ноля. Теперь мы разберемся, с какими именно сложностями сталкиваются люди, использующие Backbone, и умеющие готовить его хорошо. Эти сложности однозначно надо исправлять, и по этим причинам можно выбрать другой фреймворк. А вот то, что в минимально возможном Backbone сложностей не вызывает - для этого нужна очень хорошая аргументация, чтобы это исправлять.

Вообще-то это черновик, написанный в один проход. Но мне сегодня влом вычитывать.


Из того, что мы можем хорошего сказать про Backbone - он быстр. Вот такой простой шаблон, сговняканый на коленке при помощи underscore.js, будучи развернут 100 раз в один и тот же узел DOM при помощи присваивания в innerHTML...

<% for( var i = 0; i < 1000; i++ ){ %>
    <div class="row">
        <div class="col"> a </div>
        <div class="col"> b </div>
        <div class="col"> c </div>
    </div>
<% } %>

...берет на свой разворот примерно 1,5-2 секунды. Полностью идентичный разворот HTML на ультрасовременном ReactJS с элементами искусственного интеллекта обновления DOM занимает 12 секунд. Это с учетом того, что React разворачивает его только один раз, а остальные 99 - вообще пытается не трогать DOM. Из соображений тонкой оптимизации.

React имеет репутацию невероятно быстрого фреймворка, настолько, что отдельные коллеги вставляют его в приложение на AngularJS, "для ускорения рендеринга". Ви таки будете смеятся, да.

Из сходу плохого про бэкбон мы можем сказать то, что в своем исходном виде он не дает совсем никаких сервисов, облегчащих разработчику жизнь. Он дает правила, но почти никак не вознаграждает за следование им. Это почти голая дисциплина. И вот здесь начинается самое интересное. Что же это за сервисы такие? А я вам скажу - их отсутствие очень просто определить в любом фреймворке. Обратите внимание на две простых вещи:
- В чем люди регулярно ошибаются?
- Каким из хороших практик люди по факту предпочитают не следовать?

То есть, посмотрите на распространенные ошибки, включая ошибки дизайна, и вы сразу увидите слабые стороны фреймворка. Вы можете сказать - ну и что, эти люди просто недостаточно дисциплинированы и умны для него.

Я вам отвечу - это плохая архитектура, для следования которой надо изменять человеческую природу. Люди по природе не любят прикладывать ум для простейших бытовых ситуаций, и не любят дисциплины. Особенно, глупой дисциплины, не имеющей за собой действительно веской причины. А ваш фреймворк - это не веская причина. Смиритесь с этим.

Итак, к чему у нас склонны люди, работая с backbone.
- По разному разворачивают шаблон во View, кто куда горазд.
- По разному подключают subview, и вообще, это делается настолько тяжеловесно, что они предпочитают по возможности не делать subview, раздувая шаблон.
- В шаблоне, постоянно забывают писать model.get( 'name' ), пишут model.name.
- И не в шаблоне - тоже постоянно путаются, и делают присваивания вместо вызовов model.set( 'attr', value );
- В моделях - не пишут defaults для атрибутов. Ленятся. В итоге, понять, что на самом деле лежит в модели, и что туда попадает во время работы программы - практически невозможно.
- В атрибуте, который содержит массив или объект, меняют что-то, и удивляются, почему не обновился View. А модель не замечает глубоких изменений атрибутов. И не должна. Она замечает только model.set
- Не понимают, как им работать с атрибутами типа Date. С ними творится АД, который слишком красочен, чтобы описать его в рамках данной статьи.

Это не полный список. Я, собственно, только начал. Вопросов у команды, начавшей работать с backbone, возникает слишком много. Давайте, руководствуясь критериями, обозначенными в предыдущих статьях, выделим две главные проблемы:
- В Backbone отсутствует рекурсивный паттерн для View. Нет стандартного способа, как сделать View состоящее из других View.
- В Backbone отсутствует рекурсивный паттерн для Model. Нет стандартного способа, как включать другие модели и сложные объекты типа Date в качестве атрибутов.

Без этих двух рекурсивных паттернов, ничего сложного вы с Backbone не сделаете.

Авторы backbone честно и гордо ответят вам - парни, у нас unopinionated framework. Он дает вам свободу. Вы вольны сами решать, какие у вас будут на них ответы. И они правы. По сути, BackboneJS дает слишком слабые правила, чтобы упорядочить групповую разработку. Это конструктор, основа для конкретных фреймворков, которые вы собираете сами, из Backbone, и его расширений, дополняя это своими правилами.

То есть, Backbone сам по себе - это не ответ на вопрос, как делать браузерные приложения. С ним одним приложения сделать нельзя. Это не инструмент команды, а инструмент архитектора.

Трагизм ситуации в том, что каждый член команды, брошенный на произвол судьбы, отвечает на эти вопросы по своему. В итоге, получившийся код неподдерживаемый, и читать его совершенно невозможно.

Этого ни один вменяемый архитектор допустить не может. Поэтому, появились Chaplin и Marionette. Эти две штуковины - два варианта, как сделать из Backbone более-менее сносный фреймворк, который имеет свое мнение по части ответов на вопросы выше.

Они оба внятно отвечают на вопрос, как будет структурировано ваше приложение, а также, оба содержат в меру простой паттерн для подключения subview. Однако, оба не дают вложенных моделей и коллекций. Вам предлагается искать для них свое решение.

Год назад я был сильно удручен этими другими решениями, и поэтому мы сделали свое (Backbone.NestedTypes). Это хорошая система моделей, по своим возможностям на данный момент перекрывающая не только остальные плагины Backbone, но и системы моделей близких по идеологии фреймворков, таких как EmberJS. Кстати, знаете, например, что model.set в моделях NestedTypes в десятки раз быстрее в Chrome, в сравнении с моделями Backbone? Нет, это не NestedTypes быстр. Это Backbone-модели чудовищно тормозны.

Однако, дело сейчас не в них - давайте просто будем считать, что с моделями никаких проблем нет. И не в databinding - он для backbone также есть в виде плагинов, если вы захотите.

Сейчас я опишу комплекс проблем, нивелирующих основное преимещество Backbone, с которого мы начали - высокую скорость рендеринга UI. И с ней, в отличии от моделей, ничего поделать нельзя. Для этого нам надо будет углубиться в частные случаи, но иначе будет непонятно, в чем общая проблема. Так что приготовьтесь, оно того стоит.

Давайте предположим, что наш UI дизайнер хочет скругленные углы у элементов форм. Понятное желание, человеческое. Проблема только в том, что IE10 не откликается на соответствующий CSS-стиль. И еще, он хочет заменить уродливый скроллбар в элементе select на красивый. И чекбоксы он хочет тоже свои.

В общем, нет проблем. input надо обернуть в div, и уже этому div скруглить элементы. Сразу возникает проблема с фокусом - он хочет, чтобы элемент подсвечивался рамкой, ну ок - это делается неким глобальным скриптом. Главное для вас, как разработчика, в том, что с этого момента вы уже не можете просто писать input, а должны вставлять на его месте нетривияльный HTML.

То же самое с checkbox - вместо простого input вы должны вставлять некий непростой HTML определенной структуры.

И совсем плохо с select, в котором мы хотим подменить скроллбар и цвет фона. Это адово непростой HTML, который уже затруднительно вставлять в шаблон, и которому нужен продвинутый JS.

Если вы будете применять для каждого такого контрола backbone subview (а subview делать все еще достаточно напряжно в том числе и с Chaplin и Marionette) - вы застрелитесь на второй день. Разработчики ошибаются. Нечеловеческая дисциплина. Не вариант. И вы ищете выход.

Выход называется Web Components, позволяющий определять свои HTML-тэги. Но это новый стандарт, который браузерамм не поддерживается, и поэтому, вы находите Polymer, и чуть позже - x-tag. Та-да!

И тут вы вдруг понимаете, что ваши кастомные тэги разворачиваются асинхронно. То есть, после render, они не готовы к работе. Ну не беда, вы заменяете innerHTML на xtags.innerHTML, чтобы избежать race conditions. Та-да!

И вообще, эти Polymer - это очень модно. Вы на острие технологии. Круто. Та-да!

Только штука в том, что эти кастомные теги разворачиваются DOM-манипуляцией. И это происходит ацки медленно. На самом деле, вы получите скорость рендеринга хуже, чем в модных медленных фреймворках. Она будет настолько медленной, что вы будете замечать это невооруженным глазом. Упс.

Если проблему обобщить, то...
рекурсивный паттерн для subview в Backbone крайне неудобен на микроуровне, что не позволяет вам сделать библиотеку виджетов

А также...
применение Web Components приводит к деградации производительности, нивелируя единственное неоспоримое преимущество Backbone - скорость рендерига

И даже если бы нет, то...
работая в рамках шаблона, вы не можете передавать custom tags сложные объекты, например - модель
Только через текст. Что идиотизм, и очень сильно ограничивает вас в возможностях.

Другими словами, рекурсивный паттерн subview, в условиях того, что view состоит из текстового шаблона и подключения subview на javascipt - крайне неудобен, и значительно усложняет проектирование

Сейчас мы могли бы рассмотреть AngularJS. Но есть одно обстоятельство, которое освобождает нас от необходимости это делать. Дело в том, что уже анонсирован Angular 2.0, который будет обратно не совместим с Angular 1.x, а посему - мало кто в отважится сейчас начинать проект на Angular.

Но если вы настаиваете - в Angular ситуация чуть лучше, так как вы можете определять "директивы", однако наличествует разница между "контроллером" и "директивой", и элемент UI так же расщеплен на HTML и JS. При этом, полностью отсутствует сервис моделей. Как и принципиальное преимущество перед Backbone, которое бы заставило вас выкинуть написанный с ним код. Two-way databinding им не является, он несложно делается и в backbone.

Поэтому, мы рассмотрим Ember, ExtJS, и React. Все они решают обозначенную проблему. Каждый по своему.

4. BackboneJS.
2015-07-10 16:50 gaperton
Допустим, у нас есть группа разработчиков на PHP, которые знают чуть чуть JS и jQuery. Что самое простое мы можем сделать, чтобы начали писать браузерное приложение, и были продуктивны немедленно?

Мы можем попробовать использовать тот же принцип, и те же архитектурны правила, к которым они привыкли в PHP. У них были шаблоны с встроенным PHP? Отлично, мы будем использовать такие же шаблоны со встроенным JS, которые будут разворачиваться в браузере. Они использовали jQuery? Отлично, мы сохраним jQuery.

Нам остается задать этому какую-то структуру. Элемент UI - это будет объект View с присоединенным DOM-элементом, и методом 'render', который должен разворачивать шаблон в присоединенный элемент. Помимо этого, View должен уметь перехватывать события UI, и вызывать свои методы.

Помимо этого, нелишне добавить к этому простые средства для работы с REST API. Класс для кусочка JSON, который умеет создаваться/читаться/сохраняться/удаляться (CRUD) в каком-нибудь стандартном варианте REST. Назовем его Model. Раз у нас REST, то надо еще уметь получать их список. Значит, нужен еще Collection.

У нас сейчас получилось что? Правильно, самый популярный фреймворк для разработки в браузере - backbonejs (http://backbonejs.org), который, в сочетании с модульной системой позволяет из говна и палок собрать браузерное приложение.


Что мы видим глядя на архиутектуру Бэкбон? Два слоя, вью и модели. Однако, и вью, и модели совершенно "плоские". Логика авторов вполне понятна - в методе 'render' одного view совсем несложно подцепить другой view. Зачем навязывать людям какой-то способ это делать - пусть сами как хотят. А для точки протокола REST, которую представляет собой "модель", никакой "рекурсивности" и не нужно - она одна, и все. Хочется хранить в атрибуте модели сложный JSON? Да на здоровье.

Здесь мне полагается начать перебирать буковки чтобы описать паттерн, предоставляемый backbone - это MVC, MVVM, или что? На случай, если вам это действительно важно, какими буковками это называть (видел я таких, как определятся с буковками - сразу успокаиваются, начинают дышать ровнее, как будто поняли что-то. Или вбрасывают так - "это же MVVM!", и смотрят на тебя стеклянным глазом), то вообще-то это типичный PAC (https://en.wikipedia.org/wiki/Presentation–abstraction–control). Presentation - это шаблон, Abstraction - это модель или коллекция, а Control - это собственно сам View.

Не? Ну, тогда типичный MVP (https://en.wikipedia.org/wiki/Model–view–presenter), где презентер это опять вью, а вью - это шаблон. Не? Ну тогда я просто объясню, как оно работает :)

А на самом деле, работает оно следующим образом. Вью может как само создавать свою модель, так и получать ее снаружи. Модель умеет бросать события об изменениях, так что вью полагается на них подписываться, и вызывать себе render, внутри которого он должен развернуть в свой элемент свой шаблон с этой моделью в качестве контекста. И еще что-нибудь сделать - jQuery плагины инициализировать, и вложенные вью подцепить. Вот и все.

Зачем события? А вот тут мы приходим к фундаментальной проблеме веб платформы, предложить какое-то свое видение решения которой просто обязан каждый фреймворк. Штука в том, что JS исторически был однопоточен, и ввод-вывод из него делается асинхронно. То есть, когда вы запросили данные - вам их сразу в этом месте никто не даст. Сразу вы оставляете коллбэк, и они придут потом. И когда они придут - вы должны обновиться. Оставлять коллбэк невероятно неудобно, и разные фреймворки по разному подходят к этой проблеме.

Backbone использует очень простой подход. Мы пишем приложение, как будто данные у нас всегда есть, и как бы синхронно. Но - они по разным причинам могут обновляться (то, что они с сервера пришли - это частный случай), и мы всего-то должны - замечать это, и обновить UI. Поэтому, модели в backbone умеют бросать события 'change', а вью полагается его ловить и обновлять себя, вызывая 'render'. Выглядит это примерно вот так:

this.listenTo( this.model, 'change', this.render );
model.fetch();

Есть, конечно, и другие подходы. Например, вместо событий, можно использовать Promise.

model.fetch().done( function(){
    this.render();
}.bind( this ) );

Или, так сказать, опустится до коллбэка.

model.fetch({
    success : function(){
        this.render();
    }.bind( this )
});

Но для бэкбона идеоматической является модель программирования с событиями 'change'. И это - пожалуй, самая лучшая идея из всех, что есть в backbone.

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

Сейчас технологии разработки SPA ушли очень далеко вперед, и backbone явно устарел на фоне современных фреймворков. Его суровый солдатский дизайн не дает разработчику почти никаких сервисов. Но одно бесспорное достоинство backbone отметить надо. Дело в том, что техника, которую бэкбон предлагает вам для рендеринга HTML, а это как-то так:

render : function(){
    this.el.innerHTML = this.template( this.model );
}

принципиально самый быстрый способ рендеринга HTML из всех возможных. Он не просто "быстрее" чем всякие там Angular, React, и Ember, он их в тряпки нафиг рвет. Присваивание в innerHTML в десятки раз быстрее, чем DOM-манипуляции. В десятки, Карл.

И если вы делаете мобильное приложение, то, в принципе, это очень даже повод задуматься.

Об архитекторе
2015-07-09 01:54 gaperton
Небольшая заметка о том, что это за роль такая и кто это вообще должен быть такой, чтобы от него была польза. А то тоже проясняют уже лет 20, и все нихрена.

Вот в этом определении архитектуры...
*Архитектура* - это набор формальных и неформальных *правил*, руководствуясь которыми люди проектируют систему.

...самое важное - это явный акцент на том, что суть архитектуры в правилах для людей. Предмет архитектуры, как таковой - не технологии, а люди, которые их делают, и именно они стоят в центре.

Архитектор несет непосредственную личную ответственность не "за систему", а за продуктивность всех членов команды в их повседневной работе. Его обязанность - усиливать людей, снабжая их необходимыми технологиями для выполнения повседневных задач по проектированию системы. И оказывать им всестороннюю поддержку, если у них будут с этими технологиями какие-либо сложности.

Именно так, и никак иначе. Не придумывать как делать систему под конкретные требования. А давать людям методику (набор правил), руководствуясь которым конкретные эти люди (а не какие-то там абстрактные) смогут проектировать эффективнее.

Совершенно очевидно, что без определенного авторитета, и без разностороннего опыта работы как с технологиями так и с людьми, человек пытающийся быть архитектором быстро превращается в клоуна.

Я видел много людей с этим титулом. Настоящий архитектор не просто умеет писать код, он в состоянии исправить в этом коде вывернутый мистический баг, который приводит людей в суеверный трепет. Настоящий архитектор - он сцуко гуру и рыцарь без страха и упрека, к которому вы с этим багом придете, и скажете - "Обиван, ты наша последняя надежда".

Штука в том, что если он мудак - вы к нему просто не придете.

ЗЫ: А мудак - благодаря Стенфордскому профессору Бобу Саттону - теперь вполне научное понятие. Я лично считаю, вся наука организационного поведения давно к этому шла: https://en.wikipedia.org/wiki/The_No_Asshole_Rule

3. Рекурсивный паттерн проектирования
2015-07-06 00:49 gaperton
Теперь поговорим об архитектуре так называемых "одностраничных приложений" более детально.
Это будет непросто - сотни фреймворков, предлагающих десятки подходов - какой из них выбрать? У человека, решившего написать одностраничное приложение, будут большие проблемы. Такое многообразие выбора - это почти что то же самое, что и его отсутствие.

К счастью, основной критерий "хорошести" или "плохости" архитектуры очень простой. Коль скоро архитектура - это правила проектирования, то в первую очередь эти правила должны выполнять свою главную функцию - помогать проектировать:


Хорошая архитектура снабжает вас простыми и понятными правилами, которые помогают легко разбить что-то большое и сложное на набор менее сложных, слабо связанных между собой кусочков. А потом - эти кусочки разбить на более мелкие. И так далее.


Мы будем оценивать фреймворки и технологии именно с этой точки зрения - поддерживают ли они "рекурсивный паттерн проектирования", и если да (что уже неплохо) - то насколько легко пользуясь им разбить что-то сложное на набор мелких фрагментов.


FYI - есть два основных типа "рекурсивного паттерна".

Первый - "слои". Суть его в том, что система организована в "слои сверху вниз", таким образом, что верхний знает про нижние, а нижние про верхние ничего не знают. Слои отделены друг от друга строгим API, а за этим API вполне может царить Адъ. Ну и что.

Этот паттерн теоретически рекурсивен потому, что часто один слой при большом желании можно разбить на два слоя. Или он может быть слоистым внутри. Но, как правило, у каждого "слоя" есть определенный смысл, и бить его дальше некуда.

Второй - "иерархическая декомпозиция". Его суть в том, что сложный модуль состоит из более мелких, они - еще из более мелких, и т. д., таким образом, образуя "дерево". Все модуля отделены API.

"Иерархическая декомпозиция" является архитектурным паттерном только тогда, когда интерфейс "узлов" не уникален, а стандартизован. Например, если мы говорим о UI виджетах - то архитектурное правило говорит нам, как выглядит интерфейс виджета.

В реальной системе они всегда встречаются в сочетании. Например, если есть какой-то фрагмент используется в двух "деревьях" сразу - это означает, что он принадлежит "нижнему слою". Явно отделять слои, и наделять их смыслом - критически важно для архитектуры. Задавая осмысленные слои, с внятными критериями принадлежности им, вы задаете правила.


Надо отметить, что у "голой" браузерной платформы с этим исходно большие проблемы. Для описания UI требется целый трех языка: HTML, CSS, и JavaScript. И каждый более мелкий кусочек должен каким-то образом включать в себя все три. Но все, что может дать нам голый браузер - это один файл HTML, включающий в себя много файлов JS и CSS. А из JS файла сказать, что ему нужен другой JS файл нельзя вообще.

Прежде чем разбираться с фреймворками, надо разобраться с этим. Без нормальных модулей JS с зависимостями, этого элементарнейшего "рекурсивного паттерна", очевидно, ничего сложного в бразуре сделать в принципе невозможно.

Хорошая новость в том, что на JS модули есть открытая публичная спецификация CommonJS/Modules. Именно с такими модулями работает серверный JavaScript, например - nodejs.

Выглядит это так. В каждом файлике .js пишется что-то вот такое:

    var iamimporting = require( 'path/to/js/file' );
    ...
    module.exports = iamexporting;

В node это работает прекрасно, потому, что загрузка модуля с локального диска быстра, и может происходить синхронно. Чтобы это работало в браузере, модуль потребует дополнительной обработки (сборки). Например, мы можем собрать все модули, которые надо загрузить, в один большой файл, и включить его один раз тегом script.

Именно так работают browserify и webpack. При этом, (1) у нас в проекте появляется шаг сборки, и (2) возникает куча нюансов в случае, если приложение очень большое, и мы не хотим грузить все сразу. Мы хотим сразу загрузить необходимый минимум, а далее подгружать то, что нужно, по необходимости.

Это можно сделать, разбив приложение на крупные куски (единицы загрузки), и собрать эти куски
раздельно (по сути очень похоже на DLL). Это особенно удобно делается в webpack.

Или же, можно придумать что-нибудь еще. Это что-нибудь еще называется CommonJS/AMD (Asynchronous Module Definition), позволяет грузить модули без сборки, и в тот момент, когда они действительно нужны. Выглядит это так:

    define( [ 'path/to/js/file', ... ], function( iamimporting, ...){

        return iamexporting;
    });

И есть много загрузчиков, которые позволяют грузить такие модули. Самым популярным из них является requirejs.

Но у этого модуля есть недостаток, который сразу бросается в глаза. Им невозможно пользоваться. Поэтому, помучавшись несколько лет, разработчики придумали формат асинхронного модуля "Simplified CommonJS Wrapper", который допускает асинхронную загрузку, но выглядит по человечески:

     define( function( require, exports, module ){
        var iamimporting = require( 'path/to/js/file' );
        ...
        module.exports = iamexporting;
    });

requirejs также позволяет выполнять сборку проекта в один или несколько больших файлов js, но в данном случае это не необходимость, а оптимизация.

Глядя на это, возникает простая идея. Раз импорт модуля - это не часть языка, и все равно делается неким фреймворком, может ли он быть чуть поумнее, и загрузить прочие нужные нам ресурсы - html-шаблоны, css?

Конечно же может. Например, в requirejs это будет выглядеть так:

    define( function( require, exports, module ){
        require( 'css!./widget');
        var template = require( 'ejs!./widget' );
        ...
        module.exports = mywidget;
    });

В requirejs и webpack это далется при помощи контент-плагинов, они могут грузить практически все, что угодно, выполняя при этом над загружаемым объектом необходимые преобразования. Например, шаблон может на лету компилироваться в JS. И если они не умеют грузить то, что нужно вам - вы можете легко научить их это делать.

Что касается директивы import из ES6, я не думаю, что когда она будет поддерживаться браузерами, она быстро вытеснит модули CommonJS. Во-первых, синтаксис CommonJS совсем не плох, и никакого выигрыша сама по себе замена 'require' на 'import' не даст. Во-вторых, возможность тонко контролировать процесс загрузки, и выполнять преобразования над загружаемыми объектами - это очень большое преимущество для браузерных приложений. Вряд-ли от него кто-то просто так откажется.

Вообще, я бы не советовал уделять слишком большое внимание системе модулей. Она должна быть CоmmonJS, и выбирайте любой загрузчик. Его потом будет не так сложно заменить. Я бы советовал выбирать между requirejs и webpack. Первый - если не хотите вводить в проект шаг сборки. Сел, и поехал. Второй - готовы делать сборку, озабочены тем, чтобы "быть на острие технологий", и не хотите потом горько жалеть о том, что выбрали какую-то фигню.

Но уверяю вас, система сборки и загрузки модулей - это совсем не то острие, которое изменит
всю игру.

С модулями CommonJS и контент-плагинами уже вполне понятно, как в принципе бить приложение на кусочки, разложив их по файлам. Это необходимо, но не достаточно для того, чтобы построить наше приложение - нам надо знать, как примерно будут выглядеть эти кусочки. "UI виджет - это js модуль" - это слишком общо.

Не всякий модуль экспортирует виджет, в конце концов.

Часть 2. Возможности и ограничения современных веб-платформ
2015-06-26 22:19 gaperton

Часть 1. Об архитектуре и фреймворках
2015-06-26 20:27 gaperton

Для начала в очередной раз внесем ясность в вопрос, что же такое архитектура. Сколько десятилетий термин в ходу, и в него постоянно вносят ясность - без особого толка. Однако, коль скоро мы собираемся о ней говорить, это совершенно необходимо сделать в очередной раз. Иначе будет просто не понятно, о чем речь.

Архитектура* - это набор формальных и неформальных *правил*, руководствуясь которыми люди проектируют систему.

Результат проектирования - это как правило некоторая высокоуровневая структура системы, которую тут же снова называют словом "архитектура" (ну вот мало у нас слов, и те все иностранные), а потом начинают ломать голову, чем же это отличается от "дизайна", и пр. И накидывать при этом кучу умняка. Мы не будем. Вместо этого:

• Мы будем стараться использовать для обозначения нашего понимания термин "Common Design Principles".


• Постараемся разобраться в определении, и как оно соотносится с фреймворками и структурами. Увидете, как только вы начнете думать об архитектуре как о правилах много встанет на свои места.

Ну вот как это, правила? - спросите вы. Ну вот у меня в системе, например, MySQL, я пишу сервер на PHP с фреймворком Laravel. Вот, могу слои нарисовать, какие у меня есть. Где здесь правила? - скажете вы. Да здесь их куча. И я вам сейчас их покажу.

Во-первых, подразумевается, что все меняющиеся данные (или по карйней мере большинство) должны храниться в MySQL. Как, у вас нет такого правила? Вы можете легко заменить MySQL на PostgreSQL? Значит, правило более ограничивающее - данные должны хранится в реляционной форме, и плюс к этому вы не должны полагаться на уникальные возможности конкретной БД в работе с ними.

Во-вторых, "с фреймворком Laravel" означает, что вы не должны работать с табличками в своей базе напрямую, подразумевается, что вы должны делать это через ORM. И Laravel дает вам кучу своих правил, как это делать.

Эти правила очень сильно ограничивают вам множество вариантов, как может выглядеть структура вашего приложения, но, при этом, не ограничивают вас в в том, что будет делать ваше приложение (т.е. "функциональные требования"). И, таким образом, упрощают вам проектирование системы:

• Искать решение в меньшем множестве вариантов - проще и быстрее, естественно, при наличии навыка работы с данными правилами.


• Много людей могут проектировать в рамках этих правил, и более-менее легко понимать решения друг друга.



• Вам не придется ломать голову о решении множества мелких технических проблем - пока вы остаетесь в рамках правил, это все делается за вас.

  Это все замечательно, но, конечно, не бесплатно. Правила могут ограничивать производительность, что может стать проблемой. Ну и в конце концов, правила соблюдают люди. А им соблюдать правила не всегда легко, и далеко не в каждом случае их соблюдение приносит пользу. Иногда правила настолько сложны, что инженеры их не понимают. А как можно соблюдать то, что не понимаешь?

Вообще, чтобы архитектура была архитектурой, а не фантазией, легко опровергаемой заглядыванием в код, необходимо всегда помнить, что эти правила выполняют люди. Поэтому, если вы хотите чтобы люди их соблюдали:

• Про правила проектирования должны все в команде знать. Нет ни малейшего шанса следовать неизвестным правилам. То есть, если у вас в ящике стола лежит секретная диаграмма, про которую никто кроме вас не знает - это не архитектура. Что бы там не было написано.


• Все должны их понимать и помнить. Люди в принципе не в состоянии следовать тому, что они не поняли. То есть, правила должны быть очень простыми, и их не должно быть много. Это значит, что если ваши правила хоть чуть-чуть напоминают правила игры в "драконий покер" - они являются архитектурой только в вашем воображении, все все равно будут делать по другому.


• Соблюдение правил не должно сильно усложнять жизнь. Люди, надо отметить, и так-то не сильно любят соблюдать правила. Надо напоминать, как они поступают с правилами, требующими для соблюдения нечеловеческих усилий?


• Правила должны помогать. Выгода от следования правилам должна превышать затраты на их соблюдение.

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

Да, забыл сказать - в идеале было бы хорошо, если бы новый сотрудник только нанятый на работу про них сразу знал. Ну, хотя бы, частично.

Ну так как бы не бывает, ну? - скажете вы. И тут на сцену выходят Фреймворки. Та-да.

Фреймворки дают вам правила проектирования, соблюдение которых, предположительно должно вам помочь. Задача фреймворка - сделать этот процесс проще, приятнее, и понятнее.

За этим мы и используем фреймворки. Они, как правило, задают некий скелет приложения, или его части, или скорее, правила их построения. За это мы их любим. В отличии от библиотек - их мы испольузем чтобы получить какую-то полезную функциональность, и как раз очень не любим, когда они начинают лезть не в свое дело, и диктовать нам какие-либо условия на структуру приложения.

Ну, в жизни, конечно, все немного сложнее. Выбором одного фреймворка дело не заканчивается. Фремворк может касаться какого-то одного архитектурного аспекта - например, только делать ORM. Его одного мало, чтобы сделать архитектуру, то есть, накрыть правилами проектирования все приложение. И кроме того, фреймоворки далеко не одинаковы в причиняемом ими добре - некоторые из них деспотичны, решая за вас совершенно все, а какие-то напротив, достаточно либеральны в плане там разных свобод.

http://stackoverflow.com/questions/802050/what-is-opinionated-software

Софт бывает opinionated, и unopinionated. Эти термины не имеют отношения к тому, какое мнение относительно софтины сложилось в сообществе. Здесь речь идет о "мнении" кусочка софта о том, как вы должны делать разные вещи (ну то есть правила он вам ставит). Библиотека как правило unopinionated. А вот фреймворк, чтобы быть фреймворком, просто обязан иметь какое-то свое мнение.

Короче, все бы хорошо, только количество разных фреймворков для веб-разработки одностраничных приложений давно перевалило за сотню. И каждую неделю появляется новый. Что говорит нам об одном - не смотря ни на что, никто до сих пор тольком не понимает, как правильно их делать. И уж во всяком случае, в сообществе нет на этот счет какого-либо общего мнения.

Backbone.js on Steroids
2014-06-25 00:33 gaperton
Расскажу, пожалуй, про старую тему - разработку одностраничных JS-приложений. С тех пор, как я послежний раз об этом писал, прошло много времени - наверное, года 3. И с тех пор много чего изменилось. Появилось множество разных JS фреймворков, в моду вошел two-way databinding.

Однако, мэйнстримом (примерно 40% применений) на данный момент является Backbone.js, работающий в связке с jQuery и Underscore.js. Причиной этого, возможно, является его простота. Backbone прост в том смысле, что ему достаточно легко обучить команду, собирающуюся писать одностраничное приложение, и не имеющую в этом опыта. Это безусловный плюс backbone (как и его популярность), однако, его минусом является то, что он слишком прост. То есть, на голом backbone не так просто сделать что-то, кроме совсем простого.

Я расскажу про проблемы backbone, вытекающие из его простоты, и покажу, как их можно решить. Проблемы уйдут. Простота останется.


Начнем с элементарного. Простой модели - пусть это будет User.

	var User = Backbone.Model.extend({
		baseUrl : '/api/users',
	
		defaults : {
			name : "",
			email : ""
		}
	});

Пока проблем никаких нет, но они начинаются почти сразу, как только мы хотим сделать что-то полезное. Например - добавить к этой модели атрибут created, который будет содержать дату/время создания нашего пользователя. Человек, только начавший изучать бэкбон, скорее всего сделает примерно так.

	var User = Backbone.Model.extend({
		baseUrl : '/api/users',
	
		defaults : {
			name : "",
			email : "",
			created : new Date()
		}
	});

И мы не можем его за это осуждать - желание вполне естественное, и логика в нем есть. Только этот код работает совсем не так, как предполагал его автор.

Во-первых, этот new Date создается один раз при загрузке кода, и все экземпляры Users будут держать в created референс на один и тот же экземпляр Date. А "во-вторых" гораздо хуже. Штука в том, что в JSON такого типа данных, как Date - нет. При попытке сохранить это на сервер, а также получить эту модель с сервера, в поле created окажется вовсе не то, что автор ожидал увидеть.

Ужасно обидно получать по лбу граблями, когда даже толком не успел сделать шаг, но в итоге программист станет ученым, и станцует вокруг граблей примерно такой танец:

	var User = Backbone.Model.extend({
		baseUrl : '/api/users',
	
		defaults : function(){
			return {
				name : "",
				email : "",
				created : new Date()
			};
		},
		
		toJSON : function(){
			var toServer = Model.prototype.toJSON.apply( this, arguments );
			toServer.created = toServer.created.toJSON();
			return toServer;
		},
		
		parse : function( fromServer ){
			fromServer.created = new Date( fromServer.created );
			return fromServer;
		},
		
		validate : function( attrs ){
			if( !( attrs.created instanceof Date ) ){
				return new TypeError( "User.created is not Date" );
			}
		}
	});

	var user = new User(),
	    user2 = new User();
		
	user.set( 'created', new Date( '2012-12-12 12:12' ) );
	user2.set( 'created', user.get( 'created' ) );

Далее, когда программист захочет сделать наследование от какой-нибудь модели, его в кустах ждут маленькие такие, но очень прикольные грабельки. Сделаны с любовью. Ручная работа. Сначала программист будет верить в прекрасное, и попробует очевидный и прямолинейный способ:

var SuperUser = User.extend({
		defaults : function(){
			return {
				expiresAt : new Date()
			}
		}
	});

Это, как вы уже догадываетесь, совсем не тот способ, которым делаются простые вещи в backbone. Бэкбон попросту перетрет аттрибуты базового класса новыми, то есть - никакого created date by default не создастся. Надо (вернее сказать - не надо, но придется) как-то вот так:

	var SuperUser = User.extend({
		defaults : function(){
			return _.defaults({
					expiresAt : new Date()
				}, User.prototype.defaults() );
		},
	});

Но это ничего. Программист научится и этому, многому другому - например, не забывать вставлять куда надо get и set. И глаз его приобретет невероятную сноровку в разборе конструкций следующего вида:

model.set( 'nesting', some.get( 'thing' ).get( 'from' ).get( 'another' ).get( 'model );

вместо обычного

model.deep.nesting = some.thing.from.another.model;

Но о вложенных моделях поговорим в другой раз. Давайте для начала разберемся с элементарным - датами. Какой, однако, геморрой на нашу голову на ровном месте, да?

"Не должно быть так", скажет программист, изучающий backbone. И знаете что? Я с ним целиком и полностью согласен. Так быть не должно. Должно быть - вот так: программист берет свой первый вариант, и удалает из него лишнее. Пишет там вместо "new Date()" просто "Date". И волшебство! У него все-превсе сразу получается.

	var User = NestedTypes.Model.extend({
		baseUrl : '/api/users',
	
		defaults : {
			name : "",
			email : "",
			created : Date // use any constructor functions here to create new object by default,..
		}
			
		// ...and you'll get everything for free. No dances.
		// Object may implement 'toJSON' to be serialized properly
		// (as Date does, which is being automatically serialized to ISO)
		// Constructor will be invoked during 'parse'. Works fine with Date.
	});
	
	var SuperUser = User.extend({
		defaults : { // enjoy straightforward attribute inheritance 
			expiresAt : Date
		}
	});
	
	var user = new User(),
	    user2 = new User();
		
		
	// Also.
	user2.created = user.created; // You can now safely forget about get, and set.
	user.created = '2012-12-12 12:12'; // Enjoy automatic type coercion to Date on every 'set'.
	
	user.created = 'hjkfhfjdsk'; // ...and Invalid Date in 'created' (resulting in exception during toJSON) as result of type error.
	
	// The last but not least.
	// This thing, whenever received from server or manually set like this:
	user.set( 'attributeWithoutDefaultValue', '2012-12-12 12:12' )
	// will result in type error in console

Уже неплохо, правда? А ведь мы еще не добрались до nested models и коллекций. Хотите, чтобы было так? Сильно хотите?

Ну хорошо, хорошо. :) Я описал самую малую часть граблей, от которых вас освобождает вот этот мой маленький плагин к backbone:

https://github.com/Volicon/backbone.nestedTypes

Про остальное расскажу потом.

Пантера
2014-04-07 03:37 gaperton

- Смотри, как этот кот рычит. Прям, как пантера. Когда я был в латинской америке, я ухаживал за пантерой.
- Серьезно? Как это было?
- Пантера была в клетке, а я должен был в клетке убирать, и выводить ее гулять в джунгли. На веревке.
- Зачем?
- Ну, пантерам нужно было раз в день гулять. А джунгли - это такая штука, сам понимаешь. Там без мачете хрен проберешься вообще. И пантера убежит. Кошке то чо - она где хочешь пролезет. Поэтому, я ее привязывал веревкой, и каждый день вел гулять.
- Подожди, ты говоришь, что был привязан к пантере веревкой, и вел ее гулять в джунгли?
- Да.
- Но веревка подразумевает, что ты должен за нее иногда дергать? Иначе зачем она?
- Не, дергать за веревку нельзя, если конечно, ты хочешь остаться жив. Находясь в джунглях с пантерой, не стоит ее злить.
- Тогда я вообще ничего не понимаю. Нахрена тебе тогда веревка? А если пантера захочет рвануть в джунгли?
- Тогда ты просто стоишь. И она понимает, что дальше нельзя. Правда, иногда она залезет куда-нибудь, и веревка запутывается. Тогда приходится лезть, и распутывать, прямо перед ее мордой. Очково.
- Это ад, а не работа. И много тебе платили?
- Нет. На самом деле, это я заплатил 500 баксов, чтобы работать на этой работе. Это некоммерческая организация, они занимаются передержкой пантер, пострадавших от рук людей.

И было реально страшно. Нет, я не тот человек, которого легко напугать. В смысле, я много чего видел, когда в боевых частях пехоты служил. Но видишь ли, когда моя пантера в первый раз меня увидела, она укусила меня за бок. А потом, когда я ходил за ней в джунглях, и делал слишком много шума - например, наступал на ветку, то она оборачивалась, и громко на меня шипела. И я каждый раз думал - все, конец.

- Слушай, а какова смертность следящих за пантерами в этой организации?

- Никого. Иначе их бы закрыли. Но потом ничего, она ко мне привыкла, и я чесал ее за ухом.

- Есть большая разница с этим котом?

- Ну, знаешь, когда я вернулся домой - я так удивился. Какой мой кот все-таки маленький .

Backbone.js. Nested Types./
2014-03-31 23:04 gaperton
http://volicon.github.io/backbone.nestedTypes/

My #backbone plugin. Check it out.

It's cool thing, if you don't care about old browsers. IE is supported from version 9 only (due to the heavy use of ECMAScript native properties).

And RequireJS (or other AMD-compatible loader) is required so far. If you don't use it, I highly recommend start doing it today. Because JavaScript is a mess.

Кто, что, где, когда, зачем
2014-03-11 02:07 gaperton
Вдогонку у дискуссии о "хорошем списке задач" у Maxim Dorofeev.

На мой взгляд, нет смысла применять какие-либо методики управления задачами, не имея элементарного навыка ставить сами задачи. И именно этой части уделяется наименьшее внимание. Как это делать?

1) Хорошим принципом, знать и уметь применять который необходимо, является 5W (Что, кто, где, когда, зачем). В идеале - иметь навык формулировать mission statement для задачи в виде одного предложения, отвечающего на все 5 вопросов.

http://en.wikipedia.org/wiki/Five_Ws

В википедии об этом не сказано, однако, 5W также является основной техники приказов, используемой US Marine Corps.

2) Второй полезный навык - уметь формулировать секцию "что" развернуто, в виде списка критериев (чеклиста) наступления момента завершения задачи, допускающих простую проверку. Как я проверю, что задача завершена? Я вообще это сделать могу, это возможно?  "Весь код уже написан, осталось только отладить" - это хороший критерий?

Все остальное от лукавого. Включая S.M.A.R.T. Они автоматически получаются SMART, если следовать двум простым правилам выше.

"Фичи", юзер-стори, и юз-кейсы - не от лукавого, а вполне годные. Это более специфичные для софта способы выразить секцию "Что", иногда вместе с "зачем", и рядом других вопросов (Фичлист, как правило, получается автоматически при выполнении пункта 2).

И вот вам картинка на память - о 5W. Сам придумал. Она какбэ должна намекнуть, что процесс планирования (и формулировки задач) - довольно сложный problem-solving process, имеющий мало общего с рисованием гант-чартов в MS Project. Ошибки в котором обходятся дорого.



Успехов. И чуть не забыл - не начинайте задачу с глаголов. В них нет ничего ни полезного, ни интересного.

О легитимности
2012-07-04 03:52 gaperton
Многие руководители-программисты разных уровней, придя в новую компанию, ощущают недостаток "авторитета" в новой команде. Проявляется это не в том, что их поручений не выполняют, а, как бы это сказать, в том, что их воспринимают со скепсисом. "Ну, мы, конечно, сделаем, но...". В общем, в той или иной степени повергают "авторитет руководителя сомнению".

Поэтому, "авторитет надо заработать". Тут уж кто во что горазд.

Кто-то считает, что должен перемерять подчиненных пиписьками, что он знает больше, и ваще очень умный (разные вещи идут в ход, от технических, до сугубо менеджерского сакрала, вроде PMBoK и прочего балшыта, не имеющего прямого отношения к работе подчиненных, а потому им неизвестного).

Кто-то считает, что необходимо немедленно проявить новообретенную власть, чтоб свои и чужие боялись, и ваще поняли, осознали, сцуко. Встречается такой паттерн поведения - все у вас плохо, и ваще, вы все дураки. Далее, не оправившихся от шока подчиненных заставляют немедленно внедрять новые технологии. Ну, это только один из вариантов.

Кто-то вообще не парится, спокойно занимает должность, и концентрируется на "представительских функциях", политике, и налаживании контактов с начальством.

Не, конечно есть и такие, кто начинает спокойно принимать дела. :) Но мы сейчас не об этом, а о проблеме "авторитета" среди подчиненных, иррациональной по своей природе, и толкающей людей на иррациональные поступки - каждый руководитель, кто менял работу, в той или иной степени с этой проблемой сталкивался.

У этой проблемы есть имя. Если вы это переживали, поздравляю - вы столкнулись с недостатком "легитимности власти". Может-ли это понимание нам дать что-нибудь практически полезного?

Начнем с грустного. Слово "легитимность" относится тому к редкому типу слов, которые все употребляют, но большинство при этом не имеет ни малейшего понятия о том, что это такое (включая современную прессу). Но нам, руководителям, надо знать это точно, ибо оно имеет непосредственное отношение к самой сути власти. Скажу кратко, выделяя главное - длинно вы почитаете в википедиях и словарях:

Легитимность - есть желание людей подчиняться решениям власти при отсутствии принуждения.

Да, именно так. Необходимость принуждения - главнейший индикатор отсутствия легитимности. Возьмем для примера власть банды, захватившей маленький американский городок (сюжет многих голливудских фильмов). Городок живет по правилам, установленным бандой, это да.

В чем основа этой власти? В достаточном количестве вооруженных головорезов, которые в любой момент готовы применить насилие. Однако, уберите их - будут ли граждане готовы следовать решениям главаря банды? Вы бы - последовали? Во-от. Эта власть нелегитимна.

Возьмем другой американский городок из фильмов (ковбои, индейцы, пуф-пуф, и-иии-уии-им - помните тот фильм, где в начале пять минут летает муха, и ничего не происходит?), где граждане выбрали себе шерифа и судью. Готовы ли они подчиняться власти шерифа, и принимать справедливость судебных решений? Интуитивно, на контрасте с предыдущим примером, мы понимаем, что, скорее да.

Последнее, кстати, пример так называемого рационального типа легитимности по Веберу. А вообще, Вебер выделяет целых три типа легитимности. Вам уже интересно, правда? :) Разберем их подробнее:

1) Традиционная легитимность. Деды наши так делали, и мы делать будем. Рюриковичи нами долго правили, старожилы не упомнят, они не подведут. И вообще, власть - она от Бога, а у власти не кто-нибудь, а помазанник божий.

Подождите, подожжите... А царь-то - он ведь эта... ненастоящий!!!

Именно поэтому новая династия, приходящая к власти, частенько переписывала историю. А тех, то не озаботился данной проблемой, ждал epic fail. Иррационально? Да. Но ведь понятно почему?

Вы думаете, это к вам никак не относится, да? :) А таки нет. Когда вы приходите в новую компанию, ваша "стартовая легитимность" обеспечивается легитимностью тех, кто вас нанял. И это все, что у вас в начале есть.

Желающие сразу подчеркнуть перед подчиненными свое единство с "руководящей вертикалью" - в сущности поступают логично. Но в случае, если у вертикали низкая легитимность (а этого новонанятый знать не может) - могут быть нюансы... Неприятные, в первую очередь для вас, ибо руководству легче всего пожертвовать именно вами. Что бы вы не думали - на стартовом этапе вы еще не член банды, а стажер.

2) Легитимность харизматичного лидера. О-о-о, сколько об этом написано. :) А ведь это по сути и есть тот самый "авторитет", который, как считается, вам нужно "заработать". Смотрите, цитирую википедию: "Этот образ непогрешимого, наделенного исключительными качествами человека (харизма) переносится общественным мнением на всю систему власти. Безоговорочно веря всем действиям и замыслам харизматического лидера, люди некритически воспринимают стиль и методы его правления."

Удобно быть [харизматичным] лидером, ничего не скажешь! :) И, кстати, чрезвычайно забавно читать программы курсов по лидерству, привлекающие толпы лузеров :) Не окажись среди них, читатель! Прочти лучше вот эту книгу. "Когда Пфеффер говорит о власти, умные люди прислушиваются". И Пфеффер говорит: избегайте книг и курсов по лидерству! Впрочем, мы отвлеклись.

Зато становится понятно, что люди, объявляющие в начале все говном и немедленно начинающие  революционные мегапроекты, поступают в сущности логично: "Эмоциональный восторг населения, формирующий этот высший авторитет, чаще всего возникает в период революционных перемен, когда рушатся привычные для человека социальные порядки и идеалы и люди не могут опереться ни на бывшие нормы и ценности, ни на только ещё формирующиеся правила политической игры."

Это полезное знание, и полезный инструмент. Который также имеет оборотную сторону.

Правда в том, что этот "восторг" вызвать достаточно легко, и это очень приятно - льстит самолюбию. Но восторг (в вашем случае - высокие изначальные ожидания) - он как маятник. Он обязательно качнется в другую сторону чуть позже, тогда, когда прийдется иметь дело с результатами, и ожидания могут с ними, результатами, не совпасть.

Понимаете, о чем я?

Но мы оставили на последок третий, самый невзрачный на вид тип легитимности. Который, в отличии от предыдущих, способен творить чудеса на ровном месте, и не требует никаких особых условий, чтобы им воспользоваться.

3) Рациональная (демократическая) легитимность.
Она основана на нашей вере в правильность процедуры, посредством которой было получено то решение, которому мы должны подчиниться. Для этого, сами понимаете, процедура должны быть открыта, понятна людям, и они должны верить в ее справедливость - это необходимый минимум.

К примеру. Вы с друзьями, после долгих споров, договорились, что примете решение, куда поедете отдыхать, голосованием. Проголосовали. Да, действительно, в результате, получилось не то, что вам нравится, но - вы подчиняетесь принятому решению без споров и принуждения. Магия!

Доступно? А теперь к делу. Есть широкий спектр методов, которые может использовать руководитель, чтобы одновременно (а) выработать более качественные решения, и (б) обеспечить их легитимность (исполнение без необходимости принуждения), которые используют данный тип легитимности. Что удивительно - вам никаких стартовых условий для этого не требуется, и ничего плохого за это не будет. Я покажу лишь пару примеров.

Допустим, вы хотите ввести новые правила. Пусть это будет, скажем, самое элементарное - стандарт оформления кода.

Из практики известно, что попытки принятия такого стандарта часто сопровождаются бурлением говн, и нулевым результатом. Либо, саботажем при попытке ввести его "волевым решением". В редчайших случаях команде удается прийти к согласию по этой теме самостоятельно, без участия руководителя. И именно поэтому это будет хороший пример.

Начать мы должны с того, чтобы подготовить хоть что-то. Первый вариант стандатра. Любую, простите, хрень.

Не, конечно, мы должны очень сильно стараться, и сильно думать. Просто не надо питать никаких иллюзий, что это годный документ. Это - хрень, как бы вы не старались, запомните это, и примите как аксиому, ибо оно еще не прошло процедуры.

А процедура следующая. Мы созываем экспертный совет, в котором должны присутствовать все заинтересованные лица. И проводим обсуждение "законопроекта" в "трех чтениях". В целом, по своему духу, процесс обсуждения следует инспекциям Фагана, однако, вы, как модератор, допускаете свободные обсуждения между участниками, сохраняя за собой право подводить итог.

На "первом чтении" вы предъявляете плод долгих раздумий (не обязательно своих - вы можете поручить составление стандарта кому-то), и собираете конкретные замечания и вопросы.

На втором, вы представляете исправленный документ (он, скорее всего, будет сильно отличаться от изначального), и собираете уже конкретные замечания к пунктам.

На третьем, если вы сделали все правильно, будут мелкие правки, после чего документ немедленно принимается большинством голосов, что справедливо, учитывая, что у каждого было право и время высказаться.  

Пара советов, которые важны.
- Не пытайтесь собирать сразу слишком большие группы. Начните с частностей. Добейтесь сначала согласия в небольшой группе, и только потом выносите обсуждение на уровень выше. В этом случае, от изначальной группы должен быть выделен "выборщик", который примет участие в прениях на следующем уровне. Вы не можете представлять интересы этой группы, вы модератор.
- Не пытайтесь делать документ слишком детальным, обрабатыващим все ситуации и случаи. Гораздо больше пользы в простых базовых правилах, относительно которых все согласны, чем в сложных, но нелигитимных правилах, исполнение которых сложно проверить, и которые все один хер будут нарушать. Смело исключайте из документа спорные пункты, которые не принципиальны, или принципиальность которых сомнительна.

Например, говоря о кодстандарте - он не должен содержать советов о правильном программировании и проектировании. Это стандарт оформления кода, а не руководство, как его правильно писать. Тем не менее, эти дурацкие пункты всегда там почему-то оказываются. Резать, к чертям. Не дожидаясь перитонита. Умникам, пытающимся заставить через кодстандарт всех писать код "правильно", ответьте просто - "это тема другого, отдельного документа, который мы обсудим потом". 

Этот процесс, "три чтения", начиная с небольших групп, а также указанные рекомендации, прекрасно работает при принятии любых правил и регламентов. И прекрасно помогает вам не оказаться в дураках, и не потерять авторитет, ибо вы столкнетесь с нюансами на фазе обсуждения, а не "в бою".

Вторая ситуация. Предположим, вы руководитель отдела, и вам надо назначить тимлида. Традиционно, тимлид назначается из тех, кто сильнее других хочет им быть. И получит весь набор проблем с легитимностью, помноженных на полное отсутствие необходимых знаний и опыта для руководящей работы. Вы ведь знаете, какой тренинг обычно проходят тимлиды. Он, как говорит Эд Йордон, обычно состоит из двух слов. "Good luck". Э, это в английском - из двух. У нас вообще из одного.

Избежать нам этого поможет вовсе не то, что вы подумали. Не выборы, нет. :) А аттестация по системе 360. Вы проводите опрос коллег, кто с кем работал. На каждого сотрудника должны заполнять анкеты не менее 4-5 человек. Опрос должен быть анонимным (никто не видит индивидуальных ответов), и приватным (общий результат видит только аттестуемый, и руководитель).

Анкета состоит из серии вопросов, на каждый из которых есть три ответа - два полярных, и один нейтральный посередине. Вопросы должны касаться всех важных качеств разработчика и тимлида (эти качества - отдельный разговор, как и устройство самого опроса), включая способность к общению.

И, вы обязательно включаете в список вопросов один вопрос. Что-то вроде "если он станет моим начальником, то я... (1) решу, что это в принципе неплохо (2) ну станет, и станет, работать можно (3) буду против". Этот вопрос измеряет авторитет в роли руководителя. То есть, стартовую легитимность.

Ориентируясь на средние баллы анкет, вы сможете избежать грубых ляпов при назначении, и следующих из них проблем. И я вам скажу - не стоит ссать против ветра, и назначать в тимлиды кренделя с низкой "легитимностью", как бы лично вам он не нравился.

Это "демократические выборы"? Нет, конечно. Но это "демократичный" элемент обратной связи, весьма редкий в наших широтах, способный помочь вам не оказаться в дураках. И конечно, он сработает только тогда, когда люди будут понимать процедуру, и верить, что она (1) анонимна, и (2) приватна.

По опыту скажу, такие интересные и неожиданные сюрпризы иногда 360 показывает. Ради этого и используем.

В завершение, добавлю, что не следует путать легитимность с "легальностью". Легальность означает "законность", и это юридическая категория. В то время, как легитимность категория не юридическая, а социологическая. Власть (или отдельное решение) может быть легальной, но нелигитимной, и наоборот.

И еще. Данный пост служит цели не быть руководством, а сформировать основу для понимания предмета, и расширить границы вашего воображения. Дерзайте.

ЗЫ: И я искренне надеюсь, что теперь вы станете чуточку лучше разбираться в политике. :) Хотя это уж точно не было целью данного поста.  

О типичном вопросе начинающих руководителей
2012-06-18 02:50 gaperton
Из дискуссии на РСДН. Вопрос кажется мне важным (хоть и элементарным), публикую здесь. Черным - мои ответы, здесь я склеил несколько сообщений, чтобы был понятен контекст. Курсивом - мои комментарии, сделанные сейчас.

Началось все с этого. Безусловно, вы подобные песни не раз слышали, как и я. Там был эпичный пост, из которого содержательного были два ключевых слова (PMBoK и PRINCE2), и вот это предложение:

S>>> "Есть мнение, что проекты они и в африке проекты. И качественный ПМ одинаково хорошо разрулит проект разработки новой соц. сети и проект по постройке нового стадиона"
 
S_D>>Оно конечно качественный пм может и разрулит проект стадиона...

Вы всерьез готовы предположить, что "качественный ПМ" может что-то "разрулить" в проекте стадиона, не зная профильных ГОСТов, не имея понятия о том, что такое СНИП, не представляя основ техпроцесса, особенностей логистики данного типа проектов, и типовых проблем проблем строительства?  Правда? 

S>если ПМу нужно знать ГОСТы, то например, кирпичи класть ему тоже нужно уметь?


Вопрос типичен для начинающих руководителей. Им кажется, что надо либо уметь делать всю работу подчиненных лучше подчиненных, либо напротив, нихрена в ней не понимать, сконцентрировавшись на астронавтике вроде PMBoK.

Руководитель не делает работу за подчиненных, а направляет ее, принимая ключевые решения и неся ответственность за результат. Проработкой частных вопросов, разумеется, занимаются специалисты по заданию руководителя, которое он должен вовремя дать (и суметь сформулировать).

Как мои читатели знают по моим постам (и выступлениям на конференциях), я последние несколько лет уделял много внимания изучению военной традиции руководства (разных стран), и отношусь к ней с большим уважением.

Так вот, в качестве иллюстрации к предыдущему абзацу, добавлю: штаб готовит для руководителя пространство решений. А выбирает из него - руководитель (про "пространство решений" читаем мою презентацию два поста назад).

Но для того, чтобы группа специалистов прошерстила пространство решений, руководитель должен быть в состоянии поставить штабу внятную цель, как вы считаете? Ну или, хотя бы, как минимум говорить с ним на общем языке (я уж молчу о формулировке критериев успеха и тонкостях вроде "тактике миссиионного типа", о которых я много писал)?

Для этого, ему необходимо иметь хорошее общее представление о широком перечне вещей, относящихся к процессу работы подчиненных, потребительских ТТХ результата, вопросам контроля его качества, и типовых проблем. В частности, о том, что такое кладка кирпичей, как устроен техпроцесс кладки в целом, каковы его параметры (включая экономические), какова логистика этого процесса, и какие факторы влияют на качество кладки.

Иначе ваш менеджер превратится в дрессированную мартышку, производящую никому не нужные документы оторванные от реальности. Кому к чертям нужен "менеджер", который ни одного содержательного решения в проекте принять не в состоянии?

Ну например, может быть, мы, из соображений целей проекта, вообще предпочтем кирпичам монолит. Да-да, наш стадион проектируется с нуля, это вам не типовой панельный дом. Может быть, с монолитом будет проще логистика, окажется дешевле, и меньше рисков в нашем конкретном проекте?

Напомню один фундаментальный принцип, о котором я, кажется, ни разу явно не писал. А это очень важно. Ответственность всегда должна находится в равновесии с полномочиями. Одна из частностей, следующая из этого принципа, - мы не можем нести ответственность за то, на что реально не можем повлиять.

Не, разумеется, это во власти руководителя - "делегировать" (или, в данном случае, бросить на самотек) принятие ключевых решений, непосредственно влияющих на успех проекта. И это даже нормально, если руководитель не начинает считает, что это освобождает его от ответственности за последствия этих решений, принятых таким образом.

Вопрос только в том, насколько это решение в данном случае является вынужденным - делегировать. Хочет-ли руководитель сделать ставку на инициативу подчиненных? Или он просто нихера не в состоянии ни сформулировать задание своему "штабу", ни выбрать вариант из "пространства решений"? Имеет-ли он вообще какой-то выбор, кодга выполняет "делегирование" принятия ключевых решений?

Кому как, а мне такие "руководители" не нужны. И совершенно не важно, могут-ли они цитировать наизусть PMBoK с любой названной страницы без единой ошибки.

Что, кстати, совершенно не отменяет необходимости знать и понимать "классику" своей профессии. Просто необходимо понимать, что решающие усилия (опять военный термин - т.н. main effort, усилия, успех которых решает исход всей операции) имеют фокус не на соблюдении методик, а на результате проекта и людях, которые его делают.

О модерировании и мудаках
2012-04-14 02:14 gaperton
На всякий случай, я хочу разъяснить принципы, по которым я выполняю модерацию комментариев в своем журнале. А то, думаю, многим не понятно. И в самом деле, принципы таковы, что по фактам применения порой сложно догадаться, почему кто-то быстро, после пары комментариев, попадает в бан.

Это оборотная сторона эффективности данных правил, ибо правила направленны на то, чтобы лишить мудака возможности оставлять комментарии задолго до того, как он оставил у вас в в комментах огромные кучи бессмысленного флуда, в которых тонут содержательные комментарии других участников.

Зачем банить мудаков, и что такого плохого они делают? И главное, как отличать мудаков от обычных людей? Давайте разберем тему сетевых мудаков подробнее. Это вовсе не сложный вопрос. Он простой. Ибо...

1) ...истинный мудак виден с первого комментария.

Мудак всеми средствами стремится вас "зацепить", перейдя на личности, так как другим способом привлечь чужое внимание он просто не способен. Ему нечего сказать по существу вопроса. Ему похрен на то, что вы хотели сказать - ему интересно, к чему можно придраться (не путать с "чем можно поспорить"), а для этого понимать, что вы написали, и о чем, ему не обязательно.

Все перечисленное подлинный мудак проявляет в своем первом же комментарии. Здесь все просто - не надо отвечать ему "ты хуй". Надо его забанить сразу.

Поэтому, золотое антимудацкое правило звучит так - любой перевод разговора на личности запрещен, обсуждается содержимое поста. Оно отлично отсекает мудаков - они по натуре своей не способны обсуждать содержимое поста. 

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

Поэтому, опытный мудак усложняет вам задачу, и...
2) ...в первом же комментарии он очень загадочен.

Он сразу дает вам понять, что считает креатив говном, и он уже от этого сморщил жопу. Но никаким образом не скажет, почему - он хочет, чтобы вы спросили его об этом.

- Ах, почему же вам не нравится мой пост? - ждут они вопроса от вас.

Опытный мудак знает, что вы сомневаетесь, так ли у вас в посте все хорошо. И так как мы редко пишем то, в чем на 100% уверены, они играет на этом страхе. Если вы ответили в приведенном выше ключе - вы уже попали в ловушку. Мудак с огромным удовольствием выльет вам на уши кучу хуйни. Но так просто забанить его вы уже не сможете - вы же сами просили.

Поэтому, второе правило:
- Если вы видите комментарий с явной или скрытой претензией, при одновременном отсутствии конкретики, провоцирующий вас спросить, "ну почему же" - это 80% индикатор наличия мудака. Мудак загадочен не просто так. Он не хочет, чтобы вы поняли, что он нихуя не понял вашего поста, и что он не хочет ничего понимать. Именно поэтому он и не пишет конкретики.

Иногда, мудак со стажем может дать вам полунамек, в каком месте он думает, что у вас креатив говно. Так как он нихуя не понял - это ему сильно помогает. Он рассчитывает, что вы продумаете его ходы за него, и сами выдумаете, в чем вы не правы. Вы-то, в отличии он него, разбираетесь в том, что говорите.
- Никогда не додумывайте за мудака, почему он думает, что вы не правы. Спросите его прямо. И он вам опять не ответит по существу.

Иногда опытный мудак идет дальше, и сходу утверждает, что вы сказали хуйню, которую вы не говорили (для чего ему опять-таки не надо понимать ваш пост). Если вы, не дай бог, начнете оправдываться, и объяснять, что вы имели в виду совсем другое, то вы совершите вторую ошибку. Вы дадите мудаку повод вылить вам на уши еще один ушат хуйни, вдвое больше предыдущего.
- ...никогда не оправдывайтесь! Это ровно то, что от вас хочет мудак.

Однако, 80% это вовсе не 100%, и вы можете принять за мудака человека, не умеющего писать комментарии. Или тупо не понявшего поста.

Чтобы в полной мере овладеть техникой превентивного бана мудаков, вы должны освоить действительно продвинутую технику. Являющуюся, также, must know в контексте темных искусств. А именно...

3) ...обращать внимание не на текст комментария (действие), а на мотив, заставляющий их оставлять (причину).

Хорошая новость в том, что мотив достаточно надежно вычисляется именно по первым двум комментариям.

В первом комментарии мудака вообще никто за язык не тянул - это проявление его свободы воли. И оно ценно для определения мотива. Задумайтесь: что может заставить человека написать это? Если это непонятно, то для диагностики вам нужен второй комментарий. Для этого надо оставить ответ на первый.

Важно в ответе на первый комментарий не давать мудаку "корма", и быть нейтральным. В этом случае, вы не даете мудаку лишних поводов писать комментарии, кроме исходных, и во втором комментарии наблюдаете его мотив. 99% "хитрых" мудаков, маскирующихся на первом комментарии, палятся на втором. Они рады. С ними же заговорили! А это для них уже маленькая победа.

Так каков же мотив мудака?

Мудак по сути своей асоциален, уныл, не интересен, и глуп. И в глубине души ощущает себя таковым. Мудака это гнетет, но сеть дает ему охуенную возможность лезть к вам в журнал, и навязывать свое общество. Находясь среди нормальных людей, он таковым себя не чувствует. Он хочет вашего внимания любой ценой. Мудак начисто лишен чувства такта - он эгоистичен, ему насрать на вас, и на то, что вы думаете и чувствуете.

Когда мудак доказывает вам, что вы - пидарас (это его способ общения с внешним миром), это, по мнению мудака, автоматически символизирует, что он, мудак - вовсе не мудак, а целый Д'Артаньян. Если вы начали с ним общаться, мудак испытывает чувство эйфории, и временного облегчения, забывая о том, что он мудак.

В сущности, в этом состоит единственный смысл его существования - он не только не производит осмысленный контент, но и не потребляет его. Но психику не обманешь. Скоро эйфория проходит, и он чувствует, что он, в сущности как был мудаком, так и остался. И если вы его не забанили, он опять лезет к вам в журнал. А хуле?

Иногда мудаки думают, что они вовсе не мудаки, а "тролли". Это тоже помогает им забыть о том, что они мудаки. Но так как "тролли" выглядят и ведут себя ровно так же, как мудаки, нас с вами эта тонкая разница совершенно не интересует. Тем более, что мотив у этих двух подвидов совершенно одинаков, как и ваша реакция на них.

Короче. Баня мудаков превентивно, вы сохраняете себе кучу времени, нервов, и мыслительной энергии, ибо не отвлекаетесь на словесный онанизм. Затяжные треды с людьми, которых вы все равно в конце концов забаните, когда поймете, что их единственная цель потратить ваше время с целью заебать вас - глупая трата времени с отрицательным профитом.

Кроме того, если вы думаете, что читателям вашего журнала интересно читать ваши препирательства с мудаками - вы сильно ошибаетесь. Всем похуй.

Зато всего один мудак способен засрать ваши комменты таким объемом хуйни, превратив их в помойку, что в них потонут комментарии нормальных людей, и другие нормальные люди не смогут их в этой помойке найти.

Кроме того, нельзя не отметить, что баня мудака, вы боретесь с глобальным потеплением, сокращая расход памяти и процессоров серверной фермы LJ, что уменьшает потребление энергии и выделение тепла. Я уж молчу о ресурсе клавиатуры вашего ноутбука.

Сделай мир лучше и экологичнее. Забань мудака.

Моя презентация на Software People 2012
2012-04-12 01:30 gaperton
Здесь

Слайды, в принципе, информативны, и содержат основные тезисы. Но запись лучше. Видеозапись будет доступна позднее на сайте конференции.

Пинок под зад
2012-03-30 21:18 gaperton
В конце 90-х и начале 2000-х, когда мы с коллегами-программистами начинали всерьез интересоваться проблемами организации разработки ПО, годной литературы на русском языке было очень мало, а интернет в России еще под стол пешком ходил. Но это не означает, что не было книг о Методологиях. И вера в силу методологий и процессов была невероятно высока.

В целом, эта вера обратно пропорциональна знаниям и опыту. Ну да, мы-то не умеем и не знаем, как правильно, и мы знаем, что мы не знаем, но мы верим, что где-то существуют те, кто знают, и есть что-то вроде алгоритма, как надо делать. RUP, MSF, CMM, разные нотации диаграмм, методы, подходы. Надо изучать и пробовать. Делай так, в таком порядке - и все будет хорошо.

Но понимали ли мы, почему надо делать так, как пишут в "учебниках"? Почему оно работает, когда работает, и наоборот?

Ну разумеется нет, откуда? Для этого требуется кое-что большее, чем ум, и свежая голова.


- Тим, скажи пожалуйста, что главное в работе консультанта твоего класса, что делает его хорошим консультантом?
- Возраст.

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

Говоря о проблемах организации разработки - только примерив информацию на свой опыт, можно что-то понять. Большой возраст, конечно, сам по себе не означает большого опыта. Но зато молодость точно означает его отсутствие, со всеми вытекающими - отсутствием понимания, но верой в авторитеты. Надо же на что-то полагаться, правильно?

Но главная проблема не в отсутствии понимания. Она в том, что ты не осознаешь его глубину и границы, и, таким образом, не замечая того, лишаешь себя возможности набирать опыт. Ведь человек видит то, что хочет видеть. И не увидит того, что нужно, если не знает, куда смотреть.

Но вот однажды один из коллег притащил оригинал книги Тома ДеМарко и Тима Листера Peopleware, и сказал - читайте парни, это круто. Мы читаем, и у нас взрываются мозги. В ошметки.

Ибо, авторы Peopleware, не обладавшие тогда в наших глазах авторитетом (ну еще бы, они ни одной известной нам Методологии не придумали) говорят совершенно удивительные вещи относительно того, во что мы тупо верим:

- CMM - штука хорошая и важная для индустрии. Но тезис о снижении рисков - чушь. Надо-ли стремиться к высоким уровням? Нет, не стоит.
- Методологии вредны. То есть, цели, которые они декларируют, очень хороши, но методы достижения этих целей таковы, что они либо не приводят к результату, либо делают это крайне болезненным образом.
- Программисты (по крайней мере, чего-то стоящие программисты) и так великолепно мотивированы, нехрен к ним приставать с этой менеджерской ерундой. А вот организация рабочего пространства, и командная работа действительно важны.
- Не верьте тем, кто рассказывает про надежные методы "построить команду". Команда не дом, а люди не кирпичи.
- Зато достоверно известны способы угандошить команду в зародыше. И факторы, которые могут косвенно способствовать ее образованию.
- ...

Не-не-не. Это сейчас, когда Peopleware стало "частью дискурса", можно себе позволить в нежном возрасте пролистать их книгу, нихрена не понять, а потом писать в форумах комменты в стиле "да я с рождения это знал". "Да неужели это не очевидно". "Да я настолько крутой, что ничего нового для себя не нашел, так себе книга". И прочий набор глупостей.

А тогда было не так. Нам повезло - читая ДеМарко и Листера, мы не знали, кто они такие, и читали потому, что интересно. "Кто эти замечательные парни?" - думали мы, жадно читая книгу.

Еще бы. Ведь она была написана простым и ярким языком, искренне апеллировала к личному опыту и чувственному восприятию, была логична, где надо, не содержала натяжек и искусственных допущений.

И главное - была, в отличии от монотонных и унылых методологий, живой. Она, собственно, ничему не учила. Она, так ненавязчиво, приглашала к беседе.

И она настолько сильно входила в конфликт с нашей картиной мира, что произвела эффект "хлопка одной ладонью". Том и Тим буквально ткнули нас носом в границы нашего воображения, и любезно помогли переступить через них, дав мощный пинок под зад. И мы начали размышлять.

***

Через десять лет, у нас появился собственный опыт и понимание. Свои суждения, не являющиеся калькой с авторитетов. Свои методы. Иногда они работают великолепно, иногда не очень. Бывает, что мы пишем о них в блогах. Делимся ими друг с другом - публикуем статьи, выступаем на конференциях, и пр.

И вот, авторы Peopleware, наконец, приезжают в Москву с трехдневным семинаром. Вместе еще с тремя замечательными людьми.

Да, конечно же, мы знаем, о чем они хотят нам рассказать. Теперь, мы можем себе позволить не просто их послушать, а аргументированно не согласиться с ними в некоторых деталях. И это стало возможным вовсе не потому, что мы стали старше.

А благодаря тому самому ласковому пинку под зад, который они нам когда-то дали.

Здесь мы переходим к самой сути общения со специалистами класса "гуру". Когда они в деле, суть вовсе не в освоении какой-то особой техники, или методов, - то есть, вовсе не в том, чтобы вы научились что-то повторять. И не в том, что они сообщают вам некую информацию, которой вы раньше не слышали и не видели.

Это все второстепенно, как рябь на воде. Главное в том, что учителя расширят границы нашего воображения. Это неоценимо. Если у нас, конечно, оно вообще есть - воображение. За этим я и шел на эту конференцию. И разумеется, затем, чтобы сказать им спасибо за "пинок".

It's a honor for me to meet you, Tom.



























P.S.: Слева направо. Джеймс и Сьюзан Робертсоны. Тим Листер. Том ДеМарко. И Питер Хрюшка.
Atlantic Systems Guild почти в полном составе, за исключением Стива Мак-Менамина.

Впрочем, в одной из фотографий для него специально оставили место ближе к серединке, чтобы потом добавить его фотошопом :).

Мой доклад на SoftwarePeople
2012-03-23 01:15 gaperton
Это будет доклад о том, что вы всегда хотели знать, но боялись спросить. Это доклад о проектировании. Главных тезиса два.

1) Хорошо организованная группа профессионалов всегда проектирует лучше, чем один мегаумный архитектор. Я собираюсь это настолько хорошо обосновать, что это близко к "доказать".
2) Менеджер может эффективно направлять и контролировать процесс проектирования, в том числе надежно отмечать его прогресс. Я собираюсь не просто это сказать, а наглядно и просто показать - как, так, что вы сможете это повторить. Ведь понимание требуется для действия - или нафиг оно не нужно, такое негодное понимание.

В сущности, без участия менеджера (руководителя группы, отдела, whatever) групповой процесс проектирования невозможен. Это не основная мысль, это то, что станет понятно по ходу изложения.

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

P.S.: Мне повезло - в разные моменты жизни мне приходилось лично заниматься всеми из перечисленных, непохожими друг на друга, областями. :) При этом, мне не придется рассказывать вам про них, и пугать вас тем, в чем вы не разбираетесь.

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

P.P.S.: На тот случай, если кто не знает, что такое SoftwarePeople. www.softwarepeople.ru. Регистируйтесь.