Кто помнит шуточную историю о том как бакалавр, магистр и PhD выполняют проекты?

Question

[Санжар Аубакиров]

У меня возник спор о том, насколько детализированно нужно продумывать новый проект. Обычно это палка о двух концах, с одной стороны ты рискуешь продумывать проект вечно и ничего так и не начать. С другой стороны быстро наговнокодить и получить рабочий проект с кучей архитектурных ошибок. Помню в универе нам рассказывали шуточную историю о том как бакалвр, магистр и PhD взялись за одну и ту же задачу (что-то вроде вкрутить лампочку). К сожалению я запомнил только суть, но саму историю не помню. Она чем-то напоминает вот эту историю bash.im/quote/420672.

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

Вопроса у меня два

1. Кто-то помнит всю историю?
   
2. Есть ли на хабре статьи, где о подобных рассуждениях можно почитать?
   

Answer 1

[mamkaololosha]

Бросивший универ после 1 курса и 7 лет на продакшене пишет лучше их всех.

Comments

[Санжар Аубакиров]

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

Answer 2

[Александр Скуснов]

Я видел два суждения (противоположные).
Первое (структурный метод программирования): пишите сразу готовую программу (типа begin end), вместо нерабочих кусков используйте заглушки, главное, чтобы программа сразу работала. От себя добавлю: задание надо писать по-английски, чтобы потом эту фразу заменить на функцию (готовую из библиотеки или свою, которую надо будет написать). Ещё видел совет: побольше использовать классы (и интерфейсы). Затем остаётся только пошаговая детализация. Хотя видел ещё совет: заранее проработать структуру, напр., на UML.

Второй совет от курсов МФТИ по Ардуино: не начинать проект без детальной проработки. Ведущий - практик, поэтому плохое не посоветует.

Comments

[Сергей Протько]

Мне больше нравится мысль прагматичного Дэйва Томаса, о том что UML убило у людей представление о том что такое объектно-ориентированное проектирование. Если делать как вы описали получится очень плохо.

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

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

[Adamos]

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

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

[Санжар Аубакиров]

Сергей Протько: Мне нравится эта мысль.

[copal]

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

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

[Сергей Протько]

copal:

const eventHandlers = {}; // это просто структурка, хэш-мэпа, а не "объект".

export function addEventListener(name, handler) {
    if (eventHandlers.hasOwnProperty(name)) {
        eventHandlers[name] = []; // опять же просто структурка, никакого ООП 
    }
    eventHandlers[name].push(handler);
}

export function trigger(name, obj) {
    (eventHandlers[name] || []).forEach((handler) => handler(obj));
}

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

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

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

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

опишите свой текущий подход и как хотите поменять. В моем случае весь подход к тестрированию сводится к:

- пирамида тестов - много юнит тестов, мало интеграционных и еще меньше e2e, причем тесты фреймворка тоже считаются, и если у нас нет сложной бизнес логики и мы во всю используем мощь фреймворка - то нам остается писать только интеграционные/e2e тесты. Ну то есть вопрос в том, что мы делаем и зачем. Многие разработчики когда берут в руки подходы вроде TDD начинают практиковать их на чем-то простом и на этом проигрывают, отсуда же и критика в отношении TDD, что разработчики начинают плодить усложненный дизайн приложения. Тесты ради тестов. А есть же ATDD, например. Для простых проектов идеально. Хотя именно для обучения TDD прекрасен.
- не привязываться к реализации - тоже типичная проблема у новичков в тестировании. Слишком много моков, тесты детально знают реализацию тестирумых объектов, что означает, что на каждый чих приходится править тесты, что сильно усложняет их поддержку и т.д. Тесты должны быть простыми и удобными в написании/поддержки. Это так же тригер к тому, что с вашим тестируемым кодом что-то не так, выявляются симптомы и т.д.
- уметь составлять тестовые сценарии - тут многому можно у QA поучиться, как пограничные случаи искать, как составлять тест кейсы и т.д.

[copal]

Сергей Протько: а что объект который принимает Ваш export за объект тоже не считается? И константа разве это не инкапсуляция свойства в этом объекте? ооп это не класс, ооп это объект и в Вашем примере таких много.

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

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

[Сергей Протько]

copal: нет, это не объект, это область видимости переменной, а export это так же не объект, это просто экспорт, по аналогии с return по сути.

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

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

написал класс С для его тестирования использовал А и В

Это как, простите? Ну то есть, раскройте мысль, можете код привести если не сложно...

А покрыл, В покрыл, С покрываю с классами А и B

