У вас полностью отсутствует понятие, а что "если мой код будут исправлять/разбираться другие". Что впрочем неудивительно, после стольких лет работы в одном месте одному.

Предполагаю, что на новом месте будет достаточно непросто поначалу, если попадете в команду.

договориться, что слать в сеть

Довольно часто это просто невозможно. Есть какое то устройство/файл/канал данных и с него нужно получить данные. Договариваться просто не с кем.

...

На нашем острове обычно не делают прямой доступ к данным класса, как впрочем и не используют подобный способ сериализации

_extend = 

договориться, что слать в сеть

Довольно часто это просто невозможно. Есть какое то устройство/файл/канал данных и с него нужно получить данные. Договариваться просто не с кем.

Тогда конвенция "слать в сеть в порядке байт сети". Конвенции у вас соблюдают?

На нашем острове обычно не делают прямой доступ к данным класса, как впрочем и не используют подобный способ сериализации

_extend = 

Это не класс, а структура. Прямой доступ, т.к. методы сериализации находятся в этой же структуре.

А какой способ сериализации вы используете? Протокол обмена данными не я придумывал - использовался лабвьюшный. Там нужно всё в байты превратить.

У вас полностью отсутствует понятие, а что "если мой код будут исправлять/разбираться другие". Что впрочем неудивительно, после стольких лет работы в одном месте одному.

Я писал код, которым должны были пользоваться другие, но очень мало. А весь этот проект с Лабвью по сути прототип с постоянно меняющимися требованиями и переписываемыми модулями. Всё делалось в первую очередь, чтобы заработало здесь и сейчас, а не "чтобы могли исправлять и разбираться другие". Вот работе в команде - да, мне не хватало.

Предполагаю, что на новом месте будет достаточно непросто поначалу, если попадете в команду.

Это означает, что каких-то писаных требований к коду и работе нет - всё делается и претензии высказываются наобум, по ходу дела? Т.е. пишет человек код, а ему, заранее не предупредив, что это за продукт и какие к нему требования - мы так не пишем, где юнит-тесты? где документация? и т.п.? Не может быть одинаковых требований к любому коду. Где-то делают на коленке "на отцепись", а где-то делают библиотеки и фреймворки, где и тесты, и доки, и оптимизация. Где-то разовый заказ на написание софта - сделал и забыл. А где-то многолетняя поддержка и версионность. Если будете везде писать одинаково - как библиотеки и фреймворки, то либо все сроки нарушите, либо по деньгам не влезете в бюджет. Не может быть также "требований по умолчанию", включающих покрытие тестами и прочее. Тестами можно покрыть близко к 100%, а можно только самые важные части - разница по затратам времени может достигать разов.

Как я понимаю, изначально при устройстве на работу или при получении заказа всё это обговаривается - как работает команда вообще и как будет над этим проектом в частности. Высказывать претензии, что человек не угадал, чего хочет от него команда вообще и на этом проекте в частности - глупо. Я уже говорил, что получал такие тестовые задания - все условия максимально неподробные и с широкой трактовкой. А потом начинают говорить, что они ожидали другого и "вы нам не подходите". Ну ищите себе чтецов мыслей. Если у вас в командах в порядке вещей не договаривать и не специфицировать задания, а потом задним числом претензии предъявлять...

По дефолту покрывать всё юнит-тестами, тестами производительности, заранее думать о расширяемости - за такое и по шапке получить можно, что срок прошёл, а почти ничего не сделано. Я, например, могу много где применять всякие далеко не оптимальные алгоритмы сортировок и прочего, не идеально использовать тот же LINQ (есть полно статей, да и в самой документации, где всякие подводные камни описываются) - всякие лишние аллокации делать и т.д. Если это не критичное место, то и пофиг.

Может, у вас другая крайность - вы делали лишь библиотеки и версионные продукты с многолетней поддержкой, где надо задумываться, как и кто будет работать с вашим кодом через много лет?

Как я понимаю, изначально при устройстве на работу или при получении заказа всё это обговаривается - как работает команда вообще и как будет над этим проектом в частности.

Это действительно так. Вы попадете в команду. И здесь 2 варианта - или всем все пофиг или просто в команде вы будете смотреть, как делают остальные. А править вас будут на пульреквестаh

