-
PHP: піти не можна лишитися. Лишитися
-
PHP: піти не можна лишитися. Лишитися
Питати клієнта чи можна вам навчатись в робочий час, це як питати чи можна писати тести і рефакторити код. Якщо вам це забороняють, ви не є профі в очах клієнта. Якщо ви це собі забороняєте, то ви не є профі в своїх власних очах. Ви і тільки ви майте вирішувати що потрібно для досягнення результату.
Дядько Боб каже, що писати код, що задовольняє клієнта — це обов’язок програміста, але вторинний. Первинний обов’язок — писати код достатньо гнучкий для задоволення потреб клієнта в майбутньому.
Наразі я на невеликій, але рокетівскій галері. І я не тільки вчусь сам, але й щотижня витрачаю півтори години усіх інших інжинерів на нашій галері на навчання. Я особливо нікого не питав, сказав що так треба і вони погодились.
Єдине виключення, це коли ви на фрілансі працюєте, але ж на фрілансі ваш рейт залежить від ваших навичок і чим більше ви інвестуєте в себе, тим більше вам повернеться. Ви і є свій власний клієнт.
Підтримав: Віктор Ярошевич -
Композиция vs Наследование в Java
Так композиция ж.
-
PHP: піти не можна лишитися. Лишитися
Друже, не ображайтесь, але у вас в лінкедіні 3 останніх роботи 11, 9 та 4 місяці. Як ви можете судити про те що пхп гімно а рубі це круто, якщо по суті ви ні того ні іншого не знаєте?
-
PHP: піти не можна лишитися. Лишитися
Не повірите, але в окремих венчурах ситуація в рази краще ніж в середньому по Рокету. Сам дивуюсь часом.
-
PHP: піти не можна лишитися. Лишитися
Нащо витрачати час на таку роботу? У вас в запасі є десь років 30 максимум, на одній роботі ви в середньому пропрацюєте 3 роки. Чи варто витрачати 10 відсотків свого продуктивного життя на такого роботодавця?
-
PHP: піти не можна лишитися. Лишитися
1 година робочого часу в день. Роботодавець вам через рік подякує, це гарна інвестиція. Тим більше що професіоналам платять не за роботу, а за рішення проблем. Тільки вам вирішувати, що входить в це рішення. Якщо ж вам роботодавець такої можливості не дає, то ви для нього всього лиш робоча сила і я вам раджу міняти роботу доки ринок дозволяє.
-
Композиция vs Наследование в Java
Для полиморфизма. Вообще правильные применения наследования ищите в Design Patterns by GoF, кроме собственно словаря который могут использовать между собой разработчики, это наверное основное что дает эта недооценненно-переоценненная книга.
-
Композиция vs Наследование в Java
Немного не понял ваш вопрос, о каком примере идет речь?
-
Композиция vs Наследование в Java
Увы не тянет на хорошую статью.
— Имя класса крайне неудачное. Это скорее ReportPrinter.
— Композиция превыше наследование. Я лично считаю что джунам вообще надо запрещать наследовать, пока не научатся правильно составлять объекты. Поэтому с утверждением чтоС композицией всё просто.
крайне не согласен, это то место которое большинство девелоперов понимают очень плохо, а зря. Вообще в конце статьи правильные выводы сделаны, но как-то сумбурно и недостаточно акцентов на правильных вещах.
—если общая функциональность выносится в родительский класс
общая функциональность в 95 случаев должа выноситься в отдельный тип, т.к. это скорее всего нарушение SOLID в том или ином виде. Опять же — наследование хуже композиции почти во всех случаях, за исключением «шаблонных».
— Насчет квадратов-прямоугольников — оба типа будут implements Figure. Никакого наследования. Тот факт, что у них есть занимательные геометрические сходства не означает что квадрат может замещаться только прямоугольником, скорее любая геометрическая фигура может замещаться другой. Когда думаете о наследование, думайте в первую очередь о полиморфизме. Худшее что может сделать разработичк — ввести иерархию классов только ради устранение дублирования кода.
— На кой черт в геометрических фигурах, которые типичные ValueObject, сеттеры?Вообщем, правильные выводы в статье не видно за слегка сумбурным текстом. У меня в целом те же проблемы с изложением мыслей, поэтому и пишу Вам.
Підтримав: Віктор Ярошевич -
Сохранение версии на Github
Книга Pro Git, там 300 страниц, но первая часть из 150 достаточна для покрытия 99% ваших требований.
-
Нужны ли нам гуманитарии
Не забывайте, что Software Engineering наука прикладная, т.е. её надо к чему-то приложить. Не развиваясь в «гуманитарной» сфере, вы рискуете за всю жизнь ничего толком и не добиться, ведь выше вас всегда будет какой-то менеджер, который будет ставить вам задачи.
Так-так, ми продуктова компанія. Але з точки зору процесів в багатьох рокет стартапах це та ще галєра)