Статья лучше, чем недавно тут была просто по зарплатам, но, подумав об этой статье, я теперь думаю она малополезна для кого-нибудь кто хочет уехать.
Проблема в том, что если средний программист в Москве может накопить 3.5k$ в год и на переезд как минимум надо 15-20к$, то это надо 5 лет копить без отпусков и каких-либо расходов, а как известно у программистов мин расходы это различные девайсы, которые стоят несколько тысяч долларов точно. Т.е. можно сказать копить надо лет 10 «среднему» программисту, который должен стать уже не средним к тому времени и соответственно вся эта статистика станет не особо релевантна для не «средних» программистов.
т.е. годится только для «средних» кому папа-мама оплатили переезд :)
«где же так криво вычислился вот этот параметр?»
это сложно если методы мутируют контекст.
можно сделать большой метод вот таким:
var context = new Context();
context.Prop1 = GetProp1Method(context);
context.Prop2 = GetProp2Method(context);
ActOnFullContext(context);
GetProp1Method(IGetProp1Abstraction input);
GetProp2Method(IGetProp2Abstraction input);
public class Context: IGetProp1Abstraction, IGetProp2Abstraction {
public int Prop1 {get;set;}
public int Prop2 {get;set;}
}
public interface IGetProp1Abstraction {
object SomethingElse {get;}
}
public interface IGetProp2Abstraction {
int Prop1 {get;}
}
public interface IBigContext {
int Prop1 {get;}
int Prop2 {get;}
object SomethingElse {get;}
}
}
Так будет только одно место где делается set Prop1 или set Prop2, а весь инпут гет-онли.
По пункту 3 согласен насчет копи паста бизнес-логики, типа (если статус = 2 или 3 или статус2 = 5) и такая копи-паста. Поддерживать такое нереально.
Еще имеет смысл оборачивать внешние зависимости, аля код типа JsonConvert.Serialize/Deserialize («ну наш же проект всю жизнь будет получать на вход json и только json»)
Но всякую банальную математику или if/else по 3-5 строчек в каждом зачастую только вредит.
Поначалу пока с тебя просят MVP это может выглядеть ок, потом придут требования «а вот это логами обложи», «а сюда телеметрию прикрути», «а сюда нотификейшны добавь» и придется разворачивать обратно.
Про тестирование тоже самое, вроде раздробил и потом у тебя на входе по 10 параметров и пиши эти юнит тесты с пачкой моков. Пока все замокапишь уже забудешь что тестить нужно.
По пункту 4 — согласен если разбивка на методы делается изначально, аля ты пишешь алгоритм сверху вниз:
типа
object DoRequirement1Process(input){
DoStep1()
DoStep2()
DoStep3()
}
void DoStep1() { //TODO: implementation }
void DoStep2() { //TODO: implementation }
void DoStep3() { //TODO: implementation }
и потом каждый раз когда какой-нибудь DoStepX не совсем получается имплементировать как планировалось ты сильно задумываешься и переосмысливаешь всю структуру, а не просто вставляешь костыль и модифицируешь сначала шаги алгоритма, а не вытаскиваешь невлазящий кусок имплементации «чтоб работало».
Придерживаюсь мнения что методы должны быть двух типов: метод-оркестратор (всмысле метод который только вызывает методы других классов), или метод-имплементация (метод который что-то делает и что-то возвращает, но не вызывает ничего сам). Миксовать нельзя, даже если между шагами хочется вставить что-то казалось бы безобидное типа _logger.log() или примитивный foreach внутри которого вызывается 1 метод.
з.ы. работаю сейчас на старом VB.net/VB6 web service с главным классом в районе 80 000 строк и нескольких сторонних классах по 20-40к строк. Приятного мало. Примерно неделю читал его прежде чем представить как же это поменять, спустя 3 месяца уже могу прикинуть в уме примерно где надо что-то поменять, что не есть гуд.
С другой стороны в гринфилд сервисе который пишем над этим веб сервисом один товарищ работал по схеме «напишу ка чтоб работало, потом раскидаю по методам и сервисам». В итоге получаются методы и объекты завязанные под конкретную реализацию, нулевая абстракция и какие-то жесткие утилитарные методы оборачивающие примитивные операции типа арифметики и присвоений через рефлексию или линк экспрешны. Смысл непонятен, поменять реализацию невозможно, вся иерархия этих объектов завязана конкретно на json+rabbitmq+webapi и удачи поменять хоть что-нибудь.
вопрос по классу Command, bool Run и bool IsValid
как обрабатываются различные причины false на клиенте, когда например нужно отобразить разное сообщение пользователю почему та или иная команда не может быть выполнена?
Такое сравнение годится только для удаленных фрилансеров, которые могут работать откуда хотят.
Иначе надо выражать зарплаты в покупательной способности в регионе.
В тех же штатах зп колеблятся от 50-70к$ в год в захолустье до 100-150к$ в силиконовой долине и сиэттле.
При этом и те и те программисты могут позволить себе +- тоже.
Разница в деньгах годна только тем, кто имеет жилье в тех местах и не нужно ни копить на жилье, ни тратить на аренду.
+ еще разница в налогах.
Основной вопрос где быстрее накопить на жилье — в силиконовой долине с зп 130к$/year gross или в москве с зп 25к$/year gross.
Или какой реальный средний остаток в год после расходов на жилье+еду+мелкие товары+машина+бензин+страховки+разница в стоимости медицины. Этот остаток условно можно потратить на новую технику/путешествие/развлечения, его и надо сравнивать.
В посте подменяются понятия «интроверт» и «ребенок».
Независимо интроверт вы или экстраверт такие вещи как «доказывать свою правоту» и «принимать фидбэк» никуда не уходят. Вопрос только в форме — в виде митинга, презентации и разговора или тихонько по е-мейлу.
Отказываться от этих это типа слова бизнесу «ну че вы ко мне пристали, дайте поиграть в моей песочнице, я сам знаю как лучше». Таким можно посоветовать только сделать свой собственный бизнес и быть самому себе начальником, если знаете как лучше.
Проблема в том, что если средний программист в Москве может накопить 3.5k$ в год и на переезд как минимум надо 15-20к$, то это надо 5 лет копить без отпусков и каких-либо расходов, а как известно у программистов мин расходы это различные девайсы, которые стоят несколько тысяч долларов точно. Т.е. можно сказать копить надо лет 10 «среднему» программисту, который должен стать уже не средним к тому времени и соответственно вся эта статистика станет не особо релевантна для не «средних» программистов.
т.е. годится только для «средних» кому папа-мама оплатили переезд :)
это сложно если методы мутируют контекст.
можно сделать большой метод вот таким:
var context = new Context();
context.Prop1 = GetProp1Method(context);
context.Prop2 = GetProp2Method(context);
ActOnFullContext(context);
GetProp1Method(IGetProp1Abstraction input);
GetProp2Method(IGetProp2Abstraction input);
public class Context: IGetProp1Abstraction, IGetProp2Abstraction {
public int Prop1 {get;set;}
public int Prop2 {get;set;}
}
public interface IGetProp1Abstraction {
object SomethingElse {get;}
}
public interface IGetProp2Abstraction {
int Prop1 {get;}
}
public interface IBigContext {
int Prop1 {get;}
int Prop2 {get;}
object SomethingElse {get;}
}
}
Так будет только одно место где делается set Prop1 или set Prop2, а весь инпут гет-онли.
По пункту 3 согласен насчет копи паста бизнес-логики, типа (если статус = 2 или 3 или статус2 = 5) и такая копи-паста. Поддерживать такое нереально.
Еще имеет смысл оборачивать внешние зависимости, аля код типа JsonConvert.Serialize/Deserialize («ну наш же проект всю жизнь будет получать на вход json и только json»)
Но всякую банальную математику или if/else по 3-5 строчек в каждом зачастую только вредит.
Поначалу пока с тебя просят MVP это может выглядеть ок, потом придут требования «а вот это логами обложи», «а сюда телеметрию прикрути», «а сюда нотификейшны добавь» и придется разворачивать обратно.
Про тестирование тоже самое, вроде раздробил и потом у тебя на входе по 10 параметров и пиши эти юнит тесты с пачкой моков. Пока все замокапишь уже забудешь что тестить нужно.
По пункту 4 — согласен если разбивка на методы делается изначально, аля ты пишешь алгоритм сверху вниз:
типа
object DoRequirement1Process(input){
DoStep1()
DoStep2()
DoStep3()
}
void DoStep1() { //TODO: implementation }
void DoStep2() { //TODO: implementation }
void DoStep3() { //TODO: implementation }
и потом каждый раз когда какой-нибудь DoStepX не совсем получается имплементировать как планировалось ты сильно задумываешься и переосмысливаешь всю структуру, а не просто вставляешь костыль и модифицируешь сначала шаги алгоритма, а не вытаскиваешь невлазящий кусок имплементации «чтоб работало».
Придерживаюсь мнения что методы должны быть двух типов: метод-оркестратор (всмысле метод который только вызывает методы других классов), или метод-имплементация (метод который что-то делает и что-то возвращает, но не вызывает ничего сам). Миксовать нельзя, даже если между шагами хочется вставить что-то казалось бы безобидное типа _logger.log() или примитивный foreach внутри которого вызывается 1 метод.
з.ы. работаю сейчас на старом VB.net/VB6 web service с главным классом в районе 80 000 строк и нескольких сторонних классах по 20-40к строк. Приятного мало. Примерно неделю читал его прежде чем представить как же это поменять, спустя 3 месяца уже могу прикинуть в уме примерно где надо что-то поменять, что не есть гуд.
С другой стороны в гринфилд сервисе который пишем над этим веб сервисом один товарищ работал по схеме «напишу ка чтоб работало, потом раскидаю по методам и сервисам». В итоге получаются методы и объекты завязанные под конкретную реализацию, нулевая абстракция и какие-то жесткие утилитарные методы оборачивающие примитивные операции типа арифметики и присвоений через рефлексию или линк экспрешны. Смысл непонятен, поменять реализацию невозможно, вся иерархия этих объектов завязана конкретно на json+rabbitmq+webapi и удачи поменять хоть что-нибудь.
как обрабатываются различные причины false на клиенте, когда например нужно отобразить разное сообщение пользователю почему та или иная команда не может быть выполнена?
Иначе надо выражать зарплаты в покупательной способности в регионе.
В тех же штатах зп колеблятся от 50-70к$ в год в захолустье до 100-150к$ в силиконовой долине и сиэттле.
При этом и те и те программисты могут позволить себе +- тоже.
Разница в деньгах годна только тем, кто имеет жилье в тех местах и не нужно ни копить на жилье, ни тратить на аренду.
+ еще разница в налогах.
Основной вопрос где быстрее накопить на жилье — в силиконовой долине с зп 130к$/year gross или в москве с зп 25к$/year gross.
Или какой реальный средний остаток в год после расходов на жилье+еду+мелкие товары+машина+бензин+страховки+разница в стоимости медицины. Этот остаток условно можно потратить на новую технику/путешествие/развлечения, его и надо сравнивать.
Независимо интроверт вы или экстраверт такие вещи как «доказывать свою правоту» и «принимать фидбэк» никуда не уходят. Вопрос только в форме — в виде митинга, презентации и разговора или тихонько по е-мейлу.
Отказываться от этих это типа слова бизнесу «ну че вы ко мне пристали, дайте поиграть в моей песочнице, я сам знаю как лучше». Таким можно посоветовать только сделать свой собственный бизнес и быть самому себе начальником, если знаете как лучше.