А править вас будут на пульреквестаh

Насколько я понимаю, это бьёт по карману или личному времени? Т.е. задание нужно сделать за такое-то время. Твой код отклонили - нужно исправить. Править будешь за дополнительное время - своё личное или просто денег меньше получишь за своё время работы?

Это действительно так. Вы попадете в команду. И здесь 2 варианта - или всем все пофиг или просто в команде вы будете смотреть, как делают остальные.

Я имел ввиду, существуют же какие-то правила, как работает команда, или тим лид рассказывает, как будут делать конкретный проект? Не может же быть, чтобы все члены команды, включая новичков, сразу понимали, чего от них хотят и делали всё как надо? Ну или надо тысячу кандидатов перебрать, чтобы найти одного, который бы идеально вписывался в текущие условия текущей команды.

Править будешь за

-----

По разному.

Но в любом варианте если твои возможности будут часто не соответствовать ожиданиям менеджера/командy - попросят на выход.

существуют же какие-то правила

-----

Существуют. Иногда - в устном или бумажном варианте, иногда - в письменном.

И не всегда это помогает.

Не может же быть

-----

Не может.

Мало того, не всегда менеджер правильно понимает что нужно делать.

надо тысячу кандидатов перебрать

------

Да хоть две - у идеально работающей команды сменился проект и кто-то будет "не понимать" что нужно делать.

Хорошо если этот кто-то совсем зеленый новичек от которого ничего не зависит.

Тогда конвенция "слать в сеть в порядке байт сети".

Ну так же говорю, не с кем договариваться. Что дали то и пользуем.

Конечно, если сами всё делаем и без устройств, то все будут Intel и так пользовать.

А какой способ сериализации вы используете?

Ну например, так

public class Test
{
    private int _value1;
    private double _value2;

    Test(IReader reader)
    {
       _value1 = reader.GetInt();
       _value2 = reader.GetDouble();
    }
}

Править будешь за дополнительное время

Ни денег, ни время не урезают, просто в один прекрасный момент приходит шеф и говорит, что больше приходить на работу не нужно.

По дефолту покрывать всё юнит-тестами, тестами производительности, заранее думать о расширяемости

Всё зависит от конкретного проекта, но независимо от этого нужно всё делать правильно изначально.

Вот например требования к одному проекту

- Solid experience with OOP (Design patterns, SOLID principles, Clean Code)

- Solid experience with .NET (Framework/Core/Standard) and C#

- Basic experience with unit tests

- Basic experience with software architecture

- Quality awareness

- Customer-centric thinking

Я имел ввиду, существуют же какие-то правила

Безусловно, хотя не все описано. Например, работа с Гит. Там достаточно много правил хорошего тона, которые как бы нужно уже знать

Ни денег, ни время не урезают, просто в один прекрасный момент приходит шеф и говорит, что больше приходить на работу не нужно.

Это прям как https://leonardo.osnova.io/e6e6445a-5487-5ea0-844d-ce4e1e8...

только без первого слова. Сразу "фигакс! - не ждали?!".

Я тут недавно ссылку на интервью давал, да и в других местах подобное встречал - сначала тебе объяснят, потом на PIP поставят, и только когда ты всеми силами даёшь понять, что не будешь исправляться, тогда... Наверное, это только на словах такой либеральный подход, а на деле скорее то, что на картинке? )))

А какой способ сериализации вы используете?

Ну например, так

Ну я понял - просто логику чтения из потока атомарных данных (или элементарных данных) выносите в отдельный класс (с интерфейсом IReader), а далее уже дело вкуса - либо в конструктор класс чтения передаёте, либо где-то извне вызываете чтение данных и передаёте уже прочитанные данные в конструктор. Главное отличие от моего подхода - я не вынес логику чтения элементарных данных в отдельный класс. Как я уже сказал, не видел в этом смысла, т.к. всё содержимое этого класса будет - вызов либо просто стандартных методов из дотнета, либо с добавлением логики определения порядка записи байт того, с кем обмениваетесь данные.

Конечно, если сами всё делаем и без устройств, то все будут Intel и так пользовать.

Мало вы где найдёте для подобных устройств (платы сбора данных, встраиваемые решения и т.п.) х86. Скорее ARM везде будет. Мы хотели взять "ардуинку" или маленький одноплатный ПК на Интел - но у Лабвью с этим ничего не было, а писать низкоуровневый код работы с датчиками Холла и прочее - не было людей.

