50 ходов без взятия фигур в плане реализации это совсем несложно, поэтому для статьи не принципиально. Я сосредоточился на основных правилах. Если бы я в одной статье рассказал про все особые случаи, статья получилась бы огромной (она и так не самая маленькая).
По поводу нотации для записи ходов я сознательно выбрал более многословную запись, чтобы её легче было объяснить людям, которые вообще не знакомы с шахматными нотациями.
Про тесты интересная мысль, как и предыдущие. Спасибо, я принял к сведению! Возможно потом доработаю движок с учётом ваших предложений.
Возможно в статье это не совсем очевидно отражено, поэтому скажу ещё раз. Сначала мне просто захотелось поиграть в шахматы, а уже затем захотелось самому посмотреть, как можно реализовать простой движок. Если бы я изначально задавался целью написать полноценный движок, то да, я бы глубоко погружался в тему и начинал с изучения существующих аналогов.
Спасибо за ссылку, почитаю! Что касается рокировки, то даже не все именитые шахматисты соблюдали эти правила. То есть имеется некоторая вариативность в правилах.
Все ваши замечания справедливы, однако я перед собой и не ставил цели сразу написать полноценный движок.
1. Да, рокировка не описана, но можно сделать ещё одну реализацию интерфейса Turn, которая будет содержать всю необходимую информацию для рокировки (например, с какой ладьёй меняемся). В моём подходе все варианты рокировки должен возвращать движок, если рокировка возможна (король не двигался, ладья не двигалась, между ними нет других фигур и рокировка не поставит короля под мат).
2. В силу специфичности данного хода я даже не пытался его реализовать в первой итерации. Довольно легко избежать взятия на проходе, если знаешь про это правило. Однако это будет ещё одна реализация Turn.
3. Про мобильность интересное замечание. Приму к сведению.
4. Вы абсолютно правы, но я на это пошёл сознательно. Хотя бы потому что в основном все пишут про битовые поля, а других вариантов особо не предлагают. Хотелось продемонстрировать такую структуру данных, которая была бы максимально простой для понимания.
Судя по книге, ещё нет. Или Брукс его не применял. То есть потребность такая уже сформировалась и примерное понимание функциональности, но подходящего инструмента у них ещё не было внедрено.
Да, это просто переход на другой масштаб. Вместо увеличения кол-ва разработчиков в команде мы будем увеличивать кол-во команд в компании. Но ведь команды тоже между собой взаимодействуют.
Не у каждой команды есть возможность выделить человека на fulltime только лишь на документацию и onboarding. По поводу документации Брукс к тому же говорит, что её должен писать именно тот, кто пишет код — и это правильно.
Во всех подобных формулировках есть один нюанс. Каковы критерии определения этой квалификации? У меня одни критерии, у вас — другие. Нам может казаться, что мы определяем её одинаково, а на деле окажется по-разному.
Помимо указанных вами проблем, решаемых технически, всегда есть проблема координации большого количества людей. С возрастанием количества людей в коллективе число возможных коммуникаций между ними увеличивается в разы (вплоть до каждый с каждым). Какое совещание будет эффективнее, где будет 5 человек или 25?)
Суть в том, что даже хорошо отлаженный onboarding требует чьего-то внимания/ресурсов. Новичок не может сам по себе, «в вакууме», въезжать в проект. Ему всё равно потребуется помощь коллег. А уж когда дедлайн на носу, мобилизуются все доступные ресурсы команды.
VCS, bug tracking, wiki — это именно те инструменты, которые дал нам технический прогресс и они облегчают нашу жизнь. Назначение их при этом не меняется. В начале документацию распечатывали на бумаге и подшивали в архивы, затем Брукс предлагал как более современное решение использовать «микрофиши» (уменьшенные в 90 раз фотокопии документов на плёнке). Сейчас мы фиксируем документацию в wiki. Но назначение инструмента от этого не меняется — распространение знаний о системе.
Да, это практически неизбежно, потому что это жизненный цикл любого приложения. Относительно чистый код со временем переходит в legacy. Вопрос лишь в том, насколько быстро это происходит)
Я сознательно не стал включать выдержки из серии статей «серебряной пули нет», т.к. по сути это промежуточное подведение итогов каждого десятилетия, которое Брукс делает на основании своих же заметок. Мне хотелось прежде всего сравнить его мысли с текущим положением вещей.
По поводу нотации для записи ходов я сознательно выбрал более многословную запись, чтобы её легче было объяснить людям, которые вообще не знакомы с шахматными нотациями.
Про тесты интересная мысль, как и предыдущие. Спасибо, я принял к сведению! Возможно потом доработаю движок с учётом ваших предложений.
1. Да, рокировка не описана, но можно сделать ещё одну реализацию интерфейса Turn, которая будет содержать всю необходимую информацию для рокировки (например, с какой ладьёй меняемся). В моём подходе все варианты рокировки должен возвращать движок, если рокировка возможна (король не двигался, ладья не двигалась, между ними нет других фигур и рокировка не поставит короля под мат).
2. В силу специфичности данного хода я даже не пытался его реализовать в первой итерации. Довольно легко избежать взятия на проходе, если знаешь про это правило. Однако это будет ещё одна реализация Turn.
3. Про мобильность интересное замечание. Приму к сведению.
4. Вы абсолютно правы, но я на это пошёл сознательно. Хотя бы потому что в основном все пишут про битовые поля, а других вариантов особо не предлагают. Хотелось продемонстрировать такую структуру данных, которая была бы максимально простой для понимания.
VCS, bug tracking, wiki — это именно те инструменты, которые дал нам технический прогресс и они облегчают нашу жизнь. Назначение их при этом не меняется. В начале документацию распечатывали на бумаге и подшивали в архивы, затем Брукс предлагал как более современное решение использовать «микрофиши» (уменьшенные в 90 раз фотокопии документов на плёнке). Сейчас мы фиксируем документацию в wiki. Но назначение инструмента от этого не меняется — распространение знаний о системе.