В этой книге одна из основных идей: нужно работать над каждый день. Т.е. обычно мышление у человека устроено на измерение достижений. Когда всех успешных и умных программистов отличает как раз другая черта — они не стремятся к добраться к максимуму, они стремятся к увеличению первой производной получения знаний. Т.е. не снижать темп и работать каждый день.
Тут в статье говорится про разочарование. Разочарование в начале — это только цветочки. Настоящие разочарования начнутся через лет 5 работы, когда придет осознание, что НИКОГДА всё не изучишь. И надо привыкнуть постоянно учиться, чтобы не отставать в развитие.
Так что, гуманитарии, подумайте еще раз и не изучайте языки программирования. Не демпингуйте )))
Хотя, ничего сложного нет в программировании. Ничего сверхинтеллектуального. Программисты сами себе завысили оценку. Есть и намного посложнее науки ))
Сложность в программировании — это большой объем знаний. Который еще и быстро устаревает и появляется что-то новое.
Самого заучивать «выворачивает». Но с другой стороны, быстро забывается материал, если его не применять постоянно. А некоторые вещи просто надо наизусть знать.
А читаю первый раз книгу с интересом, медленно, всё пробую, придумываю бывает и свои варианты, если что-то не совсем понятно.
Сразу после прочтения в течении недели два-три раза перечитываю. Просто пробегаю глазами. Уже читать не надо. Просто чтобы каждая страница снова «зажглась» в памяти. До тех пор, пока не буду уверен, что помню все нюансы.
Некоторые книги, некоторые знания настолько нужны и тем временем объемны, что нужно заучивать. Правда, не сразу, не во время первого прочтения, а то никогда не закончите
MVC — более общее понятие, а, судя по описанию, MOVE — это один из вариантов.
И даже не вижу ничего сверх-хорошего. Вью напрямую слушает модель. Это ладно. Операции разделены с данными — не ощущается подвох? Всё время от этого уходили, ООП, функциональные языки. А теперь опять назад.
В MVC контроллер, как правило, что-то императивное: то есть шаг за шагом что-то «делающее». А в MOVE взаимодействие описывается декларативным образом
Хотелось бы пример. Это каким образом декларативно? Операции почему-то отделены от данных. Это имело бы смысл, если бы операции не зависели от данных, а были темплейтами (женериками) и т.д. Как-то тяжело представить, кроме работы с контейнерами, которые реализованы. А вот для бизнес-логики, не представляю. Чтобы операцию авторизации применили не только к юзеру, а к заказу, например.
Либо операции так же пишутся методами — императивно, либо нужно создавать свой язык поверх языка. Что не есть хорошо. Я знаю таких любителей, которые в гонке за гибкостью, не видят цели и выгоды. И в конечном счете делают монстра, который крайне ненадежный, не типизированный и который настроить дороже, чем если бы просто править код при изменении требований.
Во первых могут заставить. Например, для начала в городах. Все таки количество смертей в авариях огромное. Плюс пробки. Они только из-за человеческого фактора появляются. Очень подозреваю, что изначально автопилоты будут уметь общаться с друг с другом и согласовывать движение.
На счет мнения миллионов — у них нет своего мнения. За два года кардинально можно поменять. Все мнение навязаны — это всего лишь мода. Автомобили в большинстве случаев — не средство передвижения, а средство «повышения статуса». Метро эффективнее намного иногда. Но владельцы авто будут лучше два часа в пробке стоять, чем «стоять в метро с нищебродами».
Стоит точно так же раскрутить моду на автоматические автомобили. Ценой например. Что испытывает думающий об искусстве своего вождения водитель? Чувство собственной важности. Стоит другим перестать ценить его «искусство», как мнение у него неизвестно для него самого каким образом поменяется.
На счет старых автомобилей — скорее всего выход найти можно. Переоборудование. Для автоматизации вождения нужны камеры, компьютер, средства связи и как-то воздействовать на механизмы управления автомобилем.
Думаю не так. Когда начнется бум на такие автомобили (наверное скоро), пилотные автомобили начнут запрещать законодательно. Как только появится сравнительная статистика аварий.
Что угодно — вполне может двигаться со скоростью намного даже превышающей скорость света.
Пример: берем очень длинные две тонкие полоски чего-то гипотетического. Совмещаем ось вращения и раскручиваем в противоположных направлениях. И вот, точка пересечения прекрасно перемещается больше цэ.
Там, вроде, масса и/или информация не может быстрее перемещаться.
Нужна и теория и практика. Я знаю пару человек, которые очень любят изучать всё. Функциональную парадигму вдоль и поперек. Десятки языков, теории. На каждом могут программировать.
И один из них мне жаловался, что он завидует профессионалам в программировании. Нет, он работает программистом, это не хобби. Но тем не менее, жалуется, что не может создать что-то сложное.
С другой стороны, вижу намного чаще и обратную ситуацию: говнокодеры. Это люди, которые пишут не думая. Тонны кода пишут, а багов столько — что лучше бы не писали. И проблема их не в том, что они плохо соображают. А в том, что они не знают, что код может быть лучше.
Думаю, тут проблема, которая в статье описана, немного не так моделируется. Скоростью возможно и можно слепить горшок. Но программирование немного сложнее. Предлагаю такую модель. Человек не может одновременно концентрироваться на многих объектах. Допустим, может только на 5. Таким образом ему надо доводить работу до автоматизма. Именно кодированием, т.е. писать и читать код, пока эти навыки не уйдут в подкорку. Далее, приступать к изучению новых знаний.
Когда будущий программист только начинает учиться, изучая циклы, ветвления, он не сможет понять, как писать автоматический тест. Пусть наработает начальные навыки программирования. И так все время. Придет время изучать ООП. Всё это надо делать по очереди и отрабатывая обязательно кодированием.
При изучении ООП и паттернов, учащийся обязательно попадает в ловушку: сам способ обучения предлагает сразу решения. Поэтому учащийся концентрируется на том, чтобы сразу для любой задачи найти «красивое решение». Это неизбежный этап. Сопоставление задачи с уже решенными кем-то примерами и паттернами. Это помогает систематизировать знания, помогает набить руку на паттернах.
Тут пришло время поизучать функциональное программирование. Взглянуть иначе на программирование, на паттерны и рефакторинг.
И также — ТДД. Вот как раз оно и заставляет отказываться от паттернов и набрасываться на код. Здесь человек уже настолько привык к языку программирования, что больше ему ничего не нужно. Не нужны паттерны, не нужны диаграммы.
Как-то когда я был давно совсем маленьким, гладил рубашку. Никак не мог это сделать, расправлял ее, но не мог, где-то сминалась. Отец сказал: цель — чтобы утюг помещался и было еще немного места. Тебе не надо идеально расправлять. И тогда у меня начало получаться.
Необычный, конечно, пример. Но из жизни и близкий.
Вам не надо код представлять весь. Это нарушение инкапсуляции. Надо научиться работать с кодом на ограниченном участке. Видеть, что в нем не так, даже если вы всего не знаете о структуре. И это повышает и производительность и качество. Потому как качество кода в целом прямо зависит от качества его частей.
Так же код ничего не подсказывает. Код/тесты это просто текст. Все происходит в голове программиста, а вы его легко и незатейливо из процесса исключаете. Это смешно. В современном мире все и всегда зависит от человека, программирование не исключение.
Вам может и ничего не подсказывает ))
Код, не просто текст. Он написан по правилам. Как минимум, языка программирования. И не всё зависит о человека, если уж…
Потом, чем более точные науки, тем менее субъективны. Основная черта, отличающая их от психологий, стихосложения и живописи — это упор на объективность. Это значит, что человек делает минимум предположений на счет реального мира и старается их исключить вообще. Относиться без предубеждений. «Истину» принимать, такую какая бы она не оказалась, а не руководствоваться выбором, что нравится, а что нет. Логично?
Теперь о том, что зависит от человека. Человек решает, допустим, задачу по физике. Так, оказывается, он действует по каким-то строгим правилам. И приходит к решению задачи. И правильных решений — одно или совсем немного. Задо неправильных — бесконечность. Вот эта бесконечность — это и есть «творчество». Физик не скажет: я захотел выбрать такое решение, потому что так хочу, я имею право, я ж креативный. Почему вы думаете, что в программировании иначе?
В программировании тоже есть правила. Например, не использовать магических чисел. Человек видит такой код, и код ему подсказывает, что он плохой, это надо «полечить». Второй случай: человек видит, что куски кода повторяются. Просто видит, что такие похожие конструкции видел несколько раз. Это он, напоминаю, на код смотрит. А значит, применяя это правило — код ему подсказывает, надо посмотреть в эту сторону, возможно лажа. Третий случай: человек видит, что данные дублируются. Понимает, что возможна рассинхронизация, значит где-то лажа. Четвертый случай. Человек видит, что глубина наследования больше двух-трех. Возможно лажа. Анализирует код на предмет упрощения.
Правила есть. И написаны по разным книгам. Кто-то из авторов больше на одни правила обращает внимание, кто-то на другие. Потом, правила еще от языка зависят.
Человек пишет тест на свое усмотрение, «на глаз», потом по нему, опять-таки на свое усмотрение, пишет код. И это все ок. А когда он начнает этот код мержить, на свое усмотрение же, это резко становится проблемой. Это несколько нелогично, не находите?
Логично. Человек тест пишет не на глаз. Не совсем на глаз. По крайней мере очень старается, чтобы этого глаза было как можно меньше. Он анализирует требования и тест пишет либо по ним, либо анализирует наиболее простое решение требования и пишет тест на одну из частей этой реализации. А код, так вообще старается не на глаз писать. Тесты уже мешают код писать «на глаз».
Если было бы хоть сто веток, но при любом изменении в какой-то из веток, это изменение появлялось во всех остальных, то у нас по сути одна ветка.
Вот здесь подобная задача. Допустим, хотите оставлять код, который выкатили, на случай быстрой починки багов на ходу и не внесения нового, недоработанного функционала. Если с этой веткой не работают вообще, то проблем нет: когда закончится спринт, рабочая ветка просто заменит «стабильную». Если же в ней идут мелкие исправления, то сразу же, с выкатом на продакт исправлений, эти исправления мержатся в рабочую ветку.
Т.е. в рабочей ветке и разбираются со всем грузом требований и тестов. А не дожидаются, пока ветки разойдутся далеко, а потом внезапно получается сложный мерж в «стабильную» ветку, которая сразу же стает нестабильной.
Так можно.
Это общий принцип: лучше мелкими шагами, более короткими спринтами, с частыми сливаниями кода работать. Как только ветки разошлись, они назад чудесным образом не сходятся. И со временем цена мержа будет только увеличиваться.
Код почти сам себя пишет. Можно так сказать. Приблизительно
Программирование относится к точным наукам. Не гуманитарным. И творчества там быть не должно, по хорошему. Чем более профессиональный человек, тем больше у него строгих выработанных правил, которым он следует. Жаль, что эти правила не описаны четко где-то в конкретном месте. По книгам разбросаны. И по головам, с опытом.
Программирование — это перевод требований на язык программирования. И есть определенные правила, как к двигаться к цели. Код сам подсказывает, что в нем не так. Тест, рефакторинг, хотя и делает человек, но делает это вполне механически. Как водитель. Знает куда едет и знает, что надо в какой последовательности нажимать. Был бы автомобиль умнее, сам бы так ездил.
По сути, когда человек пишет юнит тест, он закрепляет требование, которое хочет от кода. Потом пишет код. Самым простым образом. Такие несложные правила позволяют эволюционно развиваться проекту, включаться другим программистам, и вносить какой-то вклад, быстро понимая, куда движется проект.
Тесты и код в одной ветке — взаимосвязанны. Когда мержат две ветки, пусть с тестами, уже тесты не дают гарантии качества, потому что код «сшивают на глаз» и то же самое делают с тестами. От теста нет толку, если его нет. Или если его удалят. Или если его переделают чтобы он проходил. При мерже так и происходит, потому что тесты из двух веток, так же как и код, могут пересекаться. Поэтому, то, что получится, зависит от того, кто мержит. И усугубляется это тем, что это никогда не бывает человек, который полностью в курсе происходящего в двух ветках. Хорошо, если это разработчик хотя бы одной из веток.
В общем, это дело намного рискованнее, чем написание кода и ведение одной ветки. Мерж веток подобен рефакторингу, но без покрытия тестов. Поэтому лучше работать в одной ветке. Все будут синхронизировать тесты, будут в курсе происходящего.
ТДД будет сломано если мерж делать тяп-ляп. Мержи — это не халява от vcs, мозги надо держать включенными.
Риски есть всегда. Чтоб небыло неожиданных багов тестировать надо перед выкатываением.
Конечно, баги можно оправдать тем, что дураки их пишут и мозги не включают. Напоминает ранние холивары, когда пишущие на ассемблере утверждали, что не менее производительные, чем на высокоуровневом языке пишущие люди и что количество багов и производительность зависят от мозгов.
Но всё не только от мозгов. Есть и технологии.
В ТДД человек пишет перед началом кодирования тест. Код покрывается тестами довольно неплохо. Эти все действия до полуавтомата доведены. Архитектура во многом строится сама, благодаря различным оценкам кода, а не планирования наперед.
Что происходит при мерже? Правильно — появился бог, который СУБЪЕКТИВНО решает, что нужно, а что нет. Включая тесты. Тесты перестают быть критерием оценки кода, потому что один человек соединяет написанное разными людьми и теперь только от его мозгов зависит, как слепится продукт.
А тестить перед выкатом, конечно, надо. Но при всем при этом, при частых сливаниях кода, проблем этих в РАЗЫ меньше. И потенциальных багов тоже. Чем большее расхождение по времени веток, тем сложнее их потом мержить и тем больше будут проявляться проблемы, описанные выше.
Да, категорично. И программировать — это зло. Любая строчка кода — зло )))
Это такой способ оценки, что лучше, а что хуже. Хороший по-моему критерий для оценки качества кода или качества работ.
Когда такого критерия нет, то часто нет вообще никаких критериев. Новички в программировании «любят» свою работу, романтизируют ее. Это отражается на качестве. Например, пытаются заранее принимать решения об архитектуре. Если им предоставить два варианта архитектур, без такого критерия они впадают в восхищение или поиск красоты.
А если понимать, что программирование — это увеличение энтропии, что это потенциальные баги, то сразу же возникают вопросы:
1. Кода больше? Зло
2. В коде учитывается больше, чем требуется на сейчас — зло.
3. Лишние ветки — зло.
Но и не кодить нельзя и без веток не всегда обходимся. Просто предлагаю рассматривать выбор решений не как выбор лучшего решения, а как выбор наименее вредного из всех. Тогда больше «лакмусовых бумажек», больше понимания, от чего нужно отказываться и куда двигаться. Когда человек выбирает лучшее из хороших, нет ни мотива развивать решение ни ощущения, что нужно делать для этого
Любые отдельные ветки — зло. Не только для задач рефакторинга.
Допустим, у вас есть две ветки, которые долго не мержились и велась параллельная разработка. При этом, допустим, всё делалось «по уму» — хорошее покрытие тестами и т.д.
Пришло время мержить. И всё «по уму» пошло коту под хвост. Сидит какой-то человек, разгребает кучу кода, субъективно решает, что важно и что правильно, включая тесты. Это громадный риск, появляется сильный человеческий фактор. ТДД уже здесь сломано.
Поэтому по возможности, нужно не плодить ветки. А если плодить, то на короткое время. Лучше одна ветка, но частые сливания кода.
Иногда это невозможно, конечно. Но я встречал людей, которые на ровном месте выдумывали проблемы, разрабатывая «очень умные» схемы управления проектами внутри одного большого проекта.
Умного в этом ничего нет. Как только мерж и выкат на продакт, так и полезли возрожденные баги, новые баги и хрен знает что.
я не рассказываю «вкратце о себе». Обо мне пусть другие книги пишут или фильмы снимают. Цель резюме — кратко перечислить знания и технологии, даже выбрасывая те, которыми не хочется заниматься, но сталкивался.
А также опыт. Т.е. какую реальную работу делал.
Кто-то еще рассказывает о психологических качествах? Наверное, это не программист.
Что значит «вкратце»? Если по одной строке — своя роль в проекте, одна — цель проекта. И при этом проекты самые маленькие по полгода, но уже на три страницы.
Спасибо. Не знаю, когда попробую. Задач таких и заказчиков тяжело найти.
1. График на работе я не определяю. Работаю с 9 до 18. И знаю по себе, что точный график лучше гибкого. Я всегда включаюсь в рабочий режим быстро и стабильно. Знаю знакомых, у которых гибкий график (не фриланс), так с ними и пива не возможно попить. Доползает на работу в 12.00 (спит долго), а потом сидит до 11 вечера, пытаясь отработать свое время и выполнить свои задачи. В результате и с семьей проблемы и с друзьями может годами не видеться.
Т.е. для себя я понимаю, что дисциплина в соблюдении рабочего времени важна, даже если бы я фрилансом занимался.
2. Очень за. Но в принципе можно и на работе принимать самому решения. Я, например, сделал несколько проектов на текущей работе сам. Т.е. один участвовал в проекте. Что дико повышало эффективность. Потом, у нас сейчас попытки наладить аджайл. У каждого есть некоторая степень свободы для принятия решений. Что тоже повышает эффективность.
3. Это да. Это меня бы привлекло. Если бы еще к этому добавить условие: наличие таких же интересных задач. Интересные задачи для меня первичнее любых условий. Не хочется тяготиться работой.
И наверное они все таки есть и в фрилансе, надо только искать хорошо.
1. Эффективность и сопровождаемость.
Сопровождаемость. И только сопровождаемость. Хорошо было бы, если бы программисты думали о термине «оптимизация», как не о кодировании, а о специальном процессе. Который состоит из шагов: замеры производительности и т.д. Без замеров производительности нет и оптимизации. Если нет замеров, любая оптимизация преждевременная.
Хотя бы исходя из того, что сопровождаемый и простой код легко изменять, а значит он поддается оптимизациям. Непростой нелегко изменять, а значит, будет поздно оптимизировать, когда заранее оптимизированный код в результате замеров покажет тормоза. Это как с одеялом — с большого можно потом сделать меньшее, но не наоборот.
Прямо здесь в примере написаны ужасы: разбухание кода. Разбухание чего? Если был бы код и мы бы уже на поздних этапах занялись как и положено оптимизацией и оказалось ВНЕЗАПНО что приложение ест много памяти, то мы бы, наверное, смотрели, что ее ест. Наиболее слабое звено. Код???? Да я физически не могу написать столько кода, даже если он в 5 раз при компиляции вырастет.
Если вырастет на несколько байт код класса — это не повод расстраиваться. Также как не повод мне расстраиваться, что возможно моя зарплата должна быть выше на 0.00001 копейку, но ее округляют в меньшую сторону.
Если что и ест память, то обычно это данные. Т.е. то, что может копироваться или тянуться из базы. Код не копируется. Код класса, напомню, в дотнете хранится в единственном экземпляре. Копироваться код может для женериков. Но и здесь сомнения, что это важно. Я не думаю, что на ходу буду создавать неорганиченное число типов и создавать жененики в цикле. Или даже не буду в цикле, скорее всего, бегать по метаданным, вытягивать все возможные типы и создавать женерики.
Так что если хотят написать эффективный код, то надо писать сопровождаемый. Если каким-то немыслимым способом окажется потом, что наш маленький класс ведет себя очень плохо, отъедая память, то потом ничего не стоит и заменить эти readonly.
2. Безопасность и эффективность
Безопасность. По тем же причинам.
3. Простота vsуниверсальность.
Простота. Согласен с приведенными аргументами. Да и вообще — программирование задачи должно идти в сторону от больших ограничений к меньшим. Это значит, от простого к сложному. И простота должна отвоевываться на каждом шаге.
4. Библиотеки и удобство использования.
Добавить нечего. Хорошо, что я не пишу библиотеки на продажу.
Бизнес для программистов. Как начать свое дело
В этой книге одна из основных идей: нужно работать над каждый день. Т.е. обычно мышление у человека устроено на измерение достижений. Когда всех успешных и умных программистов отличает как раз другая черта — они не стремятся к добраться к максимуму, они стремятся к увеличению первой производной получения знаний. Т.е. не снижать темп и работать каждый день.
Тут в статье говорится про разочарование. Разочарование в начале — это только цветочки. Настоящие разочарования начнутся через лет 5 работы, когда придет осознание, что НИКОГДА всё не изучишь. И надо привыкнуть постоянно учиться, чтобы не отставать в развитие.
Так что, гуманитарии, подумайте еще раз и не изучайте языки программирования. Не демпингуйте )))
Хотя, ничего сложного нет в программировании. Ничего сверхинтеллектуального. Программисты сами себе завысили оценку. Есть и намного посложнее науки ))
Сложность в программировании — это большой объем знаний. Который еще и быстро устаревает и появляется что-то новое.
Самого заучивать «выворачивает». Но с другой стороны, быстро забывается материал, если его не применять постоянно. А некоторые вещи просто надо наизусть знать.
А читаю первый раз книгу с интересом, медленно, всё пробую, придумываю бывает и свои варианты, если что-то не совсем понятно.
Сразу после прочтения в течении недели два-три раза перечитываю. Просто пробегаю глазами. Уже читать не надо. Просто чтобы каждая страница снова «зажглась» в памяти. До тех пор, пока не буду уверен, что помню все нюансы.
Некоторые книги, некоторые знания настолько нужны и тем временем объемны, что нужно заучивать. Правда, не сразу, не во время первого прочтения, а то никогда не закончите
И даже не вижу ничего сверх-хорошего. Вью напрямую слушает модель. Это ладно. Операции разделены с данными — не ощущается подвох? Всё время от этого уходили, ООП, функциональные языки. А теперь опять назад.
Хотелось бы пример. Это каким образом декларативно? Операции почему-то отделены от данных. Это имело бы смысл, если бы операции не зависели от данных, а были темплейтами (женериками) и т.д. Как-то тяжело представить, кроме работы с контейнерами, которые реализованы. А вот для бизнес-логики, не представляю. Чтобы операцию авторизации применили не только к юзеру, а к заказу, например.
Либо операции так же пишутся методами — императивно, либо нужно создавать свой язык поверх языка. Что не есть хорошо. Я знаю таких любителей, которые в гонке за гибкостью, не видят цели и выгоды. И в конечном счете делают монстра, который крайне ненадежный, не типизированный и который настроить дороже, чем если бы просто править код при изменении требований.
На счет мнения миллионов — у них нет своего мнения. За два года кардинально можно поменять. Все мнение навязаны — это всего лишь мода. Автомобили в большинстве случаев — не средство передвижения, а средство «повышения статуса». Метро эффективнее намного иногда. Но владельцы авто будут лучше два часа в пробке стоять, чем «стоять в метро с нищебродами».
Стоит точно так же раскрутить моду на автоматические автомобили. Ценой например. Что испытывает думающий об искусстве своего вождения водитель? Чувство собственной важности. Стоит другим перестать ценить его «искусство», как мнение у него неизвестно для него самого каким образом поменяется.
На счет старых автомобилей — скорее всего выход найти можно. Переоборудование. Для автоматизации вождения нужны камеры, компьютер, средства связи и как-то воздействовать на механизмы управления автомобилем.
Пример: берем очень длинные две тонкие полоски чего-то гипотетического. Совмещаем ось вращения и раскручиваем в противоположных направлениях. И вот, точка пересечения прекрасно перемещается больше цэ.
Там, вроде, масса и/или информация не может быстрее перемещаться.
И один из них мне жаловался, что он завидует профессионалам в программировании. Нет, он работает программистом, это не хобби. Но тем не менее, жалуется, что не может создать что-то сложное.
С другой стороны, вижу намного чаще и обратную ситуацию: говнокодеры. Это люди, которые пишут не думая. Тонны кода пишут, а багов столько — что лучше бы не писали. И проблема их не в том, что они плохо соображают. А в том, что они не знают, что код может быть лучше.
Думаю, тут проблема, которая в статье описана, немного не так моделируется. Скоростью возможно и можно слепить горшок. Но программирование немного сложнее. Предлагаю такую модель. Человек не может одновременно концентрироваться на многих объектах. Допустим, может только на 5. Таким образом ему надо доводить работу до автоматизма. Именно кодированием, т.е. писать и читать код, пока эти навыки не уйдут в подкорку. Далее, приступать к изучению новых знаний.
Когда будущий программист только начинает учиться, изучая циклы, ветвления, он не сможет понять, как писать автоматический тест. Пусть наработает начальные навыки программирования. И так все время. Придет время изучать ООП. Всё это надо делать по очереди и отрабатывая обязательно кодированием.
При изучении ООП и паттернов, учащийся обязательно попадает в ловушку: сам способ обучения предлагает сразу решения. Поэтому учащийся концентрируется на том, чтобы сразу для любой задачи найти «красивое решение». Это неизбежный этап. Сопоставление задачи с уже решенными кем-то примерами и паттернами. Это помогает систематизировать знания, помогает набить руку на паттернах.
Тут пришло время поизучать функциональное программирование. Взглянуть иначе на программирование, на паттерны и рефакторинг.
И также — ТДД. Вот как раз оно и заставляет отказываться от паттернов и набрасываться на код. Здесь человек уже настолько привык к языку программирования, что больше ему ничего не нужно. Не нужны паттерны, не нужны диаграммы.
Как-то когда я был давно совсем маленьким, гладил рубашку. Никак не мог это сделать, расправлял ее, но не мог, где-то сминалась. Отец сказал: цель — чтобы утюг помещался и было еще немного места. Тебе не надо идеально расправлять. И тогда у меня начало получаться.
Необычный, конечно, пример. Но из жизни и близкий.
Вам не надо код представлять весь. Это нарушение инкапсуляции. Надо научиться работать с кодом на ограниченном участке. Видеть, что в нем не так, даже если вы всего не знаете о структуре. И это повышает и производительность и качество. Потому как качество кода в целом прямо зависит от качества его частей.
Так, сумбурно описал то, к чему вы пришли.
Вам может и ничего не подсказывает ))
Код, не просто текст. Он написан по правилам. Как минимум, языка программирования. И не всё зависит о человека, если уж…
Потом, чем более точные науки, тем менее субъективны. Основная черта, отличающая их от психологий, стихосложения и живописи — это упор на объективность. Это значит, что человек делает минимум предположений на счет реального мира и старается их исключить вообще. Относиться без предубеждений. «Истину» принимать, такую какая бы она не оказалась, а не руководствоваться выбором, что нравится, а что нет. Логично?
Теперь о том, что зависит от человека. Человек решает, допустим, задачу по физике. Так, оказывается, он действует по каким-то строгим правилам. И приходит к решению задачи. И правильных решений — одно или совсем немного. Задо неправильных — бесконечность. Вот эта бесконечность — это и есть «творчество». Физик не скажет: я захотел выбрать такое решение, потому что так хочу, я имею право, я ж креативный. Почему вы думаете, что в программировании иначе?
В программировании тоже есть правила. Например, не использовать магических чисел. Человек видит такой код, и код ему подсказывает, что он плохой, это надо «полечить». Второй случай: человек видит, что куски кода повторяются. Просто видит, что такие похожие конструкции видел несколько раз. Это он, напоминаю, на код смотрит. А значит, применяя это правило — код ему подсказывает, надо посмотреть в эту сторону, возможно лажа. Третий случай: человек видит, что данные дублируются. Понимает, что возможна рассинхронизация, значит где-то лажа. Четвертый случай. Человек видит, что глубина наследования больше двух-трех. Возможно лажа. Анализирует код на предмет упрощения.
Правила есть. И написаны по разным книгам. Кто-то из авторов больше на одни правила обращает внимание, кто-то на другие. Потом, правила еще от языка зависят.
Логично. Человек тест пишет не на глаз. Не совсем на глаз. По крайней мере очень старается, чтобы этого глаза было как можно меньше. Он анализирует требования и тест пишет либо по ним, либо анализирует наиболее простое решение требования и пишет тест на одну из частей этой реализации. А код, так вообще старается не на глаз писать. Тесты уже мешают код писать «на глаз».
Вот здесь подобная задача. Допустим, хотите оставлять код, который выкатили, на случай быстрой починки багов на ходу и не внесения нового, недоработанного функционала. Если с этой веткой не работают вообще, то проблем нет: когда закончится спринт, рабочая ветка просто заменит «стабильную». Если же в ней идут мелкие исправления, то сразу же, с выкатом на продакт исправлений, эти исправления мержатся в рабочую ветку.
Т.е. в рабочей ветке и разбираются со всем грузом требований и тестов. А не дожидаются, пока ветки разойдутся далеко, а потом внезапно получается сложный мерж в «стабильную» ветку, которая сразу же стает нестабильной.
Так можно.
Это общий принцип: лучше мелкими шагами, более короткими спринтами, с частыми сливаниями кода работать. Как только ветки разошлись, они назад чудесным образом не сходятся. И со временем цена мержа будет только увеличиваться.
Программирование относится к точным наукам. Не гуманитарным. И творчества там быть не должно, по хорошему. Чем более профессиональный человек, тем больше у него строгих выработанных правил, которым он следует. Жаль, что эти правила не описаны четко где-то в конкретном месте. По книгам разбросаны. И по головам, с опытом.
Программирование — это перевод требований на язык программирования. И есть определенные правила, как к двигаться к цели. Код сам подсказывает, что в нем не так. Тест, рефакторинг, хотя и делает человек, но делает это вполне механически. Как водитель. Знает куда едет и знает, что надо в какой последовательности нажимать. Был бы автомобиль умнее, сам бы так ездил.
По сути, когда человек пишет юнит тест, он закрепляет требование, которое хочет от кода. Потом пишет код. Самым простым образом. Такие несложные правила позволяют эволюционно развиваться проекту, включаться другим программистам, и вносить какой-то вклад, быстро понимая, куда движется проект.
Тесты и код в одной ветке — взаимосвязанны. Когда мержат две ветки, пусть с тестами, уже тесты не дают гарантии качества, потому что код «сшивают на глаз» и то же самое делают с тестами. От теста нет толку, если его нет. Или если его удалят. Или если его переделают чтобы он проходил. При мерже так и происходит, потому что тесты из двух веток, так же как и код, могут пересекаться. Поэтому, то, что получится, зависит от того, кто мержит. И усугубляется это тем, что это никогда не бывает человек, который полностью в курсе происходящего в двух ветках. Хорошо, если это разработчик хотя бы одной из веток.
В общем, это дело намного рискованнее, чем написание кода и ведение одной ветки. Мерж веток подобен рефакторингу, но без покрытия тестов. Поэтому лучше работать в одной ветке. Все будут синхронизировать тесты, будут в курсе происходящего.
Конечно, баги можно оправдать тем, что дураки их пишут и мозги не включают. Напоминает ранние холивары, когда пишущие на ассемблере утверждали, что не менее производительные, чем на высокоуровневом языке пишущие люди и что количество багов и производительность зависят от мозгов.
Но всё не только от мозгов. Есть и технологии.
В ТДД человек пишет перед началом кодирования тест. Код покрывается тестами довольно неплохо. Эти все действия до полуавтомата доведены. Архитектура во многом строится сама, благодаря различным оценкам кода, а не планирования наперед.
Что происходит при мерже? Правильно — появился бог, который СУБЪЕКТИВНО решает, что нужно, а что нет. Включая тесты. Тесты перестают быть критерием оценки кода, потому что один человек соединяет написанное разными людьми и теперь только от его мозгов зависит, как слепится продукт.
А тестить перед выкатом, конечно, надо. Но при всем при этом, при частых сливаниях кода, проблем этих в РАЗЫ меньше. И потенциальных багов тоже. Чем большее расхождение по времени веток, тем сложнее их потом мержить и тем больше будут проявляться проблемы, описанные выше.
Это такой способ оценки, что лучше, а что хуже. Хороший по-моему критерий для оценки качества кода или качества работ.
Когда такого критерия нет, то часто нет вообще никаких критериев. Новички в программировании «любят» свою работу, романтизируют ее. Это отражается на качестве. Например, пытаются заранее принимать решения об архитектуре. Если им предоставить два варианта архитектур, без такого критерия они впадают в восхищение или поиск красоты.
А если понимать, что программирование — это увеличение энтропии, что это потенциальные баги, то сразу же возникают вопросы:
1. Кода больше? Зло
2. В коде учитывается больше, чем требуется на сейчас — зло.
3. Лишние ветки — зло.
Но и не кодить нельзя и без веток не всегда обходимся. Просто предлагаю рассматривать выбор решений не как выбор лучшего решения, а как выбор наименее вредного из всех. Тогда больше «лакмусовых бумажек», больше понимания, от чего нужно отказываться и куда двигаться. Когда человек выбирает лучшее из хороших, нет ни мотива развивать решение ни ощущения, что нужно делать для этого
Допустим, у вас есть две ветки, которые долго не мержились и велась параллельная разработка. При этом, допустим, всё делалось «по уму» — хорошее покрытие тестами и т.д.
Пришло время мержить. И всё «по уму» пошло коту под хвост. Сидит какой-то человек, разгребает кучу кода, субъективно решает, что важно и что правильно, включая тесты. Это громадный риск, появляется сильный человеческий фактор. ТДД уже здесь сломано.
Поэтому по возможности, нужно не плодить ветки. А если плодить, то на короткое время. Лучше одна ветка, но частые сливания кода.
Иногда это невозможно, конечно. Но я встречал людей, которые на ровном месте выдумывали проблемы, разрабатывая «очень умные» схемы управления проектами внутри одного большого проекта.
Умного в этом ничего нет. Как только мерж и выкат на продакт, так и полезли возрожденные баги, новые баги и хрен знает что.
А также опыт. Т.е. какую реальную работу делал.
Кто-то еще рассказывает о психологических качествах? Наверное, это не программист.
Год-два работы, это не 10.
1. График на работе я не определяю. Работаю с 9 до 18. И знаю по себе, что точный график лучше гибкого. Я всегда включаюсь в рабочий режим быстро и стабильно. Знаю знакомых, у которых гибкий график (не фриланс), так с ними и пива не возможно попить. Доползает на работу в 12.00 (спит долго), а потом сидит до 11 вечера, пытаясь отработать свое время и выполнить свои задачи. В результате и с семьей проблемы и с друзьями может годами не видеться.
Т.е. для себя я понимаю, что дисциплина в соблюдении рабочего времени важна, даже если бы я фрилансом занимался.
2. Очень за. Но в принципе можно и на работе принимать самому решения. Я, например, сделал несколько проектов на текущей работе сам. Т.е. один участвовал в проекте. Что дико повышало эффективность. Потом, у нас сейчас попытки наладить аджайл. У каждого есть некоторая степень свободы для принятия решений. Что тоже повышает эффективность.
3. Это да. Это меня бы привлекло. Если бы еще к этому добавить условие: наличие таких же интересных задач. Интересные задачи для меня первичнее любых условий. Не хочется тяготиться работой.
И наверное они все таки есть и в фрилансе, надо только искать хорошо.
Сопровождаемость. И только сопровождаемость. Хорошо было бы, если бы программисты думали о термине «оптимизация», как не о кодировании, а о специальном процессе. Который состоит из шагов: замеры производительности и т.д. Без замеров производительности нет и оптимизации. Если нет замеров, любая оптимизация преждевременная.
Хотя бы исходя из того, что сопровождаемый и простой код легко изменять, а значит он поддается оптимизациям. Непростой нелегко изменять, а значит, будет поздно оптимизировать, когда заранее оптимизированный код в результате замеров покажет тормоза. Это как с одеялом — с большого можно потом сделать меньшее, но не наоборот.
Прямо здесь в примере написаны ужасы: разбухание кода. Разбухание чего? Если был бы код и мы бы уже на поздних этапах занялись как и положено оптимизацией и оказалось ВНЕЗАПНО что приложение ест много памяти, то мы бы, наверное, смотрели, что ее ест. Наиболее слабое звено. Код???? Да я физически не могу написать столько кода, даже если он в 5 раз при компиляции вырастет.
Если вырастет на несколько байт код класса — это не повод расстраиваться. Также как не повод мне расстраиваться, что возможно моя зарплата должна быть выше на 0.00001 копейку, но ее округляют в меньшую сторону.
Если что и ест память, то обычно это данные. Т.е. то, что может копироваться или тянуться из базы. Код не копируется. Код класса, напомню, в дотнете хранится в единственном экземпляре. Копироваться код может для женериков. Но и здесь сомнения, что это важно. Я не думаю, что на ходу буду создавать неорганиченное число типов и создавать жененики в цикле. Или даже не буду в цикле, скорее всего, бегать по метаданным, вытягивать все возможные типы и создавать женерики.
Так что если хотят написать эффективный код, то надо писать сопровождаемый. Если каким-то немыслимым способом окажется потом, что наш маленький класс ведет себя очень плохо, отъедая память, то потом ничего не стоит и заменить эти readonly.
2. Безопасность и эффективность
Безопасность. По тем же причинам.
3. Простота vsуниверсальность.
Простота. Согласен с приведенными аргументами. Да и вообще — программирование задачи должно идти в сторону от больших ограничений к меньшим. Это значит, от простого к сложному. И простота должна отвоевываться на каждом шаге.
4. Библиотеки и удобство использования.
Добавить нечего. Хорошо, что я не пишу библиотеки на продажу.