Все зависит от того, какая политика у компании относительно джуниоров. Я могу и ошибаться, но это может быть не так уж и сложно делать ревью в паре опытный-молодняк в качестве ревьюеров. Теоретически, такие ревью позволят быстрее взрастить джуниора. Даже если такая пара будет ревьюить джуниоровский код, то обучаемый джуниор запомнит ошибки именно своего уровня и будет больше обращать на это внимание вместо того, чтобы получить реджекты на собственном ревью на тех же граблях.
А когда времени в обрез то в следующем порядке забивается на:
Юнит тесты
Ревью
Дизайн
Составление требований
Тестирование в общем
И в такой обстановке, нормального специалиста из джуниора вырастить нельзя. Да и из нормальных тоже можно сделать быдлокодеров при длительном замачивании.
Раньше он как Рик писал кучу кода, абстракций, пытаясь предвидеть будущие требования.
Он когда-нибудь оказывался прав?
Лично у меня сейчас есть проект, в котором требования довольно сильно менялись в прошлом (такой вот заказчик), но уже тогда была большая кодовая база и из-за некоторых изменений приходилось переписывать довольно большие модули.
Сейчас я уже заранее стараюсь писать более гибкий код, ибо чем дальше — тем больше кодовая база и если из-за каждого даже 10го изменения придется ее переписывать, то новые фичи займут сначала недели, потом месяцы, а потом и годы.
У меня был в жизни другой опыт (в самом начале моей карьеры).
Фирме нужно было быстрое решение проблем производительности и в поисках чуда нанимали и увольняли людей, которые должны были их решить (доходило до смешного, что увольняли человека после 4х полных дней работы). Я был частью команды ответственной за производительность (2 человека со скудным опытом в программировании).
И тут наняли сотрудника с замашками рок звезды. Первое что он сказал на первом митинге звучало примерно: "до меня у вас вообще не было ничего, и я это решу". Он даже не вникал в то, что нашими руками производительность кода была увеличена вдвое.
Я должен признать, что ему удалось поднять производительность еще вдвое, но это был абсолютно непонятный и неподдерживаемый код, едва ли не подобранный брутфорсом в некоторых частях.
На почве высказываний в наш адрес и методов написания кода, у нас вырос конфликт и я был вскоре уволен (что принесло мне огромное моральное облегчение).
Спустя пару месяцев звезда ушла в другую фирму, а меня просили вернуться, но я отказался.
Мне нравится, как это решается в Python через enumerate() если реально нужно знать индекс элемента.
А если его знать не нужно foreach (или ranged for в 11х плюсах если не залезать в STL) — наше все.
Как пример lpwzPath прекрасен, но это все прекрасно работает, если есть готовый LLD и нет никаких отклонений.
Приведу пример:
uint16_t mu16_InstanceId;
Предположим, у вас есть 50 строк кода где вы используете этот член класса, и на каком-то этапе вы понимаете, что 16 бит уже не катит и вы меняете тип, имя переменной и еще 50 строк кода, где она была использована (хотя семантический смысл там не поменялся).
После такого diff будет выглядеть довольно раздуто.
Я про консольный Vim ничего не говорил и необходимость IDE для разработки не отметал.
Далее:
Vim — текстовый редактор.
Текстовый редактор является неотъемлемой частью IDE
Если разработчик пользуется текстовым редактором эффективно (и тут уже не важно каким), то соответствующий плагин не может снизить его эффективность если он не ломает того функционала (автодополнение, рефакторинг, подсветка синтаксиса и пр.) который предоставляет базовый текстовый редактор в IDE.
Но желание тащить за собой устаревшие концепции разработки в современную IDE
Не понимаю о чем вы. Vim плагин в IDE никак не влияет на концепцию разработки — просто способ редактирования текста. С тем же упехом можно заявить, что использование Chrome для гугления позволяет писать более эффективный код чем тот, что вы погуглите с IE.
Звучит просто как переусложненный код без достаточной гибкости.
Все зависит от того, какая политика у компании относительно джуниоров. Я могу и ошибаться, но это может быть не так уж и сложно делать ревью в паре опытный-молодняк в качестве ревьюеров. Теоретически, такие ревью позволят быстрее взрастить джуниора. Даже если такая пара будет ревьюить джуниоровский код, то обучаемый джуниор запомнит ошибки именно своего уровня и будет больше обращать на это внимание вместо того, чтобы получить реджекты на собственном ревью на тех же граблях.
А когда времени в обрез то в следующем порядке забивается на:
И в такой обстановке, нормального специалиста из джуниора вырастить нельзя. Да и из нормальных тоже можно сделать быдлокодеров при длительном замачивании.
Я лично, хочу уточнить один момент:
Он когда-нибудь оказывался прав?
Лично у меня сейчас есть проект, в котором требования довольно сильно менялись в прошлом (такой вот заказчик), но уже тогда была большая кодовая база и из-за некоторых изменений приходилось переписывать довольно большие модули.
Сейчас я уже заранее стараюсь писать более гибкий код, ибо чем дальше — тем больше кодовая база и если из-за каждого даже 10го изменения придется ее переписывать, то новые фичи займут сначала недели, потом месяцы, а потом и годы.
Ну, человек, который писал что-то больше курсовой догадается, что
не является эталоном читабельности.
Под "скудным опытом" я подразумеваю 2 года починки багов в большом проекте большой компании.
Астрологи объявили неделю статей про Vim. Количество жертв холиваров увеличилось вдвое.
Таким образом, джуниор должен принимать участие в ревью, но должен быть и кто-то опытный в составе.
У меня был в жизни другой опыт (в самом начале моей карьеры).
Фирме нужно было быстрое решение проблем производительности и в поисках чуда нанимали и увольняли людей, которые должны были их решить (доходило до смешного, что увольняли человека после 4х полных дней работы). Я был частью команды ответственной за производительность (2 человека со скудным опытом в программировании).
И тут наняли сотрудника с замашками рок звезды. Первое что он сказал на первом митинге звучало примерно: "до меня у вас вообще не было ничего, и я это решу". Он даже не вникал в то, что нашими руками производительность кода была увеличена вдвое.
Я должен признать, что ему удалось поднять производительность еще вдвое, но это был абсолютно непонятный и неподдерживаемый код, едва ли не подобранный брутфорсом в некоторых частях.
На почве высказываний в наш адрес и методов написания кода, у нас вырос конфликт и я был вскоре уволен (что принесло мне огромное моральное облегчение).
Спустя пару месяцев звезда ушла в другую фирму, а меня просили вернуться, но я отказался.
Хамства не переношу, ни на "ты", ни на "Вы".
А давно ли мы на "ты"? На брудершафт не пили, вроде.
Ну и минус в карму за переход на личности, наслаждайтесь =)
Так можно и минусов в карму наловить.
Мне нравится, как это решается в Python через
enumerate()если реально нужно знать индекс элемента.А если его знать не нужно
foreach(илиranged forв 11х плюсах если не залезать в STL) — наше все.Как пример
lpwzPathпрекрасен, но это все прекрасно работает, если есть готовый LLD и нет никаких отклонений.Приведу пример:
Предположим, у вас есть 50 строк кода где вы используете этот член класса, и на каком-то этапе вы понимаете, что 16 бит уже не катит и вы меняете тип, имя переменной и еще 50 строк кода, где она была использована (хотя семантический смысл там не поменялся).
После такого diff будет выглядеть довольно раздуто.
del
Чтобы сэкономить время на обьяснения, посмотрите первые минут 15 из видео в этом комменте и расскажите, что вы об этом думаете.
А у вас все сразу в продакшн?
Я заметил на хабре как минимум 2 темы, которые вызывают жуткий холивар в комментах:
Под некоторыми статьями новые комменты появляются даже месяцы спустя.
Я про консольный Vim ничего не говорил и необходимость IDE для разработки не отметал.
Далее:
Если разработчик пользуется текстовым редактором эффективно (и тут уже не важно каким), то соответствующий плагин не может снизить его эффективность если он не ломает того функционала (автодополнение, рефакторинг, подсветка синтаксиса и пр.) который предоставляет базовый текстовый редактор в IDE.
Не понимаю о чем вы. Vim плагин в IDE никак не влияет на концепцию разработки — просто способ редактирования текста. С тем же упехом можно заявить, что использование Chrome для гугления позволяет писать более эффективный код чем тот, что вы погуглите с IE.
И вполне заслуженно как минимум за:
Текущая проблема экранной клавиатуры — отсутствие вменяемых тактильных ощущений. Печатать 10ю пальцами вообще слабо представляется возможным.
Я о том же.