Комментарии 301
Умению читать чужой код на курсах не научат. Умению писать код так, чтобы его было просто читать, на курсах не научат. И нет способа как учиться этому на практике.
Вас бросили за штурвал вертолета, натолкав вам основ, а дальше вы или взлатаете и становитесь асом или вы погрячились с айти.
это ж художественное чтиво ? не? )
вы сейчас как будто
из мема
Но, если серьезно, то "Распараллелить вот чё там под этой кнопкой на 2-3 потока, если получится" - это реальная задача, у меня самого такая была была полгода тому назад кстати.
А у коллеги - сейчас есть (другая кнопка в другом проекте, но та же формулировка. Теперь бедняга сидит, фигачит кластер с балансировщиком, бгггг)
Она может звучать как "нужно чтобы вот этот процесс после нажатия этой кнопки работал быстрее. Оптимизируйте как нибудь, может распараллелить можно"
Это реальная задача, но это задача не для джуна, а для миддла. Не самый начинающий джун тоже может это сделать, но только если расписать задачу гораздо детальнее. С учетом того, что задача должна быть сделана быстро, в этом случае вряд ли это имеет смысл.
Теперь бедняга сидит, фигачит кластер с балансировщиком, бгггг)
Хах… я мечтаю о таких задачах, а дают какую-то ерунду с поиском плавающих багов как у автора, только размазанных на десяток либ и сервисов…
Жесть! Буквально на вчера видел это.
Автор, это мой первый коммент и я чувствую твою боль....Помог Андру с этим, ему перекопал весь. Огород надеюсь не зацветет снова сорняком
Свет нужет!
Это очень хорошо когда есть задача распаралелить чот под кнопкой, а не "судя по метрикам из черного ящика, у пользователей упало удовлетворение от продукта, необходимо исправить"
Даже если художественное чтиво, то оно очень близко к тому, что есть.
И да и нет. Если у человека все получалось, а потом вдруг перед ним возникла пропасть, то это не правильный подход к постановке задачи. Здесь вина руководства в большей степени, неэффективное использование ресурса - сотрудника.
Тут все слишком 'it depends'...
Иногда и сам работник виноват в том, что не налаживает контакты с коллегами и руководством. Ведь нужно репортить "нифига не понял" не через день два, а через несколько часов безрезультатного тупления. И главное - важно не боятся признавать что ты не догоняешь.
Я вообще считаю, что придя в сложный проект даже и через год работы можно смело признаваться что чего-то не понимаешь - это естественно.
Возможно еще основная канва истории в том, что человек писал и рефакторил изначально собственный код, а потом ему дали чужой )))
Я например начинал свою "карьеру" разработчика с должности программиста поддержки, где часами приходилось сидеть в отладке, поэтому посыл притчи понятен, но как то не совсем жизненно что ли.
Нет тут никакой
Не согласен, все зависит от курса, не стоит говорить за всех, странная позиция.
Я прошел курсы, меня цели направленно учили понимать чужой код, писать свой и разбираться в архитектуре проекта, если Ваш опыт был не удачным, не стоит транслировать его как истину.
Умению писать код так, чтобы его было просто читать на курсах не научат
Фоксмайндед знаю, учился там. Там серьёзно у меня не принимали код до тех пор, пока он не сделан так, что его даже аквариумная рыбка сможет легко найти, понять, и изменить
Самое непонятное и возмутительное: всем окружающим нормально!
Нет, это не нормально, но общая тенденция к пофигизму. :)
Хорошо, когда есть ментор (с ваших слов "опытный программист").
Он бы ввел вас в реалии работы на месте, помог адаптироваться к проекту и чтению чужого кода.
Если ментора нет - не горячитесь, не принимайте скорых решений.
Иван, не переживайте.
Максимум что может произойти - вас уволят. :)
Пока это не случилось, наберитесь терпения и каждый день по кусочку постарайтесь вникнуть в чужой проект.
Поверьте, читать чужой код и не плеваться - это верх профессионализма.
Обычно, новички приходят в контору, смотрят на проект, говорят что это 'legacy shit' (устаревшее дерьмо) и они напишут с нуля лучше.
Это новички.
У вас сейчас курс профессионала - работа с чужим кодом.
Примите как новый бесплатный курс, за который платит контора.
иван не герой статьи, иван в последнее время разразился циклом статей про неудачи начинающих 1с-программистов.
Это следствие. Видимо, причиной является переход в 1с ERP (ну и дочерних продуктов типа УТ и КА) с 2.4 на 2.5
Пожалуйста, не теребите мой PTSD, мы сейчас делаем этот переход на второй центральной базе холдинга - ERP АПК, в которой проще сказать, что НЕ переписано за прошлые годы, и если мы не закончим этот длящийся уже восемь месяцев ад с очень медленно кипящими котлами, я скоро начну путать окно с дверью (и этому не сильно помогает то, что одно из окон у нас в кабинете это действительно дверь, ведущая на крышу)... Спасает одно - у меня отпуск через две недели. Но мне уже охота выйти если не в окно, то из айти точно, у меня скоро панические атаки от бесконечного копипаста и адаптации плохого кода будут...
2.5 - это самая лютая шиза, которую я видел в 1С за всю карьеру... хотя вру, в недрах ЗуПа в том аде функционального программирования встречаются все еще вещи похуже. Но реально, зачем в регистре, хранящем значения для RLS, просто брать и на ровном месте приписывать ресурсам "Право..." к существующему имени? Этому нет никакого обоснования, просто взяли и по желанию левой пятки в изолированном механизме, не менявшемся годами, переименовали ресурсы, поломав всем все самописные шаблоны RLS. Зачем брать и заменять в отдельных документах перечисление ставок НДС на определяемый тип, состоящий... из одного этого перечисления? У меня почти случилась истерика, когда я увидел эту причину упавшего обмена НСИ через редко используемый веб-сервис. Зачем менять перечисление способов расчета в договорах контрагентов, переименовав старое значение ПоЗаказамНакладным в ПоЗаказам с тем же смыслом... и добавив в него же новое значение ПоЗаказамНакладным с другим смыслом и синонимом?!
Кто-нибудь, внедрите уже директиву &ИменемНуралиеваВыполнитьГдеУгодноИСделатьЗашибись, у меня желание видеть код 1С уже принимает комплексные значения...
"мы не знаем, что такое <s>горжетка</s>PTSD, но если это то, что мы думаем... "
Да, вопросы именно такие же. Плюс вопрос - "что же они все-таки курят??"
Зачем брать и заменять в отдельных документах перечисление ставок НДС на определяемый тип, состоящий... из одного этого перечисления?
Услышали про enum class в C++ и тоже захотели :)
Всего за месяц ни одной строчки? Эх, салага…
Знаешь, как выглядит ночь? Это когда ты весь такой выходишь на работу, а там царство велосипедов. Хороших таких, матёрых велосипедов, целые сонмы демонов, порождённые даже слишком уж бодрствующими мозгами которым нужно промо. И ты понимаешь, что из твоего предыдущего опыта подходят разве что самые базовые знания и умение докапываться до сути самой заковыристой дичи. Вот тебе документация (неполная и часто устаревшая), вот тебе learning path (запутанный), вот тебе полгода времени - разбирайся. Собес ты прошёл, мы в тебя верим. Что-то работающее ты выдашь хорошо если через полгода. Что-то действительно полезное… ну, если повезёт то тогда же.
Если что это будни новичка одного из FAANG’ов :)
Фига себе, документация хоть какая-то есть, а еще и ноют. У меня за 15 лет работы в разных конторах документация была разве только по тем модулям, где и так все понятно былою
Выглядит как обычный рабочий день в С++ проекте :D
У меня первой настоящей задачей было перевести код эквалайзера с ассемблера устаревшего DSP на С. Из документации, только комментарии на немецком. Излишне упоминать, что в цифровой обработке сигналов я мало что понимаю
Вот почему я не стал именно программистом. Нужно достаточно глубоко вникать в каждую задачу, будь то СУБД, или обработка сигналов. В Вашем случае придëтся изучить в какой-то степени и цифровую обработку сигналов, и даташиты на тот DSP, и даже физику и высшую математику вспомнить (Фурье там и прочие комплексные числа).
Да, всё так и было примерно. Разве что физику и математику я помнил, лучше ибо то ли писал диплом, то ли только защитился
Это было бы не проблемой, если бы потом не было следующей задачи :) А по итогу, ты потрогаешь что-то, а через месяц (а то и меньше) уже вспомнить нихрена не можешь.
Вот и получается, что у меня мозг Шредингера - будто бы умный, а как будто бы и нет. Я как будто бы знаю много и в то же время нихрена. Причем чем дальше, тем хуже...
Замечательная задача же! Аж завидно стало, что-то такое из детства... Сидишь, с листочком разбираешься в ассемблерном листинге, псевдокодом основные вехи записываешь – лепота! Помнится, я так 25 лет назад разбирался, как на Sound Blaster Pro оцифровать стереосигнал – с документацией было туго (только для моно), зато была софтина, которая это умела, так что дизассемблер в руки и вперёд.
У меня был кратковременный опыт работы "программистом 1С", вернее, даже не программистом 1С, а просто разработчиком web-портала для клиентов с подключением к 1С в качестве "базы данных"... на тот момент у меня был кое-какой опыт написания внутренних web-порталов на php с БД mysql/mariadb и pgsql, был опыт администрирования 1С в среде Linux (там немало времени приходилось проводить в конфигураторе для отлова платформо-зависимых багов)... в общем, к концу первого года я запил, но к середине второго года клиенты уже вовсю работали в "личных кабинетах" и нахваливали за удобство... ах, да, помимо клиентов ещё пришлось делать "интерфейс оператора" и "мобильное приложение курьера" (нет, само приложение писал не я, но транспорт и протоколы взаимодействия - с меня)... в общем, без чтения чужого кода, а порой и без реверс-инжинеринга в более-менее крупном/старом проекте - не бывает.
Знакомый в около-FAANG первый MR/PR создал через 3 месяца. Настолько все долго. Ему не терпелось уже на второй день "фичи пилить", а ему отвечали "ну ты сначала разберись в проекте".
Звучит как типичный Яндекс. Где всё своё.
Хммм. На случай если это всё таки не разговоры с копипастой. Первый месяц при устройстве на новую работу программистом обычно приблизительно выясняешь стек и внутреннюю кухню. Написать за месяц ни строчки это конечно жирновато, но в целом, нормально при знакомстве с проектом - берём проект и начинаем раскапывать. Абстрагировать на куски по предметной области, где что почему. И расписывать на бумажке дерево диаграмм зависимостей: "Та-а-ак, эти ветки файлов глобально отвечают за вот это, их писали вот эти и эти люди, использовали такие и такие технологии", и таким образом зохавывается весь проект, попутно поглядывая документацию и спрашивая кто где что и зачем сделал.
Когда я устраивался на свою первую работу программистом, возникало острое желание всё нафиг переписать потому что "это слишком топорно и неизящно, это слишком сложно, тут копипаста дикая и вообще её как будто бухим писали". Сами архитектурные модули внутренней кухни были в целом неплохо абстрагированы, ибо ими занималось небольшое количество человек (всего штук пять-семь за всё время), но их внутреннее описание кошмарно. А потом я понял почему именно оно так написано, и внезапно осознал что сам пишу примерно то же самое, и что это нормально и что жизнь слишком коротка чтобы всё вылизывать. Но новичков немного жалко.
Этап самозванца нужно пережить, и спрашивать людей стараясь вникнуть, иначе все вокруг так и будут казаться умными умниками, хотя у них просто опыт копания в говне есть. Пока сам не перероешь миллион строчек говнокода и не напишешь свой - ничего не будет. А пара-тройка месяцев "вхолостую" это обычная практика при обучении, потом компенсируешь качеством работы.
Пожалуйста, воспользуйтесь в следующий раз конвертерами транслита вроде translit.ru - это же невозможно читать
Это достаточно редкий случай организации. Подобное тоже встречается, но туда ещё надо попасть блин, и быть достаточно неопытным чтобы не просечь это на старте.
Если с самого начала бросают в лигаси и вынуждают решать неизвестные проблемы и не дают ни у кого спрашивать - тут повод или с кем-то скорешиться, кто поможет первое время с общими элементами системы, а если таких нет то.. Можно просто уволиться и найти место где дадут нормальное время на освоение?
Нормальная работа. Просто автору не хватает веры в себя и здорового упорства.
Чужой код в работе программиста разработчика разгребать приходится наверно чаще чем писать свой. И это нормально.
Мне не так давно свалилась задача с формулировкой "там у нас непонятно почему упало - надо разобраться почему и пофиксить".
В логах - куча всякой мути и ничего толком не понять.
Глянул в код и вообще фигово стало - такого навороченного на голом месте и просто монструозного кода у нас проекте еще поискать...
Три дня я врубался как там все закручено, голова "слегка распухла" и спать плохо стал. Но после этого я понял на сколько там все плохо и как сделать проще. В результате коммит был примерно такой -1200 +320 (строчек удалено и строчек добавлено). Но убил я на это почти две недели. Логи стали "белыми и пушистыми", а главное там еще были проблемы с постоянным разрывом связи и пере-подсоединение (которые собственно и вызывали совершенно непредсказуемое поведение этой навороченной супер-хрени и ее падение). Потрейсил и разобрался - коннекшены стали сутками держаться.
А самое обидное этот код до сих пор не в мастере и не в продакшене - не бизнес-критикал компонент и падения не слишком частые, что бы это сильно беспокоило, а тестеры перегружены. :(
И вот не считаю такие задачи неинтересными или скучными.
ЗЫ а коллеги потом признались, что этот компонент они трогать побаивались из за его запредельной навороченности.
ЗЫЫ Если что я хоть и вайти, можно сказать со школы (я в последнем классе школы уже спаял свой первый комп и лабал на нем в ассемблере мешая предкам смотреть телик - он у меня монитором был), но именно разработчиком я еще и года не работаю, до этого работал аналитиком много лет и даже пробовал ИТ-менеджером(неудачно). И да,... мне через неделю полтинник.
Да есть импакт - по метрикам там меньше запросов к поставщику.
Внезапно порядка 1500 объектов переподсоединялись (посылая запрос поставщику) примерно через 2 минуты после прошлого соединения. А в новой версии это переподсоединение не требуется днями и неделями. С-но сообщений забикс кажет гораздо меньше.
И таки да я там много чего в первой версии упустил. Но потому я потом еще почти неделю все это сам гонял.
И кстати вы будете смеятся буквально сегодня там все к чертям попадало и про мой код вспомнили и вытащили в следующий спринт тестировать.
Писать MR с диффом в 1500 строк плохая идея. Вы конечно молодец, что потратили кучу времени, чтобы сделать хорошо, но во-первых никто не будет это ревьюить, во-вторых никто не возьмет ответственность за деплой этого чуда.
Настоящий сеньор должен думать головой и писать код так, чтобы его приняли. Менять код надо итерационно, мелкими шагами, чтобы обосновывать было легче и людей не пугать диффами. Это целое искусство.
Пройдет пару лет, в ваш код полезет кто-то другой и напишет статью на Хабре, как он разгребал ваш монстроузный код. /sarcasm
Это же бесконечное рекурсия. Каждый следующий разработчик видит в чужом коде оверхед и легаси.
Я даже в своем коде, написанном когда-то, все это нахожу :)
думаю, как и любой программист спустя n времени. Нередко мне пишет заказчик, которому надо что-то поправить/добавить в код, который я писал год+ назад. Я смотрю на этот код и такой "какую же дичь я писал, такой ужасный код, комментарии сформулированы криво" и т.д. и т.п. С другой стороны, приятно видеть, что со временем я делаю всё лучше, эти ситуации показывают мой прогресс, так что - с одной стороны - смотреть больно, с другой стороны приятно осознавать, что я вырос с тех времен
Глас из другого мира... Продуктовая компания с продуктом на N миллионов строк кода не ахти какая продвинутая.
В команде есть тимлид, члены команды - это ценный ресурс выделенный тимлиду для достижения целей. Нет никаких "писать код надо заслужить". Есть больше задач чем людей и эти задачи на людей валятся.
Нет никакого "распараллель это если получится". Есть ясный описанный набор требований на спринт, которые очень ждут менеджеры, который распределяется между разработчиками согласно их компетенциям и бодро пилится с шутками и прибаутками.
Программисты не решают задач "там какая-то проблема". Это дорого и нерационально. Программисты решают проблему "сделай экранную форму по дизайну", "напиши контроллер обрабатывающий нечто", "напиши алгоритм, делающий нечто" и наконец - "в модуле который ты писал нашли баг, вот как воспроизводится, разбирайся". При решении этих задач требования все время обсуждаются и уточняются. Все вовлечены, все рады, все видят итоговый успех. Не видят только, как водится, где взять столько сил и времени, чтобы это все закодить во вменяемые сроки.
Нет никакого смотрения по пол дня в непонятный код. Каждый постоянно работает с одними и теми же модулями, которые хорошо знает. В день дописывает по 30-150 строк кода в среднем. Если код надо переделывать точечно по 3 строки вместо того чтобы писать новые функции, не очень непонятно как и зачем это разрабатывали.
Нет никакого художественного "стиля" кода, который надо выдержать чтобы не оскорбить каких-то непонятых богов. Бывает только два типа решения задач в коде - запутанный и нормально упорядоченный. Каждый строчит как может. Если кто-то строчит запутанный, скоро он это почувствует, потому что будет путаться сам и путь всех. И научится. Никто не запрещает рефакторинг, если все стало плохо. Есть код-ревью на крайняк. Ну и вообще - цель - это фитчи а не код.
Почему у автора статьи все так плохо есть 3 версии:
Это просто контора, которая берет людей по приколу а потом мучает их, пытаясь от них избавиться. Типа бросим всех в воду может кто-то да не утонет. При этом новичков заставляют учиться на самой сложной из мыслимых задач: поди туда не знаю куда, сделай то незнаю что в чужом коде. А простую и ясную задачу (писать новый код под юзер стори) дают тем кто заслужил. Безнадежно, в общем.
Наша команда на самом деле не настоящие программисты. Мне просто повезло писать новый продукт а не сопровождать старый и никому непонятный. Я не знаю что такое настоящая работа и не справился бы с ней как и автор статьи.
Есть два разных мира - простой и ясный мир создания новых продуктов и сложный и мутный мир сопровождения долго существующих монстров. Автору не повезло попасть прежде всего во второй.
Вот интересно, у кого какой опыт.
Наша команда на самом деле не настоящие программисты. Мне просто повезло писать новый продукт а не сопровождать старый и никому непонятный. Я не знаю что такое настоящая работа и не справился бы с ней как и автор статьи.
Есть два разных мира — простой и ясный мир создания новых продуктов и сложный и мутный мир сопровождения долго существующих монстров. Автору не повезло попасть прежде всего во второй.
Я тоже пишу новое, а не дорабатываю старое. Но, правда, почти в одиночку. Когда я встречаю проект, написанный кем-то другим, мне там не нравится практически всё. Начиная от оформления (да, я перфекционист и написаное должно выглядеть красиво, ниже покажу, какое именно оформление я люблю) и до идеологии.
#ifndef C_IMAGE_STORAGE_H
#define C_IMAGE_STORAGE_H
//****************************************************************************************************
//класс хранения изображений
//****************************************************************************************************
//****************************************************************************************************
//подключаемые библиотеки
//****************************************************************************************************
#include <QtWidgets>
#include <stdint.h>
#include <memory>
//****************************************************************************************************
//макроопределения
//****************************************************************************************************
//****************************************************************************************************
//константы
//****************************************************************************************************
//****************************************************************************************************
//предварительные объявления
//****************************************************************************************************
//****************************************************************************************************
//класс хранения изображений
//****************************************************************************************************
class CImageStorage
{
public:
//-перечисления---------------------------------------------------------------------------------------
//-структуры------------------------------------------------------------------------------------------
//-константы------------------------------------------------------------------------------------------
static const int32_t TILE_WIDTH=16;//ширина тайла
static const int32_t TILE_HEIGHT=16;//высота тайла
static const int32_t TILE_BORDER_WIDTH=1;//ширина рамки
static const int32_t TILE_BORDER_HEIGHT=1;//высота рамки
static const int32_t TILE_WITH_BORDER_WIDTH=TILE_WIDTH+TILE_BORDER_WIDTH+TILE_BORDER_WIDTH;//ширина тайла с рамкой
static const int32_t TILE_WITH_BORDER_HEIGHT=TILE_HEIGHT+TILE_BORDER_HEIGHT+TILE_BORDER_HEIGHT;//высота тайла с рамкой
private:
//-переменные-----------------------------------------------------------------------------------------
QPixmap qPixmap_Tiles;//набор тайлов
static std::shared_ptr<CImageStorage> cImageStorage_Ptr;//указатель на класс CImageStorage
public:
//-конструктор----------------------------------------------------------------------------------------
CImageStorage(void);
//-деструктор-----------------------------------------------------------------------------------------
~CImageStorage();
public:
//-открытые функции-----------------------------------------------------------------------------------
static std::shared_ptr<CImageStorage> GetPtr(void);//получить указатель на класс CImageStorage
QPixmap& GetTiles(void);//получить набор тайлов
private:
//-закрытые функции-----------------------------------------------------------------------------------
};
#endif
В вашем perfect примере секция "класс хранения изображений " дублируется, или кажется?
И, кстати, насчет perfect формат - на вкус и цвет.
Лично у меня есть что поправить в вашем примере. :)
Что именно?
На правах полу-шутки, если что)) Почистил код, привёл к читаемому состоянию. (на момент написания своего комментария все ответы ниже ещё не читал, код под спойлером не хочет раскрашиваться поэтому вставил так)
Все "дублирующие" комментарии это просто визуальный мусор. Отлично видно, где конструктор и деструктор, такой код комментирует сам себя. Комментарии должны отвечать не на вопрос "что это", а на вопрос "зачем это и как оно работает". Вот этих комментариев я как-то не увидел, поэтому назначение кода не до конца понятно. Я так понимаю, что класс может возвращать либо картинку QPixmap, которая содержит в себе тайлы, либо некий указатель. Вот про него я не понял.
Комментарии на русском... Я ни разу не участвовал в каком-то серьезном проекте, поэтому не уверен как тут обстоят дела "у взрослых". Для меня кажется естественным писать комментарии на английском (и я всегда делаю только так), потому что всегда есть вероятность что код после меня будет читать человек, незнакомый с русским. Но подчеркну, что это субъективно всё таки.
TILE_WITH_BORDER_WITDTH я бы заменил на TILE_TOTAL_WIDTH, etc
Названия членов-функций/данных в lower camel case
Названия членов-данных начинаются с m_ или другого идентификатора
дублирование в имени переменной её типа... во-первых - загромождает код, во вторых - при изменении типа переменной придётся менять имя переменной во всём коде, выглядит как чудовищная идея как по мне
обычно классы используются для сокрытия код под некую абстракцию, поэтому имена членов-функций хорошо бы делать в терминах этой абстракции, а не в терминах кода. getPtr это буквально "получить указатель", в моём понимании в названии этого метода должно быть закодировано, что именно за указатель она возвращает. Но повторюсь, эта часть кода осталась неясной и предложить другое имя на замену не могу, и возможно что оно и не требуется.
#ifndef C_IMAGE_STORAGE_H
#define C_IMAGE_STORAGE_H
#include <QtWidgets>
#include <stdint.h>
#include <memory>
class CImageStorage
{
public:
static const int32_t TILE_WIDTH = 16;
static const int32_t TILE_HEIGHT = 16;
static const int32_t TILE_BORDER_WIDTH = 1;
static const int32_t TILE_BORDER_HEIGHT = 1;
static const int32_t TILE_TOTAL_WIDTH = TILE_WIDTH + 2*TILE_BORDER_WIDTH;
static const int32_t TILE_TOTAL_HEIGHT = TILE_HEIGHT + 2*TILE_BORDER_HEIGHT;
CImageStorage(void);
~CImageStorage();
static std::shared_ptr<CImageStorage> getPtr(void); //FIXME: rename to something meaningful
QPixmap& getTiles(void);
private:
QPixmap m_tiles;
static std::shared_ptr<CImageStorage> m_ptr;
};
#endifupd: чуть ниже указали на много других моментов, таких как включение QtWidgets в заголовочник небольшого класса, когда достаточно было бы включить QPixmap
Язык комментариев зависит от компании - если в компании все говорят по-русски, и есть программисты, владеющие английским на уровне ниже B1 - комментарии лучше писать по-русски, иначе такие программисты могут их не понять или понять неправильно. Также в этом случае имеет смысл дублировать англоязычные идентификаторы русскоязычными комментариями. Более того, часто в таких компания необходимость писать комментарии только на русском закреплена в кодстайле. Потому что многие молодые программисты стремятся писать комментарии на английском, чтобы попрактиковаться в языке, и иметь возможность легко перейти в международную компанию, но это создает проблемы более опытным программистам постарше, которые в школе и институте изучали французкий или немецкий языки, а английский осваивали уже в основном в процессе чтения технической документации к программам. Руководство также не одобряет использование английского вместо русского, потому что в таких компаниях уровень зарплат обычно ниже среднего, и руководству не выгодно, когда сотрудники всерьёз учат английский, а потом уходят на более высокие зарплаты.
5. Названия членов-данных начинаются с m_ или другого идентификатора
Это уже от принятого стиля зависит: в гугловском стиле рекомендуют ни с чего не начинать, но добавлять подчёркивание в конце имени:
Data members of classes, both static and non-static, are named like ordinary nonmember variables, but with a trailing underscore.
Это пример или у тебя столько визуального мусора в коде? Зачем ты дублируешь всё, где и так понятно из названий переменных, типов и методов? Про русские комменты вообще молчу.
Какую функцию несёт C?
Указывает, что это класс. Собственно, как и в MFC.
Какую функцию несёт комментарий? Разве не очевидно, что терм с именем TILE_WIDTH означает, ну, ширину тайла?
Как я уже сказал выше, всё написанное на русском является разграничением зон внимания. Я, например, английский не воспринимаю быстро (я вообще немецкий учил). В отличие от русского.
У вас код точно поддерживает неквадратные тайлы? Точно-точно?
Абсолютно точно поддерживает.
Время компиляции — оно важно, чай на плюсах пишем, не на го каком-нибудь.
Не надо сказок. Время компиляции очень незначительно вырастает. Вот когда метапрограммирование суют, это считают круто и зашибись и пофиг на время. А тут вот прям фу-фу. ;) Константы должны быть инкапсулированы. Мне так нравится. Точка. Можете оценить время компиляции проекта.
Какую функцию здесь выполняет qPixmap в имени?
Указывает от чего произведено. Далеко не все IDE показывают типы классов и делают подсказки. Отсюда и такая привычка.
Это синглтон?
Да. Хотя я и забыл закрыть явный вызов конструктора. Это да.
Почему бы просто не написать
Потому что это оторванная от сущности функция. И потмоу что мне нравится сделать именно так.
Зачем нужно всё это тряхомудие с конструкторами, деструкторами и шаред_птром, когда можно в буквальном смысле обойтись одной структурой с одним полем, и одной функцией, её возвращающей?
МОжет быть, чтобы потом было что расширять?
Это понятно, но зачем указывать на то, что это класс?
Потому что мне это удобно. Я вижу, с чем работаю. С классом, со структорой, с чем-то ещё.
MFC — так себе образец для стиля кода.
Ну откройте исходники линукса. Там образец? ;)
И это внимание в итоге распыляется.
Ничего подобного. Вот как раз когда по описанию или по коду скользишь внимание цепляется за такие обособленные блоки. Так что это не комментарий, что там в классе конструктор. Это указание на зону конструкторов. Когда я буду смотреть класс, я очень быстро увижу, где описаны конструкторы (и допишу новый, например).
То есть, для вас быстрее, увидев константу TILE_WIDTH в коде, перейти к определению, чем воспринять непосредственно с английского?
Разумеется. К тому же у меня есть правило, требующее описывать что это. И будет странно оставить часть переменных/констант/функций без описания только потому, что «это и так понятно что». Это нарушит эстетику восприятия. Я же сказал, я перфекционист.
Я создал файл из одной строчки — он компилируется почти четыре секунды:
И? А весь проект? Десять секунд? ;) Что вы делаете с осободившимся временем? ;) Самый большой мой проект (в репрозитории его нет, он по работе) с 100 000 строк компилируется в Qt за 3 минуты на Core 2 Duo. Но там около 1000 модулей.
И не спрашивайте, почему подключён QtWidgets вместо конкретного — это сделано, например, чтобы в будущих версия Qt, где решат поменять имя файла заголовка в очередной раз не пришлось гадать, как именно оно теперь называется.
метапрограммирование — это хотя бы прикольная разминка для ума.
Вы программы пишете чтобы какие-то задачи решать или «для разминки ума»? Так вот, я практик.
Ну так инкапсулируйте их в каком-нибудь
Так делают только с константами, которые ни к кому конкретному (имеющему с ними однозначную логическую связь) не относятся и используются в разных частях по-разному. В данном случае константа чётко привязана к классу — она его смысловая часть.
Зачем это коммитить?
Чтобы желающий просто запустить и посмотреть, как работает, не гадал, как ему ЭТО собрать и запустить.
По личному опыту — код, в котором нужно знать прям конкретный тип переменной в каждой точке её использования, обычно не очень, ну да ладно.
Когда вы будете вспоминать что такое Image ( это свой класс? Класс QImage? Или ещё что-то?), а IDE будет показывать вам фигу, вы будете лазить по коду отыскивая, от кого это образовано и какие там вообще есть внутри функции. Оно мне надо? А вот так я чётко вижу что это за класс и от кого он взят, а значит, знаю уже сразу что он может и для чего он.
Будете ли вы называть поле этого типа как
Да, буду. В Qt не постеснялись же так назвать класс? Ну так и я не постесняюсь.
Почему обязательно оторванная?
Кстати, а синглтон зачем нужен? Чтобы его нельзя было создать ни каким образом вторым экземпляром. А у вас я легко создам сколько угодно этих классов вне этих функций. Вот забуду и создам.
Как? Писать кучу ненужного кода?
А это кому как. Я так полагаю, что очень даже нужный. Тайлы убраны в отдельный класс. Класс нельзя создать дважды (как только конструктор private сделать не забуду).
Одна вещь, которую я понял за всё время разработки — что я (и никто, кого я встречал) не способен прогнозировать, в каком месте и куда будет расширяться код.
А поскольку это мой проект, я отлично знаю, куда я его поверну и что мне может потребоваться. ;)
Самый большой мой проект (в репрозитории его нет, он по работе) с 100 000 строк компилируется в Qt за 3 минуты на Core 2 Duo. Но там около 1000 модулей.
Везёт. Самый большой мой проект компилируется 42 минуты на 11900x с 64Гб памяти(32 недостаточно). И да, там тоже думали "что вы делаете со всем освободившимся временем", когда начинали его писать 10 лет назад. А распутать этот клубок сейчас сил и времени ни у кого не хватает.
Это, конечно, не хром с 6 часами на сборку, но фидбек после изменений требует минут 5 на компиляцию и линковку
Это нарушит эстетику восприятия. Я же сказал, я перфекционист.
Что же такого перфекционистского в желании писать бесполезные комментарии? Просто ваша какая-то особенность восприятия. Множество людей проревьювив такой код посоветовали бы почитать "чистый код" главу про комментарии и удалить весь этот ужас. Жестокий несовершенный мир.
Мысленно аплодирую вашему подходу к написанию кода.
Фу, пробелов нет между // и комментом.
Фу, длина строки больше 110 символов.
Фу, табы не наглядные, в стиле кланг-формат.
Фу, комменты на русском.
/* Что это? Душность в ответ на душность, наверное. */
Прямо как вывод какой-нибудь утилиты проверки code-style :)
Фу, пробелов нет между // и комментом.
Эстетически коробит от пробелов в данном месте.
Фу, длина строки больше 110 символов.
Мешает клиповое мышление воспринимать больше 100? ;)
Фу, табы не наглядные, в стиле кланг-формат.
Пробелы, а не табы. Большие отступы так же вызывают ощущение брезгливости и неряшливости.
Фу, комменты на русском.
Я плохо знаком с английским. Да и свой язык я всё же уважаю и люблю. С чего бы вдруг, а?
/* Что это? Душность в ответ на душность, наверное. */
Это просто какой-то комплекс. ;) Надейтесь, что пройдёт. :)
static const int32_t TILE_WIDTH=16;//ширина тайла
И чему же равна ширина тайла? Почему не пишете об этом в комменте?
void lcd_printd( int32_t n, uint32_t l ) // ultimately simplified sprintf
{
uint32_t k = 0;
if( n < 0 )
{
digits[0] = '-';
k++;
n = -n;
}
uint32_t i = l;
while( i > k )
{
digits[--i] = n % 10 + 0x30;
n = n / 10;
}
digits[l] = 0;
lcd_prints( digits );
}
Эдакая игра в угадайку. ;)
А я и не программист)
На самом деле, вполне себе понятный код. В Ардуино подобные оптимизации это обычная вещь. А т.к. кода обычно немного, то и сложная архитектура не требуется. Возможно, не хватает комментария, а лучше примера работы второго цикла, чтобы не тратить время на его визуализацию.
// n = 987
// i=2: digits[2] = 987 % 10 = 7
// i=1: digits[1] = 98 % 10 = 8
// i=0: digits[0] = 9 % 10 = 9
Вообще - назначение сего кода мне стало очевидно через секунд 5. Из которых через две я понял - что он делает из названия - а еще три - проверял - действительно ли все так - или чего-то я не учел. А что вас смутило? Проверяем число на отрицательность, ставим минус если надо, ну а если нет - делим на десять, беря остатки. Так обычно число на цифры и делят.
через секунд 5
А если там написать, что происходит, то это будет ясно через 1 секунду. ;)
... кто в ASCII кодах что-то писал - тот уже ни 0х10 ни 0х30 (и многих других) не забудет :)
https://github.com/da-nie/Dizzy-game-
clexicalanalyzer.cpp
Кстати, хранение всех файлов в корне проекта вместе с мусором от IDE, как я понимаю, тоже помогает разделению зон внимания?
cAutomath_PrimaryLevel.AddRule("begin","comma end",',',',',true);
//cAutomath_PrimaryLevel.AddRule("begin","plus end",'+','+',true);
//cAutomath_PrimaryLevel.AddRule("begin","minus end",'-','-',true);
cAutomath_PrimaryLevel.AddRule("begin","quote",'\"','\"',false);
cAutomath_PrimaryLevel.AddRule("begin","terminal",0,0,true);
cAutomath_PrimaryLevel.AddRule("begin","terminal",10,10,true);
cAutomath_PrimaryLevel.AddRule("begin","terminal",13,13,true);
Что такое в этом коде 0, 10 и 13, совершенно очевидно каждому
Кстати, хранение всех файлов в корне проекта вместе с мусором от IDE, как я понимаю, тоже помогает разделению зон внимания?
Просто проект ещё не разросся до того уровня, когда я такое разделение делаю. Да и в Visual Studio 2010 довольно неудобно делать папки. Но, обычно, такое разделение у меня присутствует после преодоления некоторой планки сложности.
Что такое в этом коде 0, 10 и 13, совершенно очевидно каждому
Это, конечно, требует рефакторинга. Но ещё не дошёл, значит. Начиналось-то с прототипа «на попробовать». И забыл. Много, много где надо константы заменять.
Вообще говоря, на момент написания этого кода для меня было неочевидно, что кодировка LCD-экрана совпадает с кодировкой ASCII, поэтому я глянул в табличку, посмотрел, где начинаются цифры, и вписал эту константу в код. А буква <code>l</code> символизирует length, и отличается от единицы не написанием, а цветом.
n = -n;При n равном -2147483648 код ведь будет работать неправильно?
Комментарии в коде, которые дублируют названия методов и переменных — визуальный мусор. Серьезно, подпишем рядом с конструктором, что это конструктор? Куча комментариев ради комментариев, под которыми даже кода нет, это вообще за гранью добра и зла. Если бы я такое увидел на ревью в первый раз, была бы серьезная беседа с джуном, который это написал. В случае рецидива мы бы с ним попрощались, скорее всего.
Не обижайтесь, но по этому вашему коду сразу понятно, что в командах вы не работали.
static const int32_t TILE_WIDTH=16;//ширина тайлаЯ ваш коллега, я открыл ваш код. 16 чего? cm, mm, in, px, pt?
Не обижайтесь, но по этому вашему коду сразу понятно, что в командах вы не работали.
Я работал только в маленьких командах. И вот там как раз писали как я выше показал по ссылке.
Я ваш коллега, я открыл ваш код. 16 чего? cm, mm, in, px, pt?
Логично, конечно. Но мне в голову не пришло, что размер тайла может быть отличен от пикселей. Уж извините.
Такие комментарии в коде визуально разделяют зоны внимания
Нет, они отвлекают. Я сам вижу, где тут конструктор, а где приватные свойства.
А мусор — это вот такое оформление кода, как у вышеприведённого критика.
А что конкретно тут не так с оформлением, по-вашему?
И вот там как раз писали как я выше показал по ссылке.
Вас научили плохому. Это вообще выглядит, если честно, как автоматически сгегерированный текст. Если среди всего этого мусора будет действительно полезный комментарий, велика вероятность, что ваш коллега его пропустит. Вы формируете установку, что ваши комментарии доя красоты, а не для дела.
Но мне в голову не пришло, что размер тайла может быть отличен от пикселей.
Да, писать хорошие комментарии, это навык, которому нужно учиться. Всегда нужно думать, зачем вы пишите комментарий. Добавляет ли он полезной информации или дублирует существующую? Если второе, то ваш комментарий не нужен. И всегда нужно помнить о том, что телепаты в отпусках и в вашу голову ваш коллега не влезет.
Нет, они отвлекают. Я сам вижу, где тут конструктор, а где приватные свойства.
Нифига. Когда класс станет с большим количество функций, вы будете внимательно выискивать, где же этот конструктор? А вот так, как у меня, мгновенно опередляется зона конструкторов.
А что конкретно тут не так с оформлением, по-вашему?
Куча магических констант. Неудачное имя переменной l. Нулевое объяснение, что происходит и зачем всё это. Не отделены глобальные и локальные переменные ( dgits — глобальный массив. У меня есть правило такие переменные писать с большой буквы, чтобы не путать их с локальными).
Если среди всего этого мусора будет действительно полезный комментарий, велика вероятность, что ваш коллега его пропустит.
Никакой вероятности. Просто у вас привычка смотреть на голую портянку. А у меня от таких портянок идиосинкразия.
И всегда нужно помнить о том, что телепаты в отпусках и в вашу голову ваш коллега не влезет.
О! Какой тонкий троллинг! ;)
Я конечно, не сишник и не разбираюсь в IDE, но даже VS Code может показать структуру модуля и класс со всеми конструкторами и прочим.
Комментарии - реально механизм, вами в данном случае использующийся не по целевому назначению при наличии более подходящих инструментов. Как минимум, у комментариев есть еще функция экспериментов, когда большие блоки кода скрываются и раскрываются в процессе поиска решения, и она тоже отвергается вашим подходом.
Такое оформление характерно и происходит от незрелых IDE, как у меня конфигуратор в 1Ске, где в принципе отсутствует понятие карты модуля и структуры модуля. В той же EDT на базе Eclipse, опять же, насколько бы она не устарела на текущий момент, уже зачатки этого есть, потому что это реально необходимо и нужно людям. Также преимущество инструментов по сравнению с комментариями, что структура строится автоматически средой, а текст пишется вами. Настоящий программист, и тем более перфекционист, стремится избавиться от лишнего труда, потому что человек изначально ненадежен по сравнению с компьютером в тупых механических операциях.
Ну и такой вопрос к вам, если позволите. Как и на каких условиях вы в принципе готовы воспринять новую информацию, особенно незнакомую или некомфортную? Допустим, у комментаторов, как и у меня, нет негативного настроя. Очевидно, что во всем многообразии возможных подходов есть более лучшие и менее лучшие, при чем в разрезе большого количества очень разнообразных факторов и критериев оценки. Любой из нас чисто статистически в каком-то аспекте может занять неудачный подход, не осознавая этого.
Если вы допускаете такую возможность применительно к себе, следующим логичным шагом будет осознать процедуру перехода к более удачным подходам и критерии распознавания их. Также это включает аргументированную работу с чужим мнением, возможно, научно-математический подход.
Если вы в принципе не допускаете такую возможность, это либо временное решение психики, которая компенсирует какие-то непроработанные моменты, либо откровенный косяк сознания.
Я конечно, не сишник и не разбираюсь в IDE, но даже VS Code может показать структуру модуля и класс со всеми конструкторами и прочим.
А IDEMomentics, например, не может.
Настоящий программист, и тем более перфекционист, стремится избавиться от лишнего труда, потому что человек изначально ненадежен по сравнению с компьютером в тупых механических операциях.
Вы уж извините, но эстетику миллионов мух я уже видел. И их код мне решительно не нравится. Более интересно, с какого перепугу вы вдруг решили, что можете говорить от имени всех и полагать, что это комментаторы подобные вам являются настоящими программистами? Что вы там такое программируете, что вдруг себя возомнили мерилом практик оформления? Вы, господа, просто, видно, очень молодые (хоть по возрасту, хоть прсихологически — сейчас поздно взрослеют), и, как все молодые, борзые и полагающие, что все, кто делает иначе чем вы, это отстой. Вот и не нашли ничего лучше, чем просто напасть на всё, что вам кажется непонятным. И у вас, извините, опломба столько, что на десять человек хватит. А разница тут как между классической музыкой, где всё гармонично и по-полочкам и всей этой современной дребеденью. Вы просто не зрелые, господа.
почему то или иное ваше решение в приведенном вами коде — плохое, и какие оно за собой влечет негативные последствия. Поэтому...
Да ну? ;) Это просто ваша вкусовщина и не более того. Какие негативнеы последствия вы углядели? Я написал самостоятельно несколько тысяч разных программ за все годы. От систем управления персоналом и игр до систем управления технологическим оборудованием и военной техникой. Я могу мгновенно вспомнить, что и как в этих проектах работает просто глянув на свой код. В любом. Потому что в этом именовании есть система и ряд правил. И именно они позволяют в нём легко и просто ориентироваться.
… может это вам пора психологически позврослеть и созреть, и научиться достойно принимать и прислушиваться к обоснованной критике?
А это ответ в стиле «сам дурак», да? ;) Ну и кто тут остался в детстве?
И с чего это вы взяли, что можете вообще кого-то учить? Такая твёрдая уверенность как раз и выдаёт излишне самоуверенное существо с опломбом до небес. Я вот себе такое не позволяю и допускаю разные подходы, со своими плюсами и минусами, однако, предупрежу, что вот это и это у меня вызывают практически физический дискомфорт при просмотре. А вы допускаете, даже не узнав, почему сделано именно так и какие задачи решаются таким подходом.
Вы же на все что не вписывается в ваши привычки автоматически вешаете ярлык «смотреть тяжко», сами делая именно то, в чем обвиняете других — нападаете на то, что вам кажется непонятным и что вы не способны понять.
Может, потому, что я давным-давно всё это видел? Весь гитхаб завален таким неряшливым кодом.
Коллеги-хабравчане весьма здраво и по делу поревьюили его тут и тут,
Вот именно потому, что вы сочли это здравым и по делу не вдаваясь вообще в устройство проекта, я и заключаю, что ничего вы не поняли. На все такие «ревью» я дал ответ, где подробно описал, зачем и почему. Тут некоторых удивило, зачем вообще отдельный класс-обёртка для хранения изображения? Вы бы сперва узнали для чего такое сделано вообще могло бы быть. А сделано это было для того, чтобы всю нужную редактору графику хранить в одном месте. Просто конкретно сейчас там хранится только набор тайлов. Потому что редактор ещё не дописан до конца.
Вы первым перешли на личности, видимо, по причине отсутствия разумных аргументов, обвинив ваших оппонетов в «детскости», и я решил вам немного подыграть поменявшись ролями.
Полегче на поворотах. Во всех комментариях от подобных вам прямо сквозит эдакое пренебрежение, типа, вот вы там свысока советуете. ;)
Так именно об этом вас тут в комментариях несколько раз уже подробно расспрашивали
Вы, наверное, какие-то другие комментарии читаете? Именно об этом меня тут не расспрашивали. Сразу начали хаять, минусовать и прикалываться («а чего размер в комментарий не вписали?»). Так что не надо сказок.
А когда у человека за многие годы закостенело мышление, но при этом ЧСВ раздуто до масштабов соседних галактик — тут уж извините, это не мой случай.
А с чего это вы опять решили, что ваш подход правильный? ;) Вот это и есть раздутое ЧСВ.
и тысячи (странно, что не миллионы) написанных программ
У меня одних только драйверов под QNX написано штук 40. И нет, я не соврал и не приукрасил (конечно, не все они масштабные проекты, но тем не менее). В моём репозитории лежит около 50 программ. Так это каждая сотая туда попала (и не попала, естественно, ни одна с работы). Я этих программ писал на каждый чих знаете сколько? У меня одних версий 3D-движков в 2005 было штук 10 написано. Та же участь постигла и свёрточную нейросеть — были версии с CUDA, без CUDA, с распараллеливанием на CPU, без распараллеливания, с ошибочно понятой концепцией обучения, на шаблонах и без. Дофига всего было написано. А теперь приходит Вася клепальщик-сайтов и начинает рассказывать, как он там «экономит время, как настоящий программист» и как ему не нравится визуальное оформление и отступы и вообще имена непривычные. Вася уверен, что он знает и умеет всё. Когда в реальности такому Васе даёшь задание сделать на 4 микроконтроллерах объединённых ДОЗУ отказоустойчивую систему, Вася мычит и теряется, а потом пишет вот такой вот код (который, кстати, всем нравится). А этот код, на самом деле, ну не очень и сильно не очень (но 7 плюсов, замечу!). И вот такой вот Вася с апломбом начинает рассказывать, как он постиг дзен, а у меня всё не по дзену. Так что ещё раз повторюсь, не надо сказок по поводу ваших оценок. Я же не виноват, что чувство прекрасного редкая штука и посещает не часто.
и сразу же отвергается, но когда другие (имея на то причины) говорят то же самое про ваш код, у вас тут же пригорает и вы переходите на личности ^_^
Я кому-то сказал такое? Я вам лишь сообщил о моём восприятии. Не путайте. Это не одно и то же.
Опять же — это начали делать вы, я лишь стал копировать ваше поведение, и вот вы уже снова недовольны когда к вам обращаются ровно так же, как и вы к другим :)
Что начал делать я? Вот это?
Фу, пробелов нет между // и комментом.
Фу, длина строки больше 110 символов.
Фу, табы не наглядные, в стиле кланг-формат.
Фу, комменты на русском.
/* Что это? Душность в ответ на душность, наверное. */
Так это я, стало быть, виноват в том, что мне с нифига такое пишут? ;)
А где я писал, что мой подход правильный?
Если что-то утверждают, значит, считают единственно правильным. В противном случае только советуют в стиле «я бы сделал бы так...».
То есть вы делаете какие-то выводы про ваших оппонентов, не зная про вас вообще ничего. И, само собой, промахиваетесь.
К счастью, меня бог миловал иметь такое же «чувство прекрасного» как у вас.
А вы не находите, что сейчас вы сделали то же самое, что сами же и критиковали? А про абстрактного Васю я вряд ли промахиваюсь — я этих «Вась»насмотрелся тьму. Все как под копирку с апломбом и таким раздутым ЧСВ, что аж солнце заслонит. И, что характерно, это общая болезнь этого сайта.
С другой стороны, чувство прекрасного не выбирают. Но если вам нравится тот код, что получил +7, то тут уж ничего не поделать. Каждому своё.
И вырвал бороду седую
Костлявый высохший старик,
И так воскликнул, негодуя:
— Казнить его — он еретик!
Так вот, иначе как хамством всё нижеперечисленное не является:
«И чему же равна ширина тайла? Почему не пишете об этом в комменте?»
Про «фу» я уже показывал.
«Но особенно круто — комментарий „конструктор“»
«Это пример или у тебя столько визуального мусора в коде? Зачем ты дублируешь всё, где и так понятно из названий переменных, типов и методов? Про русские комменты вообще молчу. „
Нет бы спросить по каждому пункту зачем да почему. Кто-то вот вообразил, что “конструктор» — это комментарий. Кого-то возмущают до глубины души комментарии на русском ( а знаете, результаты моей работы (в одной махонькой части, правда) вы всё прекрасно видели в новостях пару недель назад. И русские комментарии коду не помешали. Может, это потому, что они пишутся для русских?).
За сим откланиваюсь, ибо есть ещё чем заняться в выходные.
Для программиста английский это как латынь для врача.
Дело в том, что родители не догадались, что с распадом Союза потребуется английский. Вот и отдали на немецкий (который все в семье и учили). Так что в английском я самоучка и он мне не родной ни разу.
То, что вы процитировали выше, называется «сарказм» и «ирония».
А я-то думаю, чего это часто ругают весь этот IT-контингент за неспособность хоть к элементарной вежливости (токсичность, по-вашему). Я прям вижу, как придёте вы, например, к врачу, а он спросит вас анамнез и сразу сарказм и иронию в ваш адрес выскажет. Скажем, увидев вас сообщит «мда, не Аполлон...». Это будет так забавно смотреться! Только вы почему-то больше к этому врачу не пойдёте.
а на научно-техническом ресурсе с более образованной публикой, да?
Обученной, обученной. Образование — это несколько иная, более тонкая материя. К примеру, образованный человек такое бы не написал. Тактичность бы не позволила. Сами смотрите:
Давайте откроем /vk.com/habr.
На Хабре думающие люди делятся своим уникальным опытом, общаются, учатся,…
Вам не кажется, что в этом предложении отдаёт спесью и самолюбованием? Ох, какие они думающие, эти люди. ;) Ну так это очень хорошо в целом описывает данный ресурс, что упоминают довольно часто разные авторы.
Ладно, думаю, все всё давно поняли и продолжать мне отвечать смысла не имеет. Чтобы эти упомянутые тысячи программ написать нужно их писать, а не на форумах сидеть с утра до вечера. :)
Извините, но что вы называете программой?
Я называю программой законченное приложение для решения конкретной задачи. Как я уже выше указал, далеко не все из них являются масштабными проектами. И да, те же драйвера для QNX я могу написать несколько штук за день (и я писал — они логически внутри могут быть сложные (с очередями, прерываниями, режимами и так далее), но писанины там не так уж и много вне обёртки драйвера). Потому что у меня, разумеется, есть моя кодовая база (она довольно приличного размера в части чистого текста программ), позволяющая переиспользовать компоненты и архитектуру. На драйвер под Windows для Flir One я потратил буквально пару дней (с нуля), но перед этим было потрачено с месяц на выяснение принципов работы протокола обмена и в фоновом режиме я выясням, как вообще пишется драйвер (попутно родились программы работы с устройством для QNX без libusb и Linux с libusb). А просмотрщик снимков с этого тепловизора я написал дня за два (на MFC). Так получается потому, что технология построения таких приложений отработана и обкатана. Так же для микроконтроллеров программы под разное оборудование с одинаковым назначением пишутся путём модификаций и получаются разные программы (одна, грубо говоря, для одного типа дисплея, а другая для другого). Но это небольшие проекты. Большие могут писаться годами в фоновом режиме. Вот и выходит в среднем нет ни недели, когда бы хоть что-то не было бы написано. Кстати, выщеприведённое оформление тоже не набирается ручками — у меня сделан генератор шаблонов, где я просто указываю, что я хочу создать (класс, интерфейс (у них, кстати, префикс I будет, а не C), класс MFC с документ-вид, без документ-вид и так далее) и получаю готовую болванку, которую просто надо заполнить. Тем не менее, даже при частичной похожести, программы могут кардинально в чём-то различаться. Например, вот есть модель устройства, прикидывающаяся устройством в /dev. Меняем идеологию. Пусть работает через разделяемую память. Уже выходит две программы. Они работают по-разному. Но сделать второй вариант можно за день из первого (если уже отработана работа с разделяемой памятью, конечно).
Раз уж перешли к примерам конкретных IDE, я тоже упомяну свой инструментарий. По мере развития 1С от семерки к такси и от конфигуратора к edt, в модулях последовательно были применены практики:
Визуальное деление кода большими блоками комментариев, как у вас. Точный формат и состав этих блоков доступен в платной документации и в примерах типовых конфигураций. Соответственно, верстали модули кто как мог и считал логичным.
В какой-то момент добавили лексему "область", которая могла по нажатию плюсика прятать в себя все содержимое аналогично функциям и процедурам. Структуры модуля до сих нет, только линейный список всех функций в модуле, максимум - с сортировкой по алфавиту.
В edt уже появилась карта модуля, вроде расширением можно поставить, плюс схема модуля, с иерархией вложенности областей с быстрым переходом к куску коду.
Вами, кстати, всем этим оформлением поднят очень хороший, естественный, вопрос, я бы даже сказал, озвучена потребность. Только нуждающимся пользователем выступаете вы сами. И давайте ее немного переформулируем на чуть более высоком уровне абстракции. "Мне нужна новая сущность (подход) в виде проекции текста модуля в сжатом виде. Проекция должна быть лишена внутренностей реализации, оставляя только объявления и назначения, а также должна осуществлять быстрый переход к нужному участку". Другими словами, классическое оглавление книги или словарь терминов в ее конце.
Замечаете, как происходит эволюция оглавления? Начиная от пространных описаний к главам в "Путешествиях Гулливера", - через цветные срезы страниц и ярлычков на полях домашних докторов и книг по садоводству, - до настольных игр, целиком состоящих из указателей и справочников, например, "Шерлок Холмс, детектив-консультант". Оглавление сначала встраивается в текст, потом выделяется в отдельную сущность, а потом снова привязывается к сырому тексту для интерактива.
Эволюционно вы находитесь в начале пути, и на протяжении всей беседы сами это признаете. Ну да, молодые, да, шутливые, это правда, что нас миллионы и имя нам легион. И да, более приспособленные к современным реалиям и более открытые к коммуникации и совместной разработке молодые люди пытаются убедить вас, что нужно стремиться к стандартам и выбирать преемственность и воспроизводимость вместо воинствующего эгоизма.
И их [миллионов мух] код мне решительно не нравится.
И как все молодые, борзые и полагающие, что все, кто делает иначе чем вы, это отстой.
Как бы смотрите, даже по построению предложения тождественны, миллионы - это все, а мне - это молодые. Множество против одиночки. Чем вы тогда отличаетесь от молодых, если точно так же отвергаете чужую точку зрения?) Вам уже даже подсознание дает недвусмысленные сигналы, генерируя такие противоречивые парадоксы.
А IDEMomentics, например, не может.
В смысле "не может"? На видео 2011 года панель аутлайна присутствует. Да и с чего бы ей не быть, если это просто Eclipse с плагинами.
Я ваш коллега, я открыл ваш код. 16 чего? cm, mm, in, px, pt?
Имхо если это не код фронта, тем более на сях фронт не пишут, то вариант для единицы измерения только px (пиксели).
Кстати, никогда doxygen не использовали? Не видели, сколько там оформления (которое по-вашему, визуальный мусор) пишется?
А принцип именования как раз очень ясный и простой и позволяет не запутаться в сотнях объектов в большом проекте. И лучше венгерской нотации.
Дело в том, что есть и другие подходы, к которым тоже не сразу пришли. И это нормально, что для кого-то (большинства разработчиков, я подозреваю) Ваши зоны разграничения внимания являются визуальным мусором.
Свои проекты каждый, конечно, может писать так, как душе угодно.
Проблема может возникнуть, если придется работать с командой с другими взглядами на оформление кода. И аргумент "мне так нравится" уже не будет работать. И если вдруг без соблюдения своих практик держать в голове проект и легко оперировать им будет не получаться, то от этого потеряют все.
Я бы порекомендовал почитать "Совершенный код" Макконелла. Там довольно много хорошо обоснованных моментов, которые, возможно, помогут по-другому взглянуть на некоторые правила оформления.
Дело в том, что есть и другие подходы, к которым тоже не сразу пришли.
Видел, видел. Смотреть тяжко.
И это нормально, что для кого-то (большинства разработчиков, я подозреваю) Ваши зоны разграничения внимания являются визуальным мусором.
Как я уже сказал, это дело привычки.
Я бы порекомендовал почитать «Совершенный код» Макконелла.
Всё это давно было прочитано.
Проблема в том, что я вот сейчас на работе тыкаю достаточно большой сервер на плюсах. И он легаси. И без документации. Но я в этом легаси разобрался, я тоже без проблем с ним оперирую. Но разобрался в коде я, а вот он не разобрался, и ему легаси надо будет понимать. Поэтому я стараюсь по мере возможности документировать код не чтобы я понимал, а чтобы он понимал.
Ужас.
Очевидные комментарии ("конструктор", "деструктор" итд).
Нет отбивки пробелами для знака равенства и комментариев
Перед секциями public, private итд неплохо бы ставить пустую строку, иначе весь класс читается одним куском
Геттер неплохо бы иметь константный и неконстантный
"Указатель на класс" - расстрелять
(void) - привет из C. В плюсах (void) и () в определении это одно и то же
Несколько подряд секций public, решение очень на любителя
Заполнять дефисами комментарий - ооооочень на любителя
GetPtr - куча проблем, см. коммент 0xd34df00d. Зачем shared_ptr синглтону??? Вы написали сто комментов вида "конструктор это конструктор", но не потрудились закомментить единственное неочевидное место в коде.
Именование - куча проблем, выше всё сказали
"Переменные" в приличном обществе называются полями класса
Русский язык в комментариях
Вот поверхностные косметические изменения
(комменты на англ - заполнители, в реальном коде надо более подробные)
#ifndef C_IMAGE_STORAGE_H
#define C_IMAGE_STORAGE_H
#include <QtWidgets>
#include <stdint.h>
#include <memory>
class CImageStorage {
public:
CImageStorage();
~CImageStorage();
// constants
static const int32_t TILE_WIDTH = 16;
static const int32_t TILE_HEIGHT = 16;
static const int32_t TILE_BORDER_WIDTH = 1;
static const int32_t TILE_BORDER_HEIGHT = 1;
static const int32_t TILE_WITH_BORDER_WIDTH = TILE_WIDTH + 2 * TILE_BORDER_WIDTH;
static const int32_t TILE_WITH_BORDER_HEIGHT = TILE_HEIGHT + 2 * TILE_BORDER_HEIGHT;
private:
// data getters/setters
const QPixmap& getTiles() const;
QPixmap& getTiles();
static std::shared_ptr<CImageStorage> getPtr(); // wtf
// data members
QPixmap qPixmap_Tiles; // tileset
static std::shared_ptr<CImageStorage> cImageStorage_Ptr; // wtf
};
Подскажите, а зачем нужно две версии геттера, если константного достаточно? Точнее, существование неконстантного геттера автоматически ломает const-correctness, разве нет? Что-то вроде "гарантирую, что сам экземпляр класса CImageStorage не изменится, но если очень хочется, то можно"? Либо наоборот - если возвращаемый объект может быть изменен, то оставить только не-const версию? Как я понимаю, QPixmap& getTiles() const - не вариант? То есть, я чуйкой чую, что вы написали правильно, просто не хочу следовать таким практикам вслепую, хочется понимания.
Подскажите, а зачем нужно две версии геттера, если константного достаточно?
Достаточно его или нет, зависит от спецификации / соглашения. В некоторых случаях да, спецификация может говорить, что поле класса не предусмотрено для изменения. Или предусмотрено, но через сеттер. Тогда да, можно иметь только константную версию. Наличие сеттера эквивалентно наличию неконстантного геттера.
В данном случае в коде, который был до моего изменения, использовался неконстантный геттер и константного не было. Значил изменение qPixmap_Tiles предполагалось делать через неконстантный геттер. Устранять это соглашение особого смысла нет и поэтому в данном случае неконстантный геттер убирать не стоит (не говоря уже о том что такое изменение, условно, сломает API compatibility).
Почему при наличии неконстантного геттера стоит добавлять константный думаю понятно - нельзя вызвать неконстантный метод у константных объектов, поэтому у объекта const CImageStorage или const CImageStorage& компилятор запретит вызывать getTiles(). (Т.е. у таких объектов вообще запрещено будет узнавать qPixmap_Tiles, что вряд ли соответствует желаниям разработчика).
"QPixmap& getTiles() const" не скомпилируется.
Есть два разных мира - простой и ясный мир создания новых продуктов и сложный и мутный мир сопровождения долго существующих монстров.
Не помню, где это было - в "Бэтмене", что ли? - "ты либо умираешь героем, либо живёшь достаточно долго, чтобы превратиться в чудовище". Создавать новые продукты по чёткой спеке приятно и весело, но далеко не все такие продукты находят своего пользователя. Обнаружить в какой-то момент, что твои многомесячные труды берут и сливают в пустоту, весьма и весьма паршиво. С другой стороны, работая над многолетним "монстром", ты чётко понимаешь, что этот труд принесёт реальную пользу реальным людям. У меня был опыт работы в обоих мирах, и свою сторону, кажется, я выбрал.
Это все реклама :-) пропущено самое интересное
Есть ясный описанный набор требований на спринт
Есть кто-то, кто делает их ясными и понятными? Кто эти люди и сколько их?
Каждый постоянно работает с одними и теми же модулями, которые хорошо знает
А если кто-то заболел или даже уволился? Если получается «в модуле, который год назад писал Вася из Дубая нашли баг, разберись»? Как обмен информацией по структуре кода происходит?
Это все реклама :-) пропущено самое интересное
Ну нет же. Не реклама. Компания простая и люди простые. Не из таких про которые вы подумали.
Есть кто-то, кто делает их ясными и понятными? Кто эти люди и сколько их?
Из тех команд что знаю, в одной команде это тимлид и ему помогает QA, в другой это тимлид и UX, в третьей это аналитик, и дальше тимлид с разработчиками. В остальных не знаю. Но вообще работают разные схемы.
А если кто-то заболел или даже уволился? Если получается «в модуле, который год назад писал Вася из Дубая нашли баг, разберись»? Как обмен информацией по структуре кода происходит?
Тогда тот кому этот модуль достался потратит пару недель чтобы вникнуть. Но такие кардинальные перемены бывают один раз за год, грубо говоря. Вообще, есть команда и есть стабильный логически связанный набор модулей (микросервисы, модули UI) которым она занимается. Все в команде в той или иной степени понимают работу команды в целом и хорошо понимают свои модули...
Вообще, мне хотелось больше прочитать как работают другие, чем описывать самому.
Так плюс-минус все так и работают, пока есть люди, которые знают как под капотом.
Но такие кардинальные перемены бывают один раз за год, грубо говоря
Кажется это ключевой момент, вам повезло со стабильной командой. Как только выходишь за какую-то грань, тимлид перестаёт успевать расписывать все это, отдаёт на откуп разработчикам со всеми последствиями.
Ну, а джуну действительно кажется, что везде темный лес и беспросветность, такая у него, у джуна тяжелая жизнь :-)
Кажется это ключевой момент, вам повезло со стабильной командой. Как только выходишь за какую-то грань, тимлид перестаёт успевать расписывать все это, отдаёт на откуп разработчикам со всеми последствиями.
Вроде того. В данном случае я и есть тот самый тимлид, который не успевает все расписывать и ищет способы переложить часть своей нагрузки на других членов команды. В других командах тимлидам это как-то удается. Вариант когда разработчики в итоге пишут по 3 строки в день и только мучаются с выяснением задачи мне кажется нерациональным.
К комментарию @auddu_kя бы ещё добавил
Программисты не решают задач "там какая-то проблема".
А кто в команде решает задачи «в коде какая-то проблема»?
Таких задач не бывает. Приведите пример. Всегда есть кто-то кто видит проблему (тестировщик, аналитик) и есть кто-то кто проектировал систему. Тот кто проектировал скажет тому кто видит проблему - это баг или фитча. Если баг, тестировщик воспроизведет и покажет программисту. Если фитча, тот кто проектировал напишет или уточнит требование.
Конечно это не работает без того, чтобы вся команда понимала в той или иной мере всю суть проблем и продукта. ИМХО, надеяться на то что программист может работать формально по требованиям они не оправданы и слишком дорого обходятся. Но задачи типа "какая-то проблема, разберись", это издевательство и неэффективно.
Пример задачи: «юзеры жалуются что система тормозит». Без уточнений. Таких задач не бывает?
Я правильно понимаю что в вашей идеальной команде все кроме программиста должны понять в чем конкретно проблема, разжевать это программисту и тогда он, так и быть, профиксит?
Пример задачи: «юзеры жалуются что система тормозит». Без уточнений. Таких задач не бывает?
Ну, это же не внезапно случилось и команда не с луны свалилась. Наверно те кто ее разрабатывает знают что у нее есть слабые места. Кто-то имеет контакт с юзерами? Пусть он пригласит тимлида с тестировщиком и покажет им что конкретно имеется ввиду. Потом позовем еще раз уже с программистом или программистами, поймем какой критический случай нужно исследовать, сформулируем в виде требования и поручим это программисту.
Или если это локальный случай попроще, тогда жалоба передается тестеру, он воспроизводит, показывает тимлиду, тот пишет требование на программиста.
Я правильно понимаю что в вашей идеальной команде все кроме программиста должны понять в чем конкретно проблема, разжевать это программисту и тогда он, так и быть, профиксит?
Иногда так и есть. Во всяком случае если проблема сильно неопределенная, это не задача для программиста. Это задача для тимлида и тестировщика для начала. Если прямо совсем не ограждать программистов от правды жизни, это будет не сильно эффективно.
Что-то я переборщил с наводящими вопросами, напишу развёрнуто.
В начале карьеры я работал в командах с похожим принципом управления - глубокая иерархия (тимлид на 5-10 человек), специализация и формальные процессы.
Я не утверждаю что этот принцип плох, более того, я думаю программисту в таких условиях работать комфортнее всего. И эффективнее, если под эффективностью понимать количество и качество кода.
Но если под эффективностью понимать «способность решать бизнес-задачи» - не соглашусь. Отсутствие контекста и формализация (каждый пилит свой кусок, «тестирование - не моя работа», «без джиры с места не сдвинусь») добавляет существенный оверхед.
В результате задачи которые по жёстким процессам решала команда (или компания) из 100 человек и 20 менеджеров (передающих между ними задачи) можно с успехом решать плоской командой из 20 человек плюс менеджер, где «это не моя проблема» считается дурным тоном. Это не теория, это пара примеров из жизни. И это не отменяет специализацию конкретного человека в конкретной области (разработка на языке Х, тестирование, дизайн, поддержка).
В каком процессе работать - каждый решает сам, но угадайте в какой команде платят больше, если учесть что бизнесу плевать как организована команда - за определенную задачу платится определенная сумма.
Разделение труда - это конечно прекрасно. Но в основном для работодателя. Это позволяет нанять толпу низкоквалифицированного персонала и за счёт строгой организации процесса получить массовый продукт приемлемого качества на выходе. Для работника - не факт. Первые пару лет крутить гайки на конвейере может быть комфортно и интересно, но потом обычно надоедает.
Плоская команда которая достаточно хороша чтобы сама все делать, это команда мечты тимлида, это да. Если проект делает 20-30 команд, добиться подобного уровня вовлеченности и найти таких людей наверно сложно. Я уговариваю свою команду на гибридный вариант: когда тимлид (это я) не открещивается от микроменеджмента, но при этом каждый программист понимает все что только в состоянии понять про общие цели, предметную область и код, а дальше он настолько помогает в проработке требований, насколько может. Т.е. каждый "берет столько суверенитета сколько может".
Если все трудно и неопределенно, скатываемся к жесткой иерархии, если все всем понятно, работаем параллельно.
Первые пару лет крутить гайки на конвейере может быть комфортно и интересно, но потом обычно надоедает.
"Надоедает" - это полбеды. Беда ,когда начинается массовое сокращение и наш миньон, ничего не умеющий, кроме как крутить гайки (привет, спциализация и оттачивание мастерства вглубь), оказывается на открытом рынке, где может оказаться нужным что-то фрезеровать или варить. Или и то, и то и плюс объяснять заказчику почему нельзя приварить алюминиевые трубы к стальной балке.
Пример задачи: «юзеры жалуются что система тормозит». Без уточнений.
Пример задачи: «юзеры жалуются что система тормозит». Без уточнений. Таких задач не бывает?
Это не задача, это жалоба пользователя. Задачу поставит QA специалист, когда разберется, что именно и как тормозит.
Готов отправить в вашу контору резюме вот прямо сейчас, если у вас действительно так все прекрасно.
У меня сейчас так - легаси-проект, которому 30+ лет, работала над ним не одна тысяча человек, включая далекие солнечные страны, да, есть аналитики и чаще всего расписано что и как делать, но бывает, что решение предложено изначально не очень рабочее и конечный результат с ним совпадает ну примерно никак. Плюс работа каждый раз с новым куском кода, а объем такой, что за полтора года полная картина сложилась ну очень приблизительно. Ну и работать в связи с "известными событиями" осталось примерно недель 5, потом Добби выдадут его носок...
Если тебе говорят куда и как написать написать - ты кодер. Если говорят что надо написать, но не говорят как, - ты программист. А если говорят только что должно быть на выходе - ты разработчик.
Есть еще один варианты, когда они сами не знают, что должно быть выходе, как это писать и куда, но есть очень абстрактная проблема и её надо решить.
А есть еще такой вариант, когда никто вообще ничего не понимает и не хочет, а тебе надо сделать какую-то волшебную зверушку, которая бы вскрыла и решила неведомые проблемы.
И все это удивительный мир айти.
ИМХО тут все просто. Автор хочет работать кодером, а его вынуждают стать программистом. По-моему нужно перестать скулить и начать работать. Мозг - это мышца, основной орган программиста. Она очень неплохо качается, когда читаешь чужой код, пытаешься разобраться в чужой системе.
Вот это самый лучший комментарий, на мой взгляд.
А еще бывает вариант, когда ты разработчик, но тебе говорят куда и как писать менеджеры
Только начинаю вкатываться в мир айти, но эта идея меня страшит больше всего :(
Меня ужасает одна лишь мысль о том, что мне придётся писать не проектики, в которых я назову конструктор конструктором, сеттер сеттером и геттер геттером, в которых мне IDEшка как заботливая воспитательница в детском саду поможет весь визуальный мусор убрать, в которых к каждой крошечной функции написаны красивые и приятные глазу докстринги, а аки аквалангист нырять в чернющие воды легаси кода, который работает по абсолютно неведомым принципам (да и причинам тоже). Честно говоря даже не знаю как к такому подготовиться, если опыта над реальными задачами нет. Поделитесь мудростью, Джирая-сама
Вот только недавно распараллеливал код "за кнопкой". Код правда сам писал , но уже успел забыть многое из него и там всё было плохо в плане распараллеливания - глобальные переменные и т.д. В итоге всё как-то заработало, причём без существенного переписывания предыдущего кода.
Выглядит как работа инженера на производстве. Не IT, а просто инженера. Как любят говорить, если ты тут все понимаешь, то на это место инженер не нужен, хватило бы монтера с инструкцией.
Так и должно быть? У всех? Везде? И у вас? Вот вы честно мне скажите – я один такой? Все прям читают код и понимают его? И понимают, зачем понимают?Некоторые не читают чужой код и не понимают его.
Нередко именно от таких людей звучат фразы «тут все из г-на и палок, ничего не сделаешь, надо переписывать с нуля». Хотя бывает реально из ГиП, но даже в этих случаях не всегда рационально всё переделывать.
И ведь переписывают. Потому что писать код приятнее и проще. Иногда даже лучше делают чем было. Иногда делают легкий рерайт и называют это красивым словом рефакторинг. Но в любом случае на это, как правило, уходит больше времени, чем ушло бы если бы прогер разобрался в коде.
А потом приходит новый программер и говорит ту же самую фразу. Или возвращается старый и задается вопросом куда дели его идеальный код и откуда здесь эта поделка.
Вообще, по правильному, разбираться в чужом коде должны отдельные люди. Это не то что бы очень сложный скилл, но это качественно другой скилл. Даже на иностранных языках можно пример привести — навыки аудирования и речи — очень сильно разные навыки, хотя казалось бы язык один и тот же.
Вообще, по правильному, разбираться в чужом коде должны отдельные люди
Ну надеюсь, что мы к такому не придём. А то как же мне страшно будет жить в мире, где половина может только слушать, а половина только говорить:)
У нас в компании это требование есть на определённом грейде. Типа, раз новенький побегай пока, а потом это и тебя коснется
Ну надеюсь, что мы к такому не придём. А то как же мне страшно будет жить в мире, где половина может только слушать, а половина только говорить:)Помните анекдот про авторемонтника который взял 1р за то что стукнул и 99р за то что знал где стукнуть? Диагност авто и слесарь это разные профессии и разные навыки. Строитель и инженер по приемке тоже.
Задача «слушателя» — разобраться в чужом коде, понять что и как в нем работает, написать по нему ту самую документацию которой нет.
Если Вы приехали во францию с группой программистов — Вы же не будете требовать от них всех вникать во французский язык, Вы возьмете переводчика которые вникнет в суть и переведет Вам то что надо сделать. А потом сделаете, на своем языке. Чужой код — считай тот же другой язык в какой-то мере.
Программист пишет код. Не читает, не анализирует, не тестирует, не оптимизирует.
Программист чаще и больше читает код, нежели пишет. Именно поэтому важно код красиво оформить, протестировать и проанализировать прежде чем его передать другим, чтобы они могли больше писать и меньше тратить время на чтение.
Ещё у чужого кода есть диалекты, стандарты, требования к использованию. Знать их все не обязательно, потому что невозможно, но «надо их уважать». Ибо раз я читаю и хочу использовать их код, а не они мой, то уважаемые люди – они.
А кто вас уважать должен с вашим нытьём? Радуйтесь, что не мешки таскаете.
От того что вы прочитаете чужой код вы не умрёте.
Спасибо за статью. Среди большого количества материала а-ля "Как я вошёл в айти легко и непринуждённо" - глоток свежего воздуха и, возможно, для кого-то отрезвляющего, взгляда на процесс.
Эх, все-таки, @nmivan пишет лучше всех на хабре, даром что из 1с-ников. Каждый пост у него - это законченный фантастический рассказ с завязкой, кульминацией и кодой, поразительно. И круто.
Возможно, не "даром, что", а "потому, что". Насмотрится за целый день на конструкции, типа:
Если Нет = СервераОтвет()вот и тянет потом писать прекрасное с использованием того же языка))
С оценкой "лучше всех" - пожалуй, соглашусь.
По основной части - хоть и работаю несколько поболе персонажа из статьи, но все равно - бывают ситуации, когда не можешь понять как работает что-то в целом и где надо гм.. "распараллелить". И приходится долго разбираться, а не писать. И бывает, что требуется помощь тех, кто в проекте уже давно. И важно не замыкаться в самокопании, а идти и спрашивать и добиваться ответа. Через время будут спрашивать у тебя. И это нормально - это тоже скилл - "умение работать в команде". Ведь что хочет от тебя бизнес, как от "специалиста" - решенных задач. И если для этого надо идти и общаться - надо идти и общаться. Где-то слышал выражение, что комфортность в команде можно оценить по тому, что на митинге не страшно ляпнуть какую-нибудь глупость.
надо было ему в 1с идти - там бухгалтерши, а значит чай и печеньки
Я за 3 дня написал строчек 40 кода +-. Остальное сидел и просто пытался понять, почему эта хрень не работает.
Бывает, всю неделю малюешь в UML редакторе, и ни одной строчки кода не пишешь))
За 2 дня удалил 54 строки (-60+6), остальное время разгребал кто ****************** и какого *************, зачем это *********************. В итоге уменьшилось кол-во чтений в 10 раз, скорость выполнения в 5.
MS SQL, хранимая процедура, код чужой, он давно был в проде, но пришлось заняться когда при увеличившийся нагрузке вылез как виновник. Сами разработчики отказались заниматься, типа тут уже нечего оптимизировать, надо наращивать железо, вот пришлось заняться. В итоге железо вздохнуло свободнее.
Похоже настало время пройти курсы по Reverse Engineering
ха-ха-ха. А чего ждать после курсов? Что такое понимать чужой код- ну вот стоит прочесть покойного Касперского "отладка программ без исходного кода".
Касперски. А Касперский еще жив
Добро пожаловать в реальный мир)
Все прям читают код и понимают его? И понимают, зачем понимают?
Да, это 80% рабочего времени. И это умение отличает джуна от всех остальных. Опытный программист ставит и описывает задачу зная контекст. А контекст он берет не из воздуха, а читая код.
Пусть, как и в прошлом месяце, более опытный программист в моей задаче укажет, где я должен написать код.
Вот тут вы собственно неявно просите опытного программиста нырнуть в код, почитать его пару часов и выдать вам выжимку в тикете.
И это не ночь, а серые будни. Привыкайте :)
Программист пишет код. Не читает, не анализирует, не тестирует, не оптимизирует.
Это изначальная ошибка в понимании что такое "программист". Тут уже писали про разницу между кодером, программистом и разработчиком - все правильно написали.
Я не знаю как называется ваша должность в трудовом соглашении. Но вот у нас нет таких - "программистов". Есть "разработчики".
А разработчик - он не "пишет код". Он решает задачу бизнеса. А она в общем случае может быть трех видов
дефект - когда функция в каких-то условиях работает не так как надо
изменение функционала - когда функция работает, но требования к ней поменялись и нужно изменить алгоритм
новый функционал - когда нужно создать что-то новое
Самое простое - это третий случай. Там все новое, все с нуля. Нужно только разобраться что дадут на вход, что нужно получить на выходе и реализовать это максимально эффективно и так, чтобы это органично встроилось в уже существующую систему, ничего вокруг не поломав.
Первые же два случая требуют вникания в уже имеющийся код. В первом случае понять как оно работает и почему работает не так в каких-то конкретных условиях. Во втором - как оно работает сейчас, что и где нужно изменить чтобы оно работало в соответствии с новыми требованиями.
И тут вам никто не поможет. Это часть вашей работы. Максимум, на что можете рассчитывать в случае дефекта - хорошая аналитика с описанием в каких ситуациях что идет не так и подготовленные тесткейсы, воспроизводящие дефект на тестовой среде где можно простепать под отладчиком и посмотреть что именно там внутри происходит.
Ну и в любом случае очень помогает актуальная документация где будет расписано что именно делает тот или иной модуль.
И да. Приходится и чужой код изучать и блок-схемы на бумажке рисовать. Добро пожаловать в мир коммерческой разработки.
Ну и пошловатая фраза - "в первый раз всегда больно". Это именно то, с чем вы столкнулись сейчас. Лишение иллюзий.
Самое простое - это третий случай. Там все новое, все с нуля. Нужно только разобраться что дадут на вход, что нужно получить на выходе и реализовать это максимально эффективно и так, чтобы это органично встроилось в уже существующую систему, ничего вокруг не поломав.
Если это бизнес задача - может быть не совсем легко. Особенно если никто не понимает, как именно надо решать эту задачу, и именно тебе надо в этом разобраться. )))
Если это бизнес задача - может быть не совсем легко. Особенно если никто не понимает, как именно надо решать эту задачу, и именно тебе надо в этом разобраться. )))
Согласен. У нас, правда, всегда есть аналитики, консультанты направлений с которыми можно обсудить подобные вопросы.
Но в любом случае "с нуля" проще, чем когда надо еще разбираться в чужом коде. Особенно, если код написан давно одним человеком, а потом в него еще несколько вносили свои правки и доработки...
И бывают задачи с очень сложной бизнес-логикой, использованием кучи дургих модулей, да еще когда никто толком уже не знает как оно все в целом работает и откуда вызывается. Иногда такие расследования приходится проводить...
Периодическое ощущение синдрома самозванца - это нормально. Технологии развиваются, чуть ли не ежедневно появляется что-то новое. Не понимать - это нормально. Не хотеть понимать - уже печально.
В больших проектах, в частности, всё уже бывает написано. Для каждой ситуации, есть свой готовый код. Нужно только правильно вставить те самые 2-3 строчки, чтобы всё заработало как нужно. И, да, для этого нужно прочитать много написанного кода, чтобы понять какие именно строчки добавить. Временами, у меня тоже возникает чувство полностью переписать какой-то модуль, компонент или, даже, проект (конечно, если это не что-то глобальное). Но, с опытом приходит понимание, что не для каждой задачи нужно писать код - иногда, нужно его и удалять. Это как кубики конструктора - для создания крепкой и красивой конструкции, каждый кубик должен быть в определённом месте.
Кстати, про стиль разработки - это, нечто, вроде этикета - нужно придерживаться выбранного стиля, чтобы код (проекта) выглядел единообразно. Иначе, читать его будет всё сложнее и сложнее, если каждый разработчик будет писать его по-своему.
Я погряз в непонятно чём. Чтении чужого кода, понимании контекста, попытках воспроизвести ошибку, анализе производительности, понимании диалектов, режимах отладки. Так не должно быть. Не должно!
Но без этого никак. В любом эксплуатируемом коде рано или поздно что-то находится не то. А разработчиков давно нет и кто-то должен разобраться. К этому программисту надо быть готовым. Это как сантехник! Где-то что-то лопнуло, протекло и т.п. И что бы мы делали без них. Афоня знал, что нез него и нитуды и ни сюды.
Жаль конечно что такое происходит, но таков путь. Легаси и гавноконтор много, попасть туда очень легко, понять куда попал без опыта чертовски сложно, да и с опытом бывает. Это про оплату еще ни слова не сказали, а там тоже свои трюки бывают.
Если унифицировать, то в таких конторах новичков кидают в жернова, кто сможет, тот вылезет, остальные сами уйдут или их выжмут.
Что не убивает, то закаляет) Выше нос, это только первая компания, смотрите как на хороший опыт, возьмите перерыв и поищите другую, может удаленно, если у вас в городе всего 2.
Интересно написано, плюсанул. Среди многочисленных отзывов о курсах это отзыв о первой работе джуна после курсов, что конечно косвенно снова продвигает идею курсов, но все равно, мне кажется более ценной информацией для новичков.
Один из моих запросов после моих курсов был узнать что же вообще делают разработчики, как расписан их день, какие задачи решают.
Насчет компаний - как нам рассказали в блоке про трудоустройство - глобально можно разделить компании на стартапы, продуктовые и государственные (точно не помню название). У автора типичная продуктовая компания с присущим стилем управления и постановкой задач. Здесь ценится умение читать чужой код и добавлять свой так чтобы его быстро поняли коллеги. Про "творческие" задачи согласен, сложно так после решения стольких продуманных, разжеванных задач взяться за неопределенность. У самого такие стали появляться. И это вызов, справишся быстрее - быстрее повысишь свой уровень. Это прямо из мема про джунов-мидлов-сеньеров и формулировки их задач.
Я погряз в непонятно чём. Чтении чужого кода, понимании контекста, попытках воспроизвести ошибку, анализе производительности, понимании диалектов, режимах отладки. Так не должно быть. Не должно!понял, что это графоманство.
Чувак, держись! Если тебя не увольняют и платят ЗП - значит все идет нормально. Просто держись, со временем все наладится.
Не бывает такого - ты пришел в первый день в тренажерный зал, а завтра уже олимпийский чемпион. Мастерство нарабатывается годами
Все сеньоры проходили эту стадию "джун непонимающий". У меня это заняло 3 года, у кого-то быстрее, у кого-то медленнее.
Все нормально идет пока, постарайся не срываться на ближних (я срывался((() погуляй вечером в парке, сходи с женой в кафе, покатайтесь на великах и тп. Все будет хорошо!
А почему нет ни слова о code review? Если смотреть каждый раз, как данную тебе задачу решили другие - в следующий раз ты уже будешь примерно представлять как ее решать и в каких местах нужно делать изменения.
Знаете, что мне ответили? Опытный программист не может мне помочь. Он не найдёт, куда мне писать код. Ему некогда.
Поздравляю, ты попал в компанию с неадекватным руководством. Нанять не то, что джуна, а полного нуля после курсов, и ожидать от него самостоятельности - это надо уметь.
Хотя, часто это не ошибка а стратегия - нанять милда за цену джуна. Вдруг кто-то не знает себе цену.
С другой стороны, негатив в сторону курсов понятен (и жду еще большего количества статей на эту тему) - джуны и раньше были не особо нужны на рынке (как раз по тому, что большинству некогда ими заниматься), а с текущим кризисом еще хуже.
В айти стоит идти только если тебя самого тянет попрограммировать на выходных. Просто для себя, в удовольствие. Если этого желания нет - не стоит прожигать свои глаза и нервные клетки на этой айтишке.
Только полноценно поймёт тот, что в этом по уши хотя раз вывозился этак с месяцок)
Если это сарказм - то написано хорошо.)))
Если не сарказм...
Прямо сейчас у меня похожая ситуация. Перехожу в другую область - из MS SQL SSAS / SSRS -> spark and Airflow
И нормально. Разбираешься, читаешь доки, многое не понимаешь... Так это нормально! Это и есть работа.
Наверно, на курсах надо первым делом объяснять, на что уходит большая часть усилий.
Вот хорошая статья, например.
https://habr.com/ru/company/dcmiran/blog/663950/
Там в начале очень полезная диаграмма приведена. Из книжки, которой больше лет, чем герою статьи. )))
— Прочитал я Ваш роман, слабовато… А кого из классиков Вы читали? Достоевского, Толстого, Тургенева читали?
Чукча подумал и, почесав затылок, отвечает:
— Однако, нет. Чукча – не читатель, чукча – писатель.
Ха, а вот самое интересное разбираться не в чужом, а в своем коде, написанном несколько лет тому назад.
Иногда влезаешь в это и по привычке начинаешь крыть матом того придурка криворукого, который это говнокод написал....
Похоже вам не повезло с первой работой. Я бы не отчаивался на вашем месте. У вас отбили желание работать плохим менеджментом и некомпетентными ожиданиями. Reverse engineering это определенный набор навыков и он не всем дается хорошо и не всем это интересно. Этому стоит поучиться (а главное с опытом это придет), но то, что вы пока этого не умеете не означает, что вы не можете зарабатывать разработкой. Дайте себе время.
Интересно, как справляются профессиональные музыканты, у которых основная деятельность как раз в чтении и разборе (а те кто что-то пишет, уже гордо называются композиторами).
Я в айти по энтузиазму, и все чаще замечаю разницу между собой и людей "с курсов" - я начинал с пет-проектов. Не было ни заказчика, ни дедлайнов, ни курсов, был только ты и Github (а в более давние времена ты и листинги из журналов). И чтение кода на нем стало в какой-то момент основной деятельностью.
Может в процессе обучения на этих ваших "курсах" этот этап как раз и пропущен?
Кстати, тоже стало интересно что чувствуют люди, которые приходят в ИТ не по энтузиазму, а после курсов. Я помню мое первое задание на первой после вуза работе - что то в духе: "Хочу чтобы логировался текст со всех текстовых полей со всех программ после закрытия. В том числе Word, Excel, IE а не только калькулятор и блокнот". Это были времена Win98-Win2000. В команде было два человека вместе со мной. Мне тогда очень помогло многолетнее ковыряние в спектруме и знание ассемблера Z80 и, в последствии ковыряния в х86, так как пришлось лезть в глубь WinApi и в отладчике смотреть как и где можно перехватывать вызов функций. Второй сотрудник полез еще дальше в ядро и там смотрел как скрывать процесс логирования и как внедрять мой кусок для перехвата в другие процессы. Не представляю, как с таким справится после курсов С++ :)
Профессиональные музыканты слышат партитуру. Читают ее, а в голове музыка.
Хехе, на одном проекте я был единственным, кто ОЧЕНЬ умел в чтение чужого кода. Те, кто его написал, уже давно ушли.
Я не писал код. Я рисовал презентации, схемы, диаграммы, создавал странички со стрелочками, кубиками, схемами. Я прослыл тем, который знает все, потому что мог открыть SQL на 20 тысяч строк, сгенерированный системой, и ловко обнаружить строку #17895, в которой поле XYZ умножались на 2.5, если значение было меньше 7. Почему, зачем? Никому не интересно. Но сам факт того, что я это мог найти, указать, где поправить, чтобы стало умножать на 3.5 вместо 2.5 приводил в трепет даже ГЛАВНОГО.
Это звучит примерно как хитрый план родителей "сына, только ты можешь так хорошо вымыть посуду! Мы гордимся тобой! Никто не справится с этим лучше тебя!"
Это не звучит, это так и есть. Сын моет посуду и получает за это хорошие плюшки. Пять минут у умывальника, зато потом весь день можно играть в приставку и требовать киндер, спиннер, лего, велосипед и ролики. Главное понимать, что в данном конкретном случае все это возможно благодаря очень удачному стечению обстоятельств и четко видеть момент, когда пришло время спрыгнуть и идти на работу, а не продолжать сидеть на шее. Я дождался хорошого джуна, передал дела, и ушел.
Если просто рассказ, то написано очень хорошо, если же это, что называется, "крик души", то...
Программист пишет код. Не читает, не анализирует, не тестирует, не оптимизирует. Пишет код! Для остального есть другие профессии!
Иными словами человек придумал себе какую-то фентезийную профессию, а потом испытывает бурю возмущения, что реальный мир не совпадает с его фантазией. Вот, например, работает в кампании программист, а потом взял и перешел в другую кампанию, в другой проект, вообще поменял сферу деятельности, надолго заболел и не может работать и т.д. Кто по мнению автора должен далее работать с кодом этого программиста? В представлении автора как только программист уходит, его код навеки замораживается и более не меняется? А если надо поменять, то все пишется по новой уже другим программистом? Или как себе это автор представляет? Задумывался ли автор над тем, что он вряд ли будет пожизненно работать только в одной кампании, а значит кто-то в будущем будет работать с кодом автора? Или в представлении автора он теперь будет пожизненно работать в этой кампании, дабы написанный им код можно было и далее развивать? Ну и еще 100500 аналогичных вопросов.
Программист пишет код. А очень хороший программист - читает и удаляет.
Вам прямо повезло поначалу: и способности есть, и задачи попадались прям нужные по сложности - вы оставались в потоке. И вы подумали, что так и будет всегда. Но трудности обязательно когда-нибудь случатся, ни у кого не было безмятежной королевской дороги. Именно умение их преодолевать и определяет человека.
По деталям: у вас наставники, которые очень далеко оторвались от вашего периода, неэмпатичные, негибкие. Это нормально: не обязан профи в программировании быть учителем и хорошим человеком заодно. Вы очень правильно разговариваете и задаёте вопросы. А вас кидают через очень большой разрыв (и возможно, вашим коллегам/руководителям это приносит некоторое садистское удовольствие, такой вариант дедовщины, - с ними наверняка поступали так же).
Понимаю, что сложно думать о переезде, но в некрупном городе (любом, начиная с 3-го в России) ожидать другого сложно. Я в период становления работал в московских компаниях, где к росту относятся бережно (кстати, к Яндексу и mail.ru это не относится - я про ABBYY и Лабораторию Касперского, например). Иногда может повезти и в небольшом городе, если человек специально заморачивается вопросом передачи знаний и бережно относится к инициации падаванов.
В ABBYY аккуратная система рангов и даже есть обучение (по крайней мере было, когда я там работал), в ЛК - есть чистые кодеры, там очень развесистый процесс, что можно себе это позволить (чтобы позволить быть чистым кодерам, должны быть архитекторы, техписы, аналитики, тестеры, дизайнеры интерфейса, performance-инженеры, release-инженеры и т.д, причём в нетривиальных пропорциях, что возможно в командах от 100 человек, думаю).
Но вообще, нужно понимать, что постоянная разработка даже в компаниях с наличием чистых кодеров возможна только при постоянных переписываниях проектов (раз в пару лет примерно). Намного чаще проект активно строят один раз, а дальше развивать становится труднее - потому что появляется много старого кода, который нужно поддерживать. В результате для того чтобы сделать задачу, 90%+ времени тратится на анализ требований, настройку стенда для тестирования, поиск решения и тестирование. Кодирование постоянно сжимается.
Если уйдёте - попробуйте создавать свои проекты хотя бы и поддерживать их. Со временем плавно приучитесь сопровождать, потому что даже свой же код через 2 месяца становится немного (или не немного) чужим. И пробуйте дальше устраиваться в другие места (этому можно поставить диагноз, если ваша обратная связь никак не помогает), у вас хороший потенциал.
Однако, это челлендж - что бы ответил персонаж, описанный Иваном @nmivan?
Тэги: Читальный зал
Вот поэтому я и не хочу входить в IT.
Потому что хоббби - это одно, а работа - это другое. Если я пишу ради хобби и не понимаю чужой код, я могу попробовать написать свой, я могу месяцами почитывать что-то на связанные темы, пока не пойму, вообще могу от задачи отказаться. Если я оптимизирую что-то по работе, то это не прописано в должностной инструкции и вообще подарок начальнику за то, что меня не дергали несколько дней и дали поковыряться с интересной задачей, иначе я б на работе с тоски помер .
Но на работе, где это основная обязанность, в режиме ошпаренной кошки требуют готовый продукт и безотносительно чего бы то ни было. Менять спокойную, пусть малоприбыльную нелюбимую работу на попытку входа в IT и все поставить на шаткую основу надерганных тут и там знаний - занятие для истинного мазохиста.
Можно нырнуть в эту бездну, начать заплыв на выживание с молодыми и сильными и за первые года три, охренев от всего происходящего, влиться в отрасль, прокачать скиллы до нужного уровня и проникнутся пофигизмом какого-никакого, но профессионала. Но нафиг. Если в комнате дерутся, то лучше туда не заходить, даже если тебе хочется.
Зато теперь ты готов пополнить отряд инфоцыган...
PS Добро пожаловать в ад, капитан! Мы тут живём тридцать лет,- и с зарплатами, втрое меньшими того, что указано на Хабре как "в среднем по IT".
А еще после правки надо будет найти все аналогичные места в проекте, которые писали третьи люди в третье время копипастом, коряво адаптируя под места вставки. Или, что еще веселее, писали совсем по-другому, не особо разобравшись в том, что такое уже где-то есть, и неплохо бы хоть как-то хоть что-то оптимизировать и унифицировать… Нет, конечно, они оставили это тебе. Ну, а что, кто-то говорил, что будет легко?
Так это ж самое классное: смотришь две недели в чужой код, потом напишешь одно слово и все заработало)
Автор, ты попал в точку! Нашёл и умело описал одну из ключевых проблем разработки. А многие даже не подозревают, что это ключевая проблема, но лишь простодушно сообщают, что "да, и я такое видел", ну и как оно им непонравилось.
Строчки со строгой грамматикой есть лишь инструмент для решения проблем. Но количество этих строчек при неправильном использовании инструмента само создаёт проблему. И неправильно использующие этого так и не поняли. До сих пор. Даже прочитав данный текст про начинающего программиста.
У меня вот ситуация обратная. Я умею и могу разбираться в чужом коде. Но на собеседовании обычно просят написать код, а не разобраться в чужом. А я не то что не могу, но у меня это медленно и не очень эстетично выходит. И меня не берут. И вот ситуация выглядит так - я сижу на низкооплачиваемой работе, берут каких-то амбициозных студентов, они пишут код, поднатаскиваются, переходят в другую фирму на более высокую зарплату, через месяц-два оказывается что их код НИХРЕНА НЕ РАБОТАЕТ, и кто вы думаете его исправляет? Да, это я, которого на более высокую зарплату не берут. Всем нужны говнокодеры, никому не нужны программисты.
Напомнило:
"Если бы архитекторы проектировали дома так, как программисты пишут свои программы — первый случайный дятел разрушил бы цивилизацию..."
Признаюсь, ранье считал это на 90% шуткой и верил в силу разума )))
Только покрытие тестами и рефакторинг спасут отца русской демократии.))
А так, да - умение читать и анализировать код, строить зависимости - это очень важный навык в нашей профессии. Курсы тут не помогут. Ковыряние библиотек и проектов из открытых источников, попытки отрефакторить и добавить функциональность в них - вот лучшая практика для этого навыка.
Вот так выглядела моя первая работа, десятки тысяч легаси кода на делфи (знал только паскаль немного к выходу на работу, плюсы и немного шарп). Никакого менторства, или документации. Есть задачи, и вперед. Печатали листинги чтобы как-то понять взаимосвязи. Было очень тяжело первый год. Стало проще после начала переезда на C#. Но вхождение в любую профессию требует усилий. Как говорят 10000 часов практики чтобы приподняться над джуном, и я согласен с такой оценкой.
Все решения саммых ценних задач выглядили примерно так:
"расскомментировать" функцию (которая по ifdef собиралась для другого случая), прописать ее вызов в место функции по умолчанию - 1 человеко/месяц
поменять в конфиге одно число на немного другое при переходе с одной платформы на другую (старая платформа была чуть более толлерантной, новая чуть строже) - 1 человеко/месяц
добавить в одно в одном месте инициализацию не нулем (инициализации вообще небыло, только объявление) - недели чел/мес.
Работа программиста это, в основном, созерцание (ранее написанного кода), и размышления (в том числе, и о том, как поправить то что созерцал) :)))
Ну не твоё и не твоё. Уходи.
Обучалась программированию в буткемпе. Навык чтения чудого кода пришёл как-то сам собой. Программирование, как правило, командная работа. Значит, и учиться тоже есть смысл не изолированно, а в группе
Вот прикол.
А тут на собеседовании предлагают читать чужой код :)
Я инженер по автоматизации, код писать (или "рисовать" в визуальных языках) приходится частенько, но куда чаще удаётся нагуглить уже готовые решения или хотя бы куски кода.
Переход на работу в айти страшно даже представить - как это вообще возможно в отрыве от производства и железа, что-то там абстрактное решать, да ещё в команде и с жёсткими сроками. Кошмар же
Читаешь порой хабр, все такие умные, получают огромные зарплаты. А потом встречаешь дикое легаси и думаешь - а кто вообще это пишет, раз все такие умные... )
Вот эта штука "я беспомощен и мне помогут" - это убеждение-баг. Из него нельзя исходить. Вернее, можно, но это большой риск.
А я уже могу писать, могу писать!
Могу тетрадку показать, и даже полистать.
Ого, да ты учёным стал, скажи, о чём ты написал?
А мне откуда это знать? Я сам хотел бы знать.
Ведь я сказал - могу писать! Писать, а не читать!
(c) Владимир Орлов
Вот именно поэтому я за процедурное программирование. ООП без внятных комментариев прочитать скорее невозможно. Разумеется, смотря какой код. Но иногда мне попадалась такая ахинея, что без поллитры даже на код глядеть не хотелось. А после и подавно.
ЗЫ. ненавижу ООП
и с очень понятным кодом
Для тех, кто вкурил его дао. Для остальных оно, особенно при передаче в поддержку, станет той картинкой про девочку и "стану проституткой" и будет хорошим таким кандидатом на переписывание всей это магии на текст, понятный представителю профессионального интеллектуального большинства. Ибо нефиг выделываться в энтерпрайзе :)
Для понимания ООП кода нужно разбираться какую логику группировки держал в уме разработчик при написании. Так же, если на каком — то этапе была выбрана неправильная абстракция, то исправление такой ошибки будет практически невозможно, и весь код очень быстро превратится в набор костылей. Инъекция зависимостей и декомпозиция решают часть этой проблемы, но, как правило, не бесплатно.
Вообще, все примеры чистого ООП на классах и прототипах ломаются уже на добавлении третьего класса.
Как-то я пытался раскурить какой-то графический компонент с гитхаба (то ли под Qt, то ли под Avalonia) для рисования графов. Хотел узнать, как это они трансформацию делают (зум и все такое).
Пришлось продираться через длинные цепочки наследования и композиции всяких Painter'ов и прочих подобного, в которой каждый очередной класс содержал строк 100 всякого бойлерплейта (прокидывания конструкторов, методов) и задавать себе раз за разом вопрос: "так, блин, логика где?". И это довольно распространенный случай.
ИМХО, все хорошо в меру.
Как говорится
прошу прощения за мемы
Мне во второй половине нулевых посчастливилось работать в американском проекте по созданию первого процессора для одночипового цифрового ТВ. Вот там было реально весело! Дизайн чипа делали наши ребята в Питере, мы с коллегой программировали звуковой тракт, всякие ресемплеры, эквалайзеры, эффекты типа Soni Clear Audio (полная обманка для слуха :)))). И вот приходит из Тайваня инженерный образец проца на инженерной же плате. Что в нем работает нормально, а что нет, никто не знает, невозможно при проектировании дизайна на 64-модульном серваке все смоделировать. Поэтому многие блоки на проце дублировались в нескольких вариантах, что-нибудь да заработает, как нужно )).
Доков нет в принципе, есть несколько корявых тестов на Си, которые работают на эмуляторе. Есть некий эмулятор на FPGA, который должен для имитации проца в РВ работать на частоте 40 ГГц! Короче, полная терра ингогнита. Двигаешься методом проб и ошибок, потом плата улетает ФИДЕКСом в Кремниевую долину, там аккуратные девушки из ЮВА золотыми проводочками отключают дохлые блоки и подключают замену. Через 2 дня плата уже у нас. Вот так и работали.
Пришел парень с золотой медалью Универа, в таком режиме работать не смог, посадили в тестировщики на аппаратном уровне. Мог работать только по строго написанной иструкции. А я наоборот от такой свободы балдел, это мое )).
Ты привыкаешь к этому. Скоро твой мозг сам делает перевод. Я уже даже не вижу код. Я вижу блондинку, брюнетку и рыжую.
Нужна насмотренность, чтобы видеть не просто код, а паттерны. А с насмотренностью появляется собственное ощущение "как надо", и зайдя в чужой код начинаешь видеть, что квалификация предыдущего программиста отличается от твоей (и местами в обе стороны). Зная "как надо" и имея внутренний перфекционизм легко пропустить то место, когда ты начать переписывать то за что тебе не платят.
Как я понимаю автора. Если писавший программист использовал нетривиальные методы это вообще попадание.
Вон на прошлой работе столкнулся с проектом где почти весь код был прописан в самой базе данных.
Или купленная иностранная корпоративная система управления предприятием на web без доков и исходников, для которой ты должен писать код её поведения.
Или система маркировки "Честный знак" где ты должен обмениваться с их сервисом кучами файлов xml и где нет никакой поддержки программистов от слова совсем и ничего не работает.
И инет не помогает, потому что там ничего нет по твоим проблемам и спросить некого.
Странно, что автор не смог получить никакую поддержку в фирме в течении месяца, учитывая что он просил помощи не раз.
Про ментерство, архитектуру и техническое описание проекта в этой компании не слышали? Тогда правильно, что увольняетесь. - в нормальных компаниях таких проблем нет.
Понимаю) у нас расп* стиль работы можно сказать - тимлид мой товарищ, я - джун девопс и 3 разработчика. Курсы я закончить не успел, но рвался на эту должность, а в прошлом электрик, шахтёр, пи**р вообщем всё что угодно не связаное с ИТ. У меня часто бывают депресняки на тему надо научиться kafka, а я вообще не соображаю что да как, потом ещё задачи, но меня не терроризируют по срокам вообще, если это не что-то срочное. Программисты наши делают децентрализованный мессенгер и тоже читают сутками. И я как девопс не начал работать, а читаю, пробую кучу всякого мало понятного ада, сейчас надо делат бекапы кластера, репозитория, а там нет мануалов - только документация, а я с английским даже не очень дружу. На моём скудном опыте я понял, что основная работа в ИТ это читать и гуглить, если ты не уникум и не родился с матринской картой в заднице конечно. Так что либо так либо вали в свою канаву. Я всё таки после помоек за 30-50к решил остаться тут - в этой сфере хотя бы человеком себя чувствуешь, а не рабом. Так что тащи, отец!
Проблемы есть и у организации и у вас:
Вы запаниковали. У вас стандартный для каждого программиста "синдром самозванца". Этого делать нельзя. Что должен делать джун?
Обгуглить всё, что только возможно. Даже свершить немыслимое: посмотреть, что на второй странице поисковой выдачи. Совет: не искать в Гугле, лучше на duckduckgo. Гугл стал слишком "умным" для программистов и выдаёт больше мусора, чем нужных результатов.
Если ничего не помогает - не ждать! Идти с вопросом к сеньору. Не бояться выглядеть тупым, а уточнять все непонятные моменты, пока есть доступ к телу сеньора. Это нормально! Если придётся, использовать грубую лесть. Человеку подсознательно приятно выглядеть умнее окружающих и пояснять им за жизнь. Но! Обращение во второй раз с тем же самым вопросом и с теми же самыми проблемами из-за того, что не уточнил всё сразу, гораздо хуже и выглядит ещё тупее. Сеньор постарается избавиться от такого тугодума, поэтому вас и отшивали. Тут уже без лести и глубокого раскаяния не обойтись)).
Зарубить себе на носу, что "синдром самозванца" - это нормальное состояние программиста, и если его проанализировать и употреблять, как мотиватор к развитию, то он станет помощником.
Где ошибки организации?
Сеньор, который за вас отвечает, должен понимать, с кем он имеет дело, знать своих людей и иметь индивидуальный подход. Если человек где-то застрял, надо это заметить, постараться понять, это врождённая тупость, разгильдяйство или просто паника или ступор. В первом случае человека лучше постараться отговорить быть программистом, во втором случае вышвырнуть взашей с пинком под зад, а в третьем случае сделать всё возможное, усадить человека рядом с собой и показать ему по шагам, как, что и где надо сделать, куда писать код, при этом не делать всё самому, а сразу просить джуна продолжать прямо тут писать до следующего затупа. Нормальный человек быстро схватит эти вещи и будет обращаться всё реже. А увидев, что его так поддерживают, нормальный человек не будет садиться на шею и приходить по пустякам, потому что поленился сам подумать. Опытный сеньор быстро такое выкупит и вот тогда помогать перестанет. Если сеньор с недовольной миной забирает работу джуна и делает её сам, то он плохой наставник, и делает хуже в том числе и себе. Надо уметь делегировать работу в полном соответствии со знаниями подчинённых.
Возможно у организации проблемы с организацией))) Вполне возможно, что вы не можете читать код, потому что это гoвнoкoд. В большой организации нужен style guide для кода, чтобы все писали в едином стиле, тогда программисты не будут три часа читать код, чтобы написать три строчки. Есть такие конторы, где только вот тот странный Вася у окна в толстенных очках, который не поднимает голову от монитора, толком знает, как всё работает, и если его собьет автобус, то тупо всё рухнет.
Сейчас нормальные люди обычно дорожат программистами, потому что нанимать новых обходится гораздо дороже, чем просто подтягивать знания имеющихся. Если вы не слишком хорошо умеете скрывать свою панику, то ваш ступор уже должны были заметить и сами попытаться помочь.
Совет могу дать только следующий:
Зачем вам самому увольняться? Попробуйте быть упрямым и стоять некоторое время не на жизнь, а на смерть. Обычно первое время - это всегда Сталинград с тяжелыми боями. Если вы уйдёте сами, то вы останетесь не только при своих новообретенных комплексах, но и при вечно жгущем вопросе "А что если бы я не ушел?...". И вот я не знаю, что из этого хуже.
Если же вас уволят за профнепригодность, а вы при этом проанализируете пункты, что я описал выше, разберетесь с виновником проблемы, то у вас будет полная определённость в дальнейших действиях и выборе профессии.
P.S. Я тут подумал... Вам 35 лет, и может быть люди, которые могут быть моложе вас просто стесняются вас учить так же, как учат молодёжь? Или не стесняются, а просто на автомате, подсознательно, выдают вам советы в таком же кратком виде, как другим программистам своего уровня? Тут уж ваша задача "влиться в коллектив" и постоянно напоминать о своём небольшом опыте
Помню свою первую рабочую неделю. До этого за плечами только институт и 3 месячный курс по 1с. Устроилась в ГРЭС куда брали программеров способных понять чужой код ещё на динозавровских платформах и обслуживать мамонтовские датчики. На словах мой куратор все объяснил. Поняла? И ушёл в отпуск на месяц. Ночные звонки. Пару рухнувших систем. Бессонные ночи. Но выплыла. Работаю до сих пор. Но помогло по большей части упорство. Если нет желание решить задачу через не могу и не умею, дальше будет только сложнее
Да. Опять путаница понятий. Программист и кодер - это не одно и то же. Кодеру никогда не дадут задачу разрабатывать алгоритмы. Программист легко поймет как все работат после прочтения кода. Кодер зашорен на языке программирования, а программисту всеравно на чём написана программа. На мудрено, что автор в депрессии - он ведь не программист. Программист, в отличии от кодера, имеет солидный теоретический багаж и знает как им распорядиться. Кстати, 100% уверен, что автор Кнута не читал.
Помню, как будто это было вчера, как писал год назад диплом, делал сайт интернет-магазина. При том, что я по сути не знал нифига ни один язык. Специальность у нас была больше связана с проектированием баз данных, но спроектировать базу данных это слишком просто, поэтому надо сделать что-то практичное.
Методом тыка наткнулся на учебник "Django 2 в примерах". И как же у меня горело, т.к. код оттуда не всегда работал как надо, потому что сам я писал в 3 версии. Столько нервов потратил, ненавидеть стал просто каждый файл.
Каким-то неизвестным образом я осилил эту фигню и получилось неказисто, но сносно. По сравнению с другими из группы по функционалу очень даже ок.
Хотя теперь понимаю, как же убого сайт выглядел на вид, хотя мне нравилось подбирать гамму. Только бесило то, что при вёрстке тоже все ехало туда сюда.
Нравилось находить в интернете новые фишки мелкие по типу кнопки прокрутки вверх, пагинации, слайдеров, разворачивающихся списков, выпадающего меню. И нравилось как они начинали работать на моем сайте.
Нравилось постепенно редактировать уже давно созданную схему БД, дополнять, изменять ее, заполнять данными.
Но как же бесило, когда снова какая-то ошибка ломала что-то. Из-за этого я вообще не знаю кто я и что умею лучше. Потому что нравится мне что-то ровно до тех пор, пока не начинаются затупы, тогда все бросаю на несколько дней.
Отдельно от этого стояла моя курсовая, по которой я ещё только делал саму БД в MySQL и писал для нее запросы. Опять же, все круто, все классно. Пока препод не давала заковыристые запросы, где надо было вложить один select во второй. Я понимал, что запрос должен быть вложенным, но не понимал, почему он не работал, в итоге забросил это дело на месяц, пока не придумал обходной путь.
Препод сказала, что не такого ленивого способа ожидала от меня, но сойдёт и такой (было что-то с выборкой определенных заказов, с расчетом их сумм и сортировкой по количеству наименований в заказе). Найти количество наименований и суммы было несложно. Сложно было заставить показаться только нужные записи. И я тупо упорядочил их по признаку, потом обрезал результат с помощью limit.
Единственное исключение, когда я вернулся в эту фигню по своей воле, это то, что недавно писал диплом для друга, тоже сайт, уже на основе своего. Менял и дополнял фишками, экспериментировал с дизайном, уже больше стало нравиться, но профессионалы бы меня все равно утопили бы за грязный подход к использованию css в разных местах, не всегда ясный нейминг и т.д.
Что-то мне подсказывает, что мне на собеседованиях по специальности рады ой как не будут. Потому что надо ведь, чтобы был готов сдохнуть, но решить. Я скорее сдох бы, лишь бы не возвращаться к чему-то.
Энтерпрайз это ад адовый. Незнаю я как то нашел свою нишу на средних и небольших проектах и норм себя чувствую тут. Помнится было что то такое когда в штатах работал в стартапе. Типо фреймворк для мобильной разработки был написан индусами свой под разные платформы и надо было в нем копаться модули под него писать. Это еще до react native было вернее писать они его начали когда оный еще не вышел. На самом деле копание в кишках занятие не сильно творческое, я вот восхищаюсь иногда алгоритмами придуманные математиками которые использовал в своих проектах. Вот это реально свет, столпы. Как например Дийкстра полвека назад придумал то что сейчас используется для навигации когда еще компутеров не было. Вообщем мой посыл в том что знание - это свет а 1с и прочее legacy это тьма и тут уже каждый для себя выбирает с чем ему работать)
Очень художественно и проникновенно! Вот только по моим понятиям тот, кто просто пишет код, это кодер. А программист умеет также кое-что ещё. А именно, декомпозировать задачу, встраивать новое, своё в легаси код, писать детальную постановку, ... И получается, что кодирование как таковое занимает не более 50% всего времени.
Писать код можно любую обезьяну научить, написание кода для программиста это примерно то же самое как для юриста, например, умение печатать или читать)
Но не эти навыки делают юриста юристом, а программиста программистом)
И даже чтение чужого кода и понимание не самая большая проблема. Часто в огромном сложном проекте вообще непонятно где искать даже тот код который нужно читать))
В принципе в реальности все примерно так и есть как написано в тексте) но мне, например, старшие коллеги помогают в таких вещах. Но у нас там своя специфика проекта, если сложности, которые вообще к программированию не имеют отношения)
Эхх помню свою программистскую молодость.
Дали нам исходники, чтото около 10 мб голого текста написанного на си под ось о которой никто никогда не слышал. И сказали вот там есть проблемы. Вот такие. Надо решить.
Красота... код на си даже не си++ писан в 80е... немцами, комментарии на немецком, сокращения имен от немецкого...
И никаких тебе дебагеров... да вообще скомпилировать и чтото проверить можно было только у заказчика на том самом монстре для которого все и писано было.
А когда доходило до проверки то запускаешь сборку и идешь курить. Потом в туалет, потом поболтать потом на обед потом еще покурить... и еще... о сборка окончена. Даже без ошибок (нечасто такое бывало)! Ну выдохнули! пробуем!
Нет. Это не то... ну чтож, откатываемся и по домам. Будем искать дальше...
После пары лет работы на этом проекте я не выдержал и сбежал из разработки. Так что автора я понимаю, но как то он быстро сдался.
P.S. проблемы мы таки тогда пофиксили.
P.P.S. А сейчас я хочу вернутся назад в разработку.
Пока читал, успел испугаться, что все, мне кранты в айти (ибо я только начал, а тут такое)
История про паравозик, который не смог
Да... Как же много накомментировали...
Вот именно по этой причине и были когда-то две очень разные специальности. Одна - программист. Ей учили в техникумах (читай ПТУ). Дело программиста писать код. На входе четко поставленная задача - на выходе ее реализация. 8 классов советской школы (ну хорошо, еще 2 в техникумах так или иначе тоже присутствовали) и пары лет относительно тематического обучения было достаточно. Научиться писать (и читать) код - дело не сильно хитрое. Более того - оно в целом мало зависит от языка программирования (если не брать исключения типа Prolog, но даже он при близком рассмотрении оказывается не таким уж и исключением).
Вторая специальность - это инженер-математик. Его дело находить решение проблемы. И вот этих готовили уже 5,5 лет, да после 10 лет школы (вариант 8 лет школы и 4 лет техникума). Совсем другой уровень. Умение ориентироваться в той самой темноте. Решать задачи по неполным данным.
Увы, сегодня программист - это кто угодно. От эникейщика в магазине, занятого обслуживанием кассовых аппаратов (по сути компьютеров с не самым прямым кодом) до разработчика программного обеспечения (что бы это не значило). Сесть за руль может почти каждый (если нет медицинских противопоказаний), работать водителем по найму - сильно меньше, побеждать в ралли - еще меньше, а добраться до королевских гонок F1 - вообще единицы. Так же и с IT. Начать можно очень легко. Главное не кусать больше, чем сможешь проглотить. Подавиться очень легко.
Я застал только когда в ПТУ учили на «операторов ЭВМ», а на «инженеров минус математиков» учили в институтах 5 лет на специальности 0647.
а потом советский союз закончился, а вместе с ним и ПТУ с техникумами…
В 1998-ом я заканчивал как 2201 - ЭВМ, системы, комплексы и сети. Но поступал еще "на программиста". Соответственно с 1994-ом точно выпускались с дипломом программиста. А дальше за давностью лет могу врать. Вроде до 1996-ого было так. В любом случае в не успел получить в дипломе специальность "программист", но она точно была.
Ну и вот честно не помню ни одного с такой специальностью.
В "Культурной столице" тоже шла активная дележка на "лицеи" и "колледжи". Но конкретно мой оставался техникумом минимум до 1998 года. Санкт-Петербургский радиотехнический техникум. Боюсь, правда, что тех кто заканчивал до меня (особенно тех, которые "вычислители") здесь уже почитать не получится. Из нашего-то курса по специальности работают трое, при чем один на фрилансе. У меня, к сожалению, нет знакомых чтобы уточнить код и название специальности. Век ее судя по всему был не долог. Но в целом задумка вполне правильная. Надо все же различать "кодера" и "разработчика". Оба нужны. Но уж очень разные задачи они решают...
Я закончил техникум в 2011м. Специальность "Программирование для электронно-вычислительной техники и автоматизированных систем". Однако, курс который был на год позже нас заканчивал уже "колледж".
Вот именно по этой причине это и разные профессии. Совершенно. Дело математика объяснить кодеру замысел и алгоритмы, дело кодера их красиво и безошибочно реализовать.
Каждый на своем месте должен делать свое дело (с)
А уж кто из них более для матери-истории важен - дело следующее.
Другими словами как быть с областями, где алгоритмы УЖЕ разработаны и той самой темноты не наблюдается? По моему все достаточно очевидно. В идеале тут не нужен ни один ни другой. Тот самый случай, когда "все уже написано за нас".
Другое дело, что оценка "огромное количество областей" очень уж лукавая. При том, что разработчик всегда "ходит по кругу решая из раза в раз одни и те же задачи", все же они каждый следующий раз решаются на новом уровне. Именно это и называется "инновация" - сделать привычное более эффективно, точнее, быстрее.
Впрочем вы ведь не об это спрашивали. Полагаю, что ответ на незаданный вопрос звучит так - кодеров, безусловно, надо сильно больше чем инженеров-математиков. И да - как и раньше. Чем выше разряд внутри специальности, тем лучше и дороже работник. Кодер второго разряда - это типовой джун. Могу реализовать алгоритм на языке. А кодер условного 7-ого разряда вполне может обойтись и без математика-программиста на ряде задач, не тянущих на НИР. Квалификация растет с опытом и желанием.
Хорошо. Хотите чтоб я поплакался такой же простынкой? Думаете у меня не получится? Я вас уверяю - у меня множество подобных историй. Как и у любого, кто занят разработкой.
Разработка чего бы то не было нового это вечное блуждание в темноте. Степень этой новизны и темноты бывает очень разная. От банальной стыковки между собой давно и успешно работающих решений (да, в результате получиться НОВОЕ решение, которого еще не было - иначе зачем эта работа), до всяких сложных задач типа инерциальной навигации или обработки данных. Понятно, что условный "кодер второго разряда" такие задачи решать и не должен. Разряд нужно повыше. А дальше от задачи. В определенных случаях нужен просто больший разряд кодера, в определенных помощь инженера-математика. А в определенных вообще изменения в ТЗ. Ибо сделанный костыль сейчас позволит получить решение задачи, но в последствии ударит гораздо сильнее (если не по тебе, то по твоим последователям). Понимать последнее и уметь отстаивать такую позицию - вообще отдельный навык.
С сопровождением все немного не так. Исправить существующее решение не то чтоб проще, но... Темноты там меньше. Хотя, это зависит от множества факторов. Потому оценка скорее субъективная. Опять же - раз изделие стоит и работает - значит его приняли. А раз его приняли значит заявленное оно выполняет... Потому в целом и согласен - весьма субъективная оценка. Опять же, не всякую задачу по сопровождению условный "кодер второго разряда" способен решить (как минимум в разумные сроки). Но тут помощь инженера-математика обычно не требуется (опять же - обычно не синоним никогда).
Я не понимаю выдвигаемых мне претензий. Потому и не понимаю что на них отвечать. Может переформулируете как-то по другому?
Давайте сразу - у меня с международными компаниями как-то не как-то. Только результаты их работ наблюдаю (Sony, Qualcom, Mediatek и рад других). Потому как там устроено - не знаю и не готов обсуждать. Но код, который они предоставляют на условиях NDA - это что-то страшное. По ощущениям его писал тот самый условный "кодер второго разряда". Т.е. оно работает (как-то) и работоспособность железок показывает (тоже как-то) но видя этот код можно сходу придумать десяток DDOS и пару-тройку RCE. Т.е. напрямую в проект брать нельзя категорически. Во всяком случае ответственный разработчик не возьмет. Но посмотрим на код у того же Samsung'а или других производителей бытовой электроники, который выложен был по причине GPL. Я очень часто там вижу именно тот, некогда NDA'шный код со всеми его радостями. Однако на этом по "международным компаниям" у меня на этом реально все.
Чисто IT'шное "Junior->...->Staff/Principal/Architect/etc" по сути и есть тот самый разряд из совка. Вы сами посмотрите - ровненько выходит. От 2-ого до 6-ого. Так что цифра это, или слово - разница не велика. И да - 3-ий и 4-ый разряд (Middle и Senior) самые популярные. Потому как отличный баланс между трудозатратами на освоение, зарплатой, востребованностью. И в любой профессии мало кто задерживается на условном 2-ом разряде. Ничто не ново в этом мире.
По Boeing'у "все не так однозначно" (с). Вопрос о том, как у такой махины организовался единственный датчик (да еще и принципиально не ломающийся, во всяком случае с точки зрения ПО) - это очень хороший вопрос. Только вот, насколько я помню, не вина это алгоритмистов. Скорее вечное желание сэкономить на сертификации. Впрочем, свечку не держал - исключительно по тому что писалось на Хабре...
По делению в целом... Из самых известных творений алгоритмистов можно сходу назвать FFT и QuickSort. А сколько чуть менее известных? А сколько специфичных для проектов? По моему все вполне нормально без относительно места. Есть фундаментальная наука, есть инженер-математик, и есть программист. Между ними вполне очевидная связь. Понятно, что ряд "фундаментальных" идей будут долго дожидаться своего часа (и не факт что дождутся), часть задач может сделать программист не напрягая вышестоящие уровни (ну или нижестоящие - вопрос выбора точки отчета и не более того). В итоге инженер-математик самая не востребованная специальность. Понятно, что в ряде проектов она просто необходима, в ряде просто лишняя. Но разве она от этого становится менее важной и не нужной?
По претензиям - бог с ним. Просто обычно -1 под комментарием - это мимо проходили или орфография не понравилась. А меньше - уже есть претензии по существу. Проехали.
Да, да, и еще раз да. Embedded - это мои ад. Правда, за много лет я в нем чувствую себя вполне комфортно. Видимо, именно это и объясняет мой несколько специфичный взгляд на программирование в целом.
По коду у нас... Да, в принципе, все что написано вами правда. Вернее как - не вся правда, а только ее часть. Другая сторона медали состоит в том, что в современном мире упаковка ценится дороже содержания. Полагаю в том же Google идут крайне ожесточенные споры по поводу того как должны выглядеть уведомления, переключаться экраны, и все такое прочее. Но железо должно "просто работать". При этом факт того, что оно "просто работает" - это само собой. А любой сбой - это полнейший криминал. И криминал этот стоит серьезных нервов (а то и денег).
То же с автомобилями. Можно до позеленения обсуждать оптику, обводы корпуса, приборную панель с мафоном. А ЭБУ? А оно должно "просто работать". Что у нас еще? Стиральные машины? Кофеварки? Кухонные комбайны? Синтезаторы? С точки зрения любого современного заказчика главный вопрос - это вопрос UI. А базовый функционал "должен просто работать". Разве за это надо платить? Тем более большие деньги? Есть электронщики. Они за "железо". За что им платят - понятно. Есть программеры и дизайнеры. С ними тоже понятно. А кто такие ембеддеры? Микросхему перепаять они не могут, неожиданно всплывший баг в бизнес-логике починить тоже. Сидят за своим компом, делают вид что работают и обижаются на то что платят мало. А за что платить-то?
По итогу перекос в сторону условного фронтэнда и приводит к тому, что бакендом (а уж подавно low-level и тем более embedded) занимаются те самые Electrical Enginear. А у них свои заботы. Электроны пасти и дрессировать - это тоже не самая простая работа. Полагаю ровно это и является основной причиной. Квалифицированные сотрудники не хотят идти в узкий сектор. Нет той самой "IT'шной свободы" и возможности уйти на другое место "по щелчку пальцев". У меня в организации аж два ембеддера (разной квалификации) и около 50 прикладников. И даже не смотря на это подход "оно просто должно работать" живет и процветает. В итоге из двух держусь только я. Напарники как правило уходят. В основном в прикладное или веб.
Что до DevOps и прочего, то все возможно. Беда в том, что с учетом всего вышеназванного оно не невозможно. Оно просто бессмысленно.
Собственно и "мы тут делом заняты" ровно оттуда же. Любой, даже самый серьезный косяк одного из множества прикладников закончится крахом и перезапуском (сохраняйтесь чаще!). А любой косяк схемотехника или ембедера грозит утечкой магического дыма (на котором, как известно, все и работает). Помножаем на диспропорцию зарплат и получаем что? Правильно - или джунов (много, но не на долго) или фанатов (редко, и очень сложно переманиваемых - ибо страшно бросить то, что годами оттачивал и браться за новое, понимая всю степень ответственности) или ленивых ежей, с которыми пока не пнешь - не полетит (довольно частый вариант).
Вообще тема сильно далеко ушла. Не уверен что хочу сюда углубляться. Тут уж больно у каждого свой опыт. Единственный и неповторимый.
Так вот он какой "кодер", эталонный code monkey, пишет код где показали, много и активно, главное показать. Программист это не тот кто пишет код, программист это тот кто решает проблему (ну или задачу, смотря как смотреть). Если ему для решения проблемы нужно написать код - он пишет код. Если нужно разобраться в чужом коде - он разбирается. Если нужно выяснить где проблема - он это делает. Если проблему решать не стоит - он обьясняет это тому кому очень хочется ее решить. Основная задача программиста не писать код, а думать. Основной инструмент не руки и клавиатура а мозги. Программист это исследователь, первопроходец, да с рюкзаком знаний, подходов, паттернов, чужого кода и инструментов за спиной, но он всегда делает что-то новое, даже если это новое очень похоже на старое. И как исследователя его в основном беспокоит вопрос как это сделать, правильно, удобно, "хорошо", а не "куда писать нужный код". Результат работы программиста это функциональность, сервис, программа, решенная проблема, улучшение техническое или функциональное, а не код. Код это инструмент, способ, не более. Говорить что задача программиста это код, а для остального есть другие люди абсолютно эквивалентно тому чтобы сказать что задача писателя это буковки, слова и предложения, а сюжет, вселенная, персонажи, и книга в целом как интересное и возможно полезное чтиво - это задача редакторов и прочих, а писателю надо четко сказать в каком абзаце о чем написать.
Кстати "продажник" профессия тоже инициативная и творческая. Так что такой подход "скажите где копать а то я не понимаю, теряюсь и впадаю в депрессию от этого", хороший "продажник" наработать бы не смог за свои 10-15 лет работы. Смог бы только плохой продажник, ну знаете такие, сидят на телефоне и грустно по списку обзванивают зачитанным текстом год за годом. Такому бы кстати профессия тестировщика подошла, высот бы не достиг, даже до мидла не факт, там все же тоже нужна инициатива и исследовательский подход, но вот в постоянной регрессии по готовым тест кейсам, год за готом одно и то же, отличный бы работник был. Ну или менять мировоззрение и мышление.
Да, я в курсе что это художественный текст и типаж скорее всего сборный а то и выдуманный почти с нуля.
мне конечно сложно судить как нынешнее мышление устроено… но для меня это выглядит как возможность блеснуть знаниями и переделать всё нафиг 'так как надо' (как мне кажется) и вписать себе это в резюме в заслуги
которые сказали: смело бросай свою старую, нелюбимую работу, и идина новую нелюбимую :)))))
Задача примерно звучала, как «тут где-то проблема, надо найти и устранить»Это ещё по-божески. Чаще «есть проблема чёрт знает где, надо найти и устранить». Это вы ещё промышленной автоматикой не занимались. Там проблема может быть не только в софте, но и в железе. Искать её надо не с мышкой, а с мультиметром. Если не исправить прямо сейчас — процесс остановится и убытков будет — я даже знать не хочу, сколько. А условия работы… На объекте бывало от -50°С до +50°С.
И код чужой плохо понимаю.Та же самая автоматика — она больше про устранение проблем, а не написание. Поскольку у меня хорошо получается проблемы находить, меня активно этим грузили, пока я не возопил: доколе?! Идите к чёрту со своими багами, у меня уже депрессия от них. Из одного говна тут же в другое… И ответ: а кто ещё справится, если не ты?..
Блин, а я откуда должен уметь его понимать-то?! Я нигде не учился понимать код!
Но дух перевести дали.
А потом оказывается, что проблему устранять не надо, т.к. она вызывает десять более серьезных, и это уже пытались делать раза 2, но люди менялись и знание утрачивалось, а писал все дед, который умер.
А потом оказывается, что проблему устранять не надо, т.к. она вызывает десять более серьезныхТак надо, на самом деле. Просто
уже пытались делать раза 2и не получилось, поэтому, бросили.
дед, который умербыл единственным, кто способен разобраться в проблемах такого уровня сложности, а сегодняшние кадры ему в подмётки не годятся…
дед, который умер был единственным, кто способен разобраться в проблемах такого уровня сложности
бывает, что этот «дед» так налапшекодил… (возможно, из-за привычки к недостатку памяти или других ресурсов. Ну вот лично я долго «осознавал» XML потому, что нас учили, что «отправлять лишнюю сотню байт в канал — преступление». а в начале 21 века толстые каналы, гигабайты оперативки и терабайты хранения стали обычным делом)
бывает, что этот «дед» так налапшекодилНе все деды одинаково полезны для здоровья :)
нас учили, что «отправлять лишнюю сотню байт в канал — преступление»А так и есть. Но, в современных реалиях, не уголовное, а административное :)
Я обычно прихожу домой, открываю свой любимый личный проект и только там начинаю писать код. Но даже через месяц он может стать мне чужим и это нормально, кодовая база будет всегда и с этим просто надо учиться работать
Ночь темнее всего перед рассветом.
Вы, товарищ, не программист. Вы кодер. Это этакая личинка программиста. Пишите код, читайте чужой код, дописывайте чужой код и, гладишь, через какое-то время станете таки программистом.
Один из признаков сеньора - он не говорит, что написанный до него код - плохой, но запросто может назвать свой - г*окодом.
Не из вежливости, но сеньор как человек культуры умеет разбираться в сортах:
Писал джун (этим все сказано)
Переменные одной буквой и вообще ничего не понятно
Все сделали через <<название крутого и модного паттерна который тут нафиг не нужен>>
и т.д.
В то время как свой код либо написан хорошо, либо неоч. Да и снизить ожидания от кода - полезно для его восприятия третьими лицами.
Начинающие программисты боятся темноты