Совершенно типичное начало. Оперейшнс и сейлс, спредшитс, совершенно рядовой умелец, макросы, парсинг хтмл через яваскрипт плагин — вот это всё.
Поступок не мудака раз — делится со всеми, произвольность растёт.
Его запоминает начальница (непрямая, через два звена).
Потом он хочет уходить, хочет пойти учиться на нормальные курсы программировать (это Германия, своя специфика, курсам и образованию все доверяют).
Тут большая начальница идёт к директору айти и его переводят в Айти. Полставки QA, полставки поддержка макросов.
Второй немудацкий поступок директора Айти — сразу понял что чувак золото и что нужно его брать хоть куда-то.
Потом он пришёл в мою команду как джун-qa, за полгода стал отличным QA. За это же время все свои макросы перевёл в гитхаб, задокументировал, фронтендеры порефакторели это все.
Продакт был в эйфории — чувак из сейлс часто мог лучше объяснить проблему, чем его начальники на митингах. Плюс прекрасно понимал то, что тестил.
Потом, правда, все равно ушёл. Ну мы и не в обиде — и он нам дал многое, и мы ему в итоге.
У меня аналогичная история со счастливым концом. А конец счастливый потому, что никто себя как мудак не вёл и все решения были приняты правильно (я считаю).
> ParselInterface могут(?) реализовывать UrgentInterface
Вообще-то interface segregation principle как раз о том, что могут. Парсел это парсел, урджент это урджент. Друг другу они мешать не должны.
> Подозреваю, что именно существующий код то и придется модифицировать для поддержки UrgentInterface, иначе срочные посылки будут обрабатываться как обычные.
Существующий код тоже должен расширяться. Поведение существующих классов меняться не должно, но должны добавляться новые классы, которые будут реализовывать новые или существующие интерфейсы.
Т.е. говоря кодом, одновременно с ParselProcessor, реализующим ParselProcessorInterface должен появиться UrgentParselAwareProcessor, реализующий тот же интерфейс и он инджектится вместо существующего ParselProcessor
Ну конечно not modified. Если был класс, который работал с массивом ParselInterface, он будет всё так же работать с массивом ParselInterface и поддерживать все существующие к этому моменту фичи.
Появление нового интерфейса (и нового кода, знающего, как работать с ним) не требует ни одного изменения в существующем коде и существующих features.
Не понимаю, почему тут нужно жертвовать чем-то.
В рамках описанной эволюции всё делается и 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.
Это не противоречит друг другу. ETF — это тип ценных бумаг (индексный фонд), а Vanguard — компания, которая его создала.
Существует, наверное, сотни компаний, выпускающих ETF на основе SP500, SPY (это что-то типа айди) — самый первый и самый крупный из них, создан компанией SPDR. У VOO, видимо, ниже комиссия (хотя у всех ETF она всегда невысока)
Но, во-первых, не факт, что отцы-основатели посчитают это достойной мастера фичей.
Во-вторых, это требует поэтапного внедрения — сначала в 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 минут от автовокзала - это тот район. Ну он жуткий, как на мой взгляд. Кроме того, ээээ, слегка далековато от важных артерий города. Правда, когда дороют метро, это будет не критично.
Прикольно, но само место - имхо дурацкое. Все пространство в районе лыбедской-московской площади весьма неприятное впечатление оставляют. Не хочу там работать.
Если девочка сменит работу, то ей жить (вероятно) станет лучше.
Но абонентам технической поддержки от этого не будет ни холодно, ни горячо - на ее место придет другая, ситуация не изменится.
Я провел тоже больше сотни. Иногда было по интервью каждый день, в течение двух недель.
Всегда читаю резюме.
Если файнал интервью (у нас их два), то подготовка к нему не меньше 30 минут, а желательно час.
Есть чувство, что люди, жившие только в России, из всего этого подробного текста могут распарсить только машину и квартиру.
Прямо по Булгакову
Совершенно типичное начало. Оперейшнс и сейлс, спредшитс, совершенно рядовой умелец, макросы, парсинг хтмл через яваскрипт плагин — вот это всё.
Поступок не мудака раз — делится со всеми, произвольность растёт.
Его запоминает начальница (непрямая, через два звена).
Потом он хочет уходить, хочет пойти учиться на нормальные курсы программировать (это Германия, своя специфика, курсам и образованию все доверяют).
Тут большая начальница идёт к директору айти и его переводят в Айти. Полставки QA, полставки поддержка макросов.
Второй немудацкий поступок директора Айти — сразу понял что чувак золото и что нужно его брать хоть куда-то.
Потом он пришёл в мою команду как джун-qa, за полгода стал отличным QA. За это же время все свои макросы перевёл в гитхаб, задокументировал, фронтендеры порефакторели это все.
Продакт был в эйфории — чувак из сейлс часто мог лучше объяснить проблему, чем его начальники на митингах. Плюс прекрасно понимал то, что тестил.
Потом, правда, все равно ушёл. Ну мы и не в обиде — и он нам дал многое, и мы ему в итоге.
У меня аналогичная история со счастливым концом. А конец счастливый потому, что никто себя как мудак не вёл и все решения были приняты правильно (я считаю).
Вообще-то interface segregation principle как раз о том, что могут. Парсел это парсел, урджент это урджент. Друг другу они мешать не должны.
> Подозреваю, что именно существующий код то и придется модифицировать для поддержки UrgentInterface, иначе срочные посылки будут обрабатываться как обычные.
Существующий код тоже должен расширяться. Поведение существующих классов меняться не должно, но должны добавляться новые классы, которые будут реализовывать новые или существующие интерфейсы.
Т.е. говоря кодом, одновременно с ParselProcessor, реализующим ParselProcessorInterface должен появиться UrgentParselAwareProcessor, реализующий тот же интерфейс и он инджектится вместо существующего ParselProcessor
Появление нового интерфейса (и нового кода, знающего, как работать с ним) не требует ни одного изменения в существующем коде и существующих features.
В чем violation?
В рамках описанной эволюции всё делается и SOLID и DRY
Я переведу это в PHP, но суть не меняется.
Сначала была просто посылка.
Потом нас просят добавить urgent фичу, мы расширяем (но не изменяем и не дублицируем) наш код.
Что там дальше идёт? Доставка реципиенту? Тут нужно уточнить поведение, и либо мы расширяем базовый интерфейс ParselInterface (если фича общая для всех посылок), либо добавляем новый. Соответсвенно, имплементация будет или на уровне родительского Parsel, либо нет. Допустим, первое.
Наш код будет уже
И никакого нарушения тут нет. 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 минут от автовокзала - это тот район. Ну он жуткий, как на мой взгляд. Кроме того, ээээ, слегка далековато от важных артерий города. Правда, когда дороют метро, это будет не критично.
Но абонентам технической поддержки от этого не будет ни холодно, ни горячо - на ее место придет другая, ситуация не изменится.