Pull to refresh
15
0
debesha @debesha

User

Send message

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


Если файнал интервью (у нас их два), то подготовка к нему не меньше 30 минут, а желательно час.

Есть чувство, что люди, жившие только в России, из всего этого подробного текста могут распарсить только машину и квартиру.


Прямо по Булгакову

Совершенно типичное начало. Оперейшнс и сейлс, спредшитс, совершенно рядовой умелец, макросы, парсинг хтмл через яваскрипт плагин — вот это всё.


Поступок не мудака раз — делится со всеми, произвольность растёт.


Его запоминает начальница (непрямая, через два звена).


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


Тут большая начальница идёт к директору айти и его переводят в Айти. Полставки QA, полставки поддержка макросов.


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


Потом он пришёл в мою команду как джун-qa, за полгода стал отличным QA. За это же время все свои макросы перевёл в гитхаб, задокументировал, фронтендеры порефакторели это все.
Продакт был в эйфории — чувак из сейлс часто мог лучше объяснить проблему, чем его начальники на митингах. Плюс прекрасно понимал то, что тестил.


Потом, правда, все равно ушёл. Ну мы и не в обиде — и он нам дал многое, и мы ему в итоге.

У меня аналогичная история со счастливым концом. А конец счастливый потому, что никто себя как мудак не вёл и все решения были приняты правильно (я считаю).

Немного переходит в религиозный спор, не хочу настаивать.
> ParselInterface могут(?) реализовывать UrgentInterface
Вообще-то interface segregation principle как раз о том, что могут. Парсел это парсел, урджент это урджент. Друг другу они мешать не должны.

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

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

Т.е. говоря кодом, одновременно с ParselProcessor, реализующим ParselProcessorInterface должен появиться UrgentParselAwareProcessor, реализующий тот же интерфейс и он инджектится вместо существующего ParselProcessor
Ну конечно not modified. Если был класс, который работал с массивом ParselInterface, он будет всё так же работать с массивом ParselInterface и поддерживать все существующие к этому моменту фичи.

Появление нового интерфейса (и нового кода, знающего, как работать с ним) не требует ни одного изменения в существующем коде и существующих features.

В чем violation?
Да, действительно. Но не суть. Может быть и пустым интерфейс, а может содержать специфические для urgent функции
Не понимаю, почему тут нужно жертвовать чем-то.
В рамках описанной эволюции всё делается и SOLID и DRY

Я переведу это в PHP, но суть не меняется.
Сначала была просто посылка.
interface ParselInterface {

  public function getBarcode() : string;
  public function setBarcode(string $barcode);
}

class Parsel implements ParselInterface {

  public function getBarcode() : string {...};
  public function setBarcode(string $barcode) {...};
}


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

interface ParselInterface {

  public function getBarcode() : string;
  public function setBarcode(string $barcode);
}

class Parsel implements ParselInterface {

  public function getBarcode() : string {...};
  public function setBarcode(string $barcode) {...};
}

interface UrgentInterface {
  public function isUrgent() : bool;
}

class UrgentParsel extends Parsel implements UrgentInterface {
  public function isUrgent() : bool {return $this->isUrgent;}
}


Что там дальше идёт? Доставка реципиенту? Тут нужно уточнить поведение, и либо мы расширяем базовый интерфейс ParselInterface (если фича общая для всех посылок), либо добавляем новый. Соответсвенно, имплементация будет или на уровне родительского Parsel, либо нет. Допустим, первое.

Наш код будет уже
interface ParselInterface {

  public function getBarcode() : string;
  public function setBarcode(string $barcode);
  public function arrivedToRecipient();
}

class Parsel implements ParselInterface {

  public function getBarcode() : string {...};
  public function setBarcode(string $barcode) {...};
  public function arrivedToRecipient() {...};
}

interface UrgentInterface {
  public function isUrgent() : bool;
}

class UrgentParsel extends Parsel implements UrgentInterface {
  public function isUrgent() : bool {return $this->isUrgent;}
}


И никакого нарушения тут нет. arrivedToRecipient добавился к UrgentParsel, и изменения его текущего поведения не произошло. Extended, but not modified.

А уже после этого — нельзя просто так менять arrivedToRecipient(). Как раз таки потому что O.

Где тут что нарушается?

У меня с моими 3 годами работы в Берлине взгляд на все почти противоположный.


Особенно шокировало что тимлидом нельзя стать без знания немецкого.


Я, если честно, знаю около 15-20 тимлидов в Германии, и среди них, по-моему, ни одного немца. И ни одного даже говорящего по-немецки

Это не противоречит друг другу. ETF — это тип ценных бумаг (индексный фонд), а Vanguard — компания, которая его создала.
Существует, наверное, сотни компаний, выпускающих ETF на основе SP500, SPY (это что-то типа айди) — самый первый и самый крупный из них, создан компанией SPDR. У VOO, видимо, ниже комиссия (хотя у всех ETF она всегда невысока)

Он уже там.

Я не стал это упоминать, но в инструкция по установке в гитхабе использует composer, т.е. это значит что бандл уже в пакаджисте.
Да, я хочу попробовать это сделать.

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

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

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

Т.е. было обращение, допуcтим,
$record = $entity->getRecordByKey($key);

внутри которой было

public funtion getRecordByKey($key) {return $this->records[$key]; }

Если нужный record к моменту вызова getRecordByKey не был готов, но доктрин лез и выбирал все связанные records из базы.

И это правильно. К Доктрин претензий нет, и отработал он отлично. Но при этом такую ошибку допутить легко (ну не знаю, обращение к null-объекту у всех же случаяются периодически), а отладить сложно. Стандартный профайлер не помогает никак. А мой бандл «проявляет» ошибку, если можно так сказать.
Вообще говоря, я не вижу здесь ничего предосудительного.

st.sophia — не принадлежащая застройщику торговая марка, и похоже на многие другие названия. Название используется как минимум 1500 лет в Стамбуле и около 1000 в Киеве.

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

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

Information

Rating
Does not participate
Registered
Activity