Вот например требования к одному проекту
- Solid experience with OOP (Design patterns, SOLID principles, Clean Code)

Тестируете каверзными вопросами по книжкам "гуру"?

- Solid experience with .NET (Framework/Core/Standard) and C#

Это всё настолько размыто. Как раз, по-моему, каврезные вопросы и показывают, как "солид" ты знаешь свой язык программирования и фреймворк. Если ты ходячая энциклопедия по всем вопросам и даже мелким особенностям специальных случаев, да ещё регулярно все свои знания обновляешь - то да, "солид". А так я приводил в пример собес "супер-дупер сеньёра" Фила Ранжина, который на половину вопросов не ответил, но типа я тебя возьму, потому что мы кореша.

- Solid experience with OOP (Design patterns, SOLID principles, Clean Code)
- Solid experience with .NET (Framework/Core/Standard) and C#
- Basic experience with unit tests

Не пойму, как может быть солид в ООП и дотнете, но базовые знания в юнит-тестах? Типа прогал-прогал, а на тесты в основном забивал? Тут же уже сказали, что это плохо и вроде как человек неправильно развивался.

Начитаются первоходы подобных статей, а потом губу раскатывают, как их на работу возьмут и типа "берут всех, кто хоть как-то кодить умеет". Читал недавно статью на немецком про айти в Германии - от 40 до 60% первоходов нашли первую работу по знакомству и связям, а не честно пришли в незнакомое места и давай рок-солид знания демонстрировать.

По мне, если ты солид, то ты давно уже не джуниор. А если ты не джуниор, то почему у тебя по юнит-тестам только базовые знания?

Безусловно, хотя не все описано. Например, работа с Гит. Там достаточно много правил хорошего тона, которые как бы нужно уже знать

Ну вот, а я только с Team Foundation Server работал, да и то не глубоко. Тут вроде Murr писал, что кроме пары команд, типа пуша и получения обнов, ничего толком и не используешь. А тут - "много правил хорошего тона".

или тим лид рассказывает, как будут делать конкретный проект?

Рассказывает.

Насчёт командной разработки. Как я понимаю, обычно все обязанности делятся на соответствующих спецов. Т.е. программиста никто не заставит создавать БД и поддерживать её? Или админить веб-сервер, а то и ось, на которой он вертится?

Я на своей прошлой работе делал практически всё (кроме работы с железом Лабвью и ей самой) - выше написал, что фулл-стек (базы данных, веб, десктоп, сервисы), включая продумывание архитектуры, плюс админство, плюс дистрибуция, плюс документация. Меня всё это вовсе не привлекало, а я чувствовал, что теряю время, занимаясь не своим. Даже специально БД делал через Entity Framework Code First и создание инсталляторов на C# (WiX#), чтобы поближе к собственно программированию было. Но фулл-стек получился далеко не сеньёорский - по вершкам. Зато я хотя бы имею представление, как всё это в комплексе работает и везде что-то попробовал руками.

или тим лид рассказывает, как будут делать конкретный проект?

Рассказывает.

"Просто нормально нужно код писать - люди же потом после вас работать с ним будут! Делайте хорошо и не делайте плохо! Всем всё понятно? - За работу!"

"Скажите, а как сделать это?"

"Книжки умные почитай. Банда четёрых там, чистый код и прочее дерьмо".

)))

Насчёт командной разработки. Как я понимаю, обычно все обязанности делятся на соответствующих спецов. Т.е. программиста никто не заставит создавать БД и поддерживать её? Или админить веб-сервер, а то и ось, на которой он вертится?

По разному. Я часто админю томкэт. Кроме того бывает, что база данных простая или фирма маленькая и специалистов нет. Тогда и на гуде игрец. И да, базу данных я тоже часто разрабатываю. Другоре дело, что скрипты у нас конкретно после меня проверяются другими.

Просто нормально нужно код писать - люди же потом после вас работать с ним будут! Делайте хорошо и не делайте плохо! Всем всё понятно? - За работу!"

Все обычные люди. Тут вообще нет общих правил. Или покажут какой то модуль как пример. Или расскажут. Или всем все пофиг.