Если вы считаете что Single responsibility principle — это про то, что класс, или же модуль должен делать только что-то одно — то вам обязательно нужно прочитать хоть бы главу про Солид. Ибо то определение, что дано выше — это следствие, но никак не определение самого принципа
Не "делать что-то одно", а делать что-то логически связное так, чтобы потребитель использовал это целиком, но не по частям.
Например, внезапно, вы решите использовать вместо Postgresql MongoDb, или вообще файлики, или использовать mock’нутые данные, операции с которыми будут производится в памяти. И при некоторых условиях — это может заставить переписать почти всю логику.
Уверены что будет меняться — делаете интерфейс. Затупливаете и не можете выбрать — делаете интерфейс, но сначала убедитесь что в этот интерфейс лягут возможные реализации. С другой стороны, иногда хорошо именно завязаться на тот же PostgreSQL потому что иначе мы ограничим себя очень небольшим набором возможностей СУБД, который допустимо использовать. Но тут уже нужно быть уверенным.
Дядя Роб, также рассказывает о том, как детали реализации могут навредить вашей системе, и не дать эволюционировать без боли в дальнейшем.
И, насколько помню, забывает упомянуть что абстракции более-менее сложных штуковин обязательно протекают. И это делает половину того, что в книге, отличной пищей для ума, но быстро разваливающейся на практике если применять не сильно думая.
С пунктом 4 не согласен. Чем больше информации, тем вернее решение. Но, конечно, стоит задавать себе вопрос "как это влияет на работу" и если никак, не брать информацию в рассчёт.
Количество информации о человеке в интернете никак не повлияет на его найм: по ней нельзя сделать какой-то окончательный вывод.
Конкретно НСТР это уже не затронет. У них уже есть что-то почти-почти рабочее и клиенты-метеорологи. Не знаю как в аэрокосмической области, но, как правило, сложность привлечения капитала с готовым продуктом сильно снижается, а условия его получения сильно улучшаются.
От выгорания переход не спасает, если это действительно выгорание. Устал — в отпуск сходи. Надоело — это нужно рассматривать подробнее. Стоит учитывать рынок, репутацию на этом рынке и вот это всё. То есть крайность вроде перехода из компании в компанию раз в два месяца — это определённо плохо.
Что касается OpenSource, то здесь обычно попроще потому что по сути вы никому и ничего не должны так как денег вам никто не платил за чётко определённую работу. Работаете вместе ради получения инструмента для себя, ради фана совместной работы, ради фидбека. Ну и отказ от ответственности перед конечными пользователями написан прямо в license.md.
С numWorkers > 1 не работает?
Может на github его?
Не "делать что-то одно", а делать что-то логически связное так, чтобы потребитель использовал это целиком, но не по частям.
Уверены что будет меняться — делаете интерфейс. Затупливаете и не можете выбрать — делаете интерфейс, но сначала убедитесь что в этот интерфейс лягут возможные реализации. С другой стороны, иногда хорошо именно завязаться на тот же PostgreSQL потому что иначе мы ограничим себя очень небольшим набором возможностей СУБД, который допустимо использовать. Но тут уже нужно быть уверенным.
И, насколько помню, забывает упомянуть что абстракции более-менее сложных штуковин обязательно протекают. И это делает половину того, что в книге, отличной пищей для ума, но быстро разваливающейся на практике если применять не сильно думая.
Комментарий был про "нарытую" информацию по цифровому следу кандидата, а не про задачи.
Главное предупредите что будет платным в итоге чтобы для пользователей это не стало сюрпризом.
Берите со старта адекватные деньги за количество обработанных макетов. Будет коррелировать тогда нагрузка на сервис и получаемая прибыль.
Не прям чтобы комфортно, но там правило есть — не говорить. Совсем. Это немного жутковато, но позволяет фокусироваться.
С пунктом 4 не согласен. Чем больше информации, тем вернее решение. Но, конечно, стоит задавать себе вопрос "как это влияет на работу" и если никак, не брать информацию в рассчёт.
Количество нет, но вот сама информация может.
Конкретно НСТР это уже не затронет. У них уже есть что-то почти-почти рабочее и клиенты-метеорологи. Не знаю как в аэрокосмической области, но, как правило, сложность привлечения капитала с готовым продуктом сильно снижается, а условия его получения сильно улучшаются.
Либо оговорка, либо да.
Вот, например, техническая деталь: https://yiipowered.com/en/projects/372/mta-new-york-city-on-the-go-travel-stations
Сложно будет мигрировать. Попробуем запилить автоматические миграции с Rector, посмотрим, что из этого выйдет.
Интересные крупные проекты почти всегда атипичны, но общие черты есть:
Да, мы стараемся в Yii 3 сделать ряд интерфейсов, которые не поменяются серьёзно даже в 4.0.
Samsung SGR тоже можно задействовать?
Это почему не уйдёшь? Пишешь в сообщество что идёшь на отдых. Делаешь главным другого активного контрибьютера. Всё как в обычных проектах.
От выгорания переход не спасает, если это действительно выгорание. Устал — в отпуск сходи. Надоело — это нужно рассматривать подробнее. Стоит учитывать рынок, репутацию на этом рынке и вот это всё. То есть крайность вроде перехода из компании в компанию раз в два месяца — это определённо плохо.
Что касается OpenSource, то здесь обычно попроще потому что по сути вы никому и ничего не должны так как денег вам никто не платил за чётко определённую работу. Работаете вместе ради получения инструмента для себя, ради фана совместной работы, ради фидбека. Ну и отказ от ответственности перед конечными пользователями написан прямо в license.md.
Годная статья. Думаю, почти все, кого втащило в большой OpenSource это прошли. Вот только конец у него какой-то печальный. Можно и без этого.
Qiang Xue — китаец.