Опять же, о чем вы? Вы не тестируете объект C поскольку покрыты объекты A и B? или вы используете моки? Или вы используете в тестах для C объекты A и B? В любом случае вы покрываете тестами C. что при этом используется и как идет покрытие кода тестами - это детали реализации.

чтобы они в контексте всех трех классов показывали причину ошибки

Это называется "интеграционные тесты". Вообще опять же, описанная вами проблема - это code smell, что-то у вас не так.

Я сейчас понял что наследовать тесты не получится, по этому я полностью от них буду отказываться.

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

[copal]

Сергей Протько: а мне кажется что экспорт это как раз объект. Ведь синтаксис {a, b} from 'file' это всего лишь кортеж, который можно было бы записать так let {a, b} = {a: ..., b:...}

export default class LifeCycleService {
    protected animator: EventEmitter;
    protected entitySystemMediator: EntitySystemMediatorService;

    protected destroyAll: EntityVO[] = [];

    public domElementToEntityVOMap: Map<HTMLElement, EntityVO> = new Map();

    constructor(animator: EventEmitter, entitySystemMediator: EntitySystemMediatorService) {
        this.animator = animator;
        this.entitySystemMediator = entitySystemMediator;
    }

    protected animator_exitFrameHandler = ()=> {
    };

    public create(entityVO: EntityVO): void {
    }
    public destroy(entityVO: EntityVO): void {
    }

    public installLayer(entityVO: EntityVO, layer: Layer): LifeCycleService {
        return this;
    }
    public uninstallLayer(entityVO: EntityVO, layer: Layer): LifeCycleService {
        return this;
    }
    public reinstallLayer(entityVO: EntityVO, layer: Layer): LifeCycleService {
        return this;
    }
}

describe('[test Layer] >', function(){
    const NUM_CHILDREN: number = 5;
    const RANDOM_CHILD: number = 2;
    const DEPTH: number = 5;

    let layer: Layer;
    let layerFromMiddle: Layer;
    let elementHashContainer: ElementHashContainer;
    let element: Element;
    let children: Layer[];
    let composition: Layer;


    beforeAll(function(){
        element = createElementForElementHashContainer();
        elementHashContainer = createElementHashContainer(element);
    });


    describe('create instance and props >', function(){
        it('create instance', function(){
            expect(()=>layer = new Layer(elementHashContainer)).not.toThrow();
        });
    });

    describe('operations with children layers >', function(){
        beforeAll(function(){
            children = createLayerWithNullInConstructor(NUM_CHILDREN);
        });
        afterAll(function(){
            children = null;
        });



        it('insertLayer', function(){
            expect(()=> children.map((item:Layer)=>layer.insertLayer(item))).not.toThrow();
        });
        it('comparison length', function(){
            expect(layer.numChildren).toEqual(children.length);
        });
        it('getChildrenAt', function(){
            expect(layer.getChildAt(RANDOM_CHILD)).toEqual(children[RANDOM_CHILD]);
        });
        it('removeLayer', function(){
            expect(()=>children.map(item => layer.removeLayer(item))).not.toThrow();
        });
        it('comparison length', function(){
            expect(layer.numChildren).toEqual(0);
        });
    });
    describe('change child composition layer >', function(){
        beforeAll(function(){
            children = createLayerWithNullInConstructor(NUM_CHILDREN);
            composition = createCompositionLayer(children);

            layerFromMiddle = children[RANDOM_CHILD];

            layer.isRoot = true;

            spyOn(Layer, 'informRootAboutChangeTree').and.callThrough();
            spyOn(layer, 'rebuildLayer').and.callThrough();
        });
        afterAll(function(){
            children = null;
            composition = null;

            layerFromMiddle = null;

            layer.isRoot = true;

            spyOn(Layer, 'informRootAboutChangeTree').and.callThrough();
            spyOn(layer, 'rebuildLayer').and.callThrough();
        });


        it('check depth', function(){
            expect(getDepthComposition(composition)).toEqual(DEPTH);
        });
        it('check count', function(){
            expect(getCountComposition(composition)).toEqual(NUM_CHILDREN);
        });
        it('layerFromMiddle child', function(){
            expect(layerFromMiddle.numChildren).toEqual(1);
        });
    });
});

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

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

[Сергей Протько]

copal: https://www.youtube.com/watch?v=t86v3N4OshQ - может будет интересно, посмотреть расслабиться.

По тесам чуть позже отпишу или милости прошу в личку (gitter, vk)

Answer 3

[Saboteur]

https://geektimes.ru/post/268802/

Про "усложнителей".

А вообще нельзя сказать "насколько детализировано описывать" в общем.

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

Comments

[Санжар Аубакиров]

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

[Saboteur]

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

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